Deployments and ReplicaSets are the tools that keep your applications running reliably, even when things go wrong. For the CKA exam, you need to know how to create, update, and scale these resources because they are the backbone of almost every real-world Kubernetes workload.
Jump to a section
A simple way to picture Deployments and ReplicaSets
A head chef's recipe book is the master plan for a perfect dish, but the kitchen operates through a brigade system. The head chef writes the recipe card for tonight's special — exactly how many grams of each ingredient, the cooking temperature, and the plating instructions. That recipe card is a Deployment in Kubernetes.
The head chef does not cook the dish themselves. Instead, they hand the recipe to a sous chef, who is responsible for ensuring that exactly three identical portions of that dish are prepared and ready at the pass at all times. The sous chef is a ReplicaSet. They keep watch. If one plate gets dropped, the sous chef immediately tells a line cook to fire another portion. If a new recipe card replaces the old special, the sous chef smoothly phases out the old portions and brings up the new ones, one plate at a time, so the kitchen never serves a half-finished dish.
The head chef never touches a single pan. The sous chef never changes the recipe. The line cooks just follow the instructions. This division of labour means the kitchen can scale from a quiet Tuesday to a Saturday night rush by simply telling the sous chef to prepare ten portions instead of three. The recipe card (Deployment) declares the desired state. The sous chef (ReplicaSet) drives the actual state to match it. Without the sous chef, the head chef would have to run around fixing every dropped plate themselves. Without the head chef's recipe, there is no standard to maintain.
Kubernetes is a system for running containers — lightweight, self-contained packages of software — across a cluster of computers. But if you just run a container, what happens if that container crashes? What if you need five copies of it to handle traffic? What if you need to update the software without taking the whole service offline? Deployments and ReplicaSets are the Kubernetes resources that answer these questions.
A ReplicaSet is a resource whose only job is to ensure a specified number of identical Pods are running at all times. A Pod is the smallest deployable unit in Kubernetes, usually wrapping one container. The ReplicaSet constantly watches the cluster. If a Pod dies — because the node it was on failed, or the application inside it crashed — the ReplicaSet notices the count dropped and immediately creates a replacement Pod. This is called a 'self-healing' mechanism. You tell the ReplicaSet, 'I want three copies,' and it does whatever is necessary to maintain three copies.
A Deployment is a higher-level resource that manages ReplicaSets. You almost never create a ReplicaSet directly in modern Kubernetes; you create a Deployment, and the Deployment creates a ReplicaSet for you. The Deployment adds the ability to perform rolling updates and rollbacks. A rolling update means you change the container image (the software version) in the Deployment spec, and the Deployment gradually replaces old Pods with new ones, one at a time, ensuring the application stays available throughout the process. If something goes wrong with the new version, you can rollback to an older ReplicaSet that still has the previous version.
Why does this matter? Before Deployments, administrators had to manually destroy old containers and start new ones, which caused downtime. They had to script their own health checks. With Deployments, you declare the desired state — 'I want three replicas of version 2.0 of my app' — and Kubernetes makes it happen.
Here are the key components:
A Deployment YAML manifest contains a template for the Pod, which includes the container image, ports, and environment variables.
The Deployment has a 'replicas' field that sets the target number of Pods.
When you create a Deployment, it creates a ReplicaSet with a hash-based name (like 'myapp-6fb7f8c9d4').
The ReplicaSet then creates the actual Pods with a name including the ReplicaSet hash.
If you update the Pod template (e.g., change the image tag), the Deployment creates a new ReplicaSet, scales it up, and scales the old ReplicaSet down to zero.
If you need to scale, you just change the 'replicas' field and the Deployment instructs the ReplicaSet to create or delete Pods.
Deployments support different update strategies. The default is 'RollingUpdate', which updates Pods gradually. You can control how many Pods can be unavailable during the update (maxUnavailable) and how many extra Pods can be created (maxSurge). The alternative strategy is 'Recreate', which kills all old Pods at once before creating new ones. Recreate causes downtime and is used for stateful applications that cannot have two versions running simultaneously.
A crucial point for beginners: a Deployment does not directly manage Pods. It manages ReplicaSets, which manage Pods. This is a three-tier hierarchy: Deployment -> ReplicaSet -> Pod.
When you delete a Deployment, Kubernetes deletes both the ReplicaSet and all Pods under it. If you delete just a ReplicaSet, the Deployment will recreate it because the Deployment's desired state still requires a ReplicaSet. If you delete a Pod managed by a ReplicaSet, the ReplicaSet recreates it. The only way to permanently remove Pods is to delete the Deployment or reduce the replicas count to zero.
Understanding the separation of concerns is critical: the Deployment handles versions and updates; the ReplicaSet handles count and self-healing; the Pod handles the actual running container.
Create a Deployment YAML manifest
You write a YAML file that declares the API version (apps/v1), kind (Deployment), metadata (name and labels), and spec. The spec includes the replica count, a selector for Pod labels, and a template for the Pod. This YAML is your declarative configuration. Without it, Kubernetes does not know what application you want to run.
Apply the Deployment to the cluster
You run 'kubectl apply -f deployment.yaml'. This sends your desired state to the Kubernetes API server. The scheduler and controller manager read the manifest and begin creating the necessary resources. Until you apply, nothing happens.
Kubernetes creates a ReplicaSet
The Deployment controller notices there is no ReplicaSet matching the Deployment, so it creates one. The ReplicaSet is named with a hash of the Pod template, like 'myapp-6fb7f8c9d4'. This hashing is crucial because it allows the Deployment to track multiple ReplicaSets during updates.
The ReplicaSet creates Pods
The ReplicaSet sees its desired replica count (e.g., 3) and creates the specified number of Pods using the Pod template from the Deployment. Each Pod has a unique name that includes the ReplicaSet hash (e.g., 'myapp-6fb7f8c9d4-abcde'). The scheduler places these Pods onto worker nodes.
Update the Deployment's image
You run 'kubectl set image deployment/myapp mycontainer=myrepo/myapp:2.0'. This changes the image field in the Pod template inside the Deployment spec. The Deployment controller detects the template change and creates a new ReplicaSet with a new hash. It then scales up the new ReplicaSet and scales down the old one, using the rolling update strategy. This is how zero-downtime deployments work.
Rollback if the update fails
If the new version crashes, you run 'kubectl rollout undo deployment/myapp'. The Deployment scales up the previous ReplicaSet (which still has the old image) and scales down the new one. The rollback happens with the same rolling update mechanism, so the application never fully goes down. This step is the safety net that makes Deployments production-ready.
An IT professional at a mid-size e-commerce company is responsible for the checkout service. The checkout service runs as a containerised application on a Kubernetes cluster. The company expects heavy traffic during a Black Friday sale. The IT professional uses a Deployment to manage the service.
Step one is to write a YAML file for the Deployment. They specify 'replicas: 3' for normal operation. The Deployment YAML includes the container image, which points to version 2.4 of the checkout application, and a health check endpoint that Kubernetes uses to verify the Pod is alive.
During the Black Friday sale, traffic spikes. The IT professional runs 'kubectl scale deployment checkout --replicas=10'. This command updates the Deployment's replicas field. The Deployment tells the existing ReplicaSet to create seven new Pods. The application stays up the entire time because existing Pods continue serving traffic while new ones start. After the sale, the IT professional scales back down to three replicas.
A developer pushes a bug fix that bumps the container image to version 2.5. The IT professional updates the Deployment by running 'kubectl set image deployment/checkout checkout=myrepo/checkout:2.5'. The Deployment sees the change in the Pod template and creates a new ReplicaSet with the new image hash. It then scales up the new ReplicaSet to one Pod while keeping the old ReplicaSet at three. Once the new Pod passes its health check, the Deployment scales the old ReplicaSet down to two and the new up to two. This continues until all Pods run version 2.5. The entire update happens with zero downtime.
If version 2.5 contains a memory leak and Pods start crashing, the IT professional runs 'kubectl rollout undo deployment/checkout'. The Deployment immediately scales up the old ReplicaSet (which still has version 2.4) and scales down the new one. The service is restored within seconds.
In a real incident, the IT professional would:
Check the rollout status with 'kubectl rollout status deployment/checkout'
View the rollout history with 'kubectl rollout history deployment/checkout'
Describe the Deployment to see conditions like 'Progressing' or 'Available'
Look at ReplicaSet events with 'kubectl describe replicaset'
This scenario is realistic: the IT professional never touches individual Pods. They manage the Deployment as a single object, and Kubernetes handles the plumbing. Without Deployments, the IT professional would have to write shell scripts to track versions, kill old Pods, start new ones, and monitor health — a fragile and error-prone process.
The CKA exam tests your ability to create, update, scale, and rollback Deployments on the command line. You will not have to write YAML from scratch often, but you will need to edit existing YAML and understand what each field does.
The exam frequently asks you to:
Create a Deployment with a specific name, image, and replica count using 'kubectl create deployment' or by writing a YAML file.
Scale a Deployment up or down using 'kubectl scale' or by editing 'spec.replicas'.
Perform a rolling update by changing the image with 'kubectl set image' and verify the rollout status.
Rollback a failed update using 'kubectl rollout undo'.
Expose a Deployment as a Service to make it network-accessible.
Common traps the exam sets:
The exam might ask you to 'update the image' but the correct command is 'kubectl set image deployment/<name> <container-name>=<new-image>'. Many candidates forget the container name.
The exam might present a scenario where a Deployment has zero replicas and ask why Pods are not running. The answer is that replicas is zero, not that the image is broken.
The exam might ask you to 'rollback to revision 2'. You need to use 'kubectl rollout undo deployment/<name> --to-revision=2'. Revision numbers come from 'kubectl rollout history'.
The exam might ask you to pause a rollout with 'kubectl rollout pause deployment/<name>' before making changes, then resume. This is a real exam scenario.
The exam loves testing the difference between 'kubectl expose' (creates a Service) and 'kubectl create service' (creates a Service directly). For Deployments, 'kubectl expose' is the correct way to generate a Service from a Deployment.
Key definitions to memorise for the exam:
'maxSurge': the maximum number of Pods that can be created above the desired replicas during an update. Default is 25%.
'maxUnavailable': the maximum number of Pods that can be unavailable during an update. Default is 25%.
'revisionHistoryLimit': the number of old ReplicaSets to retain for rollback. Default is 10.
'strategy.type': either 'RollingUpdate' (default) or 'Recreate'.
'spec.template': the Pod template that defines the Pod's containers, volumes, and other settings.
The exam will not ask you to create a raw ReplicaSet. You only need to know that Deployments manage ReplicaSets. However, you need to understand that when you run 'kubectl get replicaset', you will see the ReplicaSets created by Deployments.
A frequent question pattern: 'A developer wants to update a Deployment with a new image but ensure that at least three Pods are always available. What should they set?' The answer involves adjusting 'maxUnavailable' to 0 or 'maxSurge' to ensure capacity.
Practice by doing: create a Deployment with 'kubectl create deployment nginx --image=nginx --replicas=3'. Then inspect the ReplicaSet. Then update the image. Then undo. This muscle memory is crucial because the exam is a live lab environment.
A Deployment manages ReplicaSets, and a ReplicaSet manages Pods — this three-tier hierarchy is the core model you must internalise.
The ReplicaSet is a self-healing controller that always maintains the exact number of Pods specified, recreating any that fail or are deleted.
Deployments support rolling updates and rollbacks; ReplicaSets do not, which is why Deployments are the standard resource for stateless applications.
The 'maxSurge' and 'maxUnavailable' fields control the speed and safety of rolling updates, with defaults of 25% each.
To scale a Deployment, change the 'replicas' field using 'kubectl scale' or by editing the YAML — never manually delete or create individual Pods.
The 'kubectl rollout undo' command reverts to the previous ReplicaSet revision, not the previous image tag — revision history is based on the Pod template, not image versions.
Deleting a Pod under a ReplicaSet is futile because the ReplicaSet will immediately recreate it — always change the replicas count or delete the Deployment.
The 'spec.template' inside a Deployment defines the Pod's containers, volumes, and other configuration — any change to this template triggers a new ReplicaSet.
These come up on the exam all the time. Here's how to tell them apart.
Deployment
Manages ReplicaSets and supports rolling updates and rollbacks.
Can be paused and resumed during updates.
Automatically creates ReplicaSets based on Pod template changes.
ReplicaSet
Only ensures a specified number of Pods are running.
Has no update or rollback capabilities.
Is created automatically by a Deployment and is rarely defined manually.
Rolling Update Strategy
Replaces Pods gradually, keeping the application available.
Uses maxSurge and maxUnavailable to control the pace.
Is the default strategy for Deployments.
Recreate Strategy
Kills all existing Pods before creating new ones.
Causes downtime during the update.
Used for stateful applications or when two versions cannot coexist.
kubectl scale
Changes the replica count of a Deployment.
Takes effect immediately without creating a new ReplicaSet.
Used for scaling up or down based on load.
kubectl set image
Changes the container image in the Pod template.
Triggers a rollout and creates a new ReplicaSet.
Used for application updates and deployments.
kubectl rollout undo
Reverts to a previous ReplicaSet revision.
Does not delete the current ReplicaSet immediately — it scales it down.
Can target a specific revision with --to-revision.
kubectl rollout history
Lists all revisions for a Deployment.
Shows revision numbers and ReplicaSet names.
Does not change the current state of the Deployment.
Mistake
If I delete a Pod that is managed by a ReplicaSet, the ReplicaSet will not recreate it because I deleted it deliberately.
Correct
The ReplicaSet will always recreate the Pod to maintain the desired replica count, regardless of how the Pod was deleted. The only way to remove Pods permanently is to delete the ReplicaSet or Deployment, or reduce the replicas count.
Beginners think that deleting a Pod is a deliberate action that Kubernetes should honour, but the ReplicaSet is a desired-state controller that does not care about intent — it only cares about count.
Mistake
A Deployment directly manages Pods, so I can edit Pods inside a Deployment to change their configuration.
Correct
A Deployment manages ReplicaSets, which manage Pods. You should never edit the Pods directly. Changes must be made to the Pod template inside the Deployment spec so that a new ReplicaSet is created with the correct configuration.
The hierarchy (Deployment -> ReplicaSet -> Pod) is invisible to beginners. They see Pods listed in 'kubectl get pods' and assume they can edit them like any other object.
Mistake
Rolling updates update all Pods at the same time to minimise the time of the update.
Correct
Rolling updates update Pods gradually, one by one (or in batches), to ensure the application stays available. The default strategy updates only a percentage of Pods at a time, not all simultaneously.
The word 'rolling' suggests continuous movement, but the actual behaviour is incremental replacement. Beginners conflate 'rolling' with 'immediate' because they think faster is better.
Mistake
If I set 'replicas: 5' in a Deployment, exactly five Pods will always run, and I can rely on that number for capacity planning.
Correct
The ReplicaSet will attempt to maintain five Pods, but if nodes are out of resources or the image is invalid, Pods may fail to start. Also, during rolling updates, the actual number may temporarily exceed five due to maxSurge. The declarative count is a target, not a guarantee.
Newcomers treat declarative configuration as a contract rather than a goal. They do not yet understand that Kubernetes is a continuous reconciliation system that works with constraints like resource limits and scheduling failures.
Mistake
Deployments and ReplicaSets are interchangeable, so I can use either one to run a stateless application.
Correct
ReplicaSets do not support rolling updates or rollbacks. You should always use a Deployment for stateless applications unless you have a very specific reason to use a bare ReplicaSet (which is rare). Deployments provide the update and rollback features that ReplicaSets lack.
The names sound similar and both manage Pods, so beginners assume they are two flavours of the same thing. They do not understand that a Deployment is an abstraction that wraps a ReplicaSet with additional capabilities.
Mistake
When I run 'kubectl rollout undo deployment/myapp', it reverts to the immediately previous version of the application.
Correct
'kubectl rollout undo' reverts to the previous ReplicaSet, which may not be the immediate previous revision if multiple updates happened. The command defaults to the last ReplicaSet in the revision history, but the history is based on changes to the Pod template, not sequential image tags.
Beginners think 'undo' means 'one step back' like an edit menu. In Kubernetes, 'undo' means 'go to the last ReplicaSet that was active before the current one', which could be several revisions behind if some revisions were skipped or cleaned up.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
A ReplicaSet ensures a specified number of Pods are running. A Deployment is a higher-level resource that manages ReplicaSets and adds support for rolling updates and rollbacks.
Yes, but the ReplicaSet will recreate it immediately because the desired replica count is still set. To permanently remove Pods, scale the Deployment down or delete it.
Run 'kubectl rollout undo deployment/<name>'. This reverts to the previous ReplicaSet. You can specify a revision with '--to-revision=N'.
The default strategy is 'RollingUpdate', which replaces Pods gradually to avoid downtime. You can change it to 'Recreate' in the YAML.
Common reasons include: the container image name is wrong, the image tag does not exist, the cluster has insufficient resources, or the image registry requires authentication. Use 'kubectl describe pod' to see the error.
Run 'kubectl rollout history deployment/<name>'. This shows the revision numbers and the ReplicaSets associated with each change. Only changes to the Pod template are recorded.
maxSurge is the maximum number of Pods that can be created above the desired replica count during an update. maxUnavailable is the maximum number of Pods that can be unavailable. Both default to 25% of the replica count.
No. You create a Deployment, and Kubernetes automatically creates the ReplicaSet. Creating a ReplicaSet directly is rarely needed and does not give you rolling updates or rollbacks.
You've finished Deployments and ReplicaSets. Continue through the CKA study guide to build a complete picture of the exam.
Done with this chapter?