1
votes

La mise à niveau de la barre sur une configuration injecte-t-elle automatiquement de nouvelles données dans le pod en cours d'exécution?

Lors de l'émission d'une mise à niveau de la barre sur un pod en cours d'exécution, mon configmap est mis à jour, mais le pod connaîtra-t-il automatiquement les valeurs mises à jour de configmap ou y a-t-il une autre étape que je dois prendre pour injecter de nouvelles valeurs de configmap dans le pod?

Mon objectif général est d'éviter d'avoir à interagir avec le pod en cours d'exécution, comme une suppression ou un redémarrage / réinstallation.

J'ai vu beaucoup d'informations sur la modification de sha1sum et la réalisation de solutions de contournement, mais ma question est plus basique: les pods prennent-ils automatiquement conscience des nouveaux éléments de configmap?

---- MISE À JOUR --- donc ce que nous avons fini par faire était:

mise à niveau de la barre -n version -f version / values.yaml --recreate-pods

bien que cela termine le pod existant, un autre est instantanément démarré lors de l'émission de la commande, ce qui signifie un temps d'arrêt "proche de zéro".


0 commentaires

3 Réponses :


6
votes

Non, les pods ne prennent pas automatiquement conscience du contenu d'un changement de carte de configuration.

Dans le cas d'une mise à niveau de barre, c'est pourquoi vous devez utiliser la syntaxe du modèle de barre pour ajouter la valeur de hachage du fichier de mappage de configuration aux métadonnées du pod (ou modèle de pod). Cela crée un lien entre la configuration et le pod.

Si vous faites cela, le pod (ou le modèle de pod) est mis à jour même si seule la carte de configuration est modifiée. Ensuite, aucune intervention manuelle n'est requise.


0 commentaires

7
votes

Si votre graphique Helm crée un ConfigMap et que ConfigMap est monté en tant que volume dans un pod, alors lorsque le ConfigMap est mis à jour, le système de fichiers du conteneur est également mis à jour . C'est alors à l'application de constater que les fichiers ont changé.

Des astuces telles que la définition d'un hachage du contenu du fichier en tant qu'annotation de pod sont spécifiquement là pour provoquer la mise à jour d'un déploiement d'une manière qui supprimera et recréera les pods existants. C'est d'accord! Les pods dans Kubernetes sont très jetables, et si vous supprimez un pod géré par un déploiement, il sera automatiquement recréé. Si votre application lit uniquement le contenu de ConfigMap au démarrage (c'est très typique), vous devez faire quelque chose comme ceci pour que le pod redémarre tout seul (copié hors de la documentation liée):

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


0 commentaires

0
votes

Utilisation de la barre:

spec:
  strategy:
    type: "Recreate"
  replicas: {{ .Values.replicaCount }}
  selector:
    matchLabels:
      {{- include "dmi.selectorLabels" . | nindent 6 }}
  template:
    metadata:
      {{- with .Values.podAnnotations }}
      annotations:
        {{- toYaml . | nindent 8 }}
      {{- end }}
      labels:
        checksum/config: {{ include (print $.Template.BasePath "/configmap.yaml") . | sha256sum | trunc 10}}

Tant que votre configmap changera, le pod se recréera car la somme de contrôle sera modifiée. J'ai utilisé la stratégie: recréer car ma solution n'a pas besoin de mise à jour continue. Mais cela devrait également fonctionner avec la mise à jour progressive.


1 commentaires

Veuillez expliquer ce que fait votre code et comment il le fait.