A cloud engineer needs to update an existing application running on a Google Kubernetes Engine (GKE) cluster with a new container image version. What is the correct sequence of actions to build, publish, and verify the deployment of this updated workload?
- 1Build and tag the new container image version locally using Docker.
- 2Push the tagged container image to the designated Google Cloud Artifact Registry repository.
- 3Run `kubectl set image deployment/web-app web-app=LOCATION-docker.pkg.dev/PROJECT_ID/REPO/IMAGE:TAG` to update the workload.
- 4Run `kubectl rollout status deployment/web-app` to verify that the new pods are running and healthy.
Answer
The correct sequence starts with building and tagging the container image locally, pushing the image to Google Cloud Artifact Registry, updating the container image on the GKE deployment using kubectl set image, and finally verifying the deployment progress using kubectl rollout status.
The workflow follows standard container lifecycle and Kubernetes deployment practices: first creating the local container image, pushing it to Google Cloud Artifact Registry so GKE can access it, applying the image update to the deployment manifest via kubectl, and lastly inspecting the rollout status to confirm workload health.
Step-by-Step Solution
Key Concept
Updating and Monitoring GKE Workloads