7.1 Installing and Configuring kubectl

Why kubectl Setup Is Its Own Exam Objective

The ACE exam guide calls out "Installing and configuring the command line interface (CLI) for Kubernetes (kubectl)" as its own bullet under Domain 3 (Deploying and implementing a cloud solution). That is deliberate: kubectl is not gcloud, and candidates who have only clicked around the Cloud Console routinely miss the fact that talking to a Google Kubernetes Engine (GKE) cluster requires a second tool, a second authentication layer, and a second configuration file. Expect scenario questions where the "fix" is simply installing or re-pointing kubectl, not touching the cluster itself.

kubectl vs. gcloud: Two Different Control Planes

• gcloud manages Google Cloud resources — it creates the GKE cluster, node pools, and the underlying VMs. It talks to the Google Cloud API.
• kubectl manages objects inside a running Kubernetes cluster — Pods, Deployments, Services, ConfigMaps. It talks directly to the cluster's Kubernetes API server, not to the Google Cloud API.

You can create a flawless GKE cluster with gcloud and still be completely unable to deploy an application to it if kubectl isn't installed and pointed at the right cluster.

Installing kubectl

A common exam trap: candidates assume gcloud installs kubectl automatically. It does not — the Cloud SDK installer only prompts you to add the kubectl component; you must accept it or run the install command explicitly.

The Authentication Plugin: gke-gcloud-auth-plugin

Since GKE version 1.26, kubectl requires a separate binary called gke-gcloud-auth-plugin to exchange your gcloud identity for a short-lived Kubernetes authentication token. Without it, kubectl commands against a GKE cluster fail even if the kubeconfig file looks correct.

gcloud components install gke-gcloud-auth-plugin

On some platforms you must also confirm the plugin is active by setting an environment variable:

export USE_GKE_GCLOUD_AUTH_PLUGIN=True

If you see an authentication error referencing "exec plugin" or "auth-provider deprecated" when running kubectl get pods against a GKE cluster, the fix is almost always a missing or outdated gke-gcloud-auth-plugin — not an IAM permission problem.

Pointing kubectl at a Cluster: get-credentials

The single most important command for this objective is:

gcloud container clusters get-credentials CLUSTER_NAME \
  --zone ZONE            # for zonal clusters
  # or
  --region REGION        # for regional clusters

This command does two things automatically:

1. Writes an entry for the cluster into your kubeconfig file (default path $HOME/.kube/config, or the path specified by the KUBECONFIG environment variable).
2. Switches kubectl's current context to point at that cluster.

You need at least the container.clusters.get IAM permission (bundled into roles/container.viewer, roles/container.developer, or roles/container.admin) on the project — without it, get-credentials itself fails before kubectl ever runs.

Working with kubeconfig and Contexts

A kubeconfig file can hold credentials for many clusters at once, each represented as a context (a named combination of cluster + user + namespace). Key commands:

Exam scenario: An engineer runs gcloud container clusters get-credentials cluster-a --zone us-central1-a, then later runs gcloud container clusters get-credentials cluster-b --region us-east1. A kubectl get pods command unexpectedly returns Pods from cluster-b. Why? Because each get-credentials call overwrites the current context, so the most recently fetched cluster becomes active — the engineer needs kubectl config use-context to switch back to cluster-a without re-running get-credentials.

Exam scenario 2: A freshly created Compute Engine VM in the same project as a GKE cluster runs kubectl get pods and receives error: You must be logged in to the server (Unauthorized) or "no configuration has been provided." The root cause is almost never a firewall rule — it is that gcloud container clusters get-credentials was never run on that VM, so no kubeconfig entry exists yet.

Key Takeaways

• kubectl and gcloud are separate tools with separate control planes: gcloud manages the cluster's infrastructure, kubectl manages objects inside it.
• Install kubectl with gcloud components install kubectl; it is not bundled by default outside Cloud Shell.
• Since GKE 1.26, gke-gcloud-auth-plugin is required for kubectl authentication — missing it produces auth errors that look unrelated to IAM.
• gcloud container clusters get-credentials writes to $HOME/.kube/config (or $KUBECONFIG) and switches the current context automatically.
• Use kubectl config use-context to switch between multiple already-configured clusters without re-running get-credentials.