Kubernetes升级：自己动手的权威指南

Kubernetes的部署很困难。这在很大程度上要归因于这样一个事实，即Kubernetes不仅是一个工具，而且是十几种组件的集合，这些组件提供了从应用程序部署和升级，日志记录和监视到持久数据存储的功能。

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 worker
Step 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-health
member 6e3bd23ae5f1eae2 is healthy: got healthy result from http://10.0.1.1:22379
member 924e2e83f93f2565 is healthy: got healthy result from http://10.0.1.2:22379
member 8211f1d0a64f3269 is healthy: got healthy result from http://10.0.1.3:22379
cluster 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 URL
GOOGLE_URL=https://storage.googleapis.com/etcd
GITHUB_URL=https://github.com/etcd-io/etcd/releases/download
DOWNLOAD_URL=${GOOGLE_URL}
​
rm -f /tmp/etcd-${ETCD_VER}-linux-amd64.tar.gz
rm -rf /usr/local/etcd && mkdir -p /usr/local/etcd
​
curl -L ${DOWNLOAD_URL}/${ETCD_VER}/etcd-${ETCD_VER}-linux-amd64.tar.gz -o /tmp/etcd-${ETCD_VER}-linux-amd64.tar.gz
tar xzvf /tmp/etcd-${ETCD_VER}-linux-amd64.tar.gz -C /usr/local/etcd --strip-components=1
rm -f /tmp/etcd-${ETCD_VER}-linux-amd64.tar.gz
​
/usr/local/etcd/etcd --version
ETCDCTL_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 health
10.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.crt
ETCD_CERT_FILE=/etc/kubernetes/pki/etcd/server.crt
ETCD_KEY_FILE=/etc/kubernetes/pki/etcd/server.key

译文链接:https://dzone.com/articles/kubernetes-upgrade-the-definitive-guide-to-do-it-yourself