Google Kubernetes Engine

Google Kubernetes Engine, powered by the open source container scheduler Kubernetes, enables you to run containers on Google Cloud Platform. Kubernetes Engine takes care of provisioning and maintaining the underlying virtual machine cluster, scaling your application, and operational logistics such as logging, monitoring, and cluster health management.

Google Cloud Compute Options – VMs, GKE & Cloud Run

~ Last updated on : ~ jayendrapatil

Google Cloud Compute Options

📌 Updated June 2026: This post has been updated to reflect major Google Cloud compute changes including Cloud Functions rebranding to Cloud Run functions (Aug 2024), Cloud Run worker pools (GA 2026), GPU support on Cloud Run, GKE Autopilot as default mode, new Axion-based machine types, and App Engine legacy runtime deprecations.

Compute Engine

  • provides Infrastructure as a Service (IaaS) in the Google Cloud
  • offers scalable, high performance virtual machines (VMs) on Google’s infrastructure.
  • provides full control/flexibility on the choice of OS, resources like CPU and memory
  • supports a wide range of machine families:
    • General-purpose: E2, N2, N2D, N4, N4A (Axion/Arm-based), C4, C4A (Axion/Arm-based), C4D
    • Compute-optimized: C2, C2D, H3
    • Memory-optimized: M1, M2, M3
    • Accelerator-optimized: A2, A3, G2 (with NVIDIA GPUs)
  • New (2024-2026):
    • Google Axion Processors – custom Arm-based processors powering C4A and N4A instances, delivering up to 65% better price-performance and 60% greater energy efficiency than comparable x86 systems
    • C4 VMs – latest Intel-based general-purpose VMs with Google Titanium system offload
    • C4D VMs – AMD-based with confidential computing support, up to 384 vCPUs and 3TB DDR5 memory
    • N4A VMs – most cost-effective N-series VM, up to 2x better price-performance than comparable x86 VMs (GA 2025)
  • Usage patterns
    • lift and shift migrations of existing systems
    • existing VM images to move to the cloud
    • need low-level access to or fine-grained control of the operating system, network, and other operational characteristics
    • require custom kernel or arbitrary OS
    • software that can’t be easily containerized
    • using a third party licensed software
    • AI/ML training workloads requiring GPU accelerators
  • Usage anti-patterns
    • containerized applications – Choose GKE or Cloud Run
    • stateless event-driven applications – Choose Cloud Run functions
    • simple web applications – Choose App Engine or Cloud Run

App Engine

  • is a platform as a service (PaaS) for developing and hosting web applications.
  • helps build highly scalable web and mobile backend applications on a fully managed serverless platform
  • developers can focus on writing code without having to manage the underlying infrastructure.
  • offers two environments:
    • Standard environment – applications run in a sandbox, supports specific runtimes, faster scaling including scale to zero
    • Flexible environment – applications run in Docker containers on Compute Engine VMs, supports any runtime
  • Runtime Updates (2024-2026):
    • Legacy runtimes (Python 2.7, Java 8, Go 1.11, PHP 5.5) reached end of support on January 30, 2024 – existing apps continue to run but re-deployment may be blocked
    • Go 1.11 and PHP 5.5 runtimes deprecated on January 31, 2026
    • Migration to second-generation runtimes is recommended
    • Latest supported runtimes include Python 3.12+, Java 21+, Node.js 20+, Go 1.22+, PHP 8.3+, Ruby 3.3+
  • Usage patterns
    • Rapidly developing CRUD-heavy applications
    • HTTP/S based applications
    • Deploying complex APIs
    • Applications needing automatic scaling without container management
  • Usage anti-patterns
    • Stateful applications requiring lots of in-memory states to meet the performance or functional requirements
    • Systems that require protocols other than HTTP
    • Applications requiring container-level customization – Choose Cloud Run
  • Note: For new projects, Google recommends evaluating Cloud Run as a more flexible alternative to App Engine, with an official migration guide available.

Google Kubernetes Engine – GKE

  • provides a managed environment for deploying, managing, and scaling containerized applications using Google infrastructure.
  • available in two modes:
    • Autopilot (recommended, default since 2023) – fully managed, Google configures and manages nodes, node pools, and in-cluster policy. Pay per pod resource requests.
    • Standard – user manages nodes and node configuration. More flexibility but more operational overhead.
  • GKE Updates (2024-2026):
    • Autopilot is now default mode for new cluster creation (30% of active GKE clusters used Autopilot in 2024)
    • Autopilot compute classes now available for Standard clusters – turn on Autopilot per-workload basis (KubeCon EU 2026)
    • GKE Enterprise (formerly Anthos) – enterprise tier for governing, managing, and operating workloads at scale across hybrid/multi-cloud
    • AI/ML workload support – 66% of organizations rely on Kubernetes for generative AI apps and agents (2026)
    • Multi-agent AI workflows surged 327% in early 2026
  • Usage patterns
    • containerized applications or those that can be easily containerized
    • Hybrid or multi-cloud environments (with GKE Enterprise)
    • Systems leveraging stateful and stateless services
    • Strong CI/CD Pipelines
    • AI/ML workloads requiring GPU orchestration at scale
    • Microservices architectures requiring service mesh
  • Usage anti-patterns
    • non-containerized applications – Choose Compute Engine or App Engine
    • applications requiring very low-level access to the underlying hardware like custom kernel, networking, etc. – Choose Compute Engine
    • stateless event-driven applications – Choose Cloud Run functions
    • simple stateless containerized apps not requiring Kubernetes features – Choose Cloud Run

Cloud Run

  • is a fully managed application platform for running code, functions, or containers on Google’s highly scalable infrastructure.
  • allows developers to build applications in any programming language and deploy them in seconds.
  • abstracts away all infrastructure management allowing users to focus on building applications.
  • is built from Knative.
  • Three resource types (2024-2026):
    • Services – responds to HTTP requests using stateless instances that autoscale (including scale to zero). Also handles events and functions.
    • Jobs – executes parallelizable tasks manually or on a schedule that run to completion.
    • Worker Pools (GA 2026) – handles always-on background workloads such as pull-based workloads (e.g., Kafka consumers, Pub/Sub pull queues, RabbitMQ consumers). Does NOT have a load-balanced endpoint or autoscale automatically.
  • Key Features (2024-2026):
    • GPU support – on-demand access to NVIDIA L4 GPUs for AI inference workloads, instances start in 5 seconds and scale to zero
    • Cloud Run functions – Cloud Functions rebranded and merged into Cloud Run (August 2024), same event-driven model with Cloud Run’s configurability
    • Sidecars – multi-container deployments with independent sidecar containers alongside main container
    • Always-on CPU allocation – CPU available even between requests for background processing
    • Volume mounts – Cloud Storage, NFS, in-memory, CIFS/SMB, and Ephemeral Disk support
    • Manual scaling option – override automatic scaling for predictable workloads
    • WebSocket and gRPC support – full support for real-time communication
    • Source-based deployment – deploy directly from source code without building containers
    • AI/ML workloads – run LLM inference (Ollama, Gemma), AI agents (ADK, A2A), and MCP servers
  • Usage patterns
    • Stateless services that are easily containerized
    • Event-driven applications and systems
    • Applications that require custom system and language dependencies
    • AI inference workloads (with GPU support)
    • Background processing (worker pools for Kafka consumers, message queues)
    • Batch processing (jobs with parallelism)
    • Websites, APIs, and microservices
  • Usage anti-patterns
    • Applications requiring persistent VMs with custom kernels – Choose Compute Engine
    • Complex container orchestration requiring Kubernetes features – Choose GKE
    • Applications requiring strict low-level infrastructure control

Cloud Run Functions (formerly Cloud Functions)

⚠️ Rebranding Notice (August 2024): Google Cloud Functions has been renamed to Cloud Run functions and merged under the Cloud Run platform. The event-driven programming model remains the same, but functions now run on Cloud Run infrastructure with its full configurability. The gcloud functions CLI and APIs continue to work.
  • offers scalable pay-as-you-go Functions as a Service (FaaS) to run code with zero server management.
  • provides a serverless execution environment for building and connecting Cloud services.
  • provides serverless compute for event-driven apps.
  • developers can focus on writing code without having to manage the underlying infrastructure.
  • Two generations:
    • Cloud Run functions (formerly 2nd gen / Cloud Functions 2nd gen) – runs on Cloud Run infrastructure, supports longer timeouts (up to 60 min), larger instances (up to 32 GB RAM, 8 vCPUs), concurrency, traffic splitting, and Direct VPC egress
    • Cloud Run functions (1st gen) (formerly Cloud Functions 1st gen) – original version with limited event triggers and configurability, limited to 9 min timeout and 8 GB RAM
  • Usage patterns
    • ephemeral and event-driven applications and functions
    • fully managed environment
    • pay only for what you use
    • quick data transformations (ETL)
    • Webhooks and lightweight APIs
    • Responding to Cloud Storage, Pub/Sub, Firestore, or Firebase events
  • Usage anti-patterns
    • continuous stateful application – Choose Compute Engine, App Engine, or GKE
    • long-running background processing – Choose Cloud Run worker pools
    • applications requiring multiple containers or sidecars – Choose Cloud Run services

