Chapter 14: Scaling and maintaining pods with ReplicaSets
The chapter introduces ReplicaSets as a way to automate the creation and management of many copies of a pod.
After this chapter you will be able to
- ReplicaSet purpose at scale. Explain why managing many copies of a pod directly is difficult and what a ReplicaSet automates.
- ReplicaSet pod creation and maintenance. Explain how a ReplicaSet uses a Pod template and desired replica count to create pods, and why it is useful even when only one pod is needed.
- ReplicaSets beneath Deployments. Explain why applications are typically deployed through Deployments rather than directly through ReplicaSets, and why ReplicaSets still matter.
- ReplicaSet spec fields. Describe the roles of the selector, template, and replicas fields in a ReplicaSet spec, including which fields are required and what happens when replicas is omitted.
- Selector and template label match. Explain why the labels in the Pod template must match the ReplicaSet selector and what happens if they do not.
- ReplicaSet inspection commands. Describe what kubectl get, kubectl get -o wide, and kubectl describe reveal about a ReplicaSet.
- Selector-based pod listing. Explain how to list pods matching a ReplicaSet and account for the five pods in the example.
- ReplicaSet pod log access. Describe how to request logs through a ReplicaSet name and when to select multiple pods or containers.
- Pod ownership and deletion. Explain how a pod records its owner and what happens to dependent pods when their ReplicaSet is deleted.
- ReplicaSet control of pods. Explain what the controller indication in a pod’s owner reference means for managing that pod.
- ReplicaSet updateable properties. Distinguish the ReplicaSet’s immutable label selector from its updateable desired replica count and Pod template, and explain that changing the desired count scales the ReplicaSet.
- ReplicaSet replica count changes. Describe how to scale a ReplicaSet up or down by changing its desired replica count, and how to verify the resulting pod count.
- Scale down pod selection. Explain the main rules Kubernetes uses to choose pods for deletion when a ReplicaSet is scaled down, including how deletion cost and node distribution affect the choice.
- Pod template label placement. Describe how to add a version label to pods created by a ReplicaSet, and distinguish the Pod template’s labels from the ReplicaSet’s own labels and selector.
- Pod template update effects. Explain which pods reflect a ReplicaSet Pod-template update and what happens when the ReplicaSet is subsequently scaled up.
- ReplicaSet controller responsibilities. Explain that the ReplicaSet controller detects and processes changes to a ReplicaSet, creates or deletes pods when it is scaled, and records those actions as Event objects.
- Controller reconciliation control loop. Explain how a controller responds when an owner or dependent object changes by comparing the dependents’ actual state with the desired state in the owner and changing the dependents if needed.
- ReplicaSet pod count reconciliation. Trace how the ReplicaSet controller responds when its associated pod count differs from the desired number in the ReplicaSet.
- Pod count reconciliation. Explain how the ReplicaSet controller responds when a managed pod is deleted or an extra pod matching its label selector is created.
- Replacement after node failure. Trace what happens to a ReplicaSet’s pods when their node becomes unavailable, including why replacement is not immediate and what happens when the node returns.
- Replica count versus readiness. Distinguish the ReplicaSet’s guarantee of a desired number of present pods from a guarantee that those pods are healthy and ready to serve traffic.
- Label-based pod removal. Explain how to remove a faulty pod from a ReplicaSet’s control by changing a label required by its selector, and why the controller creates a replacement.
- ReplicaSet deletion and pod cleanup. Explain why deleting a ReplicaSet also deletes the pods that belong to it, and identify the garbage collector as the component that performs the cleanup.
- ReplicaSet deletion and controlled pods. Explain what happens to the pods a ReplicaSet controls when the ReplicaSet is deleted in the manner described here.
- Preserving pods during ReplicaSet replacement. Explain why changing an immutable ReplicaSet label selector requires replacing the ReplicaSet, and how orphaning its pods avoids deleting them. Describe what happens to their ownership references and how a new ReplicaSet with a matching selector can take them over.
What it builds on
- Creating the Pod object from the YAML file (chapter 5) · Creating an individual Pod object directly.
- Creating pods from YAML or JSON files (chapter 5) · Pods can be created directly from manifests.
- Using label selectors in object manifests (chapter 7) · Label selectors can be used in object manifests to select objects.
- Introducing services (chapter 11) · Services expose pods.
- Creating a YAML manifest for a pod (chapter 5) · Pod manifests provide the basis for understanding the Pod template.
- Using label selectors for object management with kubectl (chapter 7) · Using label selectors with kubectl.
- Persisting files across container restarts (chapter 9) · Earlier use of generateName to create uniquely named pod copies.
- Viewing application logs (chapter 5) · Viewing application logs.
Section by section
Introduction
The chapter introduces ReplicaSets as a way to automate the creation and management of many copies of a pod.
- ReplicaSet purpose at scale: Explain why managing many copies of a pod directly is difficult and what a ReplicaSet automates.
Why it matters: This explains why you would use a ReplicaSet instead of creating every pod yourself. - ReplicationController predecessor status: Distinguish the deprecated ReplicationController from the ReplicaSet at the level described here.
Why it matters: This helps you recognize the older object type without treating it as a different concept in this chapter.
Key terms: Pod objects, pod replicas, ReplicaSet object, ReplicationController, ReplicaSet, deprecated
14.1 Introducing ReplicaSets
This section introduces ReplicaSets as a way to create and maintain pod replicas, while distinguishing their role from Services and Deployments.
- ReplicaSet pod creation and maintenance: Explain how a ReplicaSet uses a Pod template and desired replica count to create pods, and why it is useful even when only one pod is needed.
Why it matters: A ReplicaSet helps keep the requested pods available, even when the requested count is one. - ReplicaSet pod membership: Describe how a ReplicaSet determines which pods belong to it.
Why it matters: Matching labels define which pods the ReplicaSet treats as part of its group. - Service and ReplicaSet roles: Distinguish managing a set of pods with a ReplicaSet from exposing those pods together with a Service.
Why it matters: Creating and maintaining pods does not by itself give clients one Service through which to reach them. - ReplicaSets beneath Deployments: Explain why applications are typically deployed through Deployments rather than directly through ReplicaSets, and why ReplicaSets still matter.
Why it matters: Understanding ReplicaSets helps explain what a Deployment relies on, without treating a ReplicaSet as the tool for application updates.
Key terms: ReplicaSet, Pod template, replicas, label selector, pod labels, Service object, Deployment, declaratively
14.1.1 Creating a ReplicaSet
Shows how to replace three separately defined Kiada pods with a ReplicaSet manifest and explains the key requirements of its spec.
- ReplicaSet spec fields: Describe the roles of the selector, template, and replicas fields in a ReplicaSet spec, including which fields are required and what happens when replicas is omitted.
Why it matters: These fields express which Pods the ReplicaSet counts and how many copies it should create. - Selector and template label match: Explain why the labels in the Pod template must match the ReplicaSet selector and what happens if they do not.
Why it matters: The match lets the ReplicaSet count the Pods it creates toward its target. - Kiada ReplicaSet manifest details: Describe how the Kiada example replaces three separate Pod manifests with one ReplicaSet manifest, including its desired count, generated Pod names, and creation command.
Why it matters: The example connects the ReplicaSet fields to the manifest used for the existing Kiada service.
Key terms: ReplicaSet, spec, selector, template, replicas, labels, Pod template, desired number of replicas, Kiada, apps API group
14.1.2 Inspecting a ReplicaSet and its pods
This section shows how to inspect a ReplicaSet and its pods, understand their names, and view their logs.
- ReplicaSet inspection commands: Describe what kubectl get, kubectl get -o wide, and kubectl describe reveal about a ReplicaSet.
Why it matters: These commands let you check both the ReplicaSet’s replica counts and the template it uses. - Selector-based pod listing: Explain how to list pods matching a ReplicaSet and account for the five pods in the example.
Why it matters: The selector helps you find relevant pods and explains why the example includes both existing and newly created pods. - Generated ReplicaSet pod names: Explain how new ReplicaSet pods receive names and why random suffixes suit them.
Why it matters: Generated names explain the suffixes you see when inspecting newly created pods. - ReplicaSet pod log access: Describe how to request logs through a ReplicaSet name and when to select multiple pods or containers.
Why it matters: You can follow requests across replicas without typing unpredictable pod names.
Key terms: kubectl get, -o wide, kubectl describe, readyReplicas, Pod template, label selector, kubectl get pods, adopted, replicas, generateName
14.1.3 Understanding pod ownership
Explains how a pod records its ReplicaSet owner, how that ownership affects deletion, and why the pod should be managed through the ReplicaSet.
- Pod ownership and deletion: Explain how a pod records its owner and what happens to dependent pods when their ReplicaSet is deleted.
Why it matters: Ownership explains why deleting a ReplicaSet can also remove its pods. - ReplicaSet control of pods: Explain what the controller indication in a pod’s owner reference means for managing that pod.
Why it matters: Managing the ReplicaSet rather than its individual pods keeps control in the object responsible for them.
Key terms: ownerReferences, owner, dependent, garbage collector, controller: true, ReplicaSet, controlled
14.2 Updating a ReplicaSet
This section identifies which ReplicaSet properties can be updated and explains that changing the desired replica count scales the ReplicaSet.
- ReplicaSet updateable properties: Distinguish the ReplicaSet’s immutable label selector from its updateable desired replica count and Pod template, and explain that changing the desired count scales the ReplicaSet.
Why it matters: It clarifies which ReplicaSet settings you can change and which change controls scaling.
Key terms: desired number of replicas, Pod template, label selector, immutable, scale
14.2.1 Scaling a ReplicaSet
This subsection shows how to change a ReplicaSet’s replica count, explains which pods are removed when scaling down, and describes scaling to zero without deleting the ReplicaSet.
- ReplicaSet replica count changes: Describe how to scale a ReplicaSet up or down by changing its desired replica count, and how to verify the resulting pod count.
Why it matters: You can adjust how many instances of an application run without creating or deleting pods individually. - Scale down pod selection: Explain the main rules Kubernetes uses to choose pods for deletion when a ReplicaSet is scaled down, including how deletion cost and node distribution affect the choice.
Why it matters: The deletion rules help preserve healthy replicas and avoid concentrating the remaining pods on one node. - Zero replica shutdown: Explain what happens when a ReplicaSet is scaled to zero and why this can be useful for a temporary shutdown.
Why it matters: Scaling to zero stops all instances while preserving the ReplicaSet for a later restart.
Key terms: ReplicaSet, replicas, kubectl scale, kubectl edit, pod-deletion-cost, related replicas, ready, zero replicas, ReplicaSet object
14.2.2 Updating the Pod template
Shows how to change a ReplicaSet’s Pod template and why the change affects newly created pods but not existing ones.
- Pod template label placement: Describe how to add a version label to pods created by a ReplicaSet, and distinguish the Pod template’s labels from the ReplicaSet’s own labels and selector.
Why it matters: Putting a label in the right part of the manifest determines whether new pods receive it and whether the API accepts the update. - Pod template update effects: Explain which pods reflect a ReplicaSet Pod-template update and what happens when the ReplicaSet is subsequently scaled up.
Why it matters: This explains why editing a ReplicaSet’s template alone does not update its running pods.
Key terms: Pod template, metadata.labels, selector, kubectl edit, kubectl label, ReplicaSet, scale
14.3 Understanding the operation of the ReplicaSet controller
Introduces the ReplicaSet controller as the component that processes ReplicaSet changes, adjusts pods during scaling, and records its actions as events.
- ReplicaSet controller responsibilities: Explain that the ReplicaSet controller detects and processes changes to a ReplicaSet, creates or deletes pods when it is scaled, and records those actions as Event objects.
Why it matters: It connects changes to a ReplicaSet with the component that acts on its pods and reports those actions.
Key terms: ReplicaSet controller, Event object, kubectl describe, kubectl get events
14.3.1 Introducing the reconciliation control loop
This section explains how controllers reconcile actual state with desired state, using the ReplicaSet controller’s pod-count decisions as an example.
- Controller reconciliation control loop: Explain how a controller responds when an owner or dependent object changes by comparing the dependents’ actual state with the desired state in the owner and changing the dependents if needed.
Why it matters: This pattern explains why a controller responds to changes without requiring you to specify each corrective action. - ReplicaSet pod count reconciliation: Trace how the ReplicaSet controller responds when its associated pod count differs from the desired number in the ReplicaSet.
Why it matters: It explains how a ReplicaSet maintains its specified number of pods as conditions change.
Key terms: controller, owning object, dependent objects, desired state, reconciliation control loop, ReplicaSet controller, associated pods, desired number, Pod template, replicas
14.3.2 Understanding how the ReplicaSet controller reacts to pod changes
This section shows how a ReplicaSet restores its desired pod count after pod changes or node failure, and why that count does not guarantee healthy, ready replicas.
- Pod count reconciliation: Explain how the ReplicaSet controller responds when a managed pod is deleted or an extra pod matching its label selector is created.
Why it matters: It explains why manually changing the pod population does not leave the ReplicaSet at the wrong size. - Replacement after node failure: Trace what happens to a ReplicaSet’s pods when their node becomes unavailable, including why replacement is not immediate and what happens when the node returns.
Why it matters: Automatic replacement after node failure is the section’s main reason for running these pods through a ReplicaSet rather than directly. - Replica count versus readiness: Distinguish the ReplicaSet’s guarantee of a desired number of present pods from a guarantee that those pods are healthy and ready to serve traffic.
Why it matters: The requested replica count alone cannot tell you how many replicas can currently handle traffic.
Key terms: ReplicaSet controller, replicas, label selector, desired state, NotReady, Kubelet, Terminating, liveness probe, readiness probe, ready
14.3.3 Removing a pod from the ReplicaSet’s control
Shows how changing a pod’s labels removes it from a ReplicaSet’s control, prompts a replacement, and leaves the original pod available for troubleshooting.
- Label-based pod removal: Explain how to remove a faulty pod from a ReplicaSet’s control by changing a label required by its selector, and why the controller creates a replacement.
Why it matters: You can take a faulty pod out of the ReplicaSet without waiting to finish troubleshooting it. - Detached pod ownership and cleanup: Describe what happens to the removed pod after the replacement appears, including its ownership reference and who must delete it.
Why it matters: Removing a pod from the ReplicaSet does not dispose of the pod you kept for debugging.
Key terms: ReplicaSet controller, label selector, replicas, rel=stable, rel=debug, ownerReferences, ReplicaSet, faulty pod
14.4 Deleting a ReplicaSet
Deleting a ReplicaSet signals that its pod replicas are no longer wanted, so the garbage collector deletes them too.
- ReplicaSet deletion and pod cleanup: Explain why deleting a ReplicaSet also deletes the pods that belong to it, and identify the garbage collector as the component that performs the cleanup.
Why it matters: Deleting a ReplicaSet normally removes its pods as well, not just the ReplicaSet object.
Key terms: ReplicaSet, pod replicas, garbage collector
14.4.1 Deleting a ReplicaSet and all associated pods
This subsection explains that deleting a ReplicaSet also deletes the pods it controls.
- ReplicaSet deletion and controlled pods: Explain what happens to the pods a ReplicaSet controls when the ReplicaSet is deleted in the manner described here.
Why it matters: Deleting the ReplicaSet this way removes its pods too, not just the ReplicaSet object.
Key terms: ReplicaSet, pods it controls
14.4.2 Deleting a ReplicaSet while preserving the pods
Explains how to delete a ReplicaSet without deleting its pods, and how a new ReplicaSet can take ownership of those pods.
- Preserving pods during ReplicaSet replacement: Explain why changing an immutable ReplicaSet label selector requires replacing the ReplicaSet, and how orphaning its pods avoids deleting them. Describe what happens to their ownership references and how a new ReplicaSet with a matching selector can take them over.
Why it matters: Preserving the pods can avoid making the service unavailable while the ReplicaSet is replaced.
Key terms: label selector, orphan, ownerReferences, ReplicaSet
14.5 Summary
Summarizes how ReplicaSets define and maintain a desired number of identical pods, and what happens when their templates or ownership change.
Where this is used later
- (chapter intro) (chapter 15) · Introduces ReplicaSets as a way to deploy pods.
- Introducing Deployments (chapter 15) · Assumes familiarity with ReplicaSets and their pods.
- Understanding the DaemonSet object (chapter 17) · Introduces ReplicaSets as a way to maintain pod replicas.
- Updating a Deployment (chapter 15) · Deployment updates address the limitation identified here.
- The RollingUpdate strategy (chapter 15) · Inspecting a ReplicaSet and its pods.
- Scaling a Deployment (chapter 15) · Scaling a Deployment builds on the idea of changing the desired number of replicas.
- Comparing StatefulSets with Deployments (chapter 16) · The idea of changing a workload’s replica count.
- Summary (chapter 15) · Introduces the ReplicaSet Pod template that a Deployment extends.
Concepts explained in this chapter
- ReplicaSetA ReplicaSet is a Kubernetes resource that maintains a specified number of identical pod replicas.
- label selectorA label selector is a Kubernetes query expression that filters objects by label values or by the presence or absence of label keys.
- pod templateA pod template is a configuration embedded in a workload resource that defines the pods to be created, including their metadata and containers.
- Kubernetes controllerA Kubernetes controller is a control loop that observes cluster state and takes actions to move it toward a specified desired state.
- kubeletThe kubelet is the agent on a Kubernetes node that manages the applications assigned to that node and reports their status.
- readiness checkA readiness endpoint is an application-provided HTTP endpoint that reports whether the application is ready to serve requests.
- replica countA desired replica count is the configured number of pod replicas that a workload resource should maintain.
- kubectl getkubectl get is a kubectl command that retrieves Kubernetes objects of a specified type from the API.
- kubectl logskubectl logs is a Kubernetes command-line operation that retrieves output streams captured from a container.
- kubectl scale deploymentkubectl scale is a kubectl command that changes the number of replicas maintained by a scalable Kubernetes resource.
- owner referenceThe ownerReferences field is Kubernetes object metadata that identifies the objects responsible for managing the object.
- reconciliationA reconciliation loop is a repeated control process that compares observed state with desired state and makes corrective changes.
- podA pod object is a Kubernetes API resource representing the desired and observed state of a pod.
← Chapter 13: Routing traffic using the Gateway API
Chapter 15: Automating application updates with Deployments →
These guides are generated from the text of Manning books by Manning's knowledge graph and link to the sections they draw on. The full books are available on liveBook and at manning.com.