Kubernetes Components - Worker Node

• A worker node provides a running environment for client applications.

• These applications are microservices running as application containers.

• In Kubernetes, the application containers are encapsulated in Pods, controlled by the cluster control plane agents running on the control plane node.

• Pods are scheduled on worker nodes, where they find required compute, memory and storage resources to run, and networking to talk to each other and the outside world.

• A Pod is the smallest scheduling work unit in Kubernetes.

  • It is a logical collection of one or more containers scheduled together, and the collection can be started, stopped, or rescheduled as a single unit of work.

• Also, in a multi-worker Kubernetes cluster, the network traffic between client users and the containerized applications deployed in Pods is handled directly by the worker nodes, and is not routed through the control plane node.

Worker Node Components

• Following are worker node components

  • Container Runtime

  • Node Agent →kubelet

  • Proxy → kube-proxy

  • Add-ons for DNS, observability components such as dashboards, cluster-level monitoring and logging, and device plugins.

Worker Nodes in detail

Container Runtime (CRI)

• Although Kubernetes is described as a "container orchestration engine", it lacks the capability to directly handle and run containers.

• In order to manage a container's lifecycle, Kubernetes requires a container runtime on the node where a Pod and its containers are to be scheduled.

• A runtime is required on each nod of a Kubernetes cluster, both control plane and worker.

  • The recommendation is to run the Kubernetes control plane components as containers, hence the necessity of a runtime on the control plane nodes.

• Kubernetes supports several container runtimes:

  • CRI-O

  • containerd

  • Docker Engine

  • Mirantis Container Runtime (formerly Docker Enterprise Edition)

• As of now, CRI is not integrated.

Kubelet

• The kubelet is an agent running on each node, control plane and workers, and it communicates with the control plane.

• It receives Pod definitions, primarily from the API Server, and interacts with the container runtime on the node to run containers associated with the Pod.

• It also monitors the health and resources of Pods running containers.

• The kubelet connects to container runtimes through a plugin based interface - the Container Runtime Interface (CRI).

• The CRI consists of protocol buffers, gRPC API, libraries, and additional specifications and tools.

• In order to connect to interchangeable container runtimes, kubelet uses a CRI shim, an application which provides a clear abstraction layer between kubelet and the container runtime.

• The CRI implements two services: ImageService and RuntimeService.

  • The ImageService is responsible for all the image-related operations.

  • RuntimeService is responsible for all the Pod and container-related operations.

CRI shim

• Originally the kubelet agent supported only a couple of container runtimes, first the Docker Engine followed by rkt, through a unique interface model integrated directly in the kubelet source code.

• However, this approach was not intended to last forever even though it was especially beneficial for Docker.

• Kubernetes adopted a decoupled and flexible method to integrate with various container runtimes without the need to recompile its source code. Any container runtime that implements the CRI could be used by Kubernetes to manage containers.

• Shims are Container Runtime Interface (CRI) implementations, interfaces or adapters, specific to each container runtime supported by Kubernetes.

  • Below are some examples of CRI shims:

    • cri-containerd

    • cri-o (Open Container Initiative (OCI))

    • cri-dockerd

Kube-Proxy

• The kube-proxy is the network agent which runs on each node, control plane and workers, responsible for dynamic updates and maintenance of all networking rules on the node.

• It abstracts the details of Pods networking and forwards connection requests to the containers in the Pods.

• The kube-proxy is responsible for TCP, UDP, and SCTP stream forwarding or random forwarding across a set of Pod backends of an application, and it implements forwarding rules defined by users through Service API objects.

• The kube-proxy node agent operates in conjunction with the iptables of the node.

  • Iptables is a firewall utility created for the Linux OS that can be managed by users through a CLI utility of the same name.

  • The iptables utility is available for and pre-installed on many Linux distributions.

Add-ons

• Add-ons are cluster features and functionality not yet available in Kubernetes, therefore implemented through 3rd-party pods and services.

• Some of the add ons are given below,

  Add Ons	Description
  DNS	Cluster DNS is a DNS server required to assign DNS records to Kubernetes objects and resources.
  Dashboard	A general purpose web-based user interface for cluster management.
  Monitoring	Collects cluster-level container metrics and saves them to a central data store.
  Logging	Collects cluster-level container logs and saves them to a central log store for analysis.
  Device Plugins	For system hardware resources, such as GPU, FPGA, high-performance NIC, to be advertised by the node to application pods.

References

• CRI in kubernetes

• More Container Runtime