Les trois sondes interrogent le même conteneur. Elles n’ont pas le même effet, et c’est l’effet que l’intervieweur attend, pas la syntaxe YAML.
La readiness répond à : « ce conteneur peut-il recevoir du trafic maintenant ? » Un échec le retire des Endpoints du Service. Le processus continue. C’est la sonde du déploiement sûr : tant qu’elle échoue, le rolling update ne considère pas le nouveau Pod comme prêt, et les clients ne le voient pas.
La liveness répond à : « ce processus est-il encore vivant, ou faut-il le tuer ? » Un échec, et le kubelet envoie un SIGTERM puis un SIGKILL, puis relance selon restartPolicy. C’est une arme. Une liveness trop stricte, ou branchée sur une dépendance externe, crée le CrashLoopBackOff au lieu de le détecter.
La startup répond à : « le processus a-t-il fini de démarrer ? » Tant qu’elle n’a pas réussi, liveness et readiness sont suspendues. Elle existe pour les applications lentes au boot — JVM, migrations, caches à charger — afin que vous n’ayez pas à gonfler initialDelaySeconds au hasard. Une fois réussie, elle ne rejoue plus.
Utiliser le même endpoint pour liveness et readiness, surtout s’il ping la base. La readiness doit échouer si la dépendance est down : on cesse d’envoyer du trafic. La liveness, dans le même cas, redémarre tous les Pods en même temps. Vous transformez une panne de base en tempête de redémarrages.
La liveness se limite à « le processus répond encore » — un /live local, sans I/O réseau. La readiness peut être plus exigeante : /ready qui vérifie le pool de connexions, le warmup, un fichier de readiness. La startup, un /live ou un simple TCP, avec un failureThreshold assez haut pour couvrir le pire démarrage.
Que vous parlez des conséquences, pas des champs. periodSeconds, timeoutSeconds, failureThreshold comptent : une readiness toutes les deux secondes avec un seuil de 1 est un flip-flop ; une liveness qui timeout trop court tue un thread occupé. Et qu’une sonde HTTP sur le mauvais port, ou un exec qui lance un shell lourd, est elle-même une charge.
« Que se passe-t-il si vous n’en mettez aucune ? »
Sans readiness, le Pod entre dans le Service dès que le conteneur démarre : les premières requêtes échouent, et un rolling update se croit réussi trop tôt. Sans liveness, un deadlock silencieux reste dans le Service pour toujours : le processus est « Running », il ne sert plus. Sans startup, vous compensez avec un initialDelaySeconds figé, trop court en charge, trop long au quotidien.
Le manifeste minimal qui les place correctement est dans votre premier Deployment vraiment fiable.