Kubernetes-Grundlagen

Kubernetes-Grundlagen

0:00 Wir wechseln jetzt die Perspektive. Vier Module lang haben wir Container gebaut, gehärtet und abgesichert — immer mit Blick auf ein einzelnes Artefakt. Ab sofort geht es darum, wo diese Container am Ende laufen: in einem Cluster, der sie selbst verwaltet. Und das verlangt eine echte Umstellung im Denken. Sie geben keine Befehle mehr, sondern beschreiben einen Wunschzustand — und überlassen es dem System, ihn herzustellen und zu erhalten.

0:26 Das ist zunächst unbequem, weil man Kontrolle abgibt. Es ist aber der Grund, warum ein Cluster nachts einen Knotenausfall wegsteckt, ohne dass jemand aufwacht. Acht Kapitel, von der Architektur bis zur Fehlersuche.

Die Architektur eines Clusters

0:40 Beginnen wir mit dem einen Prinzip, das alles Weitere erklärt. Wer es verstanden hat, versteht jedes Objekt in Kubernetes als Sonderfall desselben Musters: ein Soll-Zustand, und Regler, die ihn herstellen. Das Bild dazu ist die Heizung mit Thermostat. Sie sagen nicht „mach den Brenner für elf Minuten an" — Sie stellen einundzwanzig Grad ein.

1:01 Der Regler vergleicht dann fortlaufend Soll und Ist und handelt, wenn beides auseinanderfällt. Genau so arbeitet ein Cluster: Eingereicht wird eine Beschreibung, nicht ein Befehl. Der Schnittstellendienst nimmt sie an und legt sie in einer Datenbank ab, und alles Weitere ist eine Schleife — beobachten, vergleichen, angleichen.

1:20 Das erklärt übrigens auch, warum Kubernetes sich manchmal so eigenwillig anfühlt: Sie können nichts befehlen, das die Regler nicht wollen. Sie können nur den Sollwert ändern. Diese fünf Bauteile müssen Sie nicht betreiben — in einem verwalteten Cluster sieht man sie nie. Kennen sollten Sie sie trotzdem, weil ihre Namen in jeder Fehlermeldung auftauchen.

1:41 Der Schnittstellendienst ist das Nadelöhr: Alles geht durch ihn, er prüft Rechte, er schreibt fort — und genau hier greifen die Eingangsprüfungen aus Modul 4. etcd verwahrt den gesamten Zustand; ein Cluster ohne diese Datenbank hat kein Gedächtnis. Der Planer wählt Knoten aus, dazu kommen wir in Kapitel 7 zurück. Und der Reglerbetreiber ist die Schleife von der letzten Folie, in Software gegossen. Auf jedem Arbeitsknoten laufen zusätzlich drei weitere Bauteile.

2:08 Vier Konsequenzen, und der erste ist der, den man einmal erlebt haben muss: Ein verlorener Pod wird ersetzt, ohne dass jemand einen Befehl gibt. Nachts, ohne Bereitschaftsdienst. Der zweite ist die Reproduzierbarkeit — dieselbe Beschreibung führt auf jedem Cluster zum selben Ergebnis, was den Weg von Test zu Produktion entschärft.

2:27 Der dritte ist derselbe Gedanke wie beim Dockerfile aus Modul 1: Der Soll-Zustand liegt als Datei im Repository und ist damit prüfbar, reviewbar, versioniert. Und der vierte verändert Ihre Arbeitsweise am spürbarsten: Fehlersuche heißt hier nicht „was ist kaputt", sondern „warum kommt das System nicht an sein Ziel". Kapitel 8 baut darauf auf.

2:48 Vier Befehle, und die Reihenfolge ist die Botschaft: Erst sehen, dann ändern. Auf einem fremden Cluster sind das die ersten Minuten — welche Knoten gibt es, was läuft schon, wie ist die Steuerungsebene erreichbar. Besonders empfehle ich die dritte Zeile, weil sie eine Frage beantwortet, die man sonst mühsam sucht: Welche Objektarten kennt dieser Cluster überhaupt?

3:08 Denn Kubernetes ist erweiterbar, und ein Cluster mit installiertem Richtlinien-Werkzeug oder Zertifikatsverwalter kennt Objekte, von denen ein anderer nie gehört hat. Diese Liste ist Ihre Inventur — und sie verhindert, dass Sie ein Manifest einreichen, für das niemand zuständig ist. Alle vier Punkte sind derselbe Rückfall: Man behandelt den Cluster wie einen Server.

3:30 Objekte von Hand einzeln zu erzeugen funktioniert und ist trotzdem falsch, weil das Ergebnis nirgends beschrieben steht — beim nächsten Mal erinnert sich niemand. Der zweite ist eine Geduldsfrage mit echtem Missverständnis: Regler arbeiten in Schleifen, eine Änderung wirkt nicht sofort, sondern beim nächsten Durchlauf. Der dritte ist eine Warnung: In die Datenbank der Steuerungsebene schreibt man nicht selbst, nie.

3:53 Und der vierte ist der philosophische und der wichtigste: Nicht der Ist-Zustand ist die Wahrheit, sondern die Beschreibung. Der Ist-Zustand ist nur die Annäherung.

Pod, ReplicaSet und Deployment

4:02 Jetzt zu den ersten Objekten, und gleich mit einer Warnung: Es sind drei Ebenen, aber Sie schreiben nur eine davon. Der häufigste Anfängerfehler in Kubernetes ist, die falsche Ebene anzufassen — und sich dann zu wundern, dass die Änderung nicht hält. Drei Ebenen, und man kann sie sich wie eine Firma vorstellen. Der Pod ist der Arbeitsplatz: ein oder mehrere Container mit gemeinsamem Netz und gemeinsamer Ablage — sie sehen einander als localhost.

4:29 Das ReplicaSet ist die Personalplanung: Es hält eine gewünschte Zahl gleichartiger Pods am Leben, stumpf und zuverlässig. Und das Deployment ist die Geschäftsführung: Es verwaltet ReplicaSets und regelt damit den Übergang von einer Fassung zur nächsten. Der letzte Satz ist der praktisch wichtigste: Geschrieben wird nur das Deployment. Pods und ReplicaSets sehen Sie, Sie lesen sie bei der Fehlersuche — aber Sie schreiben sie nicht.

4:55 Das ist der Kopf eines Manifests, und die entscheidende Stelle ist die Doppelung: Dasselbe Label steht zweimal da — einmal in der Auswahl, einmal in der Vorlage. Das sieht nach Redundanz aus und ist keine. Die Vorlage sagt, welche Labels neue Pods bekommen. Die Auswahl sagt, welche Pods dieses Deployment als seine betrachtet.

5:14 Wenn beides nicht zusammenpasst, erzeugt das Deployment Pods, die es anschließend nicht wiedererkennt — und dann erzeugt es die nächsten. Ein Verhalten, das beim ersten Mal völlig unerklärlich wirkt. Merken Sie sich diese zwei Stellen; wir kommen in Kapitel 3 darauf zurück, warum sie so heikel sind. Der Rest der Vorlage ist erfreulich unspektakulär und erinnert an das, was wir in Modul 3 in Compose geschrieben haben: Name, Image, Port.

5:40 Wer Compose kennt, erkennt hier vieles wieder — die Begriffe sind andere, die Denkweise ist ähnlich. Beachten Sie den Hinweis unten, denn dort schließt sich der Kreis zu Modul 4: Hier steht der Tag nur der Kürze wegen. In einem Cluster mit der Signaturregel wird er beim Zulassen durch den Digest ersetzt — die Faustregel „veröffentlichen mit Tags, deployen mit Digests" wird dort automatisch durchgesetzt, ohne dass jemand vierundsechzig Zeichen tippen muss.

6:07 Drei Zeilen, und der eigentliche Inhalt steht darunter: Ein gelöschter Pod kehrt zurück, ein gelöschtes Deployment nimmt alles darunter mit. Das ist die praktische Konsequenz der Ebenen und die Antwort auf die Frage, die jeder Einsteiger stellt: Warum kann ich diesen Pod nicht loswerden? Weil eine Ebene darüber ihn vermisst und neu bestellt. Merken Sie sich außerdem die Arbeitsteilung für die Fehlersuche: Ist die Anzahl falsch, sehen Sie beim ReplicaSet nach.

6:34 Geht ein Ausrollen schief, beim Deployment. Läuft ein einzelner Container nicht, beim Pod. Diese Zuordnung erspart eine Menge blindes Suchen. Der rote Faden: Sie ändern die Beschreibung, das System macht den Rest. Schritt zwei ist eine Gewohnheitsfrage, die den Unterschied macht — beobachten Sie den Fortschritt des Ausrollens, nicht die einzelnen Pods.

6:55 Wer Pods zählt, sieht ein Durcheinander; wer das Ausrollen beobachtet, sieht einen Vorgang mit klarem Ende. Schritt drei ist die eigentliche Sicherheit: Die neuen Pods melden Bereitschaft, bevor die alten gehen. Und genau das steht im Hinweis darunter, und es ist wichtig: Ohne Bereitschaftsprüfung aus Kapitel 6 rollt das Ausrollen an einem kaputten Dienst vorbei — es wirkt erfolgreich, während nichts funktioniert.

7:19 Schritt vier und fünf sind der Ernstfall. Drei Befehle für den Ernstfall, und ich empfehle, sie einmal in Ruhe zu üben, bevor man sie braucht. Der erste wartet, bis das Ausrollen fertig ist, und taugt deshalb gut für Pipelines. Der zweite zeigt den Verlauf. Der dritte nimmt zurück — und der Hinweis darunter erklärt, warum das so schnell geht: Das alte ReplicaSet ist nicht gelöscht, es steht nur auf null.

7:44 Zurückrollen heißt also umschalten, nicht neu bauen. Das ist einer der eleganten Züge dieser Architektur: Weil alles beschrieben ist, ist die vorige Beschreibung noch da. Nutzen Sie das im Ernstfall, aber beheben Sie danach die Ursache im Manifest. Diese Übung ist Ihr erster echter Cluster-Kontakt, und sie hat einen dramaturgischen Höhepunkt.

