Google Kubernetes Engine (GKE) Basics

Introduction to GKE Cluster Deployment

GKE Cluster Deployment (Google Kubernetes Engine) is the gold standard for managing containerized applications at scale. Built on the open-source Kubernetes system, GKE provides a managed environment for deploying, managing, and scaling your containerized applications using Google infrastructure. For the Associate Cloud Engineer (ACE), GKE Cluster Deployment is a critical domain that tests your ability to bridge the gap between infrastructure and application code.

The beauty of GKE Cluster Deployment lies in its ability to abstract away the underlying virtual machines, allowing you to focus on your "Pods" and "Services." Whether you choose the fully managed Autopilot mode or the customizable Standard mode, GKE ensures that your cluster is highly available, secure, and ready to handle global-scale traffic. Understanding the deployment lifecycle, networking patterns, and autoscaling mechanisms is essential for passing the ACE exam.

白話文解釋（Plain English Explanation）

Kubernetes can be complex, so let's use three analogies to simplify the core concepts of GKE Cluster Deployment.

1. The Shipping Port (Container Orchestration)

Imagine a massive international shipping port:

• Containers (Docker) are the standard shipping containers.
• Pods are the small trucks that carry one or more containers within the port.
• Nodes are the massive cargo ships that transport the trucks (Pods).
• GKE (The Orchestrator) is the Port Authority. It decides which ship has room for which container, monitors for damaged ships, and automatically calls for more ships if the port becomes too busy.

In GKE Cluster Deployment, you don't worry about how the ship is built; you just tell the Port Authority (GKE) where you want your container to go, and it handles the rest.

2. The Orchestral Conductor (State Management)

Think of a symphony orchestra:

• The Musicians are the Pods.
• The Sheet Music is your YAML configuration file (Desired State).
• The Conductor is the Kubernetes Control Plane.

If a violinist (Pod) gets sick and stops playing, the conductor notices immediately and brings in a substitute musician to keep the music playing perfectly according to the sheet music. GKE Cluster Deployment is about maintaining that "desired state" automatically without human intervention.

3. The Modern Hotel (Resource Management)

Consider a large hotel:

• The Guests are your Applications.
• The Rooms are the Pods.
• The Hotel Building is the GKE Cluster.
• The Manager is GKE Autopilot.

In a "Standard" hotel, you have to manage the maintenance, the cleaning staff, and the plumbing (Standard Mode). In an "Autopilot" hotel, you just bring your guests, and the manager handles all the room assignments, cleaning, and expansion automatically. GKE Cluster Deployment offers both levels of service depending on your needs.

Understanding GKE Modes of Operation

When starting a GKE Cluster Deployment, your first choice is the mode of operation.

GKE Autopilot: The Fully Managed Experience

Autopilot is the recommended mode for most users. Google manages the entire infrastructure, including the nodes and node pools. You are billed per Pod, not per Node, which often results in lower costs for variable workloads.

GKE Standard: Maximum Control and Flexibility

In Standard mode, you manage the node configurations. You choose the machine types, disk sizes, and networking settings for your nodes. This is ideal for workloads that require specific hardware or custom kernel configurations.

Choosing the Right Mode for Your Workload

Use Autopilot for simplicity and security. Use Standard if you need to use Spot VMs in a very specific way or if you need to run specialized workloads like those requiring GPUs in a non-standard configuration.

Cluster Architecture and Components

A successful GKE Cluster Deployment relies on a clear understanding of its architecture.

The Control Plane: Kubernetes Master

The Control Plane manages the cluster. It includes the API server, the scheduler, and the controller manager. In GKE, Google manages the Control Plane for you.

Worker Nodes and Node Pools

Worker nodes are the Compute Engine VMs that run your containers. A "Node Pool" is a group of nodes within a cluster that all have the same configuration.

Regional vs. Zonal Clusters

• Zonal Clusters: Have a single control plane in one zone. If the zone fails, the control plane is unavailable.
• Regional Clusters: Have multiple replicas of the control plane across three zones in a region. This is the best practice for high availability in GKE Cluster Deployment.

Deploying a Cluster via Console and CLI

The ACE exam expects you to know how to perform a GKE Cluster Deployment using both the UI and the gcloud command.

Key Parameters for gcloud container clusters create

To create a cluster, you use:

gcloud container clusters create my-cluster \
    --region=us-central1 \
    --num-nodes=3 \
    --enable-autoscaling \
    --min-nodes=1 --max-nodes=10

Configuring Node Machine Types

You can specify the hardware for your nodes using the --machine-type flag, similar to creating a standard VM.

Enabling Auto-repair and Auto-upgrade

These are critical "Day 2" operations for GKE Cluster Deployment. Auto-repair detects and replaces unhealthy nodes, while Auto-upgrade keeps your Kubernetes version current.

Managing Kubernetes Workloads

Once the GKE Cluster Deployment is complete, you begin deploying workloads.

Deployments: Managing ReplicaSets and Pods

A Deployment is a declarative way to manage a group of identical Pods. It ensures that the specified number of replicas are always running.

Services: Load Balancing and Service Discovery

A Service provides a stable IP address and DNS name for your Pods. Since Pods are ephemeral and can be deleted/recreated with different IPs, Services are vital for communication.

