kubernetes-sigs/cluster-api

Stale `HealthCheckSucceeded=False` condition not cleared after node recovery when using external remediation

Ouverte

#13 822 ouverte le 18 juin 2026

Voir sur GitHubGuide contributeur
 (13 commentaires) (0 réaction) (1 personne assignée)Go (1 532 forks)auto 404
area/machinehealthcheckhelp wantedkind/bugpriority/important-soontriage/accepted

Métriques du dépôt

Stars
 (4 267 étoiles)
Métriques de merge PR
 (Métriques PR en attente)

Description

We have encountered an issue where machines end up with a stale HealthCheckSucceeded=False condition that never gets cleared, even though the nodes have fully recovered and are running fine.

This has been observed in two scenarios, both using a MachineHealthCheck with a remediationTemplate:

  1. "No heartbeat for 5 minutes": Node briefly reported Ready=Unknown, the health check fired, the node recovered on its own, but HealthCheckSucceeded=False persists.
  2. "Exceeded start-up time of 30m": Node eventually came up healthy after exceeding the configured startup timeout, but the failed condition was never removed.

After a node recovers from such a transient health check failure:

  • NodeHealthy=True
  • NodeReady=True
  • No active remediation objects exist
  • HealthCheckSucceeded=False: this was not cleared
  • Available=False: machine appears unavailable when it is not

CAPI version used: v1.13.1

Label(s) to be applied

/kind bug /area machinehealthcheck

Guide contributeur

Direction de recherche
Examinez la logique de mise à jour des conditions dans le contrôleur MachineHealthCheck, en particulier la gestion des conditions `HealthCheckSucceeded` et `Available` après la récupération du nœud lors de l'utilisation d'une remédiation externe. Concentrez vous sur la réconciliation des conditions qui pourrait ne pas effacer les conditions d'échec obsolètes.
Stack technique
go
Domaine
backend
Type d'issue
Bug
DifficultéDifficulté estimée pour un nouveau contributeur, de 1 pour un très petit changement à 5 pour un travail expert.
3
Temps estiméFourchette de temps approximative pour investiguer, implémenter, tester et préparer une pull request.
1-3 heures
Statut d'activitéDisponibilité apparente de l'issue : fraîche, active, ancienne, bloquée ou en attente d'un mainteneur.
Active
ClartéClarté avec laquelle l'issue explique le changement attendu, les critères d'acceptation et la prochaine étape.
Claire
Prérequis
Go
Accessibilité débutantScore de 1 à 100 estimant l'accessibilité de cette issue pour un premier contributeur.
65