cc @ironcladlou @bgrant0607

Was ist der Anwendungsfall für den Neustart der Pods ohne Änderungen an der Spezifikation?

Beachten Sie, dass es keine Möglichkeit gibt, die Änderung rückgängig zu machen, wenn Pods beim Neustart fehlgeschlagen sind.

Immer wenn Dienste in einen eingeklemmten oder unerwünschten Zustand geraten (Verbindungen ausgereizt und jetzt blockiert, schlechter interner Zustand usw.). Dies ist normalerweise einer der ersten Schritte zur Fehlerbehebung, wenn sich ein Dienst ernsthaft schlecht benimmt.

Wenn der erste Pod beim Neustart fehlschlägt, würde ich erwarten, dass er nicht mehr fortgesetzt wird oder erneut versucht, den Pod zu starten.

Außerdem werden bei einem fortlaufenden Neustart ohne Änderung der Spezifikationen die Pods im gesamten . neu zugewiesen
Cluster.

Ich hätte aber auch gerne die Möglichkeit, dies zu tun, ohne den Termin zu verschieben
Schoten. Das könnte ein fortlaufender Etikettenwechsel sein, aber möglicherweise eine neue Dynamik erhalten
config oder löschen Sie den lokalen Dateistatus.

Am Mittwoch, den 2. September 2015 um 00:01 Uhr schrieb Sam Ghods [email protected] :

Immer wenn Dienste in einen eingeklemmten oder unerwünschten Zustand geraten (maximal ausgereizt)
Verbindungen und sind jetzt blockiert, schlechter interner Zustand usw.). Es ist normalerweise
einer der ersten Schritte zur Fehlerbehebung, wenn der Service ernst ist
sich schlecht benehmen.

Wenn der erste Pod beim Neustart fehlschlägt, würde ich erwarten, dass er aufhört
fortfahren oder erneut versuchen, den Pod zu starten.

—
Antworten Sie direkt auf diese E-Mail oder zeigen Sie sie auf GitHub an
https://github.com/kubernetes/kubernetes/issues/13488#issuecomment -136931790
.

Clayton Coleman | Leitender Ingenieur, OpenShift

@smarterclayton Ist das meine oben aufgeführte Option 2? Aber warum sollten Etiketten geändert werden?

Betreff. Keil: Dafür gibt es Lebendigkeitssonden.

Betreff. Rebalancing: siehe #12140

Wenn wir dies unterstützen würden, würde ich es mit #9043 in einen Topf werfen – der gleiche Mechanismus ist erforderlich.

Ich nehme an, dies wäre eher für eine Situation, in der der Pod lebendig ist und auf Überprüfungen reagiert, aber noch neu gestartet werden muss. Ein Beispiel ist ein Dienst mit einem In-Memory-Cache oder einem internen Zustand, der beschädigt wird und gelöscht werden muss.

Ich habe das Gefühl, dass die Aufforderung zum Neustart einer Anwendung ein ziemlich häufiger Anwendungsfall ist, aber vielleicht liege ich falsch.

Korruption wäre nur eine Kapsel, die einfach getötet und durch die RC ersetzt werden könnte.

Der andere offline erwähnte Fall war das erneute Lesen der Konfiguration. Dies ist implizit gefährlich, da Neustarts aus irgendeinem Grund dazu führen würden, dass Container die neue Konfiguration laden. Es wäre besser, ein Rolling Update durchzuführen, um eine neue versionierte Konfigurationsreferenz (zB in einer env var) auf die Pods zu übertragen. Dies ist vergleichbar mit dem, was #1353 motiviert hat.

@ bgrant0607 haben wir uns entschieden, dass wir dies nicht tun wollen?

@gmarek Im

Können wir einen post v1.1 Meilenstein (oder so) für die Dinge haben, die wir für wichtig erachten, aber es fehlen uns Leute, die sie sofort reparieren?

Ich wäre auch ein Fan dieser Funktion, Sie möchten nicht gezwungen sein, bei jedem kleinen Update, das Sie ausrollen möchten, die Tags zu wechseln.

Ich bin ein Fan dieser Funktion. Anwendungsfall: Aktualisieren Sie ganz einfach alle Pods, um ein neu gepushtes Docker-Image (mit imagePullPolicy: Always ) zu verwenden. Ich verwende derzeit eine etwas hackige Lösung: Rolling-Update mit oder ohne das :latest Tag im Bildnamen.

Ein weiterer Anwendungsfall: Aktualisieren von Geheimnissen.

Diese Funktion würde ich sehr gerne sehen. Wir führen Node-Apps auf Kubernetes aus und haben derzeit bestimmte Anwendungsfälle, in denen wir Pods neu starten, um sie im App-Pseudo-Caching zu löschen.

Folgendes mache ich derzeit:

kubectl get pod | grep 'pod-name' | cut -d " " -f1 - | xargs -n1 -P 10 kubectl delete pod

Dies löscht Pods 10 auf einmal und funktioniert gut in einem Replikationscontroller-Setup. Bedenken wie die Pod-Zuweisung oder das Fehlschlagen neuer Pods werden nicht berücksichtigt. Bei Bedarf eine schnelle Lösung.

Ich würde wirklich gerne einen Rolling Restart machen können.
Der Hauptgrund ist, dass wir ENV-Variablen mithilfe von ConfigMap in Pods einspeisen und dann, wenn wir die Konfiguration ändern, die Verbraucher dieser ConfigMap neu starten müssen.