8:05 Reichen Sie einen beschriebenen Soll-Zustand ein und weisen Sie die Wirkung der Reglerschleife nach: Drei Pods laufen verteilt, ein von Hand gelöschter Pod wird ohne Zutun ersetzt, eine geänderte Replikatzahl wirkt binnen Sekunden. Der Moment, in dem Sie einen Pod löschen und er einfach wiederkommt, ist der überzeugendste des ganzen Moduls — nehmen Sie sich Zeit dafür.

8:25 Wer schneller fertig ist, löscht das ReplicaSet statt eines Pods und erklärt den Unterschied. Das ist die Probe darauf, ob die Ebenen sitzen. Der erste Punkt ist die Bestrafung für die falsche Ebene: Ein von Hand beschriebener Pod hat niemanden über sich — fällt der Knoten aus, kommt nichts zurück. Der zweite ist die Label-Falle von der Code-Folie, und sie ist im Betrieb besonders unangenehm: Ändern Sie Auswahl und Vorlage getrennt, und die Verwaltung reißt mitten im Ausrollen.

8:53 Der dritte ist ein Kampf, den man nicht gewinnt — die Replikatzahl von Hand nachzuziehen, während ein Regler sie hält. Und der vierte ist eine Erwartung aus der Serverwelt: Pod-Adressen sind flüchtig. Sie wechseln bei jedem Ersatz, und genau deshalb gibt es das nächste Kapitel.

Labels, Annotationen und Auswahl

9:09 Jetzt ein Kapitel, das auf der Folie unscheinbar aussieht und in dem trotzdem die halbe Fehlersuche endet. Labels sind der Klebstoff, der die Objekte in Kubernetes zusammenhält — und wenn er nicht klebt, funktioniert nichts, ohne dass irgendwo ein Fehler stünde. Labels sind kurze Schlüssel-Wert-Paare, und ihre Besonderheit ist: Man kann nach ihnen auswählen. Das ist keine Nebeneigenschaft, sondern die Grundmechanik.

9:34 Dienste, Deployments und Regler finden ihre Pods ausschließlich darüber — es gibt keine Liste, keine Verweise, keine Verzeichnisstruktur. Nur Auswahl. Annotationen sehen genau gleich aus, sind aber nicht auswählbar; sie tragen Zusatzangaben für Werkzeuge und Menschen. Und daraus folgt die einzige Frage, die Sie sich stellen müssen: Muss danach ausgewählt werden? Wenn ja, Label. Wenn nein, Annotation.

10:00 Wer sich diese Frage angewöhnt, macht in diesem Bereich kaum noch Fehler. Diese vier Befehle sind mehr als Kommandozeilen-Handwerk, denn hier steht eine Erkenntnis drin: Es ist dieselbe Sprache wie im Manifest. Der Ausdruck, mit dem Sie hier auf der Kommandozeile Pods filtern, ist derselbe, der im Deployment unter der Auswahl steht.

10:20 Sie können also eine Auswahl ausprobieren, bevor Sie sie in ein Manifest schreiben — und bei der Fehlersuche fragen: Trifft diese Auswahl wirklich, was ich glaube? Beachten Sie die zweite Zeile mit dem mengenbasierten Ausdruck; solche Auswahlen sind mächtiger als reine Gleichheit. Und die dritte gehört zu den Befehlen, die man täglich braucht.

10:40 Vier Zeilen, und die erste ist die einzige, die wirklich zählt — die anderen drei folgen daraus. Interessant ist die zweite: Die Länge des Werts ist bei Labels kurz begrenzt, bei Annotationen praktisch beliebig. Das ist kein Zufall, sondern eine Folge der Auswählbarkeit: Wonach effizient gefiltert wird, muss klein sein. Deshalb der trockene Hinweis unten — wer eine lange Zeichenkette als Label vergibt, merkt es erst an der Ablehnung. Für den Alltag heißt das: Rolle, Stufe, Fassung als Label.

11:10 Kontakt, Beschreibung, Werkzeugdaten und alles, was ein Mensch lesen soll, als Annotation. Das ist eine Organisationsempfehlung, und sie zahlt sich erst nach Monaten aus — weshalb sie meist zu spät kommt. Der erste Punkt ist der technische: Dienste, Regler und Auswertungen greifen alle auf dieselben Schlüssel zu, und die müssen verabredet sein.

11:31 Der zweite ist praktisch: Eine Stufenangabe erlaubt dieselbe Beschreibung für Test und Produktion. Der dritte wird spätestens dann wichtig, wenn jemand nach Kosten fragt — Auswertungen über Auslastung brauchen eine verlässliche Rollenangabe, sonst sind sie Kaffeesatz. Und der vierte ist die Warnung: Ohne Verabredung erfindet jedes Team eigene Schlüssel, und in einem Jahr findet niemand mehr etwas.

11:53 Es gibt empfohlene Standardschlüssel — nehmen Sie sie. Der erste Punkt ist heimtückisch und passiert im Betrieb: Ein Label im laufenden Betrieb geändert, und der Pod fällt aus seinem Dienst heraus — er läuft weiter, bekommt aber keinen Verkehr mehr, und nirgends steht ein Fehler. Der zweite ist ein Entwurfsfehler mit derselben Wirkung: Ein Label, das die Fassung trägt und gleichzeitig zur Dienstauswahl gehört, reißt bei jedem Ausrollen die Erreichbarkeit ab.

