Google Kubernetes Engine (GKE)

Google Kubernetes Engine (GKE) is a managed, production-ready environment for deploying, managing, and scaling containerized applications using Kubernetes on Google Cloud. Before GKE, organizations had to install, configure, and manage Kubernetes clusters themselves—a complex task involving the control plane (etcd, API server, scheduler, controller manager), worker nodes, networking (CNI plugins), and storage. GKE automates the control plane management, node provisioning, upgrades, and repair, allowing you to focus on deploying applications. The ACE exam tests your ability to create and configure GKE clusters, understand node pools, networking modes (VPC-native vs routes-based), and use features like Workload Identity and Config Connector.

A GKE cluster consists of a control plane (managed by Google) and worker nodes (Compute Engine instances). The control plane runs Kubernetes components: kube-apiserver, kube-controller-manager, kube-scheduler, and etcd. Google manages these components, including high availability (multi-zonal control plane for regional clusters) and automatic upgrades. Worker nodes run the kubelet, kube-proxy, and container runtime (containerd or Docker). When you deploy a workload (e.g., a Deployment), the API server stores the desired state in etcd. The scheduler assigns pods to nodes based on resource requests and constraints. The kubelet on each node pulls container images and runs the pods. GKE also integrates with Google Cloud services like Cloud Load Balancing, Cloud Storage, and Cloud Monitoring.

Creating a regional cluster with default settings:

gcloud container clusters create my-cluster --region us-central1

Creating a private cluster with Workload Identity:

gcloud container clusters create my-private-cluster \
    --region us-central1 \
    --enable-private-nodes \
    --enable-ip-alias \
    --workload-pool=my-project.svc.id.goog

Verifying cluster details:

gcloud container clusters describe my-cluster --region us-central1

Getting credentials:

gcloud container clusters get-credentials my-cluster --region us-central1

Listing node pools:

gcloud container node-pools list --cluster my-cluster --region us-central1

VPC-native clusters use alias IP ranges. Each cluster has a primary IP range for nodes, and two secondary ranges for pods and services. Pods get IP addresses from the pod secondary range, and services get IPs from the service secondary range. This allows pods to communicate directly using their pod IPs without NAT, and enables network policies. The default maximum pods per node is 110 (with /24 alias range). You can configure this at cluster creation. For routes-based clusters, pods use IP forwarding and VPC routes, which can cause route table pollution at scale. VPC-native is the recommended and default mode.

GKE integrates with Cloud Operations. You can view cluster dashboards, pod logs, and metrics like CPU and memory utilization. The default metrics collection includes system metrics (e.g., node CPU, memory) and pod metrics. You can enable Managed Service for Prometheus for advanced monitoring. Alerts can be set up for high resource usage, pod failures, or cluster health issues.

A large e-commerce company runs its microservices on GKE. During Black Friday, traffic spikes 10x. They use cluster autoscaler with node auto-provisioning to automatically add node pools with different machine types (e.g., n2-highcpu for compute-intensive tasks, n2-standard for general). They set pod disruption budgets to ensure at least 50% of pods are available during upgrades. They use VPC-native clusters for direct pod-to-pod communication and network policies to isolate frontend from backend. Common issues: if cluster autoscaler scale-down unneeded time is too short (default 10 min), it may remove nodes that are about to receive traffic. They adjust it to 15 minutes. Also, if node auto-provisioning is not enabled, pods may remain pending if the existing node pool is full. They enable it with minimum CPU and memory constraints.

A bank deploys GKE private clusters with no public IP addresses. They use Cloud NAT for egress to pull images from Artifact Registry. They enable Workload Identity to allow pods to access Cloud Storage and BigQuery without managing keys. Binary Authorization is enforced: only images signed by their internal CI/CD pipeline can be deployed. They use Shielded GKE Nodes for boot integrity. They also enable GKE Sandbox for untrusted third-party workloads. A common misconfiguration: forgetting to create a Cloud NAT for private clusters, causing image pull failures. They also set up maintenance exclusions during audit periods to prevent automatic upgrades.

A video streaming company uses GKE to run transcoding jobs on GPU nodes. They create a node pool with accelerator type nvidia-tesla-t4 and enable GPU time-sharing for higher utilization. They use node taints and tolerations to ensure GPU pods are scheduled only on GPU nodes. They use Filestore for shared storage of video files. They enable cluster autoscaler to scale GPU nodes based on pending jobs. Performance consideration: GPU nodes are expensive, so they use preemptible VMs for batch jobs to reduce costs. However, preemptible nodes can be terminated at any time, so they set up pod disruption budgets and use node pools with regular VMs for critical workloads. A common issue: forgetting to install NVIDIA drivers on COS (they use the GPU driver installation add-on).