Google Cloud Compute Options Comparison

Feature Compute Engine GKE App Engine Cloud Run Cloud Run Functions
Type IaaS CaaS (Container) PaaS Serverless Containers FaaS
Abstraction Level VMs Containers/Pods Application Container/Source Function
Scaling Autoscaler (MIGs) Pod/Node Autoscaler Automatic Automatic (0 to N) Automatic (0 to N)
Scale to Zero No No (pods stay) Yes (Standard) Yes Yes
GPU Support Yes Yes No Yes (NVIDIA L4) No
Max Timeout Unlimited Unlimited 60 min 60 min (services) 60 min (2nd gen)
Pricing Per VM (sec) Per node + mgmt fee Per instance-hour Per request/instance Per invocation + time
Google Cloud Compute Options Comparison
Credit @ https://thecloudgirl.dev/

Google Cloud Compute Options Decision Tree

Google Cloud Compute Options Decision Tree

Key Decision Criteria

  • Need full VM control? → Compute Engine
  • Containerized app needing Kubernetes features (service mesh, complex networking, stateful sets)? → GKE
  • Simple containerized app, HTTP-driven? → Cloud Run (services)
  • Background pull-based processing (Kafka, queues)? → Cloud Run (worker pools)
  • Batch/parallel tasks running to completion? → Cloud Run (jobs)
  • Event-driven single-purpose functions? → Cloud Run functions
  • Quick PaaS web app without container knowledge? → App Engine
  • AI inference with serverless GPU? → Cloud Run with GPU
  • AI training at scale with GPU orchestration? → GKE or Compute Engine

GCP Certification Exam Practice Questions

  • Questions are collected from Internet and the answers are marked as per my knowledge and understanding (which might differ with yours).
  • GCP services are updated everyday and both the answers and questions might be outdated soon, so research accordingly.
  • GCP exam questions are not updated to keep up the pace with GCP updates, so even if the underlying feature has changed the question might not be updated
  • Open to further feedback, discussion and correction.
  1. Your organization is developing a new application. This application responds to events created by already running applications. The business goal for the new application is to scale to handle spikes in the flow of incoming events while minimizing administrative work for the team. Which Google Cloud product or feature should you choose?
    1. Cloud Run
    2. Cloud Run for Anthos (Note: Cloud Run for Anthos has been deprecated and archived. It is now referred to as Knative serving on GKE.)
    3. App Engine standard environment
    4. Compute Engine
  2. A company wants to build an application that stores images in a Cloud Storage bucket and wants to generate thumbnails as well as resize the images. They want to use managed service which will help them scale automatically from zero to scale and back to zero. Which GCP service satisfies the requirement?
    1. Google Compute Engine
    2. Google Kubernetes Engine
    3. Google App Engine
    4. Cloud Run functions (formerly Cloud Functions)
  3. A startup needs to deploy a containerized machine learning inference model that requires GPU access, should scale to zero when not in use, and needs to start serving requests within seconds. Which compute option is most suitable?
    1. Compute Engine with GPU attached
    2. GKE with GPU node pool
    3. Cloud Run with GPU (NVIDIA L4)
    4. App Engine flexible environment
  4. Your team has a Kafka consumer application that needs to continuously process messages from a topic. The application does not serve HTTP requests. You want to use a serverless managed platform. Which Cloud Run resource type should you use?
    1. Cloud Run service
    2. Cloud Run job
    3. Cloud Run worker pool
    4. Cloud Run functions
  5. A company is running multiple microservices across on-premises data centers and Google Cloud. They need a consistent container orchestration platform with centralized policy management across all environments. Which solution should they use?
    1. Cloud Run
    2. App Engine flexible
    3. GKE Enterprise (formerly Anthos)
    4. Compute Engine managed instance groups
  6. You are designing a new serverless application that processes files uploaded to Cloud Storage. The processing takes about 30 seconds per file and you want minimal operational overhead. Which option is most appropriate?
    1. Compute Engine with a cron job
    2. Cloud Run functions triggered by Cloud Storage event
    3. GKE CronJob
    4. App Engine Standard with task queue
  7. Your team needs to run a data migration script that processes 10,000 records in parallel and should complete execution. The script does not need to serve HTTP traffic. Which Cloud Run resource type is best suited?
    1. Cloud Run service with always-on CPU
    2. Cloud Run job with parallelism
    3. Cloud Run worker pool
    4. Cloud Run functions
  8. A company wants to use Google’s custom Arm-based processors for their web servers to optimize cost and energy efficiency. Which instance family should they choose?
    1. N2 instances
    2. C2 instances
    3. C4A instances (Google Axion)
    4. E2 instances

See also: Google Cloud Compute Services Cheat Sheet

GKE Security – Workload Identity, RBAC & Hardening

~ Last updated on : ~ jayendrapatil

GKE Security

Google Kubernetes Engine – GKE Security provides multiple layers of security to secure workloads including the contents of the container image, the container runtime, the cluster network, and access to the cluster API server.

Authentication and Authorization

  • Kubernetes supports two types of authentication:
    • User accounts are accounts that are known to Kubernetes but are not managed by Kubernetes
    • Service accounts are accounts that are created and managed by Kubernetes but can only be used by Kubernetes-created entities, such as pods.
  • In a GKE cluster, Kubernetes user accounts are managed by Google Cloud and can be of the following type
    • Google Account
    • Google Cloud service account
  • Once authenticated, these identities need to be authorized to create, read, update or delete Kubernetes resources.
  • Kubernetes service accounts and Google Cloud service accounts are different entities.
    • Kubernetes service accounts are part of the cluster in which they are defined and are typically used within that cluster.
    • Google Cloud service accounts are part of a Google Cloud project, and can easily be granted permissions both within clusters and to Google Cloud project clusters themselves, as well as to any Google Cloud resource using IAM.

Control Plane Security

  • In GKE, the Kubernetes control plane components are managed and maintained by Google.
  • Control plane components host the software that runs the Kubernetes control plane, including the API server, scheduler, controller manager, and the etcd database where the Kubernetes configuration is persisted.
  • By default, the control plane components use a public IP address.
  • Kubernetes API server can be protected by using authorized networks, and private clusters, which allow assigning a private IP address to the control plane and disable access on the public IP address.
  • Control plane can also be secured by doing credential rotation on a regular basis. When credential rotation is initiated, the SSL certificates and cluster certificate authority are rotated. This process is automated by GKE and also ensures that your control plane IP address rotates.
  • GKE encrypts etcd data at rest by default. Application-layer secrets encryption provides an additional layer of security by encrypting Kubernetes Secrets in etcd using a Cloud KMS key that you manage.

Node Security

Container-Optimized OS

  • GKE nodes, by default, use Google’s Container-Optimized OS (cos_containerd) as the operating system on which to run Kubernetes and its components.
  • Container-Optimized OS features include
    • Locked-down firewall
    • Read-only filesystem where possible
    • Limited user accounts and disabled root login
  • GKE uses containerd as the container runtime for all new clusters and node pools.

Shielded GKE Nodes

  • Shielded GKE Nodes provide verifiable node identity and integrity by using Secure Boot, vTPM, and integrity monitoring.
  • Shielded GKE Nodes are enabled by default and cannot be overridden on new clusters.
  • They protect against boot-level and kernel-level malware or rootkits that could persist beyond an infected OS.

Node upgrades

  • GKE recommends upgrading nodes on a regular basis to patch the OS for security issues in the container runtime, Kubernetes itself, or the node operating system.
  • GKE supports automatic as well as manual upgrades.
  • GKE automatically applies security patches to nodes when available, adhering to configured maintenance schedules.

Protecting nodes from untrusted workloads

  • GKE Sandbox can be enabled on the cluster to isolate untrusted workloads in sandboxes on the node if the clusters run unknown or untrusted workloads.
  • GKE Sandbox is built using gVisor, an open-source container runtime that provides a specialized guest kernel for each container, intercepting system calls between the application and the host kernel.
  • GKE Agent Sandbox (2025) is an evolution of GKE Sandbox optimized for AI agent workloads, providing kernel-level isolation for untrusted LLM-generated code execution with sub-second latency and the ability to orchestrate hundreds of sandboxes per second.

Seccomp Profiles

  • GKE applies the default containerd seccomp profile to provide baseline syscall filtering while maintaining workload compatibility.
  • Autopilot clusters enforce Pod Security Standards at the Baseline level by default, preventing known privilege escalation pathways.

