📦 Kubernetes Pods 📦

A Kubernetes Pod is the smallest and simplest deployable unit of computing that you can create and manage in Kubernetes. It represents a single instance of a running process in a cluster. A pod can contain one or more containers. Containers within the same pod share the same network namespace, which means they can communicate with each other using localhost. They can also share the same storage volumes, allowing them to share data. Pod is basically a wrapper that Kubernetes has created for a container.

A pod that contains one container refers to a single container pod and it is the most common Kubernetes use case. A pod that contains Multiple co-related containers refers to a multi-container pod.

Few patterns for multi container pod are,

☑ Sidecar container — Sidecar containers are containers that are needed to run alongside the main container. Sidecar containers allows you to enhance and extend the functionalities of the main container without having to modify its main container. They are often used for tasks like logging, monitoring, or handling data synchronization for the primary application.

☑ Adapter container — They can be used to adapt the main container to different environments, like translating logs to a specific format or handling security or authentication.

☑ Init container — Init containers run before the application containers start. Init containers always run to completion. Each init container must complete successfully before the next one starts.

🔔 Creation of Pod

PodSpec is a crucial part of the configuration for creating and defining pods. It is a section within a Kubernetes configuration file that provides detailed specifications for how a pod should be created and how its containers should be configured. Pod Templates are specifications for creating Pods, and are included in workload resources such as Deployments, Jobs and DaemonSets.

🔔 Pod networking

Each pod is assigned a unique IP address within the cluster, which can be used for communication between pods in the same or different nodes of the cluster.

🔔 Labels and Annotations

Pods can be labeled and annotated with metadata that can be used for grouping, selecting and managing them. Labels are used for querying pods and creating services, while annotations provide additional information about the pod.

🔔 Restart policy

This is an additional configuration. The default restart policy is ‘Always’.

Always: Always restart the Pod when it terminates.
OnFailure: Restart the Pod only when it terminates with failure.
Never: Never restart the Pod after it terminates.

🔔 Pod Phase

☑ Pending — Waiting for resources

The Pod has been accepted by the Kubernetes cluster, but one or more of the containers has not been set up and made ready to run. This includes time a Pod spends waiting to be scheduled as well as the time spent downloading container images over the network.

☑ Running — Containers are running

The Pod has been bound to a node, and all of the containers have been created. At least one container is still running, or is in the process of starting or restarting.

☑ Succeeded or Failed — Containers have completed their tasks

Succeeded — All containers in the Pod have terminated in success, and will not be restarted.

Failed — All containers in the Pod have terminated, and at least one container has terminated in failure. That is, the container either exited with non-zero status or was terminated by the system.

☑ Unknown — Internal problem happening

For some reason the state of the Pod could not be obtained. This phase typically occurs due to an error in communicating with the node where the Pod should be running.