您正在查看 Kubernetes 版本的文档： v1.18

Kubernetes v1.18 版本的文档已不再维护。您现在看到的版本来自于一份静态的快照。如需查阅最新文档，请点击 最新版本。

Edit This Page

升级 kubeadm 集群

本页介绍如何将 kubeadm 创建的 Kubernetes 集群从 1.17.x 版本升级到 1.18.x 版本， 或者从版本 1.18.x 升级到 1.18.y ，其中 y > x。

要查看 kubeadm 创建的有关旧版本集群升级的信息，请参考以下页面：

升级工作的基本流程如下：

  1. 升级主控制平面节点
  2. 升级其他控制平面节点
  3. 升级工作节点

准备开始

  • 你需要有一个由 kubeadm 创建并运行着 1.17.0 或更高版本的 Kubernetes 集群。
  • 禁用交换分区。
  • 集群应使用静态的控制平面和 etcd Pod 或者 外部 etcd。
  • 务必仔细认真阅读发行说明。
  • 务必备份所有重要组件，例如存储在数据库中应用层面的状态。 kubeadm upgrade 不会影响你的工作负载，只会涉及 Kubernetes 内部的组件，但备份终究是好的。

附加信息

  • 升级后，因为容器规约的哈希值已更改，所有容器都会被重新启动。
  • 你只能从一个次版本升级到下一个次版本，或者在次版本相同时升级补丁版本。 也就是说，升级时不可以跳过次版本。 例如，你只能从 1.y 升级到 1.y+1，而不能从 from 1.y 升级到 1.y+2。

确定要升级到哪个版本

找到最新的稳定版 1.18：

apt update
apt-cache policy kubeadm
# 在列表中查找最新的 1.18 版本
# 它看起来应该是 1.18.x-00 ，其中 x 是最新的补丁

yum list --showduplicates kubeadm --disableexcludes=kubernetes
# 在列表中查找最新的 1.18 版本
# 它看起来应该是 1.18.x-0 ，其中 x 是最新的补丁版本

升级控制平面节点

升级第一个控制面节点

  • 在第一个控制平面节点上，升级 kubeadm :
# 用最新的修补程序版本替换 1.18.x-00 中的 x
apt-mark unhold kubeadm && \
apt-get update && apt-get install -y kubeadm=1.18.x-00 && \
apt-mark hold kubeadm

# 用最新的修补程序版本替换 1.18.x-0 中的 x
yum install -y kubeadm-1.18.x-0 --disableexcludes=kubernetes

  • 验证下载操作正常，并且 kubeadm 版本正确：

    kubeadm version

  • 腾空控制平面节点：

    # 将 <cp-node-name> 替换为你自己的控制面节点名称
kubectl drain <cp-node-name> --ignore-daemonsets

  • 在控制面节点上，运行:

    sudo kubeadm upgrade plan

    你应该可以看到与下面类似的输出：

    [upgrade/config] Making sure the configuration is correct:
[upgrade/config] Reading configuration from the cluster...
[upgrade/config] FYI: You can look at this config file with 'kubectl -n kube-system get cm kubeadm-config -oyaml'
[preflight] Running pre-flight checks.
[upgrade] Running cluster health checks
[upgrade] Fetching available versions to upgrade to
[upgrade/versions] Cluster version: v1.17.3
[upgrade/versions] kubeadm version: v1.18.0
[upgrade/versions] Latest stable version: v1.18.0
[upgrade/versions] Latest version in the v1.17 series: v1.18.0

Components that must be upgraded manually after you have upgraded the control plane with 'kubeadm upgrade apply':
COMPONENT   CURRENT             AVAILABLE
Kubelet     1 x v1.17.3   v1.18.0

Upgrade to the latest version in the v1.17 series:

COMPONENT            CURRENT   AVAILABLE
API Server           v1.17.3   v1.18.0
Controller Manager   v1.17.3   v1.18.0
Scheduler            v1.17.3   v1.18.0
Kube Proxy           v1.17.3   v1.18.0
CoreDNS              1.6.5     1.6.7
Etcd                 3.4.3     3.4.3-0

You can now apply the upgrade by executing the following command:

    kubeadm upgrade apply v1.18.0

_____________________________________________________________________

    此命令检查你的集群是否可以升级，并可以获取到升级的版本。

说明： kubeadm upgrade 也会自动对它在此节点上管理的证书进行续约。 如果选择不对证书进行续约，可以使用标志 --certificate-renewal=false。 关于更多细节信息，可参见证书管理指南。

  • 选择要升级到的版本，然后运行相应的命令。例如:

    # 将 x 替换为你为此次升级所选的补丁版本号
