Question

我计划将kubernetes群集版本从v1.7.10升级到v1.8.12。但正如此issue所述，由于规范哈希更改，所有容器都将重新启动。那么，建议的升级程序是什么？在升级kubelet版本之前是否需要耗尽节点，或者只是进行就地升级并让所有容器重新启动？有什么区别？

此外，由于升级到v1.9.0也会导致容器重启，我可以直接将v1.7.10升级到v1.10.3吗？通过这种方式，我至少可以避免两次耗时的升级到v1.8和v1.9。有没有限制让我这样做？

任何建议都将受到赞赏。

Answer 1

Kubeadm cluster upgrade page建议不要跳过主要版本：17到1.8，然后1.8到1.9仍是推荐路径。
我想这对于kubernetes itself upgrades也是一样的想法。

我需要在升级kubelet版本
之前耗尽节点

这就是文档建议的内容：

对于群集中的每个主机（以下称为$ HOST），请执行以下命令升级kubelet：

准备主机进行维护，将其标记为不可调度并逐出工作负载：

kubectl drain $HOST --ignore-daemonsets

Answer 2

经过一些测试和研究，我得出了一些结论：

排除节点不是必须的。至少，排水不能驱逐守护进程。但是，建议使用节点来升级kubernetes，因为这可以在很大程度上减少对使用部署部署的应用程序的影响。

另外，有时需要排空一个节点。例如，从kubernetes v1.10开始，所有pod的日志文件已从/var/log/pods/pod-id/container_id.log更改为/var/log/pods/pod-id/container/id.log，因此，当升级到v1.10时，所有pod都必须重新启动才能使用新的日志文件，否则，您无法通过“kubectl logs”命令访问其日志。此时，排空节点是有帮助的，对于那些无法驱逐的吊舱，如守护进程，我们必须手动重启它们。
不支持跳过次要版本升级，尤其是在具有多个主设备的HA设置中，可以通过GKE's supported upgrades policy以某种方式证明。此外，跳过次要版本升级有时会带来一些风险。

再次，作为示例，升级到v1.10。在1.10中，apps API组中的对象开始以apps / v1格式保存在etcd中，v1.9可以很好地处理，但v1.8不能。因此，当你将kubernetes从v1.8升级到1.10时，在HA设置中，一些主人已经升级，有些没有，会带来一些奇怪的问题，比如部署/守护进程无法正常处理，更多信息参考my another question。因此，应尽可能避免这种升级。

Answer 3

在执行升级等操作任务时，排除/封锁节点始终是个好主意。升级完成后，取消对节点的控制，然后对集群中的其他节点重复此过程。

Re：跳过版本，据我所知，在升级中没有跳过次要版本的限制。