web-dev-qa-db-fra.com

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

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

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

kubernetes
78
Johan

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

Vous pouvez toujours écrire un pid1 personnalisé qui indique que la confimap a été modifiée et redémarre votre application.

Vous pouvez également, par exemple: monter la même carte de configuration dans 2 conteneurs, exposer une vérification d’état http dans le second conteneur qui échoue si le hachage du contenu de la carte de configuration change et pod partage le même espace de noms réseau). Le kubelet va redémarrer votre premier conteneur pour vous lorsque la vérification échoue.

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.

41
Prashanth B

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

Lorsque vous souhaitez modifier votre configuration, créez un nouveau ConfigMap avec les modifications que vous souhaitez apporter et dirigez votre déploiement vers le nouveau ConfigMap. Si la nouvelle configuration est interrompue, le déploiement refusera de réduire votre ReplicaSet actif. Si la nouvelle configuration fonctionne, alors votre ancien ReplicaSet sera mis à l'échelle et supprimé, et les 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.

100
Symmetric

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

Souvent, configmaps ou 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 un helm upgrade ultérieur, mais si la spécification de déploiement elle-même n'a pas changé, l'application continue de s'exécuter avec l'ancienne configuration, ce qui entraîne un déploiement incohérent.

La fonction 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 }}
18
quanta

La meilleure façon de le faire est de lancer Reloader

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

Vous avez un déploiement foo et un ConfigMap appelé foo-configmap. Vous voulez lancer les pods du déploiement à chaque changement de configmap. Vous devez exécuter Reloader avec:

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

Puis spécifiez cette annotation dans votre déploiement:

kind: Deployment
metadata:
  annotations:
    configmap.reloader.stakater.com/reload: "foo-configmap"
  name: foo
...
11
George Miller

Vous pouvez mettre à jour un libellé de métadonnées non pertinent pour votre déploiement. il va déclencher une mise à jour progressive

par exemple:

metadata:
  labels:
    configmap-version: 1
4
Maoz Zadok