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

用 kubeadm 进行管理

1: 使用 kubeadm 进行证书管理
2: 配置 cgroup 驱动
3: 升级 kubeadm 集群
4: 添加 Windows 节点
5: 升级 Windows 节点

1 - 使用 kubeadm 进行证书管理

FEATURE STATE: Kubernetes v1.15 [stable]

由 kubeadm 生成的客户端证书在 1 年后到期。本页说明如何使用 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.conf, controller-manager.conf 和 scheduler.conf）使用的 KUBECONFIG 文件中嵌入的客户端证书的到期时间/剩余时间。

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

警告： kubeadm 不能管理由外部 CA 签名的证书

说明： 上面的列表中没有包含 kubelet.conf，因为 kubeadm 将 kubelet 配置为自动更新证书。轮换的证书位于目录 /var/lib/kubelet/pki。要修复过期的 kubelet 客户端证书，请参阅 kubelet 客户端证书轮换失败。

警告：
在通过 kubeadm init 创建的节点上，在 kubeadm 1.17 版本之前有一个缺陷，该缺陷使得你必须手动修改 kubelet.conf 文件的内容。 kubeadm init 操作结束之后，你必须更新 kubelet.conf 文件将 client-certificate-data 和 client-key-data 改为如下所示的内容以便使用轮换后的 kubelet 客户端证书：
client-certificate: /var/lib/kubelet/pki/kubelet-client-current.pem
client-key: /var/lib/kubelet/pki/kubelet-client-current.pem

自动更新证书

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

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

说明： 最佳的做法是经常升级集群以确保安全。

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

警告： kubeadm 在 1.17 版本之前有一个缺陷，该缺陷导致 kubeadm update node 执行时 --certificate-renewal 的默认值被设置为 false。在这种情况下，你需要显式地设置 --certificate-renewal=true。

手动更新证书

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

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

警告： 如果你运行了一个 HA 集群，这个命令需要在所有控制面板节点上执行。

说明： certs renew 使用现有的证书作为属性 (Common Name、Organization、SAN 等) 的权威来源，而不是 kubeadm-config ConfigMap 。强烈建议使它们保持同步。

kubeadm certs renew提供以下选项：

Kubernetes 证书通常在一年后到期。

--csr-only 可用于经过一个外部 CA 生成的证书签名请求来更新证书（无需实际替换更新证书）；更多信息请参见下节。
可以更新单个证书而不是全部证书。

用 Kubernetes 证书 API 更新证书

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

注意： 这些是针对需要将其组织的证书基础结构集成到 kubeadm 构建的集群中的用户的高级主题。如果默认的 kubeadm 配置满足了你的需求，则应让 kubeadm 管理证书。

设置一个签名者（Signer）

Kubernetes 证书颁发机构不是开箱即用。你可以配置外部签名者，例如 cert-manager，也可以使用内置签名者。内置签名者是 kube-controller-manager 的一部分。要激活内置签名者，请传递 --cluster-signing-cert-file 和 --cluster-signing-key-file 参数。

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

apiVersion: kubeadm.k8s.io/v1beta2
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 有责任指定正确的证书用法

在 openssl 中，这是通过 openssl ca 命令来完成的。
在 cfssl 中，这是通过在配置文件中指定用法来完成的。

使用首选方法对证书签名后，必须将证书和私钥复制到 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/v1beta2
kind: ClusterConfiguration
---
apiVersion: kubelet.config.k8s.io/v1beta1
kind: KubeletConfiguration
serverTLSBootstrap: true

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

找到 kube-system 名字空间中名为 kubelet-config-1.22 的 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）的方式检查节点的标识符。

注意： 本部分链接到提供 Kubernetes 所需功能的第三方项目。Kubernetes 项目作者不负责这些项目。此页面遵循CNCF 网站指南，按字母顺序列出项目。要将项目添加到此列表中，请在提交更改之前阅读内容指南。

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

kubelet-rubber-stamp

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

2 - 配置 cgroup 驱动

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

准备开始

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

配置容器运行时 cgroup 驱动

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

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

配置 kubelet 的 cgroup 驱动

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

FEATURE STATE: Kubernetes v1.21 [stable]

说明： 如果用户没有在 KubeletConfiguration 中设置 cgroupDriver 字段， kubeadm init 会将它设置为默认值 systemd。

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

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

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

kubeadm init --config kubeadm-config.yaml

说明：
Kubeadm 对集群所有的节点，使用相同的 KubeletConfiguration。 KubeletConfiguration 存放于 kube-system 命名空间下的某个 ConfigMap 对象中。

执行 init、join 和 upgrade 等子命令会促使 kubeadm 将 KubeletConfiguration 写入到文件 /var/lib/kubelet/config.yaml 中，继而把它传递给本地节点的 kubelet。

使用 `cgroupfs` 驱动

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

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

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

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

迁移到 `systemd` 驱动

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

说明： 还有一种方法，可以用已配置了 systemd 的新节点替换掉集群中的老节点。按这种方法，在加入新节点、确保工作负载可以安全迁移到新节点、及至删除旧节点这一系列操作之前，只需执行以下第一个步骤。

