Kubernetes: Implémenter la mise à jour continue pour les ensembles de démons

Créé le 4 mars 2016 · 3Commentaires · Source: kubernetes/kubernetes

Salut,

Désolé de le faire dans le mauvais ordre comme mentionné ici : https://github.com/kubernetes/kubernetes/blob/master/CONTRIBUTING.md#contributing -a-patch

J'ai fait #22439 pour résoudre ce problème (côté kubectl)

Le besoin est de pouvoir mettre à jour un jeu de démons en une seule ligne de commande.
En gros c'est équivalent à faire :

kubectl delete  -f dsfile  --cascade=false
kubectl create   -f dsfile
for pod in pods
kubectl  delete pod
wait for delete

EDIT : @bgrant0607 a suggéré de mettre à jour le ds au lieu de delte/recreate

areapp-lifecycle areworkload-apdaemonset prioritbacklog siapps

Source

Seb-Solon

👍13

Commentaire le plus utile

1.6 inclut des mises à niveau progressives pour les DaemonSets.

kargakis le 20 mars 2017

🎉9 ❤6

Tous les 3 commentaires

15310 couvre les exigences pour que DaemonSet passe de la version bêta à la version GA, y compris l'orchestration des mises à jour côté serveur. Je préfère faire des efforts là-dessus, mais c'est délicat, et nous ne prévoyons pas de travailler là-dessus en 1.3.

Si vous souhaitez contribuer à une solution côté client, bien que ce ne soit pas l'orientation à long terme que nous ayons en tête (#12143), cela ne devrait pas introduire de nouvelle commande. Au lieu de cela, nous devrions faire fonctionner kubectl rolling-update pour DaemonSet (et ReplicaSet aussi, si vous le souhaitez).

https://github.com/kubernetes/kubernetes/blob/master/pkg/kubectl/cmd/rollingupdate.go

Étant donné que rolling-update ne spécifie pas le type de ressource ( replicationcontroller ), nous devons supposer rc par défaut. En dehors de cela, je pense que la syntaxe est naturellement extensible à d'autres types de contrôleurs, en utilisant la syntaxe type/nom.

Par exemple:

kubectl rolling-update daemonset/mydaemon --image=image:v2

À part la commande elle-même, je ne m'attendrais pas à ce que la procédure de mise à jour partage du code.

La commande roll-update actuelle crée un nouveau ReplicationController et le met progressivement à l'échelle tout en réduisant l'ancien. Dans le cas de --image , il effectue une "danse de suppression" à la fin afin de renommer le RC d'origine - il supprime l'original, crée un autre RC du même nom, puis supprime le RC temporaire utilisé pour déployer la nouvelle image.

Dans le cas de DaemonSet, kubectl ferait le contraire : il mettrait à jour le DaemonSet d'origine et supprimerait les pods un par un pour les remplacer. Si --image étaient spécifiés, ce serait juste fait à la fin. Si un nouveau nom de DaemonSet était spécifié (par exemple, kubectl rolling-update daemonset/mydaemon-v1 -f mydaemon-v2.yaml ), le nouveau DaemonSet serait créé à la fin du processus de mise à jour et l'original serait supprimé. Nous devons soit nous assurer que DaemonSet gère cela correctement, soit supprimer le DaemonSet d'origine avant de créer le nouveau (similaire à ma proposition dans #7402).

cc @mikedanese @davidopp @madhusudancs @janetkuo @kargakis @pwittrock @gmarek