sudo kubeadm upgrade apply v1.18.x

    你应该可以看见与下面类似的输出：

    [upgrade/config] Making sure the configuration is correct:
[upgrade/config] Reading configuration from the cluster...
[upgrade/config] FYI: You can look at this config file with 'kubectl -n kube-system get cm kubeadm-config -oyaml'
[preflight] Running pre-flight checks.
[upgrade] Running cluster health checks
[upgrade/version] You have chosen to change the cluster version to "v1.18.0"
[upgrade/versions] Cluster version: v1.17.3
[upgrade/versions] kubeadm version: v1.18.0
[upgrade/confirm] Are you sure you want to proceed with the upgrade? [y/N]: y
[upgrade/prepull] Will prepull images for components [kube-apiserver kube-controller-manager kube-scheduler etcd]
[upgrade/prepull] Prepulling image for component etcd.
[upgrade/prepull] Prepulling image for component kube-apiserver.
[upgrade/prepull] Prepulling image for component kube-controller-manager.
[upgrade/prepull] Prepulling image for component kube-scheduler.
[apiclient] Found 1 Pods for label selector k8s-app=upgrade-prepull-kube-controller-manager
[apiclient] Found 0 Pods for label selector k8s-app=upgrade-prepull-etcd
[apiclient] Found 0 Pods for label selector k8s-app=upgrade-prepull-kube-scheduler
[apiclient] Found 1 Pods for label selector k8s-app=upgrade-prepull-kube-apiserver
[apiclient] Found 1 Pods for label selector k8s-app=upgrade-prepull-etcd
[apiclient] Found 1 Pods for label selector k8s-app=upgrade-prepull-kube-scheduler
[upgrade/prepull] Prepulled image for component etcd.
[upgrade/prepull] Prepulled image for component kube-apiserver.
[upgrade/prepull] Prepulled image for component kube-controller-manager.
[upgrade/prepull] Prepulled image for component kube-scheduler.
[upgrade/prepull] Successfully prepulled the images for all the control plane components
[upgrade/apply] Upgrading your Static Pod-hosted control plane to version "v1.18.0"...
Static pod: kube-apiserver-myhost hash: 2cc222e1a577b40a8c2832320db54b46
Static pod: kube-controller-manager-myhost hash: f7ce4bc35cb6e646161578ac69910f18
Static pod: kube-scheduler-myhost hash: e3025acd90e7465e66fa19c71b916366
[upgrade/etcd] Upgrading to TLS for etcd
[upgrade/etcd] Non fatal issue encountered during upgrade: the desired etcd version for this Kubernetes version "v1.18.0" is "3.4.3-0", but the current etcd version is "3.4.3". Won't downgrade etcd, instead just continue
[upgrade/staticpods] Writing new Static Pod manifests to "/etc/kubernetes/tmp/kubeadm-upgraded-manifests308527012"
W0308 18:48:14.535122    3082 manifests.go:225] the default kube-apiserver authorization-mode is "Node,RBAC"; using "Node,RBAC"
[upgrade/staticpods] Preparing for "kube-apiserver" upgrade
[upgrade/staticpods] Renewing apiserver certificate
[upgrade/staticpods] Renewing apiserver-kubelet-client certificate
[upgrade/staticpods] Renewing front-proxy-client certificate
[upgrade/staticpods] Renewing apiserver-etcd-client certificate
[upgrade/staticpods] Moved new manifest to "/etc/kubernetes/manifests/kube-apiserver.yaml" and backed up old manifest to "/etc/kubernetes/tmp/kubeadm-backup-manifests-2020-03-08-18-48-14/kube-apiserver.yaml"
[upgrade/staticpods] Waiting for the kubelet to restart the component
[upgrade/staticpods] This might take a minute or longer depending on the component/version gap (timeout 5m0s)
Static pod: kube-apiserver-myhost hash: 2cc222e1a577b40a8c2832320db54b46
Static pod: kube-apiserver-myhost hash: 609429acb0d71dce6725836dd97d8bf4
[apiclient] Found 1 Pods for label selector component=kube-apiserver
[upgrade/staticpods] Component "kube-apiserver" upgraded successfully!
[upgrade/staticpods] Preparing for "kube-controller-manager" upgrade
[upgrade/staticpods] Renewing controller-manager.conf certificate
[upgrade/staticpods] Moved new manifest to "/etc/kubernetes/manifests/kube-controller-manager.yaml" and backed up old manifest to "/etc/kubernetes/tmp/kubeadm-backup-manifests-2020-03-08-18-48-14/kube-controller-manager.yaml"
[upgrade/staticpods] Waiting for the kubelet to restart the component
[upgrade/staticpods] This might take a minute or longer depending on the component/version gap (timeout 5m0s)
Static pod: kube-controller-manager-myhost hash: f7ce4bc35cb6e646161578ac69910f18
Static pod: kube-controller-manager-myhost hash: c7a1232ba2c5dc15641c392662fe5156
[apiclient] Found 1 Pods for label selector component=kube-controller-manager
[upgrade/staticpods] Component "kube-controller-manager" upgraded successfully!
[upgrade/staticpods] Preparing for "kube-scheduler" upgrade
[upgrade/staticpods] Renewing scheduler.conf certificate
[upgrade/staticpods] Moved new manifest to "/etc/kubernetes/manifests/kube-scheduler.yaml" and backed up old manifest to "/etc/kubernetes/tmp/kubeadm-backup-manifests-2020-03-08-18-48-14/kube-scheduler.yaml"
[upgrade/staticpods] Waiting for the kubelet to restart the component
[upgrade/staticpods] This might take a minute or longer depending on the component/version gap (timeout 5m0s)
Static pod: kube-scheduler-myhost hash: e3025acd90e7465e66fa19c71b916366
Static pod: kube-scheduler-myhost hash: b1b721486ae0ac504c160dcdc457ab0d
[apiclient] Found 1 Pods for label selector component=kube-scheduler
[upgrade/staticpods] Component "kube-scheduler" upgraded successfully!
[upload-config] Storing the configuration used in ConfigMap "kubeadm-config" in the "kube-system" Namespace
[kubelet] Creating a ConfigMap "kubelet-config-1.18" in namespace kube-system with the configuration for the kubelets in the cluster
[kubelet-start] Downloading configuration for the kubelet from the "kubelet-config-1.18" ConfigMap in the kube-system namespace
[kubelet-start] Writing kubelet configuration to file "/var/lib/kubelet/config.yaml"
[bootstrap-token] configured RBAC rules to allow Node Bootstrap tokens to post CSRs in order for nodes to get long term certificate credentials
[bootstrap-token] configured RBAC rules to allow the csrapprover controller automatically approve CSRs from a Node Bootstrap Token
[bootstrap-token] configured RBAC rules to allow certificate rotation for all node client certificates in the cluster
[addons] Applied essential addon: CoreDNS
[addons] Applied essential addon: kube-proxy

