Understanding High-Level Kubernetes
k8s, k3s, minicube, oh my!
After getting a bit of practice with Docker and containerization technology in general, I figured it was time to take a swing at learning Kubernetes (k8s). This is a crazy deep topic. It would require an entire blog to talk about all of k8s most likely. That is not what this is for. This is my high-level understanding of how the most basic parts of a k8s cluster operate.
I find that I get a great benefit when trying to learn new topics by writing about it. That could be via notes, a blog post, drawing a chart/diagram etc.
Puzzle Pieces
Server
This piece is technically optional. In a cloud-native environment this is required, but in either a home-lab or on-prem environment it is not necessary. By 'not necessary' I mean that if you do not wish to have each of your Nodes running as a VM you could run each one on bare metal instead. (I am thinking of somehting like a Raspberry Pi Cluster). Of course you could also just have a single piece of hardware running multiple VMs in any environment.
In a cloud-native production environment this would be made up of whatever hardware is running in your chose cloud provider.
Nodes
Our nodes are our VM instances. Typically Linux based. They can also be bare metal as mentioned above in an on-prem or Raspberry Pi cluster, etc. Nodes are responsible for running our pods. Each node can have upwards of ~500 pods IIRC.
Pods
Pods are the heart of our k8s cluster. They contain our running containers which contain our application images. They are made up of a storage component and a networking component in addition to our container itself.
Control Plane (Master)
The control plane is typically a VM or other Linux machine that runs our commands for managing our k8s cluster. It contains all of the processes listed below.
Process
API
The kube-apiserver exposes a JSON request formatted REST API. This is the only piece of this process that users will interact with. This accepts any command from kubectl for example and then sends it down the chain for k8s to handle the request.
Scheduler
The kube-scheduler works to select a node for pods to be deployed to based on many various factors, which are out of the scope of being 'high-level'
Controller
The kube-controller-manager watches for changes to pods and nodes. It works to maintain the user-defined desired state.
etcd
etcd is a backing store for our cluster data. It is an open-source, disrtibuted key-value store. It can be swapped out for other storage platforms like MySQL, MongoDB, etc but I don't believe this is very common.
Kubelet
The kubelet agent runs on each node, including the master node. The kubelet agents communitcate with each other to report node status. It works in conjunction with the container runtime to run containers on each node.
Container Runtime
The container runtime operates on each node to handle all running containers within each pod. This runtime can be docker, containerd, cri-o, etc.