existe-t-il un moyen de demander le statut d'unProbe à l'aide d'un nom de service lié à un déploiement? Dans un initContainer par exemple?
Imaginez que nous avons un déploiement X, en utilisant unProbedProbe, un service lié à celui-ci afin que nous puissions demander par exemple Je sais que la bonne façon de gérer les dépendances est de laisser Kubettes le faire pour nous, mais j'ai un conteneur qui ne se bloque pas et je n'ai aucune main dessus ... http: // service-x: 8080 .
Maintenant, nous créons un déploiement Y, dans l'initContainer, nous voulons savoir si le déploiement X est prêt. Y a-t-il un moyen de demander quelque chose comme déploiement-x.ready ou service-x.ready ?
3 Réponses :
Vous pouvez ajouter un Ngnix Proxy Sidecar sur le déploiement Y.
Définissez le déployagey.initContainer.readynessProbe sur un port de Nginx et que le port est proxé sur déployanty.readynessProbe
Merci pour la réponse, j'ai déjà trouvé quelque chose comme celui-ci sur Google, mais je recherche une autre solution sans Sidecar ...
au lieu de la présidenceProbe, vous pouvez utiliser juste InitContainer .
Vous créez une pod / déploiement x, faites le service X et créez un initContainer qui recherche le service x. P>
S'il le trouve -> il fera la pod. P>
S'il ne le trouvera pas - il continuera à regarder jusqu'à ce que le service X soit créé. P> blockquote>
juste un exemple simple, nous créons NGinx Déploiement en utilisant
kubectl Appliquer -f nginx.yaml code>. p>nginx.yaml p>
xxx pré> alors nous créons initContainer p>
initContainer.yaml p>
xxx pré> initContainer cherchera un service My-Nginx fort>, jusqu'à ce que vous le créiez, ce sera Dans
init: 0/1 code> Statut. P>Events: Type Reason Age From Message ---- ------ ---- ---- ------- Normal Scheduled <unknown> default-scheduler Successfully assigned default/myapp-pod to kubeadm2 Normal Pulled 20s kubelet, kubeadm2 Container image "busybox:1.28" already present on machine Normal Created 20s kubelet, kubeadm2 Created container init-myservice Normal Started 20s kubelet, kubeadm2 Started container init-myservice Normal Pulled 20s kubelet, kubeadm2 Container image "busybox:1.28" already present on machine Normal Created 20s kubelet, kubeadm2 Created container myapp-container Normal Started 20s kubelet, kubeadm2 Started container myapp-container
Bonjour, je pense que votre réponse ne prend pas le fait que le service a au moins une pod prête et que c'est pourquoi j'ai besoin d'utiliser LâveyProbe. Faites-moi savoir si je me trompe, je n'ai pas une telle expérience sur Kubettes. Mais j'ai trouvé une solution avec ce lien:
Salut @borhink, je ne sais pas si je vous comprends correctement, vous voulez dire cela fonctionnera si le service sera ici, mais il n'y aura pas de pods? Si vous avez trouvé une solution pourriez-vous l'ajouter comme une réponse afin que la communauté puisse la voir, si quelqu'un avait la même idée?
J'ai ajouté une réponse où nous pouvons vérifier si un service est créé et dispose d'une ou de plusieurs pod prêts. Merci pour votre temps. Et désolé, l'anglais n'est pas mon langage indigène, il est difficile d'expliquer certains points ...
Je finaly a trouvé une solution en suivant ce lien: https: // blog .giantswarm.io / WAIT-FOR-IT-UTILISATION-CONDITIONNEMENT-SMBES-FOR-Service-Dépendances-In-KuberNettes /
Nous avons d'abord besoin de créer un serviceAccount à Kubettes pour permettre aux points d'extrémité de la liste d'un initContainer. Après cela, nous demandons les points d'extrémité disponibles, s'il en existe au moins une, la dépendance est prête (dans mon cas).