Pod isn't restarted when configMaps or secrets change

Aperta Adatta ai principianti
  • Qualcosa non va?
#202 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
2/5
Tempo stimato
1-3 ore
Idoneità per principianti
72/100
Tipo di issue
Bug
Chiarezza
Specificata chiaramente
Stato di attività
Attiva
Stack tecnologico
helm, kubernetes
Ambito
devops

Direzione di ricerca

Il payload indica i template ConfigMap e Secret (configmap.yaml, secret.yaml) e il template del pod nel Deployment del chart, dove andrebbero le annotazioni. Leggi come vengono renderizzati i metadati del template del pod nel Deployment e come configMaps e secrets vengono montati con subPath. È completato quando il rendering del chart con un valore di configMaps o secrets modificato produce un'annotazione diversa nel template del pod, così il pod viene riavviato durante l'upgrade.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

Changing only a configMaps (or secrets) entry in values doesn't restart the pod. The deployment's pod template doesn't change, so helm upgrade updates the ConfigMap but leaves the old pod running. Since the chart mounts these with subPath, the running pod never sees the new content either: it keeps the old file until something else restarts it.

For example, changing an Rspamd override in configMaps and upgrading leaves Rspamd on the old config until a manual kubectl rollout restart.

The usual fix is a checksum annotation on the pod template, so any config change rolls the pod:

template:
  metadata:
    annotations:
      checksum/configmaps: {{ include (print $.Template.BasePath "/configmap.yaml") . | sha256sum }}
      checksum/secrets: {{ include (print $.Template.BasePath "/secret.yaml") . | sha256sum }}
Lingua principale
Mustache
Stelle
157
Fork
82
Merge medio
22m
PR unite (30g)
3

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di docker-mailserver/docker-mailserver-helm

Tutte le issue di docker-mailserver/docker-mailserver-helm

Issue simili

Altre issue su DevOps

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.