Kubernetes ReplicaSet: Erklärung, YAML-Beispiele & Skalierung

In Kubernetes willst du meistens nicht “einen Pod starten”, sondern sicherstellen, dass immer eine bestimmte Anzahl von identischen Pods läuft – selbst wenn Nodes ausfallen oder Pods abstürzen. Genau dafür gibt es das ReplicaSet.

1) Was ist ein ReplicaSet?

Ein ReplicaSet ist ein Kubernetes-Objekt, das sicherstellt, dass zu jeder Zeit eine definierte Anzahl von Pod-Replikas existiert. Es überwacht Pods, die zu einem bestimmten Label-Selector passen, und gleicht den Ist-Zustand mit dem Soll-Zustand ab:

Wenn zu wenige Pods laufen: ReplicaSet erstellt neue Pods.
Wenn zu viele Pods laufen: ReplicaSet entfernt Pods.
Wenn ein Pod abstürzt/gelöscht wird: ReplicaSet sorgt für Ersatz.

Wichtig: In der Praxis erzeugst du ReplicaSets meist nicht direkt, sondern über ein Deployment. Dennoch ist es extrem hilfreich, ReplicaSets zu verstehen – z. B. beim Debugging, bei Rollouts oder wenn du kontrolliert “nackte” Replikation ohne Deployment brauchst.

2) Warum gibt es ReplicaSets – und was ist der Unterschied zu Deployments?

ReplicaSet und Deployment hängen eng zusammen:

ReplicaSet: hält eine feste Anzahl Pods am Laufen (Replikation & Selbstheilung).
Deployment: verwaltet ReplicaSets und bietet zusätzlich Rolling Updates, Rollbacks, Versionshistorie, Strategie-Optionen etc.

Merksatz: Deployment = ReplicaSet + Update-/Rollout-Management.

Wann nutzt man ein ReplicaSet direkt?

Selten – aber es gibt Fälle, z. B.:

Du willst reine Replikation ohne Rollout-Mechanik (sehr kontrollierte Umgebungen).
Du lernst Kubernetes oder möchtest die Grundlagen “roh” verstehen.
Debugging: Du schaust dir an, welches ReplicaSet dein Deployment gerade erzeugt hat.

3) Die Kern-Idee: Labels und Selector

ReplicaSets funktionieren über Labels. Ein ReplicaSet hat einen Selector, der bestimmt, welche Pods “dazugehören”. Gleichzeitig enthält das ReplicaSet ein Pod-Template, das beschreibt, wie neue Pods erstellt werden.

Das bedeutet: Wenn ein Pod die passenden Labels trägt, kann das ReplicaSet ihn als Teil seines “Bestands” betrachten – auch wenn der Pod ursprünglich anders erstellt wurde. Genau hier entstehen typische Fehler, wenn Selector und Labels nicht sauber geplant sind.

4) Beispiel 1: Ein einfaches ReplicaSet (3 NGINX-Pods)

Dieses Beispiel erstellt ein ReplicaSet namens nginx-rs mit 3 Pods. Jeder Pod hat das Label app=nginx. Der Selector des ReplicaSets sucht genau nach diesem Label.

apiVersion: apps/v1
kind: ReplicaSet
metadata:
  name: nginx-rs
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.25
        ports:
        - containerPort: 80

Anwenden & prüfen

kubectl apply -f nginx-rs.yaml
kubectl get rs
kubectl get pods -l app=nginx

Selbstheilung testen

Lösche einen Pod und beobachte, wie das ReplicaSet automatisch einen neuen erstellt:

kubectl delete pod -l app=nginx --field-selector=status.phase=Running --limit=1
kubectl get pods -l app=nginx -w

Du wirst sehen, dass die Pod-Anzahl wieder auf 3 zurückgeht.

5) Beispiel 2: Skalieren eines ReplicaSets

Skalieren bedeutet: du änderst die gewünschte Anzahl Replikas. Das geht über das Manifest oder per Kommando.

Skalieren per kubectl

