Pods: the unit of scheduling

Kubernetes · lesson 3 of 32 · 3 min read

Understand what a pod is, why it may hold more than one container, and why you rarely create one directly.

Open this lesson in the learning hub

Key points

  • A pod is one or more containers sharing an IP, a network namespace and volumes. They reach each other on localhost.
  • Almost always one app container per pod. Extra containers are helpers such as log shippers or proxies, never a second app.
  • Init containers run to completion before the app starts. Since 1.29 a native sidecar is an init container with restartPolicy: Always.
  • Pods are cattle. Each one gets a fresh IP and is never repaired in place, only replaced.
  • Do not apply bare pods in production. A pod with no controller above it stays dead when its node dies.

Example

apiVersion: v1
kind: Pod
metadata:
  name: web
  labels:
    app: web
spec:
  containers:
    - name: app
      image: ghcr.io/acme/web:1.4.2
      ports:
        - containerPort: 8080
      env:
        - name: SPRING_PROFILES_ACTIVE
          value: prod

A pod is a scheduling unit, not a server. Expect it to vanish at any moment.

Cluster architecture kubectl and namespaces

This is a reading copy. The full lesson — with the visual explainer, the interactive lab and a Run button for the code — lives in the Kubernetes course, and every lesson in it is listed on the Kubernetes contents page.