Orca ORCA v0.174.2
Documentation navigation

Cluster Autoscaler Unregistered Nodes

Runbook for when the cluster-autoscaler has nodes that were requested but never registered with the Kubernetes API. This is the ClusterAutoscalerUnregisteredNodes alert — a sibling of ClusterAutoscalerUnhealthy (07-kubernetes/12-cluster-autoscaler-unhealthy.md).

Meaning

The cluster-autoscaler runs in kube-system and scales node groups up/down based on Pending pods. The cluster-autoscaler-status-exporter (in the shared namespace) exposes cluster_autoscaler_status_long_unregistered_total — a counter of nodes the autoscaler tried to add that never registered with the Kubernetes API. When this counter is >= 1 for 5m, the alert fires.

This is almost always a cloud-provider authentication issue: the autoscaler successfully requests nodes from the cloud provider (Scaleway/Azure), but the nodes fail to join the cluster — the kubelet cannot authenticate to the API server, the bootstrap script fails, or the node never reaches Ready.

Scoped to k8s_cluster_name=~"prd-.*|stg-.*|dev-.*" — all par (Scaleway/kommodity) and AKS GPU clusters that run cluster-autoscaler, across production, staging, and development.

Impact

  • The autoscaler is requesting capacity that never arrives — Pending pods stay Pending, and the cluster appears to be scaling but isn't.
  • The autoscaler may be stuck retrying the unregistered nodes, not scaling up new ones.

Diagnosis

See 07-kubernetes/12-cluster-autoscaler-unhealthy.md § Diagnosis — specifically steps 1, 2, and 4 (check the autoscaler logs for failed to register node, check for NotReady nodes, and check the MachineDeployment/Machine status).

Mitigation

See 07-kubernetes/12-cluster-autoscaler-unhealthy.md § Mitigation — specifically the Kommodity-specific fix (delete the *-kubeconfig secret in the downstream cluster, delete the signing-key secret in kommodity, wait for automatic recreate, validate the kubeconfig secret is recreated, restart the autoscaler). This is the standard recovery for Scaleway sovereign clusters where the signing key has expired.

For AKS GPU clusters, check the Azure VMSS activity log for provisioning failures.

Verify

  • max by (k8s_cluster_name) (cluster_autoscaler_status_long_unregistered_total{k8s_cluster_name="<cluster>"}) returns to 0.
  • kubectl get nodes shows previously-unregistered nodes as Ready (or removed if garbage-collected).
  • The autoscaler logs show ScaleUp / ScaleDown activity resuming.

Notes

  • Sibling of 07-kubernetes/12-cluster-autoscaler-unhealthy.md — same autoscaler deployment, same diagnosis, same kommodity recovery procedure.
  • All environments — production, staging, and development clusters are all covered (no environment= filter).
  • Cloud-provider auth — the most common cause is an expired or stale signing key (kommodity) or VMSS provisioning failure (AKS).
  • Related — 08-capacity/05-nodegroup-utilization-high.md for nodegroup capacity ceiling.