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

用 kubeadm 进行管理

1: 使用 kubeadm 进行证书管理
2: 升级 kubeadm 集群
3: 添加 Windows 节点
4: 升级 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的设置指南。

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

检查证书是否过期

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

kubeadm alpha 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 配置为自动更新证书。

警告：
在通过 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 alpha 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 alpha 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 证书。

2 - 升级 kubeadm 集群

本页介绍如何将 kubeadm 创建的 Kubernetes 集群从 1.23.x 版本升级到 1.24.x 版本以及从 1.24.x 升级到 1.24.y（其中 y > x）。略过次版本号的升级是不被支持的。

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

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

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

准备开始

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

附加信息

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

确定要升级到哪个版本

使用操作系统的包管理器找到最新的稳定 1.24：

Ubuntu、Debian 或 HypriotOS
CentOS、RHEL 或 Fedora

apt update
apt-cache policy 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：

Ubuntu、Debian 或 HypriotOS
CentOS、RHEL 或 Fedora

# 用最新的补丁版本号替换 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
-
# 从 apt-get 1.1 版本起，你也可以使用下面的方法
apt-get update && \
apt-get install -y --allow-change-held-packages kubeadm=1.24.x-00

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

  # 用最新的补丁版本替换 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
  - 
  # 从 apt-get 的 1.1 版本开始，你也可以使用下面的方法：
  apt-get update && \
  apt-get install -y --allow-change-held-packages kubelet=1.24.x-00 kubectl=1.24.x-00

 
  # 用最新的补丁版本号替换 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：

Ubuntu、Debian 或 HypriotOS
CentOS、RHEL 或 Fedora

# 将 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
- 
# 从 apt-get 的 1.1 版本开始，你也可以使用下面的方法：
apt-get update && \
apt-get install -y --allow-change-held-packages kubeadm=1.24.x-00

# 用最新的补丁版本替换 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：

Ubuntu、Debian 或 HypriotOS
CentOS, RHEL or Fedora

# 将 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

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

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

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

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

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

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

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

3 - 添加 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.20.15 版本的用法，不过你应该根据你自己的集群部署调整其中的版本号。
```
curl -L https://github.com/kubernetes-sigs/sig-windows-tools/releases/latest/download/kube-proxy.yml | sed 's/VERSION/v1.20.15/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 v1.20.15

运行 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 节点

4 - 升级 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.20.15 替换为你希望的版本
curl.exe -Lo C:\k\kubeadm.exe https://dl.k8s.io/v1.20.15/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/v1.20.15/bin/windows/amd64/kubelet.exe
restart-service kubelet

对节点执行 uncordon 操作

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

升级 kube-proxy

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

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