Chapter 15: Automating application updates with Deployments

Introduction

Introduces Deployments as the Kubernetes object for updating stateless workloads more seamlessly than ReplicaSets.

• Deployments versus ReplicaSets: Explain why the chapter moves from ReplicaSets to Deployments: ReplicaSets can deploy pods but do not provide seamless pod updates, while Deployments provide that functionality.
  Why it matters: This distinction explains why the book uses Deployments to manage the Kiada services.

Key terms: ReplicaSet, Deployment object, seamless pod updates

15.1 Introducing Deployments

Introduces Deployments as a declarative way to manage application pods through ReplicaSets and explains when they suit stateless or stateful workloads.

• Deployment ownership and configuration: Explain how a Deployment relates to ReplicaSets and pods, and state the configuration it specifies.
  Why it matters: This relationship explains why a Deployment manages pods without controlling them directly.
• Declarative application updates: Explain how updating a Deployment differs from manually replacing pods with an updated version.
  Why it matters: It captures the main advantage of using a Deployment for application updates.
• Stateless workloads and stateful caveat: Explain why Deployments mainly suit stateless workloads and what an application must ensure if a Deployment runs a single-instance stateful workload.
  Why it matters: It identifies a workload limitation that matters when choosing to use a Deployment.

Key terms: Deployment, ReplicaSet, Pod template, replicas, label selector, declaratively, Deployment object, update, stateless workloads, stateful workload

15.1.1 Creating a Deployment

This section creates and inspects a Deployment, explains why it creates new pods rather than adopting existing ones, and shows where to diagnose missing pods.

• Deployment spec fields: Explain how a Deployment spec compares with a ReplicaSet spec: replicas, selector, and template serve the same purposes, while strategy configures the update strategy.
  Why it matters: It lets you read or adapt a familiar ReplicaSet manifest as a Deployment.
• Deployment manifest creation: Describe the two ways given to make a Deployment manifest: generate a rough YAML manifest with a client-side dry run and edit it, or copy an existing ReplicaSet manifest and change its kind.
  Why it matters: Both approaches give you an editable manifest rather than requiring you to build one unaided.
• Deployment rollout inspection: Describe how to create the Deployment with kubectl apply and inspect its pod counts, full status, and rollout progress.
  Why it matters: It gives you ways to verify that the Deployment has produced the intended pods.
• ReplicaSet ownership and hash: Explain why the new Deployment creates three pods despite two existing pods matching its original selector, and relate the underlying ReplicaSet's name and extra label to the Pod template.
  Why it matters: It explains both the unexpected five matching pods and which pods actually belong to the Deployment.
• Missing pod diagnosis: Explain where to look when a Deployment produces no pods: check its conditions, then inspect the underlying ReplicaSet and its events for the cause.
  Why it matters: It directs troubleshooting to the component that attempts to create the missing pods.

Key terms: Deployment, ReplicaSet, replicas, selector, template, strategy, manifest, kubectl create, --dry-run=client, -o yaml

15.1.2 Scaling a Deployment

This section explains how Deployments scale through ReplicaSets, why direct changes to an owned ReplicaSet are undone, and how reapplying a manifest can accidentally change a Deployment’s replica count.

• Deployment scaling through ReplicaSets: Explain how scaling a Deployment changes its pod count and name the roles of the Deployment and ReplicaSet controllers. Describe ways to set the Deployment’s desired replica count.
  Why it matters: It tells you which controller is responsible when the number of pods changes.
• Control of owned ReplicaSets: Explain what happens if you directly scale or delete a ReplicaSet owned by a Deployment.
  Why it matters: Changing an owned ReplicaSet is not a reliable way to change the Deployment’s lasting state.
• Accidental scaling during manifest reapplication: Explain why reapplying a Deployment manifest after scaling can unintentionally change its replica count, and describe the preventive and repair approaches given here.
  Why it matters: A seemingly unrelated manifest update could remove pods needed to handle application traffic.

