What are Ku­ber­netes pods?

A Ku­ber­netes pod can contain one or more con­tain­ers that are closely connected and share resources. In this way, they serve as a co­or­di­nat­ed en­vi­ron­ment for ap­pli­ca­tions.

The de­f­i­n­i­tion of Ku­ber­netes pods

Pods are the basic de­ploy­ment units in Ku­ber­netes that comprise one or more in­ter­con­nect­ed con­tain­ers. A pod shares the same network space, storage and other resources and therefore rep­re­sents a logical grouping of con­tain­ers. The con­tain­ers within a Ku­ber­netes pod work closely together and can com­mu­ni­cate with each other

One-container pod model

A one-container pod contains only a single container. This structure is often used when an ap­pli­ca­tion or mi­croser­vice needs to run in an isolated en­vi­ron­ment without the need to share resources and network with other con­tain­ers. This pod is the simplest form in Ku­ber­netes and still offers the ad­van­tages of or­ches­tra­tion, scaling and man­age­ment.

Pods with multiple con­tain­ers

Pods that run multiple con­tain­ers host more than one container within the same pod. These con­tain­ers work together and share the same network space and resources. This is often used when con­tain­ers are closely connected and perform a common task or function. For example, a main ap­pli­ca­tion container and a sidecar container for logging or mon­i­tor­ing could run in a Ku­ber­netes pod. This allows for closer co­or­di­na­tion and com­mu­ni­ca­tion between the con­tain­ers while still treating them as a single entity within the Ku­ber­netes cluster.

How to create a Ku­ber­netes pod

To create a Ku­ber­netes pod, you need a YAML file that describes the pod spec­i­fi­ca­tion. 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

Ap­pli­ca­tions of Ku­ber­netes pods

The use of higher ab­strac­tion levels such as De­ploy­ments or State­fulSets is rec­om­mend­ed to manage pods in a pro­duc­tive en­vi­ron­ment. These con­trollers take over the de­f­i­n­i­tion of the desired state of the ap­pli­ca­tion and ensure that it matches the actual state. Scaling, gradual updating and automatic recovery of the pods are im­ple­ment­ed.

When a pod is created, either directly by the ad­min­is­tra­tor or in­di­rect­ly by a con­troller, 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 as­so­ci­at­ed pod object is manually deleted, a lack of resources or other problems require evac­u­a­tion of the pod to another node, or the current node fails. In this case, the pod is restarted on another available node to guarantee con­tin­u­ous execution.

The name of a pod must be set as a valid DNS subdomain value. This is important in making the pod uniquely iden­ti­fi­able within the Ku­ber­netes cluster. DNS labels should be shorter than 253 char­ac­ters, may only contain al­phanu­mer­ic char­ac­ters and hyphens, and must begin and end with an al­phanu­mer­ic character.

Pod OS

Ku­ber­netes pods are typically con­fig­ured 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 ap­pli­ca­tion 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 spec­i­fi­ca­tion (YAML file).

Pod man­age­ment

While it’s possible to create pods manually, it’s often not practical due to the growing com­plex­i­ty of ap­pli­ca­tions and workloads. Ku­ber­netes con­trollers provide an abstract layer based on a de­clar­a­tive con­fig­u­ra­tion. There are different types of con­trollers:

• Ku­ber­netes De­ploy­ment
• Ku­ber­netes State­fulSet
• Ku­ber­netes DaemonSet

De­ploy­ment con­trollers con­tin­u­ous­ly monitor the status of the cluster. This enables automated actions such as scaling, updating and main­tain­ing ap­pli­ca­tions. Repli­caS­ets ensure that a constant number of identical pods are running. State­fulSet con­trollers are essential for data-intensive ap­pli­ca­tions as they ensure stable network iden­ti­ties for pods.

Pod templates

A pod template is the part of the con­fig­u­ra­tion of a con­troller that describes the desired prop­er­ties of a Ku­ber­netes pod. These include con­tain­ers, the Docker image, en­vi­ron­ment variables, resource re­quire­ments and more. The con­troller uses the pod template to set up or update pods. For example, during a de­ploy­ment, 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 Ku­ber­netes pods

In Ku­ber­netes, there are various methods for updating resources, including the two fre­quent­ly 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 de­f­i­n­i­tion. 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, es­pe­cial­ly when only certain fields need to be updated.

The Replace method, on the other hand, replaces all fields of the resource with the cor­re­spond­ing fields in the new de­f­i­n­i­tion. The replace method is used when a com­pre­hen­sive update is required or fun­da­men­tal struc­tur­al changes are made to the resource.

Some metadata and fields in YAML de­f­i­n­i­tions of Ku­ber­netes 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 un­change­able in order to ensure the unique iden­ti­fi­ca­tion of the resource.
• metadata.creationTimestamp: The creation date of a resource is un­change­able and indicates when the resource was created.

How to share resources

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

Each Ku­ber­netes pod has its own IP address, which is unique within the cluster network. This IP address enables direct com­mu­ni­ca­tion between the pods. If multiple con­tain­ers are running in a pod, they can com­mu­ni­cate with each other via localhost and different ports. This sim­pli­fies the in­ter­ac­tion between the different parts of an ap­pli­ca­tion in the same pod.

Priv­i­leged mode

When a container runs in priv­i­leged mode, it has elevated priv­i­leges and can access system resources that are not normally available in a standard isolated container. In Ku­ber­netes, priv­i­leged mode is enabled by setting the securityContext.privileged option in the container spec­i­fi­ca­tions.

It’s important to note that the use of priv­i­leged mode is as­so­ci­at­ed with sig­nif­i­cant security risks. Due to the extended priv­i­leges, a com­pro­mised container or a malicious ap­pli­ca­tion on the host system could cause serious security problems. Therefore, priv­i­leged mode should only be used when necessary and after you have carefully con­sid­ered the potential security risks.

Static pods

Static pods in Ku­ber­netes are pods that are not monitored or managed by the central control plane of the cluster. Unlike regular pods, which depend on Ku­ber­netes con­trollers, static pods are initiated directly by a node. These pods are bound to a specific node and their de­f­i­n­i­tions 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, au­to­mat­i­cal­ly restart­ing it if the pod crashes.

Unlike regular pods, static pods are not con­trolled by the Ku­ber­netes API and are invisible to the central control plane of the cluster. Static pods are a simple way to deploy ap­pli­ca­tions or services on a node without a central Ku­ber­netes cluster. However, they don’t have all the features of regular pods which are managed by the Ku­ber­netes Con­troller Manager.

Container probes

Container probes are mech­a­nisms in Ku­ber­netes that monitor the status and health of a container.

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

• Ex­e­cAc­tion (executed using the container runtime en­vi­ron­ment): This action allows Kubelet to execute a command within the container. This is par­tic­u­lar­ly useful for per­form­ing custom checks or tests within the container. Once the command has been called, the test is con­sid­ered suc­cess­ful.
• TCP­Sock­e­tAc­tion (checked directly by the Kubelet): This action allows the Kubelet to check the ac­ces­si­bil­i­ty of a specific TCP port within the container. If the specified port is open, the test is con­sid­ered suc­cess­ful.
• HTTPGe­tAc­tion (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 ap­pli­ca­tion responds properly to requests. If the request triggers a 2xx status code, the probe is con­sid­ered suc­cess­ful.