Kubernetes : durée de vie maximale des pods

Question

J'utilise Kubernetes 1.6 et Docker pour déployer des instances/pods d'un microservice.

J'ai un service qui doit régulièrement extraire des données mises à jour en continu d'un référentiel externe. Cette mise à jour peut être déclenchée manuellement au moment de l'exécution, mais le service est inutilisable pendant ce temps. En outre, les données à jour sont toujours récupérées au démarrage, de sorte que l'instance de service fraîchement lancée dispose des données externes les plus récentes.

J'aimerais donc créer automatiquement un nouveau pod toutes les heures (ou à une autre fréquence), puis tuer l'ancien pod.

D'un point de vue conceptuel, il semble que je devrais simplement configurer une durée de vie maximale par pod dans le déploiement, de sorte que Kubernetes démarre une nouvelle instance/pod et tue l'ancienne si la durée de vie maximale a expiré, tout en veillant à ce qu'il y ait toujours au moins un pod en fonctionnement. Cependant, Kubernetes ne semble pas fournir une durée de vie maximale pour les pods. .

De plus, en raison de la mise à jour des données pendant le démarrage, le démarrage de la nacelle prend une à deux minutes avant qu'elle ne soit prête.

Answer 1

Ceci devait être un commentaire mais pourrait devenir une réponse. Je le poste en tant que réponse afin que l'approche soit facile à lire.

J'ai donc une approche possible qui pourrait vous convenir. Vous exécutez un pod de téléchargement global qui téléchargera les fichiers dans un dossier spécifique. Supposons que le téléchargement ait lieu toutes les heures. Vous allez donc créer un dossier comme 22-08-2017-20-00 et vous créez un fichier appelé latest . Le contenu de ce latest sera 22-08-2017-20-00

Le téléchargeur, lorsqu'il récupère une nouvelle mise à jour, crée un nouveau dossier et y télécharge les données. Une fois les données téléchargées, le contenu du dernier dossier sera remplacé par ce nom.

Désormais, les pods de votre application principale se référeront à ces volumes hôtes, liront le contenu du fichier et utiliseront ce dossier pour commencer le traitement des données.

Maintenant, vous devriez exécuter quelques répliques. Si vous configurez un cron et redémarrez les pods, ils démarreront rapidement (sans téléchargement de données) et récupéreront les dernières données. Vous pouvez faire une mise à jour continue en changeant un faux paramètre sans impact et faire une mise à jour continue.

Vous pouvez également configurer vos pods pour qu'ils échouent après une heure. Comment faire ? Assurez-vous que votre image possède la commande timeout

$ time timeout 2 sleep 12

real    0m2.002s
user    0m0.000s
sys 0m0.000s

Maintenant, vous ne voulez pas que tous les pods tombent en panne au même moment, vous pouvez donc générer un nombre aléatoire entre 50min et 70min et laisser chaque pod tomber en panne à un moment différent et être redémarré automatiquement par k8s.

Voir si l'approche a un sens

Answer 2

Voici un exemple qui pourrait vous aider : https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-probes/

apiVersion: v1
kind: Pod

metadata:
  labels:
    test: liveness
  name: liveness-exec
spec:
  containers:

  - name: liveness

    args:
    - /bin/sh
    - -c
    - touch /tmp/healthy; sleep 30; rm -rf /tmp/healthy; sleep 600

    image: gcr.io/google_containers/busybox

    livenessProbe:
      exec:
        command:
        - cat
        - /tmp/healthy
      initialDelaySeconds: 5
      periodSeconds: 5

En utilisant les contrôles de santé, vous pouvez forcer la reprogrammation du conteneur après un certain temps. Je pense que cela pourrait convenir à votre cas.