Quelle est la différence entre une sonde de liveness et une sonde de readiness, et comment les gens se trompent-ils ?

Une sonde de readiness contrôle si un pod reçoit du trafic ; une sonde de liveness contrôle si le kubelet redémarre le conteneur. L'erreur classique est de pointer la liveness vers une dépendance en aval, si bien qu'une base de données lente redémarre tous les pods en boucle et transforme une panne partielle en panne totale. La liveness ne devrait vérifier que le fait que le processus est vivant et non bloqué. Utilisez une sonde de startup pour les applications qui démarrent lentement.

La readiness décide si le pod figure dans les endpoints du service, la liveness décide si le kubelet tue et redémarre le conteneur. La panne que j'ai vraiment vue, c'est une équipe qui avait fait vérifier la base de données par l'endpoint de liveness. La base a ralenti, tous les pods ont échoué la liveness à peu près en même temps, tout le déploiement est parti en boucle de redémarrage, et au lieu de lectures dégradées on n'avait plus rien du tout, plus une ruée de connexions froides au retour. La liveness devrait être presque ennuyeuse : le processus peut-il servir un handler trivial, la boucle d'événements est-elle coincée. Tout ce qui touche aux dépendances appartient à la readiness, parce que sortir un pod de la rotation est réversible et bon marché. L'autre chose que je vérifie toujours, c'est le timing. Si l'application met 45 secondes à préchauffer ses caches, soit vous utilisez une sonde de startup, soit vous réglez initialDelaySeconds et failureThreshold en conséquence, sinon vous avez construit une machine qui ne peut jamais finir de démarrer.