Cet article de blog explore comment s'assurer qu'un conteneur sidecar Kubernetes démarre et devienne prêt avant le conteneur principal de l'application. Les conteneurs sidecar natifs dans Kubernetes démarrent avant l'application principale, souvent presque simultanément, ce qui n'est pas toujours souhaité. L'auteur examine les sondes de préparation (readiness probes), les sondes de démarrage (startup probes) et les hooks de cycle de vie postStart pour retarder le démarrage de l'application principale jusqu'à ce que le sidecar soit prêt. L'utilisation d'une sonde de préparation seule ne retarde pas le démarrage de l'application principale. Une sonde de démarrage, correctement configurée, retarde efficacement l'application principale jusqu'à ce que le sidecar soit prêt. L'article mentionne également brièvement les hooks postStart comme option. Les sondes de vivacité (liveness probes) redémarrent principalement le sidecar et n'influencent pas la préparation de l'application principale. La principale conclusion est qu'une sonde de démarrage est la méthode la plus efficace pour retarder le démarrage de l'application principale. L'auteur conclut en soulignant l'importance de contrôler l'ordre de démarrage des conteneurs lorsque l'application principale dépend d'un sidecar. Cela offre une solution lorsque la modification du code de l'application n'est pas possible.