Examkin

Question

Difficulty: HardPlanning Google Kubernetes Engine (GKE) Cluster Architectures

A logistics enterprise is designing a Google Kubernetes Engine (GKE) cluster architecture to host a real-time tracking system containing two workloads:
1. A stateless API service that ingests location updates continuously.
2. A batch analytics engine that processes bulk telemetry data, can easily recover from unexpected instance terminations, and requires specialized Linux kernel parameters (`sysctl` network tuning) configured at the node OS level.

Which cluster configuration strategy satisfies all technical and operational requirements while optimizing node management and compute costs?

  1. Deploy a single GKE Standard cluster with a standard node pool of regular Compute Engine instances for the stateless API service, and a separate node pool using Spot VMs with custom node configuration scripts to apply the required sysctl parameters for the batch analytics engine.Answer
  2. B
    Deploy a single GKE Autopilot cluster and configure a DaemonSet across the cluster to apply custom sysctl node parameters, setting the batch analytics pods to run on Spot Pods.
  3. C
    Deploy a single GKE Standard cluster with a single Spot VM node pool hosting both workloads, applying the custom sysctl parameters across all nodes in the cluster.
  4. D
    Deploy a single GKE Standard cluster with an Autopilot node pool for the stateless API service and a Standard node pool with Spot VMs for the batch analytics engine.

Answer

Deploy a single GKE Standard cluster with a standard node pool of regular Compute Engine instances for the stateless API service, and a separate node pool using Spot VMs with custom node configuration scripts to apply the required sysctl parameters for the batch analytics engine.
GKE Standard is required when workloads demand low-level node OS customizations, such as custom sysctl parameters. Creating separate node pools within a single GKE Standard cluster allows the stateless API service to run reliably on regular instances while leveraging Spot VMs for the fault-tolerant batch analytics workload to optimize costs.

Step-by-Step Solution

1
Evaluate operational boundaries between GKE Autopilot and GKE Standard
GKE Autopilot locks down node OS level access and prevents custom sysctl kernel parameter modifications. Therefore, GKE Standard must be selected.
The batch analytics engine requires custom Linux kernel sysctl parameters applied at the node level.
2
Determine node pool strategies for compute cost vs. availability
Use regular instances for the API ingestion service and Spot VMs for the fault-tolerant batch workload.
Spot VMs provide significant cost savings for workloads that tolerate unexpected node preemptions, whereas the stateless API ingestion service requires stable, non-preemptible nodes.
3
Verify cluster node pool compatibility in GKE
A single GKE Standard cluster supports multiple heterogenous node pools (standard VM node pool + Spot VM node pool with custom configurations).
Combining node pool types within one Standard cluster avoids multi-cluster management overhead while supporting distinct node requirements.

Key Concept

Selecting between GKE Standard and Autopilot based on node OS modification constraints and leveraging specialized node pools for cost optimization
Rate this question

Topics

Planning Google Kubernetes Engine (GKE) Cluster Architectures

More questions from this topic