Securing instance metadata

  • GKE nodes run as Compute Engine instances and have access to instance metadata by default, which a Pod running on the node does not necessarily need.
  • Workload Identity Federation for GKE replaces the need to use Metadata Concealment. When Workload Identity Federation is enabled, it blocks access to the node’s metadata server from workloads.
  • Legacy metadata APIs are disabled by default on GKE versions 1.12 and newer.

Network Security

  • Network Policies help cluster administrators and users lock down the ingress and egress connections created to and from the Pods in a namespace.
  • GKE has two mutually exclusive network policy plugins:
    • GKE Dataplane V2 (based on Cilium/eBPF) – the recommended plugin for all clusters and the default for Autopilot clusters. Provides enhanced visibility, performance, and advanced policy features.
    • Calico (iptables-based) – available only in Standard clusters.
  • FQDN Network Policies (GKE Dataplane V2) allow controlling Pod egress traffic based on fully qualified domain names rather than IP addresses.
  • mTLS for Pod-to-Pod communication can be enabled using Cloud Service Mesh (previously known as Istio on GKE/Anthos Service Mesh).

Giving Pods Access to Google Cloud Resources

Workload Identity Federation for GKE (recommended)

  • Workload Identity Federation for GKE (previously called Workload Identity) is the simplest and most secure way to authorize Pods to access Google Cloud resources.
  • Pods authenticate with short-lived federated tokens tied to their Kubernetes ServiceAccount — no long-lived credentials are stored in the container.
  • Kubernetes entities (clusters, service accounts) can now be addressed directly as IAM principals.
  • Workload Identity Federation for GKE replaces the need for Metadata Concealment, and the two approaches are incompatible.
  • Fleet Workload Identity Federation extends this capability across an entire fleet, including clusters outside Google Cloud and across multiple projects.

Node Service Account

  • Pods can authenticate to Google Cloud using the Kubernetes cluster’s service account credentials from metadata.
  • Node Service Account credentials can be reached by any Pod running in the cluster if Workload Identity Federation is not enabled.
  • It is recommended to create and configure a custom service account that has the minimum IAM roles required by all the Pods running in the cluster.

Service Account JSON key

  • Applications can access Google Cloud resources by using the service account’s key.
  • This approach is NOT recommended because of the difficulty of securely managing account keys.
  • A JSON service account key can be created and then mounted into the Pod using a Kubernetes Secret.
  • Workload Identity Federation for GKE eliminates the need for key files entirely and is the preferred alternative.

Secrets Management

  • Application-layer Secrets Encryption encrypts Kubernetes Secrets stored in etcd using a Cloud KMS key that you manage, providing an additional layer of protection beyond default GKE encryption.
  • Secret Manager add-on for GKE allows Pods to directly access secrets stored in Google Cloud Secret Manager via the Secrets Store CSI Driver, without requiring custom code.
  • Secret Manager add-on supports auto-rotation and syncing secrets as Kubernetes Secret objects.

Binary Authorization

  • Binary Authorization helps ensure that internal processes that safeguard the quality and integrity of the software have successfully completed before an application is deployed to the production environment.
  • Binary Authorization works with images deployed to GKE from Artifact Registry (Container Registry was shut down on March 18, 2025).
  • Binary Authorization provides:
    • A policy model that lets you describe the constraints under which images can be deployed
    • An attestation model that lets you define trusted authorities who can attest or verify that required processes have completed before deployment
    • A deploy-time enforcer that prevents images that violate the policy from being deployed
  • Continuous Validation (CV) monitors running Pods to ensure their container images continue to conform to Binary Authorization check-based platform policies, including:
    • Image freshness checks
    • Simple signing attestation checks
    • Sigstore signature verification
    • SLSA provenance checks (requires Cloud Build)
    • Vulnerability checks

GKE Autopilot Security

  • Autopilot mode clusters have a stricter default security posture than Standard mode clusters.
  • GKE Autopilot automatically configures nodes, node pools, and in-cluster policy according to security best practices.
  • Key Autopilot security defaults:
    • Workload Identity Federation for GKE is always enabled
    • Shielded GKE Nodes are enabled
    • GKE Dataplane V2 is the default network plugin
    • Pod Security Standards are enforced at the Baseline level
    • Privileged containers and host namespace access are restricted
    • Container-Optimized OS with containerd is the only supported node image

GKE Security Posture

  • The GKE security posture dashboard helps proactively identify and address security vulnerabilities in GKE clusters.
  • Features include Kubernetes security configuration scanning (misconfiguration detection) and workload vulnerability scanning.
  • Note: As of January 2025, several GKE security posture capabilities have been deprecated:
    • GKE threat detection (deprecated Jan 28, 2025, shut down March 31, 2025)
    • GKE Compliance dashboard (deprecated Jan 28, 2025)
    • Workload vulnerability scanning in GKE Standard edition has been removed; it requires GKE Enterprise edition
  • For comprehensive threat detection and vulnerability management, Google recommends using Security Command Center.

GCP Certification Exam Practice Questions

  • Questions are collected from Internet and the answers are marked as per my knowledge and understanding (which might differ with yours).
  • GCP services are updated everyday and both the answers and questions might be outdated soon, so research accordingly.
  • GCP exam questions are not updated to keep up the pace with GCP updates, so even if the underlying feature has changed the question might not be updated
  • Open to further feedback, discussion and correction.
  1. You are building a product on top of Google Kubernetes Engine (GKE). You have a single GKE cluster. For each of your customers, a Pod is running in that cluster, and your customers can run arbitrary code inside their Pod. You want to maximize the isolation between your customers’ Pods. What should you do?
    1. Use Binary Authorization and whitelist only the container images used by your customers’ Pods.
    2. Use the Container Analysis API to detect vulnerabilities in the containers used by your customers’ Pods.
    3. Create a GKE node pool with a sandbox type configured to gVisor. Add the parameter runtimeClassName: gvisor to the specification of your customers’ Pods.
    4. Use the cos_containerd image for your GKE nodes. Add a nodeSelector with the value cloud.google.com/gke-os-distribution: cos_containerd to the specification of your customers’ Pods.
  2. Your organization runs workloads on GKE and wants to ensure that Pods can only access Google Cloud APIs using short-lived credentials without managing service account keys. What should you configure?
    1. Create a Google Cloud service account key and store it as a Kubernetes Secret.
    2. Enable Workload Identity Federation for GKE and bind the Kubernetes ServiceAccount to a Google Cloud service account as an IAM principal.
    3. Use the node’s default service account credentials with metadata concealment enabled.
    4. Download a service account key and mount it as a volume in the Pod.
  3. You need to control egress traffic from Pods in your GKE cluster to specific external services by domain name. Which feature should you use?
    1. Standard Kubernetes NetworkPolicy with IP address blocks.
    2. Cloud Armor policies applied to the cluster.
    3. FQDN Network Policies with GKE Dataplane V2 enabled.
    4. VPC firewall rules targeting the node IP addresses.
  4. Your company needs to ensure that only container images that have been verified and attested by your CI/CD pipeline can be deployed to your GKE production cluster. Additionally, you want ongoing monitoring of running workloads. What should you implement?
    1. Use Artifact Registry vulnerability scanning only.
    2. Configure Pod Security Standards at the Restricted level.
    3. Enable Binary Authorization with attestation policies and Continuous Validation (CV) for runtime monitoring.
    4. Use GKE Sandbox to isolate all production workloads.
  5. You want your GKE cluster to have the strongest default security configuration with minimal manual setup. Which cluster mode should you use?
    1. Standard mode with all security features manually enabled.
    2. Autopilot mode, which enforces security best practices by default including Workload Identity Federation, Shielded Nodes, and Pod Security Standards.
    3. Standard mode with Container-Optimized OS selected.
    4. Standard mode with Shielded GKE Nodes enabled.

References

Google Kubernetes Engine – GKE

~ Last updated on : ~ jayendrapatil

Google Kubernetes Engine – GKE

  • Google Kubernetes Engine – GKE provides a managed environment for deploying, managing, and scaling containerized applications using Google infrastructure.
  • GKE is available in two editions:
    • GKE Standard edition – core GKE functionality including cluster management, autoscaling, release channels, fleet management, Config Management, and Policy Controller at no additional cost.
    • GKE Enterprise edition – adds advanced security, compliance insights, Binary Authorization, service mesh, multi-cluster management, and richer networking features for enterprise-scale operations.