Ja, es gibt viele Fälle, in denen Sie den Pod/Container wirklich ohne Änderungen neu starten möchten ...
Configs, Cache, Reconnect zu externen Diensten, etc. Ich hoffe wirklich, dass das Feature weiterentwickelt wird.

Kleine Problemumgehung (ich verwende Bereitstellungen und möchte Konfigurationen ändern, ohne echte Änderungen im Image/Pod zu haben):

• configMap erstellen
• Erstellen Sie ein Deployment mit der ENV-Variable (Sie verwenden es als Indikator für Ihr Deployment) in einem beliebigen Container
• configMap aktualisieren
• Bereitstellung aktualisieren (diese ENV-Variable ändern)

k8s erkennt, dass die Definition der Bereitstellung geändert wurde und beginnt mit dem Ersetzen der Pods
PS:
Wenn jemand eine bessere Lösung hat, bitte teilen

Danke @paunin

@paunin Genau dort, wo wir es gerade brauchen - Wir müssen ConfigMap-Werte ändern, die für die Dienste sehr wichtig sind und innerhalb von Minuten bis einigen Stunden auf die Container ausgerollt werden müssen. Wenn in der Zwischenzeit keine Bereitstellung erfolgt, werden alle Container gleichzeitig ausfallen und wir haben eine teilweise Ausfallzeit von mindestens einigen Sekunden

