我刚刚测试了Ranche RKE，将kubernetes 13.xx升级到14.xx，在升级过程中，已经运行的nginx Pod在升级过程中重新启动。这是预期的行为吗？
我们可以在不重启用户Pod的情况下进行Kubernetes集群升级吗？
哪个工具支持非侵入式升级？
我们永远无法避免的停机时间是什么？ （除了控制平面）
答案 0 :(得分：2)
Kubernetes的默认升级方式是一次对节点进行一次滚动升级。
这通过排干并封锁正在升级的每个节点（将节点标记为对于新部署不可用）来起作用，从而使该节点上没有任何容器运行。
通过在另一个节点上创建现有Pod的新修订版（如果有）来完成此操作，并在新Pod开始运行（并响应就绪/运行状况探测器）时，它将停止并删除旧Pod（发送） SIGTERM到要升级的节点上的每个pod容器。
Kubernetes等待Pod正常关闭的时间由Pod规范上的terminationGracePeriodSeconds控制，如果Pod花费的时间更长，它们将被SIGKILL杀死。
关键是，要进行优雅的Kubernetes升级，您需要有足够的可用节点，并且吊舱必须具有正确的活动性和就绪性探针（https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-probes/）。
一些值得一读的有趣材料：
https://cloud.google.com/blog/products/gcp/kubernetes-best-practices-upgrading-your-clusters-with-zero-downtime（特定于GKE，但有一些见解）
https://blog.gruntwork.io/zero-downtime-server-updates-for-your-kubernetes-cluster-902009df5b33
答案 1 :(得分：0)
已解决，通过在主机上配置容器运行时不在docker restart上重新启动容器。