Pods neu starten, wenn Configmap Updates in Kubernetes?

Question

Ich weiß, es gab Gespräche über die Möglichkeit, Pods automatisch neu zu starten, wenn eine Konfiguration Änderungen zuordnet, aber nach meinem Wissen ist dies in Kubernetes 1.2 noch nicht verfügbar.

Also was (ich denke), ich möchte tun, ist ein "Roll-Neustart" der deployment Ressource mit den Pods die Config-Karte konsumiert. Ist es möglich, und wenn, wie, einen Roll-Neustart einer Bereitstellung in Kubernetes zu erzwingen, ohne etwas in der tatsächlichen Vorlage zu ändern? Ist dies derzeit der beste Weg, oder gibt es eine bessere Option?

Answer 1

Das Signalisieren eines Pods bei der Aktualisierung der Konfig-Map ist ein Feature in Arbeit (https://github.com/kubernetes/kubernetes/issues/22368).

Sie können immer ein benutzerdefiniertes pid1 schreiben, das bemerkt, dass sich die Confimap geändert hat, und die App neu startet.

Sie können zB auch: dieselbe Konfigurationskarte in 2 Container laden, eine HTTP-Statusprüfung im zweiten Container anzeigen, die fehlschlägt, wenn sich der Hash des Konfigurationskarteninhalts ändert, und diese als Liveness-Probe des ersten Containers verschieben (weil Container in einem Pod denselben Netzwerknamespace verwenden). Das Kubelet startet Ihren ersten Container für Sie neu, wenn der Test fehlschlägt.

Natürlich, wenn Sie nicht wissen, auf welchen Knoten die Pods sind, können Sie sie einfach löschen und der Replikationscontroller wird sie für Sie "neu starten".

Answer 2

Die derzeit beste Lösung für dieses Problem (tief in https://github.com/kubernetes/kubernetes/issues/22368 verwiesen in der Geschwisterantwort verknüpft) ist die Verwendung von Bereitstellungen, und betrachten Sie Ihre ConfigMaps als unveränderlich.

Wenn Sie Ihre Konfiguration ändern möchten, erstellen Sie eine neue ConfigMap mit den Änderungen, die Sie vornehmen möchten, und zeigen Sie Ihre Implementierung auf die neue ConfigMap. Wenn die neue Konfiguration fehlerhaft ist, wird die Implementierung Ihr funktionierendes ReplicaSet nicht 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 nur das Bearbeiten der ConfigMap, aber viel sicherer.

Answer 3

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

Oft configmaps oder Geheimnisse werden als Konfigurationsdateien in Containern injiziert. Abhängig von der Anwendung ist möglicherweise ein Neustart erforderlich, wenn diese mit einem nachfolgenden helm upgrade aktualisiert werden. Wenn sich die Implementierungsspezifikation selbst jedoch nicht ändert, wird die Anwendung weiterhin mit der alten Konfiguration ausgeführt, was zu einer inkonsistenten Bereitstellung führt.

Die sha256sum Funktion kann zusammen mit der include Funktion verwendet werden, um einen Deployments Vorlage Abschnitt aktualisiert, um sicherzustellen, wenn ein andere spec Änderungen:

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

In meinem Fall aus irgendwelchen Gründen, $.Template.BasePath nicht funktionieren aber $.Chart.Name tut:

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

Answer 4

Eine andere Möglichkeit ist es in den Befehlsabschnitt des Deployment-Stick:

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

Alternativ ist es mehr ConfigMap artig zu machen, eine zusätzliche Deployment verwenden, die genau das config in der command Abschnitt hosten und kubectl create auf sie ausführen, während eine einzigartige ‚Version‘ fügt seinem Namen (wie Berechnen eines Hash der Inhalt) und Modifizieren alle Installationen, die diese Konfiguration verwenden:

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

ich wahrscheinlich kubectl-apply-config.sh veröffentlichen werde, wenn sie arbeiten endet.