[upgrade/successful] SUCCESS! Your cluster was upgraded to "v1.18.0". Enjoy!

[upgrade/kubelet] Now that your control plane is upgraded, please proceed with upgrading your kubelets if you haven't already done so.

  • 手动升级你的 CNI 驱动插件。

    你的容器网络接口（CNI）驱动应该提供了程序自身的升级说明。 参阅插件页面查找你 CNI 所提供的程序， 并查看是否需要其他升级步骤。

    如果 CNI 提供程序作为 DaemonSet 运行，则在其他控制平面节点上不需要此步骤。

  • 取消对控制面节点的保护

    # 将 <cp-node-name> 替换为你的控制面节点名称
kubectl uncordon <cp-node-name>

升级其他控制面节点

与第一个控制面节点类似，不过使用下面的命令：

sudo kubeadm upgrade node

而不是：

sudo kubeadm upgrade apply

同时，也不需要执行 sudo kubeadm upgrade plan。

升级 kubelet 和 kubectl

# 用最新的补丁版本替换 1.18.x-00 中的 x
apt-mark unhold kubelet kubectl && \
apt-get update && apt-get install -y kubelet=1.18.x-00 kubectl=1.18.x-00 && \
apt-mark hold kubelet kubectl

从 apt-get 的 1.1 版本开始，你也可以使用下面的方法：

apt-get update && \
apt-get install -y --allow-change-held-packages kubelet=1.18.x-00 kubectl=1.18.x-00

用最新的补丁版本替换 1.18.x-00 中的 x

yum install -y kubelet-1.18.x-0 kubectl-1.18.x-0 --disableexcludes=kubernetes

重启 kubelet

sudo systemctl daemon-reload
sudo systemctl restart kubelet

升级工作节点

工作节点上的升级过程应该一次执行一个节点，或者一次执行几个节点，以不影响运行工作负载所需的最小容量。

升级 kubeadm

  • 在所有工作节点升级 kubeadm:
# 将 1.18.x-00 中的 x 替换为最新的补丁版本
apt-mark unhold kubeadm && \
apt-get update && apt-get install -y kubeadm=1.18.x-00 && \
apt-mark hold kubeadm

