Core Components of the Kubernetes Architecture

This is a basic overview of the main components that build a Kubernetes cluster.

Kubernetes Cluster Main Components

#

Control Plane

#

• Manages the Kubernetes cluster and the workloads running on them.

• Includes the Kube-API-Server, Etcd, Kube-Scheduler, and Kube-Controller-Manager.

Controller Node / Control Plane Node

#

• Physical or virtual machine that runs the components of the control plane.

• In an high-availability setup multiple controller nodes are running copies of the control plane components (like kube-apiserver, etcd, etc.)

Worker Node

#

• Runs containerized workloads.

• Each node is managed by the Kubelet, an agent that receives commands from the control plane.

Control Plane Main Components

#

Kube-APIserver

#

• The API server is the brain of Kubernetes.

• Provides an API that serves as the front end of a Kubernetes control plane.

• All components, users, and external systems talk to it, when they need to interact with Kubernetes (like creating or deleting pods).

• For example a command via Kubectl goes to the API server: The API server processes it, validates it, and updates the cluster’s state via etcd.

Etcd

#

• Etcd is a distributed key-value store that contains the cluster’s configuration and state.

• Etcd stores all the critical data about the Kubernetes cluster, like cluster nodes, pods, roles, policies & secrets.

• Etcd stores data as key-value pairs. Each piece of information (like a pod or a service) is represented as a key with associated data / the value.

Kube-Scheduler

#

• Decides where new pods should run in the cluster.

• When a new pod is created, it is assigned to a node, based on available resources, policies, and constraints.

Kube-Controller-Manager

#

• Manages the controllers, which are the processes that monitor the state of the cluster and make sure it matches the desired state.

• For example, the replication controller ensures the right number of pod replicas are running. If one pod fails, it creates a new one.

Worker Node Main Components

#

Note: Depending on the Kubernetes cluster, the following components are also used on the controller nodes.

Container Runtime

#

• Engine that runs the containers. It pulls the container image and runs it inside an isolated environment.

• Container Runtime Interface (CRI): Kubernetes uses the CRI to communicate with any compatible container runtime.

Different Container Runtimes:

• Docker: The most well-known container runtime, also used with the Docker Platform. In the early days of Kubernetes, Docker was the default runtime, but Kubernetes has moved toward a more general solution for container runtimes.

• Containerd: A lightweight runtime originally developed as part of Docker but now a standalone project. It’s highly compatible with Kubernetes and is often used as a replacement for Docker because of its simplicity and performance.

• CRI-O: A runtime specifically designed for Kubernetes. It implements the Kubernetes Container Runtime Interface (CRI), making it tightly integrated and optimized for Kubernetes.

• gVisor: A sandboxed runtime designed for better security, it isolates containers with more protection at the cost of some performance.

Kubelet

#

• Its job is to make sure containers are running properly.

How it works:

• It gets it’s instructions from the Kubernetes control plane, like where to run a Pod, it interacts with the container runtime to launch and manage those containers.

• It constantly monitors the health of the containers and reports back to the control plane.

Kube-Proxy

#

• Responsible for networking at the Service level

• Routing traffic to the right pod when a service is accessed.

Container Networking Interface Plugins (CNI)

#

• Responsible for networking at the Pod level

• Assignes IP addresses to pods and enabling pods to communicate with each other across nodes.

CNI plugins used in Kubernetes

Cilium:

• Performs packet filtering, forwarding and load balancing at the kernel level, without needing traditional IP routing or iptables for networking.

• High performance & primary designed for Kubernetes clusters.

Calico:

• Uses traditional Linux networking based on IP Routing and iptables for managing container traffic and enforcing network policies.

Note: This are the only ones I have used so far.

Other Kubernetes Components

#

Kubectl

#

• CLI tool for interacting with the Kubernetes cluster by sending commands to the Kube-Apiserver.

Kubeadm

#

• Kubeadm is a tool that simplifies the process of setting up a Kubernetes cluster.

Cloud-Controller-Manager

#

• Used for cloud-based, managed Kubernetes clusters on

• Interacts with cloud provider (AWS, Azure, GCP,…) to create load balancers, attaching storage and ensuring node health through cloud APIs.

Application Deployment Components

#

Pods

#

• A Pod is the smallest unit in Kubernetes.

• It wraps one or more containers that share the same network namespace (can communicate via localhost) and storage.

• Each pod is assigned with its own unique IP, these IPs are not static.

• Pods can mount PersistentVolumes to retain data.

Init-Containers

#

• Are specialized containers that run before the application containers in a pod.

• A Pod can have multiple containers running apps within it, but it can also have one or more init containers, which are run before the app containers are started.

• Init containers always run to completion.

• Each init container must complete successfully before the next one starts.

• The main container does not start until all the init containers have successfully completed.

• If a pods init container fails, the kubelet repeatedly restarts that init container until it succeeds. Unless the pods restartPolicy is Never and an init container fails during startup of that pod, Kubernetes treats the overall Pod as failed.

• Init containers can securely run utilities or custom code that would otherwise make an application container image less secure.

Example Usecases:

• Create a database schema.

• Establishing network connections to external services.

• Clone Git repositories or write files into attached pod volumes.