Standard vs Autopilot Cluster

  • Autopilot (Recommended – Default mode since 2023)
    • Provides a fully provisioned and managed cluster configuration.
    • Cluster configuration options are made for you.
    • Autopilot clusters are pre-configured with an optimized cluster configuration that is ready for production workloads.
    • GKE manages the entire underlying infrastructure of the clusters, including the control plane, nodes, and all system components.
    • Applies security best practices by default including hardened node configuration, automatic security patching, and default seccomp profiles.
    • Billing is based on Pod resource requests (CPU, memory, ephemeral storage) rather than node-level resources.
    • Uses a container-optimized compute platform (introduced 2025) that delivers up to 85% faster provisioning speed and improved autoscaling performance.
    • Supports ComputeClasses (Balanced, Scale-Out, custom) to let workloads specify hardware requirements like GPUs, high-memory, or accelerator-optimized nodes.
    • In 2024, 30% of all active GKE clusters were created in Autopilot mode.
  • Standard
    • Provides advanced configuration flexibility over the cluster’s underlying infrastructure.
    • Cluster configurations needed for the production workloads are determined by you.
    • You manage node pools, machine types, scaling policies, and node-level security.
    • Supports Autopilot mode workloads in Standard clusters – allows deploying ComputeClasses and letting GKE auto-create/manage node pools for specific workloads while retaining Standard cluster control for others.

GKE - Autopilot vs Standard Clusters

Zonal vs Regional Cluster

  • Zonal clusters
    • Zonal clusters have a single control plane in a single zone.
    • Depending on the availability requirements, nodes for the zonal cluster can be distributed in a single zone or in multiple zones.
    • Single-zone clusters
      • Control Plane -> Single Zone & Workers -> Single Zone
      • A single-zone cluster has a single control plane running in one zone.
      • Control plane manages workloads on nodes running in the same zone.
    • Multi-zonal clusters
      • Control Plane -> Single Zone & Workers -> Multi-Zone
      • A multi-zonal cluster has a single replica of the control plane running in a single zone and has nodes running in multiple zones.
      • During an upgrade of the cluster or an outage of the zone where the control plane runs, workloads still run. However, the cluster, its nodes, and its workloads cannot be configured until the control plane is available.
      • Multi-zonal clusters balance availability and cost for consistent workloads.
  • Regional clusters
    • Control Plane -> Multi Zone & Workers -> Multi-Zone
    • A regional cluster has multiple replicas of the control plane, running in multiple zones within a given region.
    • Nodes also run in each zone where a replica of the control plane runs.
    • Because a regional cluster replicates the control plane and nodes, it consumes more Compute Engine resources than a similar single-zone or multi-zonal cluster.

GKE Zonal vs Regional Cluster

Route-Based Cluster vs VPC-Native Cluster

  • VPC-native clusters (using Alias IPs) are the default and recommended networking mode.
  • VPC-native mode is always on for Autopilot clusters and cannot be turned off.
  • Route-based clusters require explicitly disabling the VPC-native option and are not recommended for new deployments.
  • VPC-native clusters offer better scalability (not subject to route quotas), native integration with VPC features, and support for Private Google Access.

Refer blog post @ Google Kubernetes Engine Networking

Private Cluster

  • Private clusters help isolate nodes from having inbound and outbound connectivity to the public internet by providing nodes with internal IP addresses only.
  • External clients can still reach the services exposed as a load balancer by calling the external IP address of the HTTP(S) load balancer.
  • Cloud NAT or self-managed NAT gateway can provide outbound internet access for certain private nodes.
  • By default, Private Google Access is enabled, which provides private nodes and their workloads with limited outbound access to Google Cloud APIs and services over Google’s private network.
  • The defined VPC network contains the cluster nodes, and a separate Google Cloud VPC network contains the cluster’s control plane.
  • The control plane’s VPC network is located in a project controlled by Google. The control plane’s VPC network is connected to the cluster’s VPC network with VPC Network Peering. Traffic between nodes and the control plane is routed entirely using internal IP addresses.
  • Control plane for a private cluster has a private endpoint in addition to a public endpoint.
  • Control plane public endpoint access level can be controlled:
    • Public endpoint access disabled
      • Most secure option as it prevents all internet access to the control plane.
      • Cluster can be accessed using Bastion host/Jump server or if Cloud Interconnect and Cloud VPN have been configured from the on-premises network to connect to Google Cloud.
      • Authorized networks must be configured for the private endpoint, which must be internal IP addresses.
    • Public endpoint access enabled, authorized networks enabled:
      • Provides restricted access to the control plane from defined source IP addresses.
    • Public endpoint access enabled, authorized networks disabled
      • Default and least restrictive option.
      • Publicly accessible from any source IP address as long as you authenticate.
  • Nodes always contact the control plane using the private endpoint.

Shared VPC Clusters

  • Shared VPC supports both zonal and regional clusters.
  • Shared VPC supports VPC-native clusters and must have Alias IPs enabled. Legacy networks are not supported.

Node Pools

  • A node pool is a group of nodes within a cluster that all have the same configuration and are identical to one another.
  • Node pools use a NodeConfig specification.
  • Each node in the pool has a cloud.google.com/gke-nodepool Kubernetes node label, which has the node pool’s name as its value.
  • Number of nodes and type of nodes specified during cluster creation becomes the default node pool. Additional custom node pools of different sizes and types can be added to the cluster for e.g. local SSDs, GPUs, Spot VMs, or different machine types.
  • Node pools can be created, upgraded, and deleted individually without affecting the whole cluster. However, a single node in a node pool cannot be configured; any configuration changes affect all nodes in the node pool.
  • You can resize node pools in a cluster by adding or removing nodes using gcloud container clusters resize CLUSTER_NAME --node-pool POOL_NAME --num-nodes NUM_NODES
  • Existing node pools can be manually upgraded or automatically upgraded.
  • For a multi-zonal or regional cluster, all of the node pools are replicated to those zones automatically. Any new node pool is automatically created or deleted in those zones.
  • GKE drains all the nodes in the node pool when a node pool is deleted.
  • Spot VMs (replacement for Preemptible VMs) can be used in node pools for fault-tolerant workloads with up to 60-91% cost savings.
  • Node pool auto-creation (formerly Node Auto-Provisioning/NAP) allows GKE to automatically create and delete node pools based on workload requirements and ComputeClass specifications.

Cluster Autoscaler

  • GKE’s cluster autoscaler automatically resizes the number of nodes in a given node pool, based on the demands of the workloads.
  • Cluster autoscaler is automatic by specifying the minimum and maximum size of the node pool and does not require manual intervention.
  • Cluster autoscaler increases or decreases the size of the node pool automatically, based on the resource requests (rather than actual resource utilization) of Pods running on that node pool’s nodes.
    • If Pods are unschedulable because there are not enough nodes in the node pool, cluster autoscaler adds nodes, up to the maximum size of the node pool.
    • If nodes are under-utilized, and all Pods could be scheduled even with fewer nodes in the node pool, cluster autoscaler removes nodes, down to the minimum size of the node pool. If the node cannot be drained gracefully after a timeout period (currently 10 minutes – not configurable), the node is forcibly terminated.
  • Before enabling cluster autoscaler, design the workloads to tolerate potential disruption or ensure that critical Pods are not interrupted.
  • Workloads might experience transient disruption with autoscaling, esp. with workloads running with a single replica.
  • With Autopilot clusters, you don’t need to configure cluster autoscaler because node pools are automatically provisioned and scaled to meet workload requirements.

ComputeClasses

  • A ComputeClass is a Kubernetes custom resource that defines a list of node configurations (machine types, feature settings, hardware requirements) for GKE to follow when provisioning nodes.
  • Built-in ComputeClasses (Autopilot):
    • General-Purpose (default) – standard compute for most workloads.
    • Balanced – optimized balance of compute, memory, and networking.
    • Scale-Out – cost-efficient for horizontally scalable workloads.
    • Accelerator – for GPU/TPU workloads (AI/ML).
  • Custom ComputeClasses let you define prioritized lists of node configurations for autoscaling, including machine families, Spot VM fallback, specific zones, and hardware constraints.
  • ComputeClasses work in both Autopilot and Standard clusters (with Autopilot mode enabled for the workload).
  • Pods select a ComputeClass using the cloud.google.com/compute-class node selector or nodeAffinity.

Release Channels & Extended Support

  • GKE release channels provide automatic version management:
    • Rapid – latest Kubernetes release; access new GKE features as soon as they go GA.
    • Regular – 1-2 months after Rapid; balance of feature access and stability.
    • Stable – 2-3 months after Regular; priority on stability.
    • Extended – for clusters needing longer support on a specific minor version.
  • Extended Support (since GKE 1.27): clusters can remain on a specific minor version for up to 24 months – 14 months of standard support plus ~10 months of extended support with continued security patches.
  • Clusters enrolled in release channels receive automatic upgrades within their channel’s schedule.

