See issue #6079 as the roll-up for node upgrades.

This issue is to do an in-place upgrade of the kubelet and kube-proxy binaries while a node is running. Docker and the kernel/OS are not changed. This upgrade can only be performed if the requested new version of kubelet and kube-proxy are compatible with the existing Docker and kernel/OS version; see #4855 for more details on versioning.

We simply want to download the new (kube*) node binaries, stop the old ones, and start the new ones (#1573). That way, the pods continue to run, and we don't have to migrate any storage. Possible complications include:

• upgrade: Make node components upgradeable (at all possible) #3333 leftover state or configuration of the VM will cause unwanted side effects after the upgrade is complete
• the configuration of the node (environment variables, flags passed to kube_, something salt does) might change between kube_ versions
• when kube* binaries are stopped, the master might think the pods are all gone, and schedule new copies of the pods elsewhere throughout the cluster

The following requirements follow:

• smart salt stanzas: idempotency, can run on a previously salted node
• must have an upgrade grace period where the pods are considered alive even if they cannot be health-checked by kubernetes

The tests for this feature are tracked in #7256.

References:

• Cluster versioning #4855 cluster versioning
• upgrade: Make node components upgradeable (at all possible) #3333 lively debate about kubelet & kube-proxy upgrades, specifically in-place vs fresh-node
• upgrade: Make node components upgradeable (via online don't-kill-containers) #1573 online kubelet upgrades; the original issue for this work item