kubernetes社区非常活跃，每季度都会发布一个release。但是线上集群业务可用性要求较高，场景复杂，任何微小的变更都需要非常小心，此时跟随社区版本进行升级略显吃力。但是为了能够使用到最新的一些feature我们必须不定期进行一些升级操作，在经历了一次线上集群的升级操作，踩完一些坑之后，分享一些收获与感悟。原来的集群版本是1.10，为了提高GPU集群的资源利用率，需要在调度器层面支持一些抢占调度等新特性，所以升级到1.14，此次升级的集群规模不是特别大，但是有一些在线任务，还是需要慎重操作。目前kubernetes社区中所有的工具(包括使用较多的kubeadm，kops等工具)对于生产环境高可用的集群升级都显的比较乏力，所以还是建议手动升级，更加安全可控，出现问题便于定位修复。
升级策略升级方式可以分为原地升级和异地升级：
原地升级是指在原有集群直接替换二进制进行升级，此种方式升级方便，运维代价较小，理论上来说多副本的业务不会有downtime，在充分测试的情况下优先选择原地升级.
异地升级是指新搭建一个一模一样的高版本集群，然后手动或自动迁移业务到新集群。此种方式需要上层提供滚动升级的能力，支持两个backend，需要额外的开发工作。且默认double一份原集群pod到新集群不会对业务造成影响，对于使用ceph等持久化存储的集群来说，可能会有问题。但此种方式升级更加安全可控，风险更低。
官方建议升级过程首先阅读相关release node，重点关注其中几部分： Known Issues，Action Requireed，Deprecations and removals。社区会将一些变化highlight到这里，阅读这些变化可以明确自己需要采取哪些行动。
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。
slave节点的升级是滚动升级，官方建议首先使用kubectl drain驱逐pod之后，然后升级kubelet，因为kubelet会有一些状态信息文件存储在node节点上，社区并不保证这些状态文件在版本间的兼容性。
apiserver升级之前需要确保resource version被正常支持，目前kubernetes会逐步废弃掉，例如: DaemonSet，Deployment，ReplicaSet 所使用的 extensions/v1beta1，apps/v1beta1，apps/v1beta2 将会在v1.16中完全废弃掉，届时，如果你再去读取这些版本的资源，apiserver将不会认识这些资源，任何的增删改查都无法进行，只能通过etcdctl进行删除。目前社区正在开发迁移工具，并且在支持该工具之前，所有的版本移除操作都会被冻结，所以目前(2019.5.20)来说是相对安全的。
生产实践升级过程如果采用官方建议的升级策略需要小版本不断升级，但是线上运维压力较大，业务场景复杂，大多数情况下不可能跟随社区版本不断升级，所以可以在充分测试的前提下进行大版本跳跃升级。
官方建议升级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不重启容器。
虽然kubernetes建议先升级master组件，然后再升级node组件，但是实际应用过程中建议先停掉controller-manager，然后升级master组件，node组件，最后再升级controller-manager，因为controller-manager中会进行一些状态的调谐(reconcile)，对于actual status不符合desire status的对象会触发一些操作。升级过程中尽管我们会进行充分的测试，但是也难免出现一些非预期的情况下，例如apiserver中某些资源对象的兼容性不好，或者其中的某些字段进行调整，触发controller-manager执行非预期操作，例如重建一个deployment下所有的pod，更糟糕的是，如果此时kubelet还未升级，就可能不认识新版本一些资源对象中的新增的某些字段，此时老的pod被删掉了，但是新的pod没有起来，就造成一定的服务中断。(后面会有相关的案例)
升级过程中建议调高日志级别，方便定位问题，在升级完成之后在降低日志级别。
备份etcd数据，并进行故障恢复的演练，作为升级失败的最后一道防线。