Node pools and scaling in Azure - Practice Problems & Coding Challenges

Challenge - 5 Problems

🧠 Conceptual

intermediate

Understanding Node Pool Scaling Behavior

You have an Azure Kubernetes Service (AKS) cluster with two node pools: system and user. The system node pool is set to a fixed size of 3 nodes, and the user node pool has autoscaling enabled with a minimum of 1 and maximum of 5 nodes.

What happens when the workload on the user node pool increases beyond the capacity of 5 nodes?

A The <em>system</em> node pool automatically scales up to help with the <em>user</em> node pool workload.

B The <em>user</em> node pool scales beyond 5 nodes to handle the workload automatically.

C The cluster rejects new pods scheduled to the <em>user</em> node pool once it reaches 5 nodes, causing pending pods.

D AKS automatically creates a new node pool to handle the extra workload beyond 5 nodes.

💡 Hint

Think about the maximum node count set for autoscaling and how AKS manages node pools independently.

Autoscaling respects the maximum node count set for each node pool. Once the user node pool reaches 5 nodes, it cannot scale further. New pods that require more capacity remain pending until resources free up or manual scaling occurs.

❓ Configuration

intermediate

Configuring Node Pool Autoscaling Limits

You want to configure an AKS node pool named compute to autoscale between 2 and 6 nodes. Which Azure CLI command correctly sets this autoscaling configuration?

A az aks nodepool create --resource-group myRG --cluster-name myAKS --name compute --enable-autoscale --min-nodes 2 --max-nodes 6

B az aks nodepool scale --resource-group myRG --cluster-name myAKS --name compute --min-count 2 --max-count 6

C az aks update --resource-group myRG --name myAKS --nodepool-name compute --autoscale true --min 2 --max 6

D az aks nodepool update --resource-group myRG --cluster-name myAKS --name compute --enable-cluster-autoscaler --min-count 2 --max-count 6

💡 Hint

Remember that autoscaling is enabled or updated on existing node pools with specific flags.

The az aks nodepool update command with --enable-cluster-autoscaler, --min-count, and --max-count correctly configures autoscaling limits on an existing node pool.

❓ Architecture

advanced

Designing Node Pools for Mixed Workloads

You need to design an AKS cluster to run two types of workloads: latency-sensitive services and batch jobs. Latency-sensitive services require dedicated nodes with high availability, while batch jobs can run on cheaper, spot-priced nodes that can be preempted.

Which node pool architecture best fits this requirement?

A Create two node pools: one with standard VMs for latency-sensitive services and one with spot VMs for batch jobs, each with appropriate scaling policies.

B Use only spot VM node pools and rely on pod priority to manage latency-sensitive services.

C Create a single node pool with mixed VM sizes and enable autoscaling to handle both workloads.

D Create multiple node pools with spot VMs only and use taints to separate workloads.

💡 Hint

Consider workload isolation and cost optimization strategies.

Separating workloads into dedicated node pools allows tuning VM types and scaling policies per workload. Spot VMs are suitable for batch jobs but not for latency-sensitive services that require stability.

❓ security

advanced

Securing Node Pools with Azure AD Integration

You want to restrict access to the system node pool in your AKS cluster so that only cluster administrators can deploy pods there. Which approach enforces this security requirement?

A Use Azure AD RBAC to assign <code>Azure Kubernetes Service RBAC Cluster Admin</code> role only to administrators and use node pool labels with Kubernetes RBAC to restrict pod deployment.

B Enable network policies on the <code>system</code> node pool to block all traffic except from admin IPs.

C Use Azure Policy to deny pod creation on the <code>system</code> node pool for non-admin users.

D Configure pod security policies to allow only admin users to schedule pods on the <code>system</code> node pool.

💡 Hint

Think about combining Azure AD roles with Kubernetes RBAC and node labels.

Azure AD RBAC controls who can perform cluster admin actions. Kubernetes RBAC combined with node labels can restrict pod scheduling to specific node pools. This combination enforces deployment restrictions effectively.

❓ service_behavior

expert

Behavior of Node Pool Scaling with Multiple Workloads

An AKS cluster has two node pools: np1 and np2. Both have autoscaling enabled with min 1 and max 3 nodes. The cluster runs two deployments: app1 scheduled only on np1 and app2 scheduled only on np2.

If app1 suddenly requires 10 pods and app2 requires 2 pods, what is the expected scaling behavior?

A <code>np2</code> scales up to 3 nodes to help <code>np1</code> handle the extra pods from <code>app1</code>.

B <code>np1</code> scales up to 3 nodes but cannot satisfy all 10 pods, causing some pods to remain pending; <code>np2</code> scales to 2 nodes to handle <code>app2</code> pods.

C Both <code>np1</code> and <code>np2</code> scale to 3 nodes each to balance the load between deployments.

D <code>np1</code> scales beyond 3 nodes to handle all 10 pods; <code>np2</code> remains at 1 node since <code>app2</code> pods fit there.

💡 Hint

Remember that node pools scale independently and pods are scheduled only on their assigned node pools.

Each node pool autoscaler respects its max node count. np1 can only scale to 3 nodes, so it cannot run all 10 pods, leaving some pending. np2 scales to 2 nodes to run its 2 pods. Node pools do not share capacity.

Practice

1. What is the main purpose of a node pool in an Azure Kubernetes Service (AKS) cluster?

easy

A. To manage user access and permissions

B. To group nodes with similar configurations for easier management

C. To store application data persistently

D. To monitor network traffic between pods

Solution

1. Step 1: Understand node pool concept

   A node pool is a set of machines (nodes) in a cluster that share the same configuration, such as VM size and OS.

