Pody

Pody

Nejmenší plánovatelná jednotka. Není to kontejner – je to prostředí pro jeden nebo více kontejnerů.

graph TB subgraph pod [Pod – jedna IP, jeden síťový namespace] C1[kontejner: aplikace] C2[kontejner: sidecar] V[(sdílený volume)] C1 --- V C2 --- V end

Kontejnery v podu sdílejí IP adresu, porty, IPC a volumes a vždy běží na stejném uzlu. Mluví spolu přes localhost. Je to režim --network container: z Dockeru povýšený na plnohodnotný objekt.

Minimální manifest

apiVersion: v1
kind: Pod
metadata:
  name: nginx-pod
spec:
  containers:
    - name: nginx
      image: nginx:1.27
      ports:
        - containerPort: 80
      resources:
        requests: { cpu: "50m", memory: "64Mi" }
        limits:   { cpu: "200m", memory: "128Mi" }

Requests rozhodují, kam se pod naplánuje – scheduler je odečítá od volné kapacity uzlu. Limits rozhodují, co se stane pod tlakem: CPU nad limit se přiškrtí, paměť nad limit znamená OOM kill. Pod bez requests je sázka do loterie.

Životní cyklus

Pending → Running → Succeeded / Failed, plus CrashLoopBackOff, když kontejner opakovaně padá. restartPolicy je výchozí Always.

Pending znamená, že scheduler pod neumístil (kapacita, taint, nenavázaný PVC). ContainerCreating znamená, že je umístěný a pracuje kubelet – stahuje image, připojuje volume.

Init kontejnery a sidecary

spec:
  initContainers:
    - name: wait-for-db
      image: busybox
      command: ["sh", "-c", "until nc -z db 5432; do sleep 2; done"]

Init kontejnery doběhnou do konce, jeden po druhém, teprve pak startují hlavní kontejnery. Takhle se vyjádří „nestartuj, dokud neodpovídá databáze“.

V praxi

Holé pody vytváříte zřídka. Holý pod se po výpadku uzlu nikam nepřeplánuje – použijte Deployment. Holé pody jsou na ladění a jednorázové úlohy.

kubectl run tmp --image busybox --restart=Never -it --rm -- sh

Reference