Kubernetes-Grundlagen: Architektur und Denkweise

Kubernetes ist die verbreitetste Plattform zum Betreiben von Containern in größerem Maßstab. Es nimmt eine Beschreibung des gewünschten Zustands entgegen und sorgt laufend dafür, dass die Wirklichkeit dazu passt. Dieser Artikel erklärt die Architektur und die Denkweise – die Details der einzelnen Objekte bauen darauf auf.

Der zentrale Gedanke: Sollzustand statt Befehle

Klassische Systemadministration arbeitet mit Befehlen: „Starte diesen Dienst“, „Kopiere diese Datei“. Kubernetes arbeitet mit Beschreibungen: „Es sollen drei Instanzen dieser Anwendung laufen, jede mit 512 MB Speicher und dieser Konfiguration.“ Ein Regelkreis vergleicht laufend Soll und Ist und gleicht Unterschiede aus.

# Sollzustand beschreiben
apiVersion: apps/v1
kind: Deployment
metadata:
  name: webapp
spec:
  replicas: 3                    # Soll: 3 Instanzen
  selector:
    matchLabels: {app: webapp}
  template:
    metadata:
      labels: {app: webapp}
    spec:
      containers:
        - name: webapp
          image: registry.example.org/webapp:1.4.2
          ports: [{containerPort: 8080}]
          resources:
            requests: {memory: "256Mi", cpu: "250m"}
            limits:   {memory: "512Mi", cpu: "1000m"}

# Anwenden und beobachten
kubectl apply -f webapp.yaml
kubectl get deployments
kubectl get pods -o wide

Der wichtige Unterschied: Fällt ein Pod aus, startet Kubernetes einen neuen – nicht weil es befohlen wurde, sondern weil die Beschreibung drei Instanzen fordert.

Die Architektur

Control Plane (Steuerungsebene)

kube-apiserver: Die einzige Schnittstelle zum Cluster. Jede Änderung läuft über ihn – kubectl, Controller und Operatoren gleichermaßen. Er prüft Rechte, validiert Objekte und schreibt den Zustand in die Datenbank.
etcd: Der verteilte Schlüssel-Wert-Speicher mit dem gesamten Zustand des Clusters. Er ist die kritische Komponente: Geht etcd verloren, ist das Cluster verloren. Sicherungen davon sind Pflicht.
kube-scheduler: Entscheidet, auf welchem Knoten ein neuer Pod laufen soll – unter Berücksichtigung von Ressourcen, Verteilungsregeln, Knotenbindungen und Rangfolgen.
kube-controller-manager: Beherbergt viele kleine Regelkreise – einer kümmert sich um die Replikatzahl, einer um Knotenausfälle, einer um Konten, einer um Speicheranforderungen. Jeder Controller beobachtet seinen Bereich und gleicht Abweichungen aus.

Arbeitsknoten

kubelet: Der Agent auf jedem Knoten. Er nimmt die zugewiesenen Pods an, startet und überwacht die Container, meldet Zustand und Ressourcenverbrauch.
Container-Laufzeit: Kümmert sich um die tatsächliche Ausführung – heute meist containerd oder CRI-O. Docker wird über das CRI-Interface nicht mehr direkt verwendet.
kube-proxy: Setzt die Netzwerkregeln um, die eine virtuelle Adresse (Service) auf die dahinterliegenden Pods abbildet – oft über iptables oder IPVS; manche Umgebungen ersetzen ihn durch eBPF-Lösungen.

# Cluster-Uebersicht
kubectl cluster-info
kubectl get nodes -o wide
kubectl get componentstatuses      # aelter, show deprecation
kubectl api-resources              # alle verfuegbaren Objekttypen
kubectl get --raw='/readyz?verbose'

Die wichtigsten Objekte und ihre Rollen

Pod: Kleinste Einheit. Enthält einen oder mehrere Container, die sich Netzwerk und Speicher teilen. Pods sind kurzlebig und werden nicht repariert, sondern ersetzt.
Deployment: Verwaltet zustandslose Anwendungen. Kümmert sich um Replikate und um schrittweise Aktualisierungen mit Rollback.
StatefulSet: Für zustandsbehaftete Anwendungen. Jeder Pod bekommt einen stabilen Namen und eigenen Speicher – die Voraussetzung für Datenbanken und Cluster-Dienste.
DaemonSet: Sorgt dafür, dass auf jedem Knoten ein Pod läuft – für Protokollsammler, Monitoring-Agenten, Netzwerkkomponenten.
Service: Eine feste virtuelle Adresse für eine Gruppe von Pods. Notwendig, weil Pod-Adressen sich bei jedem Neustart ändern.
Ingress / Gateway API: Zugang von außen mit Regeln nach Hostname und Pfad.
ConfigMap und Secret: Konfiguration und Zugangsdaten getrennt vom Image.
Namespace: Logische Aufteilung des Clusters – für Teams, Umgebungen und Rechtevergabe.

Die Denkweise übernehmen

Alles ist deklarativ. Beschreibungen liegen in Versionsverwaltung, nicht Befehle in einer Sitzung. Damit ist jede Änderung nachvollziehbar und wiederholbar.
Anwendungen müssen zustandslos denken. Lokaler Speicher im Container verschwindet. Sitzungen gehören in einen gemeinsamen Speicher, nicht in den Prozess.
Fehler sind der Normalfall. Pods starten neu, Knoten fallen aus. Anwendungen müssen damit umgehen können – schneller Start, Robustheit gegen Verbindungsabbrüche, Wiederholbarkeit.
Ressourcen immer angeben. Ohne Anforderungen kann der Scheduler nicht planen. Ohne Grenzen kann ein Pod den Knoten lahmlegen.
Prüfungen definieren. Liveness und Readiness sagen dem Cluster, wann ein Container neu zu starten und wann er in die Lastverteilung aufzunehmen ist.
Rechte eng fassen. RBAC je Namespace, keine Cluster-weiten Rechte ohne Grund, keine Standardkonten mit zu vielen Rechten.

Wann Kubernetes passt – und wann nicht

Geeignet: viele Dienste, die sich unabhängig voneinander ausrollen lassen; schwankende Last; mehrere Teams auf gemeinsamer Infrastruktur; Anforderung an Ausfallsicherheit über mehrere Knoten; reproduzierbare Umgebungen von Entwicklung bis Produktion.

Weniger geeignet: eine einzelne Anwendung, die monolithisch wächst; sehr kleine Teams ohne Betriebserfahrung; zustandsbehaftete Anwendungen, die sich nicht verändern lassen. Der Betriebsaufwand ist erheblich – wer ihn nicht dauerhaft tragen kann, ist mit einer virtuellen Maschine und Docker Compose besser bedient. Ein Cluster ist kein Selbstzweck.

Verwandte Grundlagen: Kubernetes, Pod, Service Mesh, kubectl-Befehle.

Cloud & Container