1 - 配置 cgroup 驱动

本页阐述如何配置 kubelet 的 cgroup 驱动以匹配 kubeadm 集群中的容器运行时的 cgroup 驱动。

准备开始

你应该熟悉 Kubernetes 的容器运行时需求

配置容器运行时 cgroup 驱动

容器运行时页面提到: 由于 kubeadm 把 kubelet 视为一个系统服务来管理,所以对基于 kubeadm 的安装, 我们推荐使用 systemd 驱动,不推荐 cgroupfs 驱动。

此页还详述了如何安装若干不同的容器运行时,并将 systemd 设为其默认驱动。

配置 kubelet 的 cgroup 驱动

kubeadm 支持在执行 kubeadm init 时,传递一个 KubeletConfiguration 结构体。 KubeletConfiguration 包含 cgroupDriver 字段,可用于控制 kubelet 的 cgroup 驱动。

这是一个最小化的示例,其中显式的配置了此字段:

# kubeadm-config.yaml
kind: ClusterConfiguration
apiVersion: kubeadm.k8s.io/v1beta3
kubernetesVersion: v1.21.0
---
kind: KubeletConfiguration
apiVersion: kubelet.config.k8s.io/v1beta1
cgroupDriver: systemd

这样一个配置文件就可以传递给 kubeadm 命令了:

kubeadm init --config kubeadm-config.yaml

使用 cgroupfs 驱动

如仍需使用 cgroupfs 且要防止 kubeadm upgrade 修改现有系统中 KubeletConfiguration 的 cgroup 驱动,你必须显式声明它的值。 此方法应对的场景为:在将来某个版本的 kubeadm 中,你不想使用默认的 systemd 驱动。

参阅以下章节“修改 kubelet 的 ConfigMap ”,了解显式设置该值的方法。

如果你希望配置容器运行时来使用 cgroupfs 驱动, 则必须参考所选容器运行时的文档。

迁移到 systemd 驱动

要将现有 kubeadm 集群的 cgroup 驱动就地升级为 systemd, 需要执行一个与 kubelet 升级类似的过程。 该过程必须包含下面两个步骤:

修改 kubelet 的 ConfigMap

  • 运行 kubectl edit cm kubelet-config -n kube-system

  • 修改现有 cgroupDriver 的值,或者新增如下式样的字段:

    cgroupDriver: systemd
    

    该字段必须出现在 ConfigMap 的 kubelet: 小节下。

更新所有节点的 cgroup 驱动

对于集群中的每一个节点:

  • 执行命令 kubectl drain <node-name> --ignore-daemonsets,以 腾空节点
  • 执行命令 systemctl stop kubelet,以停止 kubelet
  • 停止容器运行时
  • 修改容器运行时 cgroup 驱动为 systemd
  • 在文件 /var/lib/kubelet/config.yaml 中添加设置 cgroupDriver: systemd
  • 启动容器运行时
  • 执行命令 systemctl start kubelet,以启动 kubelet
  • 执行命令 kubectl uncordon <node-name>,以 取消节点隔离

在节点上依次执行上述步骤,确保工作负载有充足的时间被调度到其他节点。

流程完成后,确认所有节点和工作负载均健康如常。

2 - 使用 kubeadm 进行证书管理

特性状态: Kubernetes v1.15 [stable]

kubeadm 生成的客户端证书在 1 年后到期。 本页说明如何使用 kubeadm 管理证书续订,同时也涵盖其他与 kubeadm 证书管理相关的说明。

准备开始

你应该熟悉 Kubernetes 中的 PKI 证书和要求

使用自定义的证书

默认情况下,kubeadm 会生成运行一个集群所需的全部证书。 你可以通过提供你自己的证书来改变这个行为策略。

如果要这样做,你必须将证书文件放置在通过 --cert-dir 命令行参数或者 kubeadm 配置中的 certificatesDir 配置项指明的目录中。默认的值是 /etc/kubernetes/pki

如果在运行 kubeadm init 之前存在给定的证书和私钥对,kubeadm 将不会重写它们。 例如,这意味着你可以将现有的 CA 复制到 /etc/kubernetes/pki/ca.crt/etc/kubernetes/pki/ca.key 中,而 kubeadm 将使用此 CA 对其余证书进行签名。