from (irgendwie verwandt #9043): ein Einzeiler von RESTART_ die Umgebungsvariable ist und auf einen ISO-Zeitstempel gesetzt ist:

kubectl patch deployment mydeployment \
-p'{"spec":{"template":{"spec":{"containers":[{"name":"mycontainer","env":[{"name":"RESTART_","value":"$(date -uIseconds)"}]}]}}}}'

(Beachten Sie, dass Umgebungsvariablen, die mit _ einfach zu verschwinden scheinen und numerische env value s Fehler verursachen, sie müssen Strings sein)

@paunin @rcoup Wir machen heutzutage etwas sehr Ähnliches, wir haben eine env var, die wörtlich "DUMMY_VAR_FOR_NO_OP_DEPLOYMENT" heißt.

Es fühlt sich an, als würde die richtige Lösung hier es Ihnen ermöglichen, eine Bereitstellung neu zu starten und die meisten Bereitstellungsparameter für Rollouts wie MinReadyCount wiederzuverwenden, während Befehlszeilenüberschreibungen wie die Erhöhung der Parallelität für Notfallsituationen ermöglicht werden, in denen alles sofort abprallen muss.

irgendwelche Fortschritte diesbezüglich?

Ich habe das Gefühl, dass diese Ergänzung die CLI-API unnötig aufbläht. Dies kann leicht erreicht werden, indem die Werte der Bereitstellungsumgebungsvariablen wie von @paunin vorgeschlagen aktualisiert werden .

Wir würden dies auch gerne für Bereitstellungen wie kubectl restart deployment some-api

Kubernetes darf Pods aus allen möglichen Gründen neu starten, der Cluster-Administrator jedoch nicht.
Ich verstehe den moralischen Standpunkt, dass "aus- und wieder einschalten" möglicherweise nicht die gewünschte Vorgehensweise ist ... aber ich denke auch, dass es in Ordnung sein sollte, die Leute, die dies wünschen, eine Bereitstellung neu starten zu lassen, ohne auf die Reichweite zurückzugreifen von weniger appetitlichen Tricks wie:

• Pods löschen
• Dummy-Etiketten
• Dummy-Umgebungsvariablen
• Dummy-Konfigurationszuordnungen, die der Umgebungsvariablen zugeordnet sind
• Neustart der Worker-Knoten
• Stromausfall im Rechenzentrum

'Nein, nein, ich starte nichts neu, korrigiere hier nur einen Tippfehler in diesem Etikett' 😛

Diese Funktion ist in Kombination mit kubectl apply nützlich: apply aktualisiert Konfigurationen, einschließlich Replikationscontroller, aber Pods werden nicht neu gestartet.

Wir brauchen also eine Methode, um diese Pods blau-grün neu zu starten.

@DmitryRomanenko, wie wäre es mit einem Wechsel von ReplicationControllers zu Deployments? Dadurch können Sie Updates von ReplicaSets (Nachfolger von ReplicationController) ausführen.

@kargakis es ist nicht möglich: Bereitstellungen aktualisieren nur Replikatsätze und Pods.
Mit kubectl apply aktualisieren wir auch ConfigMaps, Services usw.

@DmitryRomanenko Wenn das Problem lautet "Ich möchte Pods neu starten, wenn ConfigMap/Secret aktualisiert wird", besteht eine mögliche Lösung darin, Versionen für Ihre ConfigMap und Secrets zu haben und diese Version zu einem Teil Ihrer Bereitstellungsspezifikation zu machen. Mit kubectl apply ing wird also die Spezifikation des Deployments geändert und Pods werden neu erstellt.
In anderen Situationen sehe ich nicht, warum Pods neu gestartet werden müssen (ich meine Service/Ingress/etc-Update).

@tyranron , danke! Was ist der beste Weg, um ConfigMap s zu versionieren? Sollte ich eine neue Konfigurationszuordnung mit einem anderen Namen für die neue Bereitstellung erstellen?

@DmitryRomanenko kannst du eigentlich, warum nicht? Aber in diesem Fall sollten Sie darauf achten, alte zu entfernen. Andererseits kann es für Rollbacks nützlich sein. In den meisten Fällen reicht es jedoch aus, die Version über Labels anzugeben.

Ich glaube, dass die beste Lösung hier eine Art Watcher oder Hash-Summen-Checker für das configmap Objekt sein könnte. Was einen Neustart von verwandten Objekten/Pods auslösen sollte (alles verwendet das configmap , secret ). Ich bin mir jedoch nicht sicher, ob es in der Architektur von k8s zugänglich ist ...

Ich denke auch, dass es besser ist, die Kontrolle über das configmap|secret Objekt zu haben, um bei Änderungen einen Neustart auszulösen oder nicht.

@tyranron ,

Mit der Anwendung von kubectl wird die Spezifikation des Deployments geändert und Pods werden neu erstellt.

Könntest du erklären? Sollte ich nur kubectl apply -f new_config.yml mit aktualisierten Bereitstellungen verwenden und diese Bereitstellungen werden fortlaufend neu gestartet?

@DmitryRomanenko ja , genau.

@DmitryRomanenko mit dem Anwenden neuer Spezifikationen aktualisieren Sie Deployment , und beim Deployment-Update wird ein Neustart ausgelöst, wenn die Spezifikation geändert wurde.

Standardmäßig ist die Neustartstrategie RollingUpdate , Sie können jedoch auch eine andere explizit angeben.

Die Probleme veralten nach 90 Tagen Inaktivität.
Markieren Sie das Problem mit /remove-lifecycle stale .
Abgestandene Ausgaben verrotten nach weiteren 30 Tagen Inaktivität und werden schließlich geschlossen.

Verhindern Sie das automatische Schließen von Problemen mit einem /lifecycle frozen Kommentar.

Wenn dieses Problem jetzt sicher geschlossen werden kann, tun Sie dies bitte mit /close .

Senden Sie Feedback an sig-testing, kubernetes/test-infra und/oder @fejta .
/Lebenszyklus veraltet

Eine kleine Änderung an der Lösung von Stellen Sie sicher, dass date innerhalb der Shell ausgewertet wird:

kubectl patch deployment mydeployment -p '{"spec":{"template":{"spec":{"containers":[{"name":"mycontainer","env":[{"name":"RESTART_","value":"'$(date +%s)'"}]}]}}}}'

/Remove-Lifecycle-Stale
/Lebenszyklus eingefroren

Ich verwende seit einiger Zeit den Schwarmmodus, der als weniger flexibel als Kubernetes gilt, und kann Dienstaufgaben (sprich: Bereitstellungs-Pods) neu starten, indem ich einfach ein erzwungenes Update (ohne Änderung der Spezifikationen) wie in docker service update --force <service-name> . Ich würde erwarten, dass Kubernetes dies auch tut.
Was Configmaps und Secrets angeht, erlaubt swarm Ihnen nicht, diese zu bearbeiten, Sie müssen sie stattdessen rotieren. Sie tun dies, indem Sie neue configmaps/secrets erstellen, die Service-Spezifikation aktualisieren, um die neuen zu verwenden, und dann die älteren löschen. Ich sehe, dass dies in der Regel oben empfohlen wird, indem Sie Ihre configmaps/secrets versionieren und die Bereitstellungen aktualisieren, die sie verwenden. Um ehrlich zu sein, ist dieses Rotationsverhalten einer der Hauptgründe, warum ich den Schwarm verlassen habe! Es ist sehr unpraktisch, eine lokale Kopie zu haben, zu aktualisieren, dann neue Ressourcen zu erstellen und schließlich die abhängigen Ressourcen zu aktualisieren. Hinzu kommt, dass Geheimnisse in swarm nicht von der API gelesen werden können, Sie müssen sie in einen beliebigen Container einhängen (oder in einen Container, der sie verwendet), dann cat ihre Dateien.
In einem diesbezüglichen Hinweis habe ich Openshift für einige Zeit verwendet und glaube, dass es Pods bei env/configmap/secret change automatisch neu startet. Ich stehe aber korrigiert.

sollte die Verantwortung der App sein, das Dateisystem auf Änderungen zu überwachen. Wie bereits erwähnt, können Sie Prüfsummen in der configmap/geheimnis verwenden und auf diese Weise Neustarts erzwingen

aber wenn Sie die Konfiguration überhaupt nicht ändern und nur einen rollenden Neustart mit beliebiger Pause durchführen möchten, erledigt eine einfache Pipeline die Aufgabe (diese schläft 30 Sekunden zwischen beendetem Pod).

kubectl get po -l release=my-app -o name | cut -d"/" -f2 | while read p;do kubectl  delete po $p;sleep 30;done

Beachten Sie, dass es nicht einfach ist, dort neu zu starten, wo Sie aufgehört haben, wenn Sie Strg+C drücken

@so0k , alternativer Befehl:

kubectl get pods|grep somename|awk '{print $1}' | xargs -i sh -c 'kubectl delete pod -o name {} && sleep 4'

Zweieinhalb Jahre später arbeiten die Leute immer noch an neuen Problemumgehungen, mit Dummy-Env-Variablen, Dummy-Labels, ConfigMap- und Secret-Watcher-Sidecars, Skalierung auf Null und direkten Rolling-Update-Shell-Skripten, um die Fähigkeit zu simulieren, ein Rolling Update auszulösen. Ist das immer noch etwas, was Cluster-Admins ohne die Tricks ehrlich gesagt nicht tun dürfen?

27081 #33664 https://github.com/kubernetes/helm/issues/2639

https://stackoverflow.com/questions/41735829/update-a-deployment-image-in-kubernetes

kubectl scale --replicas=0 deployment application
kubectl scale --replicas=1 deployment application

https://stackoverflow.com/questions/40366192/kubernetes-how-to-make-deployment-to-update-image

Ein weiterer Trick besteht darin, zunächst auszuführen:

kubectl set image deployment/my-deployment mycontainer=myimage:latest

und dann:

kubectl set image deployment/my-deployment mycontainer=myimage

Es wird tatsächlich das Rolling-Update auslösen, aber stellen Sie sicher, dass Sie auch imagePullPolicy: "Always" gesetzt haben.

Ein weiterer Trick, den ich gefunden habe, bei dem Sie den Bildnamen nicht ändern müssen, besteht darin, den Wert eines Felds zu ändern, das ein fortlaufendes Update auslöst, wie z. B. TerminationGracePeriodSeconds. Sie können dies mit kubectl edit deploy your_deployment oder kubectl apply -f your_deployment.yaml oder mit einem Patch wie diesem tun:

kubectl patch deployment your_deployment -p \
  '{"spec":{"template":{"spec":{"terminationGracePeriodSeconds":31}}}}'

http://rancher.com/docs/rancher/v1.4/en/cattle/upgrading/

# Force an upgrade even though the docker-compose.yml for the services didn't change
$ rancher-compose up --force-upgrade

@so0k @KIVagant Das Löschen von Pods bedeutet Ausfallzeiten, selbst wenn mehrere Instanzen ausgeführt werden. Wenn jemand einen einzelnen Pod mit strategy.rollingUpdate.maxUnavailable = 0 ausführt, erstellt eine reguläre Bereitstellung zuerst einen neuen Pod, bevor der vorhandene Pod beendet wird. Der Trick kubectl patch deployment löst dieses Verhalten aus, das Löschen von Pods nicht. Ich würde wirklich gerne eine nicht-hackige Möglichkeit haben, dieses Verhalten bei Bedarf auszulösen.

Wenn Sie beispielsweise Images von hub.docker.com ausführen, kann dasselbe Tag für Sicherheitsupdates gepatcht werden. Ich würde gerne "die neuesten Bilder abrufen" und ein fortlaufendes Update für alle veralteten Bilder durchführen.

Rollout von ConfigMap/Secret-Updates ist #22368
Einfacherer Rollout neuer Bilder ist #1697
In-place Rolling Updates ist #9043

Neustart bei Image-Builds: https://github.com/GoogleCloudPlatform/freshpod
Helm-Gipfel-Präsentation eines Tricks mit einer vorlagenbasierten Anmerkung zum Auslösen von Bereitstellungs-Rollouts: https://www.youtube.com/watch?v=dSw0w1x96ak

@bgrant0607 Ich denke, der wichtige Anwendungsfall, der nicht von anderen Tickets abgedeckt wird, ist dieser: https://github.com/kubernetes/kubernetes/issues/13488#issuecomment -136946912

@ghodss schrieb:
Ich nehme an, dies wäre eher für eine Situation, in der der Pod lebendig ist und auf Überprüfungen reagiert, aber noch neu gestartet werden muss. Ein Beispiel ist ein Dienst mit einem In-Memory-Cache oder einem internen Zustand, der beschädigt wird und gelöscht werden muss.

Ich habe das Gefühl, dass die Aufforderung zum Neustart einer Anwendung ein ziemlich häufiger Anwendungsfall ist, aber vielleicht liege ich falsch.

Ich möchte einen fortlaufenden Neustart erzwingen, um den gesamten Anwendungsstatus ohne manuelle Tricks zu löschen.

Ich habe einen ähnlichen Einzeiler , der auf dem von @rcoup und @paunin beschriebenen Ansatz

kubectl-restart() {
  kubectl get deploy $1 -o json | jq \
    'del(
      .spec.template.spec.containers[0].env[]
      | select(.name == "RESTART_"))
    | .spec.template.spec.containers[0].env += [{name: "RESTART_", value: now|tostring}]' | kubectl apply -f -
}

