Existe-t-il un parm de configuration kubernetes (service ou rc ou autre) à retarder avant d'utiliser un pod

Question

Nous exécutons une charge de travail sur un cluster hébergeant 2 instances d'un petit pod (3 conteneurs). Accéder au pod en utilisant un service avec nodeport. Si nous arrêtons un pod et que rc en lance un nouveau, notre charge de travail constante (faible volume) a de nombreux échecs (Rational Perf Tester, test http frappant le service sur le maître ... mais probablement même s'il frappait l'un ou l'autre minion ... le maître a aussi un serviteur). Quoi qu'il en soit, si nous ajoutons simplement un pod avec une échelle de kubectl, nous obtenons également des erreurs. Si on enlève alors ceci un pod (rc n'en commence pas un nouveau car on en avait un de plus que nécessaire à cause de l'échelle) ... pas d'erreurs. Il semble que le service commence à envoyer du travail à un nouveau pod car Kubelet a fait son truc, même si les conteneurs ne sont pas en place. Ainsi, chaque fois qu'un pod est démarré ... il commence à recevoir un peu trop de travail (après que Kubelet ait fait son travail, mais avant que tous les containers ne soient prêts). Existe-t-il un moyen de garantir que le service ne sera pas acheminé vers ce pod tant que tous les conteneurs ne seront pas ouverts? À part cela, y a-t-il un moyen de dire attendre 'n' secondes avant d'envoyer à ce pod? Je peux me tromper, mais le comportement semble suggérer ce scénario.

Answer 1

Ceci est précisément ce que l'option est readinessProbe :)

Il est documenté plus here et here, et fait partie de la container definition dans une spécification de pod. Par exemple, vous pouvez utiliser une spécification de pod comme celle ci-dessous pour vous assurer que votre pod nginx ne sera pas marqué comme prêt (et donc que le trafic ne lui sera pas envoyé) jusqu'à ce qu'il réponde à une requête HTTP pour /index.html:

apiVersion: v1 
kind: ReplicationController 
metadata: 
    name: my-nginx 
spec: 
    replicas: 2 
    template: 
    metadata: 
     labels: 
     app: nginx 
    spec: 
     containers: 
     - name: nginx 
     image: nginx 
     ports: 
     - containerPort: 80 
     lifecycle: 
      httpGet: 
      path: /index.html 
      port: 80 
      initialDelaySeconds: 10 
      timeoutSeconds: 5