这是本节的多页打印视图。 点击此处打印.

返回本页常规视图.

用 kubeadm 进行管理

1 - 使用 kubeadm 进行证书管理

FEATURE STATE: Kubernetes v1.15 [stable]

由 kubeadm 生成的客户端证书在 1 年后到期。 本页说明如何使用 kubeadm 管理证书续订。

Before you begin

你应该熟悉 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.conf, controller-manager.conf 和 scheduler.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 的目录，将 CRS 输出到指定位置。 如果未指定 --csr-dir ，则使用默认证书目录（/etc/kubernetes/pki）。

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

CSR 签署证书后，必须将证书和私钥复制到 PKI 目录（默认情况下为 /etc/kubernetes/pki）。

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.24 的 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 将 KubeletConfiguration 的 rotateCertificates 字段设置为 true；这意味着证书快要过期时，会生成一组针对服务证书的新的 CSR，而 这些 CSR 也要被批准才能完成证书轮换。 要进一步了解这里的细节，可参阅 证书轮换 文档。

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

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

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

2 - 配置 cgroup 驱动

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

Before you begin

你应该熟悉 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 驱动

正如本指南阐述的：不推荐与 kubeadm 一起使用 cgroupfs 驱动。

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

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

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

迁移到 systemd 驱动

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

修改 kubelet 的 ConfigMap

  • 用命令 kubectl get cm -n kube-system | grep kubelet-config 找到 kubelet 的 ConfigMap 名称。

  • 运行 kubectl edit cm kubelet-config-x.yy -n kube-system （把 x.yy 替换为 Kubernetes 版本）。

  • 修改现有 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>，以 取消节点隔离

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

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

3 - 重新配置 kubeadm 集群

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

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

Before you begin

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

重新配置集群

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

kubectl edit 命令将打开一个文本编辑器，你可以在其中直接编辑和保存对象。 你可以使用环境变量 KUBECONFIG 和 KUBE_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 清单进行管理。 对 apiServer、controllerManager、scheduler 或 etcd键下的 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-proxy 的 kube-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。

What's next

4 - 升级 kubeadm 集群

本页介绍如何将 kubeadm 创建的 Kubernetes 集群从 1.23.x 版本 升级到 1.24.x 版本以及从 1.24.x 升级到 1.24.y（其中 y > x）。略过次版本号的升级是 不被支持的。更多详情请访问版本倾斜政策。

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

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

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

Before you begin

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

附加信息

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

确定要升级到哪个版本

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

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


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

升级控制平面节点

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

执行 "kubeadm upgrade"

升级第一个控制面节点

  • 升级 kubeadm：

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



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

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

    kubeadm version

  • 验证升级计划：

    kubeadm upgrade plan

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

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

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

一旦该命令结束，你应该会看到：

[upgrade/successful] SUCCESS! Your cluster was upgraded to "v1.24.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：

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


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

  • 重启 kubelet

    sudo systemctl daemon-reload
sudo systemctl restart kubelet

解除节点的保护

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

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

升级工作节点

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

升级 kubeadm

  • 升级 kubeadm：

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


    # 用最新的补丁版本替换 1.24.x-00 中的 x
yum install -y kubeadm-1.24.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.24.x-00 中的 x 替换为最新的补丁版本
apt-mark unhold kubelet kubectl && \
apt-get update && apt-get install -y kubelet=1.24.x-00 kubectl=1.24.x-00 && \
apt-mark hold kubelet kubectl


    # 将 1.24.x-0 x 替换为最新的补丁版本
yum install -y kubelet-1.24.x-0 kubectl-1.24.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 状态
    • 控制面是健康的
  • 强制执行版本偏差策略。
  • 确保控制面的镜像是可用的或可拉取到服务器上。
  • 如果组件配置要求版本升级，则生成替代配置与/或使用用户提供的覆盖版本配置。
  • 升级控制面组件或回滚（如果其中任何一个组件无法启动）。
  • 应用新的 CoreDNS 和 kube-proxy 清单，并强制创建所有必需的 RBAC 规则。
  • 如果旧文件在 180 天后过期，将创建 API 服务器的新证书和密钥文件并备份旧文件。

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

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

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

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

5 - 添加 Windows 节点

FEATURE STATE: Kubernetes v1.18 [beta]

你可以使用 Kubernetes 来混合运行 Linux 和 Windows 节点，这样你就可以 混合使用运行于 Linux 上的 Pod 和运行于 Windows 上的 Pod。 本页面展示如何将 Windows 节点注册到你的集群。

Before you begin

Your Kubernetes server must be at or later than version 1.17. To check the version, enter kubectl version.

Objectives

  • 将一个 Windows 节点注册到集群上
  • 配置网络，以便 Linux 和 Windows 上的 Pod 和 Service 之间能够相互通信。

开始行动：向你的集群添加一个 Windows 节点

联网配置

一旦你有了一个基于 Linux 的 Kubernetes 控制面节点，你就可以为其选择联网方案。 出于简单考虑，本指南展示如何使用 VXLAN 模式的 Flannel。

