Question

Difficulty: Very hardPlanning Google Kubernetes Engine (GKE) Cluster Architectures

A financial transaction processing company is planning a new Google Kubernetes Engine (GKE) cluster architecture to host two workloads with contrasting technical requirements. The first workload is a stateful transaction logging engine that requires custom host-level Linux kernel parameters (`sysctl`) tuned on the underlying nodes. The second workload is a large-scale, fault-tolerant batch processing job that can tolerate sudden instance terminations. The DevOps team wants to minimize node compute costs for the batch processing job while ensuring the transaction logging engine runs on nodes with the required kernel modifications. Which cluster architecture design should you recommend?

  1. Provision a GKE Standard cluster containing a dedicated node pool configured with custom sysctl settings for the transaction logging workload, and a separate node pool using Spot VMs for the batch processing workload.Answer
  2. B
    Provision a GKE Autopilot cluster, deploying the transaction logging workload with a privileged DaemonSet to set host kernel parameters, and deploying the batch processing workload as Spot Pods.
  3. C
    Provision a GKE Autopilot cluster utilizing Spot Pods for both the stateful transaction logging workload and the batch processing workload to minimize compute cost and node management overhead.
  4. D
    Provision a GKE Standard cluster with a single node pool comprised of Spot VMs, applying custom sysctl parameters across all nodes to support both workloads within one pool.

Answer

Provision a GKE Standard cluster containing a dedicated node pool configured with custom sysctl settings for the transaction logging workload, and a separate node pool using Spot VMs for the batch processing workload.
The correct recommendation is to use a GKE Standard cluster configured with multiple node pools. GKE Standard provides full access to node configurations, allowing sysctl kernel parameter customization for the stateful transaction logging workload. Adding a secondary node pool using Spot VMs allows the fault-tolerant batch processing workload to run at significantly reduced costs without risking the stability of the transaction logger.

Step-by-Step Solution

1
Analyze host OS kernel modification requirements
GKE Standard is required because GKE Autopilot locks down host node operating system configurations and prevents custom node kernel (sysctl) parameter tuning.
Autopilot manages node provisioning and security baseline automatically, restricting low-level host kernel customization.
2
Evaluate fault tolerance and cost requirements for batch processing
Batch processing is fault-tolerant and stateless, making it ideal for Spot VMs to significantly reduce compute costs.
Spot VMs provide deep discounts in exchange for being preemptible, which suits batch jobs that can resume or restart easily.
3
Evaluate availability requirements for the stateful transaction logging engine
The stateful logging engine requires standard (on-demand) node pools to prevent sudden node preemptions.
Stateful workloads can suffer data loss or service disruption if placed on preemptible Spot VM instances.
4
Combine workload requirements into an optimal cluster architecture
A single GKE Standard cluster with multiple heterogeneous node pools (one custom sysctl pool and one Spot VM pool) meets all requirements.
Separate node pools isolate host configurations and pricing models while allowing single-cluster administrative management.

Key Concept

GKE Cluster Planning: Autopilot vs Standard Operational Boundaries & Heterogeneous Node Pool Architecture
Rate this question