Kubernetes StatefulSets — Stabile Identität für zustandsbehaftete Workloads

In diesem 100-Minuten-Modul schließt ihr die Lücke zwischen zustandslosen und zustandsbehafteten Workloads. Der Einstieg ist die zentrale Abgrenzung: Ein ReplicaSet/ Deployment behandelt seine Pods als austauschbar – generierte Namen wie web-7d9f8c9-x2k4p, keine garantierte Start-Reihenfolge, kein stabiler Speicher-Zuordnungspunkt. Ein StatefulSet gibt genau das auf, was Deployments schnell macht, und tauscht es gegen stabile, geordnete Identität: Pods heißen <name>-0, <name>-1, … und behalten diesen Namen über jeden Neustart hinweg. Im ersten Hands-on setzt ihr volumeClaimTemplates ein: Statt eine gemeinsame PersistentVolumeClaim für alle Replicas zu teilen – aus dem Modul Storage bereits als Engpass bekannt, ReadWriteOnce erlaubt ohnehin meist nur einem Pod gleichzeitig Schreibzugriff – provisioniert Kubernetes für jede Replica automatisch eine eigene PVC nach dem Muster <template>-<statefulset>-<ordinal>. Danach ordnet ihr podManagementPolicy ein – OrderedReady (Default, strikt sequentiell, jeder Pod muss erst bereit sein, bevor der nächste startet) gegen Parallel (alle Replicas gleichzeitig) – und seht, wie dieselbe Reihenfolge beim Scale-down rückwärts gilt. Im zweiten Hands-on koppelt ihr das StatefulSet an einen Headless Service (clusterIP: None, aus dem Modul Networking Vertiefung als Konzept bereits bekannt) und löst live einen stabilen Pro-Pod-DNS-Namen auf wie pod-0.<service>.<namespace>.svc.cluster.local – der Baustein, den verteilte Systeme für Peer-Discovery brauchen. Voraussetzung sind die Module “Kubernetes Storage” (PersistentVolume/ PersistentVolumeClaim/StorageClass) und “Kubernetes Networking Vertiefung” (Headless Services, SRV-Records) – beide werden hier vorausgesetzt und nicht wiederholt. Die Session läuft weiterhin vollständig lokal über Minikube oder kind, ohne Cloud-Account und ohne Kostenwirkung.