Warning
🚧 This series is a Work in Progress
I am writing, rewriting and publishing almost everyday. Some of the write-up links to others and sometimes I realise that context should have been given earlier, so I reorganise the pages in the series.
It felt more valuable to share this series as I wrote it, rather than wait till I polish everything up. This keeps me motivated to iterate quickly and avoid procrastination.
Feel free to share your thoughts and opinions as comments.
Now that you know what the control plane and containers are, you must be wondering where they run on a k8s cluster.
Your workload on K8s, runs on nodes. K8s places your containers into something called a pod and then that Pod runs on Nodes. Consider a node as a virtual or physical machine in your cluster, based on the type of cluster you manage.
In a cluster, you generally have multiple nodes and each node may have 1 or more pods running on them. This is entirely up to the configuration of the containers. There may be cases where it is best for a couple of containers to run on the same pod, whereas in other circumstance, there maybe pods that must never run on the same node. We’ll look at the terminology of the configuration behind that later.
But what does a node do though. Running a pod seems easy. Or is it?
Node components
A node includes the following:
kubelet
This is the main application that runs on a node - also called a “node agent”. It registers the node with the k8s api-server using:
- hostname
- a flag to override the hostname
- specific logic for a cloud provider
It’s main responsibilities are:
- It helps with container management and orchestration.
- It supports the communication between the control plane (part of the cluster that controls everything else. it is another concept to uncover later) and the individual nodes.
Container runtime
Covered this in the post on containers
Without a working container runtime on each node, the kubelet would fail to launch pods and their containers.
kube-proxy
Also known as the k8s network proxy. This runs on every node. It takes care of all the network traffic things - TCP, UDP and SCTP stream forwarding or round robin forwarding across a set of backends. It monitors changes that happen to network related things and translates it into actual network rules inside the node. We’ll slowly uncover those things as we progress.