An enterprise SaaS organization is architecting a Google Kubernetes Engine (GKE) environment to host two distinct workloads with strict operational requirements:
1. A high-throughput custom API gateway service that requires modifying specific OS kernel sysctl parameters (`net.core.somaxconn`) on the underlying cluster nodes.
2. A fault-tolerant, stateless asynchronous batch analytics engine designed to process non-critical queued jobs at minimal cost.
You need to plan a cluster architecture that meets these workload demands while minimizing operational expenditure. Which TWO architectural decisions should you execute?
- Deploy a GKE Standard cluster with a custom node pool where kernel sysctl settings can be customized for the API gateway workload.Answer
- Provision a dedicated node pool utilizing Spot VMs configured with taints and tolerations for the asynchronous batch analytics workload.Answer
- CDeploy a GKE Autopilot cluster for the API gateway workload to eliminate node management while applying custom OS sysctl kernel configurations.
- DProvision a Spot VM node pool to host the primary stateful database instances supporting the SaaS platform.
- EConfigure the Horizontal Pod Autoscaler (HPA) to scale out the number of Compute Engine worker nodes when batch processing queues grow.
Answer
Select GKE Standard for custom OS kernel sysctl modifications on the node pool, and utilize Spot VMs with taints and tolerations for stateless batch processing workloads.
Choosing GKE Standard enables necessary low-level node kernel modifications (sysctl settings) required by high-throughput network components. Additionally, implementing Spot VMs with proper taints and tolerations enables significant cost reductions for fault-tolerant, stateless batch workloads without exposing critical services to preemption risks.
Step-by-Step Solution
Key Concept
GKE Standard vs Autopilot node management boundaries and Spot VM workload suitability
Estimated Time:2m 0s