Question

Difficulty: HardDeploying and Managing Google Kubernetes Engine (GKE) Clusters and Workloads

A cloud engineer must deploy an updated containerized microservice to an existing private Google Kubernetes Engine (GKE) cluster named `private-app-cluster` in zone `us-east4-a`. The cluster control plane is configured with private endpoint access only, and the engineer is operating from an authorized internal management workstation. In what sequence should the engineer execute the operational steps to establish private cluster connectivity, generate local cluster authentication, deploy the application manifest, and verify workload rollout?

  1. 1Establish a secure network path to the private GKE control plane network (e.g., via an authorized internal VPC connection or IAP SSH tunnel).
  2. 2Execute `gcloud container clusters get-credentials private-app-cluster --zone us-east4-a --internal-ip` to update the local kubeconfig file.
  3. 3Execute `kubectl apply -f microservice-deployment.yaml` to submit the workload configuration.
  4. 4Execute `kubectl rollout status deployment/microservice-app` to monitor pod creation and readiness.

Answer

The correct operational sequence is: 1) Establish a secure network path to the private GKE control plane, 2) Execute `gcloud container clusters get-credentials private-app-cluster --zone us-east4-a --internal-ip`, 3) Execute `kubectl apply -f microservice-deployment.yaml`, and 4) Execute `kubectl rollout status deployment/microservice-app`.
The deployment of workloads to a private GKE cluster follows a logical dependency chain: network connectivity to the private master endpoint must exist first, followed by authentication setup via `gcloud container clusters get-credentials --internal-ip`. Once `kubectl` context is configured, the manifest is submitted with `kubectl apply`, and finally, the rollout state is verified with `kubectl rollout status` to confirm operational readiness.

Step-by-Step Solution

1
Ensure network connectivity to the private GKE control plane internal IP address.
Network routes allow TCP traffic to reach the GKE master API server on port 443.
Private GKE clusters disable public endpoint access, requiring internal network routing or bastion access prior to API invocation.
2
Run `gcloud container clusters get-credentials` using the `--internal-ip` flag.
The local `~/.kube/config` file is updated with cluster endpoint details and user credentials.
Without fetching credentials and specifying `--internal-ip`, local `kubectl` calls will fail to resolve or reach the private control plane.
3
Run `kubectl apply -f microservice-deployment.yaml`.
The Kubernetes API server accepts the deployment specification and schedules requested pods.
Deploying the manifest requires an active, authenticated `kubectl` context pointing to the control plane.
4
Run `kubectl rollout status deployment/microservice-app`.
Real-time deployment lifecycle progress is displayed until all updated replicas are healthy and operational.
Verification ensures that the deployment was not only submitted but also successfully completed without container crashes or scheduling failures.

Key Concept

Private GKE Cluster Management and Workload Deployment Workflow
Rate this question