Kubernetes Components

Kubernetes Components

A cluster is what you get when you install Kubernetes. Worker machines known as nodes that run containerized apps make up a Kubernetes cluster. At least one worker node is present in each cluster. The Pods, which are a part of the application workload, are hosted by the worker node(s). Worker nodes and Pods in the cluster are controlled by the control plane which is a part of Kubernetes components. In production scenarios, the control plane is frequently distributed across a number of computers, and a cluster is distributed across a number of nodes, providing fault tolerance and high availability.

Control Panel Components

In Kubernetes Components, the control panel's parts decide on the cluster as a whole (such as scheduling), as well as recognise and react to cluster events (such as launching a new pod when the replicas' field of deployment is not met).

Any cluster nodes designated as control plane nodes that run these components. On the other hand, setup scripts frequently start all control plane components on the same computer without running user containers there.

As illustrated in the graph, there are four components operating on the Kubernetes control plane in Kubernetes components, each of which is necessary for maintaining a healthy Kubernetes cluster, and they play various roles inside the cluster:

• kube-apiserver: a part of the Kubernetes control plane that makes the API available. The API server serves as the front end of the Kubernetes control plane.

• etcd: A trustworthy and highly accessible key-value store that acts as the central repository for all cluster data in Kubernetes.

• kube-scheduler: It searches for recently created Pods without an associated node and selects one for them to run on.

• kube-controller-manager: Using the API server watch feature, it keeps track of the cluster's state and makes adjustments to get it into the required condition. There are several sorts of controllers . Here are a few examples:

  • Node controllers: The task of identifying and responding to node failures falls on node controllers.
  • Job controller: It searches for Job objects that represent one-time tasks before building Pods to do them.
  • EndpointSlice controller: The creation of EndpointSlice objects (used to link Services and Pods).
  • ServiceAccount controller: Apply the ServiceAccount controller to new namespaces to create default ServiceAccounts.

• cloud-controller-manager:

  • In Kubernetes components,a Kubernetes control plane component with built-in cloud-specific control logic. The cloud controller manager separates components that interface with the cloud platform from those that solely interact with your cluster, enabling you to link your cluster to your cloud provider's API.
  • Only controllers relevant to your cloud provider are managed by the cloud-controller-manager. When you deploy Kubernetes on your own premises or in a learning environment on your own PC, the cluster lacks a cloud controller manager.
  • The cloud-controller-manager, similar to the kube-controller-manager,combines a number of conceptually independent control loops into a single binary that executes as a single process. You can scale horizontally (run several copies) to increase performance or put up with errors.
  • The following controllers may be dependent on a cloud provider:
    • Node controller: Checks the cloud provider to see whether a node in the cloud has been removed when it stops responding.
    • Route controller: A device used to configure routes in the underlying cloud architecture.
    • Service controllers are used to create, update, and delete cloud provider load balancers.

Node Components

In Components of kubernetes, Every node has node components that are part of components of kubernetes that keep pods operating and provide the Kubernetes runtime environment.

• kubelet:
  • An agent that operates on each cluster node. It ensures that containers in a Pod are operating.
  • The kubelet accepts a variety of PodSpecs given in a variety of methods and ensures that the containers specified in those PodSpecs are operational. The kubelet does not handle containers that were not created by Kubernetes.
• kube-proxy:
  • kube-proxy is a network proxy that operates or runs on all cluster nodes and implements a component of the Kubernetes Service model.
  • kube-proxy maintains network rules on nodes up to date. These network limitations allow network access to the Pods via network sessions both within and outside of the cluster.
• Container Runtime
  • The container runtime is the software that is in charge of container execution.
  • Kubernetes supports container runtimes such as containerd, CRI-O, and any other Kubernetes CRI (Container Runtime Interface) implementation.

Add on Components

In Components of kubernetes, Addons implement cluster functionalities by using Kubernetes resources (DaemonSet, Deployment, and so on) are components of kubernetes. Namespaced resources for addons belong in the kube-system namespace since they provide cluster-level features.

DNS:

• While the other addons are optional, cluster DNS should be included in all Kubernetes clusters because many examples rely on it.
• Cluster DNS is a DNS server that, in addition to the existing DNS server(s) in your environment, delivers DNS records for Kubernetes services. By default, Kubernetes containers include this DNS server in their DNS requests.

Web UI (Dashboard): Dashboard is a user interface for Kubernetes clusters that is accessible over the web. It allows users to manage and troubleshoot both clustered apps and the cluster itself.

Container Resource Monitoring: Container Resource Monitoring maintains a centralized collection of generic time-series metrics about containers and provides a user interface for studying that data.

Cluster-level Logging: Container logs are saved to a central log store with a search/browsing interface through a cluster-level logging mechanism.

Network Plugins: Network plugins are software components that implement the container network interface (CNI) standard. They are in charge of assigning IP addresses to pods and allowing them to communicate with one another inside the cluster.