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

ゞ浴缸里的玫瑰 2022-10-29 07:50 2阅读 0赞

> **原文发表于[kubernetes中文社区][kubernetes]，为作者原创翻译 ，[原文地址][Link 1]**
> 
> **更多kubernetes文章，请多关注[kubernetes中文社区][kubernetes 1]**

**目录**

升级Kubernetes

Kubernetes集群：升级指南

1. 登录第一个节点并仅升级kubeadm工具：

2. 验证升级计划：

3. 应用升级计划：

4. 更新Kubelet并重新启动服务：

5. 将升级计划应用于其他主节点：

6. 在所有主节点上升级kubectl：

7. 在工作节点上升级kubeadm：

8. 登录到主节点并驱逐第一个工作节点：

9. 在工作节点上升级kubelet配置：

10. 在工作节点上升级kubelet并重新启动服务：

11. 恢复工作节点：

升级Etcd

升级Etcd集群：升级指南

1. 登录到第一个节点并停止现有的etcd进程：

2. 备份etcd数据目录以在出现错误时提供降级路径：

3. 下载新的etcd二进制文件，并使用相同的配置启动etcd服务器：

4. 对所有其他节点重复步骤1到步骤3

5. 验证集群是否正常：

--------------------

![49469d5c05245de06bf5b4b6180dc2f7.png][]

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主节点：

<table> 
 <thead> 
  <tr> 
   <th>名称</th> 
   <th>地址</th> 
   <th>主机名</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>kube-1</td> 
   <td>10.0.11.1</td> 
   <td>kube-1.example.com</td> 
  </tr> 
  <tr> 
   <td>kube-2</td> 
   <td>10.0.11.2</td> 
   <td>kube-2.example.com</td> 
  </tr> 
  <tr> 
   <td>kube-3</td> 
   <td>10.0.11.3</td> 
   <td>kube-3.example.com</td> 
  </tr> 
 </tbody> 
</table>

1个v1.13的工作节点：

<table> 
 <thead> 
  <tr> 
   <th>名称</th> 
   <th>地址</th> 
   <th>主机名</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>worker</td> 
   <td>10.0.12.1</td> 
   <td>worker..example.com</td> 
  </tr> 
 </tbody> 
</table>

Kubernetes主站点上记录了升级Kubernetes主节点的过程。

*  [从v1.12升级到v1.13 HA][v1.12_v1.13 HA]
 *  [从v1.12升级到v1.13][v1.12_v1.13]
 *  [从v1.13升级到v1.14][v1.13_v1.14]
 *  [从v1.14升级到v1.15][v1.14_v1.15]

在此示例中，我们将看到从v1.13升级到v.1.14 HA的升级路径。不建议跳过版本（例如，从v1.13升级到v.1.15）。

在开始之前，我们应该始终检查要升级的版本的[发行说明][Link 2]，以防它们提及重大更改。

## 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][2.3_3.0]
 *  [从3.0升级到3.1][3.0_3.1]
 *  [从3.1升级到3.2][3.1_3.2]
 *  [从3.2升级到3.3][3.2_3.3]
 *  [从3.3升级到3.4][3.3_3.4]
 *  [从3.4升级到3.5][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版本的etcd和etcdctl二进制文件，以及用于升级和降级etcd的迁移操作的实用程序。这将帮助你自动化迁移和升级etcd实例的过程。

其中最重要的变化是从etcd2.3到etcd3.0，有一个[主要的API的变化][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。

执行每一步之前，我们应该始终执行基本的[维护操作][Link 3]，如定期快照和定期备份。确保检查集群的运行状况的健康。

假设我们有以下etcd集群节点：

<table> 
 <thead> 
  <tr> 
   <th>名称</th> 
   <th>地址</th> 
   <th>主机名</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>etcd-1</td> 
   <td>10.0.11.1</td> 
   <td>etcd-1.example.com</td> 
  </tr> 
  <tr> 
   <td>etcd-2</td> 
   <td>10.0.11.2</td> 
   <td>etcd-2.example.com</td> 
  </tr> 
  <tr> 
   <td>etcd-3</td> 
   <td>10.0.11.3</td> 
   <td>etcd-3.example.com</td> 
  </tr> 
 </tbody> 
</table>

$ ./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][https_dzone.com_articles_kubernetes-upgrade-the-definitive-guide-to-do-it-yourself]

[kubernetes]: https://www.kubernetes.org.cn/
[Link 1]: http://ttps//www.kubernetes.org.cn/8877.html
[kubernetes 1]: https://glory.blog.csdn.net/article/details/112467716
[49469d5c05245de06bf5b4b6180dc2f7.png]: /images/20221024/690319b8da78453bb01354992648bdf1.png
[v1.12_v1.13 HA]: https://kubernetes.io/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade-ha-1-13/
[v1.12_v1.13]: https://kubernetes.io/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade-1-13/
[v1.13_v1.14]: https://kubernetes.io/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade-1-14/
[v1.14_v1.15]: https://kubernetes.io/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade-1-15/
[Link 2]: https://v1-14.docs.kubernetes.io/docs/setup/release/notes/
[2.3_3.0]: https://github.com/etcd-io/etcd/blob/master/Documentation/upgrades/upgrade_3_0.md
[3.0_3.1]: https://github.com/etcd-io/etcd/blob/master/Documentation/upgrades/upgrade_3_1.md
[3.1_3.2]: https://github.com/etcd-io/etcd/blob/master/Documentation/upgrades/upgrade_3_2.md
[3.2_3.3]: https://github.com/etcd-io/etcd/blob/master/Documentation/upgrades/upgrade_3_3.md
[3.3_3.4]: https://github.com/etcd-io/etcd/blob/master/Documentation/upgrades/upgrade_3_4.md
[3.4_3.5]: https://github.com/etcd-io/etcd/blob/master/Documentation/upgrades/upgrade_3_5.md
[etcd]: https://github.com/kubernetes/kubernetes/tree/master/cluster/images/etcd
[API]: https://github.com/etcd-io/etcd/blob/master/Documentation/op-guide/v2-migration.md
[Link 3]: https://github.com/etcd-io/etcd/blob/master/Documentation/op-guide/maintenance.md#snapshot-backup
[https_dzone.com_articles_kubernetes-upgrade-the-definitive-guide-to-do-it-yourself]: https://dzone.com/articles/kubernetes-upgrade-the-definitive-guide-to-do-it-yourself