A Kubernetes cluster consists of a set of work machines called nodes that run containerized applications. Each cluster has at least one worker node.
The worker node hosts pods, which are components of the application workload. The control plane take care of the worker nodes and pods in the cluster. In a production environment, the control plane typically runs on multiple machines, and clusters typically run on multiple nodes, providing fault tolerance and high availability.
This post describes the various components required for a fully functional Kubernetes cluster.
Control Plane Component
The control plane component makes global decisions about the cluster and detects and responds to cluster events.
Kube API server
It is a component of the Kubernetes control plane that exposes the Kubernetes API and it is the front end of the Kubernetes control plane.
The main task of the Kubernetes API server is kube-apiserver. kube-apiserver is designed to scale horizontally. That is, it scales by deploying more instances. You can run multiple instances of kube-apiserver and balance the traffic between those instances.
etc
A consistent and highly available key-value store used as the Kubernetes backing store for all cluster data.
If your Kubernetes cluster is using etcd as backup storage, make sure you have a backup plan for this data.
Kube Scheduler
A control plane component that searches for newly created pods that have no nodes assigned and selects the node to run them.
Kube controller manager
A control plane component that runs the controller process. Logically, each controller is a separate process, but to reduce complexity, everything is compiled into a single binary and run in a single process.
Some types of these controllers are:
1. Node Controller
Responsible for detecting and responding to node failures.
2. Job Controller
Finds job objects that represent one-time tasks and creates pods to complete those tasks.
3. Endpoints Controller
Enter data into the Endpoints object.
4. Service account and token controller
It will create a default account and API access token for the new namespace.
Cloud controller manager
A component of the Kubernetes control plane that incorporates cloud-specific control logic. You can use Cloud Controller Manager to connect your cluster to the cloud provider's API and separate the components that interact with that cloud platform from the components that interact only with the cluster.
The cloud controller manager runs only the controllers that are specific to the cloud provider. Like the kube controller manager, the cloud controller manager combines multiple logically independent control loops into a single binary and runs it as a single process. You can scale out to improve performance or tolerate bugs.
The following controllers can have cloud provider dependencies:
1. Node controller
It is used to check the cloud provider to determine if a node in the cloud was deleted after it became unresponsive.
2. Route controller
To route to the underlying cloud infrastructure
3. Service Controller
Create, update, and delete cloud provider load balancers
Node component
The node component runs on each node, keeps the pod running, and provides a Kubernetes runtime environment.
Kubelet
It is an agent running on each node in the cluster. Make sure the container is running inside the pod. The kubelet uses a set of PodSpecs provided through various mechanisms to ensure that the containers described in those PodSpecs are running and error free. kubelet does not manage containers that have not been created by Kubernetes.
Kube proxy
kube-proxy is a network proxy that runs on each node in the cluster and implements part of the Kubernetes service concept. kube-proxy manages node network rules. These network rules allow network sessions inside and outside the cluster to communicate with the pod.
kube-proxy uses the operating system's packet filtering level, if it exists and is available. Otherwise, kube-proxy routes the traffic itself.
Container runtime
It is the software accountable for running the container. Kubernetes supports container runtimes such as containerd, CRI-O, and other task of Kubernetes CRI.
Add-on
Add-ons use Kubernetes resources to implement cluster functionality. Add-on namespace resources belong to the kube-system namespace because they provide functionality at the cluster level.
DNS
Cluster DNS is a DNS server that provides DNS records for Kubernetes services in addition to other DNS servers in your environment.
Containers launched from Kubernetes will automatically include this DNS server in their DNS lookups.
Web UI
Dashboards are a generic web-based user interface for Kubernetes clusters. This allows users to manage and troubleshoot the applications running in the cluster and the cluster itself.
Container Resource Monitor
The Container Resource Monitor records common time series metrics for containers in a central database and provides a user interface for viewing this data.
Cluster level logging
The cluster-level logging mechanism is responsible for storing container logs in a central log store with a search / browse interface.
Gratitude for perusing my article till end. I hope you realized something unique today. If you enjoyed this article then please share to your buddies and if you have suggestions or thoughts to share with me then please write in the comment box.
Above blog is submitted as part of 'Devtron Blogathon 2022' - https://devtron.ai/
Check out Devtron's GitHub repo - https://github.com/devtron-labs/devtron/ and give a ⭐ to show your love & support.
Follow Devtron on LinkedIn - https://www.linkedin.com/company/devtron-labs/ and Twitter - https://twitter.com/DevtronL/, to keep yourself updated on this
Top comments (0)