12:19 Trennen Sie diese beiden Zwecke. Der dritte ist die Verwechslung aus der Tabelle. Und der vierte betrifft geteilte Cluster: Eine zu weit gefasste Auswahl zählt fremde Pods eines anderen Teams mit — und verteilt Verkehr an sie.

Services und Erreichbarkeit

12:32 Wir hatten es gerade: Pod-Adressen sind flüchtig. Jetzt kommt die Antwort darauf, und sie ist eines der elegantesten Stücke von Kubernetes. Pods kommen und gehen, die Adresse bleibt. Und dabei trennt sich internes Ansprechen von echtem Zugang aus dem Netz. Ein Service ist eine dauerhafte Adresse vor einer wechselnden Menge von Pods — denken Sie an eine Telefonzentrale. Die Durchwahl bleibt gleich, wer abnimmt, kann wechseln.

12:59 Und wie findet der Service seine Ziele? Über Labels, genau wie im letzten Kapitel besprochen. Innerhalb des Clusters genügt das vollständig: Ihre Dienste sprechen sich untereinander an, fertig. Für Zugang von außen braucht es eine Ebene darüber — einen Lastverteiler der Umgebung oder einen Türsteher, der nach Rechnernamen und Pfaden entscheidet.

13:19 Diese Unterscheidung zwischen innen und außen sauber zu ziehen, ist der Inhalt dieses Kapitels. Fünf Arten, und in der Praxis brauchen Sie meist die erste. Das ist der Punkt, den ich hervorheben will: Die Voreinstellung ist nur im Cluster erreichbar, und das ist für die überwiegende Mehrheit Ihrer Dienste genau richtig — eine Datenbank hat nach außen nichts zu suchen.

13:40 Die zweite Art öffnet einen hohen Port auf jedem Knoten und ist eher ein Notbehelf. Die dritte verlangt einen Lastverteiler von der Umgebung, weshalb sie in der Cloud funktioniert und lokal nicht. Die vierte ist ein Namensverweis nach außen. Und die fünfte, ohne eigene Adresse, ist der Sonderfall für Datenbanken, die ihre Knoten einzeln ansprechen müssen.

14:01 Ein kurzes Manifest, und zwei Stellen sind hervorzuheben. Die Auswahl greift auf dasselbe Label wie das Deployment — hier hängt der Klebstoff. Und die beiden Ports darunter sind die klassische Verwechslungsquelle: Der eine ist die Adresse, unter der der Service angesprochen wird, der andere der Port im Container. Beide gleich zu benennen wäre bequem und ist unüblich.

14:22 Der Hinweis unten schließt den Bogen zu Modul 3: Der Dienstname ist gleichzeitig der Rechnername im Cluster — genau wie bei Compose. Wer dort verstanden hat, warum in der Datenbankadresse ein Dienstname stand, versteht es hier sofort wieder. Jetzt der Zugang von außen — und hier hat sich etwas bewegt, das man wissen sollte. Lange war der Ingress der einzige Weg.

14:44 Die Kubernetes-Dokumentation führt ihn heute als eingefroren und empfiehlt stattdessen die Gateway API: dieselbe Aufgabe, aber getrennt nach Rollen. Der Betrieb beschreibt das Tor, die Entwicklung beschreibt die Wege darauf. Das klingt nach Bürokratie und ist tatsächlich eine Verbesserung, weil es die Wirklichkeit abbildet — Zertifikate und öffentliche Adressen gehören dem Betrieb, Pfade und Rechnernamen den Teams.

15:08 Und die beruhigende Nachricht: Ingress bleibt lauffähig und wird nicht entfernt. Sie müssen nichts umbauen, aber Neues sollten Sie anders anfangen. Lesen Sie dieses Manifest von unten nach oben, dann erzählt es eine Geschichte: Es gibt einen Dienst mit einem Port, es gibt einen Rechnernamen, unter dem er erreichbar sein soll — und es gibt ein Tor, an das dieser Weg gehängt wird.

15:29 Genau dieser Verweis nach oben ist die Rollentrennung von der letzten Folie in einer Zeile. Das Tor beschreibt der Betrieb einmal, mit Zertifikat und öffentlicher Adresse. Ihr Team schreibt nur diesen Weg — und braucht dafür keine Rechte am Tor. Wenn Sie aus der Ingress-Welt kommen, ist das der eine Unterschied, den es zu verinnerlichen lohnt: zwei Objekte statt einem, zwei Zuständigkeiten statt Annotationen.

15:53 Vier Vergleichszeilen, und die erste ist die entscheidende: eingefroren gegen laufend. Ein eingefrorenes Objekt ist nicht kaputt, aber es bekommt keine neuen Fähigkeiten mehr — und in einem Feld, das sich weiterbewegt, bedeutet das Stillstand. Die dritte Zeile beschreibt den eigentlichen Schmerz der alten Lösung: Anbieterbesonderheiten liefen über Annotationen, und dadurch war jedes Ingress-Manifest faktisch an einen bestimmten Türsteher gebunden.