外部 CA 模式

只提供了 ca.crt 文件但是不提供 ca.key 文件也是可以的 (这只对 CA 根证书可用,其它证书不可用)。 如果所有的其它证书和 kubeconfig 文件已就绪,kubeadm 检测到满足以上条件就会激活 "外部 CA" 模式。kubeadm 将会在没有 CA 密钥文件的情况下继续执行。

否则,kubeadm 将独立运行 controller-manager,附加一个 --controllers=csrsigner 的参数,并且指明 CA 证书和密钥。

PKI 证书和要求包括集群使用外部 CA 的设置指南。

检查证书是否过期

你可以使用 check-expiration 子命令来检查证书何时过期

kubeadm certs check-expiration

输出类似于以下内容:

CERTIFICATE                EXPIRES                  RESIDUAL TIME   CERTIFICATE AUTHORITY   EXTERNALLY MANAGED
admin.conf                 Dec 30, 2020 23:36 UTC   364d                                    no
apiserver                  Dec 30, 2020 23:36 UTC   364d            ca                      no
apiserver-etcd-client      Dec 30, 2020 23:36 UTC   364d            etcd-ca                 no
apiserver-kubelet-client   Dec 30, 2020 23:36 UTC   364d            ca                      no
controller-manager.conf    Dec 30, 2020 23:36 UTC   364d                                    no
etcd-healthcheck-client    Dec 30, 2020 23:36 UTC   364d            etcd-ca                 no
etcd-peer                  Dec 30, 2020 23:36 UTC   364d            etcd-ca                 no
etcd-server                Dec 30, 2020 23:36 UTC   364d            etcd-ca                 no
front-proxy-client         Dec 30, 2020 23:36 UTC   364d            front-proxy-ca          no
scheduler.conf             Dec 30, 2020 23:36 UTC   364d                                    no

CERTIFICATE AUTHORITY   EXPIRES                  RESIDUAL TIME   EXTERNALLY MANAGED
ca                      Dec 28, 2029 23:36 UTC   9y              no
etcd-ca                 Dec 28, 2029 23:36 UTC   9y              no
front-proxy-ca          Dec 28, 2029 23:36 UTC   9y              no

该命令显示 /etc/kubernetes/pki 文件夹中的客户端证书以及 kubeadm(admin.confcontroller-manager.confscheduler.conf) 使用的 kubeconfig 文件中嵌入的客户端证书的到期时间/剩余时间。

另外,kubeadm 会通知用户证书是否由外部管理; 在这种情况下,用户应该小心的手动/使用其他工具来管理证书更新。

自动更新证书

kubeadm 会在控制面升级的时候更新所有证书。

这个功能旨在解决最简单的用例;如果你对此类证书的更新没有特殊要求, 并且定期执行 Kubernetes 版本升级(每次升级之间的间隔时间少于 1 年), 则 kubeadm 将确保你的集群保持最新状态并保持合理的安全性。

如果你对证书更新有更复杂的需求,则可通过将 --certificate-renewal=false 传递给 kubeadm upgrade apply 或者 kubeadm upgrade node,从而选择不采用默认行为。

手动更新证书

你能随时通过 kubeadm certs renew 命令手动更新你的证书。

此命令用 CA(或者 front-proxy-CA )证书和存储在 /etc/kubernetes/pki 中的密钥执行更新。

执行完此命令之后你需要重启控制面 Pods。因为动态证书重载目前还不被所有组件和证书支持,所有这项操作是必须的。 静态 Pods 是被本地 kubelet 而不是 API Server 管理, 所以 kubectl 不能用来删除或重启他们。 要重启静态 Pod 你可以临时将清单文件从 /etc/kubernetes/manifests/ 移除并等待 20 秒 (参考 KubeletConfiguration 结构 中的fileCheckFrequency 值)。 如果 Pod 不在清单目录里,kubelet 将会终止它。 在另一个 fileCheckFrequency 周期之后你可以将文件移回去,为了组件可以完成 kubelet 将重新创建 Pod 和证书更新。

kubeadm certs renew 提供以下选项:

  • Kubernetes 证书通常在一年后到期。
  • --csr-only 可用于经过一个外部 CA 生成的证书签名请求来更新证书(无需实际替换更新证书); 更多信息请参见下节。

  • 可以更新单个证书而不是全部证书。

