the site subtitle

K8s 集群升级

2019.10.22

目前k8s差不多三个月就会有一个大版本,差不多半年不更新的话就追不上官方的步伐了,同时还会有一些重大0day的CVE被发现,所以适当的升级集群也是有必要的。本文试尝讨论一种可以把影响降到最低甚至zero down time的升级方式。另外本文主要讨论kubeadm搭建的集群,在原基群中升级。

何时升级

k8s遵守语义化版本的规定,比如x.y.z中,最后的小版本可以随意升级,当发现有新的CVE之后,可以通过升级小版本来快速修复,当然如果在VPC或者内网之内,就不用太担心了。

当y需要升级的时候,官方不建议跨两个版本号升级,虽然代码中有兼容的方式,这时候通过kubeadm upgrade的命令也是可以升级的,需要注意的是检测更新的时候需要科学上网,doc见 https://kubernetes.io/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade/

升级准备

备份数据,这个应该在平时就做好,etcd的数据全量备份,数据目录也应该备份,集群中应用对应的yaml文件,甚至是pvc中的数据,当然这个要根据实际情况进行备份。

然后阅读相关release node,重点关注其中几部分: Known Issues,Action Requireed,Deprecations and removals。社区会将一些变化highlight到这里,阅读这些变化可以明确自己需要采取哪些行动。有哪些参数变化,哪些feature发生更改。比如1.13到1.14 Node Lease的feature就默认打开了。见 https://github.com/kubernetes/kubernetes/pull/72096

升级流程,按照我的经验,升级步骤应该是etcd master node addons,node组件可以与master组件最多延迟两个小版本(minor version),但是不能比master组件新,因为可能会有新的字段,所以master版本应该高一点。

etcd需要注意的是,要保证集群的可用性必须要有(n+1)/2个可用节点,这时候才能进行读写操作,否则etcd就会拒绝写入。

除此以外 https://www.cnblogs.com/gaorong/p/11266629.html 这篇文章提到应该暂时停掉KCM,避免pod漂移或者副本发送变化,仔细想来也是很有必要的,不过这样降低了集群的可用时间,也就是升级的时候不能进行其他操作,当然可用性和一致性也是需要做一个选择。

升级测试,自己搭建一个旧的集群,然后按照步骤升级,看看是否有一些意料之外的问题出现。

Ref

kubernetes集群升级的正确姿势

https://www.cnblogs.com/gaorong/p/11266629.html