So what is a pod in Kubernetes?
- Transfer
Note trans. : This article continues the cycle of materials from a Google technical writer working on documentation for Kubernetes (Andrew Chen) and a software engineering director at SAP (Dominik Tornow). Their goal is to explain the basics of the organization Kubernetes in an accessible and visual way Last time we translated an article about high availability , but 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(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 brevity, this had to omit some of the other features Pod'ov such as liveness probes and readiness , the separation resources (including recently appeared namespace sharing - approx Trans.. ) , With a job network.
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 both 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 talking about a request, and for the second case, use the expression “container set”.
Pods are considered the basic building blocks of Kubernetes, because all the workloads in Kubernetes — for example, Deployments , ReplicaSets, and Jobs- can be expressed as pods.
A 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
Scheme 2. Pod'y, Scheduler (Scheduler) and Kubelet
In this illustration, the corresponding objects and components are highlighted. Pods are represented as Kubernetes Pod Objects , and they deal with them:
Scheme 3. Kubernetes objects
This illustration shows the Kubernetes objects responsible for working with the pod:
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 status.
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 a Kubernetes cluster.
Scheme 4. Processing a
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:
Scheme 5. The control cycle of the Kubernetes scheduler
The task of the scheduler (Scheduler) in Kubernetes is to schedule the pod, that is, to assign it a suitable node in the Kubernetes cluster for the subsequent launch.
Pod'a binding object with the object node
Pod is assigned to the node (or associated with) if and only if there is an object binding (a binding) , which:
(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.)
Scheme 6. Kubelet control loop The Kubelet
task is to launch a pod, which in essence means starting 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 during 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 the pod
During the main phase, Kubelet simultaneously launches containers in accordance with the specifications of the pod
Scheme 7.2. Run pod, details of this process
In the event of a container crash, 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 is one of the following values:
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 (that is, it will trigger the launch of a new container with the same specification) when it completes its work only if the following conditions are met:
Restart policy for the main container The main container will be restarted (that is, it will trigger the launch of a new container with the same specification) when you finish your work only when the following conditions are met:
Scheme 8. An example of a timeline with a red dot, symbolizing the failure of a container.
The illustration shows a possible timeline for launching a pod with two specifications of init-containers and two specifications of main containers. 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 .
Scheme 9. Kubelet interaction with the object and executable pod'a medium container (container runtime)
Kubelet receives specification pod'a
Kubelet collapses
The pod phase is a projection of the state of containers from a set of containers, it depends on:
Scheme 10. Phases of pod
The Pending
Pod phase is in the standby phase if and only if:
The Running
Pod phase is in a work phase if and only if:
The Success
Pod is in a success phase if and only if:
The Failure
Pod Phase is in a phase of failure if and only if:
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.
Scheme 11. The garbage collector control cycle for pods (Pod Garbage Collector)
After the pod has been planned and launched, a special controller in Kubernetes - Pod Garbage Collector Controller - is responsible for removing pod objects from the Kubernetes Object Store object storage .
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.
Read also in our blog:
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(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 brevity, this had to omit some of the other features Pod'ov such as liveness probes and readiness , the separation resources (including recently appeared namespace sharing - approx Trans.. ) , With a job 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 both 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 talking about a request, and for the second case, use the expression “container set”.
Pods are considered the basic building blocks of Kubernetes, because all the workloads in Kubernetes — for example, Deployments , ReplicaSets, and Jobs- can be expressed as pods.
A 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. Pod'y, Scheduler (Scheduler) and Kubelet
In this illustration, the corresponding objects and components are highlighted. Pods are represented as Kubernetes Pod Objects , and they deal with them:
- scheduler (Scheduler) ,
- Kubelet.
Kubernetes Objects
Scheme 3. Kubernetes objects
This illustration shows the Kubernetes objects responsible for working with the pod:
- pod object itself (Pod Object) ;
- binding sites (Binding Object) ;
- object node (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 status.
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 a Kubernetes cluster.
Pod processing
Scheme 4. Processing a
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 of the Kubernetes scheduler
The task of the scheduler (Scheduler) in Kubernetes is to schedule the pod, that is, to assign it a suitable node in the Kubernetes cluster for the subsequent launch.
Pod'a binding object with the object node
Pod is assigned to the node (or associated with) if and only if there is an object binding (a binding) , which:
- namespace equals pod namespace,
- the name equals the name of the pod,
- type of target is equal to
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 loop The Kubelet
task is to launch a pod, which in essence means starting 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 during 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 the pod
.Spec.InitContainersand 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 the pod
.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 crash, 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 is 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 (that is, it will trigger the launch of a new container with the same specification) when it completes its work only if the following conditions are met:
- container exit code reports an error and
- pod's restart policy matters
AlwaysorOnFailure.
Restart policy for the main container The main container will be restarted (that is, it will trigger the launch of a new container with the same specification) when you finish your work only when the following conditions are met:
- restart policy is defined as
Alwaysor - The restart policy is defined as the
OnFailureexit code of the container reports an error.
Scheme 8. An example of a timeline with a red dot, symbolizing the failure of a container.
The illustration shows a possible timeline for launching a pod with two specifications of init-containers and two specifications of main containers. 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
Scheme 9. Kubelet interaction with the object and executable pod'a medium container (container runtime)
Kubelet receives specification pod'a
.Spec.InitContainersand .Spec.Containerstriggers said set of containers and appropriately updates the values pod'a .Status.InitContainerStatusesand .Status.ContainerStatuses. Kubelet collapses
.Status.InitContainerStatusesand .Status.ContainerStatusespod'a in 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
The Pending
Pod phase is in the standby phase if and only if:
- none of the pod's init containers are in
Terminatedan error state (Failure); - All pod's main containers are in condition
Waiting.
Running (Running)
The Running
Pod phase is in a work phase if and only if:
- All pod's init containers are in a
Terminatedsuccessful state (Success); - at least one main pod container is in a state
Running; - none of the pod's main containers are in
Terminatedan error state (Failure).
Success
The Success
Pod is in a success phase if and only if:
- All pod's init containers are in a
Terminatedsuccessful state (Success); - all pod's main containers are in a state
Terminatedwith success (Success).
Failure
The Failure
Pod Phase is in a phase of failure if and only if:
- all pod's containers are in condition
Terminated; - at least one of the pod's containers is in
Terminatedan error state (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
Scheme 11. The garbage collector control cycle for pods (Pod Garbage Collector)
After the pod has been planned and launched, a special controller in Kubernetes - Pod Garbage Collector Controller - is responsible for removing pod objects from the Kubernetes Object Store object storage .
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.
PS from translator
Read also in our blog:
- “ Kubernetes: a poda life ”;
- " How to ensure high availability in Kubernetes ";
- “ How does the Kubernetes scheduler actually work? ";
- “What happens in Kubernetes when starting the kubectl run?” Part 1 and Part 2 ;
- " Our experience with Kubernetes in small projects " (video of the report, which includes an introduction to the technical device Kubernetes) .