ReplicaSet (K8s)

Du siehst sie, wenn du kubectl get rs tippst. Name: my-app-5f88d7b9 (Der Hash am Ende kommt vom Pod Template). Wenn du ein Deployment updatest (neues Image v2), erstellt K8s ein neues ReplicaSet für v2 und scalt das alte ReplicaSet (v1) langsam auf 0 runter. So funktioniert Rolling Update.

1. Label Selector Magic

Woher weiß das RS, welche Pods ihm gehören? Labels. selector: app=frontend. Es zählt alle Pods im Cluster (Namespace), die dieses Label haben. Gefahr: Wenn du manuell einen Pod startest mit app=frontend, denkt das RS "Huch, einer zu viel!" und tötet ihn (oder einen anderen). ReplicaSets "adoptieren" verwaiste Pods, wenn die Labels passen.

2. HPA (Horizontal Pod Autoscaler)

Das RS hat eine feste Zahl (replicas: 3). Der HPA ist der Chef vom RS. Er misst CPU-Last. Wenn hoch -> HPA editiert das RS: replicas: 10. Wenn niedrig -> HPA editiert das RS: replicas: 1. Das RS führt nur stumpf den Befehl des HPA aus.

3. Cascading Delete

Wenn du ein RS löschst kubectl delete rs my-rs, werden standardmäßig auch alle Pods gelöscht (Cascade). Mit --cascade=orphan kannst du nur den Aufpasser löschen, aber die Pods am Leben lassen. Nützlich für Migrationen oder Debugging ("Ich will den Controller rebooten, aber die App soll weiterlaufen").

Das Informer-Pattern & Delta FIFO Queue

ReplicaSets fragen den API-Server des Clusters niemals aktiv per Polling an ("Gibt es neue Pods?"). Das würde das gesamte K8s-Netzwerk crashen. Moderne Controller nutzen das Informer Pattern via gRPC. Das ReplicaSet öffnet eine langlaufende Watch-Verbindung zum kube-apiserver. Wenn im Cluster ein Pod gelöscht wird, pusht der etcd diesen Event auf eine "Delta FIFO Queue". Das RS empfängt passiv das Delta, gleicht es mit seinem internen Cache (dem Desired State) ab, und feuert dann blitzschnell den Erstellungs-Call ab. Die Latenz ist minimal.

OwnerReferences und Garbage Collection

Woher weiß K8s beim Löschen eines RS, dass es genau diese 10 Pods mitlöschen soll? Wenn ein Controller einen Pod generiert, platziert er eine strikte ownerReferences Meta-Property im YAML des Pods. Der K8s Garbage Collector-Controller patrouilliert im Hintergrund durch den Cluster ("Background Deletion"). Sieht er einen Pod, dessen ownerReference auf eine nicht existierende UID (eines gelöschten RS) zeigt, verurteilt er ihn als herrenlos und bittet den Kubelet gnadenlos zur Terminierung. Bei --cascade=orphan schneidet die API vor dem RS-Delete lediglich hart diese Owner-Links durch; die Pods schweben frei im Raum.

Disconnected ReplicaSets (Die Historie im Deployment)

Wenn du ein K8s-Deployment aktualisierst (z.B. von Image v1 auf v2), greift K8s auf RS-Level brutal ein. Ein paralleles ReplicaSet für v2 wird hochgefahren, das v1-ReplicaSet wird schrittweise auf 0 gedownt. Das Geheimnis: Das v1-ReplicaSet wird nicht gelöscht. Es verweilt nutzlos aber existent als Daten-Leiche mit replicas: 0 im Namespace. Das Feature .spec.revisionHistoryLimit=10 hält genau die letzten 10 ReplicaSets der Vergangenheit fest. Nur dank dieser stillen Relikte kann der Befehl kubectl rollout undo deployment ohne Image-Pull-Probleme sofort das v1 ReplicaSet aus dem Nichts wiederbeleben und auf replicas: 3 wuchten.