Kubernetes, abbreviated as K8s, is a portable, extensible, open-source platform for managing contained workloads and services. It facilitates both declarative configuration and automation. It has a huge and rapidly growing ecosystem. Its services, support, and tools are widely available. Kubernetes docker supports container runtime. It is abbreviated as K8s because of the gap between the letter “K” and letter “S.” Google open sources for this project in 2014. It combines over 15 years of Google’s experience running production workloads at scale with best-of-breed ideas and practices from the community. Kubernetes docker supports container runtime. 

Components:

• Nodes:

A cluster consists of a set of worker machines called Nodes. They run containerized applications. Every cluster has at least one worker node.

The worker node(s) host the pods that are the components of the application workload. The control plane is responsible for managing the worker nodes and the pods in the cluster. The control plane usually runs across multiple computers, and a cluster usually runs multiple nodes, providing high availability and fault tolerance.

• Node components: node components run on every node, maintaining running pods and providing the Kubernetes runtime environment.

1. Kubelet: Kubelet is an agent that runs on each node in the cluster. It makes sure that containers are running in a pod. 

The kubelet takes a set of PodSpecs that are provided through various mechanisms and ensures that the containers described in those PodSpecs are running and healthy. The kubelet doesn’t manage containers which were not created by this tool.

2. Kube proxy:

Kube proxy is a network that runs on each node in your cluster, implementing part of the Kubernetes Service concept.

Kube proxy maintains network rules on nodes. These network rules allow network communication to the pods from network sessions inside or outside of the cluster.

Kube proxy uses the operating system packet filtering layer if there is one and it is available. Kube proxy forwards the traffic.

3. Container runtime: container runtime is the software that is responsible for running containers. It supports many container runtimes, namely, Docker, containerd, CRI-O, and any implementation of the Kubernetes CRI(Container Runtime Interface).

• Addons:

Addons use resources like DaemonSet, Deployment, etc to implement cluster features. Since these are providing cluster-level features, namespace resources for addons, it belongs within the kube system namespace.

Selected addons are listed below: 

1. DNS: While other addons are not strictly required, all kubernetes clusters should have cluster DNS since many examples rely on it.

Cluster DNS is a server and it is an addition to other DNS servers in the environment, which serves DNS records for its services.

Containers started by Kubernetes automatically include this DNS server in their DNS searches.

2. Web UI(Dashboard):

Dashboard is general purpose, web-based UI for kubernetes cluster. It allows users to manage and troubleshoot applications running in the cluster, as well as the cluster itself.

3. Container resource monitoring:

Container resource monitoring records generic time series metrics about containers in the central database. it also provides a GUI for browsing that data.

4. Cluster level logging:

Cluster level logging mechanism is responsible for saving container logs to a central log store with search or browsing interface.

• Control plane components:

Global decisions about the cluster, like scheduling, detecting, and responding to cluster events, like starting up a new pod when a deployment’s replicas field is unsatisfied, are the control plane’s responsibilities. 

Control plane components can be run on any machine in the cluster. Anyway, for simplicity, setup scripts typically start all control plane components on the same machine. They do not run user containers on this machine. For example, the control plane setup runs across multiple virtual machines.

• Kube-apiserver:

The API server is a component of the control plane which exposes the Kubernetes API. This API serves as the front end for the control plane. 

Kube-apiserver is the main implementation of the Kubernetes API server. Kube-apiserver scales horizontally. This means it scales by deploying more instances. Several instances of kube-api servers can be run and can be balanced with respect to traffic with those instances.

• Etcd:

It is a highly available and consistent key-value store used as a backing store for all cluster data. If the cluster uses etcd as its backing store, a backup plan for that data is a mandate.

• Kube scheduler:

Kube scheduler is a control plane component that watches for newly created pods with no assigned node. It also selects a node for them to run on. There are a few factors that are supposed to be taken into account while scheduling decisions are made: individual and collective resource requirements, software, hardware and policy constraints, affinity and anti-affinity specifications, data locality, deadlines, and inter-workload interferences.

• Kube controller manager:

Kube controller manager is the component that runs controller processes. Logically, every controller is a separate process, but to reduce complexity, they are all compiled into a single binary, and it is run in a single process. A few of the controllers are listed below:

i) Node controller: it is responsible for noticing and responding when nodes go down.

ii) Job controller: it watches for job objects that represent one-off tasks, then creates pods to run those tasks to completion.

iii) Endpoints controller: it populates the endpoints objects, which are joined services and pods.

iv) Service account and token controllers: they create default accounts and API access tokens for new namespaces.

• Cloud controller manager:

It is a control plane component that embeds cloud-specific control logic. The cloud controller manager lets the user like the cluster into the cloud provider’s API, and it separates out the components that interact with that cloud platform from components that only interact with the cluster.

The cloud controller manager only runs controllers that are specific to the cloud provider. If Kubernetes is run on a personal premise or in a learning environment inside the personal PC, the cluster does not have a cloud controller manager.

The cloud controller manager combines several logically independent control loops into a single binary that is run as a single process with respect to the Kube controller manager. It can be scaled horizontally, which means more than one copy can be run to improve performance or to help bare failures. 

Listed below are a few controllers that can have cloud provider dependencies:

i) Node controller: it is used for checking the cloud provider to determine if a node has been deleted in the cloud after it stops responding.

ii) Route controller: it is used for setting up routes in the underlying cloud infrastructure.

iii) Service controller: it is used for creating, updating, and deleting cloud provider load balancers.

The Kubernetes tutorial offered by Great Learning will help you learn Kubernetes for free. The Kubernetes course will help you learn the different components present in Kubernetes and how they work. It will help professionals to work better with the Kubernetes tool and also help students to work with their projects. You will earn a certificate for the Kubernetes course after the successful completion. You can also register for the free Kubernetes tutorial to learn it in your free time. Happy learning!