Dies erlaubt mir einfach zu sagen: kubectl-restart my-deployment-name und es wird die RESTART_ env var im ersten Container auf den aktuellen Zeitstempel "aktualisieren". Ich bin weit davon entfernt, ein jq-Experte zu sein, daher gibt es möglicherweise einen besseren Weg, aber im Grunde löscht es die alte RESTART_ env var aus der Ausgabe (falls vorhanden) und fügt sie dann wieder mit dem hinzu aktuelle Uhrzeit.

Es fühlt sich für mich jedoch sehr seltsam an, dass es keine native Möglichkeit gibt, dies zu tun ... Sicherlich würde ein Raum voller Ingenieure zustimmen, dass die Möglichkeit, ihn aus- und wieder einzuschalten, etwas ist, was wir gerne hätten.

Das ist ein guter Hack und alles, aber es hat einen großen Nachteil. Bei der nächsten Bereitstellung mit kubectl apply -f wird diese Komponente neu gestartet, wenn sie eine RESTART_xxx env var hat, auch wenn sich sonst nichts ändert. Mit anderen Worten, es verursacht falsche Neustarts bei der nächsten Bereitstellung, wenn es zwischen der letzten Bereitstellung und dieser Bereitstellung jemals neu gestartet wurde. Nicht ideal...

Aus diesem Grund sollte die Rolling-Restart-Funktionalität in den Deployment-Controller integriert und nicht darauf aufgebaut werden.

