kubernetes

Kubernetes is a container orchestrator for managing high scale deployment challenges

Architecture

The kubernetes cluster architecture presents itself as follows:

flowchart TD subgraph control_plane A[api-server] B[scheduler] C[control manager] D[etcd] end subgraph worker_1 E[kublet] subgraph container_runtime_1 F[pod] G[pod] H[pod] end end subgraph worker_2 I[kublet] subgraph container_runtime_2 J[pod] K[pod] L[pod] end end subgraph worker_3 M[kublet] subgraph container_runtime_3 N[pod] O[pod] P[pod] end end control_plane --> worker_1 & worker_2 & worker_3

Where the control plane node manages the worker nodes that run pods, pods are managed trough a container runtime (for example containerd) that runs the containers, the control plane is also responsible for managing deployments

Controllers and control loops

Controllers are entities that move that runs action until a given job is concluded, moving the cluster to the desired state

Control patterns

Controllers can make changes to the cluster in 2 modes, through the api server or directly interacting with external resources

--- title: control patterns --- flowchart LR subgraph api-server-control A@{shape: circle, label: "controller" } B@{shape: circle, label: "api-server" } C@{shape: rect, label: "cluster" } A -- make requests to --> B -- changes state --> C end subgraph direct-control D@{shape: circle, label: "controller" } E@{shape: rect, label: "external resource" } F@{shape: rect, label: "cluster" } D -- make requests to --> E -- changes state --> F end api-server-control ~~~ direct-control

Controllers typically monitors a set of kubernetes objects and delegate action to other elements and monitor the final state of the created objects

Networking in a kubernetes cluster

Containers and pods share a private network stack that allow them to communicate inside the cluster, and a name service

Deployment in a kubernetes cluster

Deployment on a kubernetes cluster is done trough the use of the api server using a descriptor that specifies:

🔷 Note

pods are the minimum unit of deployment in kubernetes

Installation using kubeadm

To install the control plane on a linux machine do the following (package manager updates are locked)

sudo apt-get update
sudo apt-get install -y apt-transport-https ca-certificates curl gpg
echo 'deb [signed-by=/etc/apt/keyrings/kubernetes-apt-keyring.gpg] https://pkgs.k8s.io/core:/stable:/v1.32/deb/ /' | sudo tee /etc/apt/sources.list.d/kubernetes.list
sudo apt-get update
sudo apt-get install -y kubelet kubeadm kubectl
sudo apt-mark hold kubelet kubeadm kubectl

This will install necessary components on a node to run the control plane, then initialize the cluster using the kubeadm command

# enable forwarding
sysctl net.ipv4.ip_forward=1 && echo 'net.ipv4.ip_forward=1' >> /etc/sysctl.conf
# install containerd
apt install containerd
# init kluster
kubeadm init

Configuring worker nodes

In worker nodes after installing the kubeadm tool, init the kubelet process

systemctl enable --now kubelet

Then join the kluster using kubeadm join command

Custom resource definitions (CRD)

Kubernetes is not limited to manage containers, it can in principle orchestrate any kind of resource using Custom Resource Definitions

🔷 Note

For example deploy a database inside kubernetes it’s possible but is not possible to define application specific practices like database backup and restore procedures or data replications

Controllers for CRDs

To make kubernetes do something when a CRD item is created a controller needs to listen for the creation event and do something to fulfill the creation and management of that item

flowchart TD A@{shape: proc,label: controller} B@{shape: doc,label: CRD records} A -- listen to events on --> B

🔷 CRDs are heavily used in crossplane

command tips

RESOURCE_TYPE=pod
RESOURCE_NAME=superpod
kubectl get $RESOURCE_TYPE $RESOURCE_NAME -n default -o yaml > ${RESOURCE_NAME}.${RESOURCE_TYPE}.yaml