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 nodesshows previously-unregistered nodes asReady(or removed if garbage-collected).- The autoscaler logs show
ScaleUp/ScaleDownactivity 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.mdfor nodegroup capacity ceiling.