用 Kubernetes 证书 API 更新证书

本节提供有关如何使用 Kubernetes 证书 API 执行手动证书更新的更多详细信息。

设置一个签名者(Signer)

Kubernetes 证书颁发机构不是开箱即用。你可以配置外部签名者,例如 cert-manager, 也可以使用内置签名者。

内置签名者是 kube-controller-manager 的一部分。

要激活内置签名者,请传递 --cluster-signing-cert-file--cluster-signing-key-file 参数。

如果你正在创建一个新的集群,你可以使用 kubeadm 的配置文件

apiVersion: kubeadm.k8s.io/v1beta3
kind: ClusterConfiguration
controllerManager:
  extraArgs:
    cluster-signing-cert-file: /etc/kubernetes/pki/ca.crt
    cluster-signing-key-file: /etc/kubernetes/pki/ca.key

创建证书签名请求 (CSR)

有关使用 Kubernetes API 创建 CSR 的信息, 请参见创建 CertificateSigningRequest

通过外部 CA 更新证书

本节提供有关如何使用外部 CA 执行手动更新证书的更多详细信息。

为了更好的与外部 CA 集成,kubeadm 还可以生成证书签名请求(CSR)。 CSR 表示向 CA 请求客户的签名证书。 在 kubeadm 术语中,通常由磁盘 CA 签名的任何证书都可以作为 CSR 生成。但是,CA 不能作为 CSR 生成。

创建证书签名请求 (CSR)

你可以通过 kubeadm certs renew --csr-only 命令创建证书签名请求。

CSR 和随附的私钥都在输出中给出。 你可以传入一个带有 --csr-dir 的目录,将 CSR 输出到指定位置。 如果未指定 --csr-dir,则使用默认证书目录(/etc/kubernetes/pki)。

证书可以通过 kubeadm certs renew --csr-only 来续订。 和 kubeadm init 一样,可以使用 --csr-dir 标志指定一个输出目录。

CSR 中包含一个证书的名字,域和 IP,但是未指定用法。 颁发证书时,CA 有责任指定正确的证书用法

使用首选方法对证书签名后,必须将证书和私钥复制到 PKI 目录(默认为 /etc/kubernetes/pki)。

证书机构(CA)轮换

kubeadm 并不直接支持对 CA 证书的轮换或者替换。

关于手动轮换或者置换 CA 的更多信息, 可参阅手动轮换 CA 证书

启用已签名的 kubelet 服务证书

默认情况下,kubeadm 所部署的 kubelet 服务证书是自签名(Self-Signed)。 这意味着从 metrics-server 这类外部服务发起向 kubelet 的链接时无法使用 TLS 来完成保护。

要在新的 kubeadm 集群中配置 kubelet 以使用被正确签名的服务证书, 你必须向 kubeadm init 传递如下最小配置数据:

apiVersion: kubeadm.k8s.io/v1beta3
kind: ClusterConfiguration
---
apiVersion: kubelet.config.k8s.io/v1beta1
kind: KubeletConfiguration
serverTLSBootstrap: true

如果你已经创建了集群,你必须通过执行下面的操作来完成适配:

  • 找到 kube-system 名字空间中名为 kubelet-config-1.26 的 ConfigMap 并编辑之。 在该 ConfigMap 中,kubelet 键下面有一个 KubeletConfiguration 文档作为其取值。编辑该 KubeletConfiguration 文档以设置 serverTLSBootstrap: true
  • 在每个节点上,在 /var/lib/kubelet/config.yaml 文件中添加 serverTLSBootstrap: true 字段,并使用 systemctl restart kubelet 来重启 kubelet。

字段 serverTLSBootstrap 将允许启动引导 kubelet 的服务证书,方式是从 certificates.k8s.io API 处读取。这种方式的一种局限在于这些证书的 CSR(证书签名请求)不能被 kube-controller-manager 中默认的签名组件 kubernetes.io/kubelet-serving 批准。需要用户或者第三方控制器来执行此操作。

可以使用下面的命令来查看 CSR:

kubectl get csr
NAME        AGE     SIGNERNAME                        REQUESTOR                      CONDITION
csr-9wvgt   112s    kubernetes.io/kubelet-serving     system:node:worker-1           Pending
csr-lz97v   1m58s   kubernetes.io/kubelet-serving     system:node:control-plane-1    Pending

你可以执行下面的操作来批准这些请求:

kubectl certificate approve <CSR-名称>

默认情况下,这些服务证书会在一年后过期。 kubeadm 将 KubeletConfigurationrotateCertificates 字段设置为 true;这意味着证书快要过期时,会生成一组针对服务证书的新的 CSR,而这些 CSR 也要被批准才能完成证书轮换。要进一步了解这里的细节, 可参阅证书轮换文档。

如果你在寻找一种能够自动批准这些 CSR 的解决方案,建议你与你的云提供商 联系,询问他们是否有 CSR 签名组件,用来以带外(out-of-band)的方式检查 节点的标识符。

也可以使用第三方定制的控制器:

除非既能够验证 CSR 中的 CommonName,也能检查请求的 IP 和域名, 这类控制器还算不得安全的机制。 只有完成彻底的检查,才有可能避免有恶意的、能够访问 kubelet 客户端证书的第三方为任何 IP 或域名请求服务证书。

为其他用户生成 kubeconfig 文件

在集群创建过程中,kubeadm 对 admin.conf 中的证书进行签名时,将其配置为 Subject: O = system:masters, CN = kubernetes-adminsystem:masters 是一个例外的超级用户组,可以绕过鉴权层(例如 RBAC)。 强烈建议不要将 admin.conf 文件与任何人共享。

你要使用 kubeadm kubeconfig user 命令为其他用户生成 kubeconfig 文件,这个命令支持命令行参数和 kubeadm 配置结构。 以上命令会将 kubeconfig 打印到终端上,也可以使用 kubeadm kubeconfig user ... > somefile.conf 输出到一个文件中。

如下 kubeadm 可以在 --config 后加的配置文件示例:

# example.yaml
apiVersion: kubeadm.k8s.io/v1beta3
kind: ClusterConfiguration
# kubernetes 将作为 kubeconfig 中集群名称
clusterName: "kubernetes"
# some-dns-address:6443 将作为集群 kubeconfig 文件中服务地址(IP 或者 DNS 名称)
controlPlaneEndpoint: "some-dns-address:6443"
# 从本地挂载集群的 CA 秘钥和 CA 证书
certificatesDir: "/etc/kubernetes/pki"

确保这些设置与所需的目标集群设置相匹配。可以使用以下命令查看现有集群的设置:

kubectl get cm kubeadm-config -n kube-system -o=jsonpath="{.data.ClusterConfiguration}"

以下示例将为在 appdevs 组的 johndoe 用户创建一个有效期为 24 小时的 kubeconfig 文件:

kubeadm kubeconfig user --config example.yaml --org appdevs --client-name johndoe --validity-period 24h

以下示例将为管理员创建一个有效期有一周的 kubeconfig 文件:

kubeadm kubeconfig user --config example.yaml --client-name admin --validity-period 168h

3 - 重新配置 kubeadm 集群

kubeadm 不支持自动重新配置部署在托管节点上的组件的方式。 一种自动化的方法是使用自定义的 operator

要修改组件配置,你必须手动编辑磁盘上关联的集群对象和文件。 本指南展示了实现 kubeadm 集群重新配置所需执行的正确步骤顺序。

准备开始

  • 你需要一个使用 kubeadm 部署的集群
  • 拥有管理员凭据(/etc/kubernetes/admin.conf) 和从安装了 kubectl 的主机到集群中正在运行的 kube-apiserver 的网络连接
  • 在所有主机上安装文本编辑器

重新配置集群

kubeadm 在 ConfigMap 和其他对象中写入了一组集群范围的组件配置选项。 这些对象必须手动编辑,可以使用命令 kubectl edit

kubectl edit 命令将打开一个文本编辑器,你可以在其中直接编辑和保存对象。 你可以使用环境变量 KUBECONFIGKUBE_EDITOR 来指定 kubectl 使用的 kubeconfig 文件和首选文本编辑器的位置。

例如:

KUBECONFIG=/etc/kubernetes/admin.conf KUBE_EDITOR=nano kubectl edit <parameters>

应用集群配置更改

更新 ClusterConfiguration