• Retrieving secrets from a vault

• Creating directories, applying permissions, or running custom scripts to set up the environment for the main application.

• Wait for a service to start before the main application starts.

Sidecar-Containers

#

• A sidecar container is a secondary container that runs alongside the main application container in the same Pod.

• A common usecase is to collect logs from the main container and forward them to a central logging system, or to fetch secrets from an external store.

Probes

#

Liveness Probe:

• Checks whether the application / container is running properly. If it fails, the container is restarted.

Readiness Probe:

• Checks whether the application / container is ready to serve requests. If it fails, traffic is stopped until it’s ready.

Startup Probes:

• Checks whether the application / container has started properly and is ready to handle requests.

• Unlike liveness & readiness probes ( which run continuously), startup probes only run once during the container startup phase.

• Useful for containers with long startup time on their first initialization. Prevents the container from beeing killed before they are ready.

Jobs

#

• A Job creates pods that run short-term, one-off tasks that should run once, until completion, or a limited number of times.

• When the task is done, the Job finishes.

• Jobs are used to process data, run a script, or clean up temporary files.

Non-Parallel Jobs:

• Are designed to run a single task to completion.

• Are used for tasks that can’t be divided among multiple pods.

• For example a script that needs to be run once a day.

Parallel Jobs with a Fixed Completion Count:

• Used to divide the a among several pods, each processing a portion of the data.

• The workload can be spread across multiple nodes.

• The job is considered complete when a specified number of Pods successfully complete their tasks.

CronJobs:

• A CronJob allows to define a job that will run automatically at specified times or intervals.

Deployments & ReplicaSets

#

• Used to manage stateless applications by defining how Pods should be created, updated, and scaled.

• Deployments create and manage ReplicaSets, which in turn manage Pods

• Self-Healing: If a Pod crashes, the ReplicaSet ensures a new one is started. The placement of those pods across nodes is handled by Kubernetes.

• Declarative Pod Management: Define how many replicas of a pod should run

• Rolling Updates: Deployment of new versions without downtime

DaemonSets

#

• Ensures that a copy of a pod runs on every Kubernetes node.

• New Kubernetes nodes that join the cluster will automatically start pods that are part of a DaemonSet.

• DaemonSets are designed to run a Pod on every Node, also in situations that would normally be prevented. DaemonSet pods will still be scheduled even if a target Node is facing resource constraints or isn’t accepting new Pods.

• DaemonSets are often used for node monitoring and log collection agents.

StatefulSets

#

• Manages pods that need unique, persistent storage across rescheduling.

• Used for stateful applications where each pod needs to maintain its own data, e.g databases.

• Each pod has a unique, stable identity, e.g. “pod-0”, “pod-1” and “pod-2” and keeps its identity even if rescheduled. If “pod-1” fails, it will be recreated with the same name, preserving its state.

• StatefulSets ensure that Pods are created and deleted in a ordered manner.

Access Components

#

Overview

#

• Kubernetes Services are used that map network traffic to the Pods inside the cluster

• Network traffic flows into the Service before being redirected to one of the available Pods

ClusterIP Service

#

• ClusterIP is the default service type that’s used when not otherwise specified

• Kubernetes assigns a stable virtual IP ClusterIP to the service, the service name is automatically resolvable via Kubernetes DNS.

• Service DNS names a structured as follows:
  <service-name>.<namespace-name>.svc.cluster-domain
  for example:
  example-service.default.svc.cluster.local

• Pods in the same cluster can reach the service via its ClusterIP or DNS name

• The service selects Pods based on selectors and labels

• It cannot be accessed from outside the cluster

• Used for inter-service communication within the cluster, for example, communication between the front-end and back-end components.

NodePort Service

#

• NodePort exposes the service on each worker nodes IP at a static port, the NodePort: <NodeIP>:<NodePort>

• The port must be in the range of 30000–32767. If the port is undefined, Kubernetes will automatically assign one.

• A ClusterIP service, to which the NodePort service routes, is automatically created.

LoadBalancer Service

#

• NodePort and ClusterIP services to which the LoadBalancer routes, are automatically created.

• Provides external access to applications by provisioning a cloud provider’s LoadBalancer, or for example MetalLB in on-premise environments.

• Every cloud-based LoadBalancer service creates a separate cloud LoadBalancer, which increases cost.

• It does not handle routing based on URLs or domains.

Headless Service (for Stateful Applications)

#

• Does not assign a ClusterIP and allows direct access to individual pod instances.

• Used with StatefulSets (stateful applications like clustered databases), where each pod needs a unique network identity and persistent storage.

• Each pod gets its own stable DNS name, for example pod-0.my-service.default.svc.cluster.local

ExternalName Service / Service for External Endpoint

#

• Maps a service name to an external DNS name instead of routing traffic to internal pods.

• Used for external resources like databases or APIs.

Ingress

#

• Ingress is an API object that manages external access to services within a cluster.

• Uses a single cloud LoadBalancer for multiple services by routing traffic based on hostnames or paths.

• Can route traffic based on URL paths (example.com/endpoint1, example.com/endpoint2) or hostnames (endpoint1.example.com, endpoint2.example.com).