Using kubectl, Deployments can be created, inspected, scaled, updated, and rolled back. These operations demonstrate how Deployments automate the application lifecycle. A simple NGINX web server will be deployed.
Before you begin, ensure you have a running Kubernetes cluster and kubectl is configured to interact with it. If you followed the setup guide in Chapter 1, your local Minikube or Kind cluster is ready for this exercise.
First, we create a YAML manifest file that describes our desired state. This declarative approach is central to managing Kubernetes resources effectively. Create a file named nginx-deployment.yaml and add the following content:
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-deployment
spec:
replicas: 3
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx:1.21.6
ports:
- containerPort: 80
Let's briefly examine the structure of this manifest:
apiVersion: apps/v1: Specifies the API version for the Deployment object.kind: Deployment: Defines the resource type as a Deployment.metadata.name: Names our Deployment nginx-deployment.spec.replicas: 3: Instructs the controller to maintain exactly three running Pods for this application.spec.selector: Tells the Deployment which Pods to manage. The matchLabels field must match the labels defined in the Pod template (spec.template.metadata.labels). This connection is how the Deployment finds its Pods.spec.template: This is the blueprint for the Pods the Deployment will create. It contains the standard Pod metadata (with labels) and spec (with the container definition).spec.template.spec.containers: Here we define a single container using the nginx:1.21.6 image.With the manifest file ready, apply it to your cluster using kubectl apply. This command sends the manifest to the Kubernetes API server, which then initiates the creation of the resources.
kubectl apply -f nginx-deployment.yaml
You should see the output deployment.apps/nginx-deployment created. Kubernetes now works to match the cluster's current state to the desired state defined in your file. The Deployment controller creates a ReplicaSet, which in turn creates three Pods based on your template.
Let's verify the resources that were created.
First, check the status of the Deployment itself:
kubectl get deployments
The output should show that 3 replicas are desired, current, up-to-date, and available.
NAME READY UP-TO-DATE AVAILABLE AGE
nginx-deployment 3/3 3 3 15s
Next, inspect the ReplicaSet created by the Deployment. You'll notice its name is generated from the Deployment name plus a unique hash.
kubectl get replicasets
NAME DESIRED CURRENT READY AGE
nginx-deployment-65c65b4f6d 3 3 3 30s
Finally, list the Pods to confirm that three instances are running:
kubectl get pods
NAME READY STATUS RESTARTS AGE
nginx-deployment-65c65b4f6d-7vjpl 1/1 Running 0 45s
nginx-deployment-65c65b4f6d-8xqz8 1/1 Running 0 45s
nginx-deployment-65c65b4f6d-kbnm4 1/1 Running 0 45s
Your application is gaining traffic, and you need to scale from three to five instances. The Deployment controller makes this simple. You can update the replicas field in your nginx-deployment.yaml file to 5 and re-apply it.
# In nginx-deployment.yaml
...
spec:
replicas: 5 # Changed from 3
...
Apply the updated manifest:
kubectl apply -f nginx-deployment.yaml
Kubernetes detects the change and reconciles the state. The Deployment controller updates the ReplicaSet's desired count, and the ReplicaSet controller creates two new Pods.
Verify the scaling operation by listing the Pods again:
kubectl get pods
NAME READY STATUS RESTARTS AGE
nginx-deployment-65c65b4f6d-7vjpl 1/1 Running 0 3m
nginx-deployment-65c65b4f6d-8xqz8 1/1 Running 0 3m
nginx-deployment-65c65b4f6d-kbnm4 1/1 Running 0 3m
nginx-deployment-65c65b4f6d-pxr9t 1/1 Running 0 30s
nginx-deployment-65c65b4f6d-q7z2l 1/1 Running 0 30s
You now have five Pods running. Scaling down is just as easy; simply reduce the replicas count and re-apply the manifest.
Imperative vs. Declarative Scaling You can also scale a Deployment using an imperative command like
kubectl scale deployment nginx-deployment --replicas=5. While this is quick for immediate adjustments, it creates a discrepancy between your live configuration and your manifest files. The declarativekubectl applyapproach is preferred as it keeps your version-controlled manifests as the single source of truth for your cluster's state.
Deployments excel at managing application updates with zero downtime. Let's update our NGINX application from version 1.21.6 to 1.23.3.
Modify the image field in nginx-deployment.yaml:
# In nginx-deployment.yaml
...
spec:
containers:
- name: nginx
image: nginx:1.23.3 # Changed from nginx:1.21.6
...
Apply the change:
kubectl apply -f nginx-deployment.yaml
When you apply this change, the Deployment controller initiates a rolling update. It creates a new ReplicaSet for the new version (1.23.3) and gradually scales it up while scaling down the old ReplicaSet for the previous version (1.21.6). This ensures that the application remains available throughout the update process.
The rolling update process managed by a Deployment. The controller transitions from an old ReplicaSet to a new one incrementally, ensuring service availability.
You can monitor the status of the rollout in real-time:
kubectl rollout status deployment/nginx-deployment
The command will exit once the rollout is complete. While it's in progress, you can open another terminal and run kubectl get pods to see new Pods being created and old ones being terminated.
Imagine the new version 1.23.3 has a critical bug. You need to revert to the previous, stable version immediately. Deployments maintain a revision history, making rollbacks straightforward.
First, view the revision history for your Deployment:
kubectl rollout history deployment/nginx-deployment
REVISION CHANGE-CAUSE
1 <none>
2 <none>
You can see two revisions. Revision 1 corresponds to the initial creation with image 1.21.6, and revision 2 corresponds to the update to 1.23.3.
To roll back to the previous version (revision 1), use the rollout undo command:
kubectl rollout undo deployment/nginx-deployment
This command tells the Deployment to revert to the previous configuration. The controller will now perform another rolling update, this time scaling down the new ReplicaSet (1.23.3) and scaling up the old one (1.21.6).
You can verify the rollback by describing the Deployment and checking the image tag:
kubectl describe deployment nginx-deployment | grep Image
The output will show the image has been reverted to nginx:1.21.6.
Once you are finished, you can delete the Deployment and all the resources it created (ReplicaSets and Pods) with a single command:
kubectl delete -f nginx-deployment.yaml
This command removes the nginx-deployment and instructs Kubernetes to terminate its associated ReplicaSets and Pods, cleaning up your cluster.
Was this section helpful?
kubectl operations, from fundamental to advanced topics.kubectl command-line tool, covering its syntax, common commands, and how to interact with Kubernetes clusters.© 2026 ApX Machine LearningEngineered with