Hands-on Practical: Creating and Updating Deployments

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.

Prerequisites

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.

Step 1: Define the Deployment

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.

Step 2: Create and Inspect the Deployment

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

Step 3: Scale the Application

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 declarative kubectl apply approach is preferred as it keeps your version-controlled manifests as the single source of truth for your cluster's state.

Step 4: Perform a Rolling Update

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.

Step 5: Roll Back a Faulty Update

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.

Step 6: Clean Up

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.