Auto-upgrading Nodes

  • Node auto-upgrades help keep the nodes in the GKE cluster up-to-date with the cluster control plane version when the control plane is updated on your behalf.
  • Node auto-upgrade is enabled by default when a new cluster or node pool is created with Google Cloud Console or the gcloud command.
  • Node auto-upgrades provide several benefits:
    • Lower management overhead – no need to manually track and update the nodes when the control plane is upgraded on your behalf.
    • Better security – GKE automatically ensures that security updates are applied and kept up to date.
    • Ease of use – provides a simple way to keep the nodes up to date with the latest Kubernetes features.
  • Node pools with auto-upgrades enabled are scheduled for upgrades when they meet the selection criteria. Rollouts are phased across multiple weeks to ensure cluster and fleet stability.
  • During the upgrade, nodes are drained and re-created to match the current control plane version. Modifications on the boot disk of a node VM do not persist across node re-creations. To preserve modifications across node re-creation, use a DaemonSet.
  • Enabling auto-upgrades does not cause the nodes to upgrade immediately.

Workload Identity Federation

  • Workload Identity Federation for GKE (previously known as Workload Identity) is the recommended way for workloads running on GKE to authenticate to Google Cloud APIs.
  • Eliminates the need for service account keys, which are a security risk due to being long-lived credentials.
  • Allows Kubernetes service accounts to act as IAM principals, directly referencing them in IAM policies without an intermediate Google service account.
  • Provides per-Pod identity using the principle of least privilege, unlike node-level service accounts that are shared by all workloads on a node.
  • Enabled by default on Autopilot clusters.
  • Supports fleet-level Workload Identity Federation for multi-cluster environments.

Fleet Management

  • A Fleet is a logical grouping of GKE clusters that enables multi-cluster management and governance.
  • Fleets allow you to manage features like Config Management, Policy Controller, and service mesh across multiple clusters simultaneously.
  • Fleet-level features include:
    • Teams – define team scopes across clusters for multi-tenancy.
    • Config Sync – apply consistent configuration across fleet members.
    • Policy Controller – enforce governance policies fleet-wide.
    • Service Mesh – unified service mesh across clusters (Cloud Service Mesh).
    • Multi-cluster Services (MCS) – discover and route to services across clusters.
    • Multi-cluster Gateway – global load balancing across clusters using Gateway API.
  • Fleet management features are available in GKE Standard edition at no additional cost (since 2024).

GKE Security

https://jayendrapatil.com/google-kubernetes-engine-gke-security/

GCP Certification Exam Practice Questions

  • Questions are collected from Internet and the answers are marked as per my knowledge and understanding (which might differ with yours).
  • GCP services are updated everyday and both the answers and questions might be outdated soon, so research accordingly.
  • GCP exam questions are not updated to keep up the pace with GCP updates, so even if the underlying feature has changed the question might not be updated
  • Open to further feedback, discussion and correction.
  1. Your existing application running in Google Kubernetes Engine (GKE) consists of multiple pods running on four GKE n1-standard-2 nodes. You need to deploy additional pods requiring n2-highmem-16 nodes without any downtime. What should you do?
    1. Use gcloud container clusters upgrade. Deploy the new services.
    2. Create a new Node Pool and specify machine type n2-highmem-16. Deploy the new pods.
    3. Create a new cluster with n2-highmem-16 nodes. Redeploy the pods and delete the old cluster.
    4. Create a new cluster with both n1-standard-2 and n2-highmem-16 nodes. Redeploy the pods and delete the old cluster.
  2. A company is running a production GKE cluster and wants to minimize operational overhead while ensuring nodes are always patched and running the latest supported Kubernetes version. What should they configure?
    1. Manually upgrade nodes each quarter using gcloud container clusters upgrade.
    2. Use GKE Autopilot mode with release channels enabled.
    3. Disable auto-upgrade and use a custom CI/CD pipeline for upgrades.
    4. Use preemptible VMs so nodes are recycled frequently.
  3. Your organization runs multiple GKE clusters across different regions. You need a way to apply consistent security policies and deploy services accessible across all clusters. Which features should you use?
    1. Create separate IAM policies for each cluster and use external load balancers.
    2. Register clusters in a Fleet and use Policy Controller with Multi-cluster Services.
    3. Deploy identical configurations manually to each cluster.
    4. Use a single regional cluster spanning all regions.
  4. A team wants their GKE workloads to securely access Google Cloud Storage and BigQuery APIs without managing service account keys. What is the recommended approach?
    1. Mount service account JSON keys as Kubernetes secrets.
    2. Use the node’s default service account for all Pods.
    3. Enable Workload Identity Federation and bind Kubernetes service accounts to IAM principals.
    4. Store service account keys in Secret Manager and inject at runtime.
  5. You are deploying an AI/ML training workload on GKE that requires GPU nodes. You want GKE to automatically provision the right node type without manual node pool creation. What should you use?
    1. Manually create a GPU node pool and set taints/tolerations.
    2. Use cluster autoscaler with a pre-created GPU node pool.
    3. Use GKE Autopilot with the Accelerator ComputeClass.
    4. Deploy the workload on CPU nodes and use software-based GPU emulation.
  6. You want your GKE cluster to remain on Kubernetes version 1.29 for 24 months to minimize disruption to production workloads. What should you configure?
    1. Disable auto-upgrades and manually manage the cluster version.
    2. Use the Rapid release channel for the latest patches.
    3. Enroll the cluster in the Extended release channel for extended support.
    4. Create a new cluster every 14 months on the desired version.

References

GKE Networking – VPC, Gateway API & Dataplane V2

~ Last updated on : ~ jayendrapatil

Google Kubernetes Engine – Networking

📅 Last Updated: June 2026 — Added GKE Dataplane V2, Gateway API, Network Isolation simplification, Multi-Pod CIDR, Multi-Network support, IPv6 Dual-Stack, and GKE Inference Gateway sections.

IP allocation

Kubernetes uses various IP ranges to assign IP addresses to Nodes, Pods, and Services.

  • Node IP
    • Each node has an IP address assigned from the cluster’s VPC network.
    • Node IP provides connectivity from control components like kube-proxy and kubelet to the Kubernetes API server.
    • Node IP is the node’s connection to the rest of the cluster.
  • Pod CIDR or Address Range
    • Each node has a pool of IP addresses that GKE assigns the Pods running on that node (a /24 CIDR block by default).
    • With Multi-Pod CIDR (GKE 1.29+), additional Pod IP address ranges can be added to an existing cluster without recreating it.
  • Pod Address
    • Each Pod has a single IP address assigned from the Pod CIDR range of its node.
    • Pod IP address is shared by all containers running within the Pod and connects them to other Pods running in the cluster.
  • Service Address Range
    • Each Service has an IP address, called the ClusterIP, assigned from the cluster’s VPC network.
  • For Standard clusters
    • a maximum of 110 Pods can run on a node with a /24 range, not 256 as you might expect. This provides a buffer so that Pods don’t become unschedulable due to a transient lack of IP addresses in the Pod IP range for a given node.
    • For ranges smaller than /24, roughly half as many Pods can be scheduled as IP addresses in the range.
  • Autopilot clusters can run a maximum of 32 Pods per node.

GKE Cluster Networking Types

  • GKE, clusters can be distinguished according to the way they route traffic from one Pod to another Pod.
    • VPC-native cluster: A cluster that uses alias IP address ranges (recommended and default)
    • Routes-based cluster: A cluster that uses custom static routes in a VPC network (legacy, not recommended for new clusters)
  • GKE clusters can also be distinguished by their dataplane:
    • GKE Dataplane V2 (default for Autopilot): Uses eBPF/Cilium for packet processing, replacing iptables and kube-proxy
    • Legacy Dataplane: Uses iptables and kube-proxy with Calico for network policy

VPC-Native Clusters

  • VPC-native cluster uses alias IP address ranges
  • VPC-native is the default and recommended network mode for all new clusters
  • VPC-native clusters have several benefits:
    • Pod IP addresses are natively routable within the cluster’s VPC network and other VPC networks connected to it by VPC Network Peering.
    • Pod IP address ranges, and subnet secondary IP address ranges in general, are accessible from on-premises networks connected with Cloud VPN or Cloud Interconnect using Cloud Routers.
    • Pod IP addresses are reserved in the VPC network before the Pods are created in the cluster. This prevents conflict with other resources in the VPC network and allows you to better plan IP address allocations.
    • Pod IP address ranges do not depend on custom static routes and do not consume the system-generated and custom static routes quota. Instead, automatically generated subnet routes handle routing for VPC-native clusters.
    • Firewall rules can be created that apply to just Pod IP address ranges instead of any IP address on the cluster’s nodes.
    • Supports GKE Dataplane V2 with eBPF-based networking
    • Required for multi-network support for Pods (multi-NIC)

VPC-Native Clusters IP Allocation