Ich habe eine Bash-Funktion geschrieben, um die Strategie "Patch-Bereitstellung von terminationGracePeriodSeconds " durchzuführen, die Kommentar zitiert hat (Quelle: https://stackoverflow.com/a/40368520/90442).

# $1 is a valid namespace
function refresh-all-pods() {
  echo
  DEPLOYMENT_LIST=$(kubectl -n $1 get deployment -o json|jq -r .items[].metadata.name)
  echo "Refreshing pods in all Deployments"
  for deployment_name in $DEPLOYMENT_LIST ; do
    TERMINATION_GRACE_PERIOD_SECONDS=$(kubectl -n $1 get deployment "$deployment_name" -o json|jq .spec.template.spec.terminationGracePeriodSeconds)
    if [ "$TERMINATION_GRACE_PERIOD_SECONDS" -eq 30 ]; then
      TERMINATION_GRACE_PERIOD_SECONDS='31'
    else
      TERMINATION_GRACE_PERIOD_SECONDS='30'
    fi
    patch_string="{\"spec\":{\"template\":{\"spec\":{\"terminationGracePeriodSeconds\":$TERMINATION_GRACE_PERIOD_SECONDS}}}}"
    kubectl -n $1 patch deployment $deployment_name -p $patch_string
  done
  echo
}

Kommentieren / aktualisieren Sie es über das Wesentliche hier . Ich werde die Kommentare anderer wiederholen, dass es besser wäre, wenn dies nicht notwendig wäre.

Nur als eine spezifischere kube-bezogene Begründung ermöglicht Neustart auch das erneute Ausführen eines Init-Containers, der verwendet werden kann, um Schlüssel zu rollen, die Konfiguration zu aktualisieren oder was auch immer Sie init-Container verwenden.

@ kubernetes / sig-apps-feature-requests @ kow3ns @janetkuo

@gjcarneiro Hatten Sie eine RESTART_xxx env var in der Konfiguration, die Sie angewendet haben, oder nicht? Wenn nicht, würde ich erwarten, dass apply die zusätzliche env var im Live-Zustand ignoriert.

cc @apelisse

@gjcarneiro Ja, das Problem mit dem @mattdodge- Skript besteht darin, dass es apply verwendet, sodass die Änderung in der Anmerkung lastApplied gespeichert wird. Das Skript könnte mithilfe eines Patches oder einer anderen Methode zum Aktualisieren der Bereitstellung behoben werden.

Hätte diese Funktion gerne. Es scheint sehr einfach und notwendig.

Kein Fortschritt hier noch auf #22368, le seufz :-(

Kann jemand eine schnelle und schmutzige Lösung empfehlen, um ein DaemonSet neu zu starten, nachdem die gemountete ConfigMap aktualisiert wurde (Name ist immer noch identisch)?

@alcohol , überprüfen Sie diese https://github.com/kubernetes/kubernetes/issues/13488#issuecomment -356892053

Danke für den Tipp :-)

Openshift hat das Konzept von Deployment-Triggern, die einen Rollout bei Imagewechsel, Webhook oder Konfigurationsänderung auslösen. Es wäre eine sehr gute Funktion in Kubernetes zu haben. Natürlich auch manuelle Rollouts.

Darüber hinaus hat das Docker-Repository eine Historie, so dass es keinen Grund gibt, warum ein Rollback nicht funktionieren könnte - Pods, die aus .spec.template können das image-tag:@digest Format verwenden, wenn Bilder für Container abgerufen werden. Rollback würde die Digest-ID des vorherigen Rollouts verwenden.

Bin mir nicht sicher ob ich das richtig verstehe. Nur falls das jemandem hilft.

Es scheint, dass, wenn Sie den Wert eines Labels unter Pod > Vorlage > Metadaten aktualisieren, eine fortlaufende Aktualisierung stattfindet, nachdem Sie kubectl apply -f file.yaml

So können Sie immer ein Label für Ihre Version haben und wann immer Sie ein Rolling Update durchführen möchten, die Version ändern und die Datei anwenden.

Sicher, der Nachteil ist, dass Sie das nächste Mal, wenn Sie eine Bereitstellung durchführen möchten, kubectl apply -f some.yaml tun, oder? Wenn sich in some.yaml nichts ändert, wird normalerweise nichts neu gestartet, das ist eines der schönsten Dinge an Kubernetes.

Aber stellen Sie sich vor, was passiert, nachdem Sie eine Bezeichnung geändert haben, um eine Bereitstellung neu zu starten. Bei der nächsten normalen Softwarebereitstellung führen Sie wie üblich kubectl apply -f some.yaml , aber da die yaml-Datei nicht dieselbe Bezeichnung enthält, wird die Bereitstellung unnötigerweise neu gestartet.

@gjcarneiro Wenn Sie apply nicht tun, wenn Sie eine Änderung vornehmen, wird die Anmerkung kubectl.kubernetes.io/last-applied-configuration nicht aktualisiert, sodass das nächste apply keinen weiteren Neustart verursacht.

Ich bin nachdrücklich dafür, kubectl einen Rolling-Restart-Befehl hinzuzufügen, aber in der Zwischenzeit verwende ich Folgendes (basierend auf den obigen Lösungen):

kubectl patch deployment mydeployment -p '{"spec":{"template":{"spec":{"containers":[{"name":"mycontainer","env":[{"name":"RESTART_","value":"'$(date +%s)'"}]}]}}}}'

Parametrieren Sie dies und fügen Sie es als Funktion in Ihre .bashrc ein und es ist eine gute Zwischenlösung.

Ah cool, das wusste ich nicht, danke!