Key terms: Deployment controller, ReplicaSet controller, replicas field, kubectl scale, owned ReplicaSet, desired number of replicas, kubectl apply, kubectl.kubernetes.io/last-applied-configuration annotation

15.1.3 Deleting a Deployment

Explains what happens to a Deployment’s ReplicaSet and pods when the Deployment is deleted, and when a recreated Deployment can adopt them.

• Deployment deletion and orphaning: Explain that deleting a Deployment normally deletes its underlying ReplicaSet and pods, while using kubectl delete with --cascade=orphan preserves both the ReplicaSet and its pods.
  Why it matters: The deletion option determines whether the application’s pods remain after the Deployment is removed.
• Recreated Deployment adoption: Explain when a recreated Deployment picks up an existing ReplicaSet: its Pod template must not have changed, so the controller finds a ReplicaSet whose name matches the one it would otherwise create.
  Why it matters: This explains why recreating a Deployment may reuse the workload you preserved instead of creating a new ReplicaSet.

Key terms: Deployment, ReplicaSet, pods, --cascade=orphan, Deployment controller, Pod template

15.2 Updating a Deployment

This section explains why updating a Deployment’s Pod template replaces existing pods and introduces the strategies that govern their replacement.

• Deployment versus ReplicaSet updates: Explain how updating a Pod template affects existing pods differently in a Deployment and a ReplicaSet.
  Why it matters: This is the update behavior that makes a Deployment useful beyond a ReplicaSet.
• Deployment update strategy choices: Describe what the configured update strategy controls and distinguish the configuration options stated here for Recreate and RollingUpdate.
  Why it matters: The strategy determines how a Deployment carries out a Pod template update.

Key terms: Deployment, ReplicaSet, Pod template, update strategy, Recreate, RollingUpdate

15.2.1 The Recreate strategy

This section shows how to run a Deployment update with the Recreate strategy, observe the replacement of its ReplicaSet and pods, and recognize the resulting interruption in service.

• Recreate configuration and update trigger: Distinguish setting a Deployment’s update strategy from triggering an update: Recreate must be specified because RollingUpdate is the default, but changing the strategy alone does not update pods; changing the Pod template does.
  Why it matters: It explains why setting the strategy and starting an update are separate actions.
• Consistent image and version labels: Explain why an image-only change can leave this Deployment’s pod version label inconsistent, and describe how kubectl patch can change both fields together.
  Why it matters: Keeping the version label aligned with the image makes the updated pods easier to identify correctly.
• ReplicaSet replacement sequence: Trace how the Deployment and ReplicaSet controllers replace the old pods during a Recreate update, from scaling the old ReplicaSet to zero through creation and readiness of the new pods.
  Why it matters: The controller sequence explains why all old pods disappear before the new version is ready.
• Recreate service interruption: Explain why the service briefly cannot serve requests during a Recreate update and describe the responses observed through an Ingress and through the internal cluster IP.
  Why it matters: It identifies the availability cost of choosing Recreate for an application update.

Key terms: Recreate, RollingUpdate, Pod template, kubectl edit, kubectl apply, kubectl set image, kubectl patch, image, pod labels, Deployment controller

15.2.2 The RollingUpdate strategy

This section shows how a Deployment’s RollingUpdate strategy gradually replaces pods while keeping the Service available, and how to configure and observe that rollout.

• Rolling update availability: Explain why RollingUpdate is the default Deployment strategy and how it avoids the disruption associated with Recreate.
  Why it matters: The reason for a rolling update is to keep the application reachable while changing versions.
• ReplicaSet rollout progression: Trace how the old and new ReplicaSets change during the example rollout, including when the Deployment controller waits before continuing.
  Why it matters: Following both ReplicaSets and pod readiness explains why old and new versions can serve traffic at the same time.
