What Is a Kubernetes Pod? How Pods Work in EKS

Simple explanation

Kubernetes does not schedule individual containers. It schedules pods. A pod is the unit Kubernetes places on a node, monitors for health, and restarts if it crashes. When you ask for three replicas of your app, you get three pods, each containing one container.

Most pods contain a single container. Multi-container pods are a specific pattern (sidecars, init containers) and not the default. If you are new to Kubernetes, assume single-container pods until you have a clear reason to add more.

What a pod actually is

A pod groups one or more containers and provides them with shared infrastructure:

• Shared IP address. All containers in a pod share a single IP address. They can reach each other on localhost without going through the cluster network.
• Shared network namespace. Containers in the same pod see the same network interfaces and can bind to different ports on localhost.
• Shared volumes. Containers can mount the same volume, allowing them to exchange files without making network calls.
• Single node. All containers in a pod always run on the same node. A pod cannot span multiple nodes.

From the perspective of the rest of the cluster, a pod is one entity with one IP. From inside the pod, containers are tightly coupled: they live and die together.

How it works

When you deploy an application to Amazon EKS, here is what happens at the pod level:

1. You define a workload. You write a Deployment manifest that includes a pod template: the image, ports, resource limits, and health checks.
2. A controller creates pods. The Deployment controller reads your desired state and creates pods to match it. You rarely write bare pod specs in production.
3. The scheduler assigns a node. Kubernetes looks at the pod’s resource requests and finds a node with enough available capacity.
4. Kubelet starts containers. The kubelet agent on the target node pulls the container image from ECR (or another registry) and starts the containers.
5. The pod gets a network address. EKS uses the VPC CNI plugin to assign the pod a real IP from your VPC subnet, making it directly routable inside your VPC.
6. A Service routes traffic. A Kubernetes Service uses a label selector to find pods with matching labels and sends traffic to them.

The relationship between these concepts, in plain terms:

• A pod is one running instance of your app.
• A node is the EC2 instance (or Fargate profile) where the pod runs.
• A Deployment manages a set of identical pods and handles updates and failures.
• A Service provides a stable IP and DNS name that always points to healthy pods.

Kubernetes pod vs container vs Deployment

These three terms are the ones beginners mix up the most.

Containers run inside pods, and pods are managed by Deployments (or other controllers). You interact with Deployments. Kubernetes manages the pods. For the EKS vs ECS tradeoff when choosing a container platform, see EKS vs ECS.

When to use this

In practice, you rarely create bare pods directly. You use higher-level resources that manage pods for you.

Common pod patterns in production EKS workloads:

• App replicas via Deployment. Your API or web service runs as multiple pods managed by a Deployment. Each pod handles a share of traffic. If one crashes, the Deployment creates a replacement automatically.
• Sidecars. A main app container runs alongside a helper container in the same pod. For example, a Fluent Bit container that ships logs to CloudWatch. See logging in Kubernetes for how this works.
• Node-level agents via DaemonSet. Monitoring and logging agents need to run on every node. A DaemonSet creates one pod per node automatically. See monitoring EKS clusters for common agent patterns.
• Batch tasks via Job or CronJob. A data processing script runs to completion in a pod, exits with Succeeded, and the pod is done.
• Debugging. A bare pod lets you run a shell inside the cluster to test network connectivity or inspect a volume.

Pod lifecycle and common states

Every pod moves through a series of phases. Knowing these helps you diagnose problems when pods are not behaving as expected.

Within a running pod, individual containers have their own states: Waiting, Running, or Terminated. The pod phase is the overall summary. The container state tells you the detail. A pod can show Running while a container inside it is still Waiting for an image pull to complete.

Use these commands to inspect pod and container state:

# List all pods in the current namespace
kubectl get pods

# Describe a pod — shows events, container states, exit codes, and conditions
kubectl describe pod <pod-name>

# View logs from a container
kubectl logs <pod-name>

# View logs from a specific container in a multi-container pod
kubectl logs <pod-name> -c <container-name>

# Stream logs in real time
kubectl logs <pod-name> -f

Pod YAML example

Here is a complete single-container pod specification:

apiVersion: v1
kind: Pod
metadata:
  name: web-server
  labels:
    app: web
    environment: production
spec:
  containers:
  - name: nginx
    image: nginx:1.27
    ports:
    - containerPort: 80
    resources:
      requests:
        cpu: 100m
        memory: 128Mi
      limits:
        cpu: 500m
        memory: 256Mi
    readinessProbe:
      httpGet:
        path: /health
        port: 80
      initialDelaySeconds: 5
      periodSeconds: 10

Key fields explained:

• metadata.labels — key-value pairs attached to the pod. Services use label selectors to find pods, so these labels control which pods receive traffic. They are not just documentation.
• image — the container image to run. Always pin to a specific version tag (nginx:1.27) rather than latest. The latest tag changes silently and can cause unpredictable behaviour when pods restart.
• resources.requests — the minimum CPU and memory the pod needs. The scheduler uses these to decide which node to place the pod on. CPU is measured in millicores (100m = 0.1 cores). Memory is in mebibytes (128Mi).
• resources.limits — the maximum CPU and memory the pod can use. A container that exceeds its memory limit is killed with an OOMKilled error.
• readinessProbe — Kubernetes checks this before sending traffic to the pod. A pod that fails its readiness check is removed from Service endpoints. Without this, your app receives traffic before it is ready.

You can apply this manifest using kubectl:

kubectl apply -f pod.yaml
kubectl get pod web-server

Multi-container pods and sidecars

Multi-container pods are not the default. Use them when two containers genuinely need to share a network or a volume, not simply because they are related services.

The most common pattern is the sidecar: a helper container running alongside the main app. In this example, a Fluent Bit container reads log files written by the web app and ships them to CloudWatch:

apiVersion: v1
kind: Pod
metadata:
  name: app-with-logging
spec:
  containers:
  - name: web-app
    image: my-company/web-app:2.1.0
    ports:
    - containerPort: 8080
    volumeMounts:
    - name: log-volume
      mountPath: /var/log/app
  - name: log-shipper
    image: fluent/fluent-bit:3.0
    volumeMounts:
    - name: log-volume
      mountPath: /var/log/app
      readOnly: true
  volumes:
  - name: log-volume
    emptyDir: {}

The web app writes to /var/log/app. Fluent Bit reads from the same directory via a shared emptyDir volume. The two containers coordinate through the filesystem without any network calls. Because they share an IP, they can also communicate directly over localhost on any port.

Other multi-container patterns include init containers (run to completion before the main container starts, used for setup tasks like schema checks) and ambassador containers (proxy network connections on behalf of the main container).

Pod vs node, Service, and Deployment

These four concepts are easy to mix up when you are starting out: