Topics Covered:
The Kubernetes Cluster Architecture
Building our Kubernetes Cluster
Kubeadm Installation and Deep Dive
Understanding Kubernetes Static Pods
Understanding CNI
Working with Kubectl context and kubeconfig
Working with Role Base Accessed Control
Maintaining the Cluster
Managing the certs and rotation
Upgrading the Cluster
Backing up the etcd
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
devopscube.com/setup-kubernetes-cluster-kub..
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 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:
Makes sure the cluster have L3 Connectivity. (Routing traffic to different environments [both at pods and node levels] )
Network Policy enforcement
IPAM
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:
- 1. Create a user
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
5. Add RBAC to the user
Create role / cluster role
Create rolebinding / cluster rolebinding
kind: Role
apiVersion: rbac.authorization.k8s.io/v1
metadata:
namespace: databases # Same namespace as the one in the context
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 # Here we say it's a normal user and not a service account
name: team-readonly # Here is where we define the user we created and defined in the context
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:
Cluster role / role
Cluster rolebinding / rolebinding
Users Groups and Service Accounts
Maintaining the Cluster
Managing the certs and rotation
Upgrading the Cluster
Backing up the etcd
Those maintenance tasks above have different implementations, you can use a configuration management tool to automate the process.