Kubernetes是迄今为止Github上最活跃的项目之一，已经积累了超过8万次提交和550个发布。在本地或在云中安装高可用Kubernetes集群的过程已经有足够多的文档，在大多数情况下，我们无需执行许多步骤。还有其他工具，例如Kops或Kubespray，可帮助自动执行此过程。
但是，我们经常需要升级集群，以跟上最新的安全功能和错误修复，并不断受益于新功能。
通常，在升级Kubernetes高可用集群时，升级过程涉及两个可能不会重叠或无法同时执行的单独任务：升级Kubernetes集群；升级etcd集群–是Kubernetes的分布式键值存储。让我们看看如何以最小的中断执行这些任务。
升级Kubernetes
请注意，此升级过程专门用于在云或本地中手动安装Kubernetes。它不涵盖托管的Kubernetes环境或公共云上的Kubernetes服务（例如AWS的EKS或Azure Kubernetes服务），它们具有自己的升级过程。
就本教程而言，我们假设是配置了Kubernetes版本是v1.13的3个主节点和一个工作节点。
3个Kubernetes主节点：
1个v1.13的工作节点：
Kubernetes主站点上记录了升级Kubernetes主节点的过程。
从v1.12升级到v1.13 HA
从v1.12升级到v1.13
从v1.13升级到v1.14
从v1.14升级到v1.15
在此示例中，我们将看到从v1.13升级到v.1.14 HA的升级路径。不建议跳过版本（例如，从v1.13升级到v.1.15）。
在开始之前，我们应该始终检查要升级的版本的发行说明，以防它们提及重大更改。
Kubernetes集群：升级指南
让我们现在按照升级步骤进行操作：
1. 登录第一个节点并仅升级kubeadm工具：
$ ssh admin@10.0.11.1 $ apt-mark unhold kubeadm && \ $ apt-get update && apt-get install -y kubeadm=1.13.0-00 && apt-mark hold kubeadm
我们运行apt-mark unhold和apt-mark hold的原因是，如果我们升级kubeadm，则安装程序将默认自动将其他组件（例如kubelet）升级到最新版本（v1.15），这会造成软件包升级。
为了解决这个问题，我们使用hold将软件包标记为已保留，这将阻止软件包被自动安装，升级或删除。
2. 验证升级计划：
$ kubeadm upgrade plan ... COMPONENT CURRENT AVAILABLE API Server v1.13.0 v1.14.0 Controller Manager v1.13.0 v1.14.0 Scheduler v1.13.0 v1.14.0 Kube Proxy v1.13.0 v1.14.0 ...
3. 应用升级计划：
$ kubeadm upgrade plan apply v1.14.0
4. 更新Kubelet并重新启动服务：
$ apt-mark unhold kubelet && apt-get update && apt-get install -y kubelet=1.14.0-00 && apt-mark hold kubelet $ systemctl restart kubelet
5. 将升级计划应用于其他主节点：
$ ssh admin@10.0.11.2 $ kubeadm upgrade node experimental-control-plane $ ssh admin@10.0.11.3 $ kubeadm upgrade node experimental-control-plane
6. 在所有主节点上升级kubectl：
$ apt-mark unhold kubectl && apt-get update && apt-get install -y kubectl=1.14.0-00 && apt-mark hold kubectl
7. 在工作节点上升级kubeadm：
$ ssh worker@10.0.12.1 $ apt-mark unhold kubeadm && apt-get update && apt-get install -y kubeadm=1.14.0-00 && apt-mark hold kubeadm
8. 登录到主节点并驱逐第一个工作节点：
$ ssh admin@10.0.11.1 $ kubectl drain worker --ignore-daemonsets
9. 在工作节点上升级kubelet配置：
$ ssh worker@10.0.12.1 $ kubeadm upgrade node config --kubelet-version v1.14.0
10. 在工作节点上升级kubelet并重新启动服务：
$ apt-mark unhold kubelet && apt-get update && apt-get install -y kubelet=1.14.0-00 && apt-mark hold kubelet $ systemctl restart kubelet
11. 恢复工作节点：
$ ssh admin@10.0.11.1 $ kubectl uncordon workerStep 12: Repeat steps 7-11 for the rest of the worker nodes.Step 13: Verify the health of the cluster: $ kubectl get nodes
升级Etcd
Etcd是用于共享配置和服务发现的分布式，一致性的KV存储系统。当我们运行高可用的 Kubernetes集群时，我们也想运行高可用的etcd集群。这样在某些节点出现故障，我们能有一个回退。
通常，我们至少要有3个etcd节点。etcd存储库中记录了升级etcd节点的过程。
从2.3升级到3.0
从3.0升级到3.1
从3.1升级到3.2
从3.2升级到3.3
从3.3升级到3.4
从3.4升级到3.5
在计划进行etcd升级时，应始终遵循以下计划：
检查你使用的版本。例如
$ ./etcdctl endpoint status
不要跳超过一个版本。例如，不要从3.3升级到3.5。而是从3.3到3.4，然后从3.4到3.5。
使用对应的Kubernetes etcd镜像。Kubernetes团队了维护了一个自定义etcd镜像的，其中包含用于多个etcd版本的etcd和etcdctl二进制文件，以及用于升级和降级etcd的迁移操作的实用程序。这将帮助你自动化迁移和升级etcd实例的过程。
其中最重要的变化是从etcd2.3到etcd3.0，有一个主要的API的变化。
你还应注意：
Etcd v3能够处理对v2和v3数据的请求。例如，我们可以使用环境变量ETCDCTL_API 来指定API版本：
$ ETCDCTL_API=2 ./etcdctl endpoint status
使用etcdv3 api操作etcd v2数据，不会自动将数据目录升级为v3格式。 使用etcdv2 api操作etcd v3，仅更新存储在etcd中的v2数据。
你可能还会想知道Kubernetes版本和etcd版本的对应关系。
Kubernetes v1.0：仅支持etcd2 Kubernetes v1.5.1：添加了etcd3支持，新集群仍然默认为etcd Kubernetes v1.6.0：使用kube-up.sh创建的新集群默认为etcd3，而kube-apiserver默认为etcd3 Kubernetes v1.9.0：宣布弃用etcd2 Kubernetes v1.13.0：删除etcd2存储，kube-apiserver将拒绝以–storage-backend = etcd2开头。
因此，基于该信息，如果你正在运行带有etcd2的Kubernetes v1.12.0，那么当你将Kubernetes升级到v1.13.0时，由于不支持–storage-backend = etcd3，因此你需要将etcd升级到v3 。如果你具有Kubernetes v1.12.0及更低版本，则可以同时运行etcd2和etcd3。
执行每一步之前，我们应该始终执行基本的维护操作，如定期快照和定期备份。确保检查集群的运行状况的健康。
假设我们有以下etcd集群节点：
$ ./etcdctl cluster-healthmember 6e3bd23ae5f1eae2 is healthy: got healthy result from http://10.0.1.1:22379member 924e2e83f93f2565 is healthy: got healthy result from http://10.0.1.2:22379member 8211f1d0a64f3269 is healthy: got healthy result from http://10.0.1.3:22379cluster is healthy
升级Etcd集群：升级指南
基于上述考虑，典型的升级etcd过程包括以下步骤：
1. 登录到第一个节点并停止现有的etcd进程：
$ ssh 10.0.1.1$ kill `pgrep etcd`
2. 备份etcd数据目录以在出现错误时提供降级路径：
$ ./etcdctl backup \--data-dir %data_dir% \ [--wal-dir %wal_dir%] \--backup-dir %backup_data_dir% [--backup-wal-dir %backup_wal_dir%]
3. 下载新的etcd二进制文件，并使用相同的配置启动etcd服务器：
ETCD_VER=v3.3.15# choose either URLGOOGLE_URL=https://storage.googleapis.com/etcdGITHUB_URL=https://github.com/etcd-io/etcd/releases/downloadDOWNLOAD_URL=${GOOGLE_URL}rm -f /tmp/etcd-${ETCD_VER}-linux-amd64.tar.gzrm -rf /usr/local/etcd && mkdir -p /usr/local/etcdcurl -L ${DOWNLOAD_URL}/${ETCD_VER}/etcd-${ETCD_VER}-linux-amd64.tar.gz -o /tmp/etcd-${ETCD_VER}-linux-amd64.tar.gztar xzvf /tmp/etcd-${ETCD_VER}-linux-amd64.tar.gz -C /usr/local/etcd --strip-components=1rm -f /tmp/etcd-${ETCD_VER}-linux-amd64.tar.gz/usr/local/etcd/etcd --versionETCDCTL_API=3 /usr/local/etcd/etcdctl version# start etcd server/usr/local/etcd/etcd -name etcd-1 -listen-peer-urls http://10.0.1.1:2380 -listen-client-urls http://10.0.1.1:2379,http://127.0.0.1:2379 -advertise-client-urls http://10.0.1.1:2379,http://127.0.0.1:2379
4. 对所有其他节点重复步骤1到步骤3
5. 验证集群是否正常：
$ ./etcdctl endpoint health10.0.1.1:12379 is healthy: successfully committed proposal: took =10.0.1.2:12379 is healthy: successfully committed proposal: took =10.0.1.3:12379 is healthy: successfully committed proposal: took =
注意：如果在连接到集群时遇到问题，则可能需要提供HTTPS证书。例如：
$ ./etcdctl --ca-file=/etc/kubernetes/pki/etcd/ca.crt --cert-file=/etc/kubernetes/pki/etcd/server.crt --key-file=/etc/kubernetes/pki/etcd/server.key endpoint health
为了方便起见，可以使用以下环境变量：
ETCD_CA_FILE=/etc/kubernetes/pki/etcd/ca.crtETCD_CERT_FILE=/etc/kubernetes/pki/etcd/server.crtETCD_KEY_FILE=/etc/kubernetes/pki/etcd/server.key
温馨提示：文章内容系作者个人观点，不代表Docker中文社区对观点赞同或支持。
版权声明：本文为转载文章，来源于 互联网 ，版权归原作者所有，欢迎分享本文，转载请保留出处！
发表评论