#99: Cluster-Architektur mit Kubernetes: self-hosted, managed oder gar nicht?
Notes de l’épisode
Sebastian und Michelle sprechen in dieser Folge über Cluster-Architektur mit Kubernetes: was das Tool leistet, welche Betriebsvarianten es gibt und für wen sich der Einsatz überhaupt rechnet. Ausgangspunkt sind die typischen Gründe für k8s – Skalierung, Ausfallsicherheit durch Health Checks und Rolling Updates sowie Infrastructure as Code. Danach geht es um die Frage self-hosted (k8s, k3s) oder managed (AWS, GCP, Azure) und um den Unterschied zwischen plain Kubernetes und Red Hat OpenShift. Ein zweiter Schwerpunkt liegt auf dem Zuschnitt der Umgebung: wie viele Cluster sinnvoll sind (pro Stage, pro Produkt) und wie innerhalb eines Clusters mit Namespaces und Network Policies getrennt wird. Zum Schluss diskutieren die beiden Alternativen ohne Kubernetes und die Voraussetzungen, die im Team erfüllt sein müssen.
**Zusammenfassung**
- Kubernetes verwaltet containerisierte Anwendungen und arbeitet mit Docker zusammen – die beiden Tools sind keine Konkurrenz
- Hauptargumente für k8s: Skalierung und Ressourcennutzung, Verfügbarkeit über Health Checks (Liveness, Readiness), Rolling Updates und Rollbacks, Konfiguration als Code in YAML
- Self-hosted (k8s, k3s) bedeutet eigene Versions-Updates und Skills in Systemadministration und Provisionierung; Managed Cluster kosten mehr, reduzieren aber Maintenance und erhöhen die Verfügbarkeitsgarantie
- OpenShift bringt eigene CLI, UI, Monitoring und Enterprise Support mit (Open-Source-Variante: OKD), plain k8s läuft dafür auf schlankerer Hardware
- Anzahl der Cluster: mindestens eine Trennung von DEV und PRD, größere Organisationen provisionieren pro Produkt x Stage – jedes zusätzliche Cluster bedeutet mehr Aufwand für Updates, Monitoring und Provisionierung
- Trennung nach Produkt statt nach Team, weil Zuständigkeiten sich ändern; Namespaces sind die leichtgewichtige Alternative zur vollen Isolation
- Network Policies funktionieren wie Firewall-Regeln für Pods (Ziel/Quelle, ingress/egress); standardmäßig ist alles erlaubt, sobald ein Pod eine Policy hat, gilt für ihn Deny-All – ein Deny-All pro Namespace ist deshalb Pflicht
- Alternative für kleine Setups: ein oder zwei VMs mit mehreren Instanzen hinter einem Loadbalancer, Rolling Updates per Skript; entscheidend sind Produkt, Verfügbarkeitsanspruch und vorhandenes Know-how
**Links**
- Episode #14: Kubernetes https://inwt.podbean.com/e/14-kubernetes/
- Training Course by The Linux Foundation: Introduction to Kubernetes (LFS158) https://training.linuxfoundation.org/training/introduction-to-kubernetes/
- Kubernetes: https://kubernetes.io/
- k3s: https://k3s.io/
📬 Fragen, Feedback oder Themenwünsche?
Schreibt uns gern an: [email protected]