Topics Covered:
The Kubernetes Architecture
Control Plane
API Server - handles the request from client such as kubectl. Responsible for authentication and authorization of request.
Etcd - stores the state of the cluster and its configurations
Scheduler - schedule a pod to a node.
Controller - runs an infinite loop to maintain the desired state to the current state (e.g. cronjobs, daemonsets, replicasets)
Worker Plane
Kubelet - receives instruction from the scheduler then assigns the Pods to a Container Runtime
Container Runtime - allows a pod/containers to be runnable. Eg. docker, cri-o
Kubeproxy - forward the request to the appropriate service and endpoints.
Building Our Kubernetes Cluster
Kubernetes Installation via kubeadm
https://devopscube.com/setup-kubernetes-cluster-kubeadm/
Good to know:
- Container runtime (either containerd or cri-o). It allows us to run container in host system. Check the image below how container runtime fits in the process. Image from https://phoenixnap.com
Understanding Kubernetes Static Pods
These are the pods that are created when boostrapping a cluster via kubeadm on the kube-system :
coredns - default dns for kubernetes. Provides service discovery and resolving dns names. DNS allows us to map a name to an IP. Allows use of external domain name.
kube-proxy - forward the request for appropriate endpoints and services. acts as a proxy, intercepts a traffic and redirect to specific service.
etcd - store the state of the cluster. Responsible for persisting configuration. (Stores endpoint)
apiserver - handles incoming requests from kubectl and others. Responsible for aut
scheduler - schedules pods to worker nodes
controller - runs an infinite loop to maintain the desired state to the current state (e.g. cronjobs, daemonsets, replicasets)
Understanding Kubernetes Networking Plugin
There are two main purpose of Kubernetes Networking plugin:
Working with Kubectl context and kubeconfig
A Kubernetes context consists of a cluster, a namespace, and a user and is the configuration used to access a specific cluster and namespace
Allows use to give access to specific user
Steps:
adduser team-readonly
passwd team-readonly
- 2. Create keypairs and certificate
openssl genrsa -out team-readonly.key 2048
openssl req -new -key team-readonly.key \
-out team-readonly.csr -subj "/CN=team-readonly"
sudo openssl x509 -req -in team-readonly.csr \
-CA /etc/kubernetes/pki/ca.crt \
-CAkey /etc/kubernetes/pki/ca.key \
-CAcreateserial \
-out team-readonly.crt -days 360
- 3. Update kubeconfig to include the keypair and certificate and
team-readonly user
kubectl config set-credentials team-readonly \
--client-certificate=team-readonly.crt \
--client-key=team-readonly.key
- 4. Create a new context. Including user, namespace and cluster
kubectl config set-context nontechnical-view \
--cluster=kubernetes \
--namespace=databases \
--user=team-readonly
kind: Role
apiVersion: rbac.authorization.k8s.io/v1
metadata:
namespace: databases
name: team-readonly
rules:
- apiGroups: ["", "extensions", "apps"]
resources: ["deployments", "replicasets", "pods", "nodes"]
verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]
---
kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
name: team-readonly-role-binding
namespace: databases
subjects:
- kind: User
name: team-readonly
apiGroup: ""
roleRef:
kind: Role
name: team-readonly
apiGroup: ""
Check this: https://kubernetes.io/docs/reference/access-authn-authz/rbac/
Working with Role Base Accessed Control
Different users/groups == different level access. (cluster level, namespace level, resources, verbs access, particular application, api groups etc)
Roles and Cluster roles containes (resources, verbs) that is rolebinded (rolebinding) to users/groups/service accounts.
Elements:
Maintaining the Cluster
Those maintenance tasks above have different implementations, you can use a configuration management tool to automate the process.
