Kubernetes

Stell dir vor, du hast 1 Container (Lunchbox). Den trägst du leicht selbst. Stell dir vor, du hast 10.000 Container (einen Frachtschiff-Hafen). Du brauchst einen Kranführer, der den Überblick behält. "Container A muss auf Schiff B. Container C ist abgestürzt, wir brauchen einen neuen." Kubernetes (K8s) ist dieser Kranführer für Software-Container. Es wurde von Google erfunden (die starten Milliarden Container pro Woche) und steuert riesige Server-Flotten automatisch.

Merksatz: Ein Open-Source-System zur Automatisierung der Bereitstellung, Skalierung und Verwaltung von Container-Anwendungen.

Du sagst Kubernetes nicht: "Starte Server X". Du gibst ihm einen Wunschzettel (YAML-Datei): "Ich hätte gerne immer 3 Kopien meiner Webseite. Sie sollen auf Servern mit viel RAM laufen." Kubernetes macht den Rest:

Es sucht freie Server.
Es startet die 3 Kopien.
Wenn eine abstürzt, startet es sofort eine neue (Self-Healing).

Sobald mehrere Teams und Services im Cluster laufen, begrenzt eine Network Policy (Kubernetes), welche Pods miteinander sprechen dürfen. Ohne solche Regeln ist ein Cluster zwar funktional, aber schwerer sauber zu segmentieren.

Praxisroutine

In der Praxis lernst du Kubernetes, indem du mit einem kleinen, kontrollierten Beispiel beginnst. Baue zuerst einen Minimalfall, prüfe das Ergebnis, veraendere genau eine Sache und beobachte, was sich ändert. Notiere dir Eingabe, Aktion, Ausgabe und typischen Fehler.

Übung: Erstelle ein Beispiel aus deinem Alltag, fuehre den Ablauf gedanklich Schritt für Schritt durch und markiere die Stelle, an der du Feedback oder ein Log brauchst. Wenn du diese Stelle benennen kannst, verstehst du den Begriff praktisch.

1. Pods

Kubernetes kennt keine "Container". Die kleinste Einheit ist ein Pod. Ein Pod ist wie eine Erbsenschote: Meist ist nur 1 Erbse (Container) drin, manchmal aber auch zwei, die sich eng umarmen (z. B. ein Log-Collector-Container direkt neben der App).

2. Service Discovery

Wenn Pod A mit Pod B reden will, ist das schwer, weil Pods ständig sterben und neu starten (neue IP). Kubernetes bietet Services: Eine stabile Telefonnummer für eine Gruppe von Pods. "Ruf Service B an", und Kubernetes leitet dich zu einem der gerade lebenden Pods weiter.

Technische Einordnung im System

Technisch ist Kubernetes nicht isoliert. Es wirkt mit Nachbarbegriffen zusammen, hat Voraussetzungen und erzeugt Folgen. Für ein robustes Verständnis prüfst du drei Fragen: Welche Daten oder Bedingungen braucht dieser Schritt? Welche Ausgabe oder Wirkung entsteht? Was passiert bei falschen, fehlenden oder zu großen Eingaben?

Diese Sicht ist wichtig, weil echte Systeme selten am Hauptpfad scheitern. Sie scheitern an Randfällen, Berechtigungen, Zeitpunkten, Formaten, Reihenfolgen oder stillen Annahmen.

1. Control Plane Architecture (etcd)

K8s ist ein gewaltiges State-Machine Cluster. In der Control Plane (dem Hirn von K8s) liegt die Quelle der Wahrheit: etcd. Ein hochverfügbarer, verteilter Key-Value Store (basierend auf dem Raft-Konsensalgorithmus). Dort liegt der YAML-Wunsch. Der Rest von K8s besteht aus endlosen "Controlern" (Scheduler, ReplicaSet-Controller). Diese Controller laufen in der Schleife und fragen sich sekündlich: "Was ist der Ist-Zustand des RZs? Und was ist der Soll-Zustand in etcd?". Stimmen sie nicht überein (eine Node brannte ab, ReplicaCount ging von 3 auf 2 runter), greift der Controller ein und startet einen Pod. Das gesamte System reagiert asynchron auf State-Drifts in etcd.

2. CNI und Kube-Proxy (Networking)

Wie spricht Pod A auf Server 1 mit Pod B auf Server 2? Mit rohem Docker ist das ein Albtraum. Kubernetes nutzt CNI (Container Network Interface) Plugins (Calico, Cilium). Diese erzeugen ein "Overlay Network" (Flannel). Jeder Pod erhält intern die Illusion eines gigantischen, flachen L2-LANs, auch wenn die physischen Server im Rechenzentrum dutzende Router dazwischen haben. Der kube-proxy ist zudem ein winziger Daemon auf jeder physischen Node, welcher rohe Linux iptables (oder eBPF) manipuliert. Er ist der Grund, warum ein K8s-Service IPX an tausende Pods loadbalancen kann, ohne jemals einen traditionellen Hardware-Router der Telekom zu benötigen.

3. eBPF und Cilium (Die nächste Generation K8s)

kube-proxy und rohe iptables stoßen bei massiver Skalierung (100.000 Services) extrem an Leistungsgrenzen (Lineare Suchzeiten für Routing). Die Lösung ist eBPF (Extended Berkeley Packet Filter). Es erlaubt das Ausführen von blitzschnellem C-Bytecode direkt im Linux-Kernel-Space, ohne das Kernel-Modul zu modifizieren. K8s CNI Plugins wie Cilium nutzen eBPF. Damit greifen sie Traffic, Security-Policys und Observability gnadenlos tief "im Hardware-Kern" ab. Latenzen stürzen ab, und Container in Kubernetes können auf Netzwerkebene nahezu Bare-Metal Geschwindigkeiten erreichen.