修改 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 创建的 Kubernetes 集群从 1.21.x 版本升级到 1.22.x 版本以及从 1.22.x 升级到 1.22.y（其中 y > x）。略过次版本号的升级是不被支持的。

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

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

升级主控制平面节点
升级其他控制平面节点
升级工作节点

准备开始

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

附加信息

在对 kubelet 作次版本升版时需要腾空节点。对于控制面节点，其上可能运行着 CoreDNS Pods 或者其它非常重要的负载。
升级后，因为容器规约的哈希值已更改，所有容器都会被重新启动。

确定要升级到哪个版本

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

Ubuntu、Debian 或 HypriotOS
CentOS、RHEL 或 Fedora

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

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

升级控制平面节点

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

执行 "kubeadm upgrade"

升级第一个控制面节点

升级 kubeadm：

Ubuntu、Debian 或 HypriotOS
CentOS、RHEL 或 Fedora

# 用最新的补丁版本号替换 1.22.x-00 中的 x
apt-mark unhold kubeadm && \
apt-get update && apt-get install -y kubeadm=1.22.x-00 && \
apt-mark hold kubeadm
-
# 从 apt-get 1.1 版本起，你也可以使用下面的方法
apt-get update && \
apt-get install -y --allow-change-held-packages kubeadm=1.22.x-00

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

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

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

说明：
kubeadm upgrade 也会自动对 kubeadm 在节点上所管理的证书执行续约操作。如果需要略过证书续约操作，可以使用标志 --certificate-renewal=false。更多的信息，可参阅证书管理指南。

说明：
如果 kubeadm upgrade plan 给出任何需要手动升级的组件配置，用户必须通过 --config 命令行标志向 kubeadm upgrade apply 命令提供替代的配置文件。如果不这样做，kubeadm upgrade apply 会出错并退出，不再执行升级操作。

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

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

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

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

  # 用最新的补丁版本替换 1.22.x-00 中的 x
  apt-mark unhold kubelet kubectl && \
  apt-get update && apt-get install -y kubelet=1.22.x-00 kubectl=1.22.x-00 && \
  apt-mark hold kubelet kubectl
  - 
  # 从 apt-get 的 1.1 版本开始，你也可以使用下面的方法：
  apt-get update && \
  apt-get install -y --allow-change-held-packages kubelet=1.22.x-00 kubectl=1.22.x-00

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

重启 kubelet

sudo systemctl daemon-reload
sudo systemctl restart kubelet

解除节点的保护

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

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

升级工作节点

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

升级 kubeadm

升级 kubeadm：

Ubuntu、Debian 或 HypriotOS
CentOS、RHEL 或 Fedora

# 将 1.22.x-00 中的 x 替换为最新的补丁版本号
apt-mark unhold kubeadm && \
apt-get update && apt-get install -y kubeadm=1.22.x-00 && \
apt-mark hold kubeadm
- 
# 从 apt-get 的 1.1 版本开始，你也可以使用下面的方法：
apt-get update && \
apt-get install -y --allow-change-held-packages kubeadm=1.22.x-00

# 用最新的补丁版本替换 1.22.x-00 中的 x
yum install -y kubeadm-1.22.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：

Ubuntu、Debian 或 HypriotOS
CentOS, RHEL or Fedora

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

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

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

# 将 1.22.x-0 x 替换为最新的补丁版本
yum install -y kubelet-1.22.x-0 kubectl-1.22.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 配置。

4 - 添加 Windows 节点

FEATURE STATE: Kubernetes v1.18 [beta]

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

准备开始

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

获取 Windows Server 2019 或更高版本的授权以便配置托管 Windows 容器的 Windows 节点。如果你在使用 VXLAN/覆盖（Overlay）联网设施，则你还必须安装 KB4489899。
一个利用 kubeadm 创建的基于 Linux 的 Kubernetes 集群；你能访问该集群的控制面（参见使用 kubeadm 创建一个单控制面的集群)。

教程目标

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

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

联网配置

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

配置 Flannel

为 Flannel 准备 Kubernetes 的控制面

在我们的集群中，建议对 Kubernetes 的控制面进行少许准备处理。建议在使用 Flannel 时为 iptables 链启用桥接方式的 IPv4 流处理，必须在所有 Linux 节点上执行如下命令：
```
sudo sysctl net.bridge.bridge-nf-call-iptables=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
    }
}
```
说明： 在 Linux 节点上 VNI 必须设置为 4096，端口必须设置为 4789，这样才能令其与 Windows 上的 Flannel 互操作。关于这些字段的详细说明，请参见 VXLAN 文档。

说明： 如要使用 L2Bridge/Host-gateway 模式，则可将 Type 值设置为 "host-gw"，并忽略 VNI 和 Port 的设置。

应用 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

添加 Windows Flannel 和 kube-proxy DaemonSet

