GKE: ACE Exam Study Guide (2026)

Image source: Google Cloud Documentation

1. GKE Fundamentals

Google Kubernetes Engine (GKE) is a managed environment for deploying, managing, and scaling containerized applications using Google infrastructure.

• Managed Kubernetes: Google manages the Kubernetes Control Plane, while you manage worker nodes in Standard mode.
• Cluster Types:
  • Autopilot: The default and recommended mode for 2026. Fully managed; Google manages nodes, scaling, and security. You pay only for running pods.
  • Standard: You manage the node infrastructure. Full control over nodes, SSH access, and custom machine types.

2. Cluster Configurations

• Regional Clusters: Control Plane and nodes replicated across multiple zones. Higher availability (99.95% SLA).
• Zonal Clusters: Control Plane and nodes in a single zone. Less expensive (99.5% SLA).
• Private Clusters: Nodes have internal IP addresses only. Communication with Control Plane via VPC peering. Requires Cloud NAT for outbound internet access.

3. Node Management and Scaling

• Node Pools: A group of nodes with the same configuration. Support for N4 (general purpose) and C4 (compute optimized) machine types in 2026 for optimized performance.
• Cluster Autoscaler: Automatically adds or removes nodes based on resource demands.
• Horizontal Pod Autoscaler (HPA): Scales pod replicas based on CPU or custom metrics.
• Vertical Pod Autoscaler (VPA): Adjusts CPU and memory reservations for pods.

Deployment → Manages app lifecycle: rolling updates, rollbacks, scaling. Creates and controls ReplicaSets. This is a recommented way to run stateless apps in GKE.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app
spec:
  replicas: 3
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 1
  selector:
    matchLabels:
      app: my-app
  template:
    metadata:
      labels:
        app: my-app
    spec:
      containers:
        - name: app
          image: nginx:1.25
          ports:
            - containerPort: 80

ReplicaSet → Ensures a fixed number of Pods are running. Usually not used directly. Managed (created automatically) by Deployments.

apiVersion: apps/v1
kind: ReplicaSet
metadata:
  name: my-app-rs
spec:
  replicas: 3
  selector:
    matchLabels:
      app: my-app
  template:
    metadata:
      labels:
        app: my-app
    spec:
      containers:
        - name: app
          image: nginx:1.25

GKE → Use Deployments for stateless workloads. ReplicaSets are created automatically.

4. GKE Networking

• Services:

  • ClusterIP (default)
    • Internal-only virtual IP.
    • Accessible only inside the cluster.
    • Used for pod‑to‑pod communication.

  ClusterIP Service Definition for Internal Traffic

  apiVersion: v1
  kind: Service
  metadata:
    name: my-clusterip-service
  spec:
    type: ClusterIP
    selector:
      app: my-app
    ports:
      - port: 80 # service port
        targetPort: 8080 # container port
  

  • NodePort
    • Opens port 30080 on every node.
    • Accessible via http://<node-ip>:30080.
    • Still load‑balances across pods.

  NodePort Service Exposing Port 80 → 30080

  apiVersion: v1
  kind: Service
  metadata:
    name: my-nodeport-service
  spec:
    type: NodePort
    selector:
      app: my-app
    ports:
      - port: 80
        targetPort: 8080
        nodePort: 30080 # must be in range 30000–32767
  

  • LoadBalancer:
    • GKE automatically creates a Google Cloud external Load Balancer
    • Assigns a public IP
    • Traffic → LB → NodePort → Pod
    • This is the standard way to expose a service publicly

  LoadBalancer Service Exposing Port 80

  apiVersion: v1
  kind: Service
  metadata:
    name: my-loadbalancer-service
  spec:
    type: LoadBalancer
    selector:
      app: my-app
    ports:
      - port: 80
        targetPort: 8080
  

• Ingress: Manages external access (layer-7 HTTP/HTTPS) routing mechanism and creates a Google Cloud External Application Load Balancer.

• Container-Native Load Balancing: Uses Network Endpoint Groups (NEGs) to route traffic directly to pods.

5. Storage in GKE

In Kubernetes, Pods are ephemeral — they can be rescheduled, recreated, or moved to another node at any time. Stateful apps (databases, queues, caches, file‑based apps) need persistent storage that survives pod restarts.

That’s where Persistent Volumes (PV) and Persistent Volume Claims (PVC) come in.

• Persistent Volumes and Persistent Volume Claims: Managed storage for stateful applications.
• Storage Classes: Defines storage types (e.g., standard HDD, SSD, or Balanced PD).
• Hyperdisk: Support for Google Cloud Hyperdisk in 2026 for high-performance GKE workloads.

For more details see Persistant Disk

6. Connecting GKE Pod to Memorystore (standard)

To connect a GKE Pod to a Google Cloud Memorystore (Redis) instance, you need to ensure they share a network and then inject the connection details into your Kubernetes deployment.

Network Prerequisites

• Same VPC: The Redis instance and GKE cluster must be in the same VPC network and same region.
• VPC-Native GKE: Your GKE cluster must be VPC-native (IP Aliasing enabled). Standard route-based clusters cannot natively route traffic to the Google-managed VPC where Redis lives.

Find Connection Details

Once the Redis instance is created, retrieve its internal IP address and port from the Google Cloud Console or CLI:

• Host IP: 10.x.x.x
• Port: 6379 (Default)
• Auth String: If Auth is enabled, you will also need the password string.

Store Credentials in Kubernetes

The best practice is to store these details in a Kubernetes Secret so they aren’t hardcoded in your application code.

kubectl create secret generic redis-creds \
  --from-literal=REDIS_HOST=10.x.x.x \
  --from-literal=REDIS_PORT=6379 \
  --from-literal=REDIS_PASSWORD=your-auth-string

Update the GKE Deployment

Inject these values into your Pod as environment variables in your deployment.yaml.

spec:
  containers:
    - name: my-app
      image: gcr.io/my-project/my-app:v1
      env:
        - name: REDIS_HOST
          valueFrom:
            secretKeyRef:
              name: redis-creds
              key: REDIS_HOST
        - name: REDIS_PORT
          valueFrom:
            secretKeyRef:
              name: redis-creds
              key: REDIS_PORT

Verify Connectivity

You can test the connection by running a temporary “debug” pod with redis-cli installed:

kubectl run redis-test --rm -it --image=redis:7 -- \
  redis-cli -h [YOUR_REDIS_IP] -p 6379 ping
# Expected Output: PONG

Note on Security: By default, Memorystore does not have a firewall. Use Kubernetes NetworkPolicies to restrict which Pods in your cluster are allowed to send egress traffic to the Redis IP address.

7. GKE Security

• Workload Identity: The recommended way for GKE workloads to access Google Cloud services.

  Workload Identity lets GKE pods access Google Cloud APIs without service account keys. It maps a Kubernetes Service Account to a Google Cloud Service Account, giving pods secure, short‑lived credentials managed automatically by GKE and IAM.

• Binary Authorization: Ensures only trusted container images are deployed.

  Binary Authorization ensures only trusted, verified container images can run in GKE. It enforces deploy‑time security by requiring signed attestations from approved build or security systems, blocking unapproved or unscanned images before they reach the cluster.

• RBAC: Manages permissions inside the cluster.

  Role‑Based Access Control in Kubernetes controls who can do what in the cluster. It uses Roles/ClusterRoles to define permissions and RoleBindings/ClusterRoleBindings to assign them to users, groups, or service accounts. It provides fine‑grained, namespace‑scoped or cluster‑wide access control without exposing unnecessary privileges.

• IAM: Manages permissions outside the cluster (e.g., cluster creation).
• Shielded GKE Nodes: Provides node identity and integrity.

8. Essential gcloud and kubectl Commands

• Create a Cluster: gcloud container clusters create [CLUSTER_NAME] --zone [ZONE] --num-nodes [NUMBER]
• Get Credentials: gcloud container clusters get-credentials [CLUSTER_NAME] --zone [ZONE]
• Resize a Cluster: gcloud container clusters resize [CLUSTER_NAME] --node-pool [POOL_NAME] --num-nodes [NEW_SIZE]
• Deploy an Application: kubectl apply -f [FILENAME.YAML]
• Check Pod Status: kubectl get pods

9. Exam Tips and Gotchas

• Control Plane Upgrade: Google automatically upgrades the Control Plane. Define Maintenance Windows and Exclusions.
• Preemptible/Spot VMs: Use for cost savings in fault-tolerant workloads.
• Autopilot vs Standard: Choose Autopilot for reduced operational overhead unless specific node customization is required.

10. External Links

• Google Kubernetes Engine - The Cloud Girl
• Where should I run my staff - The Cloud Girl