Ich brauche den Bash-Alias ​​nicht, in meiner Firma haben wir mein eigenes Webinterface für die Verwaltung von Kubernetes mit Python + aiohttp erstellt und es verwendet bereits Patch. Ich dachte über Open Sourcing nach, war nur faul...

Es sieht so aus, als würden die Leute in diesem Thread die gleichen Problemumgehungslösungen wiederholen - bitte lesen Sie den vollständigen Thread, bevor Sie hier posten

@joelittlejohn Ich habe Ihr Makro ausgeführt und es hat einen Neustart meiner Pods ausgelöst, aber sie wurden alle gleichzeitig neu gestartet. Ich dachte, das würde einen rollierenden Neustart auslösen, nicht wahr?

@Macmee Dies hängt von der Konfiguration Ihrer Bereitstellung ab. Der obige Befehl ändert nur die Bereitstellung. Die Pods werden dann gemäß dem von Ihrer Bereitstellung definierten Rollout strategy aktualisiert. Dies ist wie jede andere Änderung an der Bereitstellung.

Dies kann nur alle Pods gleichzeitig ersetzen, wenn Ihr .spec.strategy.rollingUpdate.maxUnavailable zulässt.

Wir brauchen diese Funktion auch irgendwie. Ein Anwendungsfall auch auf unserer Seite ist, dass wir spring-cloud-config-server, unterstützt von und scm, für unsere Spring-Boot-App verwenden. Wenn wir eine Konfigurationseigenschaft ändern, muss die Spring-Boot-App neu gestartet werden, um die neue Konfigurationsänderung abrufen zu können. Daher benötigen wir auch diesen eleganten Neustart-Trigger ohne erneute Bereitstellung.

@japzio Wie von Helm vorgeschlagen , ist eine Prüfsumme der configmap in den Anmerkungen eine gute Möglichkeit, diesen Fall zu behandeln.

Gab es hierzu ein Update? Wir suchen diese Funktion auch. @bgrant0607 @nikhiljindal

@bholagabbar-mt Was ist Ihr Anwendungsfall?

cc @kow3ns @janetkuo

@bgrant0607 @kow3ns @janetkuo Der Anwendungsfall für unsere Systeme ist vielfältig.

1. Aktualisierung der Geheimnisse - Ich bin sicher, Sie wissen, dass es viele Unternehmen wie meines gibt, die ihre eigenen Abstraktionen über Kubernetes erstellt haben. Wir verfügen über ein eigenes Container-Management-System, das über Kubernetes orchestriert wird. Daher sind der Kommentar zum geheimen Vorschlag des

2. Dies ist etwas kompliziert, aber der Gesamtumfang besteht, wie jemand vorgeschlagen hat, darin, anormales Verhalten zu beheben. Wir haben 4-5 schwere Java-Apps, die auf dem Play-Framework ausgeführt werden. Wir stoßen auf eine Situation, in der der Speicherverbrauch unserer Java-Pods linear ansteigt und die Pods dann neu startet, wenn das Speicherlimit erreicht ist. Dies ist ein dokumentiertes Java-Problem mit einem Stackoverflow-Problem und einem damit verbundenen Kubernetes- Problem . Ein rollierender Neustart aller Pods in einem Zeitraum von 3-4 Stunden würde den Speicherverbrauch zurücksetzen und unseren Apps ermöglichen, reibungslos ohne Spitzen zu funktionieren.

Hoffentlich war das überzeugend genug und kann dieses Feature von jemandem für die Entwicklung aufgegriffen werden?

@bholagabbar-mt ändere einfach eine Umgebungsvariable und es wird ein Rolling Deploy ausgelöst:

kubectl patch deployment mydeployment -p '{"spec":{"template":{"spec":{"containers":[{"name":"mycontainer","env":[{"name":"LAST_MANUAL_RESTART","value":"'$(date +%s)'"}]}]}}}}'

@montanaflynn Das ist perfekt. Wir haben diese Änderung heute selbst in unsere Systeme integriert und sie läuft einwandfrei. Danke vielmals!

cc @huzhengchuan

Ein weiterer Anwendungsfall dafür: Aufgrund eines Sicherheitsproblems in containerd möchte ich alle Pods neu starten. https://seclists.org/oss-sec/2019/q1/119 Entweder geht der Cluster vollständig aus oder er führt einen rollierenden Neustart durch. Ein Neustartbefehl würde einen großen Unterschied machen!

Update , Problemumgehung:

kubectl set env --all deployment --env="LAST_MANUAL_RESTART=$(date +%s)" --namespace=...
kubectl set env --all daemonset --env="LAST_MANUAL_RESTART=$(date +%s)" --namespace=...

@realfresh Sie sind die Best Practices. füge annotation:{creatTime: 12312312} in Rancher hinzu!

kubectl set env deployment mydeployment --env="LAST_RESTART=$(date)" --namespace ...

scheint ein minimaler Befehl zu sein, der die Arbeit für eine Bereitstellung erledigt. Es ist ein Beispiel für die Verwendung der imperativen Konfiguration.

cc @monopole @apelisse

\ Zwei \ Dreieinhalb Jahre und Menschen neue Abhilfen sind noch Handwerk, mit Dummy - env vars, Dummy - Etikett, Dummy -

Rollierende Updates sind immer noch eine ziemlich beliebte Aktivität für etwas, das anscheinend keinen Anwendungsfall hat 😄

Langzeit-Problem (Notiz an sich selbst)

