Lektion 04 · Deployen

Deklarativ deployen

Deine erste eigene App per YAML — mit Sicherheitsnetz, bevor du schreibst.

Jetzt der erste schreibende Befehl. Wir machen es so, wie man es im Job tut: in einem eigenen Namespace, mit Vorschau, ohne Risiko fürs Bestehende.

1. Der Aufbau eines Manifests

Jedes Objekt hat dieselben vier Top-Level-Felder:

apiVersion: apps/v1     # welche API-Version
kind: Deployment        # welcher Objekttyp
metadata:               # Name, Namespace, Labels
  name: web
spec:                   # der gewünschte Soll-Zustand
  replicas: 2
  selector:
    matchLabels: { app: web }
  template:
    metadata:
      labels: { app: web }
    spec:
      containers:
        - name: web
          image: nginx:1.27
          ports:
            - containerPort: 80
Merke die vier Felder

„Was — Wie heißt's — Was soll's sein“: apiVersion+kind (was), metadata (wie heißt's), spec (was soll's sein). Diese Struktur hat jedes Objekt.

2. Der sichere Deploy-Workflow

Drei Schritte, immer in dieser Reihenfolge:

SchrittBefehlWarum
1. Validierenapply --dry-run=serverServer prüft das YAML, schreibt aber nichts.
2. Vorschaukubectl diff -fZeigt genau, was sich ändern würde.
3. Anwendenkubectl apply -fGleicht den Cluster an dein Manifest an.
dry-run: client vs. server

--dry-run=client prüft nur lokal die Form (gut zum YAML-Erzeugen). --dry-run=server schickt es an den API-Server, der es echt validiert (Admission, Schema) — aber nichts speichert. Im Zweifel server.

3. Hands-on: App in eigenem Namespace

Ein eigener Namespace lernen hält deine Übungen sauber getrennt vom Rest des Clusters.

# 0) Sicherheit: wo bin ich?
kubectl config current-context

# 1) Übungs-Namespace anlegen
kubectl create namespace lernen

# 2) Manifest erzeugen lassen (imperativ → YAML), NICHT anwenden
kubectl create deployment web --image=nginx:1.27 -n lernen \
  --dry-run=client -o yaml > web.yaml

# 3) web.yaml ansehen/anpassen (z.B. replicas: 2)

# 4) Validieren — schreibt nichts
kubectl apply -f web.yaml --dry-run=server

# 5) Anwenden
kubectl apply -f web.yaml

# 6) Kontrolle (Lektion 2 lässt grüßen)
kubectl get deploy,pods -n lernen
Eselsbrücke: apply ist idempotent

apply nochmal aufrufen schadet nicht — gleicht nur ab. Es ist wie ein Thermostat, nicht wie ein Lichtschalter: du sagst „so soll es sein“, nicht „tu das jetzt einmal“.

Selbsttest

1. Welcher Befehl zeigt vorab, was sich am Cluster ändern würde?
2. Du führst dasselbe apply zweimal aus. Folge?
3. Welches Feld beschreibt den gewünschten Zustand eines Objekts?
Frag deinen Lehrer: „Was ist der Unterschied zwischen apply und create?“, „Wie räume ich die Übung wieder auf?“ (Vorschau: Lektion 9) oder „Was bedeutet nginx:1.27 vs. nginx:latest?“