配置 Flannel

  1. 为 Flannel 准备 Kubernetes 的控制面

    在我们的集群中，建议对 Kubernetes 的控制面进行少许准备处理。 建议在使用 Flannel 时为 iptables 链启用桥接方式的 IPv4 流处理， 必须在所有 Linux 节点上执行如下命令：

    sudo sysctl net.bridge.bridge-nf-call-iptables=1

  1. 下载并配置 Linux 版本的 Flannel

    下载最新的 Flannel 清单文件：

    wget https://raw.githubusercontent.com/coreos/flannel/master/Documentation/kube-flannel.yml

    修改 Flannel 清单中的 net-conf.json 部分，将 VNI 设置为 4096，并将 Port 设置为 4789。 结果看起来像下面这样：

    net-conf.json: |
    {
      "Network": "10.244.0.0/16",
      "Backend": {
         "Type": "vxlan",
         "VNI": 4096,
         "Port": 4789
    }
}

  1. 应用 Flannel 清单并验证

    首先应用 Flannel 配置：

    kubectl apply -f kube-flannel.yml

    几分钟之后，如果 Flannel Pod 网络被正确部署，你应该会看到所有 Pods 都处于运行中状态。

    kubectl get pods -n kube-system

    输出中应该包含处于运行中状态的 Linux Flannel DaemonSet：

    NAMESPACE     NAME                                      READY        STATUS    RESTARTS   AGE
...
kube-system   kube-flannel-ds-54954                     1/1          Running   0          1m

  1. 添加 Windows Flannel 和 kube-proxy DaemonSet

    现在你可以添加 Windows 兼容版本的 Flannel 和 kube-proxy。为了确保你能获得兼容 版本的 kube-proxy，你需要替换镜像中的标签。 下面的例子中展示的是针对 Kubernetes v1.24.0 版本的用法， 不过你应该根据你自己的集群部署调整其中的版本号。

    curl -L https://github.com/kubernetes-sigs/sig-windows-tools/releases/latest/download/kube-proxy.yml | sed 's/VERSION/v1.24.0/g' | kubectl apply -f -
kubectl apply -f https://github.com/kubernetes-sigs/sig-windows-tools/releases/latest/download/flannel-overlay.yml

加入 Windows 工作节点

安装 Docker EE

Install-WindowsFeature -Name containers

安装 Docker 操作指南在 Install Docker Engine - Enterprise on Windows Servers。

安装 wins、kubelet 和 kubeadm

curl.exe -LO https://raw.githubusercontent.com/kubernetes-sigs/sig-windows-tools/master/kubeadm/scripts/PrepareNode.ps1
.\PrepareNode.ps1 -KubernetesVersion v1.24.0

运行 kubeadm 添加节点

当你在控制面主机上运行 kubeadm init 时，输出了一个命令。现在运行这个命令。 如果你找不到这个命令，或者命令中对应的令牌已经过期，你可以（在一个控制面主机上）运行 kubeadm token create --print-join-command 来生成新的令牌和 join 命令。

安装 containerD

curl.exe -LO https://github.com/kubernetes-sigs/sig-windows-tools/releases/latest/download/Install-Containerd.ps1
.\Install-Containerd.ps1

安装 wins，kubelet 和 kubeadm

curl.exe -LO https://raw.githubusercontent.com/kubernetes-sigs/sig-windows-tools/master/kubeadm/scripts/PrepareNode.ps1
.\PrepareNode.ps1 -KubernetesVersion v1.24.0 -ContainerRuntime containerD

运行 kubeadm 添加节点

使用当你在控制面主机上运行 kubeadm init 时得到的命令。 如果你找不到这个命令，或者命令中对应的令牌已经过期，你可以（在一个控制面主机上）运行 kubeadm token create --print-join-command 来生成新的令牌和 join 命令。

检查你的安装

你现在应该能够通过运行下面的命令来查看集群中的 Windows 节点了：

kubectl get nodes -o wide

如果你的新节点处于 NotReady 状态，很可能的原因是系统仍在下载 Flannel 镜像。 你可以像之前一样，通过检查 kube-system 名字空间中的 Flannel Pods 来了解 安装进度。

kubectl -n kube-system get pods -l app=flannel

一旦 Flannel Pod 运行起来，你的节点就应该能进入 Ready 状态并可 用来处理负载。

What's next

6 - 升级 Windows 节点

FEATURE STATE: Kubernetes v1.18 [beta]

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

Before you begin

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

Your Kubernetes server must be at or later than version 1.17. To check the version, enter kubectl version.

升级工作节点

升级 kubeadm

  1. 在 Windows 节点上升级 kubeadm：

    # 将 v1.24.0 替换为你希望的版本
curl.exe -Lo C:\k\kubeadm.exe https://dl.k8s.io//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

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

    stop-service kubelet
curl.exe -Lo C:\k\kubelet.exe https://dl.k8s.io//bin/windows/amd64/kubelet.exe
restart-service kubelet

对节点执行 uncordon 操作

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

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

升级 kube-proxy

  1. 在一台可访问 Kubernetes API 的机器上和，将 v1.24.0 替换成你 期望的版本后再次执行下面的命令：

    curl -L https://github.com/kubernetes-sigs/sig-windows-tools/releases/latest/download/kube-proxy.yml | sed 's/VERSION/v1.24.0/g' | kubectl apply -f -