Add RollingUpdate strategy to Calico DaemonSet manifests

[Quentin-M]

Hi there,

Current Behavior

According to Kubernetes' documentation, DaemonSets have two update strategy types:

DaemonSet has two update strategy types:

• OnDelete: This is the default update strategy for backward-compatibility. With OnDelete update strategy, after you update a DaemonSet template, new DaemonSet pods will only be created when you manually delete old DaemonSet pods. This is the same behavior of DaemonSet in Kubernetes version 1.5 or before.
• RollingUpdate: With RollingUpdate update strategy, after you update a DaemonSet template, old DaemonSet pods will be killed, and new DaemonSet pods will be created automatically, in a controlled fashion.

Because the Calico self-hosted manifests do not specify a strategy, they are all using the default one: OnDelete, meaning that after kubectl apply -f calico.yaml is executed, nothing will happen until the nodes reboot (or similar).

Expected Behavior

It'd be awesome to have Kubernetes execute Rolling Upgrades of Calico pods instead - if that's technically possible on the Calico side of things.

Possible Solution

Adding the following to the manifests:

updateStrategy:
  type: RollingUpdate
  rollingUpdate:
    maxUnavailable: 1

[caseydavenport]

Duplicate of #777, but I like this one better so I'll close #777.

Yes - I think we should do this across all of our k8s manifests in master. Would anyone like to submit a patch? :)