k8s升级集群时的pod状态

Question

k8s 文档说 kubeadm 升级不涉及您的工作负载，只涉及 Kubernetes 内部的组件，但我目前不了解 Pod 的状态。

Answer 1

有不同的升级策略，但我假设您希望以零停机时间升级集群。
在这种情况下，高级升级过程如下：

1. 升级控制平面节点 - 应该一次执行一个节点。
2. 升级工作节点 - 应一次执行一个节点或一次执行几个节点，而不会影响运行工作负载所需的最低容量。

通过将节点标记为'unschedulable' 并驱逐工作负载（将工作负载移动到其他节点）来准备节点以进行维护非常重要：

$ kubectl drain <node-to-drain> --ignore-daemonsets

注意：如果有未被ReplicationController、ReplicaSet、Job、DaemonSet 或 StatefulSet 管理的 Pod，则排水操作将被拒绝，除非您使用--force 选项。

正如您在 Safely Drain a Node 文档中看到的那样：

在对节点执行维护（例如内核升级、硬件维护等）之前，您可以使用 kubectl drain 从节点安全地驱逐所有 pod。安全驱逐允许 pod 的容器优雅地终止，并将遵守您指定的 PodDisruptionBudgets。

如果您在此节点上完成了升级过程，则需要通过运行使节点重新联机：

$ kubectl uncordon <node name> 

总结一下：kubectl drain 改变了Pods 的状态（工作流移动到另一个节点）。 与kubectl drain 不同，kubeadm upgrade 不会触及/影响您的工作负载，只会修改 Kubernetes 内部的组件。

以“kube-scheduler”为例，我们可以看到当我们运行kubeadm upgrade apply命令时，控制平面组件究竟发生了什么：

[upgrade/staticpods] Preparing for "kube-scheduler" upgrade
[upgrade/staticpods] Renewing scheduler.conf certificate
[upgrade/staticpods] Moved new manifest to "/etc/kubernetes/manifests/kube-scheduler.yaml" and backed up old manifest to "/etc/kubernetes/tmp/kubeadm-backup-manifests-2021-03-07-15-42-15/kube-scheduler.yaml"
[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 "kube-scheduler" upgraded successfully!

Answer 2

• Pod 的扩容和缩容方式，集群也可以通过扩容和缩容来增加/减少节点。
• 在扩展集群时，如果您增加节点池的大小，现有 Pod 将不会移动到较新的节点。
• 在扩展集群时，如果您手动减小节点池的大小，则已删除节点上的任何 Pod 都不会在其他节点上重新启动。
• 如果自动缩放减少了节点池的大小，则已删除节点上不受复制控制器管理的任何 Pod 都不会丢失。