kubectl scale rs nginx-rs --replicas=5
kubectl get pods -l app=nginx

Skalieren per YAML

Du passt spec.replicas an und wendest die Datei erneut an.

6) Beispiel 3: ReplicaSet & Service – stabile Adresse für wechselnde Pods

ReplicaSets sorgen dafür, dass Pods immer wieder neu entstehen können. Pods haben aber keine stabile IP. Deshalb kombiniert man ReplicaSets fast immer mit einem Service, um eine stabile Netzwerkadresse zu bekommen.

Service für unser NGINX-ReplicaSet (ClusterIP)

apiVersion: v1
kind: Service
metadata:
  name: nginx-svc
spec:
  selector:
    app: nginx
  ports:
  - port: 80
    targetPort: 80

Dieser Service routet zu allen Pods mit app=nginx. Wenn Pods ersetzt werden, bleibt der Service trotzdem stabil.

kubectl apply -f nginx-svc.yaml
kubectl get svc nginx-svc

7) Häufige Stolperfallen & Best Practices

7.1 Selector & Labels müssen zusammenpassen

Das ReplicaSet zählt Pods über den Selector. Wenn du z. B. im Template andere Labels setzt als im Selector, kann es passieren, dass das ReplicaSet keine eigenen Pods erkennt und immer wieder neue erstellt (bis zum Limit / Chaos).

Best Practice: Der Selector sollte exakt zu den Labels im Template passen.

7.2 Keine “zu allgemeinen” Selector verwenden

Ein Selector wie app=web kann auch andere Pods matchen, die du gar nicht unter Kontrolle dieses ReplicaSets haben willst. Dadurch kann das ReplicaSet Pods “übernehmen” oder falsch mitzählen.

Best Practice: Verwende klare, spezifische Labels, z. B.:

app=shop
component=frontend
tier=web
version=v1 (nur wenn bewusst gewollt)

7.3 Nutze in der Praxis meist Deployments

Ein ReplicaSet alleine kann nicht komfortabel “rollend” aktualisieren oder zurückrollen. Für produktive Systeme ist ein Deployment fast immer die bessere Wahl.

8) ReplicaSet im Alltag: Was sehe ich bei Deployments?

Wenn du ein Deployment erstellst, erzeugt Kubernetes im Hintergrund ein ReplicaSet. Bei einem Update (z. B. neues Image) wird oft ein neues ReplicaSet erstellt, während das alte schrittweise heruntergefahren wird.

Beispiel:

kubectl get deploy
kubectl get rs
kubectl describe rs

Du erkennst ReplicaSets von Deployments häufig an Namen wie: myapp-7c9d7c8f5 (Suffix ist ein Hash).

9) Troubleshooting: Nützliche Kommandos

kubectl get rs – alle ReplicaSets anzeigen
kubectl describe rs <name> – Events, Selector, Template, Fehler
kubectl get pods -l app=nginx – Pods per Label filtern
kubectl get events --sort-by=.metadata.creationTimestamp – was ist zuletzt passiert?

Typischer Fehler: “Pods werden ständig neu erstellt”

Mögliche Ursachen:

Selector matcht nicht die Template-Labels
ImagePullBackOff (Image nicht erreichbar)
CrashLoopBackOff (Container startet und crasht wieder)
Ressourcenmangel (kein Platz auf Nodes, Pending Pods)

10) Fazit

Ein ReplicaSet ist das “Arbeitstier” hinter der Replikation in Kubernetes: Es hält eine definierte Anzahl identischer Pods am Leben und ersetzt sie automatisch bei Ausfällen. In der Praxis begegnet es dir vor allem als Bestandteil von Deployments. Wer ReplicaSets versteht, kann Kubernetes-Rollouts besser debuggen und versteht, warum Kubernetes so robust und selbstheilend ist.

Tipp: Wenn du als Nächstes tiefer einsteigen willst, schau dir an, wie Deployments ReplicaSets beim Rolling Update verwenden – das macht das ganze Bild komplett.