Make sure to back up any important components, such as app-level state stored in a database.
kubeadm upgrade does not touch your workloads, only components internal to Kubernetes, but backups are always a best practice.

Additional information

All containers are restarted after upgrade, because the container spec hash value is changed.

You only can upgrade from one MINOR version to the next MINOR version,
or between PATCH versions of the same MINOR. That is, you cannot skip MINOR versions when you upgrade.
For example, you can upgrade from 1.y to 1.y+1, but not from 1.y to 1.y+2.

[upgrade/config] Making sure the configuration is correct:
[upgrade/config] Reading configuration from the cluster...
[upgrade/config] FYI: You can look at this config file with 'kubectl -n kube-system get cm kubeadm-config -oyaml'
[preflight] Running pre-flight checks.
[upgrade] Making sure the cluster is healthy:
[upgrade] Fetching available versions to upgrade to
[upgrade/versions] Cluster version: v1.15.2
[upgrade/versions] kubeadm version: v1.16.0
Components that must be upgraded manually after you have upgraded the control plane with 'kubeadm upgrade apply':
COMPONENT CURRENT AVAILABLE
Kubelet 1 x v1.15.2 v1.16.0
Upgrade to the latest version in the v1.16 series:
COMPONENT CURRENT AVAILABLE
API Server v1.15.2 v1.16.0
Controller Manager v1.15.2 v1.16.0
Scheduler v1.15.2 v1.16.0
Kube Proxy v1.15.2 v1.16.0
CoreDNS 1.3.1 1.6.2
Etcd 3.3.10 3.3.15
You can now apply the upgrade by executing the following command:
kubeadm upgrade apply v1.16.0
_____________________________________________________________________

This command checks that your cluster can be upgraded, and fetches the versions you can upgrade to.

Note:kubeadm upgrade also automatically renews the certificates that it manages on this node.
To opt-out of certificate renewal the flag --certificate-renewal=false can be used.
For more information see the certificate management guide.

Choose a version to upgrade to, and run the appropriate command. For example:

Your Container Network Interface (CNI) provider may have its own upgrade instructions to follow.
Check the addons page to
find your CNI provider and see whether additional upgrade steps are required.

This step is not required on additional control plane nodes if the CNI provider runs as a DaemonSet.

One common issue you may encounter if you are using Flannel network is
that after the upgrade, the cluster nodes remain in NotReady state.
If you do kubectl get nodes -o yaml, you may see following lines in the
output:

message:docker: network plugin is not ready: cni config uninitialized

In this case, you will need to update the /etc/cni/net.d/10-flannel.conflist
file to include the cniVersion line, as shown below:

Uncordon the node

Verify the status of the cluster

After the kubelet is upgraded on all nodes verify that all nodes are available again by running the following command from anywhere kubectl can access the cluster:

kubectl get nodes

The STATUS column should show Ready for all your nodes, and the version number should be updated.

Recovering from a failure state

If kubeadm upgrade fails and does not roll back, for example because of an unexpected shutdown during execution, you can run kubeadm upgrade again.
This command is idempotent and eventually makes sure that the actual state is the desired state you declare.

To recover from a bad state, you can also run kubeadm upgrade apply --force without changing the version that your cluster is running.

How it works

kubeadm upgrade apply does the following:

Checks that your cluster is in an upgradeable state:

The API server is reachable

All nodes are in the Ready state

The control plane is healthy

Enforces the version skew policies.

Makes sure the control plane images are available or available to pull to the machine.

Upgrades the control plane components or rollbacks if any of them fails to come up.

Applies the new kube-dns and kube-proxy manifests and makes sure that all necessary RBAC rules are created.

Creates new certificate and key files of the API server and backs up old files if they’re about to expire in 180 days.

kubeadm upgrade node does the following on additional control plane nodes: