Kubernetes cluster components¶

A Kubernetes cluster includes the Kubernetes components as well as supplementary services that run on all or some of the nodes.

Unless noted otherwise, all listed components run as daemon processes on a host operating system, controlled by systemd.

The components can be divided into the following types:

Common components

These components run on all nodes in a Kubernetes cluster.

• The kubelet agent service is responsible for creating and managing containerd containers on the Kubernetes cluster nodes.
• The kube-proxy service is responsible for the TCP/UDP stream forwarding or round-robin TCP/UDP forwarding across various backends to reach cluster services (acts as a service proxy). This service is used for the Calico SDN only.

Master components

These components run on the Kubernetes Master nodes and provide the control plane functionality.

• The etcd service is a distributed key-value store that stores data across a Kubernetes cluster.
• The kube-addon-manager service manages two classes of addons with given template files located at /etc/kubernetes/addons/ by default. It runs as a pod controlled by Kubernetes.
• The kube-apiserver REST API server verifies and configures data for such API objects as pods, services, replication controllers, and so on.
• The kubectl command-line client for the Kubernetes API enables cloud operators to execute commands against Kubernetes clusters.
• The kube-control-manager process embeds the core control loops shipped with Kubernetes, such as the replication controller and so on.
• The kube-scheduler utility implements the scheduling functions of workloads provisioning in pods to specific Kubernetes Nodes according to the capacity requirements of workloads, Nodes allowances, and user-defined policies, such as affinity, data localization, and other custom restraints. The kube-scheduler utility may significantly affect performance, availability, and capacity.

Networking components

These components run on the Kubernetes nodes.

• The Calico SDN solution provides pure L3 networking to a Kubernetes cluster. Calico runs as a containerd container calico-node.
• The Container Network Interface (CNI) plugin for the Calico SDN establishes a standard for the network interface configuration in Linux containers.

Mandatory addons

These components are mandatory for an MCP Kubernetes cluster.

• The coredns process manages the DNS requests for the Kubernetes Nodes as well as monitors the Kubernetes Master nodes for changes in Services and Endpoints. It runs runs on the Kubernetes Master nodes as a pod controlled by Kubernetes.

Optional components

You may need to install these components if your environment has specific requirements:

• The cni-genie addon allows container orchestrators to use multiple CNI plugins in runtime.
• The Kubernetes dashboard allows using a web UI to manage applications that run on a Kubernetes cluster as well as troubleshoot them through the web UI.
• The external-dns manages DNS records dynamically through the Kubernetes resources in a DNS provider-agnostic way, as well as makes these resources discoverable through public DNS servers.
• The helm addon is a tool for managing Kubernetes charts.
• The ingress-nginx controller provides load balancing, SSL termination, and name-based virtual hosting. The NGINX Ingress controller requires MetalLB to be enabled on a cluster.
• The metallb service for Calico provides external IP addresses to the workloads services, for example, NGINX, from the pool of addresses defined in the MetalLB configuration.
• The sriov-cni CNI plugin allows the Kubernetes pods to attach to an SR-IOV virtual function.