16:18 Bei der Gateway API sind es eigene Objekte, also sichtbar und prüfbar. Meine Einordnung deckt sich mit dem Hinweis unten: Für bestehende Cluster bleibt Ingress vertretbar. Für Neues ist die Empfehlung eindeutig. Diese Übung verbindet die beiden Hälften des Kapitels: Unterscheiden Sie interne Adressierung von externem Zugang und belegen Sie den Weg von außen bis zum Pod.

16:40 Geschafft ist es, wenn der Dienst unter einem eigenen Rechnernamen von außen antwortet — und wenn die Auswahl nachvollziehbar auf genau die drei Pods weist. Der zweite Teil ist der lehrreichere: Sehen Sie sich die Endpunkte an, denn dort wird die Label-Auswahl sichtbar, die sonst unsichtbar arbeitet. Wer schneller fertig ist, entfernt ein Label an einem Pod und beobachtet, wie er aus der Verteilung fällt.

17:02 Damit haben Sie den Stolperstein von vorhin selbst erzeugt — und werden ihn wiedererkennen. Der erste Punkt trifft jeden beim ersten lokalen Cluster: Ein Lastverteiler wird verlangt, aber lokal stellt ihn niemand bereit — der Service bleibt für immer im Zustand „ausstehend". Der zweite ist die Portverwechslung aus der Code-Folie und führt zu einem Dienst, der antwortet, aber ins Leere leitet.

17:24 Der dritte ist der klassische Klebstoff-Fehler und mein erster Griff bei „Dienst antwortet nicht": Eine falsch geschriebene Auswahl ergibt eine Adresse ohne Endpunkte — technisch alles in Ordnung, praktisch niemand dahinter. Und der vierte ist eine Investitionsfrage: Für neue Wege auf Ingress zu setzen, heißt heute schon in eine eingefrorene Schnittstelle zu bauen.

Konfiguration und Geheimnisse

17:44 Jetzt zu der Frage, die erklärt, warum ein Image über alle Stufen dasselbe bleiben darf. Dasselbe Image, andere Umgebung — Test, Abnahme, Produktion, ohne neuen Bauvorgang. Das ist eine der Grundregeln moderner Anwendungen, und in Kubernetes hat sie zwei Objekte. Konfiguration gehört nicht ins Image, sondern daneben — dieser Satz ist der Kern. Denn ein Image, das die Testdatenbank fest eingebaut hat, ist kein Produktionsartefakt.

18:12 Also gibt es zwei Objekte: eine ConfigMap für unkritische Werte, ein Secret für die vertraulichen. Beide lassen sich als Umgebungswerte oder als Dateien einbinden. Und jetzt der Satz, der die häufigste Fehlvorstellung in Kubernetes auflöst: Ein Secret ist nur kodiert, nicht verschlüsselt. Der Inhalt sieht aus wie Kauderwelsch und ist in einem Schritt lesbar.

18:33 Schützen muss es die Verschlüsselung der Cluster-Datenbank und die Rechteverwaltung — das Objekt selbst schützt gar nichts. Hier stehen die beiden üblichen Wege direkt untereinander. Der erste nimmt einen ganzen Block auf einmal — bequem für eine Handvoll unkritischer Einstellungen. Der zweite holt einen einzelnen Wert aus einem Secret, und diese Ausführlichkeit ist bei Geheimnissen angemessen: Man will genau sehen, welches Geheimnis in welchen Container wandert.

19:01 Beides ist mischbar und wird in der Praxis auch gemischt. Ein Rat, der später Ärger erspart: Halten Sie die Namen der Umgebungswerte gleich mit dem, was Ihre Anwendung erwartet, und dokumentieren Sie sie an einer Stelle. Sonst suchen Sie irgendwann in drei Dateien nach einem Wert, der nirgends ankommt. Vier Vergleichszeilen, und zwei verlangen Aufmerksamkeit. Die zweite ist die Ehrlichkeit von vorhin: kodiert, nicht verschlüsselt.

19:26 Die dritte ist die Konsequenz — Verschlüsselung im Ruhezustand muss am Cluster eingerichtet werden, und in einem verwalteten Cluster sollten Sie nachfragen, ob das geschehen ist. Die vierte Zeile enthält eine Empfehlung, die zu selten befolgt wird: Als Datei eingehängt, ist bei Geheimnissen die bessere Wahl. Der Grund steht unten und ist handfest: Was in der Prozessumgebung steht, landet in Fehlerberichten, Absturzprotokollen und Prozesslisten. Was als Datei liegt, tut das nicht.

19:55 Der erste Punkt ist der, der alles zusammenhält und den Bogen über die ganzen vier vorigen Module spannt: Ein Image durchläuft Test und Produktion unverändert und bleibt damit genau jenes Image, das gescannt, signiert und geprüft wurde. Jeder Neubau für eine andere Stufe würde diese Kette zerreißen. Der zweite ist Alltagsnutzen — ein geänderter Grenzwert braucht keinen Bauvorgang.

20:17 Der dritte ist Sicherheit über die Rechteverwaltung: Wer die Werte lesen darf, ist steuerbar. Und der vierte ist ein Betriebsvorteil, der oft überrascht: Als Datei eingehängte Werte lassen sich im laufenden Betrieb austauschen. Der erste Punkt ist die Fehlvorstellung, die ich am häufigsten korrigieren muss, und sie hat eine harmlose Ursache: Der Inhalt sieht verschlüsselt aus. Ist er nicht.

