Kubernetes: Implement rolling update for daemon sets

Created on 4 Mar 2016 · 3Comments · Source: kubernetes/kubernetes

Hi,

Sorry for doing it in the wrong order as mentioned here : https://github.com/kubernetes/kubernetes/blob/master/CONTRIBUTING.md#contributing-a-patch

I did #22439 to address this problem (on kubectl side)

The need is to be able to update a daemon set in a single command line.
Basically it is equivalent to do :

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

EDIT : @bgrant0607 suggested to update the ds instead of delte / recreate

areapp-lifecycle areworkload-apdaemonset prioritbacklog siapps

Source

Seb-Solon

👍13

Most helpful comment

1.6 includes rolling upgrades for DaemonSets.

kargakis on 20 Mar 2017

🎉9 ❤6

All 3 comments

15310 covers requirements for DaemonSet to graduate from beta to GA, including server-side update orchestration. I'd rather put effort into that, but it's tricky, and we don't plan to work on that in 1.3.

If you'd like to contribute a client-side solution, though that's not the long-term direction we have in mind (#12143), it shouldn't introduce a new command. Instead, we should make kubectl rolling-update work for DaemonSet (and ReplicaSet, too, if you're so inclined).

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

Because rolling-update doesn't specify the resource type (replicationcontroller), we must assume rc by default. Other than that, I think the syntax is naturally extensible to other controller types, using the type/name syntax.

For example:

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

Other than the command itself, I wouldn't expect the update procedure to share code, though.

The current rolling-update command creates a new ReplicationController and gradually scales it up while scaling the old one down. In the case of --image, it does a "deletion dance" at the end in order to change the name back to the original RC -- it deletes the original, creates another RC of the same name, and then deletes the temporary RC used to roll out the new image.

In the case of DaemonSet, kubectl would do the opposite: it would update the original DaemonSet and delete pods one by one to cause them to be replaced. If --image were specified, it would just be done at the end. If a new DaemonSet name were specified (e.g., kubectl rolling-update daemonset/mydaemon-v1 -f mydaemon-v2.yaml), the new DaemonSet would be created at the end of the update process, and the original would be deleted. We'd either need to ensure DaemonSet handled that gracefully, or we'd need to delete the original DaemonSet before creating the new one (similar to my proposal in #7402).

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