在集群创建和升级期间,kubeadm 将其 ClusterConfiguration 写入 kube-system 命名空间中名为 kubeadm-config 的 ConfigMap。

要更改 ClusterConfiguration 中的特定选项,你可以使用以下命令编辑 ConfigMap:

kubectl edit cm -n kube-system kubeadm-config

配置位于 data.ClusterConfiguration 键下。

在控制平面节点上反映 ClusterConfiguration 更改

kubeadm 将控制平面组件作为位于 /etc/kubernetes/manifests 目录中的静态 Pod 清单进行管理。 对 apiServercontrollerManagerscheduleretcd键下的 ClusterConfiguration 的任何更改都必须反映在控制平面节点上清单目录中的关联文件中。

此类更改可能包括:

  • extraArgs - 需要更新传递给组件容器的标志列表
  • extraMounts - 需要更新组件容器的卷挂载
  • *SANs - 需要使用更新的主题备用名称编写新证书

在继续进行这些更改之前,请确保你已备份目录 /etc/kubernetes/

要编写新证书,你可以使用:

kubeadm init phase certs <component-name> --config <config-file>

要在 /etc/kubernetes/manifests 中编写新的清单文件,你可以使用:

kubeadm init phase control-plane <component-name> --config <config-file>

<config-file> 内容必须与更新后的 ClusterConfiguration 匹配。 <component-name> 值必须是组件的名称。

应用 kubelet 配置更改

更新 KubeletConfiguration

在集群创建和升级期间,kubeadm 将其 KubeletConfiguration 写入 kube-system 命名空间中名为 kubelet-config 的 ConfigMap。 你可以使用以下命令编辑 ConfigMap:

kubectl edit cm -n kube-system kubelet-config

配置位于 data.kubelet 键下。

反映 kubelet 的更改

要反映 kubeadm 节点上的更改,你必须执行以下操作:

  • 登录到 kubeadm 节点
  • 运行 kubeadm upgrade node phase kubelet-config 下载最新的 kubelet-config ConfigMap 内容到本地文件 /var/lib/kubelet/config.conf
  • 编辑文件 /var/lib/kubelet/kubeadm-flags.env 以使用标志来应用额外的配置
  • 使用 systemctl restart kubelet 重启 kubelet 服务

应用 kube-proxy 配置更改

更新 KubeProxyConfiguration

在集群创建和升级期间,kubeadm 将其写入 KubeProxyConfiguration 在名为 kube-proxykube-system 命名空间中的 ConfigMap 中。

此 ConfigMap 由 kube-system 命名空间中的 kube-proxy DaemonSet 使用。

要更改 KubeProxyConfiguration 中的特定选项,你可以使用以下命令编辑 ConfigMap:

kubectl edit cm -n kube-system kube-proxy

配置位于 data.config.conf 键下。

反映 kube-proxy 的更改

更新 kube-proxy ConfigMap 后,你可以重新启动所有 kube-proxy Pod:

获取 Pod 名称:

kubectl get po -n kube-system | grep kube-proxy

使用以下命令删除 Pod:

kubectl delete po -n kube-system <pod-name>

将创建使用更新的 ConfigMap 的新 Pod。

应用 CoreDNS 配置更改

更新 CoreDNS 的 Deployment 和 Service

kubeadm 将 CoreDNS 部署为名为 coredns 的 Deployment,并使用 Service kube-dns, 两者都在 kube-system 命名空间中。

要更新任何 CoreDNS 设置,你可以编辑 Deployment 和 Service:

kubectl edit deployment -n kube-system coredns
kubectl edit service -n kube-system kube-dns

反映 CoreDNS 的更改

应用 CoreDNS 更改后,你可以删除 CoreDNS Pod。

获取 Pod 名称:

kubectl get po -n kube-system | grep coredns

使用以下命令删除 Pod:

kubectl delete po -n kube-system <pod-name>

将创建具有更新的 CoreDNS 配置的新 Pod。

持久化重新配置

在受管节点上执行 kubeadm upgrade 期间,kubeadm 可能会覆盖在创建集群(重新配置)后应用的配置。

持久化 Node 对象重新配置

kubeadm 在特定 Kubernetes 节点的 Node 对象上写入标签、污点、CRI 套接字和其他信息。要更改此 Node 对象的任何内容,你可以使用:

kubectl edit no <node-name>

kubeadm upgrade 期间,此类节点的内容可能会被覆盖。 如果你想在升级后保留对 Node 对象的修改,你可以准备一个 kubectl patch 并将其应用到 Node 对象:

kubectl patch no <node-name> --patch-file <patch-file>

持久化控制平面组件重新配置

控制平面配置的主要来源是存储在集群中的 ClusterConfiguration 对象。 要扩展静态 Pod 清单配置,可以使用 patches

这些补丁文件必须作为文件保留在控制平面节点上,以确保它们可以被 kubeadm upgrade ... --patches <directory> 使用。

如果对 ClusterConfiguration 和磁盘上的静态 Pod 清单进行了重新配置,则必须相应地更新节点特定补丁集。

持久化 kubelet 重新配置

对存储在 /var/lib/kubelet/config.conf 中的 KubeletConfiguration 所做的任何更改都将在 kubeadm upgrade 时因为下载集群范围内的 kubelet-config ConfigMap 的内容而被覆盖。 要持久保存 kubelet 节点特定的配置,文件/var/lib/kubelet/config.conf 必须在升级后手动更新,或者文件/var/lib/kubelet/kubeadm-flags.env 可以包含标志。 kubelet 标志会覆盖相关的 KubeletConfiguration 选项,但请注意,有些标志已被弃用。

更改 /var/lib/kubelet/config.conf/var/lib/kubelet/kubeadm-flags.env 后需要重启 kubelet。

接下来

4 - 升级 kubeadm 集群

本页介绍如何将 kubeadm 创建的 Kubernetes 集群从 1.25.x 版本 升级到 1.26.x 版本以及从 1.26.x 升级到 1.26.y(其中 y > x)。略过次版本号的升级是 不被支持的。更多详情请访问版本偏差策略

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

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

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

准备开始

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

附加信息

  • 下述说明了在升级过程中何时腾空每个节点。如果你正在对任何 kubelet 进行小版本升级, 你需要先腾空待升级的节点(或多个节点)。对于控制面节点,其上可能运行着 CoreDNS Pod 或者其它非常重要的负载。更多信息见腾空节点
  • 升级后,因为容器规约的哈希值已更改,所有容器都会被重新启动。
  • 要验证 kubelet 服务在升级后是否成功重启,可以执行 systemctl status kubeletjournalctl -xeu kubelet 查看服务日志。
  • 不建议使用 kubeadm upgrade--config 参数和 kubeadm 配置 API 类型来重新配置集群, 这样会产生意想不到的结果。 请按照重新配置 kubeadm 集群中的步骤来进行。

确定要升级到哪个版本

使用操作系统的包管理器找到最新的补丁版本 Kubernetes 1.26:

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

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

升级控制平面节点

控制面节点上的升级过程应该每次处理一个节点。 首先选择一个要先行升级的控制面节点。该节点上必须拥有 /etc/kubernetes/admin.conf 文件。

执行 “kubeadm upgrade”

对于第一个控制面节点

  • 升级 kubeadm:

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

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

  • 验证下载操作正常,并且 kubeadm 版本正确:

    kubeadm version
    
  • 验证升级计划:

    kubeadm upgrade plan
    

    此命令检查你的集群是否可被升级,并取回你要升级的目标版本。 命令也会显示一个包含组件配置版本状态的表格。

  • 选择要升级到的目标版本,运行合适的命令。例如:

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

    一旦该命令结束,你应该会看到:

    [upgrade/successful] SUCCESS! Your cluster was upgraded to "v1.26.x". 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 运行,则在其他控制平面节点上不需要此步骤。

对于其它控制面节点

与第一个控制面节点相同,但是使用:

sudo kubeadm upgrade node

而不是:

sudo kubeadm upgrade apply

此外,不需要执行 kubeadm upgrade plan 和更新 CNI 驱动插件的操作。

腾空节点

  • 将节点标记为不可调度并驱逐所有负载,准备节点的维护:

    # 将 <node-to-drain> 替换为你要腾空的控制面节点名称
    kubectl drain <node-to-drain> --ignore-daemonsets
    

