您正在查看 Kubernetes 版本的文档: v1.18
Kubernetes v1.18 版本的文档已不再维护。您现在看到的版本来自于一份静态的快照。如需查阅最新文档,请点击 最新版本。
升级 kubeadm 集群
本页介绍如何将 kubeadm
创建的 Kubernetes 集群从 1.17.x 版本升级到 1.18.x 版本,
或者从版本 1.18.x 升级到 1.18.y ,其中 y > x
。
要查看 kubeadm 创建的有关旧版本集群升级的信息,请参考以下页面:
- 将 kubeadm 集群从 1.16 升级到 1.17
- 将 kubeadm 集群从 1.15 升级到 1.16
- 将 kubeadm 集群从 1.14 升级到 1.15
- 将 kubeadm 集群从 1.13 升级到 1.14
升级工作的基本流程如下:
- 升级主控制平面节点
- 升级其他控制平面节点
- 升级工作节点
准备开始
- 你需要有一个由
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 配置