从 apt-get 的 1.1 版本开始，你也可以使用下面的方法：

apt-get update && \
apt-get install -y --allow-change-held-packages kubeadm=1.18.x-00

# 用最新的补丁版本替换 1.18.x-00 中的 x
yum install -y kubeadm-1.18.x-0 --disableexcludes=kubernetes

保护节点

  • 通过将节点标记为不可调度并逐出工作负载，为维护做好准备。运行：

    # 将 <node-to-drain> 替换为你正在腾空的节点的名称
kubectl drain <node-to-drain> --ignore-daemonsets

    你应该可以看见与下面类似的输出：

    node/ip-172-31-85-18 cordoned
WARNING: ignoring DaemonSet-managed Pods: kube-system/kube-proxy-dj7d7, kube-system/weave-net-z65qx
node/ip-172-31-85-18 drained

升级 kubelet 配置

  • 升级 kubelet 配置:

    sudo kubeadm upgrade node

升级 kubelet 与 kubectl

  • 在所有工作节点上升级 kubelet 和 kubectl：
# 将 1.18.x-00 中的 x 替换为最新的补丁版本
apt-mark unhold kubelet kubectl && \
apt-get update && apt-get install -y kubelet=1.18.x-00 kubectl=1.18.x-00 && \
apt-mark hold kubelet kubectl

从 apt-get 的 1.1 版本开始，你也可以使用下面的方法：

apt-get update && \
apt-get install -y --allow-change-held-packages kubelet=1.18.x-00 kubectl=1.18.x-00

# 将 1.18.x-00 中的 x 替换为最新的补丁版本
yum install -y kubelet-1.18.x-0 kubectl-1.18.x-0 --disableexcludes=kubernetes

  • 重启 kubelet

    sudo systemctl daemon-reload
sudo systemctl restart kubelet

取消对节点的保护

  • 通过将节点标记为可调度，让节点重新上线:

    # 将 <node-to-drain> 替换为当前节点的名称
kubectl uncordon <node-to-drain>

验证集群的状态

在所有节点上升级 kubelet 后，通过从 kubectl 可以访问集群的任何位置运行以下命令，验证所有节点是否再次可用：

kubectl get nodes

STATUS 应显示所有节点为 Ready 状态，并且版本号已经被更新。

从故障状态恢复

如果 kubeadm upgrade 失败并且没有回滚，例如由于执行期间意外关闭，你可以再次运行 kubeadm upgrade。 此命令是幂等的，并最终确保实际状态是你声明的所需状态。 要从故障状态恢复，你还可以运行 kubeadm upgrade --force 而不去更改集群正在运行的版本。

在升级期间，kubeadm 向 /etc/kubernetes/tmp 目录下的如下备份文件夹写入数据：

  • kubeadm-backup-etcd-<date>-<time>
  • kubeadm-backup-manifests-<date>-<time>

kubeadm-backup-etcd 包含当前控制面节点本地 etcd 成员数据的备份。 如果 etcd 升级失败并且自动回滚也无法修复，则可以将此文件夹中的内容复制到 /var/lib/etcd 进行手工修复。如果使用的是外部的 etcd，则此备份文件夹为空。

kubeadm-backup-manifests 包含当前控制面节点的静态 Pod 清单文件的备份版本。 如果升级失败并且无法自动回滚，则此文件夹中的内容可以复制到 /etc/kubernetes/manifests 目录实现手工恢复。 如果由于某些原因，在升级前后某个组件的清单未发生变化，则 kubeadm 也不会为之 生成备份版本。

工作原理

kubeadm upgrade apply 做了以下工作：

  • 检查你的集群是否处于可升级状态:
    • API 服务器是可访问的
    • 所有节点处于 Ready 状态
    • 控制面是健康的
  • 强制执行版本 skew 策略。
  • 确保控制面的镜像是可用的或可拉取到服务器上。
  • 升级控制面组件或回滚（如果其中任何一个组件无法启动）。
  • 应用新的 kube-dns 和 kube-proxy 清单，并强制创建所有必需的 RBAC 规则。
  • 如果旧文件在 180 天后过期，将创建 API 服务器的新证书和密钥文件并备份旧文件。

kubeadm upgrade node 在其他控制平节点上执行以下操作：

  • 从集群中获取 kubeadm ClusterConfiguration。
  • 可选地备份 kube-apiserver 证书。
  • 升级控制平面组件的静态 Pod 清单。
  • 为本节点升级 kubelet 配置

kubeadm upgrade node 在工作节点上完成以下工作：

  • 从集群取回 kubeadm ClusterConfiguration。
  • 为本节点升级 kubelet 配置