Introduction to Kubernetes - main components
Quick 101 about main components of the Kubernetes ecosystem
Welcome to a quick 101 about the main Kubernetes components. Kubernetes, often referred to as K8s, is an open-source system designed to orchestrate containers – automate deploying, scaling, and managing containerized applications. It groups containers that make up an application into logical units for easy management and discovery.
Patient Introduction: Our patient for today’s discussion is a young prodigy, just 12 years old. Despite his tender age, he has already graduated with honors from the prestigious Cloud Native Computing Foundation project hub. He is none other than Kubernetes, arguably the best container orchestration system available today. Kubernetes has revolutionized the way we manage and orchestrate containerized applications, making it a vital part of modern DevOps toolchains.
The anatomy of Kubernetes: Well that can be a real rabbit hole! Kubernetes is intricate and complex, much like the inner workings of a living organism. To do justice to its complexity, we will be conducting an in-depth autopsy of Kubernetes in a three-part blog post series. In these posts, we will dissect and explore the main components of Kubernetes, including its architecture, services, and key features. Stay tuned for a deep dive into the world of Kubernetes, where we unravel the secrets of this powerful orchestration tool.
The Basic Components of Kubernetes
The Kubernetes ecosystem is a vast and intricate network, but at its core, it is primarily composed of two main components: the master node and the worker nodes. Each of these components plays a crucial role in the orchestration of containerized applications, and each deserves its own spotlight.
So, let’s dive in!
The Kubernetes Control Plane (the Master Nodes)
The master node is the central point of control for a Kubernetes cluster. It is the brain of the operation, responsible for maintaining the cluster state and managing the life cycle of all other nodes in the cluster. The master node exposes the Kubernetes API, which your command-line tools talk to. It has no web interface of its own; a dashboard is an optional add-on.
The master node houses several key components:
- API Server: This is the communication hub for the cluster. It serves as the entry point for all your GUIs and command line tools.
- ETCD: This is a key-value store used to store the configuration of the cluster.
- Controller Manager: This component runs the controllers that keep the actual state of the cluster in line with what you asked for.
- Scheduler: This component finds new Pods that have no node yet and assigns each one to a suitable worker node.
In a production environment, there are usually multiple master nodes to ensure the robustness of the whole cluster. Collectively, all master nodes are referred to as the Control Plane. This term has replaced the term “Master Node” in various project documentations, reflecting a broader shift in IT terminology.
The Kubernetes Worker Nodes
Worker nodes are the workhorses of a Kubernetes cluster. They run your applications and tasks, managed by the master nodes. Inside worker nodes, you’ll find pods, which house the containers of various apps. So, in essence, worker nodes are where your app comes to life.
Each worker node contains:
- Kubelet: A process that runs on each worker node and communicates with the master nodes to ensure that the containers on the worker node are running as expected.
- Kube-proxy: This component is responsible for routing traffic to the correct container on the worker node, as there can be multiple, even thousands, of containers on a node.
- Container runtime: This is the component that actually runs the containers on the worker node, today usually containerd or CRI-O. Kubernetes removed its direct Docker Engine support in version 1.24. Images built with Docker still work exactly the same.
The Kubernetes Pods
Inside worker nodes, you’ll find pods. Think of a pod as the outer Matryoshka doll: open it and the containers are inside. A Kubernetes pod is a group of containers that are deployed together on the same host. Pods are the smallest deployable units in Kubernetes and consist of one or more containers, all running on the same host and sharing one network identity. Pods are created and destroyed as needed by the Kubernetes master and are assigned a unique IP address, but that address disappears with the pod, which is why traffic normally reaches pods through a Service.
The Kubernetes Sidecar
A sidecar is a special type of container that runs alongside another container in a pod. Sidecars are used to add functionality to a pod that is not provided by the main container. For example, a sidecar might be used to add logging or monitoring capabilities to a pod.
Sidecars used to be a convention rather than a feature. Since Kubernetes 1.33 they are a stable, native feature: a sidecar starts before your application and stops after it.
What Kubernetes Components Mean for Your Business
A board doesn’t need to know what etcd is. It does need to know what breaks when it goes.
| Component | If it fails | Who carries it |
|---|---|---|
| Worker node | Pods managed by a controller restart on other nodes after a delay, if spare capacity exists. Stateful pods can take longer | You, by paying for that spare capacity |
| Control plane | Running applications carry on, because the kubelet on each node keeps their containers going, but nothing can be deployed, scaled or healed | The provider, on a managed service |
| etcd | The cluster loses its record of what should be running | The provider on a managed service; on your own hardware, you and your backups |
| Pod | Replaced automatically by its Deployment. With one replica you still get a short outage, so run at least two | Your engineers, in the application design |
That table is also the short argument for a managed service. Most SMEs should let a provider carry the control plane and etcd rows, and spend their attention on the other two.
The provider carries the control plane, though, not the hardware your nodes run on. On one AWS project the cluster kept scaling up and down for no reason we could find in our own workloads. As far as we could tell, the cause was faulty EC2 capacity at AWS’s hypervisor level, and it went on for more than two weeks. What fixed it was moving to another region, not just another availability zone, and later moving back on a different instance family in a different zone. I know now that we could have handled it better. At the time, it was the option the business agreed to.
Whether any of this is worth it for your company is a separate question, and it’s the one I answer in Kubernetes for SMEs.
Summary
In this first part of our Kubernetes journey, we’ve explored the basic components of the Kubernetes ecosystem. We’ve delved into the roles and functions of the master node, worker nodes, and pods, and even touched on the concept of a sidecar.
As we wrap up this part, you should now have a foundational understanding of how these components interact to orchestrate containerized applications efficiently. But our journey doesn’t end here. In the next part, we’ll dive deeper into additional components and abstract concepts that are vital for the whole Kubernetes ecosystem. We’ll unravel more layers of this powerful tool, further enhancing your understanding of Kubernetes.
Check out all the articles in this series
`[Elementor widget: eael-post-grid]`
Are you considering streamlining your business processes with modern technology? You have heard of Kubernetes and wondered if it’s right for your organization?
Let’s discuss how Kubernetes can benefit your business!
Tell me about your current applications, IT infrastructure setup, and deployment methods. In return, I’ll share how containerization orchestration can enhance the productivity of your entire team, from developers and testers to DevOps and SecOps.
I’ll walk you through the potential benefits, my approach, and the strategic business and technology partnerships I bring to the table.
I believe in delivering tangible outcomes, not just selling visions. And that is why a discovery consultation is free.
Don’t hesitate and contact me today!