Google Kubernetes Engine Networking VPC-Native Cluster IP Management

  • VPC-native cluster uses three unique subnet IP address ranges
    • Subnet’s primary IP address range for all node IP addresses.
      • Node IP addresses are assigned from the primary IP address range of the subnet associated with the cluster.
      • Both node IP addresses and the size of the subnet’s secondary IP address range for Pods limit the number of nodes that a cluster can support
    • One secondary IP address range for all Pod IP addresses.
      • Pod IP addresses are taken from the cluster subnet’s secondary IP address range for Pods.
      • By default, GKE allocates a /24 alias IP range (256 addresses) to each node for the Pods running on it.
      • On each node, those 256 alias IP addresses support up to 110 Pods.
      • Pod Address Range previously could not be changed once created. However, with Multi-Pod CIDR (available since GKE 1.29), additional Pod IP address ranges can now be added to an existing cluster.
        • Allows adding discontiguous secondary ranges for Pod IPs without recreating the cluster.
        • If the original range is exhausted, add a new Pod CIDR range using gcloud container clusters update.
        • Alternatively, node pools can be recreated with decreased --max-pods-per-node settings.
    • Another secondary IP address range for all Service (cluster IP) addresses.
      • Service (cluster IP) addresses are taken from the cluster’s subnet’s secondary IP address range for Services.
      • Service address range should be large enough to provide addresses for all the Kubernetes Services hosted in the cluster.
  • Node, Pod, and Services IP address ranges must all be unique and subnets with overlapping primary and secondary IP addresses cannot be created.

Routes-based Cluster

⚠️ Note: Routes-based clusters are legacy and not recommended for new clusters. VPC-native clusters are the default and recommended mode. To create a routes-based cluster, you must explicitly disable the VPC-native option.
  • Routes-based cluster that uses custom static routes in a VPC network i.e. it uses Google Cloud Routes to route traffic between nodes
  • In a routes-based cluster,
    • each node is allocated a /24 range of IP addresses for Pods.
    • With a /24 range, there are 256 addresses, but the maximum number of Pods per node is 110.
    • With approximately twice as many available IP addresses as possible Pods, Kubernetes is able to mitigate IP address reuse as Pods are added to and removed from a node.
  • Routes-based cluster uses two unique subnet IP address ranges
    • Subnet’s primary IP address range for all node IP addresses.
      • Node IP addresses are taken from the primary range of the cluster subnet
      • Cluster subnet must be large enough to hold the total number of nodes in your cluster.
    • Pod address range
      • A routes-based cluster has a range of IP addresses that are used for Pods and Services
      • Last /20 (4096 addresses) of the Pod address range is used for Services and the rest of the range is used for Pods
      • Pod address range size cannot be changed after cluster creation. So ensure that a large enough Pod address range is chosen to accommodate the cluster’s anticipated growth during cluster creation
  • Maximum number of nodes, Pods, and Services for a given GKE cluster is determined by the size of the cluster subnet and the size of the Pod address range.
  • Routes-based clusters do not support GKE Dataplane V2, multi-network Pods, or many newer GKE networking features.

GKE Dataplane V2

  • GKE Dataplane V2 is a modern dataplane optimized for Kubernetes networking, powered by eBPF and Cilium.
  • Enabled by default for all new Autopilot clusters.
  • Replaces iptables and kube-proxy with eBPF programs for packet processing, routing, load balancing, and network policy enforcement.
  • Key benefits:
    • Scalability: Removes iptables bottlenecks; supports up to 260,000 endpoints across all services via eBPF maps.
    • Security: Kubernetes NetworkPolicy is always enabled without needing third-party add-ons like Calico.
    • Observability: Built-in network policy logging and Hubble integration for real-time traffic visibility.
    • Consistency: Unified networking behavior across GKE environments.
    • SCTP Support: Supports Stream Control Transmission Protocol workloads.
  • Implementation:
    • Deploys a DaemonSet named anetd in the kube-system namespace on each node.
    • anetd interprets Kubernetes objects and programs network topologies using eBPF.
    • Does not use kube-proxy or iptables for service routing.
  • Cluster scale with Dataplane V2:
    • Up to 15,000 nodes per regional cluster (65,000 with scale-optimized mode that disables network policy enforcement).
    • Up to 400,000 Pods per cluster.
    • Up to 10,000 ClusterIP Services.
  • Limitations:
    • Can only be enabled at cluster creation time; existing clusters cannot be upgraded.
    • Custom eBPF programs are not supported on Dataplane V2 nodes.
    • Third-party eBPF tools may interfere with Dataplane V2 programs.
  • Supports Cilium Cluster-wide Network Policies for centralized network rule enforcement across all namespaces.
  • Refer GKE Dataplane V2

GKE Network Isolation (Control Plane & Node Access)

  • As of January 2025, GKE has simplified cluster networking by decoupling control-plane access from node-pool IP configuration.
    • The terms “public cluster” and “private cluster” are being replaced with flexible network isolation settings.
    • Control plane access and node configuration can now be changed at any time without recreating the cluster.
  • Control Plane Access Methods:
    • DNS-based endpoint (new, recommended): Uses IAM and authentication-based policies for dynamic, flexible access. Works with VPC Service Controls for multi-layer security.
    • Public IP-based endpoint: Traditional external access with authorized networks.
    • Private IP-based endpoint: Access restricted to private networks (VPC Peering or Private Service Connect-based clusters). Can now be locked down to specific RFC-1918 addresses.
  • All three endpoints can be enabled simultaneously or in any combination.
  • Node Pool Flexibility:
    • Each node pool has its own network configuration (public/private IP).
    • Public IPs can be attached or detached from node pools independently at any time.
    • Traffic between nodes and the control plane is always private regardless of configuration.
  • Private Service Connect (PSC): Newer clusters use PSC instead of VPC Peering for control-plane connectivity, eliminating VPC peering complexity.
  • Refer GKE Network Isolation

Gateway API (Recommended for Service Networking)

  • The Gateway API is the recommended evolution of Kubernetes service networking, replacing traditional Ingress resources.
  • Key advantages over Ingress:
    • Role-oriented: Separate API resources for cluster operators (Gateway), developers (HTTPRoute), and infrastructure providers (GatewayClass).
    • Expressive: Built-in support for header-based matching, traffic weighting, and traffic splitting without custom annotations.
    • Portable: Consistent concepts across environments with a core conformance model.
    • Multi-namespace: A single Gateway can serve routes across multiple namespaces.
  • GKE Gateway supports:
    • External and Internal Application Load Balancers
    • Frontend mTLS (client certificate validation) — 2025
    • Cloud CDN integration
    • Multi-cluster Gateways for cross-cluster load balancing
  • All Ingress resources are directly convertible to Gateway and HTTPRoute resources.
  • Refer GKE Gateway API

GKE Inference Gateway

  • GKE Inference Gateway is a specialized networking layer for AI/ML inference workloads, announced in 2025.
  • Extends the GKE Gateway to optimize serving of generative AI applications.
  • Key features:
    • Model-aware routing: Routes traffic to inference pools of model replicas based on model name.
    • Predicted latency-based routing: Routes requests to the model server with the lowest predicted latency.
    • Body-based routing: Routes based on request body content.
    • Prefix caching: Accelerates inference by caching common prompt prefixes.
    • Multi-cluster support: Scale AI workloads across clusters and regions.
  • Benchmarks show 15.7% higher throughput, 92.8% shorter wait times, and 62.6% lower inter-token latency vs. competing solutions.
  • Refer GKE Inference Gateway

Multi-Network Support for Pods

  • GKE supports attaching multiple network interfaces (multi-NIC) to Pods, removing the single-interface limitation.
  • Requires GKE Dataplane V2 and VPC-native clusters.
  • Use cases:
    • Separating control plane traffic from data plane traffic.
    • Network isolation between different workload types.
    • Multicast capability for Pods.
    • High-performance RDMA networking for AI/GPU workloads (via DRANET).
  • Pods can connect to up to 8 networks (default + 7 additional).
  • DRANET (Dynamic Resource Allocation for Networking): Specifically designed for AI workloads running across multiple GPUs, enabling RDMA network interface allocation for high-throughput inter-GPU communication.
  • Supports multi-network network policies for per-interface traffic control.
  • Refer Multi-Network Support for Pods

IPv6 Dual-Stack Networking

  • GKE supports dual-stack (IPv4 and IPv6) networking for clusters.
  • Available for Standard clusters (GKE 1.24+) and Autopilot clusters (GKE 1.25+).
  • Dual-stack clusters assign both IPv4 and IPv6 addresses to Pods and Services.
  • Requirements:
    • VPC-native clusters only.
    • Dual-stack subnets with both IPv4 and IPv6 ranges.
    • For internal IPv6, VPC must be custom mode with ULA internal IPv6 enabled.
  • Enables applications to serve both IPv4 and IPv6 clients without separate infrastructure.

Related Reads

GCP Certification Exam Practice Questions

  • Questions are collected from Internet and the answers are marked as per my knowledge and understanding (which might differ with yours).
  • GCP services are updated everyday and both the answers and questions might be outdated soon, so research accordingly.
  • GCP exam questions are not updated to keep up the pace with GCP updates, so even if the underlying feature has changed the question might not be updated
  • Open to further feedback, discussion and correction.

