Story

Kubernetes: vom Einzelcluster zur Plattform.

Eine Folie kann manchmal mehr erklären als ein ganzer Absatz: Kubernetes ist nicht nur ein Cluster, sondern kann ein Betriebsmodell werden, das vom Homelab bis zur Multi-Cluster-Plattform trägt.

Ausgangspunkt ist die Präsentation Kubernetes Infrastructure at CSCS von Dino Conciatore und Elia Oggian, CSCS, ETH Zürich.

Einordnung

Mich interessiert an Kubernetes nicht der Hype, sondern die Ordnung dahinter.

Wer Kubernetes nur als Sammlung von YAML-Dateien betrachtet, verpasst den eigentlichen Nutzen. Spannend wird es, wenn Infrastruktur, Deployments, Netzwerk, Sicherheit, DNS, Zertifikate, Secrets und Observability als wiederholbare Plattform gedacht werden.

Genau das zeigt das Beispiel des CSCS, des Swiss National Supercomputing Centre der ETH Zürich. Dort werden Kubernetes-Cluster nicht einzeln von Hand zusammengeklickt, sondern mit Infrastructure as Code, GitOps und klaren Betriebsbausteinen aufgebaut. Die Technologie ist gross, aber die Idee ist auch für kleinere Umgebungen wertvoll: beschreiben, versionieren, prüfen, automatisieren.

Infrastructure as Code

Cluster entstehen aus Beschreibung, nicht aus Klickarbeit.

In der CSCS-Architektur werden Cluster über Git und Infrastructure as Code beschrieben. Terraform oder OpenTofu kann die Zielumgebung vorbereiten, Ansible kann RKE2 installieren, Rancher kann Cluster verwalten, und ArgoCD kann Anwendungen nach dem GitOps-Prinzip synchron halten.

Bemerkenswert ist die Spannweite: Harvester beziehungsweise SUSE Virtualization, VMware, Bare Metal, MAAS und sogar CSCS Alps als HPC-Umgebung werden in ein gemeinsames Plattformdenken gebracht. Das ist der Maximalausbau. Im Kleinen beginnt dieselbe Idee mit einem einzelnen Server, einem PC, einem Homelab oder einer Private Cloud.

Folie Infrastructure as Code mit Terraform, Ansible, Rancher, Harvester, MAAS und CSCS Alps — Auszug aus der Präsentation Kubernetes Infrastructure at CSCS, CSCS / ETH Zürich: Cluster Provisioning mit Terraform, Ansible, Rancher, Harvester, MAAS und HPC-Nodes.

GitOps

Git wird zur sichtbaren Wahrheit des Betriebs.

GitOps mit ArgoCD macht den Sollzustand sichtbar. Anwendungen, Helm-Charts, Kubernetes-Manifeste, ApplicationSets und gemeinsame Services liegen in Repositories. ArgoCD vergleicht den Zustand im Cluster mit dem gewünschten Zustand in Git und synchronisiert Abweichungen kontrolliert.

Das ist für Teams wichtig, weil Entscheidungen nachvollziehbar werden: Was wurde geändert? Warum wurde es geändert? Wer hat es geprüft? Genau hier verbinden sich Kubernetes, CI/CD, GitLab, ArgoCD, Helm und Betriebsdisziplin zu einem wartbaren Modell.

Folie GitOps with ArgoCD mit Git-Repositories, ApplicationSets und Kubernetes-Clustern — Auszug aus der CSCS/ETH-Zürich-Präsentation: GitOps mit ArgoCD, ApplicationSets, Helm oder Kubernetes-Manifests über mehrere Cluster hinweg.

Betrieb

Eine Plattform besteht aus wiederkehrenden Bausteinen.

Ein Cluster allein ist noch keine Plattform. Erst mit Netzwerk, Storage, Ingress, Zertifikaten, DNS, Secrets, Monitoring, Logging und klarer Verantwortung entsteht ein System, das produktiv betrieben werden kann.

Die Präsentation nennt Bausteine wie Cilium, eBPF, Hubble, CephFS, Ceph RBD, Istio, Nginx, MetalLB, External Secrets, Vault, cert-manager, external-dns, Filebeat und Metricbeat. Solche Namen sind nicht Dekoration. Sie zeigen, dass Plattformarbeit immer aus Architektur, Sicherheit, Automatisierung und Betrieb besteht.

Folie Kubernetes cluster common features mit Cilium, Hubble, MetalLB, External Secrets und Observability — Auszug aus der CSCS/ETH-Zürich-Präsentation: gemeinsame Kubernetes-Services für Netzwerk, Ingress, Secrets, Zertifikate, DNS und Observability.

Meine Lesart

Die gleiche Denkweise hilft auch in kleineren Projekten.

Nicht jede Firma braucht eine CSCS-Plattform. Aber viele Firmen brauchen die gleichen Grundsätze: reproduzierbare Infrastruktur, nachvollziehbare Änderungen, klare Trennung von Umgebungen, saubere Schnittstellen, automatisierte Deployments und Observability, bevor es brennt.

Darum erzähle ich Kubernetes gerne nicht als Produkt, sondern als Arbeitsweise. Eine Anwendung kann auf einem PC, einem einzelnen Server, in einer Public Cloud, in einer Private Cloud oder in einem eigenen Rechenzentrum laufen. Wenn die Architektur stimmt, bleibt sie beweglich: von klein nach gross, von Cloud A nach Cloud B oder zurück auf eigene Hardware.

Mehr Grundlagen dazu stehen in den Themen zu Kubernetes, Terraform, Ansible und Infrastructure as Code.

Quellen und Hinweise

Die Folienbilder sind als Auszüge aus der genannten CSCS/ETH-Zürich- Präsentation gekennzeichnet.