Operating Kubernetes Deployments

Introduction: Managing Your Running Application

Deploying an application is just the beginning. Once your application is running in Kubernetes, you need to know how to manage it, monitor its health, troubleshoot issues, and make changes as requirements evolve. This lesson focuses on the essential operations you'll perform regularly, forming the core toolkit for any Kubernetes practitioner. You'll learn how to check the status of your deployments and pods, view application logs, scale your application up or down, update it to new versions, and restart it when necessary. These commands allow you to declare your desired state and let Kubernetes handle the complex orchestration. The manifest file represents your goal, but these operational commands give you real-time visibility and control over the actual state of your cluster, which is critical for running production applications. We'll continue working with the my-web-deploy deployment from the previous lesson.

Checking Deployment and Pod Status

Join the 1M+ learners on CodeSignal

Be a part of our community of 1M+ users who develop and demonstrate their skills on CodeSignal

Viewing Application Logs

Understanding what your application is doing requires looking at its logs. Logs are the primary way that applications communicate what's happening internally, and being able to view logs quickly is essential for debugging issues and monitoring application behavior. In traditional server environments, you might SSH into a server and read log files directly. In Kubernetes, you use kubectl logs to retrieve logs from containers running in pods.

Before you can view logs, you need to know which pod to look at. If you have multiple replicas of your deployment, you'll have multiple pods, and you'll need to choose which one to examine. You can get the pod name from the output of kubectl get pods, but there's a more efficient way to do this programmatically. You can use kubectl with a JSONPath query to extract just the pod name:

Shell

kubectl get pod -n apps -l app=my-web -o jsonpath='{.items[0].metadata.name}'

kubectl get pod -n apps -l app=my-web -o jsonpath='{.items[0].metadata.name}'

This command uses the label selector -l app=my-web to find pods with that label, which matches the pods created by your deployment. The -o jsonpath option tells kubectl to output only the specific field you want, in this case, the name of the first pod in the list. This technique is useful in scripts or when you want to quickly grab a pod name without manually copying it from the output.

Once you have the pod name, you can view its logs with the kubectl logs command. Even though your current deployment has only one container, it's a best practice to always specify the container name explicitly using the -c flag:

Shell

kubectl logs -n apps <POD> -c web

kubectl logs -n apps <POD> -c web

This command retrieves the logs from the web container running in the specified pod. While Kubernetes will default to the only container if you omit -c in single-container pods, explicitly specifying the container name is a good habit to develop. When you encounter multi-container pods in production environments—such as pods with sidecar containers for logging, monitoring, or service mesh functionality—you'll need to specify which container's logs you want to view. Building this habit now will prevent confusion later.

The output shows you everything the application has written to standard output and standard error:

text

/docker-entrypoint.sh: /docker-entrypoint.d/ is not empty, will attempt to perform configuration
/docker-entrypoint.sh: Looking for shell scripts in /docker-entrypoint.d/
/docker-entrypoint.sh: Configuration complete; ready for start up
2026/01/15 10:39:24 [notice] 1#1: using the "epoll" event method
2026/01/15 10:39:24 [notice] 1#1: nginx/1.24.0
2026/01/15 10:39:24 [notice] 1#1: start worker processes
2026/01/15 10:39:24 [notice] 1#1: start worker process 29

/docker-entrypoint.sh: /docker-entrypoint.d/ is not empty, will attempt to perform configuration
/docker-entrypoint.sh: Looking for shell scripts in /docker-entrypoint.d/
/docker-entrypoint.sh: Configuration complete; ready for start up
2026/01/15 10:39:24 [notice] 1#1: using the "epoll" event method
2026/01/15 10:39:24 [notice] 1#1: nginx/1.24.0
2026/01/15 10:39:24 [notice] 1#1: start worker processes
2026/01/15 10:39:24 [notice] 1#1: start worker process 29

The logs show you that the nginx web server started successfully and is listening on port 80. If there were any errors during startup, they would appear in the logs. If the web server received any requests, you'd see log entries for those requests as well. The logs are your window into what's happening inside the container, and they're often the first place you look when troubleshooting issues.

The kubectl logs command also has several useful flags that modify its behavior:

-f: Follows the log output in real-time, similar to tail -f on a traditional server. This is useful for watching logs as they are generated.
--tail: Specifies the number of recent lines to retrieve, which is helpful when you only want to see the most recent entries.
--previous: Shows logs from the previous instance of a container, which is invaluable for debugging a container that has crashed and restarted.