Questions on GKE Networking Updates:

  1. Your organization runs a GKE cluster that is running out of Pod IP addresses. What is the best approach to address this without downtime?
    1. Recreate the cluster with a larger Pod CIDR range
    2. Use Multi-Pod CIDR to add additional Pod IP address ranges to the existing cluster
    3. Migrate to a routes-based cluster with more IP space
    4. Reduce the number of Pods per node
    Show Answer

    Answer: b – Multi-Pod CIDR (GKE 1.29+) allows adding discontiguous Pod IP ranges to existing VPC-native clusters without recreation.

  2. Which of the following are advantages of GKE Dataplane V2 over the legacy dataplane? (Choose THREE)
    1. Uses eBPF instead of iptables for packet processing
    2. Built-in Kubernetes NetworkPolicy enforcement without third-party add-ons
    3. Can be enabled on existing clusters via an upgrade
    4. Provides real-time network observability via Hubble
    5. Requires manual installation of Calico for network policies
    Show Answer

    Answer: a, b, d – Dataplane V2 uses eBPF/Cilium replacing iptables/kube-proxy, has built-in NetworkPolicy (no Calico needed), and integrates Hubble for observability. It can only be enabled at cluster creation.

  3. A company wants to change their GKE cluster from publicly accessible to private without recreating it. Which GKE networking feature enables this?
    1. VPC Peering-based private clusters
    2. Routes-based cluster configuration
    3. GKE flexible network isolation with DNS-based endpoints
    4. Cloud NAT configuration
    Show Answer

    Answer: c – Since January 2025, GKE allows changing control-plane access and node-pool configuration at any time without cluster recreation. DNS-based endpoints provide IAM-based dynamic security.

  4. Your team needs to expose multiple HTTP services across different namespaces using a single load balancer with traffic splitting capabilities. Which GKE networking resource should you use?
    1. Kubernetes Ingress with annotations
    2. GKE Gateway with HTTPRoute resources
    3. LoadBalancer Service per application
    4. Cloud DNS with round-robin
    Show Answer

    Answer: b – Gateway API is the recommended approach for HTTP service networking in GKE. A single Gateway can serve routes across namespaces with built-in traffic splitting.

  5. An AI team needs high-throughput RDMA networking between GPU pods in their GKE cluster. Which feature should they use?
    1. Standard Pod networking with increased MTU
    2. Multi-network support for Pods with DRANET
    3. Routes-based cluster with custom routes
    4. GKE Inference Gateway
    Show Answer

    Answer: b – DRANET (Dynamic Resource Allocation for Networking) enables allocation of RDMA network interfaces for high-throughput inter-GPU communication in AI workloads.

  6. What is the maximum number of nodes supported in a GKE regional cluster with Dataplane V2?
    1. 5,000 nodes
    2. 15,000 nodes
    3. 65,000 nodes with scale-optimized mode
    4. 1,000 nodes
    Show Answer

    Answer: c – GKE supports up to 65,000 nodes in regional clusters with Dataplane V2 scale-optimized mode (which disables network policy enforcement). Standard regional clusters support up to 15,000 nodes.

 

Google Cloud Compute Services Cheat Sheet

~ Last updated on : ~ jayendrapatil

Google Cloud Compute Services

Google Cloud - Compute Services Options

Google Cloud provides a range of compute services to run workloads, from fully managed serverless platforms to infrastructure-level virtual machines. The key compute services include Compute Engine, GKE, App Engine, Cloud Run, and Cloud Run functions (formerly Cloud Functions).

Compute Engine

  • is a virtual machine (VM) hosted on Google’s infrastructure.
  • can run the public images for Google provided Linux and Windows Server as well as custom images created or imported from existing systems
  • availability policy determines how it behaves when there is a maintenance event
    • VM instance’s maintenance behavior onHostMaintenance, which determines whether the instance is live migrated MIGRATE (default) or stopped TERMINATE
    • Instance’s restart behavior automaticRestart which determines whether the instance automatically restarts (default) if it crashes or gets stopped
  • Live migration helps keep the VM instances running even when a host system event, such as a software or hardware update, occurs
  • Spot VMs (recommended replacement for Preemptible VMs) offer up to 60-91% discount compared to on-demand pricing
    • can be reclaimed by Compute Engine at any time when resources are needed
    • unlike Preemptible VMs, Spot VMs have no maximum runtime limit (no 24-hour expiration)
    • same pricing model as Preemptible VMs
    • ideal for fault-tolerant, batch, and stateless workloads
  • Preemptible VMs (legacy — Google recommends using Spot VMs instead)
    • can be created and run at a much lower price than normal instances
    • always stop after 24 hours of running
    • can be stopped at any time when Compute Engine needs resources
  • Shielded VM offers verifiable integrity of the Compute Engine VM instances, to confirm the instances haven’t been compromised by boot- or kernel-level malware or rootkits.
  • Confidential VMs keep sensitive code and data encrypted in memory during processing (encryption-in-use)
    • uses hardware-based memory encryption with AMD SEV, AMD SEV-SNP, or Intel TDX
    • supports GPU workloads with A3 machine types (NVIDIA H100) using Intel TDX
    • together with encryption-at-rest and encryption-in-transit, provides encryption at all times
  • Instance template is a resource used to create VM instances and managed instance groups (MIGs) with identical configuration
  • Instance group is a collection of virtual machine (VM) instances that can be managed as a single entity.
    • Managed instance groups (MIGs)
      • allows app creation with multiple identical VMs.
      • workloads can be made scalable and highly available by taking advantage of automated MIG services, including: autoscaling, autohealing, regional (multiple zone) deployment, and automatic updating
      • supports rolling update feature
      • works with load balancing services to distribute traffic across all of the instances in the group.
    • Unmanaged instance groups
      • allows load balance across a fleet of VMs that you manage yourself which may not be identical
  • Instance templates are global, while instance groups are regional.
  • Machine image stores all the configuration, data, metadata and permissions from one or more disks required to create a VM instance
  • Sole-tenancy provides dedicated hosting only for the project’s VM and provides added layer of hardware isolation
  • deletionProtection prevents accidental VM deletion esp. for VMs running critical workloads and need to be protected
  • provides Sustained Discounts, Committed discounts, free tier etc. in pricing

Machine Families (Updated 2025)

  • General-purpose — best price-performance for common workloads
    • C4 — powered by 5th/6th Gen Intel Xeon Scalable processors (Emerald Rapids/Granite Rapids) and Google Titanium
    • C4D — powered by 5th Gen AMD EPYC Turin processors and Titanium; up to 80% higher throughput per vCPU for web-serving workloads; supports confidential computing
    • C4A — powered by Google Axion (Arm-based) processors with Titanium SSD; up to 72 vCPUs
    • N4D — AMD Turin-based; up to 3.5x throughput for web-serving vs. previous-gen N2D
    • E2, N2, N2D, N1 — previous generation general-purpose options
  • Compute-optimized — highest per-core performance (C2, C2D, H3)
  • Memory-optimized — large in-memory workloads (M1, M2, M3, X4)
  • Accelerator-optimized — GPU/ML workloads (A2, A3, G2, G4)
    • A3 — NVIDIA H100 GPUs, ideal for AI/ML training and large model inference
    • G4 — NVIDIA RTX PRO 6000 GPUs for graphics and virtual workstations
  • Storage-optimized — high IOPS local storage (Z3)

Storage Options

  • Persistent Disk — network-attached block storage (Standard, Balanced, SSD, Extreme)
  • Hyperdisk — next-generation block storage with substantially higher IOPS and throughput
    • Hyperdisk Balanced — general workloads with independently configurable IOPS and throughput
    • Hyperdisk Throughput — optimized for sequential reads/writes
    • Hyperdisk Extreme — highest performance for databases
    • Hyperdisk Balanced High Availability — multi-zone replication for critical workloads
    • Supports Confidential mode for hardware-based encryption
  • Local SSD — physically attached high-performance local storage
  • Titanium SSD — Google’s custom SSD integrated with Titanium infrastructure (available on C4A)

App Engine

  • App Engine helps build highly scalable applications on a fully managed serverless platform
  • Each Cloud project can contain only a single App Engine application
  • App Engine is regional, which means the infrastructure that runs the apps is located in a specific region, and Google manages it so that it is available redundantly across all of the zones within that region
  • App Engine application location or region cannot be changed once created
  • App engine allows traffic management to an application version by migrating or splitting traffic.
    • Traffic Splitting (Canary) – distributes a percentage of traffic to versions of the application.
    • Traffic Migration – smoothly switches request routing
  • Supports Standard and Flexible environments
    • Standard environment
      • Application instances that run in a sandbox, using the runtime environment of a supported language only.
      • Sandbox restricts what the application can do
        • only allows the app to use a limited set of binary libraries
        • app cannot write to disk
        • limits the CPU and memory options available to the application
      • Sandbox does not support
        • SSH debugging
        • Background processes
        • Background threads (limited capability)
        • Using Cloud VPN
    • Flexible environment
      • Application instances run within Docker containers on Compute Engine virtual machines (VM).
      • As Flexible environment supports docker it can support custom runtime or source code written in other programming languages.
      • Allows selection of any Compute Engine machine type for instances so that the application has access to more memory and CPU.
  • min_idle_instances indicates the number of additional instances to be kept running and ready to serve traffic for this version.

