So what is a pod in Kubernetes?

Note trans. : This article continues the cycle of materials from a technical writer from Google, working on documentation for Kubernetes (Andrew Chen), and director of software engineering at SAP (Dominik Tornow). Their goal is to explain the basics of the organization Kubernetes in an accessible and graphic manner. Last time we translated an article about high availability , and now we’ll talk about such a basic concept in Kubernetes as pod.

Kubernetes is a container orchestration engine designed to run containerized applications on multiple nodes, commonly referred to as a cluster. In these publications, we use a systems modeling approach to improve the understanding of Kubernetes and its underlying concepts. Readers are advised to already have a basic understanding of Kubernetes.
')
Pods are the basic building blocks of Kubernetes, but even experienced users of Kubernetes cannot always explain what it is.

This publication offers a concise mental model that sheds light on the defining characteristics of the Kubernetes pods. For the sake of this brevity, I had to omit some other features of Pods, such as liveness and readiness probes , the sharing of resources (including the recently appeared namespace sharing ) , and work with the network.

Definition

A pod is a request to launch one or more containers on a single node.

A pod is determined by the presentation of a launch request (execute) of one or more containers on a single node, and these containers share access to resources such as storage volumes and the network stack.

However, in everyday life, the term "pod" can be used in the sense of this request , and in the sense of a set of containers that are launched in response to a request. Therefore, in the publication we will use the word “pod” when we are talking about a request, and for the second case, we use the expression “container set”.

Pods are considered to be the basic building blocks of Kubernetes, because all the workloads in Kubernetes — for example, Deployments , ReplicaSets, and Jobs — can be expressed as pods.

The pod is the one and only object in Kubernetes that leads to the launch of containers. No pod - no container!

Scheme 1. Deployment, ReplicaSet, pod and containers

Kubernetes architecture

Scheme 2. Pods, Scheduler and Kubelet

This illustration highlights the relevant objects and components. Pods are represented as Kubernetes Pod Objects , and they deal with them:

Scheduler
Kubelet.

Kubernetes Objects

Scheme 3. Objects Kubernetes

This illustration shows the Kubernetes objects responsible for working with the pod:

pod object itself (Pod Object) ;
Binding Object ;
Node Object .

The Pod Object specifies the set of containers that will be launched, and the desired restart policy in the event of a crash, and also tracks the launch state.

Binding Object binds the Pod Object to the Node Object , i.e. assigns pod to the node for later launch.

The Node Object represents a node in the Kubernetes cluster.

Pod processing

Scheme 4. Processing pod

When a pod is created by a user or a controller like ReplicaSet Controller or Job Controller , Kubernetes processes the pod in two steps:

Scheduler plans pod,
Kubelet launches pod.

Pod planning

Scheme 5. The control cycle scheduler Kubernetes

The task scheduler (Scheduler) in Kubernetes is to schedule a pod, that is, assign it a suitable node in the Kubernetes cluster for later launch.

Associating a pod object with a node object

A pod is assigned to a node (or is associated with it) if and only if there is a binding object, which has:

namespace equals pod namespace,
the name equals the name of the pod,
target type equals Node ,
the name of the goal equals the name of the node.

(Adventure lovers can take a look at GitHub gist from Kelsey Hightower entitled " Creating and Scheduling a Pod Manually " - a step-by-step guide to creating a manual binding object.)

Run pod

Scheme 6. Kubelet control cycle

The task of Kubelet is to launch pod, which essentially means launching a set of pod containers. Launch pod Kubelet'om occurs in two phases: initialization and the main stage.

As a rule, a set of containers in the initialization phase performs preparatory work, such as preparing the necessary directory and file structure. A set of containers on the main phase already performs the "most important" tasks.

In everyday life, although this is not entirely correct, the term “pod” often implies a set of containers on the main phase or an even narrower meaning of the “most important” container of the main phase.

Scheme 7.1. Run pod, initialization phase (init) and main phase (main)

During initialization, Kubelet sequentially launches containers in accordance with the specifications of .Spec.InitContainers and in the order specified in the list. For a successful launch of the pod and taking into account the restart policy, its init containers must start and complete successfully.

During the main phase, Kubelet simultaneously launches containers in accordance with the specifications of .Spec.Containers . Here, for the successful launch of the pod and taking into account the restart policy, its main (main) containers must be running and either complete successfully or work indefinitely.

Scheme 7.2. Run pod, details of this process

In the event of a container failure, when the container stops working with a non-zero (0) return code (exit code) , Kubelet can restart the container in accordance with the restart policy of the pod. This policy has one of the following values: Always , OnFailure , Never .

The restart policy of pod has different semantics for init containers and main containers: if the launch of init containers is bound to end, then the main containers may not be completed.

Restart policy for the init container

The init-container will be restarted (i.e. will entail launching a new container with the same specification) at the completion of its work only if the following conditions are met:

The container exit code reports an error and
OnFailure restart policy is set to Always or OnFailure .

Restart policy for the main container

The main container will be restarted (i.e. will entail the launch of a new container with the same specification) at the completion of its work only if the following conditions are met:

restart policy is defined as Always or
The restart policy is defined as OnFailure and the exit code of the container reports an error.

Scheme 8. An example of a timeline with a red dot, symbolizing the failure of the container

The illustration shows a possible timeline for launching a pod with two init-container specifications and two main container specifications. It also shows the creation (in accordance with the restart policy) of a new container Main Container 1.2 after a problem with the launch of Main Container 1.1 .

Phase pod'a

Diagram 9. Kubelet interaction with the pod object and the container runtime

Kubelet acquires the specifications of .Spec.InitContainers and .Spec.Containers , runs the specified set of containers, and updates the values of .Status.InitContainerStatuses .Status.ContainerStatuses . .Status.InitContainerStatuses and .Status.ContainerStatuses .

Kubelet collapses .Status.InitContainerStatuses and .Status.ContainerStatuses into one value - .Status.Phase .

The pod phase is a projection of the state of containers from a set of containers, it depends on:

states and exit codes of init containers
states and exit codes of main containers.

Scheme 10. Phases of pod

Pending

Pending Phase

A pod is in the waiting phase if and only if:

none of the pod's init containers are in a terminated state with an error ( Failure );
All pod's main containers are in the Waiting state.

Running (Running)

Running phase

A pod is in a work phase if and only if:

all pod's init containers are in a Terminated state with success ( Success );
at least one pod's main container is in the Running state;
none of the pod's main containers are in a terminated state with an error ( Failure ).

Success

Success Phase

A pod is in a success phase if and only if:

all pod's init containers are in a Terminated state with success ( Success );
All pod's main containers are in a state of Terminated with success ( Success ).

Failure

Phase Failure

A pod is in a failure phase if and only if:

all pod containers are in Terminated condition;
at least one of the pod's containers is in the Terminated state with an error ( Failure ).

Unknown

In addition to the phases described above, pod may be in an unknown phase, which indicates that it is impossible to determine its current phase.

Garbage collection for pods

Diagram 11. Garbage collector control cycle for pods (Pod Garbage Collector)

After the pod has been scheduled and launched, a special controller in Kubernetes, the Pod Garbage Collector Controller, is responsible for deleting the pods from the Kubernetes Object Store .

Conclusion

A pod is the basic building block Kubernetes: pod is defined as the representation of a request to launch one or more containers on a single node. After the pod is created, Kubernetes processes it in two stages: first, the scheduler (Scheduler) plans the pod, and then Kubelet launches it. Throughout its life cycle, the pod goes through different phases, reporting the status — or, more precisely, the status of its container set — to the user and the system.