ConfigMaps and Secrets: Application Configuration

Store configuration data (ConfigMaps) and sensitive data like passwords (Secrets) outside of your container image for better security and flexibility.

Networking in GKE

Networking is often the most challenging part of GKE Cluster Deployment.

Pod and Service IP Ranges

GKE uses specific CIDR ranges for Pods and Services that are separate from the node IP addresses.

Alias IP Ranges and VPC-Native Clusters

VPC-native clusters use Alias IP ranges, which allows Pod IPs to be natively routable within the VPC. This is the default and recommended setting for modern GKE Cluster Deployment.

Ingress Controllers and HTTP(S) Load Balancing

Ingress is an API object that manages external access to the services in a cluster, typically HTTP. GKE provides a built-in Ingress controller that automatically creates a Google Cloud HTTP(S) Load Balancer.

Scaling Your GKE Cluster

Scaling is a core strength of GKE Cluster Deployment.

Horizontal Pod Autoscaler (HPA)

HPA adjusts the number of Pod replicas in a deployment based on CPU utilization or other metrics.

Vertical Pod Autoscaler (VPA)

VPA analyzes the resource requirements of your Pods and automatically adjusts the CPU and memory requests/limits.

Cluster Autoscaler (CA)

CA adds or removes nodes from your node pools based on the resource demands of your Pods. If a Pod cannot be scheduled because there are no available resources, CA will spin up a new node.

Security Best Practices for GKE

Security must be integrated into every GKE Cluster Deployment.

Workload Identity: Secure API Access

This is the recommended way for your GKE workloads to access Google Cloud services (like Cloud Storage or BigQuery) without managing service account keys.

Role-Based Access Control (RBAC)

RBAC allows you to define fine-grained permissions for what users and applications can do within the Kubernetes cluster.

Binary Authorization for Container Integrity

A deploy-time security control that ensures only trusted container images are deployed in your GKE Cluster Deployment.

Storage Management in GKE

PersistentVolume (PV) and PersistentVolumeClaim (PVC)

PVs are the actual storage resources (like Persistent Disks), and PVCs are the requests made by Pods for that storage.

StorageClasses: Dynamic Disk Provisioning

StorageClasses allow GKE to automatically create Persistent Disks whenever a user creates a PVC, simplifying the storage lifecycle in GKE Cluster Deployment.

Monitoring and Logging for Clusters

Cloud Monitoring for GKE

Provides dashboards and alerts for cluster health, node performance, and Pod resource usage.

Cloud Logging and Container Logs

GKE automatically sends all stdout and stderr logs from your containers to Cloud Logging, making it easy to troubleshoot your GKE Cluster Deployment.

Managing GKE via gcloud and kubectl

gcloud container clusters get-credentials

This command downloads the necessary authentication info so you can use kubectl to manage your cluster.

Basic kubectl commands

• kubectl get pods: See all running pods.
• kubectl describe deployment [NAME]: See detailed info and events for a deployment.
• kubectl logs [POD_NAME]: View the output of a specific pod.

Troubleshooting GKE Issues

Debugging Pending Pods

If a Pod is "Pending," it usually means the GKE Cluster Deployment doesn't have enough resources (CPU/RAM) or the Pod is requesting a resource that doesn't exist.

Investigating CrashLoopBackOff

This status means your container is starting but then immediately crashing. Check the kubectl logs to find the application error.

Cluster Upgrade Failures

Upgrades can fail if there are incompatible APIs in your YAML files or if your nodes cannot be gracefully drained.

Common Exam Scenarios for ACE

Moving from Zonal to Regional clusters

"Your application requires 99.99% availability. Your current cluster is Zonal. What should you do?" (Answer: Recreate the cluster as a Regional cluster).

Configuring Autoscaling for a Spike in Traffic

"You expect a 500% increase in traffic for a holiday sale. How should you prepare your GKE cluster?" (Answer: Enable Cluster Autoscaler and Horizontal Pod Autoscaler).

Securing a GKE Workload with IAM

"How do you allow a Pod to write to a Cloud Storage bucket without using a JSON key?" (Answer: Enable Workload Identity and map a K8s ServiceAccount to a Google ServiceAccount).

FAQ

Q1: Can I convert a Zonal cluster to a Regional cluster? A1: No. You must create a new Regional cluster and migrate your workloads.

Q2: What is the difference between a Pod and a Container? A2: A Container is the software package. A Pod is the smallest deployable unit in Kubernetes and can contain one or more containers.

Q3: Does GKE Autopilot support all Kubernetes features? A3: Most features are supported, but some low-level configurations (like privileged containers or custom mutations) are restricted for security.

Q4: Can I run Windows containers on GKE? A4: Yes, GKE supports Windows Server node pools in Standard mode.

Q5: How do I access a private GKE cluster? A5: You can use a bastion host, a VPN, or the Cloud Shell if it is configured to access the private network.

Summary Checklist for ACE

• Understand the differences between Autopilot and Standard modes.
• Know the difference between Zonal and Regional clusters.
• Memorize the gcloud command to get cluster credentials for kubectl.
• Understand how HPA, VPA, and Cluster Autoscaler work together.
• Know that Workload Identity is the best practice for secret-less authentication.
• Recognize the basic components of a Deployment and a Service.