kubernetes集群升级的正确姿势

kubernetes社区非常活跃，每季度都会发布一个release。但是线上集群业务可用性要求较高，场景复杂，任何微小的变更都需要非常小心，此时跟随社区版本进行升级略显吃力。但是为了能够使用到最新的一些feature我们必须不定期进行一些升级操作，在经历了一次线上集群的升级操作，踩完一些坑之后，分享一些收获与感悟。原来的集群版本是1.10，为了提高GPU集群的资源利用率，需要在调度器层面支持一些抢占调度等新特性，所以升级到1.14，此次升级的集群规模不是特别大，但是有一些在线任务，还是需要慎重操作。目前kubernetes社区中所有的工具(包括使用较多的kubeadm，kops等工具)对于生产环境高可用的集群升级都显的比较乏力，所以还是建议手动升级，更加安全可控，出现问题便于定位修复。

升级策略

升级方式可以分为原地升级和异地升级：

• 原地升级是指在原有集群直接替换二进制进行升级，此种方式升级方便，运维代价较小，理论上来说多副本的业务不会有downtime，在充分测试的情况下优先选择原地升级.
• 异地升级是指新搭建一个一模一样的高版本集群，然后手动或自动迁移业务到新集群。此种方式需要上层提供滚动升级的能力，支持两个backend，需要额外的开发工作。且默认double一份原集群pod到新集群不会对业务造成影响，对于使用ceph等持久化存储的集群来说，可能会有问题。但此种方式升级更加安全可控，风险更低。

官方建议升级过程

1. 首先阅读相关release node，重点关注其中几部分： Known Issues，Action Requireed，Deprecations and removals。社区会将一些变化highlight到这里，阅读这些变化可以明确自己需要采取哪些行动。
2. kubernetes 建议不断地进行小版本升级，而不是一次进行大的版本跳跃。具体的兼容策略是： slave组件可以与master组件最多延迟两个小版本(minor version)，但是不能比master组件新。client不能与master组件落后一个小版本，但是可以高一个版本，也就是说： v1.3的master可以与v1.1，v1.2，v1.3的slave组件一起使用，与v1.2，v1.3，v1.4 client一起使用。官方建议每次升级不要跨越两个版本，升级顺序为: master，addons，salve。
3. slave节点的升级是滚动升级，官方建议首先使用kubectl drain驱逐pod之后，然后升级kubelet，因为kubelet会有一些状态信息文件存储在node节点上，社区并不保证这些状态文件在版本间的兼容性。
4. apiserver升级之前需要确保resource version被正常支持，目前kubernetes会逐步废弃掉，例如: DaemonSet，Deployment，ReplicaSet 所使用的 extensions/v1beta1，apps/v1beta1，apps/v1beta2 将会在v1.16中完全废弃掉，届时，如果你再去读取这些版本的资源，apiserver将不会认识这些资源，任何的增删改查都无法进行，只能通过etcdctl进行删除。目前社区正在开发迁移工具，并且在支持该工具之前，所有的版本移除操作都会被冻结，所以目前(2019.5.20)来说是相对安全的。

生产实践升级过程

1. 如果采用官方建议的升级策略需要小版本不断升级，但是线上运维压力较大，业务场景复杂，大多数情况下不可能跟随社区版本不断升级，所以可以在充分测试的前提下进行大版本跳跃升级。
2. 官方建议升级kubelet之前先将所有pod驱逐，但是此种方式可能会造成业务容器频繁重启。例如升级nodeA时pod漂移到未升级节点nodeB，后续升级nodeB可能需要继续驱逐该pod。为避免频繁重启业务，在充分测试的情况下不用驱逐，直接原地升级即可。目前（2019.6.5）在master组件升级之后重启或升级kubelet会导致大部分容器重启，因为kubelet通过hash(container spec)来生成容器的唯一标识，不同版本间container spec会发生变化，引起hash值变化，进而导致容器重启，参见kubernetes/kubernetes: Issue #63814。在不驱逐pod的情况下原地升级最坏情况下只有一次重启，而且volume等信息不会发生变化，对于集群的扰动也较小。 有能力的同学可以研究下如何做到升级kubelet不重启容器。
3. 虽然kubernetes建议先升级master组件，然后再升级node组件，但是实际应用过程中建议先停掉controller-manager，然后升级master组件，node组件，最后再升级controller-manager，因为controller-manager中会进行一些状态的调谐(reconcile)，对于actual status不符合desire status的对象会触发一些操作。升级过程中尽管我们会进行充分的测试，但是也难免出现一些非预期的情况下，例如apiserver中某些资源对象的兼容性不好，或者其中的某些字段进行调整，触发controller-manager执行非预期操作，例如重建一个deployment下所有的pod，更糟糕的是，如果此时kubelet还未升级，就可能不认识新版本一些资源对象中的新增的某些字段，此时老的pod被删掉了，但是新的pod没有起来，就造成一定的服务中断。(后面会有相关的案例)
4. 升级过程中建议调高日志级别，方便定位问题，在升级完成之后在降低日志级别。
5. 备份etcd数据，并进行故障恢复的演练，作为升级失败的最后一道防线。
6. 升级之前review集群状态，确保所有组件正常工作，review重要业务的实例数，避免副本数为1，并且适当设置PDB; 需要检查是否有单个node带有特殊的label，可能有pod依赖于该label，如果该node异常导致pod也会发生故障(这个坑真的有人踩过：参见:ingress-cordoned)。

升级过程中发现的“坑” (已填)

1. 上面的实践3中就是笔者测试的时候发现的一个坑： 目前升级会导致部分controller(daemonset)重建容器，升级之后因为pod spec发生变化，部分controller会创建新的controllerrevision ，升级更新所有其控制的容器。如果先升级master/controller-manager，因为此时kubelet还未升级，版本较低，会出现不兼容的字段，严重情况下kubelet会reject掉该pod，导致最终该node上此daemonset container退出并无法重启。如果daemonset 设置为滚动升级，并且maxUnavailable设置为1的话，可以避免一定损失，最多只允许同时挂掉一个daemonset container。参见kubernetes/kubernetes: Issue #78633。所以最佳实践还是升级之前停掉Controller-manager，集群实际完毕之后最后升级controller-manager。设置所有controller的升级策略为滚动升级并设置最大不可用实例数。对于上述Issue官方在新版本中已经进行修复并backport到旧版本中。
2. 对于一些刚从alpha转到beta的特性，beta版本是默认开启的版本，对于这些特性一定要非常小心，可能仍然会存在一些bug，建议还是手动关闭，对于一些可用性要求较高的集群建议只使用GA的feature。这次踩的一个坑就是node lease特性，该特性在1.14中刚好是Beta版本默认开启，这是一个非常有用的feature，对于大规模集群可以有效降低apiserver，etcd的负载，但是kubelet中node lease的默认renew周期是hardcode的10s中且不可调整，也就是说此时node与master心跳的频率只能是10s，此时指定--node-status-update-frequencyflag没有任何作用，如果controller-manager中配置的--node-monitor-grace-period刚好是10s，这时候node会不断地在ready和non-ready直接摇摆，参见kubernetes/kubernetes issue#80172，该issue已经被笔者给修复掉了 :)。

写在后面

kubernetes还是在高速的迭代过程中，升级过程中出现不兼容是在所难免的， 唯有搞懂内部的实现机制才能保障集群的长治久安。发现问题也需要我们有能力去解决并且反馈到社区中，取之于社区，理应回报于社区。

reference

Kubernetes Release Versioning