升级 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-dnskube-proxy 清单,并强制创建所有必需的 RBAC 规则。
  • 如果旧文件在 180 天后过期,将创建 API 服务器的新证书和密钥文件并备份旧文件。

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

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

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

  • 从集群取回 kubeadm ClusterConfiguration
  • 为本节点升级 kubelet 配置
最后修改 August 16, 2020 at 11:05 AM PST: [zh] Tidy up and fix links in tasks section (8/10) (c2aae6890)