Pods neu starten, wenn configmap in Kubernetes aktualisiert wird?

Wie starte ich Kubernetes-Pods und Pods, die mit Bereitstellungen verknüpft sind, automatisch neu, wenn ihre Konfigurationszuordnung geändert / aktualisiert wird?

Ich weiß, dass über die Möglichkeit gesprochen wurde, Pods automatisch neu zu starten, wenn sich eine Konfigurationszuordnung ändert, aber meines Wissens ist dies in Kubernetes 1.2 noch nicht verfügbar.

Was ich (glaube ich) tun möchte, ist ein "fortlaufender Neustart" der Bereitstellungsressource , die den Pods zugeordnet ist, die die Konfigurationszuordnung verbrauchen. Ist es möglich und wenn ja, wie Sie einen fortlaufenden Neustart einer Bereitstellung in Kubernetes erzwingen können, ohne etwas an der tatsächlichen Vorlage zu ändern? Ist dies derzeit der beste Weg oder gibt es eine bessere Option?

Das Signalisieren eines Pods bei der Aktualisierung der Konfigurationskarte ist eine Funktion in Arbeit ( https://github.com/kubernetes/kubernetes/issues/22368 ).

Sie können jederzeit eine benutzerdefinierte pid1 schreiben, die feststellt, dass sich die Confimap geändert hat, und Ihre App neu startet.

Sie können z Pod teilen sich den gleichen Netzwerk-Namespace). Das Kubelet startet Ihren ersten Container für Sie neu, wenn die Sonde ausfällt.

Wenn Sie sich nicht darum kümmern, auf welchen Knoten sich die Pods befinden, können Sie sie natürlich einfach löschen, und der Replikationscontroller "startet" sie für Sie neu.

Die derzeit beste Lösung für dieses Problem (auf die in https://github.com/kubernetes/kubernetes/issues/22368 in der Antwort der Geschwister verwiesen wird ) besteht darin, Bereitstellungen zu verwenden und Ihre ConfigMaps als unveränderlich zu betrachten.

Wenn Sie Ihre Konfiguration ändern möchten, erstellen Sie eine neue ConfigMap mit den Änderungen, die Sie vornehmen möchten, und verweisen Sie Ihre Bereitstellung auf die neue ConfigMap. Wenn die neue Konfiguration fehlerhaft ist, weigert sich die Bereitstellung, Ihr funktionierendes ReplicaSet zu verkleinern. Wenn die neue Konfiguration funktioniert, wird Ihr altes ReplicaSet auf 0 Replikate skaliert und gelöscht, und neue Pods werden mit der neuen Konfiguration gestartet.

Nicht ganz so schnell wie das Bearbeiten der ConfigMap, aber viel sicherer.

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

Oft werden Konfigurationskarten oder Geheimnisse als Konfigurationsdateien in Container eingefügt. Abhängig von der Anwendung kann ein Neustart erforderlich sein, wenn diese mit einer nachfolgenden aktualisiert werden. helm upgradeWenn sich jedoch die Bereitstellungsspezifikation selbst nicht geändert hat, wird die Anwendung mit der alten Konfiguration weiter ausgeführt, was zu einer inkonsistenten Bereitstellung führt.

Die sha256sumFunktion kann zusammen mit der includeFunktion verwendet werden, um sicherzustellen, dass ein Abschnitt mit Bereitstellungsvorlagen aktualisiert wird, wenn sich eine andere Spezifikation ändert:

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

In meinem Fall hat es aus bestimmten Gründen $.Template.BasePathnicht funktioniert, aber es $.Chart.Namefunktioniert:

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

Der beste Weg, dies zu tun, ist Reloader auszuführen

Sie können Konfigurationskarten oder Geheimnisse definieren, die überwacht werden sollen. Wenn diese aktualisiert werden, wird eine fortlaufende Aktualisierung Ihrer Bereitstellung durchgeführt. Hier ist ein Beispiel:

Sie haben eine Bereitstellung foound eine ConfigMap aufgerufen foo-configmap. Sie möchten die Pods der Bereitstellung jedes Mal rollen, wenn die Konfigurationszuordnung geändert wird. Sie müssen Reloader ausführen mit:

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

Geben Sie dann diese Anmerkung in Ihrer Bereitstellung an:

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

Sie können eine Metadatenbezeichnung aktualisieren, die für Ihre Bereitstellung nicht relevant ist. Es wird ein fortlaufendes Update ausgelöst

beispielsweise:

metadata:
  labels:
    configmap-version: 1

Hatte dieses Problem, wenn sich die Bereitstellung in einem Unterdiagramm befand und die Werte, die sie steuern, in der Wertedatei des übergeordneten Diagramms waren. Dies ist, was wir verwendet haben, um einen Neustart auszulösen:

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

Dies löst natürlich einen Neustart bei jeder Wertänderung aus, funktioniert jedoch für unsere Situation. Was ursprünglich im untergeordneten Diagramm enthalten war, würde nur funktionieren, wenn die Datei config.yaml im untergeordneten Diagramm selbst geändert würde:

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

Ich mache die Lösung von Quanten und es funktioniert perfekt. Aber was ich nicht verstehe ist, dass der Pod tatsächlich nicht neu startet ... Der Pod ist immer noch derselbe, aber die Änderung ist da!

Zum Beispiel: Der Pod läuft seit 50 Minuten und ich ändere etwas und die Änderung ist online. Ich kann sie in meinem Browser sehen und der Pod läuft noch + 50 Minuten !! Ich verwende Helm3 ... Wissen Sie, was dies ermöglicht, ohne die Aktualisierung der Konfigurationskarte neu zu starten?

Eine andere Möglichkeit besteht darin, es in den Befehlsabschnitt der Bereitstellung einzufügen:

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

Um es ConfigMap-ähnlicher zu machen, verwenden Sie alternativ eine zusätzliche Bereitstellung, die nur diese Konfiguration in dem commandAbschnitt hostet und darauf ausführt kubectl create, während Sie ihrem Namen eine eindeutige 'Version' hinzufügen (z. B. einen Hash des Inhalts berechnen) und alle ändern Bereitstellungen, die diese Konfiguration verwenden:

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

Ich werde wahrscheinlich posten, kubectl-apply-config.shwenn es funktioniert.

(Tu das nicht; es sieht zu schlecht aus)