This content originally appeared on DEV Community and was authored by Stephen Rodriguez
Welcome back to the next chapter of { Zero to Helm }. A blog-series in which I create "byte"-sized pieces of content aimed at mastering Kubernetes.
In this section, we are going to look to take a surface dive into Kubernetes by inspecting its architecture. Whether you are a fan of minimal version of k8s like k3s or robust cloud-specific versions like EKS, AKS, or GKE - the information explained here applies to all of them.
So lets start to breakdown this architecture:
Nodes
Kubernetes at its essence is a collection of servers that work together to achieve a single purpose; run your workloads. These servers are referenced as "Nodes", and their responsibility is to run your workloads by placing containers into Pods.
Since Nodes are servers, they can be anything from physical machines to even virtual ones! But each node is managed by something called a "control plane". Which is a collection of essential services that run on the node in order for Pods to be created, and managed by the node. Those services are the kubelet, a container runtime, and the kube-proxy.
Once a node is connected to a Kubernetes master node, it will begin to report vital information like:
- CPU/Memory availability
- Info about the host/kernel
- Heartbeats
All of this information help the control plane make decisions about where workloads get scheduled/assigned.
Control Plane Communication
When we say “Control Plane” - we are speaking about the essential services that run on the master nodes of your Kubernetes Cluster. Collectively, these services help Kubernetes perform most of its magic for being easily extensible, accessible, and able to run workloads efficiently.
Now - those magical services are:
-
kube-apiserver
Exposes the Kubernetes API that is used by worker nodes, kubectl, and other services to interact with the entire k8s control plane.
-
etcd*
This service can differ based on your k8s flavour but a simple highly available key/value store is used in k8s to track cluster states such as pod information, workload assignments, etc.
-
kube-scheduler
Watches for new pods without a node assignment and selects one for them. Various factors are taken into account but the assignment is based on the pod’s manifest and key scheduling information collected from the cluster’s available nodes.
-
kube-controller-manager
Runs controller processes like:
- Node Controller => Monitors cluster nodes
- Jobs Controller => Monitors Pods that run one-off tasks
-
cloud-controller-manager*
- This one is a bit of a special one because not every flavour of k8s will include it. But this service typically handles cloud specific control logic like identity permission controls, network rules, and anything else your cloud-hosting provider specifically requires for their flavour of k8s.
More info: Kubernetes Components | Kubernetes
And that’s it! It really is that simple at a high level. There is a lot more additional terminology like Services, Ingress, and Namespaces - but all in good time! The point here is not to overwhelm but rather to encourage individual discovery.
There are a lot of helpful links throughout here and I highly encourage you to dive deeper and investigate what other flavours of k8s look like! How do they differ? What’s similar…?!
As always, feel free to give feedback and let me know about your journey with Kubernetes! Until next time, happy coding!
This content originally appeared on DEV Community and was authored by Stephen Rodriguez
Stephen Rodriguez | Sciencx (2021-10-17T19:58:48+00:00) { Zero to Helm }: Part 2 – Architecture. Retrieved from https://www.scien.cx/2021/10/17/zero-to-helm-%e2%80%8apart-2-architecture/
Please log in to upload a file.
There are no updates yet.
Click the Upload button above to add an update.