Containers & Kubernetes

Kubernetes Overview

---

Kubernetes architecture

Kubernetes is an open-source container orchestration platform that automates deployment, scaling, and management of containerized applications. Over time, it has become the de facto standard for container orchestration in large-scale production environments.

See the article Borg, Omega, and Kubernetes for a historical perspective on Kubernetes and its predecessors.

A Kubernetes setup consists of a cluster of machines (nodes) that run containerized applications. Kubernetes separates the management of the cluster into two main components: a control plane and a set of worker nodes. The control plane is responsible for managing the cluster, making global decisions (such as scheduling workloads), and maintaining the desired state. The worker nodes are the machines (virtual or physical) that run the containerized applications.

Every Kubernetes cluster has at least one worker node.

In Kubernetes terminology, a pod is the smallest deployable unit that can be created, scheduled, and managed. A Pod can contain one or more containers, which share resources and are scheduled together on the same node. Pods are the building blocks of Kubernetes applications, and they encapsulate an application’s container (or multiple containers) and storage resources.

Control plane

The control plane has a set of components that together maintain the desired state of the cluster: the API server, etcd, the scheduler, and the controller manager

The API Server exposes the Kubernetes API and serves as the front-end for management operations. Data is stored in etcd, which is a key-value store. The Scheduler watches for new pods that do not yet have a node assignment and selects a suitable node for them to run on. The Controller Manager ensures that the cluster’s actual state matches the desired state — if not, it takes corrective action such as restarting a failed pod.

In cloud environments, an optional Cloud Controller Manager integrates with the cloud provider’s APIs for managing load balancers, nodes, etc. Typically, in production, control plane components are run on multiple nodes for high availability, but in a local or test setup, they might all run on a single machine (as in a single-node cluster).

The high-level functionality of Kubernetes control plane is shown in Figure 1 below.

Figure 1 — High-level functionality of Kubernetes Control Plane.

Worker node

Worker nodes are the concrete machines that run the applications. The machines can either be virtualized (e.g., in a cloud environment) or physical (e.g. on-premises servers). Each worker node has a set of components that maintain and run application Pods. The main components are Kubelet, container runtime, and kube-proxy.

• Kubelet is a service that runs on each node and ensures that the containers in pods are running. It communicates with the control plane through the API server to receive instructions, and reports back the status of running Pods.

• Container runtime is the software that runs containers. Kubernetes supports multiple container runtimes, such as Docker, containerd, and CRI-O. The runtime pulls images from a container registry, runs the containers, and manages their lifecycle. Kubelet interacts with the container runtime to start, stop, and monitor containers through a container runtime interface.

• Kube-proxy is a network service that maintains network rules on nodes. It enables communication across Pods and services in the cluster. In addition, it provides services such as load balancing and network proxying, and communicates with the API server and the host network to manage network rules.

In addition, each node has a container runtime (e.g. containerd) that pulls container images and runs containers.

The high-level overview of a worker node is shown in Figure 2 below.

Figure 2 — High-level overview of a worker node.

Loading Exercise...

Kubernetes container management concepts

Kubernetes introduces abstractions to manage containers at scale, which are Pods, ReplicaSets, and Deployments. These build on each other to provide layered control over how containers are grouped, replicated, and updated. The relationship of the three is briefly summarized in Figure 3 below.

Figure 3 — Relationship of Deployments, ReplicaSets, and Pods.

Pods

A Pod is the smallest deployable and manageable unit in Kubernetes. A Pod encapsulates one or more application containers with shared resources — networking and volumes — for those containers.

Pods are considered the atomic unit of scheduling in Kubernetes, which means that when you want to run an application, you create a Pod to run it. Pods are also ephemeral, meaning they can be created, destroyed, and replaced at any time. There can be also multiple replicas of a Pod running at the same time.

When deploying containers, the common pattern is to have one application container per Pod. However, it is possible to run multiple containers in a Pod when they are tightly coupled and need to share resources. For example, one container might fetch data and write it to a shared volume for another container to process.

ReplicaSets

A ReplicaSet is a Kubernetes object that ensures a specified number of Pod replicas are running at any given time. The primary purpose of a ReplicaSet is to provide replication and self-healing: if a Pod managed by the ReplicaSet is deleted or crashes, the ReplicaSet will automatically create a new Pod to replace it, maintaining the desired number of replicas. Similarly, if there are more Pods than desired, the ReplicaSet will terminate the excess Pods.

In Kubernetes, ReplicaSets are managed by Deployments.

Deployments

A Deployment is a higher-level concept that manages ReplicaSets (and by extension, Pods) and provides declarative updates to applications. With a Deployment, you declare the desired state of your application, e.g. “I want 5 replicas of my server”, and the Deployment’s controller will work to make the reality match the desired state.

Each deployment’s controller is managed by the controller manager in the Kubernetes Control Plane.

When you create a Deployment, it will automatically create a ReplicaSet (or adopt an existing one) to achieve its goals. If you update the Deployment (for example, to use a new container image version or change the number of replicas), the Deployment will launch a new ReplicaSet or modify the existing one to transition from the current state to the new desired state in a controlled way (e.g., rolling update, so that not all Pods are destroyed at once).

Deployments can also keep track of revision history, allowing rollbacks to previous versions if needed.

Deployment is the main object you’ll use to manage long-running applications.

Loading Exercise...