App Engine Runtime Lifecycle (Updated 2025)

  • Legacy runtimes reached End of Support on January 30, 2024 — Python 2.7, Java 8, PHP 5.5, Go 1.11
  • Legacy runtimes deprecated on January 31, 2026 and will be decommissioned after that
  • Google recommends Cloud Run as the modern alternative for new serverless container workloads
  • Cloud Run offers more flexibility: custom containers, VPC connectivity, GPU support, and finer-grained scaling controls
  • App Engine migration center provides guidance for moving to Cloud Run

Google Kubernetes Engine (GKE)

  • is a managed Kubernetes service for deploying and managing containerized applications
  • provides a fully managed environment for deployment, management, and scaling of containerized apps using Google infrastructure
  • uses Compute Engine instances as nodes in a cluster

GKE Modes of Operation

  • Autopilot mode (default since 2023, recommended)
    • fully managed — GKE manages nodes, node pools, and cluster infrastructure
    • pay-per-pod model — charges based on requested vCPU, memory, and ephemeral storage
    • hardened security configuration enabled by default
    • automatic security patching of nodes
    • built-in best practices for security, reliability, performance, and scalability
    • In 2024, 30% of active GKE clusters used Autopilot mode
    • In 2025, Autopilot became available to all qualifying clusters (automatic migration)
    • supports custom compute classes for workload-specific hardware requirements
  • Standard mode
    • provides full control over node configuration and management
    • user is responsible for managing and configuring individual nodes
    • can run Autopilot-mode workloads within Standard clusters
    • multi-cluster management features (Fleets, Teams, Config Management, Policy Controller) now included at no additional cost (2025)

GKE Key Features

  • Node Pools — group of nodes with identical configuration within a cluster
    • supports autoscaling (automatically adjusts number of nodes)
    • supports auto-provisioning (GKE creates optimal node pools automatically)
    • surge upgrade strategy by default (maxSurge=1, maxUnavailable=0)
  • Cluster Autoscaler — automatically resizes number of nodes based on workload demands
  • Vertical Pod Autoscaler (VPA) — adjusts CPU/memory requests for containers
  • Horizontal Pod Autoscaler (HPA) — adjusts number of pod replicas
  • GKE Sandbox — provides an extra layer of security using gVisor for untrusted workloads
  • Confidential GKE Nodes — uses Confidential VMs for hardware-based memory encryption
  • Workload Identity Federation — recommended way to access Google Cloud services from GKE workloads
  • Binary Authorization — deploy-time security control to ensure only trusted containers are deployed

GKE AI/ML Features (2024-2026)

  • GKE Inference Gateway — optimized routing for AI model inference workloads
  • GKE Inference Quickstart — simplified deployment for AI inference serving
  • Custom Compute Classes — define hardware requirements for AI workloads (GPUs, TPUs)
  • GKE Agent Sandbox — secure execution environment for AI agents
  • Support for clusters up to 130,000 nodes for massive AI computation
  • GKE now powers AI workloads for all top 50 Google Cloud platform customers

GKE Commands

  • gcloud container clusters create — creates a new cluster (Autopilot by default)
  • gcloud container clusters create --mode=standard — creates a Standard mode cluster
  • gcloud container clusters resize --num-nodes — scales the cluster node count (--size is deprecated)
  • gcloud container node-pools create — creates a new node pool

Cloud Run

  • is a fully managed serverless platform for running containerized applications
  • automatically scales containers up and down, including scale to zero
  • supports any container that listens for HTTP requests or processes events
  • no infrastructure to manage — deploy with a single command (gcloud run deploy)
  • Cloud Run services — for serving HTTP requests (web apps, APIs)
  • Cloud Run jobs — for running batch tasks to completion (GA since 2023)
  • Cloud Run worker pools — for long-running background workers (2025)
  • GPU support — serverless GPU acceleration with NVIDIA L4 GPUs (GA 2025)
    • ideal for AI inference, image/video processing, and scientific computation
    • no cluster management required
  • pay-per-use pricing — charged only when container is handling requests or running jobs
  • supports both request-based and instance-based billing models
  • integrates with VPC for private networking and direct VPC egress

Cloud Run Functions (formerly Cloud Functions)

  • Renamed from Cloud Functions to Cloud Run functions in August 2024
  • is a Functions-as-a-Service (FaaS) offering powered by Cloud Run and Eventarc
  • provides a simple event-driven programming model for small code snippets
  • supports 90+ event sources via Eventarc triggers
  • deployed as Cloud Run services under the hood, providing same scalability and networking features
  • 1st gen — original version with limited event triggers (legacy)
  • 2nd gen (Cloud Run functions) — latest version with advanced control, longer timeouts, larger instances, and traffic splitting
  • no server management — write code and deploy, infrastructure is handled automatically
  • supports Node.js, Python, Go, Java, .NET, Ruby, and PHP

Compute Services Comparison

Feature Compute Engine GKE App Engine Cloud Run Cloud Run Functions
Type IaaS CaaS (Containers) PaaS Serverless containers FaaS
Use case Full VM control Container orchestration Web apps Stateless containers Event-driven functions
Scaling MIG autoscaling Pod/node autoscaling Automatic Automatic (to zero) Automatic (to zero)
Management User manages OS, runtime User manages containers Google manages runtime Google manages infra Google manages everything
Pricing Per VM (seconds) Per node or per pod Per instance hour Per request/instance Per invocation
GPU support Yes Yes No Yes (L4) No

Google Cloud Compute Services Cheat Sheet Questions

  1. A company needs to run a containerized application that automatically scales based on traffic and requires zero infrastructure management. Which service should they use?
    1. Compute Engine
    2. GKE Standard
    3. Cloud Run
    4. App Engine Flexible
    Show Answer

    Answer: c. Cloud Run – provides automatic scaling including scale-to-zero with no infrastructure management for containerized apps.

  2. A team wants to run Kubernetes workloads without managing node pools, patching, or capacity planning. Which GKE mode should they choose?
    1. GKE Standard
    2. GKE Autopilot
    3. GKE Enterprise
    4. GKE Sandbox
    Show Answer

    Answer: b. GKE Autopilot – fully managed mode where GKE handles all node management, patching, and capacity planning.

  3. Which Compute Engine VM type is recommended over Preemptible VMs and has no maximum runtime limit?
    1. Shielded VM
    2. Confidential VM
    3. Spot VM
    4. Sole-tenant VM
    Show Answer

    Answer: c. Spot VM – recommended replacement for Preemptible VMs with same pricing but no 24-hour time limit.

  4. What happened to Google Cloud Functions in August 2024?
    1. It was deprecated entirely
    2. It was renamed to Cloud Run functions
    3. It was merged into App Engine
    4. It moved to GKE
    Show Answer

    Answer: b. It was renamed to Cloud Run functions – Cloud Functions (2nd gen) is now Cloud Run functions, deployed as services on Cloud Run.

  5. An organization needs to deploy AI inference models on GKE with optimized routing. Which feature should they use?
    1. GKE Sandbox
    2. GKE Inference Gateway
    3. Cloud Run GPU
    4. Compute Engine A3
    Show Answer

    Answer: b. GKE Inference Gateway – provides optimized routing specifically for AI model inference workloads on GKE.

  6. Which storage option provides substantially higher IOPS and throughput than Persistent Disk with independently configurable performance?
    1. Local SSD
    2. Standard Persistent Disk
    3. Hyperdisk
    4. Filestore
    Show Answer

    Answer: c. Hyperdisk – next-generation block storage with independently configurable IOPS and throughput.

  7. A company wants to run serverless GPU workloads for AI inference without managing clusters. Which service is most appropriate?
    1. Compute Engine with GPU
    2. GKE with A3 nodes
    3. Cloud Run with GPU
    4. App Engine Flexible
    Show Answer

    Answer: c. Cloud Run with GPU – provides serverless GPU acceleration with NVIDIA L4 GPUs, no cluster management required.

  8. Which Compute Engine feature protects data in memory using hardware-based encryption?
    1. Shielded VM
    2. Confidential VM
    3. Sole-tenant node
    4. Live migration
    Show Answer

    Answer: b. Confidential VM – keeps data encrypted in memory during processing using AMD SEV, SEV-SNP, or Intel TDX.

Related Posts