--- title: "Rolling Updates in Kubernetes: ein Einblick in ReplicaSets und Deployments" description: Dieser Blogpost beschreibt die Unterschiede zwischen ReplicaSets, ReplicaControllern und Deployments und geht detailliert auf die Unterschiedlichen Rollout-Strategies ein um das Prinzip von Rolling-Updates in Kubernetes zu verdeutlichen. image: https://scalewerk.io/hubfs/assets/images_webp/Blog/RollingUpdates/happy_rolling_update.webp --- [scalewerk.io](https://scalewerk.io):~# - [Heimat](https://scalewerk.io) - Lösungen - [Automatisierung & Prozessoptimierung](https://scalewerk.io/automatisierung-und-prozessoptimierung) - [Künstliche Intelligenz & Daten](https://scalewerk.io/ki-und-daten) - [Cloud-Engineering](https://scalewerk.io/cloud-engineering) - [Skalierung & Verfügbarkeit](https://scalewerk.io/skalierung-und-verfuegbarkeit) - [Kontakt](https://scalewerk.io/kontakt) - [Blog](https://scalewerk.io/blog) September 27, 2024 [scalewerk.io](https://scalewerk.io/blog/author/scalewerk-io) # Rolling Updates in Kubernetes: ein Einblick in ReplicaSets und Deployments [kubernetes](https://scalewerk.io/blog/tag/kubernetes) ![Picture of scalewerk.io](https://scalewerk.io/hubfs/assets/images_webp/Blog/RollingUpdates/happy_rolling_update.webp) ##### Share - - - Eines der Kern-Features in denen [Kubernetes](https://scalewerk.io/kubernetes-and-containers) seine Stärken ausspielt sind Rolling Updates im Rahmen von Deployment-Prozessen. Dadurch werden Zero-Downtime-Deployments ermöglicht und dem Endnutzer eine nahtlose User-Experience geboten auch wenn unter der Haube mal eben ein komplett neues Release ausgerollt wird. In diesem Blog-Post soll losgelöst von den konkreten Herausforderungen im Einzelfall, welche bei jeder größeren Applikation zu lösen sind, einmal das grundsätzliche Prinzip im Detail beleuchtet werden, mit welchem Kubernetes dieses Problem löst. ### ReplicaSets vs. Deployments #### ReplicaSets ReplicaSets sind die deklarative Abbildung einer Kubernetes-Ressource welche sicherstellt, dass eine definierte Anzahl an Pods von einem bestimmten Typ zu jeder Zeit laufen. Replicasets definieren also den Soll-Zustand einer Applikation und ihrer Skalierung. Oft ist in dem Kontext auch von [Replication Controllern](https://kubernetes.io/docs/concepts/workloads/controllers/replicationcontroller/) die Rede. Diese sind allerdings schon seit Längerem veraltet und die Verwendung von Deployments und ReplicaSets wird empfohlen. #### Deployments Deployments sind eine Abstraktionsebene höher angesiedelt und managen die ReplicaSets, kümmern sich um deren Lifecyle und ermöglichen Updates und Rollbacks. #### ReplicaSets   Nehmen wir einmal die folgende Pod-Definition: ``` # pod.yaml apiVersion: v1 kind: Pod metadata:   name: nginx-pod   labels:     app: web     tier: frontend spec:  containers:   - name: nginx     image: nginx:latest     ports:     - containerPort: 80 ``` Darauf aufbauend würde eine passende ReplicaSet-Definition z.B. wie folgt aussehen: ``` # replicaset.yaml apiVersion: apps/v1 kind: ReplicaSet metadata: name: nginx-replicaset labels: app: web tier: frontend spec: template: # hier folgt obige Pod-Deklaration metadata: name: nginx-pod labels: app: web tier: frontend spec: containers: - name: nginx image: nginx:latest ports: - containerPort: 80 replicas: 3 selector: matchLabels: app: web tier: frontend ``` Anlegen des ReplicaSets: ``` kubectl create -f replicaset.yaml ``` ![Bildschirmfoto_2024-09-19_um_10.44.00_1726735527599_0](https://scalewerk.io/hs-fs/hubfs/assets/images/Blog/RollingUpdates/Bildschirmfoto_2024-09-19_um_10.44.00_1726735527599_0.png?width=488&height=178&name=Bildschirmfoto_2024-09-19_um_10.44.00_1726735527599_0.png)   Über die Selektoren wird definiert welche Pods dem ReplicaSet zugeordnet sind. Dies erlaubt es auch, dass ReplicaSets auf bestehende Pods mit den selben Labels angewendet werden. Diese werden dann vom Kubernetes-Controller-Manager überwacht. Der Kubernetes-Controller-Manager ist ein Prozess innerhalb des Kubernetes-Clusters welcher diverse Controller verwaltet, darunter auch den ReplicaSet-Controller.   Ändern wir jetzt die Anzahl der Pods des ReplicaSets mit ***kubectl edit*** oder ***kubectl scale***, dann passt der Kubernetes-Controller-Manager die Skalierung der Pods entsprechend an:    ![rolling_update_snippet_2](https://scalewerk.io/hs-fs/hubfs/assets/images_webp/Blog/RollingUpdates/rolling_update_snippet_2.webp?width=383&height=163&name=rolling_update_snippet_2.webp)   Was passiert wenn wir jetzt das Container-Image ändern welches in den ReplicaSets definiert ist?    ![rolling_update_snippet_3](https://scalewerk.io/hs-fs/hubfs/assets/images_webp/Blog/RollingUpdates/rolling_update_snippet_3.webp?width=740&height=148&name=rolling_update_snippet_3.webp)   Obwohl das ReplicaSet erfolgreich gepatched wurde, bleiben die Pods unverändert. Das liegt daran, dass ReplicaSets nur den gewünschten Zustand der Replicas, also die der Anzahl der Pods verwalten. Sie lösen aber keinen Neustart der Pods aus wenn sich deren Template ändert, da ReplicaSets keine eingebaute Logik für Rolling Updates haben. Hier kommen die Deployments ins Spiel.   #### Deployments   Deployments sind wie schon eingangs angedeutet eine Abstraktionsebene höher angesiedelt als ReplicaSets:   ![deployment](https://scalewerk.io/hubfs/assets/images/Blog/RollingUpdates/deployment.svg)   Die Definition eines Deployments sieht der eines ReplicaSets sehr ähnlich, in unserem Beispiel ändern sich nur der ***kind*** und der ***name***:   ``` # deployment.yaml apiVersion: apps/v1 kind: Deployment metadata: name: nginx-deployment labels: app: web tier: frontend spec: template: metadata: name: nginx-pod labels: app: web tier: frontend spec: containers: - name: nginx image: nginx:latest ports: - containerPort: 80 replicas: 3 selector: matchLabels: app: web tier: frontend ```   ![rolling_update_snippet_4](https://scalewerk.io/hs-fs/hubfs/assets/images_webp/Blog/RollingUpdates/rolling_update_snippet_4.webp?width=551&height=279&name=rolling_update_snippet_4.webp)   Es wurden folgende Ressourcen angelegt:   - 3 Pods - 1 ReplicaSet - 1 Deployment Wiederholen wir einmal den Task welchen wir mit dem ReplicaSet schon einmal durchgeführt haben und ändern das Image des ReplicaSets:   ![rolling_update_snippet_5](https://scalewerk.io/hs-fs/hubfs/assets/images_webp/Blog/RollingUpdates/rolling_update_snippet_5.webp?width=740&height=160&name=rolling_update_snippet_5.webp)   Jetzt sehen wir, dass die Änderungen scheinbar sofort angewendet werden, da das Deployment die Änderungen an der Pod-Spezifikation überwacht und per Rolling-Update anwendet. Sehen wir genauer hin, sehen wir auch, dass ein zweites ReplicaSet angelegt wurde. Aber laufen wirklich die richtigen Pods?    ![rolling_update_snippet_6](https://scalewerk.io/hs-fs/hubfs/assets/images_webp/Blog/RollingUpdates/rolling_update_snippet_6.webp?width=687&height=142&name=rolling_update_snippet_6.webp)   Nginx ist noch immer mit dem latest Image ausgerollt, obwohl ein neues ReplicaSet angelegt wurde. Was ist passiert?   Das ReplicaSet, welches wir gepatcht haben, wurde durch das Deployment angelegt und wird auch durch dieses verwaltet. Die Änderung hat also zu einer Inkonsistenz geführt, da das Deployment die Quelle der Wahrheit für das Pod-Template ist. Daher hat das Deployment ein zweites ReplicaSet angelegt, welches wieder dem Stand der Deployment-Spezifikation entspricht.   Wie gehen wir also richtig vor, um ein Deployment zu aktualisieren?   Idealerweise editieren wir das Deployment-File und triggern anschließend einen neuen Rollout mit einer neuen Revision mit ***kubectl apply*** : ``` kubectl apply -f deployment.yaml ``` Alternativ kann auch der imperative Ansatz gewählt werden. Hierbei wird die Änderung allerdings nicht in der yaml-Definition persistiert: ``` kubectl set image deployment/nginx-deployment nginx=nginx=1.26.2 ``` Intern geschieht dabei Folgendes:   Zunächst wird ein neues ReplicaSet durch das Kubernetes-Deployment angelegt. Die neuen Container werden in diesem neuen ReplicaSet angelegt und zeitgleich die Container aus dem alten ReplicaSet gelöscht. Abhängig von der Deployment-Strategie werden dabei entweder zunächst alle Container aus dem ersten ReplicaSet gelöscht bevor neue erstellt werden (Recreate-Strategy) oder einer nach dem anderen durch einen neuen ausgetauscht (RollingUpdate-Strategy). Die RollingUpdate-Strategy ist dabei die Default-Strategie:    ![Rollout](https://scalewerk.io/hubfs/assets/images/Blog/RollingUpdates/Rollout.svg)   Nachvollziehen lässt sich das alles auch über ***kubectl*** commands: Ausgehend von einem existierenden Deployment, sehen wir dass eine neue Revision in der Rollout-History angelegt wird:   ![rolling_update_snippet_7](https://scalewerk.io/hs-fs/hubfs/assets/images_webp/Blog/RollingUpdates/rolling_update_snippet_7.webp?width=502&height=208&name=rolling_update_snippet_7.webp)   Sehen wir uns das Deployment genau an, sehen wir das neue ReplicaSet und die Anwendung der RollingUpdate-Strategy:   ![rolling_update_snippet_9](https://scalewerk.io/hubfs/assets/images/Blog/RollingUpdates/rolling_update_snippet_9.svg)   Wendet man hingegen die Recreate-Strategy wie folgt an, ist zu sehen, dass die Pods zunächst auf 0 Replicas runterskaliert werden: ``` # deployment.yaml apiVersion: apps/v1 kind: Deployment metadata: name: nginx-deployment labels: app: web tier: frontend spec: template: metadata: name: nginx-pod labels: app: web tier: frontend spec: containers: - name: nginx image: nginx:latest ports: - containerPort: 80 replicas: 3 strategy: type: Recreate # Recreate- statt RollingUpdate-Strategy selector: matchLabels: app: web tier: frontend ``` ![Recreate](https://scalewerk.io/hubfs/assets/images/Blog/RollingUpdates/Recreate.svg)   Den vorherigen Stand können wir in beiden Fällen über einen rollback auch sehr schnell wiederherstellen:   ``` kubectl rollout undo deployment nginx-deployment ```   Achtung: hierbei werden die Kubernetes-Ressourcen der vorherigen Revision erneut angewendet und als neue Revision angelegt. Änderungen an persistierten Daten werden hiermit natürlich nicht zurückgerollt.   #### Liveness-, Readiness- und Startup-Probes   Die Möglichkeit die Pods per RollingUpdate-Strategy auszutauschen ist allerdings nur ein erster Schritt um auch Zero-Downtime fähig zu werden. Um zu verhindern, dass Pods zu früh oder zu spät aus der Verteilung bzw. zu früh wieder in die Lastverteilung genommen werden ist es wichtig messbare Probes zu definieren, welche es Kubernetes ermöglichen das Scheduling optimal und ohne Downtime zu gestalten.   Diese Probes werden vom Kubelet-Prozess, welcher auf jeder Node des Clusters läuft, regelmäßig ausgeführt, um den Zustand der Container zu validieren. Basierend auf dem Ergebnis der Probes werden dann die Deployment-Steps durchlaufen. Kubernetes unterscheidet dabei zwischen:   ##### Liveness-Probes   Prüft regelmäßig ob ein laufender Container noch funktioniert. Bspw. indem ein definierter HTTP-Endpunkt abgefragt und das Ergebnis validiert wird. Schlägt die Probe wiederholt fehl, wird der Container neu gestartet.   ##### Readiness-Probes   Prüft ob ein Container bereit ist Anfragen zu bearbeiten. Schlägt die Readiness-Probe fehl, wird der Container temporär aus der Verteilung genommen aber nicht neu gestartet.   ##### Startup-Probes   Die Startup-Probe prüft ob ein Container erfolgreich gestartet ist. Wenn eine Startup-Probe implementiert ist, werden Readiness- und Liveness-Probe solange deaktiviert, bis die Startup-Probe erfolgreich ist. Dies verhindert bei Containern mit langen Startvorgängen, dass diese während des Startups durch die Liveness Probe neu gestartet werden.   ### Fazit   Deployments und ReplicaSets ermöglichen uns in Kubernetes die Durchführung von Rolling Updates auf sehr elegante und effiziente Weise. Durch den Einsatz sinnvoll implementierter Probes können wir dabei die Downtime während des Update-Prozesses auf ein absolutes Minimum reduzieren – im Idealfall sogar vollständig vermeiden.   ![scalewerkio-2](https://scalewerk.io/hs-fs/hubfs/assets/images_webp/Logo/scalewerkio-2.webp?width=112&height=77&name=scalewerkio-2.webp) scalewerk.io ist Ihr Partner für Automatisierung & Cloud-Lösungen im Ruhrgebiet. Von Workflow-Automation über DevOps bis KI-Integration – alles aus einer Hand. Pragmatische Full-Service-Begleitung mit Tech-Expertise. Wir liefern Ergebnisse! ### Kontakt [contact@scalewerk.io](mailto:contact@scalewerk.io) scalewerk.io GmbH Schmachtendorfer Str. 5 46147 Oberhausen [+49 208 46839980](tel:+49%20208%2046839980) scalewerk.io GmbH Persebecker Str. 47  44227 Dortmund [+49 231 98629250](tel:+49%20231%2098629250) [Impressum](https://scalewerk.io/impressum) | [Datenschutz](https://scalewerk.io/datenschutz) - © 2026 scalewerk.io GmbH  ```json { "@context" : "https://schema.org", "@type" : "BlogPosting", "author" : { "@type" : "Person", "name" : "scalewerk.io", "url" : "https://scalewerk.io/blog/author/scalewerk-io" }, "dateModified" : "2026-02-06T14:04:00.617Z", "datePublished" : "2024-09-27T09:06:15.000Z", "headline" : "Rolling Updates in Kubernetes: ein Einblick in ReplicaSets und Deployments", "image" : [ "https://scalewerk.io/hubfs/assets/images_webp/Blog/RollingUpdates/happy_rolling_update.webp" ], "mainEntityOfPage" : { "@id" : "https://scalewerk.io/blog/rolling-updates-in-kubernetes-ein-einblick-in-replicasets-und-deployments", "@type" : "WebPage" }, "publisher" : { "@type" : "Organization", "logo" : { "@type" : "ImageObject", "url" : "https://scalewerk.io/hubfs/assets/images/Logo/Scalewerk_Logo_%23292C33-1.jpg" }, "name" : "scalewerk.io:~#" } } ``` ```json { "@context" : "http://schema.org", "@type" : "Corporation", "address" : { "@type" : "PostalAddress", "addressCountry" : "", "addressLocality" : "", "addressRegion" : "", "postalCode" : "", "streetAddress" : " " }, "alternateName" : "Lagom", "description" : "Lorem ipsum dolor sit amet, consectetur adipiscing elit", "email" : "", "image" : "", "logo" : "https://scalewerk.io/hubfs/assets/images/Logo/Scalewerk_Logo_%23292C33-1.jpg", "mainEntityOfPage" : { "@id" : "https://scalewerk.io/blog/rolling-updates-in-kubernetes-ein-einblick-in-replicasets-und-deployments", "@type" : "WebPage", "description" : "Dieser Blogpost beschreibt die Unterschiede zwischen ReplicaSets, ReplicaControllern und Deployments und geht detailliert auf die Unterschiedlichen Rollout-Strategies ein um das Prinzip von Rolling-Updates in Kubernetes zu verdeutlichen." }, "name" : "", "sameAs" : [ "https://www.linkedin.com/company/revivalpixel/", "https://www.linkedin.com/company/revivalpixel/", "https://www.linkedin.com/company/revivalpixel/" ], "telephone" : "", "url" : "/" } ```