Riavviare i pod quando la mappa di configurazione si aggiorna in Kubernetes?

Come faccio a riavviare automaticamente i pod Kubernetes e i pod associati alle distribuzioni quando la loro mappa di configurazione viene modificata / aggiornata?

So che si è parlato della possibilità di riavviare automaticamente i pod quando una mappa di configurazione cambia, ma per quanto ne so questo non è ancora disponibile in Kubernetes 1.2.

Quindi quello che (penso) vorrei fare è un "riavvio continuo" della risorsa di distribuzione associata ai pod che consumano la mappa di configurazione. È possibile, e in tal caso come, forzare un riavvio continuo di una distribuzione in Kubernetes senza modificare nulla nel modello effettivo? Questo è attualmente il modo migliore per farlo o esiste un'opzione migliore?

La segnalazione di un pod durante l'aggiornamento della mappa di configurazione è una funzionalità in lavorazione ( https://github.com/kubernetes/kubernetes/issues/22368 ).

Puoi sempre scrivere un pid1 personalizzato che noti che la mappa di configurazione è cambiata e riavvia la tua app.

Puoi anche, ad esempio: montare la stessa mappa di configurazione in 2 contenitori, esporre un controllo di integrità http nel secondo contenitore che fallisce se l'hash del contenuto della mappa di configurazione cambia e spingerlo come sonda di vivacità del primo contenitore (perché i contenitori in un pod condivide lo stesso spazio dei nomi di rete). Il kubelet riavvierà il tuo primo contenitore per te quando la sonda fallisce.

Ovviamente se non ti interessa su quali nodi si trovano i pod, puoi semplicemente eliminarli e il controller di replica li "riavvierà" per te.

L'attuale migliore soluzione a questo problema (referenziato in profondità in https://github.com/kubernetes/kubernetes/issues/22368 collegato nella risposta del fratello) è utilizzare le distribuzioni e considerare le tue ConfigMaps immutabili.

Quando si desidera modificare la configurazione, creare una nuova ConfigMap con le modifiche che si desidera apportare e indirizzare la distribuzione alla nuova ConfigMap. Se la nuova configurazione non funziona, la distribuzione rifiuterà di ridimensionare il ReplicaSet funzionante. Se la nuova configurazione funziona, il tuo vecchio ReplicaSet verrà ridimensionato a 0 repliche ed eliminato e i nuovi pod verranno avviati con la nuova configurazione.

Non abbastanza veloce come modificare la ConfigMap in posizione, ma molto più sicuro.

Il modo migliore che ho trovato per farlo è eseguire Reloader

Ti consente di definire mappe di configurazione o segreti per guardare, quando vengono aggiornati, viene eseguito un aggiornamento continuo della tua distribuzione. Ecco un esempio:

Hai una distribuzione fooe una ConfigMap chiamata foo-configmap. Vuoi eseguire il roll dei pod della distribuzione ogni volta che viene modificata la mappa di configurazione. Devi eseguire Reloader con:

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

Quindi specifica questa annotazione nella tua distribuzione:

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

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

Spesso le mappe di configurazione o i segreti vengono iniettati come file di configurazione nei contenitori. A seconda dell'applicazione potrebbe essere necessario un riavvio nel caso in cui questi vengano aggiornati con un successivohelm upgrade , ma se la specifica di distribuzione stessa non è cambiata, l'applicazione continua a funzionare con la vecchia configurazione risultando in una distribuzione incoerente.

La sha256sumfunzione può essere utilizzata insieme alla includefunzione per garantire che una sezione del modello di distribuzioni venga aggiornata se un'altra specifica cambia:

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

Nel mio caso, per alcuni motivi, $.Template.BasePathnon ha funzionato ma $.Chart.Namefunziona:

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

Puoi aggiornare un'etichetta di metadati che non è rilevante per la tua distribuzione. attiverà un aggiornamento continuo

per esempio:

metadata:
  labels:
    configmap-version: 1

Aveva questo problema in cui la distribuzione era in un sottografico ei valori che la controllavano erano nel file dei valori del grafico principale. Questo è ciò che abbiamo usato per attivare il riavvio:

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

Ovviamente questo attiverà il riavvio su qualsiasi modifica di valore, ma funziona per la nostra situazione. Ciò che era originariamente nel grafico figlio avrebbe funzionato solo se il file config.yaml nel grafico figlio stesso fosse cambiato:

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

Faccio la soluzione dei quanti e funziona perfettamente. Ma quello che non capisco è che il pod in realtà non si riavvia ... Il pod è sempre lo stesso ma il cambiamento c'è!

Ad esempio: il pod è in esecuzione da 50min e cambio qualcosa e il cambiamento è online, posso vederlo sul mio browser e il pod è ancora in esecuzione + 50min !! Sto usando Helm3 ... Sai cosa lo rende possibile senza riavviare l'aggiornamento della configurazione?

Un altro modo è inserirlo nella sezione dei comandi della distribuzione:

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

In alternativa, per renderlo più simile a ConfigMap, usa una distribuzione aggiuntiva che ospiterà semplicemente quella configurazione nella commandsezione ed eseguirà kubectl createsu di essa aggiungendo una 'versione' univoca al suo nome (come calcolare un hash del contenuto) e modificando tutto il distribuzioni che utilizzano quella configurazione:

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

Probabilmente posterò kubectl-apply-config.sh se finisce per funzionare.

(non farlo; sembra troppo brutto)