# Kubernetes (K8s): Die Architektur der Container-Orchestrierung

TL;DR / Management Summary Während Docker einen einzelnen Host verwaltet, verwaltet Kubernetes ein ganzes Rechenzentrum voller Hosts. Es ist das “Betriebssystem des RZs”. Die Architektur basiert auf der Trennung von Control Plane (das Gehirn) und Worker Nodes (die Muskeln). Ein Senior Admin betreibt Kubernetes-Cluster meist virtualisiert auf Proxmox (Artikel 678), um von der Hardware-Abstraktion und den einfachen Snapshots der Master-Knoten zu profitieren.

# 1. Die Control Plane (Das Gehirn)

Die Intelligenz des Clusters.

Besteht aus mehreren kritischen Komponenten:

  1. API Server (kube-apiserver): Die zentrale Drehscheibe. Alles kommuniziert mit ihm (Admin, Nodes, Controller).
  2. etcd: Die Datenbank. Speichert den gesamten Zustand des Clusters (Soll vs. Ist). Kritisch: Muss hochverfügbar sein!
  3. Scheduler (kube-scheduler): Entscheidet, welche VM (Node) genug Platz für einen neuen Pod hat.
  4. Controller Manager: Sorgt dafür, dass der Soll-Zustand eingehalten wird (z.B. “Immer 3 Kopien von Webserver A”).

# 2. Worker Nodes (Die Muskeln)

Wo die Workloads laufen.

Jeder Knoten im Cluster führt die eigentlichen Container aus:

  1. Kubelet: Der Agent auf dem Host. Er empfängt Befehle von der Control Plane und startet die Container.
  2. Kube-Proxy: Verwaltet das Netzwerk (Routing) zu den Services.
  3. Container Runtime: Meist containerd oder CRI-O. (Führt die Images aus).

# 3. Deep Dive: etcd – Die Quelle der Wahrheit

Das wichtigste Element.

etcd ist ein verteilter Key-Value Store.

# 4. Day-2 Operations: Hochverfügbarkeit (HA)

Kein Single Point of Failure.

Ein Produktions-Cluster benötigt:

# 5. Troubleshooting & “War Stories”

Wenn das Gehirn die Muskeln nicht erreicht.

# Top 3 Fehlerbilder

  1. Symptom: kubectl Befehle schlagen fehl (“Connection Refused”).

    • Ursache: Der API-Server Prozess ist abgestürzt oder das Zertifikat ist abgelaufen.
    • Lösung: journalctl -u kube-apiserver prüfen.

  2. Symptom: Worker Node steht auf Status NotReady.

    • Ursache: Das Kubelet kann den Master nicht erreichen oder der RAM des Hosts ist voll.
    • Fix: systemctl restart kubelet.

  3. Symptom: Änderungen in der GUI werden nicht übernommen.

    • Ursache: Der etcd-Cluster hat kein Quorum mehr (z.B. 2 von 3 Mastern offline).

# “War Story”: Der “Zombie” Cluster

Ein Admin löschte einen der drei Master-Knoten in Proxmox, um RAM zu sparen. Das Ereignis: Der Cluster lief erst weiter. Die Katastrophe: Nach einem geplanten Update der anderen zwei Master kam der Cluster nicht mehr hoch. Die Ursache: etcd benötigt eine Mehrheit. Bei 3 Knoten sind das 2. Da einer gelöscht war und ein zweiter während des Updates neustartete, war nur noch 1 Knoten online (keine Mehrheit). etcd schaltete sich in den Read-Only Modus, der API-Server startete nicht mehr. Lehre: Halten Sie sich bei K8s-Mastern strikt an die ungeraden Zahlen (3, 5, 7) und löschen Sie niemals “einfach mal so” einen Knoten.

# 6. Monitoring & Reporting

Cluster-Health.

# Kubernetes Dashboard

Nutzen Sie das offizielle Dashboard oder Lens, um den Cluster zu visualisieren.

# 7. Fazit & Empfehlung

Kubernetes ist komplex, bietet aber unerreichte Stabilität für Apps.

# Anhang: Cheatsheet (Core Components)

Komponente Port Zweck
API Server 6443 Die Schnittstelle
etcd 2379/2380 Die Datenbank
Kubelet 10250 Agent am Host
NodePort 30000-32767 Externer Zugriff

# Referenzen