What are Kubernetes pods?

A Kubernetes pod can contain one or more containers that are closely connected and share resources. In this way, they serve as a coordinated environment for applications.

The definition of Kubernetes pods

Pods are the basic deployment units in Kubernetes that comprise one or more interconnected containers. A pod shares the same network space, storage and other resources and therefore represents a logical grouping of containers. The containers within a Kubernetes pod work closely together and can communicate with each other

One-container pod model

A one-container pod contains only a single container. This structure is often used when an application or microservice needs to run in an isolated environment without the need to share resources and network with other containers. This pod is the simplest form in Kubernetes and still offers the advantages of orchestration, scaling and management.

Pods with multiple containers

Pods that run multiple containers host more than one container within the same pod. These containers work together and share the same network space and resources. This is often used when containers are closely connected and perform a common task or function. For example, a main application container and a sidecar container for logging or monitoring could run in a Kubernetes pod. This allows for closer coordination and communication between the containers while still treating them as a single entity within the Kubernetes cluster.

How to create a Kubernetes pod

To create a Kubernetes pod, you need a YAML file that describes the pod specification. Here’s a simple example of an Nginx pod:

apiVersion: v1
kind: Pod
metadata:
    name: nginx-pod
spec:
    containers:
    - name: nginx-container
        image: nginx:latest

This YAML document defines a pod named nginx-pod that contains a single container named nginx-container. The container uses the latest Nginx image from the Docker Hub.

Enter the following command to create the pod:

kubectl apply -f nginx-pod.yaml

Applications of Kubernetes pods

The use of higher abstraction levels such as Deployments or StatefulSets is recommended to manage pods in a productive environment. These controllers take over the definition of the desired state of the application and ensure that it matches the actual state. Scaling, gradual updating and automatic recovery of the pods are implemented.

When a pod is created, either directly by the administrator or indirectly by a controller, the new pod is scheduled on a specific node in the cluster. The pod remains on that assigned node until one of the following occurs: it stops running, the associated pod object is manually deleted, a lack of resources or other problems require evacuation of the pod to another node, or the current node fails. In this case, the pod is restarted on another available node to guarantee continuous execution.

The name of a pod must be set as a valid DNS subdomain value. This is important in making the pod uniquely identifiable within the Kubernetes cluster. DNS labels should be shorter than 253 characters, may only contain alphanumeric characters and hyphens, and must begin and end with an alphanumeric character.

Pod OS

Kubernetes pods are typically configured to run on a Linux operating system. However, there are cases where you may want to run a pod on a Windows operating system, for example, if your application or a specific part of it requires Windows-specific features. You can change the operating system in the .spec.os.name field of the pod specification (YAML file).

Pod management

While it’s possible to create pods manually, it’s often not practical due to the growing complexity of applications and workloads. Kubernetes controllers provide an abstract layer based on a declarative configuration. There are different types of controllers:

• Kubernetes Deployment
• Kubernetes StatefulSet
• Kubernetes DaemonSet

Deployment controllers continuously monitor the status of the cluster. This enables automated actions such as scaling, updating and maintaining applications. ReplicaSets ensure that a constant number of identical pods are running. StatefulSet controllers are essential for data-intensive applications as they ensure stable network identities for pods.

Pod templates

A pod template is the part of the configuration of a controller that describes the desired properties of a Kubernetes pod. These include containers, the Docker image, environment variables, resource requirements and more. The controller uses the pod template to set up or update pods. For example, during a deployment, it creates new pods when scaling is required or updates existing pods during a rolling update.

apiVersion: batch/v1
kind: Job
metadata:
    name: new-job
spec:
    template:
        metadata:
            name: pod
        spec:
            containers:
            - name: container
                image: ubuntu:latest
                command: ["echo", "Hello from Kubernetes"]
    backoffLimit: 3

In this example, we configure a job with the name new-job. The pod template creates a single pod with a container that uses the Ubuntu image and executes the command echo "Hello from Kubernetes". The job will have a maximum of three retries if an error occurs due to the set backoffLimit.

How to update Kubernetes pods

In Kubernetes, there are various methods for updating resources, including the two frequently used methods of patch and replace.

The Patch method is used to make targeted and partial updates to a resource without replacing the entire resource definition. This is done by providing a patch that only contains the fields to be changed. This allows specific parts of a resource to be updated while leaving others unchanged. This method provides an efficient way to make minimal changes to a resource, especially when only certain fields need to be updated.

The Replace method, on the other hand, replaces all fields of the resource with the corresponding fields in the new definition. The replace method is used when a comprehensive update is required or fundamental structural changes are made to the resource.

Some metadata and fields in YAML definitions of Kubernetes resources are fixed. These include:

• apiVersion and kind: This metadata defines the type and version of the resource and isn’t usually changed.
• metadata.name and metadata.namespace: The name and namespace of a resource are usually unchangeable in order to ensure the unique identification of the resource.
• metadata.creationTimestamp: The creation date of a resource is unchangeable and indicates when the resource was created.

How to share resources

Pods can use volumes to share data between containers within the same pod. A volume is a file system or directory that is shared by one or more containers in the pod. Volumes are effective mechanisms for storing data that extends beyond the lifecycle of a single container.

Each Kubernetes pod has its own IP address, which is unique within the cluster network. This IP address enables direct communication between the pods. If multiple containers are running in a pod, they can communicate with each other via localhost and different ports. This simplifies the interaction between the different parts of an application in the same pod.

Privileged mode

When a container runs in privileged mode, it has elevated privileges and can access system resources that are not normally available in a standard isolated container. In Kubernetes, privileged mode is enabled by setting the securityContext.privileged option in the container specifications.

It’s important to note that the use of privileged mode is associated with significant security risks. Due to the extended privileges, a compromised container or a malicious application on the host system could cause serious security problems. Therefore, privileged mode should only be used when necessary and after you have carefully considered the potential security risks.

Static pods

Static pods in Kubernetes are pods that are not monitored or managed by the central control plane of the cluster. Unlike regular pods, which depend on Kubernetes controllers, static pods are initiated directly by a node. These pods are bound to a specific node and their definitions are placed on the node itself, usually in a directory such as /etc/kubernetes/manifests/. Kubelet on the node monitors and starts the static pod, automatically restarting it if the pod crashes.

Unlike regular pods, static pods are not controlled by the Kubernetes API and are invisible to the central control plane of the cluster. Static pods are a simple way to deploy applications or services on a node without a central Kubernetes cluster. However, they don’t have all the features of regular pods which are managed by the Kubernetes Controller Manager.

Container probes

Container probes are mechanisms in Kubernetes that monitor the status and health of a container.

To perform a diagnosis, the Kubelet can trigger various actions:

• ExecAction (executed using the container runtime environment): This action allows Kubelet to execute a command within the container. This is particularly useful for performing custom checks or tests within the container. Once the command has been called, the test is considered successful.
• TCPSocketAction (checked directly by the Kubelet): This action allows the Kubelet to check the accessibility of a specific TCP port within the container. If the specified port is open, the test is considered successful.
• HTTPGetAction (checked directly by the Kubelet): With this action, the Kubelet performs a HTTP GET request to a specific path and port within the container. This action is often used for HTTP endpoints to ensure that an application responds properly to requests. If the request triggers a 2xx status code, the probe is considered successful.