DAY 4 : Pods

DAY 4 : Pods

Pods are the smallest deployable units of computing that you can create and manage in Kubernetes. A Pod is a group of one or more containers, with shared storage and network resources, and a specification for how to run the containers. A Pod's contents are always co-located and co-scheduled, and run in a shared context.

The purpose of a Pod is to provide a cohesive and isolated environment for containers to run and share resources, including storage, network, and inter-process communication.

Why Are Pods Useful?

Pods have revolutionized how containers are managed in production. A single pod can be configured to manage multiple containers in real-time. Kubernetes pods provide a conducive environment for these containers to operate in.

Pods in Kubernetes have networks such as localhost that simplify communication among containers. The networks enable containers to share resources such as each container’s data, volumes, and status. Additionally, pods have IP addresses that allow them to communicate and share resources with other pods.

They also facilitate application scalability. Depending on the demand and supply status, the controller can configure pods to create replica pods or shut down unused ones automatically.

Types of Pods

  1. Single containers: One Kubernetes pod can run a single container. In this case, the container represents an entire application, including all dependencies and resources needed to run the application. Pods with single containers are simple and easy to run.

  2. Multiple containers: Equally, a pod in Kubernetes can run multiple containers on one server. Such cases occur when an application’s programs depend on one another and need to share resources such as files, volume, or data. Kubernetes pods enable this co-dependency by forming an abstraction layer over the containers where they can easily share resources in a controlled environment.

Pod Lifecycle :

  1. Pending: Indicates that the pod has been successfully created in the cluster, but one or more of its containers is not running.

  2. Running: Indicates a pod has been embedded to a node with all its containers created, running, or restarting.

  3. Succeeded: Indicates all pod containers have been terminated successfully. Once terminated, the pods will not restart.

  4. Failed: Indicates one container in the pods failed to terminate or delete. All terminated pods issue a zero status. Anything else is regarded as a failure.

  5. Unknown: Indicates the controller cannot determine the Pod’s state.

Pod Networking

Kubernetes Networking Model

  • Pods in Kubernetes are assigned unique IP addresses within a cluster, enabling direct communication between them. By default, each pod is isolated and has its own IP address, which allows for secure communication and avoids port conflicts. These IP addresses are reachable only within the Kubernetes cluster network unless specific configurations are made for external access.

  • Each Pod creates its own network namespace. This includes a single IP address, a single range of TCP and UDP ports, and a single routing table.

  • If a Pod has a single container, that container has full access to the network namespace of the pod. But if it’s a multi-container pod, then all containers will share the network namespace.

  • Container-to-Container communication works via the Pod’s localhost adapter and port number.

  • Pod-to-Pod Communication within the Same Node:

    When multiple pods are scheduled on the same node, they can communicate with each other directly using localhost or the loopback interface. This communication happens through the pod’s assigned IP address within the cluster, typically in the form of a Virtual Ethernet (veth) pair. The communication occurs at the network layer, enabling high-performance and low-latency interactions between pods on the same node.

  • Pod-to-Pod Communication across Nodes:

    When pods need to communicate across different nodes in the cluster, Kubernetes employs various networking solutions, such as Container Network Interfaces (CNIs) and software-defined networking (SDN) technologies. These solutions create a virtual network overlay that spans the entire cluster, enabling pod-to-pod communication across nodes. These networking solutions ensure that the pod’s IP address remains reachable and provides transparent network connectivity regardless of the pod’s location within the cluster.