Redémarrer les pods lors des mises à jour de la carte de configuration dans Kubernetes ?

Question

Comment redémarrer automatiquement les pods Kubernetes et les pods associés aux déploiements lorsque leur configmap est modifiée/mise à jour ?

---

Je sais qu'il a été question de la possibilité de redémarrer automatiquement les pods lorsqu'une carte de configuration est modifiée, mais à ma connaissance, cela n'est pas encore disponible dans Kubernetes 1.2.

Donc, ce que j'aimerais faire (je pense), c'est un "redémarrage à froid" de l'application déploiement associée aux pods consommant la carte de configuration. Est-il possible, et si oui comment, de forcer un redémarrage continu d'un déploiement dans Kubernetes sans rien changer dans le modèle réel ? Est-ce actuellement la meilleure façon de procéder ou existe-t-il une meilleure option ?

Answer 1

La meilleure solution actuelle à ce problème (référencée profondément dans https://github.com/kubernetes/kubernetes/issues/22368 liée dans la réponse sœur) est d'utiliser les déploiements, et de considérer vos ConfigMaps comme immuables.

Lorsque vous souhaitez modifier votre configuration, créez une nouvelle ConfigMap avec les modifications que vous souhaitez apporter, et faites pointer votre déploiement vers la nouvelle ConfigMap. Si la nouvelle configuration ne fonctionne pas, le déploiement refusera de réduire votre ReplicaSet actif. Si la nouvelle configuration fonctionne, votre ancien ReplicaSet sera réduit à 0 réplique et supprimé, et de nouveaux pods seront lancés avec la nouvelle configuration.

Ce n'est pas aussi rapide que de modifier la ConfigMap en place, mais c'est beaucoup plus sûr.

Answer 2

La signalisation d'un pod lors de la mise à jour de la carte de configuration est une fonctionnalité en cours de réalisation ( https://github.com/kubernetes/kubernetes/issues/22368 ).

Vous pouvez toujours écrire un pid1 personnalisé qui remarque que le confimap a changé et redémarre votre application.

Vous pouvez aussi, par exemple, monter la même carte de configuration dans deux conteneurs, exposer un contrôle de santé http dans le deuxième conteneur qui échoue si le hachage du contenu de la carte de configuration change, et utiliser ce contrôle comme sonde de vivacité du premier conteneur (car les conteneurs d'un pod partagent le même espace de noms réseau). Le kubelet redémarrera votre premier conteneur pour vous lorsque la sonde échouera.

Bien sûr, si vous ne vous souciez pas des nœuds sur lesquels se trouvent les pods, vous pouvez simplement les supprimer et le contrôleur de réplication les "redémarrera" pour vous.

Answer 3

https://github.com/kubernetes/helm/blob/master/docs/charts_tips_and_tricks.md#user-content-automatically-roll-deployments-when-configmaps-or-secrets-change

Souvent, les configmaps ou les secrets sont injectés comme fichiers de configuration dans les conteneurs. En fonction de l'application, un redémarrage peut être nécessaire si ces fichiers sont mis à jour lors d'une prochaine mise à jour de l'application. helm upgrade Mais si la spécification de déploiement elle-même n'a pas changé, l'application continue de fonctionner avec l'ancienne configuration, ce qui entraîne un déploiement incohérent.

El sha256sum peut être utilisée avec la fonction include pour s'assurer qu'une section de modèle de déploiement est mise à jour si une autre spécification change :

kind: Deployment
spec:
  template:
    metadata:
      annotations:
        checksum/config: {{ include (print $.Template.BasePath "/secret.yaml") . | sha256sum }}
[...]

Dans mon cas, pour certaines raisons, $.Template.BasePath n'a pas fonctionné mais $.Chart.Name fait :

spec:
  replicas: 1
  template:
    metadata:
      labels:
        app: admin-app
      annotations:
        checksum/config: {{ include (print $.Chart.Name "/templates/" $.Chart.Name "-configmap.yaml") . | sha256sum }}

Answer 4

Vous pouvez mettre à jour une annotation de métadonnées qui n'est pas pertinente pour votre déploiement. Cela déclenchera une mise à jour continue.

par exemple :

    spec:
      template:
        metadata:
          annotations:
            configmap-version: 1

Answer 5

Une autre façon est de le coller dans la section commande du déploiement :

...
command: [ "echo", "
  option = value\n
  other_option = value\n
" ]
...

Sinon, pour que cela ressemble davantage à ConfigMap, vous pouvez utiliser un déploiement supplémentaire qui hébergera simplement cette configuration dans le fichier command et exécuter kubectl create sur celle-ci tout en ajoutant une "version" unique à son nom (comme pour calculer un hachage du contenu) et en modifiant tous les déploiements qui utilisent cette configuration :

...
command: [ "/usr/sbin/kubectl-apply-config.sh", "
  option = value\n
  other_option = value\n
" ]
...

Je vais probablement poster kubectl-apply-config.sh si ça finit par marcher.

(ne faites pas ça, ça fait trop mauvais effet)