Kubernetes: Rolling Update für Daemon-Sets implementieren
Hi,
Entschuldigung, dass ich es in der falschen Reihenfolge gemacht habe, wie hier erwähnt: https://github.com/kubernetes/kubernetes/blob/master/CONTRIBUTING.md#contributing -a-patch
Ich habe #22439 gemacht, um dieses Problem zu lösen (auf kubectl-Seite)
Die Notwendigkeit besteht darin, einen Daemon-Satz in einer einzigen Befehlszeile aktualisieren zu können.
Grundsätzlich ist es gleichbedeutend mit:
kubectl delete -f dsfile --cascade=false
kubectl create -f dsfile
for pod in pods
kubectl delete pod
wait for delete
BEARBEITEN :
Seb-Solon
Alle 3 Kommentare
15310 deckt die Anforderungen für DaemonSet ab, um von Beta auf GA umzusteigen, einschließlich serverseitiger Update-Orchestrierung. Da würde ich mir lieber Mühe geben, aber es ist knifflig, und wir haben nicht vor, in 1.3 daran zu arbeiten.
Wenn Sie eine clientseitige Lösung beitragen möchten, obwohl dies nicht die langfristige Richtung ist, die wir im Auge haben (#12143), sollte kein neuer Befehl eingeführt werden. Stattdessen sollten wir dafür sorgen, dass kubectl rolling-update für DaemonSet (und auch ReplicaSet, wenn Sie so geneigt sind) funktioniert.
https://github.com/kubernetes/kubernetes/blob/master/pkg/kubectl/cmd/rollingupdate.go
Da rolling-update den Ressourcentyp ( replicationcontroller ) nicht angibt, müssen wir standardmäßig rc annehmen. Abgesehen davon denke ich, dass die Syntax natürlich auf andere Controllertypen erweiterbar ist, indem die Typ/Name-Syntax verwendet wird.
Zum Beispiel:
kubectl rolling-update daemonset/mydaemon --image=image:v2
Abgesehen vom Befehl selbst würde ich jedoch nicht erwarten, dass der Aktualisierungsvorgang Code teilt.
Der aktuelle Rolling-Update-Befehl erstellt einen neuen ReplicationController und skaliert ihn nach und nach hoch, während der alte herunterskaliert wird. Im Fall von --image führt es am Ende einen "Löschtanz" durch, um den Namen wieder in das ursprüngliche RC zu ändern - es löscht das Original, erstellt ein weiteres RC mit demselben Namen und löscht dann der temporäre RC, der zum Ausrollen des neuen Images verwendet wurde.
Im Fall von DaemonSet würde kubectl das Gegenteil tun: Es würde das ursprüngliche DaemonSet aktualisieren und Pods nacheinander löschen, um sie zu ersetzen. Wenn --image angegeben würde, würde dies nur am Ende erfolgen. Wenn ein neuer DaemonSet-Name angegeben wurde (zB kubectl rolling-update daemonset/mydaemon-v1 -f mydaemon-v2.yaml ), würde das neue DaemonSet am Ende des Aktualisierungsprozesses erstellt und das Original gelöscht. Wir müssen entweder sicherstellen, dass DaemonSet dies ordnungsgemäß behandelt, oder wir müssen das ursprüngliche DaemonSet löschen, bevor wir das neue erstellen (ähnlich meinem Vorschlag in #7402).
cc @mikedanese @davidopp @madhusudancs @janetkuo @kargakis @pwittrock @gmarek
bgrant0607
am 29. Apr. 2016
1.6 enthält fortlaufende Upgrades für DaemonSets.
kargakis
am 20. März 2017
Danke für das Update! 👍
Seb-Solon
am 20. März 2017
Verwandte Themen
jadhavnitind
·
3Kommentare
ddysher
·
3Kommentare
errordeveloper
·
3Kommentare
alexferl
·
3Kommentare
arun-gupta
·
3Kommentare
Hilfreichster Kommentar
1.6 enthält fortlaufende Upgrades für DaemonSets.