Alles, was du in Kubernetes erstellst, ist ein in einem Manifest beschriebenes Objekt, einer YAML-Datei, die sagt, was du willst. Diese Anleitung behandelt gerade genug YAML, um eines zu lesen, erklärt die Struktur, die jedes Manifest teilt, und führt durch das Ausführen eines Pods aus einer Datei. Sie setzt einen funktionierenden Cluster voraus (siehe die vorherige Anleitung).

YAML in fünf Minuten

YAML hat zwei Bausteine, die du erkennen musst.

Eine Map ist eine Menge von key: value-Paaren. Die Einrückung zeigt die Verschachtelung, und alles, was unter einem Schlüssel eingerückt ist, gehört zu ihm. Eine Liste ist eine Folge von Einträgen, die jeweils mit einem Bindestrich beginnen:

app:
  name: shop
  enabled: true
  labels:
    tier: frontend
  ports:
    - 80
    - 443

Hier ist app eine Map mit den Schlüsseln name, enabled, labels und ports. labels ist selbst eine Map, und ports ist eine Liste aus zwei Zahlen. Nutze Leerzeichen, niemals Tabs. Falsche Einrückung ist die häufigste Ursache für ein Manifest, das sich nicht anwenden lässt, und sie ändert stillschweigend, was zu was gehört. Mehrere Objekte können sich eine Datei teilen, wenn du sie durch eine Zeile mit --- trennst.

Anatomie eines Manifests

Jedes Kubernetes-Objekt hat dieselben Felder auf oberster Ebene:

• apiVersion sagt, welche Version der API diese Art von Objekt definiert.
• kind ist der Typ des Objekts, etwa Pod oder Deployment. Es unterscheidet Groß- und Kleinschreibung.
• metadata identifiziert das Objekt: seinen name, optional einen namespace und beliebige labels und annotations.
• spec ist der Soll-Zustand, und sein Inhalt hängt vom Kind ab.

Kubernetes fügt einen vierten Abschnitt hinzu, status, der den tatsächlichen Zustand beschreibt. Du schreibst ihn nicht. Hier ist ein minimaler Pod:

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

containers ist eine Liste, ein Pod könnte also mehrere Container betreiben, die jeweils mit einem eigenen Bindestrich beginnen. Das Feld image solltest du doppelt prüfen. Ein Tippfehler bedeutet, dass Kubernetes es nicht pullen kann und der Pod in einem Fehlerzustand verharrt.

Manifeste nicht von Grund auf schreiben

Kopiere ein funktionierendes Beispiel aus der Kubernetes-Dokumentation oder lass kubectl eines erzeugen:

kubectl run web --image=nginx:1.25 --port=80 --dry-run=client -o yaml > pod.yaml

--dry-run=client baut das Objekt lokal, ohne es zu erstellen, und -o yaml gibt es als YAML aus. Das gibt dir einen gültigen Ausgangspunkt zum Bearbeiten.

Die apiVersion richtig setzen

Verschiedene Kinds leben in verschiedenen API-Gruppen und -Versionen. Pods sind v1, Deployments sind apps/v1, Ingresses sind networking.k8s.io/v1. Wählst du die falsche oder eine Version, die ein neuerer Cluster entfernt hat, bekommst du einen Fehler wie no matches for kind "X" in version "Y". So findest du den richtigen Wert:

kubectl api-resources | grep -i deployment
kubectl explain deployment | head

Das Erste zeigt die Gruppe für jedes Kind, das Zweite seine VERSION. Das zählt am meisten, wenn du einen Cluster upgradest, weil alte Manifeste aufhören können zu funktionieren, wenn eine Version entfernt wird. Die Kubernetes-Anleitung zu Deprecations listet auf, was sich in jedem Release geändert hat.

Erstellen, untersuchen und löschen

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

In kubectl get pods zeigt die Spalte READY, wie viele Container des Pods bereit sind (1/1 ist gesund), STATUS zeigt seine Phase, und RESTARTS zählt Container-Neustarts. Eine Zahl, die ständig steigt, bedeutet, dass etwas den Container immer wieder beendet. describe gibt die vollständigen Details des Pods aus, mit den letzten Events unten, der ersten Anlaufstelle, wenn etwas nicht stimmt.

apply ist deklarativ: Es erstellt das Objekt, wenn es nicht existiert, und aktualisiert es, wenn es existiert, sodass du die Datei bearbeiten und erneut anwenden kannst. kubectl create -f schlägt fehl, wenn das Objekt bereits existiert.

Imperativ vs. deklarativ

Befehle wie kubectl run und kubectl create sind imperativ: Du sagst Kubernetes, etwas jetzt zu tun. Sie sind schnell für Experimente und für Zertifizierungsprüfungen. Mit kubectl apply -f angewendete Manifeste sind deklarativ, und das willst du für alles Echte, weil die Dateien in Git liegen, geprüft und erneut angewendet werden können. Die Argo-CD-Anleitungen in dieser Reihe zeigen, wie du diese Idee zu Ende denkst.