<p>The k8s documentation says that kubeadm upgrade does not touch your workloads, only components internal to Kubernetes, but I don't understand the status of the Pods at this time.</p>

hlwo jiv
<p>There are different upgrade strategies, but I assume you want to upgrade your cluster with zero downtime.<br />
In this case, the upgrade procedure at high level is the following:</p>
<ol>
<li>Upgrade control plane nodes - should be executed one node at a time.</li>
<li>Upgrade worker nodes - should be executed one node at a time or few nodes at a time, without compromising the minimum required capacity for running your workloads.</li>
</ol>
<p>It's important to prepare the node for maintenance by marking it <code>'unschedulable'</code> and evicting the workloads (moving the workloads to other nodes):</p>
<pre><code>$ kubectl drain &lt;node-to-drain&gt; --ignore-daemonsets
</code></pre>
<p><strong>NOTE:</strong> If there are Pods not managed by a <code>ReplicationController</code>, <code>ReplicaSet</code>, <code>Job</code>, <code>DaemonSet</code> or <code>StatefulSet</code> , the drain operation will be refused, unless you use the <code>--force</code> option.</p>
<p>As you can see in the <a href="https://kubernetes.io/docs/tasks/administer-cluster/safely-drain-node/" rel="nofollow noreferrer">Safely Drain a Node</a> documentation:</p>
<blockquote>
<p>You can use kubectl drain to safely evict all of your pods from a node before you perform maintenance on the node (e.g. kernel upgrade, hardware maintenance, etc.). Safe evictions allow the pod's containers to gracefully terminate and will respect the PodDisruptionBudgets you have specified.</p>
</blockquote>
<p>If you finished the upgrade procedure on this node, you need to bring the node back online by running:</p>
<pre><code>$ kubectl uncordon &lt;node name&gt; 
</code></pre>
<p>To sum up: <code>kubectl drain</code> changes the status of the <code>Pods</code> (workflow moves to another node).
Unlike <code>kubectl drain</code>, <code>kubeadm upgrade</code> does not touch/affect your workloads, only modifies components internal to Kubernetes.</p>
<p>Using &quot;kube-scheduler&quot; as an example, we can see what exactly happens to the control plane components when we run the <code>kubeadm upgrade apply</code> command:</p>
<pre><code>[upgrade/staticpods] Preparing for &quot;kube-scheduler&quot; upgrade
[upgrade/staticpods] Renewing scheduler.conf certificate
[upgrade/staticpods] Moved new manifest to &quot;/etc/kubernetes/manifests/kube-scheduler.yaml&quot; and backed up old manifest to &quot;/etc/kubernetes/tmp/kubeadm-backup-manifests-2021-03-07-15-42-15/kube-scheduler.yaml&quot;
[upgrade/staticpods] Waiting for the kubelet to restart the component
[upgrade/staticpods] This might take a minute or longer depending on the component/version gap (timeout 5m0s)
[upgrade/staticpods] Component &quot;kube-scheduler&quot; upgraded successfully!
</code></pre>
