Niemand tut sich mit Kubernetes schwer, weil das YAML schwer zu tippen wäre. Man tut sich schwer, weil zwischen „eine Anfrage kommt an“ und „ein Container bearbeitet sie“ eine unsichtbare Kette von Objekten liegt, und nichts davon steht an einem Ort. Ein Pod führt den Code aus, aber du richtest Traffic nie auf einen Pod. Ein Service gibt ihm einen stabilen Namen, aber ein Service terminiert kein TLS. Ein Ingress oder ein Gateway kümmert sich um die Außenwelt, leitet aber an einen Service weiter, der Pods auswählt, die sich jederzeit verschieben können. Fehlt ein Glied, funktioniert nichts, und die Fehlermeldung sagt dir selten, welches Glied.
Ein Diagramm dieser Kette ist mehr wert als jedes erneute Lesen der Manifeste. Bauen wir das mentale Modell Objekt für Objekt auf und zeichnen es dann.
Pods: wo der Code wirklich läuft
Ein Pod besteht aus einem oder mehreren Containern, die gemeinsam eingeplant werden und sich eine Netzwerkidentität teilen. Er ist die Einheit, die deinen Prozess ausführt. Die entscheidende Tatsache für ein Diagramm: Pods sind Nutzvieh, keine Haustiere. Sie werden ständig erzeugt und zerstört, ihre IPs ändern sich, und du solltest dich nie auf einen bestimmten verlassen. Genau deshalb existiert alles über ihnen: um etwas Stabiles zu bieten, auf das man zeigen kann.
Services: ein stabiler Name vor wandernden Pods
Ein Service ist eine stabile virtuelle Adresse plus eine Load-Balancing-Regel. Er findet über einen Label-Selector die Pods, die ihn bedienen, und verteilt den Traffic auf die, die gerade existieren. Stirbt ein Pod und startet ein neuer, aktualisiert sich der Service still; Aufrufer merken nichts. In deinem Diagramm ist der Service der Kasten, mit dem sich andere Dinge verbinden, mit einer impliziten Auffächerung auf eine wechselnde Menge Pods dahinter.
Kubernetes Ingress und Gateway: die Tür nach draußen
Ein Service allein macht dich nicht sinnvoll von außen erreichbar. Das ist die Aufgabe eines Ingress oder, im neueren Modell, eines Gateways. Diese Schicht übernimmt Host- und Pfad-Routing, TLS-Terminierung und die Regeln, die sagen: „Anfragen für diesen Host und diesen Pfad gehen an jenen Service.“ Die Gateway API verallgemeinert den älteren Ingress mit einer saubereren Aufteilung der Verantwortlichkeiten (wem das Gateway gehört und wem die Routen), aber die Form im Diagramm ist dieselbe: Es ist der Kasten am Rand, auf den alles Externe zuerst trifft und der per Regel an Services weiterleitet.
Zeichne die Kette einmal, und die Fehler fangen an, sich selbst zu erklären: ein kaputter Selector, eine fehlende Route, ein Service, der auf nichts zeigt.
Warum Zeichnen besser ist als erneutes Lesen
Wenn etwas nicht erreichbar ist, ist das Diagramm eine Checkliste. Zeigt die Ingress-Regel auf den richtigen Service? Passt der Selector des Service zu den Labels der Pods? Gibt es überhaupt Pods? Jedes Glied im Bild ist etwas, das falsch sein kann, und wenn du sie ausgebreitet siehst, wird aus einem vagen „es geht nicht“ ein konkretes „der Selector passt nicht“. Das ist der Unterschied zwischen Debuggen und Raten.
Lass die Manifeste es zeichnen
Du musst diese Kästen nicht von Hand platzieren. Deine Manifeste enthalten die ganze Kette bereits: Der Ingress nennt seinen Service, der Service trägt seinen Selector, das Deployment versieht seine Pods mit den Labels. Füge das YAML ein, und die Beziehungen werden für dich gezeichnet, nach Namespace gruppiert, sodass das Bild dem Cluster entspricht statt deinen Annahmen darüber.
Dann für Menschen annotieren
Sobald die Objekte auf der Leinwand sind, lass das Bild etwas lehren. Färbe den externen Rand ein, gruppiere nach Namespace, markiere, wo TLS terminiert wird, und notiere, welcher Service unter Last steht. Ein neuer Engineer sollte eine Anfrage vom Internet bis zum Container mit dem Finger nachverfolgen können, ohne eine einzige YAML-Datei zu öffnen. Das ist das Diagramm, das sich zu behalten lohnt.
Füge deine Manifeste ein, sieh, wie sich Pods, Services, Ingress und Gateways verbinden, und hab endlich den ganzen Weg einer Anfrage auf einmal im Kopf.