Une mise à niveau de l'agent n'a pas pris effet

Symptom

Une mise à jour a été approuvée pour un nœud et le nœud est dégradé, a été restauré à sa version précédente, ou signale sa version précédente. GET /api/v1/nodes/{name}/upgrade/history montre la tentative.

Diagnose

1. Qu’a dit l’agent ?

   sudo journalctl -u odysseus-agent --since "30 minutes ago"

   Attendez-vous à ce que la mise à jour soit annoncée, que la nouvelle image soit tirée et que le service redémarre. Les erreurs de pull d’image, les erreurs de permission et les échecs de démarrage se nomment eux-mêmes.

2. Le nœud peut-il tirer la nouvelle image ? L’image de l’agent est tirée par le nœud lui-même, depuis le registre pour lequel le nœud est configuré — pas via le plan de contrôle.

3. S’est-il restauré automatiquement ? Une mise à jour échouée revient à la version précédente. Un nœud qui est sain sur l’ancienne version s’est déjà rétabli ; la question est de savoir pourquoi la nouvelle n’a pas démarré.

4. Vérifiez l’historique de mise à niveau plutôt que l’état actuel du nœud. Un nœud qui s’est rétabli est identique à un nœud qui n’a jamais été mis à niveau.

Resolve

• Échec du pull : restaurez l’accès du nœud au registre, puis approuvez à nouveau la mise à niveau depuis le tableau de bord.
• Démarré et planté : le journal indique la raison. N’approuvez pas à nouveau tant que ce n’est pas résolu — une seconde tentative identique produit un second rollback identique.
• Bloqué dégradé après un rollback : redémarrez le service agent sur le nœud. Il se ré-enregistre ; il n’a pas besoin d’être réinscrit.

Prevent

Mettez à niveau un nœud et laissez-le se stabiliser avant d’approuver les autres. Les nœuds appartenant au locataire sont mis à niveau par approbation plutôt qu’à distance, et c’est à ce moment-là que l’échec d’un nœud est peu coûteux.