Node pools and auto scaling in GCP - Practice Problems & Coding Challenges

Challenge - 5 Problems

❓ Architecture

intermediate

How does a node pool affect cluster scaling in GKE?

You have a Google Kubernetes Engine (GKE) cluster with two node pools: one for general workloads and one for high-memory workloads. You want to enable auto scaling to adjust the number of nodes based on demand.

Which statement best describes how node pools influence auto scaling behavior?

A Each node pool scales independently based on the resource requests of pods scheduled to it.

B Auto scaling adjusts the total number of nodes in the cluster without considering node pools.

C Only the default node pool can be auto scaled; additional node pools remain fixed size.

D Node pools must have the same machine type to enable auto scaling across the cluster.

💡 Hint

Think about how pods are assigned to node pools and how scaling reacts to workload demands.

In GKE, each node pool can be configured with its own auto scaling settings. The cluster autoscaler adjusts the size of each node pool independently based on the resource requests of pods scheduled to that pool.

❓ Configuration

intermediate

Identify the correct YAML snippet to enable auto scaling on a GKE node pool

You want to enable auto scaling on a GKE node pool named high-mem-pool with a minimum of 2 nodes and a maximum of 5 nodes.

Which YAML snippet correctly configures this?

A

nodePools:
- name: high-mem-pool
  autoscaling:
    enabled: true
    minCount: 2
    maxCount: 5

B

nodePools:
- name: high-mem-pool
  autoscaling:
    enabled: true
    minNodeCount: 2
    maxNodeCount: 5

C

nodePools:
- name: high-mem-pool
  autoscaling:
    enabled: false
    minNodeCount: 2
    maxNodeCount: 5

D

nodePools:
- name: high-mem-pool
  autoscaling:
    minNodeCount: 2
    maxNodeCount: 5

💡 Hint

Check the exact field names required to enable autoscaling in GKE node pool configuration.

The autoscaling block must include enabled: true along with minNodeCount and maxNodeCount to properly enable autoscaling on a node pool.

❓ service_behavior

advanced

What happens when a pod requests more resources than any node in the node pool can provide?

You have a GKE cluster with a node pool of machines each having 4 CPU cores and 16 GB RAM. A pod requests 8 CPU cores and 32 GB RAM.

What will be the behavior of the cluster autoscaler and scheduler?

A The pod will be split across multiple nodes to satisfy resource requests.

B Autoscaler will add more nodes until the pod fits; scheduler places the pod once enough nodes exist.

C The scheduler will not place the pod; autoscaler will not add nodes because no node can satisfy the request.

D The scheduler will place the pod on the node with the most free resources, ignoring resource limits.

💡 Hint

Consider how Kubernetes schedules pods and how autoscaler reacts to unschedulable pods.

Kubernetes scheduler cannot place a pod if no single node has enough resources. The autoscaler only adds nodes if a pod can fit on a new node type. Since the pod requests more than any node can provide, it remains unschedulable and autoscaler does not add nodes.

❓ security

advanced

Which node pool configuration improves security by isolating sensitive workloads?

You want to run sensitive workloads in a GKE cluster with enhanced security. Which node pool configuration best isolates these workloads?

A Create a dedicated node pool with nodes having Shielded VM enabled and use node taints to isolate pods.

B Use the default node pool and label sensitive pods with a security label only.

C Run all workloads on the same node pool but use network policies to isolate traffic.

D Create a node pool with larger machines and run sensitive and non-sensitive pods together.

💡 Hint

Think about physical and logical isolation methods in Kubernetes node pools.

Creating a dedicated node pool with Shielded VMs and using taints ensures sensitive workloads run on isolated, secure nodes. Labels alone or network policies do not isolate nodes physically.

🧠 Conceptual

expert

Why might enabling cluster autoscaler on multiple node pools cause unexpected scaling behavior?

You enabled autoscaling on three node pools in a GKE cluster. You notice that sometimes one node pool scales up aggressively while others remain at minimum size, even though workloads are balanced.

What is the most likely cause?

A The cluster autoscaler requires all node pools to have identical resource limits to scale evenly.

B The autoscaler prioritizes scaling node pools with cheaper machine types first, causing uneven scaling.

C Autoscaler cannot scale multiple node pools simultaneously and picks one at random to scale.

D Pods have node selectors or affinity rules that restrict them to specific node pools, causing autoscaler to scale only those pools.

💡 Hint

Consider how pod scheduling constraints affect node pool scaling.

If pods have node selectors or affinity rules, they can only be scheduled on certain node pools. The autoscaler scales only the node pools that can host the pods, leading to uneven scaling.

Practice

1. What is the main purpose of a node pool in a GKE cluster?

easy

A. To group similar machines for easier management and scaling

B. To store data permanently in the cluster

C. To monitor network traffic between nodes

D. To create backups of the cluster configuration

Solution

1. Step 1: Understand node pool concept

   A node pool is a set of nodes with the same configuration in a cluster.

