Context
An AKS node pool upgrade needs somewhere for workloads to run while nodes are replaced. Surge settings create temporary node capacity, while pod disruption budgets control permitted voluntary eviction. Either boundary can stop progress. Raising one limit does not automatically satisfy the other.
Prerequisites are the node pool's current and target versions, networking mode, scale limits and workload availability requirements. Obtain read access to node pool settings, subnet configuration, pods and disruption budgets. Plan a pilot pool or representative test cluster before upgrading critical production capacity.
1. Calculate temporary resource demand
Read the effective surge and unavailable settings rather than using a percentage remembered from another cluster. Translate percentages into nodes at the pool's actual size. Include VM-family quota and potential zonal allocation constraints; spare subnet addresses do not reserve compute capacity.
Calculate IP demand using the deployed networking mode. Traditional Azure CNI, separate pod subnets and overlay networking allocate addresses differently. Include temporary nodes, pods, system workloads and concurrent pool operations. Do not apply one address formula indiscriminately to every AKS cluster.
2. Check whether workloads can drain
Inspect disruption budgets for workloads on the pool. Compare minimum availability with replica counts and current readiness. A budget requiring every replica to remain available can prevent voluntary eviction. A single-replica stateful application also needs an explicit availability decision rather than a copied generic budget.
Use read-only inspection such as kubectl get pdb -n example-app and review the selected workloads. Check topology constraints, storage attachment, node selectors and resource requests that determine whether replacements can schedule. An allowed eviction is insufficient if the replacement pod cannot become ready elsewhere.
3. Select settings with a recovery plan
Choose surge and drain behavior that the application, quota and network can support together. Lower surge can reduce temporary capacity demand while extending upgrade duration. Relaxing a disruption budget permits more eviction but can reduce serving capacity. Review those tradeoffs with the workload owner.
Run a pilot using representative scheduling and storage conditions. Observe new node provisioning, eviction, pod scheduling and readiness as separate stages. Stop or roll back according to prewritten criteria if serving capacity falls below the accepted requirement. Avoid deleting disruption budgets simply to force the operation through.
Diagnostic checkpoints
| Observation | Likely boundary | Next evidence |
|---|---|---|
| Surge node cannot provision | Quota, capacity or addresses | Detailed allocation error |
| Node exists, drain waits | Disruption or termination | PDB and pod events |
| Pod evicted, replacement pending | Scheduling constraint | Requests, topology and volumes |
| Replacement running, not ready | Application startup | Readiness and dependencies |
Illustrative scenario
A hypothetical pool has address headroom for its normal size but not its configured surge. Meanwhile, a critical worker budget permits no disruption. Increasing the subnet alone would leave the drain blocker unresolved. The upgrade plan reviews both temporary infrastructure and application availability. This is a fictional planning case without a claimed upgrade result.
Verification and upgrade SOP
Acceptance requires the target node version, healthy replacement pods and representative business transactions throughout the allowed disruption envelope. Check that temporary resources are reconciled and capacity returns to the intended baseline afterward.
Maintain networking-mode assumptions, surge calculations, PDB owners and stop criteria in the SOP. Monitor stalled provisioning and drain time separately. Recalculate after increasing pool size, changing maxPods or introducing stricter topology rules, because each can invalidate the previous pilot's capacity and scheduling assumptions.
Explore Clouvenix containers kubernetes for implementation and operational handover.