Aks Cost Optimization

Bin-Packing Evidence

Collect bounded evidence for one candidate pool at a time. Include all nodes and scheduled pods across namespaces; add only pools losing nodes or receiving workloads.

Cluster and Workloads

Use Azure MCP AKS for cluster/pool, autoscaling/NAP, node resource group, CRG, and surge data; otherwise use an approved az aks show. With approved shell access and target-bound kubectl, run:

kubectl get nodes -l "kubernetes.azure.com/agentpool=<POOL>" \
  -o custom-columns="NAME:.metadata.name,NAP_POOL:.metadata.labels.karpenter\.sh/nodepool,SKU:.metadata.labels.node\.kubernetes\.io/instance-type,ZONE:.metadata.labels.topology\.kubernetes\.io/zone,CPU:.status.allocatable.cpu,MEM:.status.allocatable.memory,PODS:.status.allocatable.pods,TAINTS:.spec.taints"

kubectl get pods -A --field-selector "spec.nodeName=<NODE_NAME>" \
  -o custom-columns="NAMESPACE:.metadata.namespace,NAME:.metadata.name,NODE:.spec.nodeName,OWNER_KIND:.metadata.ownerReferences[0].kind,OWNER_NAME:.metadata.ownerReferences[0].name,REQUESTS:.spec.containers[*].resources.requests,INIT_REQUESTS:.spec.initContainers[*].resources.requests,OVERHEAD:.spec.overhead,SELECTOR:.spec.nodeSelector,AFFINITY:.spec.affinity,TOLERATIONS:.spec.tolerations,SPREAD:.spec.topologySpreadConstraints,PVCS:.spec.volumes[*].persistentVolumeClaim.claimName"

Aggregate all nodes before modeling. For discovered namespaces, project PDBs; collect FailedScheduling only for known pending pods eligible for affected pools. Resolve referenced owners, following ReplicaSets to Deployments. Retrieve other details only for identified constraints. Never retrieve full nodes; they include cached images. Report covered pools, nodes, namespaces, owners, and omissions.

Reuse rightsizing metrics or retrieve 7-14 days of CPU/memory history. Current usage alone cannot justify consolidation. If requests or history are missing, invoke azure-kubernetes for rightsizing if available; otherwise stop. Read PVC/PV topology or SKU/quota only when it constrains placement.

For unexplained scaling, evictions, or pending pods despite available compute, use node scaling bottlenecks before consolidation.

Signals

• compatible small pools with sustained low requested and actual utilization;

• nodes with stranded CPU but insufficient memory, or the reverse;

• oversized pod requests that prevent otherwise available capacity from being used;

• required node/pod affinity, anti-affinity, topology spread, selectors, taints, zones, host ports, PV node/zone affinity, maxPods, or extended resources that restrict placement;

• PDBs, unmanaged pods, node-local storage, or do-not-disrupt settings that block safe eviction;

• persistent pending pods confirmed eligible for affected pools; include their requests in the theoretical minimum, exclude unrelated pods, and do not model unresolved scheduling failures.

Pools are merge candidates only when workload isolation, OS/architecture, priority, zones, networking, security/compliance, storage, accelerator, and availability requirements remain compatible. Preserve a dedicated production system pool.

Placement Controls

For every workload and pool, inventory controls that limit eligible nodes or block eviction. Record the source, hard or preferred behavior, scope, eligible nodes/domains, excluded capacity, and documented intent. Include topology spread, affinity/anti-affinity, selectors, taints/tolerations, zones, host ports, storage locality, extended resources, and disruption controls.

Correlate each control with scheduling failures, evictions, blocked scale-down, or autoscaler/NAP node creation; presence alone does not prove cost impact. Preserve confirmed requirements and unknown intent. Flag owner review only when evidence shows a control is stale, redundant, conflicting, broader than its intent, or disproportionately strands capacity.