1. Ich sehe keine Möglichkeit, dies zu tun, ohne die zwingende Logik in eine deklarative API einfließen zu lassen, wodurch unsere Konvention gebrochen wird, die APIs deklarativ zu halten und zwingendes Verhalten in den Controllern zu implementieren und Inkompatibilitäten mit den meisten CI/CD-Praktiken einzuführen.
2. Ich könnte mir eine RollingRestart-API und einen Controller vorstellen, bei denen die Erstellung einer RollingRestart-Ressource dazu führte, dass der Controller die Pods 1 nach 1 per Räumung neu startete (und damit die Unterbrechungsbudgets respektiert), aber ein solcher Controller könnte als CRD implementiert werden (dh ich verstehe den Grund dafür) wir müssen dies im Baum tun).
3. Der deklarative Ansatz, zB das Hinzufügen einer lastRestartedAt=TIMESTAMP-Annotation, scheint mir kein Hack zu sein.
4. Wenn jemand ein deklaratives Design und einen Beitrag zur Implementierung dieser Funktion (in einem Baum oder auf andere Weise) anbieten möchte, erwägen Sie bitte, eine KEP-PR gegen das Erweiterungsrepo zu verfassen. Wenn eine deklarative, integrierte Implementierung entworfen werden kann, würde ich mich freuen, die APIs für Arbeitslasten zu überprüfen / zu unterstützen. Wenn ein CRD-Controller wie [2] angeboten wird, könnten wir ihn in SIG Apps als von der Community gesponserte Erweiterung sponsern.

Der deklarative Ansatz, zB das Hinzufügen einer lastRestartedAt=TIMESTAMP-Annotation, scheint mir kein Hack zu sein.

Es ist kein Hack, es sollte nur eine Kurzbefehlszeile dafür geben.

Jemand könnte ein Krew- Plugin bauen, das den Patch sendet. kubectl restart-deployment <deployment_name> ?

kubectl rollout restart das ein Deployment/Daemonset/Statefulset patcht, um einen neuen 'Rollout' auszulösen?

Dies entspricht dem Ansatz von kubectl rollout Befehlen gestartet haben, ansehen/anhalten/fortsetzen können.

@whereisaaron Ich werde sehen, ob ich dafür einen Patch senden kann (Wortspiel nicht beabsichtigt)

Für das Ausrollen neuer Secrets und Configmaps lautet meine Empfehlung immer noch #22368: Neue erstellen. Damit ist sowohl die Kontrolle des Rollouts als auch das Rollback möglich. Wir müssen nur die GC von alten Objekten beenden:
https://github.com/kubernetes/community/pull/1163
https://github.com/kubernetes/community/pull/2287

Die Dokumentation und/oder Unterstützung (in kustomize, kubectl oder einem kubectl-Plugin) ist jedoch sinnvoll, um einen rollierenden Neustart mit der vorhandenen API durchzuführen.

cc @monopole

Für neue Images, CI/CD oder einen Controller, der Tags zum Verdauen auflöst: #1697.

