kubernetes-handbook/practice/manually-upgrade.md

5.7 KiB
Raw Blame History

手动升级kubernetes集群

在我最开始写作本书的时候kubernetes刚发布1.6.0版本而kubernetes基本按照每三个月发布一个大版本的速度迭代为了使用新特性和只支持新版本kubernetes的配套软件升级kubernetes就迫在眉睫在此我们使用替换kubernets的旧的二进制文件这种暴力的方式来升级测试集群若升级生产集群还望三思。

另外自kubernetes1.6版本之后发布的1.7和1.8版本又增加了一些新特性,参考:

目前kubernetes的官方文档上并没有详细的手动安装的集群如何升级的参考资料只有两篇关于kubernetes集群升级的文档。

手动升级的还没有详细的方案大多是基于管理工具部署和升级比如juju、kubeadm、kops、kubespray等。

manual upgrade/downgrade testing for Kubernetes 1.6 - google group在这个Google group中讨论了kubernetes手动升级的问题并给出了参考建议。

升级步骤

**注意:**该升级步骤是实验性的,建议在测试集群上使用,无法保证线上服务不中断,实际升级完成后无需对线上服务做任何操作。

大体上的升级步骤是先升级master节点然后再一次升级每台node节点。

升级建议

下图来自@ahmetb的Twitter这是他对于0宕机时间的kubernetes集群升级建议。

Kubernetes零宕机时间升级建议

主要包括以下建议:

  • 应用使用高级对象定义,如支持滚动更新的Deployment对象
  • 应用要部署成多个实例
  • 使用pod的preStop hook加强pod的生命周期管理
  • 使用就绪和健康检查探针来确保应用存活和及时阻拦应用流量的分发

准备

  1. 备份kubernetes原先的二进制文件和配置文件。
  2. 下载最新版本的kubernetes二进制包如1.8.5版本,查看changelog,下载二进制包,我们使用的是kubernetes-server-linux-amd64.tar.gz,分发到集群的每个节点上。

升级master节点

停止master节点的进程

systemctl stop kube-apiserver
systemctl stop kube-scheduler
systemctl stop kube-controller-manager
systemctl stop kube-proxy
systemctl stop kubelet

使用新版本的kubernetes二进制文件替换原来老版本的文件然后启动master节点上的进程

systemctl start kube-apiserver
systemctl start kube-scheduler
systemctl start kube-controller-manager

因为我们的master节点同时也作为node节点所有还要执行下面的”升级node节点“中的步骤。

升级node节点

关闭swap

# 临时关闭
swapoff -a

# 永久关闭注释掉swap分区即可
vim /etc/fstab
#UUID=65c9f92d-4828-4d46-bf19-fb78a38d2fd1 swap                    swap    defaults        0 0

修改kubelet的配置文件

将kubelet的配置文件/etc/kubernetes/kublet配置文件中的KUBELET_API_SERVER="--api-servers=http://172.20.0.113:8080"行注释掉。

注意:kubernetes1.7及以上版本已经没有该配置了API server的地址写在了kubeconfig文件中。

停止node节点上的kubernetes进程

systemctl stop kubelet
systemctl stop kube-proxy

使用新版本的kubernetes二进制文件替换原来老版本的文件然后启动node节点上的进程

systemctl start kubelet
systemctl start kube-proxy

启动新版本的kube-proxy报错找不到conntrack命令,使用yum install -y conntrack-tools命令安装后重启kube-proxy即可。

检查

到此升级完成在master节点上检查节点状态

NAME           STATUS    ROLES     AGE       VERSION
172.20.0.113   Ready     <none>    244d      v1.8.5
172.20.0.114   Ready     <none>    244d      v1.8.5
172.20.0.115   Ready     <none>    244d      v1.8.5

所有节点的状态都正常再检查下原先的运行在kubernetes之上的服务是否正常如果服务正常的话说明这次升级无误。

API版本变更适配

对于不同版本的Kubernetes许多资源对象的API的版本可能会变更下表列出了kubernetes1.5至1.9的API资源对象的版本演进

Kuberentes API对象的版本演进

当我们升级过后可能出现资源对象的API变更后原先的YAML文件无法使用的情况因此需要对新版本的Kubernetes进行适配。对应的API版本转换工具https://github.com/fleeto/kube-version-converter可以将Kuberntes API对象转换到指定版本。

参考