[フレーム][フレーム]

Mastering Kubernetes Pods: Essential Guide for Administrators

This concise guide covers how to effectively create, monitor, and manage Kubernetes pods.

Christopher Tozzi , Technology analyst, Fixate.IO

July 28, 2025

7 Min Read
Kubernetes wheel
Alamy

Arguably, the single most important skill to acquire as a Kubernetes admin is learning to work with pods. Pods are the fundamental building block of Kubernetes workloads. Knowing how to deploy, monitor, scale, and delete pods is absolutely critical to using Kubernetes effectively.

With that reality in mind, here's a concise guide to working with Kubernetes pods. This article doesn't explain every single technical detail and nuance of pods, but it covers what you need to know to get started running pods on a Kubernetes cluster.

What Is a Kubernetes Pod?

In Kubernetes, a pod is essentially an application or workload. Each pod consists of one or more containers that perform a related task.

So, if you want to run, for instance, a web server or a database on top of Kubernetes, you'd configure the web server or database as a deploy, then deploy it.

This is why pods are so important to Kubernetes: Everything you'd want to host on top of a Kubernetes cluster needs to run as a pod.

How Do Pods Work in Kubernetes?

Pods work based on the following process:

  1. Define a pod: Using YAML code, a Kubernetes admin defines a pod. The definition must specify which container or containers should run as part of the pod. It also includes some metadata, such as the name to assign to the pod, and it can optionally include configuration settings like the network port that the pod should use.

  2. Deploy a pod: After defining a pod, admins deploy it using kubectl. This tells Kubernetes to run the pod. Kubernetes automatically decides which node or nodes within the cluster should host your pod (unless you've specified a node to use, which you typically would do only if you need the pod to run on a certain node due to factors like requiring hardware that is available only on that node). It will also reschedule the pod (meaning it will move it from one node to another) if necessary.

  3. Manage the pod: Once a pod is running, you can perform various actions, such as creating replicas of the pod (which means Kubernetes will run multiple instances of it) or stopping the pod. Note that there is no way to "pause" a running pod.

Related:How to SSH into a Kubernetes Pod

Types of Kubernetes Pods

Kubernetes pods can be broken into two key categories based on the type of storage resources they require (or don't require):

  • Stateless pods are ones that don't require persistent storage resources.

  • Stateful pods are ones that do require persistent storage.

This difference is important because it impacts how you go about running a pod. For stateless pods, the easiest way to define and run a pod is by creating what's known as a Deployment (we're capitalizing this term because it's a specific type of Kubernetes object). Stateful pods are typically deployed using a StatefulSet, which makes it easy to connect pods to persistent storage resources so that they can store data without having it disappear when the pods shut down.

Related:Kubernetes 1.32 'Penelope' Introduces Key Innovations for Open Source Cloud Deployment

You can also categorize Kubernetes pods based on how many containers exist within the pod:

  • Single-container pods are the easiest way to run workloads that require just an application, without complementary services (like logging or monitoring agents) running alongside the main application.

  • Multi-container pods are usually used to run logging or monitoring services alongside an application. They do this by hosting the services in separate containers, while the application runs in its own container.

Note that there are ways of running monitoring and logging services for applications without using multi-container pods. For example, you could use eBPF , which doesn't require the use of containers to collect monitoring data or logs. But more traditional approaches to logging and monitoring, like those that use OpenTelemetry collectors, typically involve multi-container pods.

How to Create and Run a Pod: Examples

Related:How to Simplify Kubernetes Management

To create and run a pod in Kubernetes, you must first decide which type of pod to run — a stateless or stateful pod, and a single-container or multi-container pod. As noted above, each type of pod aligns with different use cases and management strategies.

Single-container pods

If you want to run a single-container stateless pod, you'd typically define a Deployment using YAML like the following:

apiVersion: v1
kind: Pod
metadata:
 name: my-stateless-pod
 labels:
       app: myapp
spec:
 containers:
       - name: myapp-container
       image: nginx:latest
       ports:
       - containerPort: 80

To run this pod, save the YAML as a file (such as my-stateless-pod.yaml), then apply it using a kubectl command:

kubectl apply -f my-stateless-pod.yaml

You can verify that the pod has started using the command:

kubectl get pods --all-namespaces

Multi-container pods

If you wanted to run a multi-container pod, you'd define a Deployment that includes multiple containers, such as the following:

apiVersion: apps/v1
kind: Deployment
metadata:
 name: multi-container-deployment
spec:
 replicas: 2
 selector:
       matchLabels:
       app: multi-container-app
 template:
       metadata:
        labels:
          app: multi-container-app
       spec:
        containers:
         - name: main-app
        image: nginx:latest
        ports:
          - containerPort: 80
        - name: log-sidecar
        image: busybox
        command: ["/bin/sh", "-c", "while true; do echo 'Logs from sidecar'; sleep 5; done"]

This Deployment runs two containers — one that hosts the Nginx web server and another that runs a simple logging agent based on a BusyBox instance.

You would deploy these pods by applying the definition with kubectl, using the same approach as for the single-container pod.

Stateful pods

To create a pod that requires stateful storage resources, you'd define a Kubernetes StatefulSet, such as the following:

apiVersion: apps/v1
kind: StatefulSet
metadata:
 name: web-stateful
spec:
 serviceName: "web"
 replicas: 3
 selector:
       matchLabels:
       app: web
 template:
       metadata:
        labels:
          app: web
       spec:
        containers:
         - name: web
          image: nginx:latest
          ports:
            - containerPort: 80
         volumeMounts:
          - name: www
          mountPath: /usr/share/nginx/html
 volumeClaimTemplates:
       - metadata:
         name: www
       spec:
         accessModes: [ "ReadWriteOnce" ]
       resources:
         requests:
           storage: 1Gi

This StatefulSet defines a single-container pod that runs the Nginx web server. It also assigns a persistent volume claim with 1 gigabyte of storage to the pod. The pod could use this volume to store data persistently, and any data stored in the volume will remain intact even if the pod restarts or stops.

As with other types of objects, you'd deploy a StatefulSet using the kubectl apply command.

Managing Kubernetes Pods

Once pods are running, you typically don't need to do a lot to manage them. Indeed, part of the point of Kubernetes is that it automatically runs your pods for you. If your pods run into a problem — such as being hosted on a node that is running out of sufficient CPU or memory resources — Kubernetes will automatically relocate the pods to a different node (assuming one with more resources is available). If a pod crashes, Kubernetes will automatically restart it.

Still, there are some actions you may want to perform to manage pods. Common pod management tasks include the following:

View running pods

To see which pods are running running, use:

kubectl get pods --all-namespaces

This will list running pods, along with information about their current state. Typically, you want to see that active pods are in the Running state. If a pod is stuck in the Pending state for more than a little bit of time, it usually means the pod is not starting properly for some reason (although it's normal for pods to be in Pending mode for some amount of time — usually no more than a minute or two — during startup).

Stop pods

You can stop a pod from running using:

kubectl delete pod <pod_name> -n <namespace>

Restart pods

To restart a running pod, use:

kubectl rollout restart deployment/name

Be sure to replace name with the actual name of your Deployment. You may also need to replace deployment with the Kubernetes object type that refers to the type of resource you created. For example, if you created a StatefulSet instead of a Deployment, you'd restart it using:

kubectl rollout restart statefulset/name

About the Author

Technology analyst, Fixate.IO

Christopher Tozzi is a technology analyst with subject matter expertise in cloud computing, application development, open source software, virtualization, containers and more. He also lectures at a major university in the Albany, New York, area. His book, "For Fun and Profit: A History of the Free and Open Source Software Revolution ," was published by MIT Press.

You May Also Like


Important Update

ITPro Today ended publication on September 30, 2025.

Learn More

AltStyle によって変換されたページ (->オリジナル) /