Redémarrer les pods lorsque configmap est mis à jour dans Kubernetes?

121

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


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

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

Johan
la source
$ kubectl set env deployment my deployment --env="LAST_RESTART=$(date)" --namespace ...fais le travail pour moi
maciek

Réponses:

60

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

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

Vous pouvez également par exemple: monter la même mappe de configuration dans 2 conteneurs, exposer une vérification d'intégrité http dans le deuxième conteneur qui échoue si le hachage du contenu de la mappe de configuration change, et pousser cela comme sonde de vivacité du premier conteneur (car les conteneurs dans un pod partage 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.

Prashanth B
la source
Avec «suppression de pods», vous voulez dire: Collecter tous les noms de pod, en supprimer un, attendre le remplacement, supprimer le second, attendre le remplacement, etc. Correct?
Torsten Bronger
6
en utilisant un déploiement, je le réduirais puis augmenterais. Cependant, vous aurez toujours ce petit temps d'arrêt. Vous pouvez le faire en une ligne pour réduire cela ... kubectl scale deployment/update-demo --replicas=0; kubectl scale deployment/update-demo --replicas=4;
Nick H
Si vous ne voulez pas trouver tous les pods et que vous ne vous souciez pas des temps d'arrêt, supprimez simplement le RC, puis recréez le RC.
Tiré
1
Cela signifie-t-il que le volume sur lequel il est monté est mis à jour et qu'il vous suffit de relire le fichier sur le pod sans redémarrer tout le pod?
Matt Williamson
@NickH Rapide et sale, heureusement, le temps d'arrêt était acceptable dans mon cas et cela a très bien fonctionné, merci!
ChocolateAndCheese
129

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

Lorsque vous souhaitez modifier votre configuration, créez un nouveau ConfigMap avec les modifications que vous souhaitez apporter et pointez votre déploiement sur le nouveau ConfigMap. Si la nouvelle configuration est interrompue, le déploiement refusera de réduire votre ReplicaSet opérationnel. Si la nouvelle configuration fonctionne, votre ancien ReplicaSet sera mis à l'échelle à 0 réplique et supprimé, et de nouveaux pods seront démarrés avec la nouvelle configuration.

Pas aussi rapide que de simplement éditer le ConfigMap en place, mais beaucoup plus sûr.

Symétrique
la source
2
C'est l'approche que nous avons également adoptée
Johan
5
Il convient de mentionner que le nouvel outil expérimental kustomizeprend en charge la création automatique d'un hachage de configmap déterministe, ce qui signifie que vous n'avez pas besoin de créer manuellement une nouvelle configmap: github.com/kubernetes-sigs/kustomize/blob/…
Symétrique
C'est ce que fait Spinnaker dans les coulisses, donc si vous l'utilisez, vous n'aurez pas à vous en soucier.
Gus
32

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 sous forme de fichiers de configuration dans des conteneurs. Selon l'application, un redémarrage peut être nécessaire si ceux-ci sont mis à jour avec unehelm 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.

La sha256sumfonction peut être utilisée avec la includefonction pour garantir 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.BasePathn'a pas fonctionné mais $.Chart.Namefonctionne:

spec:
  replicas: 1
  template:
    metadata:
      labels:
        app: admin-app
      annotations:
        checksum/config: {{ include (print $.Chart.Name "/templates/" $.Chart.Name "-configmap.yaml") . | sha256sum }}
quanta
la source
8
Non applicable à l'utilisation générale de Kubernetes, uniquement applicable à Helm
Emii Khaos
2
La réponse est utile mais probablement pas pertinente à cette question
Anand Singh Kunwar
helm3 a été publié récemment. Ainsi, le lien est obsolète. Il indique une masterbranche. L'URL suivante mènera aux helm2 derniers documents (actuellement) : github.com/helm/helm/blob/release-2.16/docs/…
Marcel Hoyer
Solution fraîche. J'ai changé en sha1sum, car dans mon cas, sha256sum avait 65 caractères, ce qui a donné lieu à Deployment.apps "xxx" is invalid: metadata.labels: Invalid value: "xxx": must be no more than 63 characters. Une alternative serait | trunc 63, mais sha1sum devrait être "plus unique".
iptizer le
32

Le meilleur moyen que j'ai trouvé pour le faire est d'exécuter Reloader

Il vous permet de définir des configmaps ou des secrets à surveiller, lorsqu'ils sont mis à jour, une mise à jour progressive de votre déploiement est effectuée. Voici un exemple:

Vous avez un déploiement fooet un ConfigMap appelé foo-configmap. Vous souhaitez faire rouler les pods du déploiement à chaque fois que la configmap est modifiée. Vous devez exécuter Reloader avec:

kubectl apply -f https://raw.githubusercontent.com/stakater/Reloader/master/deployments/kubernetes/reloader.yaml

Spécifiez ensuite cette annotation dans votre déploiement:

kind: Deployment
metadata:
  annotations:
    configmap.reloader.stakater.com/reload: "foo-configmap"
  name: foo
...
George Miller
la source
Reloader est compatible avec kubernetes> = 1.9
jacktrade
11

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

par exemple:

metadata:
  labels:
    configmap-version: 1
Maoz Zadok
la source
Je cherche des documents sur les métadonnées: labels: configmap-version: 1
c4f4t0r
7
les changements d'étiquette de métadonnées ne déclenchent pas un redémarrage des pods
dan carter
Cette réponse a des upwotes donc je dois demander. Si nous mettons à jour les métadonnées, le cluster Kubernetes déclenchera-t-il une mise à jour progressive? @ maoz-zadok
titus
1
Je crois que cela fonctionne tant que l'étiquette des métadonnées est soustemplate.spec
Saikiran Yerram
1

Avait ce problème où le déploiement était dans un sous-graphique et les valeurs qui le contrôlaient étaient dans le fichier de valeurs du graphique parent. Voici ce que nous avons utilisé pour déclencher le redémarrage:

spec:
  template:
    metadata:
      annotations:
        checksum/config: {{ tpl (toYaml .Values) . | sha256sum }}

Évidemment, cela déclenchera un redémarrage à tout changement de valeur, mais cela fonctionne pour notre situation. Ce qui était à l'origine dans le graphique enfant ne fonctionnerait que si le config.yaml dans le graphique enfant lui-même changeait:

    checksum/config: {{ include (print $.Template.BasePath "/config.yaml") . | sha256sum }}
Bryji
la source
0

Je fais la solution des quanta et ça marche parfaitement. Mais ce que je ne comprends pas, c'est qu'en fait le pod ne redémarre pas ... Le pod est toujours le même mais le changement est là!

Par exemple: le pod fonctionne depuis 50min et je change quelque chose et le changement est en ligne Je peux le voir sur mon navigateur et le pod est toujours en cours d'exécution + 50min !! J'utilise Helm3 ... Savez-vous ce qui rend cela possible sans redémarrer la mise à jour de configmap?

Ibrahim Yesilay
la source
1
D'accord! Je le trouve ... Parce que nous avons monté notre configmap en tant que volume et mis à jour dynamiquement ... C'est pourquoi quand je fais ce truc de "checksum" alors mon pod ne redémarre pas mais les changements sont là! Je suggère comme un bonne solution :)
Ibrahim Yesilay
-1

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

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

Alternativement, pour le rendre plus semblable à ConfigMap, utilisez un déploiement supplémentaire qui hébergera simplement cette configuration dans la commandsection et l'exécutera kubectl createdessus tout en ajoutant une `` version '' unique à son nom (comme calculer un hachage du contenu) et modifier tous les déploiements qui utilisent cette configuration:

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

Je posterai probablement kubectl-apply-config.shsi cela finit par fonctionner.

(ne fais pas ça, ça a l'air trop mauvais)

Velkan
la source