20:40 Der zweite ist die Empfehlung aus der Tabelle in Negativform — Geheimnisse in der Umgebung wandern in Protokolle und Abstürze. Der dritte ist eine Überraschung im Betrieb, mit der man rechnen muss: Eine geänderte ConfigMap zieht bei Umgebungswerten nicht nach, bei eingehängten Dateien schon. Wer das nicht weiß, ändert einen Wert und wartet vergeblich.

21:00 Und der vierte ist der gefährlichste, weil er so naheliegt: Geheimnisse ins Repository legen, weil das Manifest ohnehin dort liegt. Nein — dafür gibt es verschlüsselte Verfahren.

Bereitschaft prüfen mit Probes

21:11 Jetzt die Fortsetzung eines Themas aus Modul 3. Dort haben wir gelernt: gestartet heißt nicht bereit. In Kubernetes kommt eine dritte Frage hinzu, und damit werden es drei Zustände mit drei völlig verschiedenen Folgen — läuft, bereit und angelaufen. Drei Prüfungen, und der Unterschied liegt nicht in der Frage, sondern in der Folge.

21:32 Die Lebendigkeitsprüfung fragt, ob der Container noch arbeitet; scheitert sie, wird er neu gestartet. Die Bereitschaftsprüfung fragt, ob er Anfragen annehmen kann; scheitert sie, fällt er aus der Verteilung — bekommt also keinen Verkehr mehr, wird aber nicht angetastet. Diese Unterscheidung ist das ganze Kapitel: Neustart gegen Verkehrsentzug. Und die dritte, die Startprüfung, deckt die Anlaufzeit ab und hält die anderen beiden so lange zurück.

21:58 Sie löst ein Problem, das früher mit langen Anfangsverzögerungen behelfsmäßig gelöst wurde. Drei Prüfungen, drei verschiedene Pfade — und genau das ist die Empfehlung dieser Folie. Denn nur mit getrennten Pfaden können Sie unterschiedlich antworten, und darum geht es. Beachten Sie die Zahlen bei der Startprüfung: dreißig Fehlversuche im Zwei-Sekunden-Takt, also bis zu einer Minute Geduld.

22:22 Das klingt großzügig und ist es auch — der Hinweis unten sagt, warum es unbedenklich ist: Diese Prüfung läuft nur einmal, beim Anlauf, und blockiert währenddessen die anderen. Danach ist sie vorbei. Sie können hier also freundlich sein, ohne dass es Sie im Betrieb etwas kostet. Diese Tabelle steht und fällt mit ihrer letzten Spalte — die Folge ist das Unterscheidungsmerkmal.

22:44 Und der Hinweis darunter ist die wichtigste Regel des Kapitels, deshalb sage ich sie langsam: Nur die Bereitschaftsprüfung darf von Abhängigkeiten abhängen. Die anderen nie. Warum, ist schnell erklärt: Wenn Ihre Lebendigkeitsprüfung die Datenbank mitprüft, dann startet Ihr Dienst bei jeder Datenbankstörung neu — und alle anderen Dienste auch, gleichzeitig.

23:05 Aus einer Störung wird eine Neustartwelle. Die Bereitschaftsprüfung hingegen soll genau das: Bei fehlender Datenbank kein Verkehr, aber auch kein Neustart. Warten, nicht zappeln. Die Schritte eins bis drei sind die Regel von der letzten Folie in Handlungsform: eigener Prozess für die Lebendigkeit, Abhängigkeiten für die Bereitschaft, Startprüfung statt langer Anfangsverzögerung.

23:28 Warum die Startprüfung besser ist, lohnt einen Satz: Eine feste Verzögerung wartet immer gleich lang — auch wenn der Dienst nach zwei Sekunden bereit wäre, und zu kurz, wenn er heute länger braucht. Die Startprüfung fragt einfach. Schritt vier ist Kalibrieren mit echten Zahlen. Und Schritt fünf ist der, den fast alle weglassen: einen Fehlschlag künstlich erzeugen und beide Wirkungen beobachten. Eine Prüfung, die nie gescheitert ist, ist unerprobt.

23:54 Das Wort ehrlich ist hier wörtlich gemeint: Der Dienst soll melden, was tatsächlich ist — nicht pauschal in Ordnung, nicht pauschal kaputt. Besetzen Sie die drei Prüfungen so, dass Neustart und Verkehrsentzug getrennt und aus dem richtigen Grund ausgelöst werden. Der Erfolg besteht aus zwei Gegentests: Eine abgeschaltete Datenbank nimmt den Dienst aus der Verteilung, ohne ihn neu zu starten.

24:17 Ein blockierter Prozess wird dagegen neu gestartet. Erst beide zusammen beweisen, dass die Aufgabenteilung sitzt — eine Prüfung allein beweist nichts. Wer schneller fertig ist, misst die Zeit vom Start bis zur ersten angenommenen Anfrage. Der erste Punkt ist die Neustartwelle von vorhin, und er ist der teuerste Fehler in diesem Kapitel — er verwandelt eine überstehbare Störung in einen Ausfall.

