35. Pody, Deploymenty a ReplicaSety

Úvod a kontext

Minulá lekce popsala architekturu clusteru. Teď je čas podívat se na
to, co v Kubernetes skutečně spouští aplikace. Kubernetes nikdy
nepracuje přímo s "kontejnerem" jako nejmenší jednotkou — nejmenší
nasaditelnou jednotkou je Pod. Nad Pody pak stojí vyšší abstrakce
ReplicaSet a Deployment, které v praxi používáte téměř vždy
místo ručního vytváření jednotlivých Podů.

Teorie

Pod

Pod je nejmenší nasaditelná jednotka v Kubernetes. Obsahuje jeden
nebo více kontejnerů, které:

• sdílejí stejnou síťovou identitu (jednu IP adresu a port prostor —
  kontejnery uvnitř jednoho Podu spolu komunikují přes localhost),
• mohou sdílet volumes,
• jsou vždy plánovány a škálovány společně na stejný uzel.

Nejčastější případ je jeden kontejner na Pod — víc kontejnerů v
jednom Podu se používá jen pro úzce provázané pomocné procesy (tzv.
sidecar vzor, např. kontejner sbírající logy vedle hlavní aplikace).

Minimální manifest Podu:

apiVersion: v1
kind: Pod
metadata:
  name: web-pod
  labels:
    app: web
spec:
  containers:
    - name: web
      image: nginx:1.25
      ports:
        - containerPort: 80

kubectl apply -f pod.yaml
kubectl get pods
kubectl logs web-pod
kubectl delete pod web-pod

Ruční Pod má zásadní problém: pokud spadne (nebo spadne uzel, na kterém
běžel), nikdo ho automaticky znovu nevytvoří. Pody vytvořené přímo
tímto způsobem jsou tedy vhodné jen pro dočasné ladění, ne pro
produkční nasazení.

ReplicaSet

ReplicaSet řeší přesně tento problém — zajišťuje, že běží
zadaný počet replik Podu odpovídajícího danému vzoru (selektoru).
Pokud Pod spadne, ReplicaSet vytvoří nový, aby se počet běžících Podů
vrátil k požadovanému.

apiVersion: apps/v1
kind: ReplicaSet
metadata:
  name: web-rs
spec:
  replicas: 3
  selector:
    matchLabels:
      app: web
  template:
    metadata:
      labels:
        app: web
    spec:
      containers:
        - name: web
          image: nginx:1.25

Deployment

V praxi se ReplicaSet ale téměř nikdy nevytváří ručně — používá se
Deployment, vyšší abstrakce, která ReplicaSet spravuje za vás a
navíc přidává:

• rolling updates — při změně image Deployment postupně nahradí
  staré Pody novými bez výpadku (vytvoří nový ReplicaSet, postupně
  škáluje nahoru, starý škáluje dolů),
• rollback — možnost vrátit se k předchozí verzi jedním příkazem,
• historii revizí nasazení.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web
spec:
  replicas: 3
  selector:
    matchLabels:
      app: web
  template:
    metadata:
      labels:
        app: web
    spec:
      containers:
        - name: web
          image: mycompany/web:1.4.0
          ports:
            - containerPort: 8000
          resources:
            requests:
              cpu: "100m"
              memory: "128Mi"
            limits:
              cpu: "500m"
              memory: "256Mi"

Vztah mezi objekty je hierarchický: Deployment spravuje ReplicaSet,
ReplicaSet spravuje Pody. Když aktualizujete image v Deploymentu,
Kubernetes vytvoří nový ReplicaSet s novým image a postupně na něj
přepne provoz; starý ReplicaSet zůstává (se škálováním na 0 replik)
pro případný rollback.

Praktický příklad

# vytvoření Deploymentu
kubectl apply -f deployment.yaml

# sledování stavu
kubectl get deployments
kubectl get replicasets
kubectl get pods -l app=web

# aktualizace na novou verzi image
kubectl set image deployment/web web=mycompany/web:1.5.0

# sledování průběhu rolling update
kubectl rollout status deployment/web

# v případě problému rychlý návrat na předchozí verzi
kubectl rollout undo deployment/web

# historie revizí
kubectl rollout history deployment/web

Výstup kubectl get pods -l app=web během rolling update ukáže, jak
postupně mizí Pody se starým image a přibývají Pody s novým — provoz
mezitím neustane, protože v každém okamžiku je k dispozici dostatek
běžících replik.

Shrnutí

Pod je nejmenší nasaditelná jednotka (jeden nebo víc úzce provázaných
kontejnerů se sdílenou sítí), ale sám o sobě se neumí zotavit z pádu.
ReplicaSet udržuje zadaný počet replik Podu. Deployment spravuje
ReplicaSet a navíc přidává rolling update a rollback — v praxi je to
objekt, který pro nasazení bezstavových aplikací používáte téměř vždy
místo ručního vytváření Podů nebo ReplicaSetů.

Kontrolní otázky

1. Proč se v produkci téměř nikdy nevytváří Pod přímo, ale skrz
   Deployment?
2. Jaký je vztah mezi Deploymentem, ReplicaSetem a Podem?
3. Co se stane s předchozím ReplicaSetem po rolling update na novou
   verzi image a k čemu se hodí?
4. Mini cvičení: napište Deployment manifest pro image httpd:2.4 se
   4 replikami a labelem app: apache, nasaďte ho příkazem kubectl apply, poté proveďte kubectl scale deployment/<jméno> --replicas=2 a ověřte pomocí kubectl get pods, že se počet
   běžících Podů skutečně snížil.