Pods are the smallest deployable computing units that Kubernetes allows you to create and manage. A Pod is a collection of one or more containers with shared storage and network resources, as well as instructions on how to run the containers. The contents of a Pod are always co-located, co-scheduled, and run in a shared context.
Below is an example of POD which consists of a container running the nginx image.
Usually we don't need to create Pods directly. Instead, we can use workload resources like Deployment or Job to create them. Consider the StatefulSet resource if your Pods require state tracking.
PODs are used in two different ways:
1. PODs that run a single container -
The most common Kubernetes use case is the "one-container-per-Pod" model; in this case, a Pod can be thought of as a wrapper around a single container; Kubernetes manages Pods rather than containers directly.
2. PODs that run multiple containers that need to work together -
A Pod can encapsulate an application made up of multiple tightly coupled containers that need to share resources. These co-located containers form a single cohesive unit of service—for example, one container serving public data from a shared volume while a separate sidecar container refreshes or updates those files. The Pod wraps these containers, storage resources, and an ephemeral network identity in a single package.
Each Pod is designed to run a single instance of a particular application. If you want to horizontally scale your application (provide more overall resources by running more instances), use multiple Pods, one for each instance. In Kubernetes, this is typically referred to as replication. Replicated Pods are usually created and managed as a group by a workload resource and its controller.
Pods are intended to support multiple cooperating processes (as containers) that work together to form a unified unit of service. Containers in a Pod are automatically co-located and co-scheduled on the cluster's same physical or virtual machine. Containers can share resources and dependencies, communicate, and coordinate when and how they are terminated.
Pods natively provide two kinds of shared resources for their constituent containers: networking and storage.
How do pods communicate with each other?
When a pod is created, it is given its own distinct IP address. If the pod contains multiple containers, they can communicate with one another simply by using localhost. Extending communication outside the pod is accomplished by exposing a port.
The fact that Kubernetes assigns a cluster-private IP address to every pid in a cluster eliminates the need to either explicitly create links between pods or map container ports to host ports. As a result, without the use of NAT, every pod in a cluster can 'see' each other.
POD Lifecycle -
Pods have a defined lifecycle that begins with the Pending phase, progresses to the Running phase if at least one of its primary containers starts normally, and then to the Succeeded or Failed phases depending on whether any container in the Pod terminated in failure.
Pods are created, offered a unique ID (UID), and assigned to nodes, where they will remain until they are terminated (according to the restart policy) or deleted. If a Node goes down, the Pods assigned to that Node are deleted after a timeout period. Pods do not self-heal on their own. A given Pod is never "rescheduled" to a different node; rather, that Pod can be replaced by a new, nearly-identical Pod, even with the same name if desired, but with a different UID.
POD phases -
1. Pending
This is the first stage of the pod's lifecycle. The pod has been accepted at this point, and the scheduler is looking for a suitable node to run this container on. This includes both the time a Pod waits to be scheduled and the time spent downloading container images over the network.
2. Running
The Pod has been associated with a node, and all containers have been created. At least one container is still active or is in the process of being started or restarted.
3. Succeeded
All containers in the Pod successfully terminated and will not be restarted by Kubernetes cluster.
4. Failed
All containers in the Pod have terminated, and at least one of them has failed. That is, either the container exited with a non-zero status or the system terminated it.
5. Unknown
The state of the Pod could not be obtained for some reason. This phase is usually caused by a communication failure with the node where the Pod should be running.
I hope this was helpful.
Thank you for reading!
*** Explore | Share | Grow ***
Comments