24:40 Der zweite ist die überholte Gewohnheit: lange Anfangsverzögerung, wo eine Startprüfung gehört. Der dritte ist der bequeme: derselbe Pfad für alle drei Prüfungen. Damit haben Sie formal Prüfungen und praktisch keine Unterscheidung — bei fehlender Datenbank startet der Dienst neu, obwohl er nur warten sollte. Und der vierte ist eine Kalibrierungsfrage mit unangenehmer Wirkung: Ein zu knapper Takt macht aus jedem kurzen Ausschlag einen Neustart, und der kommt dann immer zur Spitzenlast.

Ressourcen und QoS-Klassen

25:08 Jetzt zu dem Teil, der später die Rechnung und die Stabilität bestimmt — und der im Alltag am häufigsten geraten statt gemessen wird. Was ein Pod verlangt, entscheidet, wo er landet und wann er weichen muss. Zwei Werte, zwei völlig verschiedene Bedeutungen — und die Verwechslung ist der Kern aller Probleme hier. Eine Anforderung ist die Menge, die der Planer freihalten muss; sie entscheidet über die Knotenwahl, wirkt also beim Platzieren. Denken Sie an eine Tischreservierung im Restaurant.

25:37 Eine Grenze ist das Maximum, das der Container tatsächlich nutzen darf — die Größe des Tellers, den Sie leeren dürfen. Und aus dem Verhältnis beider ergibt sich die Güteklasse, QoS genannt. Die bestimmt, welcher Pod bei Knappheit auf dem Knoten zuerst weichen muss. Reservieren Sie zu wenig, sitzen Sie beim Andrang draußen.

25:57 Sechs Zeilen mit einer beabsichtigten Asymmetrie, und die ist der Inhalt der Folie. Bei der Rechenzeit steht die Grenze über der Anforderung — der Container darf also bei Bedarf mehr nutzen, wenn der Knoten es hergibt. Beim Speicher stehen beide Werte gleich, und der Hinweis unten sagt, was das bedeutet: Der Container kann nie über seine Anforderung hinauswachsen. Warum diese Ungleichbehandlung?

26:21 Weil Rechenzeit teilbar ist und Speicher nicht. Zu wenig Rechenzeit macht langsam, zu wenig Speicher beendet den Prozess. Für Speicher lohnt es also, ehrlich zu planen statt zu hoffen — und genau das erzwingt diese Schreibweise. Drei Klassen, und die letzte Spalte ist die Rangfolge auf dem Rettungsboot. Der Hinweis unten ist die wichtigste Information: Die Klasse wird berechnet, nicht gesetzt.

26:45 Es gibt kein Feld dafür — sie ergibt sich aus den Werten aller Container des Pods. Wer eine Klasse haben will, setzt Werte. Guaranteed verlangt, dass Grenze und Anforderung überall deckungsgleich sind, und dafür weicht der Pod zuletzt. Burstable ist der Alltagsfall und ein guter Kompromiss. Und die dritte, ohne jede Angabe, weicht zuerst — sie ist die Voreinstellung, wenn Sie nichts eintragen. Ihre unbedachten Pods sind also genau die, die zuerst gehen.

27:14 Die ersten zwei Punkte sind die beiden Ausfälle: Ohne Anforderung plant der Planer blind und überbucht den Knoten. Ohne Grenze kann ein einzelner Container den Knoten leerräumen — und nimmt dabei fremde Pods mit, was Ihre Kollegen zu Recht verärgert. Die letzten zwei Punkte sind der Unterschied, den Sie sich merken sollten, weil er die Fehlersuche steuert: Eine Speichergrenze wird hart durchgesetzt, Überschreiten beendet den Prozess sofort.

27:40 Eine Rechenzeitgrenze bremst nur — der Dienst wird langsam, nicht beendet. Zwei völlig verschiedene Fehlerbilder also. Plötzlich weg heißt Speicher. Unerklärlich langsam heißt Rechenzeit. Der erste Punkt ist der unangenehmste, weil er nicht als Fehler auftritt: Eine zu knappe Rechenzeitgrenze macht den Dienst langsam, und niemand sucht dort.

28:00 Die Antwortzeiten steigen, alle vermuten die Datenbank. Der zweite ist eine halbe Konfiguration mit blinder Planung. Der dritte ist der teure: Beim Speicher großzügig aufzurunden fühlt sich sicher an und verschenkt rechnerisch Knotenkapazität — bei hundert Pods sind das echte Server. Und der vierte ist die Erwartung aus der Tabelle: Die Güteklasse ist kein Feld, das man einträgt. Wer sie sucht, sucht vergeblich, und wer sie will, setzt Werte.

Fehlersuche mit kubectl

28:27 Zum Abschluss das Kapitel, das bewusst am Ende steht: Fehlersuche. Erst jetzt sind alle Begriffe da, die in den Meldungen vorkommen — Pods, Auswahl, Endpunkte, Prüfungen, Grenzen. Vier Befehle klären neunzig Prozent der Fälle. Fehlersuche im Cluster heißt, den Unterschied zwischen Soll und Ist zu erklären — das ist der Satz aus Kapitel 1, jetzt als Arbeitsanweisung.

