What are Kuber­netes pods?

A Kuber­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­ordin­ated en­vir­on­ment for ap­plic­a­tions.

The defin­i­tion of Kuber­netes pods

Pods are the basic de­ploy­ment units in Kuber­netes that comprise one or more in­ter­con­nec­ted con­tain­ers. A pod shares the same network space, storage and other resources and therefore rep­res­ents a logical grouping of con­tain­ers. The con­tain­ers within a Kuber­netes pod work closely together and can com­mu­nic­ate with each other

One-container pod model

A one-container pod contains only a single container. This structure is often used when an ap­plic­a­tion or mi­croservice needs to run in an isolated en­vir­on­ment without the need to share resources and network with other con­tain­ers. This pod is the simplest form in Kuber­netes and still offers the ad­vant­ages 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­plic­a­tion container and a sidecar container for logging or mon­it­or­ing could run in a Kuber­netes pod. This allows for closer co­ordin­a­tion and com­mu­nic­a­tion between the con­tain­ers while still treating them as a single entity within the Kuber­netes cluster.

How to create a Kuber­netes pod

To create a Kuber­netes pod, you need a YAML file that describes the pod spe­cific­a­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­plic­a­tions of Kuber­netes pods

The use of higher ab­strac­tion levels such as De­ploy­ments or State­ful­Sets is re­com­men­ded to manage pods in a pro­duct­ive en­vir­on­ment. These con­trol­lers take over the defin­i­tion of the desired state of the ap­plic­a­tion and ensure that it matches the actual state. Scaling, gradual updating and automatic recovery of the pods are im­ple­men­ted.

When a pod is created, either directly by the ad­min­is­trat­or or in­dir­ectly by a con­trol­ler, 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­ated pod object is manually deleted, a lack of resources or other problems require evac­u­ation 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­tinu­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 Kuber­netes cluster. DNS labels should be shorter than 253 char­ac­ters, may only contain al­pha­nu­mer­ic char­ac­ters and hyphens, and must begin and end with an al­pha­nu­mer­ic character.

Pod OS

Kuber­netes pods are typically con­figured 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­plic­a­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 spe­cific­a­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­ity of ap­plic­a­tions and workloads. Kuber­netes con­trol­lers provide an abstract layer based on a de­clar­at­ive con­fig­ur­a­tion. There are different types of con­trol­lers:

• Kuber­netes De­ploy­ment
• Kuber­netes State­ful­Set
• Kuber­netes DaemonSet

De­ploy­ment con­trol­lers con­tinu­ously monitor the status of the cluster. This enables automated actions such as scaling, updating and main­tain­ing ap­plic­a­tions. Rep­lica­Se­ts ensure that a constant number of identical pods are running. State­ful­Set con­trol­lers are essential for data-intensive ap­plic­a­tions as they ensure stable network iden­tit­ies for pods.

Pod templates

A pod template is the part of the con­fig­ur­a­tion of a con­trol­ler that describes the desired prop­er­ties of a Kuber­netes pod. These include con­tain­ers, the Docker image, en­vir­on­ment variables, resource re­quire­ments and more. The con­trol­ler 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 Kuber­netes pods

In Kuber­netes, there are various methods for updating resources, including the two fre­quently 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 defin­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­cially when only certain fields need to be updated.

The Replace method, on the other hand, replaces all fields of the resource with the cor­res­pond­ing fields in the new defin­i­tion. The replace method is used when a com­pre­hens­ive update is required or fun­da­ment­al struc­tur­al changes are made to the resource.

Some metadata and fields in YAML defin­i­tions of Kuber­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­fic­a­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­an­isms for storing data that extends beyond the lifecycle of a single container.

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

Priv­ileged mode

When a container runs in priv­ileged mode, it has elevated priv­ileges and can access system resources that are not normally available in a standard isolated container. In Kuber­netes, priv­ileged mode is enabled by setting the securityContext.privileged option in the container spe­cific­a­tions.

It’s important to note that the use of priv­ileged mode is as­so­ci­ated with sig­ni­fic­ant security risks. Due to the extended priv­ileges, a com­prom­ised container or a malicious ap­plic­a­tion on the host system could cause serious security problems. Therefore, priv­ileged mode should only be used when necessary and after you have carefully con­sidered the potential security risks.

Static pods

Static pods in Kuber­netes are pods that are not monitored or managed by the central control plane of the cluster. Unlike regular pods, which depend on Kuber­netes con­trol­lers, static pods are initiated directly by a node. These pods are bound to a specific node and their defin­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, auto­mat­ic­ally re­start­ing it if the pod crashes.

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

Container probes

Container probes are mech­an­isms in Kuber­netes that monitor the status and health of a container.

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

• Ex­ecAc­tion (executed using the container runtime en­vir­on­ment): This action allows Kubelet to execute a command within the container. This is par­tic­u­larly useful for per­form­ing custom checks or tests within the container. Once the command has been called, the test is con­sidered suc­cess­ful.
• TCPSock­et­Ac­tion (checked directly by the Kubelet): This action allows the Kubelet to check the ac­cess­ib­il­ity of a specific TCP port within the container. If the specified port is open, the test is con­sidered suc­cess­ful.
• HT­TP­Get­Ac­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­plic­a­tion responds properly to requests. If the request triggers a 2xx status code, the probe is con­sidered suc­cess­ful.