Kubernetes ReplicaSet: Immer die richtige Anzahl Pods – einfach erklärt

Kubernetes ReplicaSet stellt sicher, dass zu jeder Zeit eine definierte Anzahl identischer Pods läuft. Fällt ein Pod aus, startet der ReplicaSet-Controller sofort einen Ersatz; werden zu viele Pods gefunden, beendet er die überzähligen. Damit ist das ReplicaSet die Grundlage für Hochverfügbarkeit und Skalierung in Kubernetes. Für echte Ausfallsicherheit verteilt die Pod-Anti-Affinität Replikate auf verschiedene Nodes oder Zonen; die gleichmäßige Verteilung übernimmt Topology Spread Constraints.

Aufbau

Ein ReplicaSet (Ressource apps/v1) besteht aus drei Kernbestandteilen: spec.replicas (Soll-Anzahl), spec.selector (welche Pods es verwaltet, üblicherweise per matchLabels) und spec.template (Vorlage für neue Pods). Der Selector ist zwingend: Der Controller übernimmt alle Pods, die zu ihm passen – auch verwaiste Pods ohne Besitzer – und versieht die von ihm erzeugten Pods mit einer ownerReferences-Markierung, sodass sie beim Löschen des ReplicaSets mit aufgeräumt werden.

apiVersion: apps/v1
kind: ReplicaSet
metadata:
  name: webserver
spec:
  replicas: 3
  selector:
    matchLabels:
      app: webserver
  template:
    metadata:
      labels:
        app: webserver
    spec:
      containers:
      - name: nginx
        image: nginx:latest

Deployment statt direktem ReplicaSet

In der Praxis legt man ReplicaSets kaum direkt an: Das Deployment verwaltet ReplicaSets automatisch und bringt zusätzlich deklarative Updates mit. Bei einem Rolling Update erzeugt das Deployment ein neues ReplicaSet und skaliert das alte schrittweise herunter. Wer direkt ein ReplicaSet nutzt, verzichtet auf diese Update-Mechanik. Skalieren lässt sich beides – per kubectl scale oder automatisch über den Horizontal Pod Autoscaler, der auf ReplicaSets und Deployments aufsetzt.

Zusammen mit StatefulSet, DaemonSet, Job und CronJob gehört das ReplicaSet zu den Workload-Controllern, mit denen Kubernetes Anwendungen in Kubernetes betreibt.