28:50 Nicht „was ist kaputt", sondern „warum kommt das System nicht an sein Ziel". Dafür gibt es vier Zugänge in einer bewährten Reihenfolge: die Beschreibung eines Objekts samt seiner Ereignisse, die Ausgaben des Prozesses, ein Blick in den laufenden Container und die Ereignisliste des Namensraums. Die Reihenfolge ist nicht beliebig, sie geht von außen nach innen und von billig nach teuer.

29:12 Wer sie einhält, findet die meisten Ursachen, bevor er überhaupt in einen Container hineinsieht. Diese vier Befehle sollten Sie im Schlaf tippen können. Der erste ist der, mit dem fast jede Diagnose beginnt, denn er zeigt am Ende die Ereignisse — und dort steht die Ursache oft im Klartext. Der zweite hat einen Zusatz, auf den ich besonders hinweisen will, weil er der wertvollste in dieser Sammlung ist: Er zeigt die Ausgaben des abgestürzten Vorgängers.

29:38 Bei einer Neustartschleife sind die Ausgaben des laufenden Containers nämlich leer oder harmlos — der Grund steckt im Vorgänger, der gerade gestorben ist. Der dritte geht hinein, der vierte zeigt die Ereignisse des ganzen Namensraums nach Zeit sortiert. Diese Tabelle ist die praktischste Folie des Moduls — schreiben Sie sie ab. Fünf typische Symptome und jeweils der Griff, der am schnellsten zur Ursache führt.

30:02 Beachten Sie, wie oft frühere Kapitel darin auftauchen: Ausstehende Pods führen zu den Anforderungen aus Kapitel 7. Ein Dienst, der nicht antwortet, führt zu Endpunkten und Labels aus Kapitel 3 und 4. Ein sofort beendeter Prozess führt zur Speichergrenze. Und der Hinweis unten schließt den Bogen zu Modul 4: Bei einem gehärteten Image ohne Shell hilft der Blick hinein nicht.

30:25 Dann brauchen Sie einen Nebencontainer zum Untersuchen — der Preis der Härtung, bewusst bezahlt. Fünf Schritte, und ihr roter Faden ist Disziplin gegen den Reflex. Der Reflex sagt: etwas ändern und schauen, ob es hilft. Das Vorgehen sagt: ablesen, lesen, prüfen — und erst dann hineingehen. Schritt zwei verdient Nachdruck, weil er so oft übersprungen wird: Die Ereignisse nennen die Ursache meist im Klartext, in ganzen Sätzen. Man muss sie nur lesen.

30:53 Und Schritt fünf ist die Regel des ganzen Moduls, deshalb steht sie auch im Hinweis: Beheben Sie die Ursache im Manifest, nicht am laufenden Objekt. Eine Änderung am Ist-Zustand hält keine Reglerschleife aus — beim nächsten Ausrollen ist sie weg. Diese Übung ist die Abschlussprüfung des Moduls, und ihr Lernziel ist ausdrücklich eine Haltung: die Ursache benennen, statt Änderungen zu probieren.

31:17 Für drei vorbereitete Fehlerbilder soll jeweils die Ursache benannt und im Manifest behoben sein — und der Dienst soll laufen, ohne dass am laufenden Objekt gepfuscht wurde. Die drei Fehler sind mit Absicht gewählt und decken die Modulkette ab: ein falscher Digest, eine zu knappe Speichergrenze und eine falsche Label-Auswahl.

31:35 Wer schneller fertig ist, schreibt zu jedem Fehlerbild die Meldung auf, die es verraten hat. Diese Notizen sind später mehr wert als die Lösung. Der erste Punkt ist der Reflex aus dem Vorgehen, und seine Folge ist besonders tückisch: Am laufenden Objekt geändert, funktioniert es — bis zum nächsten Ausrollen. Dann kommt der Fehler zurück, und niemand versteht, warum. Der zweite ist das Überlesen der Ereignisse, die die Antwort meist mitliefern.

32:01 Der dritte ist der Zusatz aus der Code-Folie, den man vergisst, wenn man ihn braucht: Nach einem Neustart sind die Ausgaben des laufenden Containers wertlos. Und der vierte ist eine Frist, die man kennen sollte: Ereignisse verfallen nach kurzer Zeit. Wer erst am Montag nachsieht, findet vom Freitagabend nichts mehr — dafür braucht es eine Protokollsammlung.

Was ab hier trägt

32:22 Vier Sätze aus diesem Modul, und sie tragen die zweite Seminarhälfte. Beschrieben wird ein Soll-Zustand, und Regler stellen ihn her — nicht Befehle. Labels sind der Klebstoff; Dienste und Regler finden ihre Pods nur darüber, und das erklärt die halbe Fehlersuche. Läuft, bereit und angelaufen sind drei Fragen mit drei verschiedenen Folgen, und wer sie vermischt, erzeugt Neustartwellen.

32:45 Anforderungen und Grenzen entscheiden über Knotenwahl, Kosten und Stabilität. Im nächsten Modul geht es darum, wie aus diesen Handgriffen ein produktiver Betrieb wird — Vorlagen mit Helm, Auslieferung über Git, und Skalierung, die von selbst reagiert.