These flags provide powerful options for inspecting logs, whether you're watching live traffic or investigating a past failure. You can combine these flags with the -c flag, for example: kubectl logs -n apps <POD> -c web -f --tail=50 to follow the last 50 lines of logs from the web container in real-time.

Scaling Your Deployment

One of the most powerful features of Kubernetes is the ability to scale your applications up or down quickly and easily. Scaling means changing the number of replicas of your application that are running. You might scale up to handle increased traffic, scale down to save resources during quiet periods, or scale to zero to completely stop an application without deleting its configuration. The kubectl scale command makes this operation simple and fast.

To scale your deployment up from one replica to two replicas, you use the following command:

Shell

kubectl scale deploy/my-web-deploy -n apps --replicas=2

kubectl scale deploy/my-web-deploy -n apps --replicas=2

This command tells Kubernetes to update the deployment's replica count to two. The output confirms that the deployment was scaled:

text

deployment.apps/my-web-deploy scaled

deployment.apps/my-web-deploy scaled

When you run this command, Kubernetes immediately begins creating a second pod. The deployment controller sees that the desired replica count is two but only one pod exists, so it creates another pod to match the desired state. This happens automatically without any additional commands from you. The new pod goes through the same lifecycle as the first one: it's scheduled to a node, the container image is pulled if necessary, the container starts, and the readiness probe checks whether it's ready to accept traffic.

You can verify that the scaling operation worked by checking the pods again:

Shell

kubectl get pods -n apps

kubectl get pods -n apps

Now you should see two pods instead of one:

text

NAME                                 READY   STATUS    RESTARTS   AGE
pod/my-web-deploy-7d4f8b9c5d-x7k2m   1/1     Running   0          10m
pod/my-web-deploy-7d4f8b9c5d-9p4tn   1/1     Running   0          15s

NAME                                 READY   STATUS    RESTARTS   AGE
pod/my-web-deploy-7d4f8b9c5d-x7k2m   1/1     Running   0          10m
pod/my-web-deploy-7d4f8b9c5d-9p4tn   1/1     Running   0          15s

The second pod has a different random suffix in its name, but it's part of the same deployment. Both pods are running the same container image with the same configuration. If you had a Service routing traffic to these pods, Kubernetes would automatically distribute requests between them, providing load balancing and redundancy. If one pod crashes, the other continues serving traffic while Kubernetes creates a replacement for the failed pod.

Scaling works in both directions. If you want to scale back down to one replica, you'd use the same command with --replicas=1. Kubernetes would then terminate one of the pods, choosing which one to remove based on various factors like pod age and node resource usage. The important thing to understand is that scaling is a declarative operation. You tell Kubernetes how many replicas you want, and it figures out what actions to take to achieve that state. You don't need to manually create or delete pods.

There are many reasons you might scale a deployment. During a traffic spike, you might scale up to handle the increased load. During maintenance, you might scale down to reduce resource usage. In development environments, you might scale to zero when you're not actively working to save costs. Some organizations use autoscaling, where Kubernetes automatically adjusts the replica count based on metrics like CPU usage or request rate. However, even with autoscaling, understanding manual scaling is important because it's the foundation that autoscaling builds upon.

Updating to New Container Images

As you develop your application, you'll frequently need to deploy new versions. This might be to add features, fix bugs, improve performance, or update dependencies. In Kubernetes, deploying a new version means updating the container image that your pods are running. The kubectl set image command provides a quick way to update the image without editing and reapplying the entire manifest file.

Before you can update to a new image, you need to have that image available in your container registry. In a real workflow, you'd build a new version of your application, tag it with a new version number like 1.0.1, and push it to Amazon ECR. For this example, let's assume you've already done that and your new image is available at 123456789012.dkr.ecr.us-east-1.amazonaws.com/my-web-app:1.0.1. Notice that the only difference from your original image is the tag changed from 1.0.0 to 1.0.1.

To update your deployment to use the new image, you run this command:

Shell

kubectl set image deploy/my-web-deploy web=123456789012.dkr.ecr.us-east-1.amazonaws.com/my-web-app:1.0.1 -n apps

kubectl set image deploy/my-web-deploy web=123456789012.dkr.ecr.us-east-1.amazonaws.com/my-web-app:1.0.1 -n apps

This command tells Kubernetes to update the container named web in the my-web-deploy deployment to use the new image. Remember that web is the name you gave to the container in your deployment manifest. The output confirms that the image was updated:

text

deployment.apps/my-web-deploy image updated

deployment.apps/my-web-deploy image updated

When you update the image, Kubernetes performs a rolling update. This means it gradually replaces the old pods with new pods running the new image, ensuring that your application remains available throughout the update process. This rolling update process is designed for zero-downtime deployments and follows a specific sequence:

A new ReplicaSet is created with the updated pod template containing the new image.
Kubernetes scales up the new ReplicaSet, creating new pods one by one (respecting the maxSurge setting).
As each new pod becomes ready, Kubernetes scales down the old ReplicaSet by terminating an old pod (respecting the maxUnavailable setting).
This continues until all old pods are replaced by new, healthy pods running the updated image.

You can watch this process in progress by checking the rollout status:

Shell

kubectl rollout status deploy/my-web-deploy -n apps

kubectl rollout status deploy/my-web-deploy -n apps

This command will show you the progress of the update:

text

Waiting for deployment "my-web-deploy" rollout to finish: 1 out of 2 new replicas have been updated...
Waiting for deployment "my-web-deploy" rollout to finish: 1 old replicas are pending termination...
deployment "my-web-deploy" successfully rolled out

Waiting for deployment "my-web-deploy" rollout to finish: 1 out of 2 new replicas have been updated...
Waiting for deployment "my-web-deploy" rollout to finish: 1 old replicas are pending termination...
deployment "my-web-deploy" successfully rolled out

This controlled process ensures that there's always at least one pod ready to serve traffic. If the new pods fail their readiness probes, Kubernetes pauses the rollout, preventing a bad deployment from taking down your application. This is why using specific image tags like 1.0.1 is critical; it gives Kubernetes a clear signal that a change has occurred, triggering this safe update mechanism.

Restarting Deployments

Sometimes you need to restart your pods without changing the container image. This might be necessary when you've updated a ConfigMap or Secret that your application reads, when you want to clear a stuck state in your application, or when you're troubleshooting an issue and want to see if a fresh start resolves it. The kubectl rollout restart command provides a clean way to restart all pods in a deployment.

To restart your deployment, you run this command:

Shell

kubectl rollout restart deploy/my-web-deploy -n apps

kubectl rollout restart deploy/my-web-deploy -n apps

This command triggers a rollout that replaces all pods with new pods running the same image. The output confirms that the restart was initiated:

text

deployment.apps/my-web-deploy restarted

deployment.apps/my-web-deploy restarted

When you restart a deployment, Kubernetes performs the same rolling update process that it uses when you change the image. It creates new pods, waits for them to become ready, and then terminates the old pods. You might restart pods without changing the image in several common scenarios:

To apply changes from an updated ConfigMap or Secret that the application only reads on startup.
To clear a stuck state or a memory leak in an application without deploying a new version.
To force a pod to re-initialize its state as part of a troubleshooting process.

It's important to understand the difference between restarting a deployment and manually deleting pods. If you delete a pod directly with kubectl delete pod, the deployment controller immediately creates a replacement, but this happens without the controlled rolling update process, which could cause a brief outage. The kubectl rollout restart command is safer because it uses the rolling update strategy to ensure availability.

After restarting, you can verify that new pods were created by checking their age:

Shell

kubectl get pods -n apps

kubectl get pods -n apps

You'll see that the pods have a recent creation time:

text

NAME                                 READY   STATUS    RESTARTS   AGE
pod/my-web-deploy-7d4f8b9c5d-k8m3p   1/1     Running   0          30s
pod/my-web-deploy-7d4f8b9c5d-t5n9q   1/1     Running   0          25s

NAME                                 READY   STATUS    RESTARTS   AGE
pod/my-web-deploy-7d4f8b9c5d-k8m3p   1/1     Running   0          30s
pod/my-web-deploy-7d4f8b9c5d-t5n9q   1/1     Running   0          25s

The pods have new random suffixes in their names, and their age shows they were recently created. The restart count is zero because these are new pods, not restarted containers within existing pods. This distinction is important: restarting a deployment creates new pods, while a container restart within a pod increments the restart count you see in the pod status.

Operating Kubernetes Deployments

Introduction: Managing Your Running Application

Checking Deployment and Pod Status

Join the 1M+ learners on CodeSignal

Viewing Application Logs

Scaling Your Deployment

Updating to New Container Images

Restarting Deployments

Summary: Your Kubernetes Operations Toolkit