Deploying an application is just the beginning. Once your application is running in Google Kubernetes Engine, 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, roll back a bad release, and restart it when necessary. 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.

The first skill you need when managing Kubernetes applications is the ability to check their status. You need to know whether your deployments are healthy, how many pods are running, and whether those pods are ready to accept traffic. Kubernetes provides several commands that give you different levels of detail about your resources. Knowing which command to use in different situations is an important part of working effectively with Kubernetes.

The most basic way to check your resources is with the kubectl get command. You've seen this command before, but now you'll learn how to use it more effectively. Instead of checking deployments and pods separately, you can view them together in a single command:

This command tells kubectl to retrieve both deployments and pods from the apps namespace. The output shows you both resource types in a single view:

This combined view is useful because it shows you the relationship between the deployment and its pods. The deployment shows that it wants one replica and has one replica ready. The pod shows that it's running and has been restarted zero times. If there were any problems, you'd see them immediately in this output. For example, if the pod was crashing, you'd see a high restart count. If the pod couldn't pull the image, you'd see a status like ImagePullBackOff. This quick overview is often the first thing you check when investigating issues or verifying that changes have taken effect.

When you want more detailed information about a deployment's progress, you can use the kubectl rollout status command. This command is specifically designed to monitor deployments and show you whether a rollout is complete:

The output tells you whether the deployment has successfully rolled out:

This command is particularly useful when you're waiting for a deployment to complete after making changes. If you've just updated the image or scaled the deployment, kubectl rollout status will wait and show you progress until the rollout is complete. If something goes wrong during the rollout, this command will show you the error. The command blocks until the rollout finishes or fails, which makes it perfect for use in scripts or CI/CD pipelines where you need to wait for a deployment to complete before proceeding to the next step.

For even more detailed information about a deployment, you can use the kubectl describe command. This command shows you everything Kubernetes knows about a resource, including its configuration, current state, and recent events:

The output from describe is extensive, but a few key sections provide the most value:

Let's break down the most important parts of this output:

• Replicas and StrategyType: These lines show the desired number of pods and the strategy (RollingUpdate) Kubernetes will use to update them.
• Pod Template: This section details the specification for the pods that the deployment manages, including the container image, ports, resource requests, and limits.
• Conditions: This provides a high-level summary of the deployment's current state, such as whether it's and .

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 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:

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:

This command retrieves the logs from the web container running in the specified pod. While will default to the only container if you omit 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.

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:

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

When you run this command, Kubernetes immediately begins creating a second pod. The deployment controller sees that the desired replica count is 2 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:

Now you should see two pods instead of one:

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 creates a replacement for the failed pod.

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.

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 Google Artifact Registry. For this example, let's assume you've already done that and your new image is available at us-docker.pkg.dev/my-project-12345/my-repo/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:

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 when you created your deployment. The output confirms that the image was 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.

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.

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

This command will show you the progress of the update:

No matter how carefully you test, a bad release can make it into production. Kubernetes tracks the history of every rollout, which means you can undo a problematic update and return to the previous known-good state immediately — without manually reapplying old manifests or rebuilding images. The kubectl rollout undo command handles this.

Before rolling back, it's useful to inspect the revision history of your deployment to understand what versions are available:

This shows you the list of revisions Kubernetes has recorded:

Each time you change the pod template (for example, by updating the image), Kubernetes creates a new revision. To roll back to the immediately previous revision, run:

The output confirms the rollback was initiated:

Kubernetes performs the rollback using the exact same rolling update process, gradually replacing the current pods with pods running the previous image. This means there is no downtime during a rollback. You can confirm it completed successfully using kubectl rollout status:

If you need to skip back further than just one revision — for example, to return to a specific stable baseline after several bad releases — you can use the --to-revision flag with the revision number from the history output:

This makes rollbacks a precise and reliable recovery tool, not just a simple "undo" of the last change.

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:

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

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:

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

In this lesson, you learned the essential operations for managing applications running on Google Kubernetes Engine. You now have a core toolkit of commands for observing and managing your application's lifecycle. You learned to check status with kubectl get, rollout status, and describe; view logs with kubectl logs; and modify the running state with kubectl scale, set image, rollout undo, and rollout restart. This workflow — checking the current state, making a change with imperative commands, and verifying the result — is fundamental to working with Kubernetes.

These skills will be solidified in the upcoming practice exercises, where you'll get hands-on experience with each of these operations. Mastering this toolkit will prepare you for the next lesson, where you'll learn how to expose your applications to external traffic using Services.