• RollingUpdate manifest configuration: Describe how the example manifest selects RollingUpdate and triggers the version update in one apply operation.
  Why it matters: The strategy change and application update can be submitted together rather than as separate operations.
• Rollout observation methods: Describe what inspecting ReplicaSets and continuous client requests reveal about the rolling update.
  Why it matters: Watching both ReplicaSets and client responses connects the controller’s actions to what users experience.

Key terms: RollingUpdate, Recreate, Service, Deployment controller, ReplicaSet, ready, minReadySeconds, strategy, type, kubectl apply

15.2.3 Configuring how many pods are replaced at a time

This section explains how maxSurge and maxUnavailable control the pace and capacity limits of a Deployment rolling update.

• Rolling update capacity limits: Explain what maxSurge and maxUnavailable limit, how those limits relate to the desired replica count, and why both cannot be zero.
  Why it matters: These limits tell you how much extra capacity an update may use and how much availability it may temporarily lose.
• Pod replacement under different limits: Trace how the controller replaces old pods when the limits are 0/1, 1/0, or 1/1 for maxSurge/maxUnavailable, respectively.
  Why it matters: The settings determine whether an update first makes room, first adds capacity, or does both.
• Percentage limits and rounding: Apply the percentage form of maxSurge and maxUnavailable, including their different rounding directions and the example with ten desired replicas.
  Why it matters: Rounding can change the actual number of pods added or made unavailable, particularly at smaller replica counts.

Key terms: maxSurge, maxUnavailable, desired number of replicas, Deployment controller, old ReplicaSet, new ReplicaSet, available replicas, terminating pods, percentages, rounding up

15.2.4 Pausing the rollout process

Explains how pausing a Deployment controls a rolling update and reveals a risk when a web application serves mixed versions.

• Paused Deployment rollout control: Explain how pausing and resuming a Deployment controls its rolling update, both partway through a rollout and before making several changes.
  Why it matters: Pausing gives you a chance to inspect a partial rollout or finish a set of changes before it proceeds.
• Mixed-version web resource risk: Explain why a rolling update can give a browser resources from different application versions, and describe the precautions presented here.
  Why it matters: A rollout can keep the application available yet still produce a broken page if its versions’ resources are incompatible.

Key terms: Deployment, rolling update, paused field, Deployment controller, ReplicaSets, session affinity, backwards compatibility, Blue/Green deployment strategy

15.2.5 Updating to a faulty version

Explains how pod availability can hold back a faulty Deployment rollout and how Kubernetes reports a rollout that stops progressing.

• Readiness versus pod availability: Distinguish a ready pod from an available pod and explain how minReadySeconds affects when a rolling update can continue.
  Why it matters: Availability gives the Deployment a chance to observe a new pod before replacing more old pods.
• Faulty version rollout containment: Trace why the example’s readiness probe and 60-second minReadySeconds keep the faulty Kiada version from replacing every old pod, while not preventing all client errors.
  Why it matters: This explains both the protection minReadySeconds provides and why it is not a guarantee of zero errors.
• Stalled rollout status: Describe how a Deployment reports a rollout that has made no progress and what Kubernetes does afterward.
  Why it matters: A reported deadline failure is a status signal, not an automatic fix for the deployment.

Key terms: ready, available, minReadySeconds, readiness probe, FAIL_AFTER_SECONDS, Progressing condition, ProgressDeadlineExceeded, progressDeadlineSeconds, kubectl rollout status

15.2.6 Rolling back a Deployment

Explains how to undo Deployment updates, inspect and select past revisions, distinguish rollback from reapplying a manifest, and restart a Deployment’s pods.

• Undoing a Deployment update: Explain how kubectl rollout undo reverses an update and how the Deployment’s update strategy governs the rollback.
  Why it matters: You can reverse a bad update without assuming that rollback replaces every pod at once.