2. Step 2: Identify node pool purpose

   Node pools help manage and scale groups of similar machines easily.

3. Final Answer:

   To group similar machines for easier management and scaling -> Option A

4. Quick Check:

   Node pool = group similar machines [OK]

Hint: Node pools group similar nodes for scaling and management [OK]

Common Mistakes:

• Confusing node pools with storage or backup features
• Thinking node pools monitor network traffic
• Assuming node pools store data permanently

2. Which of the following is the correct way to enable auto scaling on a node pool using gcloud CLI?

easy

A. gcloud container clusters create CLUSTER_NAME --autoscaling

B. gcloud container node-pools update POOL_NAME --enable-autoscaling --min-nodes=1 --max-nodes=5

C. gcloud container node-pools create POOL_NAME --autoscaling-enabled

D. gcloud container node-pools set-autoscale POOL_NAME --min=1 --max=5

Solution

1. Step 1: Recall gcloud syntax for node pool auto scaling

   The correct command uses 'node-pools update' with '--enable-autoscaling' and min/max nodes.

2. Step 2: Match options with correct syntax

   gcloud container node-pools update POOL_NAME --enable-autoscaling --min-nodes=1 --max-nodes=5 matches the correct syntax and flags for enabling auto scaling.

3. Final Answer:

   gcloud container node-pools update POOL_NAME --enable-autoscaling --min-nodes=1 --max-nodes=5 -> Option B

4. Quick Check:

   Enable autoscaling with update and min/max nodes [OK]

Hint: Use 'node-pools update' with --enable-autoscaling and min/max nodes [OK]

Common Mistakes:

• Using cluster create command to enable node pool autoscaling
• Incorrect flag names like --autoscaling-enabled
• Commands that do not specify min and max nodes

3. Given a node pool with auto scaling enabled (min nodes=2, max nodes=4), what happens when workload increases beyond current capacity?

medium

A. The node pool scales up by adding nodes up to the max limit

B. The node pool scales down to reduce costs

C. The cluster deletes existing nodes to balance load

D. The workload is rejected until manual scaling is done

Solution

1. Step 1: Understand auto scaling behavior on workload increase

   Auto scaling adds nodes when workload exceeds current capacity, up to max nodes.

2. Step 2: Analyze options

   The node pool scales up by adding nodes up to the max limit correctly describes scaling up; others describe incorrect or opposite behaviors.

3. Final Answer:

   The node pool scales up by adding nodes up to the max limit -> Option A

4. Quick Check:

   Workload increase triggers scale up [OK]

Hint: Auto scaling adds nodes when workload grows, up to max nodes [OK]

Common Mistakes:

• Thinking auto scaling scales down on workload increase
• Assuming nodes are deleted to balance load
• Believing workload is rejected without manual scaling

4. You configured auto scaling on a node pool but notice nodes are not scaling up despite high CPU usage. What is the most likely cause?

medium

A. Auto scaling is disabled on the node pool

B. The node pool has no nodes initially

C. The cluster is in maintenance mode

D. The max nodes limit is set too low

Solution

1. Step 1: Check auto scaling settings

   If auto scaling is enabled but nodes don't increase, max nodes limit may be reached.

2. Step 2: Identify cause of no scale up

   The max nodes limit is set too low explains that max nodes limit is too low to add more nodes despite workload.

3. Final Answer:

   The max nodes limit is set too low -> Option D

4. Quick Check:

   Max nodes limit blocks scaling up [OK]

Hint: Check max nodes limit if scaling doesn't happen [OK]

Common Mistakes:

• Assuming auto scaling is disabled without checking limits
• Ignoring max nodes limit as a cause
• Thinking cluster maintenance mode blocks scaling always

5. You want to optimize costs by using multiple node pools with different machine types and enable auto scaling only on the pool handling variable workloads. Which approach is best?

hard

A. Disable auto scaling on all node pools and manually adjust nodes daily

B. Use a single node pool with auto scaling enabled for all workloads

C. Create a small fixed node pool for stable workloads and a separate auto scaling node pool for variable workloads

D. Create multiple auto scaling node pools with the same machine type

Solution

1. Step 1: Understand workload types and node pools

   Stable workloads benefit from fixed nodes; variable workloads benefit from auto scaling.

2. Step 2: Choose best cost optimization strategy

   Create a small fixed node pool for stable workloads and a separate auto scaling node pool for variable workloads separates stable and variable workloads into different pools with appropriate scaling.

3. Final Answer:

   Create a small fixed node pool for stable workloads and a separate auto scaling node pool for variable workloads -> Option C

4. Quick Check:

   Separate pools for stable and variable workloads optimize cost [OK]

Hint: Use fixed pool for stable, auto scaling pool for variable workloads [OK]

Common Mistakes:

• Using single auto scaling pool for all workloads
• Disabling auto scaling and relying on manual scaling
• Creating multiple auto scaling pools with same machine type unnecessarily