This blog post will provide a simple overview of Kubernetes architecture, offering insight into its key components. By the end, you’ll have a clear grasp of how Kubernetes orchestrates containerized applications and manages your cluster’s resources efficiently.
If you’re new to Kubernetes, I highly recommend starting with this blog post for an introduction to Kubernetes basics. Once you’ve got the fundamentals down, you’ll be well-prepared to dive into our exploration of Kubernetes architecture.
A Kubernetes cluster comprises worker machines known as nodes. These nodes run containerized applications, ensuring the system runs smoothly. Importantly, every cluster must have at least one such worker node.
The worker node(s) host the Pods that are the components of the application workload. Meanwhile, the control plane oversees these worker nodes and manages all the Pods in the cluster.
Control Plane Components
The control plane is like the brain of the cluster. It handles tasks such as scheduling workloads, scaling applications, monitoring health, and many other essential functions. In production environments, the control plane usually runs across multiple computers and a cluster usually runs multiple nodes, providing fault-tolerance and high availability.
Now let’s deep-dive into the main components of the control plane.
API server
The API server acts as the cluster gateway handling the request for updates or queries. It handles authentication and authorization for all requests to the Kubernetes API. It verifies the identity of users and components, checks their permissions against the cluster’s access control policies, and grants or denies access accordingly.
Event notification is another important aspect of the API server’s functionality. It generates events to notify clients of changes to resources within the cluster, such as Pod creations, deletions, or updates. Clients can subscribe to these events to receive real-time notifications about relevant changes, enabling them to react accordingly.
Scheduler
As the name suggests, the scheduler is responsible for determining which node in the cluster should run the new Pod that is created. It evaluates various factors such as resource requirements, node capacity, and other constraints specified in the Pod’s configuration. Once the scheduler determines the best node for a Pod, it updates the Kubernetes API server with the Pod’s assignment, a process known as binding. This ensures that the kubelet on the selected node is notified to start the Pod.
The scheduler continuously monitors the cluster’s state and adjusts Pod placement dynamically in response to changes such as node failures, resource availability, or changes in Pod requirements.
Controller Manager
The controller manager is defined by a collection of controllers, each of which is responsible for managing objects of a specific resource type on the cluster. It plays a crucial role in ensuring the desired state of the cluster by managing various controllers responsible for different aspects of cluster management, including replication, node health, resource allocation, and application deployment.
The controller manager continuously checks the cluster’s state against the desired state through the API server. If the cluster’s configuration doesn’t match our intentions, the controller manager utilizes the API server to make the necessary adjustments and align it with our desired state.
etcd
etcd is a distributed key-value store that serves as the primary data store for Kubernetes, storing the cluster’s configuration data and state information.
It stores configuration data such as API server settings, networking configurations, and authentication parameters, ensuring consistent cluster-wide settings. Note that the actual application data doesn’t get stored in the etcd.
Note: etcd is the only stateful component in our control plane, all other components are stateless.
Node Components
Node components run on every node, maintaining running pods and providing the Kubernetes runtime environment.
kubelet
The kubelet acts as a node’s agent which runs on each node in the cluster ensuring that Pods are running and healthy on those nodes. It ensures that Pods are started, stopped, and restarted as necessary, based on the desired state. The kubelet interacts with the container runtime to execute and manage containers within Pods.
The kubelet enforces resource constraints such as CPU and memory limits. It monitors resource usage on the node and ensures that containers are allocated the appropriate amount of resources. The kubelet regularly reports the status of Pods running on the node to the Kubernetes control plane. This includes information about container readiness, liveness, and any errors or issues encountered during Pod execution.
container runtime
The container runtime’s core role in Kubernetes revolves around managing the fundamental operations of containers. It oversees the creation, deletion, and lifecycle management of containers, responding to directives from Kubernetes components like the kubelet. The container runtime enforces resource isolation for containers, ensuring that they have access only to the resources allocated to them.
Essentially, the container runtime acts as the underlying engine responsible for executing and overseeing containers within the Kubernetes environment. Examples include Docker, containerd, and cri-o.
kube-proxy
The role of kube-proxy in Kubernetes is to manage network connectivity to Pods and services within the cluster. It enables containers to communicate with each other across the various nodes on the cluster. This component handles all the networking concerns such as how to forward traffic to the appropriate pod.
Kube-proxy implements a simple network proxy and load balancer to distribute incoming traffic across multiple Pods providing the same service. It ensures that requests are evenly distributed among available Pods, improving the availability and scalability of services. Kube-proxy monitors Pod health and dynamically updates load balancing, directing traffic only to healthy Pods.
As you continue your Kubernetes exploration, remember that understanding its architecture is just the beginning. There is much more to learn and explore, from advanced concepts to best practices for managing and scaling your Kubernetes clusters.
Keep experimenting, learning, and pushing the boundaries of what you can achieve with Kubernetes. Stay tuned for more insightful posts on Kubernetes and related topics.