Das Verschieben unglücklicher Pods sollte vom Descheduler (https://github.com/kubernetes-incubator/descheduler) oder etwas Ähnlichem durchgeführt werden, der Containerstatus, Kernmetriken und sogar benutzerdefinierte Metriken verbrauchen könnte:

https://github.com/kubernetes/community/blob/master/contributors/design-proposals/scheduling/rescheduler.md
https://github.com/kubernetes/community/blob/master/contributors/design-proposals/scheduling/rescheduling.md

Außerdem offizielle Dokumentation zum Umgang mit Geheimnissen und configmap: https://kubectl.docs.kubernetes.io/pages/app_management/secrets_and_configmaps.html

Rolling Restart ist dringend erforderlich. Ein Beispiel ist, dass wir alle Geheimnisse von SSM von AWS erhalten. Wenn wir ein Geheimnis von SSM ändern, möchten wir einen rollierenden Neustart durchführen, damit die Pods jetzt beim Booten das Neueste abrufen. Manchmal gibt es auch Anwendungsprobleme, die einen rollenden Neustart erfordern, bis die tatsächliche Fehlerbehebung in der Produktion landet.

OK, kubectl rollout restart wurde zusammengeführt!

Das ist toll zu hören nach fast 4 Jahren, danke!

Ich glaube, dass die zusammengeführte PR nur Bereitstellungen unterstützt, ist das richtig?

Einige Leute in dieser Ausgabe haben die Notwendigkeit geäußert, auch Daemonsets und Statefulsets neu zu starten.

@apelisse gibt es auch eine Möglichkeit, dies über das SDK oder nur über kubectl zu tun?

@e-nikolov Was ist das SDK?

Ich meinte den Go-Client, der verwendet werden kann, um aus Go-Programmen mit Kubernetes zu kommunizieren.

Nein, Sie müssten die (sehr einfache) Logik, die in kubectl implementiert ist, neu implementieren.

OK, der Neustart von kubectl rollout wurde zusammengeführt!

Welche kubectl Version wird es haben?

Welche kubectl-Version wird es haben?

Kubernetes 1.15

Unser GKE-Cluster im "Rapid"-Release-Channel hat sich selbst auf Kubernetes 1.16 aktualisiert und jetzt funktioniert kubectl rollout restart mehr:

kubectl rollout Bereitstellung neu starten myapp
Fehler: Unbekannter Befehl "Bereitstellung myapp neu starten"

@nikhiljindal fragte vor

Ich weiß, dass wir die Bereitstellung mit früheren Modelldateien nicht einfach zurücksetzen können, aber das ist der Kompromiss, den wir gewählt haben, um Modelle so nah wie möglich an die App zu bringen und einen Netzwerkaufruf zu vermeiden (wie einige vielleicht vorschlagen).

Hey @dimileeh

Weißt du zufällig, welche Version von kubectl du gerade verwendest? und welche version hast du vorher benutzt? Ich würde gerne wissen, ob es eine Regression gab, aber gleichzeitig wäre ich überrascht, wenn das Feature vollständig verschwunden wäre.

In Bezug auf die GCS-Sache und da Sie sehr wenig über Ihren Anwendungsfall wissen, tut es mir leid, wenn es keinen Sinn macht: Ich würde vorschlagen, dass das gcs-Modell jedes Mal einen anderen Namen erhält, wenn es modifiziert wird (vielleicht Suffix mit ihrem Hash), und das der Name würde in der Bereitstellung enthalten sein. Das Aktualisieren der Bereitstellung zur Verwendung der neuen Dateien würde automatisch einen Rollout auslösen. Dies gibt Ihnen die Möglichkeit, zu einer früheren Bereitstellung/einem früheren Modell zurückzukehren, die Änderungen an den Modellen besser zu verstehen usw.

Hallo @apelisse , danke für deine Antwort!

Wenn ich kubectl version von Google Cloud Terminal aus ausführe, erhalte ich Folgendes:

Client Version: version.Info{Major:"1", Minor:"13+", GitVersion:"v1.13.11-dispatcher", GitCommit:"2e298c7e992f83f47af60cf4830b11c7370f6668", GitTreeState:"clean", BuildDate:"2019-09-19T22:20:12Z", GoVersion:"go1.11.13", Compiler:"gc", Platform:"linux/amd64"}
Server Version: version.Info{Major:"1", Minor:"16+", GitVersion:"v1.16.0-gke.20", GitCommit:"d324c1db214acfc1ff3d543767f33feab3f4dcaa", GitTreeState:"clean", BuildDate:"2019-11-26T20:51:21Z", GoVersion:"go1.12.11b4", Compiler:"gc", Platform:"linux/amd64"}

Als ich versuchte, kubectl über gcloud components update zu aktualisieren, hieß es, dass ich bereits die neuesten Versionen aller Produkte verwende. Daher denke ich, dass meine kubectl-Version gleich geblieben ist, während der K8S-Cluster von 1.15 auf 1.16 aktualisiert wurde.

Die Kubenetes-Dokumentation 1.17, 1.16 und 1.15 enthält nichts über die kubectl rollout restart Funktion. Ich frage mich also, ob Ihr wertvoller Beitrag von 1.16 verschwunden sein könnte?

Vielen Dank für Ihren Vorschlag zur Modellversionierung, er macht absolut Sinn. Wir haben darüber nachgedacht, aber dann, da wir unsere Modelle jeden Tag neu trainieren, dachten wir, wir würden zu viele Modelle ansammeln (und sie sind ziemlich schwer). Natürlich könnten wir nach einiger Zeit ein Skript verwenden, um alte Versionen zu bereinigen, aber bisher haben wir uns entschieden, es einfach zu halten, indem wir uns auf kubectl rollout restart und uns nicht um die Modellversionierung kümmern :)

Ich kann die Dokumente hier einsehen:
https://v1-16.docs.kubernetes.io/docs/reference/generated/kubectl/kubectl-commands# -em-restart-em-

Ah, danke, ich habe hier gesucht:
https://v1-16.docs.kubernetes.io/docs/reference/kubectl/cheatsheet/

Vielen Dank für diesen Link, ich werde dafür sorgen, dass er aktualisiert wird!

Am Do, 19. Dez. 2019 um 12:40 Uhr Dmitri Lihhatsov [email protected]
schrieb:

Ah, danke, ich habe hier gesucht:
https://v1-16.docs.kubernetes.io/docs/reference/kubectl/cheatsheet/

—
Sie erhalten dies, weil Sie erwähnt wurden.
Antworten Sie direkt auf diese E-Mail und zeigen Sie sie auf GitHub an
https://github.com/kubernetes/kubernetes/issues/13488?email_source=notifications&email_token=AAOXDLCDSTPYK6EGBQWSRADQZPL5BA5CNFSM4BOYZ5Z2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJment3
oder abmelden
https://github.com/notifications/unsubscribe-auth/AAOXDLHWCU4T6NCSHOYZIELQZPL5BANCNFSM4BOYZ5ZQ
.

@dimileeh PTAL https://github.com/kubernetes/website/pull/18224 (Ich werde in relevanten Zweigen die Rosinen auswählen, sobald dies zusammengeführt wird).

@dimileeh Ich glaube, ich habe herausgefunden, was mit deiner kubectl-Version nicht stimmt, wir werden daran arbeiten.

Ja, wir haben auch den Anwendungsfall, den Pod ohne Codeänderung neu zu starten, nachdem die Konfigurationskarte aktualisiert wurde. Dies dient dazu, ein ML-Modell zu aktualisieren, ohne den Dienst erneut bereitzustellen.

@anuragtr mit den neuesten Versionen, die Sie ausführen können

kubectl rollout restart deploy NAME

Ich habe dafür einen benutzerdefinierten Befehl verwendet [1], froh, dass er jetzt im Standardkubectl enthalten ist! Vielen Dank

[1] https://github.com/mauri870/kubectl-renew

@anuragtr mit den neuesten Versionen, die Sie ausführen können

kubectl rollout restart deploy NAME

@countrogue