IT 3300 : Virtualization

Kubernetes — Pods

Where pods run

  • The control plane schedules pods onto nodes (physical or virtual)
  • Each node's kubelet starts and watches the pod's containers

What is a pod?

  • The smallest deployable unit in Kubernetes
  • One or more containers that are tightly coupled, plus a shared
    specification for how to run them
  • Containers in a pod share:
    • a network namespace (same IP, reach each other on localhost)
    • storage volumes

Pod examples

Usually one container per pod

  • Most pods = a single app container
  • Multiple containers only when tightly coupled (e.g. a sidecar
    that ships logs or serves as a proxy)
  • Shared IP means shared port space — containers in a pod must
    coordinate which ports they use
  • If they don't need to share resources, use separate pods

Pods on nodes

  • A node can run many pods
  • Containers in different pods have distinct IP addresses

A pod, imperatively

    kubectl run kubernetes-bootcamp \
      --image=docker.io/jocatalin/kubernetes-bootcamp:v1 --port=8080
    kubectl get pods
  • The scheduler found a suitable node and scheduled the pod there
  • Quick for experiments — but real work uses YAML

A pod, declaratively

apiVersion: v1
kind: Pod
metadata:
  name: web
spec:
  containers:
    - name: web
      image: nginx:1.27
      ports:
        - containerPort: 80

    kubectl apply -f pod.yaml

Inspecting pods

  • kubectl get pods -o wide — which node, which IP
  • kubectl describe pod web — events, status, why it's stuck
  • kubectl logs web — the container's output
    (-c <container> if the pod has more than one)
  • kubectl exec -it web -- bash — a shell inside
  • kubectl delete pod web — remove it

Pod networking

  • Pods run on a private, isolated cluster network

  • Visible to other pods and services in the cluster — not from outside

  • kubectl proxy connects your machine to the cluster API:

      kubectl proxy
  wget -qO- http://localhost:8001/version

  • Real external access comes from Services (later deck)

Pods are disposable

  • Each pod gets its own IP — but pods come and go
  • When a node dies, its pods are scheduled for deletion after a timeout
  • They are not rescheduled; they're replaced
  • A replacement is a new pod (new UID, maybe new IP) — even if it
    reuses the same name
  • Lesson: never depend on a specific pod or its IP

So who replaces them?

  • You rarely create bare pods in production
  • Delete a bare pod and it's gone
  • A controller (Deployment) watches desired vs. actual and recreates
    pods to keep the count right — that's next