• Deployment revisions and history: Describe where Deployment revisions are kept, how to inspect them, and how to select a specific revision for rollback.
  Why it matters: Finding the right retained revision lets you roll back farther than just the last update.
• Rollback versus manifest reapplication: Distinguish what kubectl rollout undo changes from what happens when you apply an older Deployment manifest.
  Why it matters: The choice of rollback method determines whether newer scaling and update-strategy settings survive.
• Restarting Deployment pods: Explain what kubectl rollout restart does and how the Deployment’s strategy affects pod replacement.
  Why it matters: Restarting pods need not mean taking every replica down at the same time.

Key terms: kubectl rollout undo, RollingUpdate, kubectl rollout resume, kubectl rollout history, --revision, ReplicaSet, revisionHistoryLimit, Pod template, kubectl apply, update strategy

15.3 Implementing other deployment strategies

This section distinguishes Kubernetes’ built-in Deployment strategies from other strategies that require additional effort to implement.

• Built-in versus other strategies: Distinguish the Recreate and RollingUpdate strategies supported by the Deployment controller from other deployment strategies, which can be implemented manually or automated by a higher-level controller.
  Why it matters: This distinction clarifies what a Deployment provides directly and what needs an additional implementation.

Key terms: Deployment controller, Recreate, RollingUpdate, higher-level controller

15.3.1 The Canary deployment strategy

Explains two ways to test a new application version with canary pods before updating the rest.

• Pausing for canary checks: Distinguish a high minReadySeconds setting from manually pausing a rollout to check its first new pods. Explain when the rollout resumes in each case.
  Why it matters: It helps you distinguish a canary check from a delay repeated throughout the update.
• Separate canary Deployment traffic: Explain how a small canary Deployment and a larger stable Deployment use one Service to expose the new version to a small share of traffic, and describe what happens when it is time to update the remaining pods.
  Why it matters: It explains how to try a new version with limited live traffic while most traffic still reaches the stable version.

Key terms: minReadySeconds, kubectl rollout pause, kubectl rollout resume, canary pods, canary Deployment, stable version, replicas, Service, rolling update

15.3.2 The A/B strategy

Explains how to direct selected users to a new application version for an A/B rollout using Ingress, and notes that support depends on the Ingress implementation.

• Conditional A/B traffic routing: Explain how an A/B rollout directs selected users to a new version using two Deployments, two Services, and an Ingress configured to route by a condition. State that Kubernetes has no native way to do this and that support depends on the Ingress implementation.
  Why it matters: It distinguishes conditional A/B routing from simply sending every user to the new version.

Key terms: A/B deployment strategy, Deployments, Services, Ingress object, Ingress implementations

15.3.3 The Blue/Green strategy

Explains how two Deployments and a Service label selector enable an all-at-once traffic switch from Blue to Green.

• Blue Green traffic switch: Explain how a Blue/Green deployment uses two Deployments and a Service to switch traffic from one group of pods to the other.
  Why it matters: The switch is a Service configuration change, not a requirement to replace the Blue pods first.

Key terms: Blue/Green strategy, Blue Deployment, Green Deployment, Service, labels, label selector

15.3.4 Traffic shadowing

Explains how traffic shadowing tests a new application version with mirrored production traffic without serving its responses to clients.

• Traffic shadowing flow: Explain how a new version receives mirrored production traffic while the existing version continues to serve clients, and why this helps test the new version in production conditions.
  Why it matters: It lets you see how a new version behaves under real production traffic without making clients depend on its responses.
• Ingress implementation requirement: State whether Kubernetes provides traffic shadowing natively and where the needed functionality may be available.
  Why it matters: You need a suitable Ingress implementation rather than assuming the Deployment and Service provide mirroring on their own.

Key terms: traffic shadowing, Deployment, pod labels, label selector, Service, Ingress, Ingress implementations

15.4 Summary

Summarizes how Deployments extend ReplicaSets to update pods, how update strategies differ, and how ownership affects deletion.