GKE clusters

Everything goes through the API server: kubectl, the console, and the cluster's own components are its clients. You tell Kubernetes the desired state of objects and Kubernetes works to maintain it.

Cloud Shell already includes gcloud and kubectl. On your machine, kubectl is installed as a gcloud component or with apt/yum, and it needs the gke-gcloud-auth-plugin authentication plugin: without it, kubectl can't talk to GKE.

gcloud components install kubectl
gcloud components install gke-gcloud-auth-plugin
kubectl version --client

# Store the cluster credentials in kubeconfig
gcloud container clusters get-credentials CLUSTER_NAME --location=us-central1
kubectl get namespaces

• Credentials are stored in kubeconfig, at $HOME/.kube/config by default.
• kubeconfig holds contexts (cluster + user + optional namespace). kubectl uses the current context.
• get-credentials adds the entry and switches the current context. Creating the cluster with gcloud does too.
• --location is a region for regional clusters or a zone for zonal ones. Set a default compute/region or compute/zone so you don't have to pass it every time.
• View the configuration: kubectl config view. Switch clusters: kubectl config use-context.

Autopilot versus Standard

Autopilot is the mode where Google manages nodes, scaling, security, and other settings, and provisions resources based on your manifests. Google recommends it for most production workloads. In a Standard cluster you can also run specific workloads in Autopilot mode with ComputeClasses.

• If you deploy to Autopilot without CPU and memory requests, GKE applies default values and adjusts the requests.
• Hardware needs (GPUs, Spot, Arm) are requested with ComputeClasses, without configuring nodes.
• In Autopilot, all Pod traffic goes through VPC firewall rules, even between Pods in the cluster.

# Autopilot (always regional)
gcloud container clusters create-auto hello-cluster --location=us-central1

# Regional Standard
gcloud container clusters create std-cluster --location=us-central1 --num-nodes=1

Regional, zonal, and multi-zonal clusters

• Google recommends regional clusters for production.
• A regional cluster can't be changed to zonal later.
• The default node pool of a regional Standard cluster has nine nodes (three per zone); you can reduce it to one per zone. New billing accounts get only eight in-use IP addresses per region, so creation can fail on quota.
• Node-to-node traffic across zones is charged.
• For GPUs in a regional cluster, use --node-locations to specify zones that have that GPU.
• If you add persistent storage without specifying a zone, GKE puts the zonal disk in a random zone.

Private clusters: network isolation

What the exam guide calls "private clusters" the current docs treat as network isolation, which controls three kinds of access: to the control plane from outside, from the API server to external webhooks, and to the nodes from outside.

With or without private nodes, the control plane talks to nodes over internal IPs only. If you expand a subnet used by a cluster with authorized networks, update the authorized networks list too.

Release channels

GKE upgrades every cluster automatically. The channel sets the balance between new features and stability; maintenance windows and exclusions control when it happens.

Deploying a containerized application

The official quickstart flow: enable the GKE and Artifact Registry APIs, have the roles/container.admin role, create the cluster, and deploy.

• For production, use declarative YAML manifests with kubectl apply -f instead of imperative commands.
• A LoadBalancer Service gets an ephemeral external IP; to use a static IP you already reserved, set it in loadBalancerIP. Autopilot doesn't support externalIps.
• Google's best practice: use Cloud Build, Cloud Deploy, and Artifact Registry for CI/CD.

Exam scenarios

Common exam traps