A Pod encapsulates one (or) more containers, shared storage (volumes), and configuration options about how to run the containers.

Here are some key points about Pods in Kubernetes:

Atomic Unit: A Pod represents a single instance of an application in Kubernetes. It's the basic building block for deploying and managing containers.

Single (or) Multiple Containers: A Pod can contain one (or) more containers that are tightly coupled and share certain resources such as networking and storage. These containers are scheduled onto the same node and can communicate with each other via localhost.

Shared Network and Storage: Containers within the same Pod share the same network namespace, including IP address and port space, and they can communicate with each other using localhost. They can also share storage volumes, allowing them to share data.

Lifecycle: Pods have a lifecycle that includes phases such as Pending, Running, Succeeded, Failed, (or) Unknown. Kubernetes manages the lifecycle of Pods, ensuring they are always in the desired state.

Immutable: Pods are immutable once created. If changes are needed, a new Pod is typically created with the updated configuration.

Labels and Selectors: Pods can be labeled with key-value pairs, and selectors are used to identify Pods based on these labels. This allows for grouping and organizing Pods, which is useful for tasks like service discovery and load balancing.

Controllers: While Pods can be created manually, they are typically managed by higher-level controllers like Deployments, StatefulSets (or) DaemonSets. These controllers ensure that a specified number of Pod replicas are running and manage rolling updates, scaling, and self-healing.

Resource Management: Pods can have resource requests and limits specified for CPU and memory usage, allowing Kubernetes to make scheduling decisions based on available resources.

Pod Lifecycle Management: Kubelet handles the lifecycle of pods, including starting, stopping, and restarting containers as necessary to maintain the desired state specified in the pod definition.

Pods in Kubernetes using YAML files. Using these YAML files, we can create objects that interact with the Kubernetes API (Pods, Namespace, Deployments, etc.). Under the hood, kubectl converts the information defined in our YAML file to JSON, which requests the Kubernetes API.

apiVersion: v1
kind: Pod
metadata:
  name: nginx-1
  labels:
    name: nginx-1
    env: production
spec:
  containers:
  - name: nginx
    image: nginx

To create Kubernetes objects using YAML, we need to set values for the following fields.

apiVersion - This defines the Kubernetes API version. We want to use this YAML file.

kind - This defines what kind of Kubernetes object we want to create.

metadata - This is data that helps us uniquely identify the object that we want to create. Here we can provide a name for our app, as well as apply labels to our object.

spec - This defines the state that we want or our object. The format that we use for spec. For our Pod file, we have provided information about the containers that we want to host on our Pod.

Deploy and interact with our Pods using kubectl

kubectl, (kube-control (or) as some people call it, kube-cuddle) is the Kubernetes command-line tool. It allows us to run commands against Kubernetes clusters.

Create a Pod using our YAML definition file like

kubectl apply -f mypod.yaml

List all of our Pods

kubectl get pods

Pods and Containers are only accessible within the Kubernetes Cluster. Expose a container port externally using kubectl

kubectl port-forward mypod 8080:80

Delete the pod

kubectl delete pod mypod

Pod to be destroyed and created. We can also delete the Deployment that manages the Pod.

kubectl delete deployment mydeployment

Ensure that our Pods in Kubernetes are healthy

Kubernetes relies on Probes to determine whether (or) not a Pod is healthy.

Liveness Probes
Readiness Probes
Startup Probe

Probe https://dev.to/ibrahimsi/probe-kubernetes-o67

Kubernetes manages the lifecycle of Pods, ensuring they are always in the desired state and below the lifecycle of a pod in Kubernetes.

✅ 𝗣𝗲𝗻𝗱𝗶𝗻𝗴 ➡ When a pod is created, it enters the Pending state. In this state, the Kubernetes scheduler assigns the pod to a suitable node in the cluster.

The scheduler considers factors like resource availability, node affinity, and pod anti-affinity when making this assignment.

✅ 𝗥𝘂𝗻𝗻𝗶𝗻𝗴 ➡ Once a pod is assigned to a node, it transitions to the Running state. In this state, the pod's containers are created and started, and they begin running on the assigned node.

However, the containers may still be initializing or starting up, so the pod may not be fully ready to serve traffic.

✅ 𝗦𝘂𝗰𝗰𝗲𝗲𝗱𝗲𝗱 ➡ If a pod completes its main task successfully and terminates, it enters the Succeeded state.

This typically happens for batch jobs or one-time tasks. Once in the Succeeded state, the pod remains in this state until it is explicitly deleted. The system can reclaim the resources occupied by the pod.

✅ 𝗙𝗮𝗶𝗹𝗲𝗱 ➡ If a pod encounters an error or its containers fail to start or run, it enters the Failed state.