升级 kubelet 和 kubectl

  • 升级 kubelet 和 kubectl:

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

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

  • 重启 kubelet:

    sudo systemctl daemon-reload
    sudo systemctl restart kubelet
    

解除节点的保护

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

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

升级工作节点

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

升级 kubeadm

  • 升级 kubeadm:

    # 将 1.26.x-00 中的 x 替换为最新的补丁版本号
    apt-mark unhold kubeadm && \
    apt-get update && apt-get install -y kubeadm=1.26.x-00 && \
    apt-mark hold kubeadm
    

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

执行 "kubeadm upgrade"

  • 对于工作节点,下面的命令会升级本地的 kubelet 配置:

    sudo kubeadm upgrade node
    

腾空节点

  • 将节点标记为不可调度并驱逐所有负载,准备节点的维护:

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

升级 kubelet 和 kubectl

  • 升级 kubelet 和 kubectl:

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

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

  • 重启 kubelet:

    sudo systemctl daemon-reload
    sudo systemctl restart kubelet
    

取消对节点的保护

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

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

验证集群的状态

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

kubectl get nodes

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

从故障状态恢复

如果 kubeadm upgrade 失败并且没有回滚,例如由于执行期间节点意外关闭, 你可以再次运行 kubeadm upgrade。 此命令是幂等的,并最终确保实际状态是你声明的期望状态。

要从故障状态恢复,你还可以运行 kubeadm upgrade apply --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 状态
    • 控制面是健康的
  • 强制执行版本偏差策略。
  • 确保控制面的镜像是可用的或可拉取到服务器上。
  • 如果组件配置要求版本升级,则生成替代配置与/或使用用户提供的覆盖版本配置。
  • 升级控制面组件或回滚(如果其中任何一个组件无法启动)。
  • 应用新的 CoreDNSkube-proxy 清单,并强制创建所有必需的 RBAC 规则。
  • 如果旧文件在 180 天后过期,将创建 API 服务器的新证书和密钥文件并备份旧文件。

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

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

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

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

5 - 升级 Windows 节点

特性状态: Kubernetes v1.18 [beta]

本页解释如何升级用 kubeadm 创建的 Windows 节点。

准备开始

你必须拥有一个 Kubernetes 的集群,同时你的 Kubernetes 集群必须带有 kubectl 命令行工具。 建议在至少有两个节点的集群上运行本教程,且这些节点不作为控制平面主机。 如果你还没有集群,你可以通过 Minikube 构建一个你自己的集群,或者你可以使用下面任意一个 Kubernetes 工具构建:

你的 Kubernetes 服务器版本必须不低于版本 1.17. 要获知版本信息,请输入 kubectl version.

升级工作节点

升级 kubeadm

  1. 在 Windows 节点上升级 kubeadm:

    # 将 v1.26.0 替换为你希望的版本
    curl.exe -Lo <kubeadm.exe 路径>  "https://dl.k8s.io/v1.26.0/bin/windows/amd64/kubeadm.exe"
    

腾空节点

  1. 在一个能访问到 Kubernetes API 的机器上,将 Windows 节点标记为不可调度并 驱逐其上的所有负载,以便准备节点维护操作:

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

    你应该会看到类似下面的输出:

    node/ip-172-31-85-18 cordoned
    node/ip-172-31-85-18 drained
    

升级 kubelet 配置

  1. 在 Windows 节点上,执行下面的命令来同步新的 kubelet 配置:

    kubeadm upgrade node
    

升级 kubelet 和 kube-proxy

  1. 在 Windows 节点上升级并重启 kubelet:

    stop-service kubelet
    curl.exe -Lo <kubelet.exe 路径> "https://dl.k8s.io/v1.26.0/bin/windows/amd64/kubelet.exe"
    restart-service kubelet
    
  1. 在 Windows 节点上升级并重启 kube-proxy:

    stop-service kube-proxy
    curl.exe -Lo <kube-proxy.exe 路径> "https://dl.k8s.io/v1.26.0/bin/windows/amd64/kube-proxy.exe"
    restart-service kube-proxy
    

对节点执行 uncordon 操作

  1. 从一台能够访问到 Kubernetes API 的机器上,通过将节点标记为可调度,使之 重新上线:

    # 将 <要腾空的节点> 替换为你的节点名称
    kubectl uncordon <要腾空的节点>