Google Kubernetes Engine (GKE): Deploy and Scale Clusters

Overview

This tutorial covers the essential skills for deploying and managing Google Kubernetes Engine (GKE) clusters on Google Cloud Platform. You'll learn to create production-ready clusters, configure node pools, implement autoscaling, and manage workload distribution—all critical components tested on the Google Cloud Professional Cloud Architect certification exam.

What You'll Learn:

• Creating and configuring GKE clusters with optimal settings
• Managing node pools and custom machine types
• Implementing cluster autoscaling and horizontal pod autoscaling
• Setting up networking and security best practices
• Monitoring cluster health and resource utilization

Prerequisites:

• Active Google Cloud account with billing enabled
• gcloud CLI installed (version 400+)
• kubectl installed (version 1.24+)
• Familiarity with Kubernetes concepts (pods, deployments, services)
• Understanding of GCP resource hierarchy (projects, VPCs)

Why This Matters: The Professional Cloud Architect exam heavily emphasizes cluster management, scaling decisions, and cost optimization. GKE questions typically focus on choosing appropriate node configurations, autoscaling policies, and handling multi-zone deployments.

Getting Started

Begin by authenticating and setting your project context:

gcloud auth login
gcloud config set project PROJECT_ID
gcloud config get-value project

Install the necessary components if not already present:

gcloud components install kubectl
gcloud components install gke-gcloud-auth-plugin
gcloud components update

Enable the required APIs for your project:

gcloud services enable container.googleapis.com
gcloud services enable compute.googleapis.com
gcloud services enable monitoring.googleapis.com
gcloud services enable logging.googleapis.com

Set environment variables for consistency throughout this tutorial:

export CLUSTER_NAME='architect-demo'
export REGION='us-central1'
export ZONE='us-central1-a'
export PROJECT_ID=$(gcloud config get-value project)
export MACHINE_TYPE='n2-standard-4'

Creating Production-Grade GKE Clusters

Creating a cluster requires careful consideration of networking, security, and resource configuration. The command below creates a cluster with production best practices:

gcloud container clusters create $CLUSTER_NAME \
  --region $REGION \
  --num-nodes 3 \
  --machine-type $MACHINE_TYPE \
  --enable-ip-alias \
  --network 'default' \
  --cluster-secondary-range-name pods \
  --services-secondary-range-name services \
  --enable-stackdriver-kubernetes \
  --logging=SYSTEM_COMPONENTS,WORKLOADS \
  --monitoring=SYSTEM_COMPONENTS,WORKLOADS \
  --enable-network-policy \
  --enable-intra-node-visibility \
  --addons HorizontalPodAutoscaling,HttpLoadBalancing,GcePersistentDiskCsiDriver \
  --workload-pool=$PROJECT_ID.svc.id.goog \
  --enable-shielded-nodes \
  --enable-vertical-pod-autoscaling

Critical Parameters Explained:

• --enable-ip-alias: Enables VPC-native networking (required for production)
• --cluster-secondary-range-name: Reserves IP space for pods, preventing fragmentation
• --enable-network-policy: Enforces pod-to-pod communication policies
• --workload-pool: Enables Workload Identity for secure GCP service authentication
• --enable-vertical-pod-autoscaling: Automatically right-sizes container resource requests

Retrieve cluster credentials to interact with it locally:

gcloud container clusters get-credentials $CLUSTER_NAME --region $REGION
kubectl cluster-info
kubectl get nodes

Common Pitfall: Many engineers create clusters without enabling Workload Identity. This forces workloads to use service account keys, which violates security best practices. Always include --workload-pool in production deployments.

Advanced Node Pool Management and Autoscaling

A single node pool rarely meets production demands. Create specialized node pools for different workload types:

gcloud container node-pools create compute-pool \
  --cluster=$CLUSTER_NAME \
  --region=$REGION \
  --machine-type=n2-highmem-8 \
  --enable-autoscaling \
  --min-nodes=2 \
  --max-nodes=10 \
  --node-taints=workload-type=compute:NoSchedule \
  --node-labels=pool-type=compute \
  --enable-autorepair \
  --enable-autoupgrade \
  --maintenance-window-start=2024-01-01T00:00:00Z \
  --maintenance-window-duration=4h \
  --maintenance-window-recurrence='FREQ=WEEKLY;BYDAY=SA'

Create a second pool for memory-intensive applications:

gcloud container node-pools create memory-pool \
  --cluster=$CLUSTER_NAME \
  --region=$REGION \
  --machine-type=n2-highmem-16 \
  --enable-autoscaling \
  --min-nodes=1 \
  --max-nodes=5 \
  --node-taints=workload-type=memory:NoSchedule \
  --node-labels=pool-type=memory \
  --spot \
  --enable-autorepair

Key Autoscaling Decisions:

• Min/Max Nodes: Set minimums based on baseline traffic; maximums on budget constraints
• Node Taints: Prevent inappropriate workload placement (e.g., only memory-intensive apps on highmem nodes)
• Spot Instances: Reduce costs 70% for fault-tolerant workloads; unacceptable for stateful services
• Maintenance Windows: Schedule during low-traffic periods to prevent service disruption

Configure Horizontal Pod Autoscaling (HPA) for your deployments:

kubectl apply -f - <<'EOF'
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: web-app-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: web-app
  minReplicas: 3
  maxReplicas: 50
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 70
  - type: Resource
    resource:
      name: memory
      target:
        type: Utilization
        averageUtilization: 80
  behavior:
    scaleDown:
      stabilizationWindowSeconds: 300
      policies:
      - type: Percent
        value: 50
        periodSeconds: 60
    scaleUp:
      stabilizationWindowSeconds: 0
      policies:
      - type: Percent
        value: 100
        periodSeconds: 30
      - type: Pods
        value: 4
        periodSeconds: 30
      selectPolicy: Max
EOF

Verify autoscaling is active:

kubectl get hpa -w
kubectl describe hpa web-app-hpa

Best Practice: Always set resource requests and limits on containers. HPA metrics depend on accurate requests; without them, percentage-based scaling fails unpredictably.

Networking and Security Configuration

Implement Network Policies to restrict traffic between workloads:

kubectl apply -f - <<'EOF'
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: deny-all-ingress
spec:
  podSelector: {}
  policyTypes:
  - Ingress
---
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-web-to-api
spec:
  podSelector:
    matchLabels:
      tier: api
  policyTypes:
  - Ingress
  ingress:
  - from:
    - podSelector:
        matchLabels:
          tier: web
    ports:
    - protocol: TCP
      port: 8080
EOF

Configure Workload Identity for secure GCP service access without keys:

kubectl create namespace production
kubectl create serviceaccount gke-workload-sa -n production
gcloud iam service-accounts create gke-workload-identity
gcloud iam service-accounts add-iam-policy-binding \
  gke-workload-identity@$PROJECT_ID.iam.gserviceaccount.com \
  --role roles/iam.workloadIdentityUser \
  --member serviceAccount:$PROJECT_ID.svc.id.goog[production/gke-workload-sa]
kubectl annotate serviceaccount gke-workload-sa \
  -n production \
  iam.gke.io/gcp-service-account=gke-workload-identity@$PROJECT_ID.iam.gserviceaccount.com

Enable read access to Cloud Storage for this workload:

gcloud projects add-iam-policy-binding $PROJECT_ID \
  --member=serviceAccount:gke-workload-identity@$PROJECT_ID.iam.gserviceaccount.com \
  --role=roles/storage.objectViewer

Exam Tips for Google Cloud Professional Cloud Architect

Frequently Tested Concepts:

• Node Pool Selection: Exam questions often present cost vs. performance tradeoffs. Spot instances save 70% but can't run stateful workloads.
• Autoscaling Strategy: Know when to use Cluster Autoscaler (adds nodes) vs. HPA (scales pods). HPA scales faster but can't exceed node capacity.
• Multi-zone vs. Regional: Regional clusters replicate node pools across three zones, increasing availability but costs.
• Network Architecture: VPC-native (IP alias) is mandatory for production. Know the difference between pod secondary ranges and service secondary ranges.
• Workload Identity: Always presented as the secure alternative to service account keys in scenario-based questions.

Sample Exam Scenario: 'Your organization runs a batch processing job requiring 100 GB RAM but only once weekly. Cost is critical. Which approach is optimal?'

Answer: Create a dedicated node pool with n2-highmem machines tagged with batch-only taints. Enable autoscaling with --min-nodes=0 --max-nodes=5. Deploy batch jobs with matching tolerations. Nodes scale to zero when jobs complete.

Quick Reference Commands:

gcloud container clusters list
gcloud container clusters describe $CLUSTER_NAME --region $REGION
gcloud container node-pools list --cluster $CLUSTER_NAME --region $REGION
kubectl top nodes
kubectl top pods --all-namespaces
kubectl get pdb --all-namespaces

Summary

You've mastered core GKE cluster deployment and scaling. Key takeaways:

• Always enable VPC-native networking, Workload Identity, and autoscaling from creation
• Use multiple node pools to match workload requirements and optimize costs
• Combine Cluster Autoscaler (node-level) with HPA (pod-level) for robust scaling
• Implement Network Policies and Workload Identity for production security
• Set resource requests and limits—they're mandatory for accurate autoscaling

Next Steps:

• Deploy a multi-tier application across node pools with network policies
• Test autoscaling under load using tools like Apache JMeter
• Explore GKE Autopilot for fully managed Kubernetes experience
• Review the Google Cloud Professional Cloud Architect Certification Guide for related GCP services