An enterprise platform team is provisioning Google Kubernetes Engine (GKE) infrastructure for two application components. Component 1 is a daemon daemonset that requires privileged kernel capabilities (`CAP_SYS_ADMIN`) and custom hostPath volume mounts to load proprietary kernel modules on the underlying node. Component 2 is a stateless, fault-tolerant data ingestion pipeline designed to handle sudden instance terminations gracefully. Which cluster architecture and node pool strategy correctly supports both components while optimizing cost and operational overhead?
- Deploy Component 1 on a GKE Standard node pool allowing custom node configurations, and deploy Component 2 on a GKE Standard Spot node pool.Answer
- BDeploy both Component 1 and Component 2 to a GKE Autopilot cluster, configuring Spot Pods for Component 2.
- CDeploy Component 1 to a GKE Standard Spot node pool, and deploy Component 2 to a GKE Standard node pool configured with persistent SSD storage.
- DDeploy both components to a single GKE Standard node pool and enable the Horizontal Pod Autoscaler (HPA) to automatically provision new Compute Engine VM nodes when cluster CPU utilization spikes.
Answer
Deploy the privileged kernel workload (Component 1) on a GKE Standard node pool and the fault-tolerant pipeline (Component 2) on a GKE Standard Spot node pool.
GKE Standard node pools allow node-level customizations, privileged security capabilities (`CAP_SYS_ADMIN`), and raw hostPath mounts required by kernel monitoring software. Concurrently, utilizing GKE Standard Spot node pools for stateless, fault-tolerant batch workloads provides significant cost savings without risking application state loss during node preemption.
Step-by-Step Solution
Key Concept
GKE Autopilot vs. Standard Operational Boundaries and Spot Node Pool Selection
Estimated Time:2m 30s