Introduction
Kubernetes is an open-source platform for maintaining containerized workloads and services that helps declarative automation and configuration. It is extensible as well as portable and has a fast-growing ecosystem. It aims to implement more reliable ways of managing distributed components, and services across multiple infrastructures.
In this blog post, we will be going through beginners’ view of the main Kubernetes components which will be helpful for anyone who is looking forward to learning the basics of Kubernetes and how Kubernetes components work. We will cover basic Kubernetes structure and components right from what each container constitutes, to how objects are scheduled and deployed across every worker. It is essential to understand the full architecture of the Kubernetes cluster in order to be able to complete and design a solution based on Kubernetes as an orchestrator for containerized applications.
Though this blog may seem complicated at first glance, it’s actually not. I’m sure that by the end of this blog post, you will have a clear understanding of how these Kubernetes components interact with each other.
To make it simpler for you we have got an exclusive blog post on Beginner’s Guide to Kubernetes. We recommend checking that blog before you start digging into Kubernetes Clusters and Core Components.
Let’s dig deeper and understand the major and critical Kubernetes components, which are –
1. Master Components
- 1. Etcd
- 2. API Server
- 3. Controller Manager
- 4. Cloud Controlling Manager
- 5. Scheduler
2. Worker/Slave Node Components
- 1. Pods
- 2. Docker Container
- 3. Kubelet
- 4. Kube-proxy
- 5. Kubectl
- 6. Master and Worker Node Interaction
We will cover each and every component listed above in detail and understand how each one of these Kubernetes components interdependent on each other.
Kubernetes Tutorial: Guide to K8s, Containers & Container Orchestration
The Kubernetes master node is the component where the core control plane services live. Though not all services have to reside on the same node; for practicality and centralization, they are often used in this way. This certainly raises services availability questions; but, they can easily be overcome by owning several nodes and providing load balancing requests to obtain a highly available set of master nodes. Even though master nodes can run on either bare metal servers, virtual machines, or a private or public cloud, it is recommended to not run container workloads on them.
The master node comprises of five basic services:
- Etcd database
- Kube-API server
- Kube-controller-manager
- Cloud-controller-manager
- Kube-scheduler
The Kubernetes master runs the components that are responsible for managing the Kubernetes cluster. Essentially, these components act as the brain of the cluster! Now, let’s dive into each of these master components.
Etcd
The Etcd is a simple, consistent, distributed, and shared key-value store component. It is mainly used for configuration management, service discovery, coordinating distributed work, and shared configuration. In the case of Kubernetes, etcd, reliably stores the configuration data of the Kubernetes cluster. Representing the state of the cluster, such as what pods should be running, what all nodes exist in the cluster, which nodes they are running on, and several more at any time. It is always recommended to have a backup plan for all cluster data is stored in etcd. Using the etcdctl snapshot save command, You can easily back up your etcd data. You can back up, etcd, by taking a snapshot of the EBS volume even when you are running Kubernetes on AWS. Etcdctl (Etcd control) is the command-line interface tool written in Go. This command allows manipulating an etcd cluster. It is used to perform a variety of functions, such as:
- Add or delete, etcd nodes
- Set, update, and eliminate keys
- Creating database snapshots
- Validate the cluster stability and health
API Server
The API server is utilized to manage all of the REST commands that are used to control the Kubernetes clusters. When you communicate with your Kubernetes cluster using the Kube-control (kubectl) command-line interface, you are actually interacting with the master API Server component. The API Server acts as the central management point of the entire Kubernetes cluster. Basically, it processes all of the REST operations, verifies them, and updates the corresponding objects in the etcd component.
The API Server works up the Kubernetes API and is designed to be a comparatively simple server, by most business logic implemented in different plugins or on separate components. This server is also in charge of the authorization and authentication mechanism. Before interacting with the API Server, all API clients should be authenticated. The API Server also performs a watch mechanism so that API clients can observe the changes. This is similar to the etcd mechanism. It allows components such as the Controller Manager and Scheduler to interact with the API Server in a loosely coupled way. This API server pattern is broadly used in Kubernetes.
Controller Manager
The Kubernetes Controller Manager is a component that controls the Kubernetes cluster. It also operates and embeds different non-terminating core control loops known as “controllers” that are shipped with Kubernetes. The control manager runs several distinct controller processes in the background. Basically, a control manager observes the state of the cluster through the API Server watch feature. When the server notifies the controller, it makes the necessary changes in an attempt to move from the current state towards the desired state. Some examples of controllers that ship with Kubernetes include the Endpoints Controller, Replication Controller, and Namespace Controller. An endpoint controller populates endpoint objects like services and pods. A replication controller controls a number of replicas in a pod.
This is done to improve the shared state of the cluster and perform regular tasks. Whenever there is a change in the service configuration, such as a change in parameters in the configuration YAML file or replacement of an image from which the pods are running, the controller detects the change and starts working towards the new desired state. Moreover, the Kube-controller-manager performs lifecycle functions such as namespace creation and lifecycle, event garbage collection, cascading-deletion garbage collection, node garbage collection, terminated-pod garbage collection, etc.
Cloud Controller Manager
Cloud-controller-manager is in charge of managing the processing of the controller with dependencies on the underlying cloud provider (if any). For instance, the controller is used to check if a node was terminated or was setting up routes, volumes, load balancers, or the cloud infrastructure. All these are single handedly managed by the cloud-controller-manager.
Scheduler
The Kube-scheduler maintains and records the tasks to the worker node component. It registers the information and files it on resource usage for each worker node. The Scheduler looks out for unscheduled pods and then connects them to nodes via the binding pod subresource API. This binding is done depending upon the availability of the requested resources, affinity and anti-affinity specifications, quality of their service requirements, and many other constraints. Once a node has been assigned to the pod, the normal behavior of the Kubelet is triggered, and this creates the pod and its containers.
The Kube-scheduler records and schedules your newly created pods and containers to the nodes that have enough space to satisfy the resource needs of the pods. It basically communicates with the Kube-API server and the Kube-controller-manager about the freshly created pods that are put into a queue and then later scheduled to an available node by the Kube-scheduler. Other than computing resources, the Kube-scheduler reads the affinity and anti-affinity rules of the nodes to figure out whether a node is capable of running that pod or not.
Understand Kubernetes Components in 5 mins
Worker/Slave Node Components
The worker nodes components in Kubernetes are the nodes that combine all the necessary tools and services to manage the networking between the containers.
These are simply called as a node component as to Earlier, in 2014, they were named as minions components of the Kubernetes. The managing tasks it performs are communication with the master node and distributing resources to the other scheduled containers. The worker nodes are the only place to be running workloads, as it is not suggested to have containers or loads on the master nodes, as they need to be available to manage the entire cluster altogether.
The worker nodes are very simple in terms of components; they only require five services to fulfill their task:
- Etcd database
- Kube-API server
- Kube-controller-manager
- Cloud-controller-manager
- Kube-scheduler
Let’s explore these five components in a little bit more depth –
Pods
A pod component in Kubernetes cluster is a single or multiple containers on nodes that logically operate together. It usually belongs to one or more containers that should be managed as a single application. A pod encapsulates storage resources, a unique network ID, application containers, and other configurations that are used to run the containers.
Docker Container
Docker container runs and operates the configured pods on each of the worker nodes. We need a docker container runtime to be able to spin up containers. Container runtime is the base engine that will create the containers in the node’s kernel for our pods to run. The kubelet component will then communicate to this runtime to spin up or stop our containers on demand. Presently, Kubernetes supports any OCI-compliant container runtime, such as Docker, Runc, Runsc, Rkt, and so on.
Kubelet
The kubelet is a service on the Kubernetes that runs Kubernetes nodes and monitors to the API server for pod creation. It is a low-level Kubernetes component. It is also one of the most important components after the Kube-API server. Both of these components are necessary for the provisioning of pods and containers in the cluster. Kubelet initiates the configuration of a Pod from the API server and guards the specified containers that are up and working. The kubelet is only one responsible for starting, stopping the containers in pods, and also making sure that they are stable running in the desired state. This component also reports to the master on the status of the host and where it is running.
The kubelet will not be able to maintain any containers that it did not create. It accomplishes its goals by communicating with the container runtime via container runtime interface. The container runtime interface provides pluggability to the kubelet via a client, which can speak with different container runtimes. As we stated earlier, Kubernetes maintains various container runtimes to deploy containers, and using kubelet is how it achieves such diverse support for multiple engines.
Kube-proxy
Kube-proxy is a proxy service that operates as a network proxy and a load balancer for functions that operate on a single worker node. This service works on every worker node and deals with each individual subnetting host to expose services to the external world. It functions by forwarding requests to the right pods or containers in a cluster across several isolated networks. This proxy service resides on each node of the cluster.
The Kube-proxy service is the one that makes communications between pods, containers, and nodes possible. It observes the Kube-API server for modifications on defined services (in Kubernetes, service is a kind of logical load balancer) and keeps the network up to date via IP tables rules. These rules direct the traffic to the correct endpoints. The Kube-proxy service also sets up rules in IP tables that do random load balancing across pods behind a service.
Kubectl
The Kubernetes control command – kubectl is a line tool that allows you to run commands against Kubernetes clusters. You can use the Kube control command to interact with the Kube-API server to send commands to the master node. It is used to inspect and manage cluster resources, deploy applications, and view logs. In kubectl command, each command is converted into an API call.
Master and Worker Node Interaction
The master component is responsible for choosing what runs on all of the cluster’s nodes. This includes deciding upon scheduling workloads such as containerized applications and managing the workloads’ life-cycles, such as scaling and upgrading them. The master component also maintains storage and network resources for those workloads on clusters.
The master and worker nodes communicate using Kubernetes APIs. The master components interact with the worker node cluster over the API server using a secure port. As a result, the communicating mode for connections from the cluster nodes to the master is secured by default and can be operated over untrusted public networks.
Summary
Kubernetes is an orchestration application for maintaining containerized tools or distributed services over a distributed cluster of nodes. It was structured to natively support high availability, auto-scaling, high security, and portability. Kubernetes follows a master node composed of client-server architecture, which includes etcd cluster, Kube-API server, Kube-controller-manager, cloud-controller-manager, and scheduler. Client nodes are composed of Kube-proxy and kubelet components. Core objects in Kubernetes include pods (a group of containers deployed together), services (a group of logical pods with a stable IP address) and deployments (a definition of the desired state for a pod or replica set, acted upon by a controller if the current state differs from the desired state), among others.
Subscribe to our blog for more such articles!