现在你可以添加 Windows 兼容版本的 Flannel 和 kube-proxy。为了确保你能获得兼容版本的 kube-proxy，你需要替换镜像中的标签。下面的例子中展示的是针对 Kubernetes v1.22.0 版本的用法，不过你应该根据你自己的集群部署调整其中的版本号。
```
curl -L https://github.com/kubernetes-sigs/sig-windows-tools/releases/latest/download/kube-proxy.yml | sed 's/VERSION/v1.22.0/g' | kubectl apply -f -
kubectl apply -f https://github.com/kubernetes-sigs/sig-windows-tools/releases/latest/download/flannel-overlay.yml
```
说明： 如果你在使用 host-gateway 模式，则应该使用 https://github.com/kubernetes-sigs/sig-windows-tools/releases/latest/download/flannel-host-gw.yml 这一清单。
说明：
如果你在 Windows 节点上使用的不是以太网（即，"Ethernet0 2"）接口，你需要修改 flannel-host-gw.yml 或 flannel-overlay.yml 文件中的下面这行：
```
wins cli process run --path /k/flannel/setup.exe --args "--mode=overlay --interface=Ethernet"
```
在其中根据情况设置要使用的网络接口。
```
# Example
curl -L https://github.com/kubernetes-sigs/sig-windows-tools/releases/latest/download/flannel-overlay.yml | sed 's/Ethernet/Ethernet0 2/g' | kubectl apply -f -
```

加入 Windows 工作节点

你必须安装 Containers 功能特性并安装 Docker 工具。相关的指令可以在 Install Docker Engine - Enterprise on Windows Servers 处找到。

Windows 节的所有代码片段都需要在 PowerShell 环境中执行，并且要求在 Windows 工作节点上具有提升的权限（Administrator）。

安装 wins、kubelet 和 kubeadm

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

运行 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 状态并可用来处理负载。

接下来

升级 kubeadm 安装的 Windows 节点

5 - 升级 Windows 节点

FEATURE STATE: Kubernetes v1.18 [beta]

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

准备开始

你必须拥有一个 Kubernetes 的集群，同时你的 Kubernetes 集群必须带有 kubectl 命令行工具。如果你还没有集群，你可以通过 Minikube 构建一个你自己的集群，或者你可以使用下面任意一个 Kubernetes 工具构建：

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

熟悉更新 kubeadm 集群中的其余组件。在升级你的 Windows 节点之前你会想要升级控制面节点。

升级工作节点

升级 kubeadm

在 Windows 节点上升级 kubeadm：

# 将 v1.22.0 替换为你希望的版本
curl.exe -Lo C:\k\kubeadm.exe https://dl.k8s.io//bin/windows/amd64/kubeadm.exe

腾空节点

在一个能访问到 Kubernetes API 的机器上，将 Windows 节点标记为不可调度并驱逐其上的所有负载，以便准备节点维护操作：
```
# 将 <要腾空的节点> 替换为你要腾空的节点的名称
kubectl drain <要腾空的节点> -ignore-daemonsets
```
你应该会看到类似下面的输出：
```
node/ip-172-31-85-18 cordoned
node/ip-172-31-85-18 drained
```

升级 kubelet 配置

在 Windows 节点上，执行下面的命令来同步新的 kubelet 配置：
```
kubeadm upgrade node
```

升级 kubelet

在 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 操作

从一台能够访问到 Kubernetes API 的机器上，通过将节点标记为可调度，使之重新上线：
```
# 将 <要腾空的节点> 替换为你的节点名称
kubectl uncordon <要腾空的节点>
```

升级 kube-proxy

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

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

用 kubeadm 进行管理

1 - 使用 kubeadm 进行证书管理

准备开始

使用自定义的证书

外部 CA 模式

检查证书是否过期

自动更新证书

手动更新证书

用 Kubernetes 证书 API 更新证书

设置一个签名者（Signer）

创建证书签名请求 (CSR)

通过外部 CA 更新证书

创建证书签名请求 (CSR)

证书机构（CA）轮换

启用已签名的 kubelet 服务证书

2 - 配置 cgroup 驱动

准备开始

配置容器运行时 cgroup 驱动

配置 kubelet 的 cgroup 驱动

使用 cgroupfs 驱动

迁移到 systemd 驱动

修改 kubelet 的 ConfigMap

更新所有节点的 cgroup 驱动

3 - 升级 kubeadm 集群

准备开始

附加信息

确定要升级到哪个版本

升级控制平面节点

执行 "kubeadm upgrade"

腾空节点

升级 kubelet 和 kubectl

解除节点的保护

升级工作节点

升级 kubeadm

执行 "kubeadm upgrade"

腾空节点

升级 kubelet 和 kubectl

取消对节点的保护

验证集群的状态

从故障状态恢复

工作原理

4 - 添加 Windows 节点

准备开始

教程目标

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

联网配置

配置 Flannel

加入 Windows 工作节点

检查你的安装

接下来

5 - 升级 Windows 节点

准备开始

升级工作节点

升级 kubeadm

腾空节点

升级 kubelet 配置

升级 kubelet

对节点执行 uncordon 操作

升级 kube-proxy

使用 `cgroupfs` 驱动

迁移到 `systemd` 驱动