Question

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

Answer 1

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

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

通过将节点标记为 '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

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

k8s升级集群时的pod状态

2 个答案: