Question

Difficulty: HardDeploying and Managing Google Kubernetes Engine (GKE) Clusters and Workloads

A financial analytics company is preparing to launch a low-latency transaction processing workload on Google Kubernetes Engine (GKE). The application requires custom Linux kernel sysctl parameters (such as modifying `net.core.somaxconn`) on the underlying node OS to support high network throughput, and it requires guaranteed host stability without node preemptions. Additionally, an engineer on a new management workstation must configure local `kubectl` access to interact with the cluster and deploy the workload manifest. Which combination of cluster mode configuration and operational commands correctly satisfies these requirements according to Google Cloud recommended practices?

  1. Deploy a GKE Standard cluster with a dedicated standard (non-Spot) node pool configured with custom sysctls, execute `gcloud container clusters get-credentials` to update the local kubeconfig context, and deploy the workload using `kubectl apply`.Answer
  2. B
    Deploy a GKE Autopilot cluster to eliminate node pool administration overhead, execute `gcloud container clusters get-credentials` to authenticate `kubectl`, and deploy the workload using `kubectl apply`.
  3. C
    Deploy a GKE Standard cluster with a Spot node pool to handle high-throughput workloads, run `gcloud container clusters get-credentials` to establish the `kubectl` context, and deploy the workload using `kubectl apply`.
  4. D
    Deploy a GKE Standard cluster with a dedicated standard node pool configured with custom sysctls, run `gcloud config set container/cluster` to configure the local command environment, and deploy the workload using `kubectl apply`.

Answer

The application must be deployed on a GKE Standard cluster utilizing a dedicated standard node pool configured with custom sysctls, followed by executing `gcloud container clusters get-credentials` to configure `kubectl` access.
Deploying a GKE Standard cluster with a standard node pool allows explicit configuration of node OS sysctl parameters while guaranteeing non-preemptible execution. Executing `gcloud container clusters get-credentials` generates the necessary authentication context in the local kubeconfig file, enabling `kubectl` to successfully deploy workloads to the cluster.

Step-by-Step Solution

1
Evaluate cluster mode requirements based on node OS customization and workload characteristics.
GKE Autopilot locks down node OS modifications, so custom sysctl kernel parameter tuning requires GKE Standard mode.
GKE Autopilot enforces strict node management boundaries that prevent custom sysctls or custom node OS configurations.
2
Evaluate node pool type based on workload interruption tolerance.
A standard persistent node pool must be selected instead of a Spot node pool.
Spot instances can be reclaimed dynamically by Google Cloud at any time, violating the guaranteed non-preemptible requirement for latency-critical processing.
3
Determine the correct CLI command to establish local `kubectl` authentication credentials.
Execute `gcloud container clusters get-credentials [CLUSTER_NAME] --zone [ZONE] --project [PROJECT_ID]`.
This command fetches the API endpoint, cluster CA certificate, and OAuth tokens, writing them into `~/.kube/config` so `kubectl` can communicate with the GKE control plane.

Key Concept

GKE Cluster Modes and Kubeconfig Management
Estimated Time:2m 0s
Rate this question