2. Step 2: Identify the main purpose

   Grouping nodes with similar settings helps manage and scale them easily within the cluster.

3. Final Answer:

   To group nodes with similar configurations for easier management -> Option B

4. Quick Check:

   Node pool = group of similar nodes [OK]

Hint: Node pools group similar machines in a cluster [OK]

Common Mistakes:

• Confusing node pools with storage or permissions
• Thinking node pools monitor network traffic
• Assuming node pools store data

2. Which of the following is the correct Azure CLI command to scale a node pool named pool1 in an AKS cluster called myCluster to 5 nodes?

easy

A. az aks nodepool scale --resource-group myResourceGroup --cluster-name myCluster --name pool1 --node-count 5

B. az aks scale nodepool --cluster myCluster --name pool1 --count 5

C. az nodepool scale --cluster myCluster --name pool1 --nodes 5

D. az aks nodepool update --resource-group myResourceGroup --cluster myCluster --name pool1 --count 5

Solution

1. Step 1: Recall correct Azure CLI syntax for scaling node pools

   The correct command uses az aks nodepool scale with parameters for resource group, cluster name, node pool name, and node count.

2. Step 2: Match command with options

   az aks nodepool scale --resource-group myResourceGroup --cluster-name myCluster --name pool1 --node-count 5 matches the correct syntax exactly, including all required flags and parameters.

3. Final Answer:

   az aks nodepool scale --resource-group myResourceGroup --cluster-name myCluster --name pool1 --node-count 5 -> Option A

4. Quick Check:

   Correct CLI command = az aks nodepool scale --resource-group myResourceGroup --cluster-name myCluster --name pool1 --node-count 5 [OK]

Hint: Use 'az aks nodepool scale' with correct flags [OK]

Common Mistakes:

• Using wrong command verbs like 'update' or 'scale nodepool'
• Missing resource group or cluster name flags
• Incorrect flag names like --count instead of --node-count

3. Given this YAML snippet for an AKS node pool auto-scaling configuration:

nodePools:
  - name: pool1
    count: 3
    enableAutoScaling: true
    minCount: 2
    maxCount: 6

What is the maximum number of nodes this node pool can scale up to automatically?

medium

A. 6

B. 2

C. 3

D. Unlimited

Solution

1. Step 1: Identify auto-scaling parameters

   The YAML shows enableAutoScaling: true with minCount: 2 and maxCount: 6.

2. Step 2: Understand maxCount meaning

   The maxCount sets the upper limit for automatic scaling, so the node pool can scale up to 6 nodes.

3. Final Answer:

   6 -> Option A

4. Quick Check:

   Max nodes = maxCount = 6 [OK]

Hint: Max nodes = maxCount value in config [OK]

Common Mistakes:

• Confusing current count with maxCount
• Assuming unlimited scaling without maxCount
• Mixing minCount and maxCount values

4. You tried to scale a node pool using this command:
az aks nodepool scale --resource-group myRG --cluster-name myCluster --name poolA --node-count 0
But it failed. What is the most likely reason?

medium

A. Node pool name is case sensitive and must be uppercase

B. Missing --max-count parameter for scaling

C. Node count cannot be set to zero; minimum is 1

D. Cluster name is incorrect

Solution

1. Step 1: Understand node count limits

   AKS node pools require at least one node; zero nodes is invalid and causes failure.

2. Step 2: Check command parameters

   The command tries to scale to zero nodes, which is not allowed, causing the error.

3. Final Answer:

   Node count cannot be set to zero; minimum is 1 -> Option C

4. Quick Check:

   Minimum nodes = 1, zero not allowed [OK]

Hint: Node pools must have at least one node [OK]

Common Mistakes:

• Trying to scale node pool to zero nodes
• Assuming max-count is required for scaling
• Confusing case sensitivity of node pool names

5. You have an AKS cluster with two node pools: pool1 (3 nodes) and pool2 (5 nodes). You want to enable auto-scaling on pool2 to scale between 3 and 10 nodes based on workload. Which of the following steps correctly applies this configuration?

hard

A. Run az aks nodepool update --resource-group RG --cluster-name Cluster --name pool2 --enable-cluster-autoscaler --min-count 3 --max-count 10

B. Run az aks scale nodepool --resource-group RG --cluster Cluster --name pool2 --enable-auto-scaling --min 3 --max 10

C. Run az aks nodepool scale --resource-group RG --cluster-name Cluster --name pool2 --node-count 10

D. Run az aks nodepool update --resource-group RG --cluster-name Cluster --name pool2 --enable-auto-scaling --min-count 3 --max-count 10

Solution

1. Step 1: Identify correct command to enable auto-scaling

   The correct command is az aks nodepool update with flags --enable-auto-scaling, --min-count, and --max-count.

2. Step 2: Compare options for correct flag names and syntax

   Run az aks nodepool update --resource-group RG --cluster-name Cluster --name pool2 --enable-auto-scaling --min-count 3 --max-count 10 uses the correct flag --enable-auto-scaling (not cluster-autoscaler), and proper min/max count flags.

3. Final Answer:

   Run az aks nodepool update --resource-group RG --cluster-name Cluster --name pool2 --enable-auto-scaling --min-count 3 --max-count 10 -> Option D

4. Quick Check:

   Enable auto-scaling with correct flags = Run az aks nodepool update --resource-group RG --cluster-name Cluster --name pool2 --enable-auto-scaling --min-count 3 --max-count 10 [OK]

Hint: Use 'az aks nodepool update' with --enable-auto-scaling flag [OK]

Common Mistakes:

• Using wrong flag --enable-cluster-autoscaler
• Using scale command instead of update for auto-scaling
• Incorrect flag names like --min or --max instead of --min-count and --max-count