#99: Cluster-Architektur mit Kubernetes: self-hosted, managed oder gar nicht?

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:
podcast@inwt-statistics.de