Switch language name 'zh' to 'zh-cn'
This is the first step to rename 'zh' to 'zh-cn'. There are several reasons why we rename the language name.
- The upstream docsy theme changed the language name, leading to many warnings during site build;
The side-effect is that the i18n strings are no longer working.
- We believe renaming the language is the right thing to do, because this move can make room for other variants of Chinese language, such as 'zh-tw', 'zh-sg' etc.
There would be several follow-ups to this PR, such as fixing the intra-site links, adding redirects etc.
We will lock up changes to zh/zh-cn pages for the moment, until this one gets in.
This PR is based on commit cdad0a7342.
This commit is contained in:
Qiming Teng
@@ -0,0 +1,4 @@
|
||||
---
|
||||
title: "用 kubeadm 进行管理"
|
||||
weight: 10
|
||||
---
|
||||
@@ -0,0 +1,464 @@
|
||||
---
|
||||
title: 添加 Windows 节点
|
||||
min-kubernetes-server-version: 1.17
|
||||
content_type: tutorial
|
||||
weight: 30
|
||||
---
|
||||
<!--
|
||||
reviewers:
|
||||
- michmike
|
||||
- patricklang
|
||||
title: Adding Windows nodes
|
||||
min-kubernetes-server-version: 1.17
|
||||
content_type: tutorial
|
||||
weight: 30
|
||||
-->
|
||||
|
||||
<!-- overview -->
|
||||
|
||||
{{< feature-state for_k8s_version="v1.18" state="beta" >}}
|
||||
|
||||
<!--
|
||||
You can use Kubernetes to run a mixture of Linux and Windows nodes, so you can mix Pods that run on Linux on with Pods that run on Windows. This page shows how to register Windows nodes to your cluster.
|
||||
-->
|
||||
你可以使用 Kubernetes 来混合运行 Linux 和 Windows 节点，这样你就可以
|
||||
混合使用运行于 Linux 上的 Pod 和运行于 Windows 上的 Pod。
|
||||
本页面展示如何将 Windows 节点注册到你的集群。
|
||||
|
||||
## {{% heading "prerequisites" %}}
|
||||
{{< version-check >}}
|
||||
|
||||
<!--
|
||||
* Obtain a [Windows Server 2019 license](https://www.microsoft.com/en-us/cloud-platform/windows-server-pricing)
|
||||
(or higher) in order to configure the Windows node that hosts Windows containers.
|
||||
If you are using VXLAN/Overlay networking you must have also have [KB4489899](https://support.microsoft.com/help/4489899) installed.
|
||||
|
||||
* A Linux-based Kubernetes kubeadm cluster in which you have access to the control plane (see [Creating a single control-plane cluster with kubeadm](/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/)).
|
||||
-->
|
||||
|
||||
* 获取 [Windows Server 2019 或更高版本的授权](https://www.microsoft.com/en-us/cloud-platform/windows-server-pricing)
|
||||
以便配置托管 Windows 容器的 Windows 节点。
|
||||
如果你在使用 VXLAN/覆盖（Overlay）联网设施，则你还必须安装 [KB4489899](https://support.microsoft.com/help/4489899)。
|
||||
|
||||
* 一个利用 kubeadm 创建的基于 Linux 的 Kubernetes 集群；你能访问该集群的控制面
|
||||
（参见[使用 kubeadm 创建一个单控制面的集群](/zh/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/))。
|
||||
|
||||
## {{% heading "objectives" %}}
|
||||
|
||||
<!--
|
||||
* Register a Windows node to the cluster
|
||||
* Configure networking so Pods and Services on Linux and Windows can communicate with each other
|
||||
-->
|
||||
* 将一个 Windows 节点注册到集群上
|
||||
* 配置网络，以便 Linux 和 Windows 上的 Pod 和 Service 之间能够相互通信。
|
||||
|
||||
<!-- lessoncontent -->
|
||||
|
||||
<!--
|
||||
## Getting Started: Adding a Windows Node to Your Cluster
|
||||
|
||||
### Networking Configuration
|
||||
|
||||
Once you have a Linux-based Kubernetes control-plane node you are ready to choose a networking solution. This guide illustrates using Flannel in VXLAN mode for simplicity.
|
||||
-->
|
||||
## 开始行动：向你的集群添加一个 Windows 节点
|
||||
|
||||
### 联网配置 {#networking-configuration}
|
||||
|
||||
一旦你有了一个基于 Linux 的 Kubernetes 控制面节点，你就可以为其选择联网方案。
|
||||
出于简单考虑，本指南展示如何使用 VXLAN 模式的 Flannel。
|
||||
|
||||
<!--
|
||||
#### Configuring Flannel
|
||||
|
||||
1. Prepare Kubernetes control plane for Flannel
|
||||
|
||||
Some minor preparation is recommended on the Kubernetes control plane in our cluster. It is recommended to enable bridged IPv4 traffic to iptables chains when using Flannel. The following command must be run on all Linux nodes:
|
||||
|
||||
```bash
|
||||
sudo sysctl net.bridge.bridge-nf-call-iptables=1
|
||||
```
|
||||
-->
|
||||
#### 配置 Flannel {#configuring-flannel}
|
||||
|
||||
1. 为 Flannel 准备 Kubernetes 的控制面
|
||||
|
||||
在我们的集群中，建议对 Kubernetes 的控制面进行少许准备处理。
|
||||
建议在使用 Flannel 时为 iptables 链启用桥接方式的 IPv4 流处理，
|
||||
必须在所有 Linux 节点上执行如下命令：
|
||||
|
||||
```bash
|
||||
sudo sysctl net.bridge.bridge-nf-call-iptables=1
|
||||
```
|
||||
|
||||
<!--
|
||||
1. Download & configure Flannel for Linux
|
||||
|
||||
Download the most recent Flannel manifest:
|
||||
|
||||
```bash
|
||||
wget https://raw.githubusercontent.com/coreos/flannel/master/Documentation/kube-flannel.yml
|
||||
```
|
||||
|
||||
Modify the `net-conf.json` section of the flannel manifest in order to set the VNI to 4096 and the Port to 4789. It should look as follows:
|
||||
|
||||
```json
|
||||
net-conf.json: |
|
||||
{
|
||||
"Network": "10.244.0.0/16",
|
||||
"Backend": {
|
||||
"Type": "vxlan",
|
||||
"VNI": 4096,
|
||||
"Port": 4789
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
The VNI must be set to 4096 and port 4789 for Flannel on Linux to interoperate with Flannel on Windows. See the [VXLAN documentation](https://github.com/coreos/flannel/blob/master/Documentation/backends.md#vxlan).
|
||||
for an explanation of these fields.
|
||||
|
||||
To use L2Bridge/Host-gateway mode instead change the value of `Type` to `"host-gw"` and omit `VNI` and `Port`.
|
||||
-->
|
||||
2. 下载并配置 Linux 版本的 Flannel
|
||||
|
||||
下载最新的 Flannel 清单文件：
|
||||
|
||||
```bash
|
||||
wget https://raw.githubusercontent.com/coreos/flannel/master/Documentation/kube-flannel.yml
|
||||
```
|
||||
|
||||
修改 Flannel 清单中的 `net-conf.json` 部分，将 VNI 设置为 4096，并将 Port 设置为 4789。
|
||||
结果看起来像下面这样：
|
||||
|
||||
```json
|
||||
net-conf.json: |
|
||||
{
|
||||
"Network": "10.244.0.0/16",
|
||||
"Backend": {
|
||||
"Type": "vxlan",
|
||||
"VNI": 4096,
|
||||
"Port": 4789
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
{{< note >}}
|
||||
在 Linux 节点上 VNI 必须设置为 4096，端口必须设置为 4789，这样才能令其与 Windows 上的
|
||||
Flannel 互操作。关于这些字段的详细说明，请参见
|
||||
[VXLAN 文档](https://github.com/coreos/flannel/blob/master/Documentation/backends.md#vxlan)。
|
||||
{{< /note >}}
|
||||
|
||||
{{< note >}}
|
||||
如要使用 L2Bridge/Host-gateway 模式，则可将 `Type` 值设置为
|
||||
`"host-gw"`，并忽略 `VNI` 和 `Port` 的设置。
|
||||
{{< /note >}}
|
||||
|
||||
<!--
|
||||
1. Apply the Flannel manifest and validate
|
||||
|
||||
Let's apply the Flannel configuration:
|
||||
|
||||
```bash
|
||||
kubectl apply -f kube-flannel.yml
|
||||
```
|
||||
|
||||
After a few minutes, you should see all the pods as running if the Flannel pod network was deployed.
|
||||
|
||||
```bash
|
||||
kubectl get pods -n kube-system
|
||||
```
|
||||
|
||||
The output should include the Linux flannel DaemonSet as running:
|
||||
|
||||
```
|
||||
NAMESPACE NAME READY STATUS RESTARTS AGE
|
||||
...
|
||||
kube-system kube-flannel-ds-54954 1/1 Running 0 1m
|
||||
```
|
||||
-->
|
||||
3. 应用 Flannel 清单并验证
|
||||
|
||||
首先应用 Flannel 配置：
|
||||
|
||||
```bash
|
||||
kubectl apply -f kube-flannel.yml
|
||||
```
|
||||
|
||||
几分钟之后，如果 Flannel Pod 网络被正确部署，你应该会看到所有 Pods 都处于运行中状态。
|
||||
|
||||
```bash
|
||||
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. Add Windows Flannel and kube-proxy DaemonSets
|
||||
|
||||
Now you can add Windows-compatible versions of Flannel and kube-proxy. In order
|
||||
to ensure that you get a compatible version of kube-proxy, you'll need to substitute
|
||||
the tag of the image. The following example shows usage for Kubernetes {{< param "fullversion" >}},
|
||||
but you should adjust the version for your own deployment.
|
||||
|
||||
```bash
|
||||
curl -L https://github.com/kubernetes-sigs/sig-windows-tools/releases/latest/download/kube-proxy.yml | sed 's/VERSION/{{< param "fullversion" >}}/g' | kubectl apply -f -
|
||||
kubectl apply -f https://github.com/kubernetes-sigs/sig-windows-tools/releases/latest/download/flannel-overlay.yml
|
||||
```
|
||||
|
||||
If you're using host-gateway use https://github.com/kubernetes-sigs/sig-windows-tools/releases/latest/download/flannel-host-gw.yml instead
|
||||
|
||||
If you're using a different interface rather than Ethernet (i.e. "Ethernet0 2") on the Windows nodes, you have to modify the line:
|
||||
|
||||
```powershell
|
||||
wins cli process run --path /k/flannel/setup.exe --args "--mode=overlay --interface=Ethernet"
|
||||
```
|
||||
|
||||
in the `flannel-host-gw.yml` or `flannel-overlay.yml` file and specify your interface accordingly.
|
||||
|
||||
```bash
|
||||
# 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 -
|
||||
```
|
||||
-->
|
||||
4. 添加 Windows Flannel 和 kube-proxy DaemonSet
|
||||
|
||||
现在你可以添加 Windows 兼容版本的 Flannel 和 kube-proxy。为了确保你能获得兼容
|
||||
版本的 kube-proxy，你需要替换镜像中的标签。
|
||||
下面的例子中展示的是针对 Kubernetes {{< param "fullversion" >}} 版本的用法，
|
||||
不过你应该根据你自己的集群部署调整其中的版本号。
|
||||
|
||||
```bash
|
||||
curl -L https://github.com/kubernetes-sigs/sig-windows-tools/releases/latest/download/kube-proxy.yml | sed 's/VERSION/{{< param "fullversion" >}}/g' | kubectl apply -f -
|
||||
kubectl apply -f https://github.com/kubernetes-sigs/sig-windows-tools/releases/latest/download/flannel-overlay.yml
|
||||
```
|
||||
|
||||
{{< note >}}
|
||||
如果你在使用 host-gateway 模式，则应该使用
|
||||
https://github.com/kubernetes-sigs/sig-windows-tools/releases/latest/download/flannel-host-gw.yml
|
||||
这一清单。
|
||||
{{< /note >}}
|
||||
|
||||
{{< note >}}
|
||||
如果你在 Windows 节点上使用的不是以太网（即，"Ethernet0 2"）接口，你需要
|
||||
修改 `flannel-host-gw.yml` 或 `flannel-overlay.yml` 文件中的下面这行：
|
||||
|
||||
```powershell
|
||||
wins cli process run --path /k/flannel/setup.exe --args "--mode=overlay --interface=Ethernet"
|
||||
```
|
||||
|
||||
在其中根据情况设置要使用的网络接口。
|
||||
|
||||
```bash
|
||||
# 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 -
|
||||
```
|
||||
{{< /note >}}
|
||||
|
||||
<!--
|
||||
### Joining a Windows worker node
|
||||
-->
|
||||
### 加入 Windows 工作节点 {#joining-a-windows-worker-node}
|
||||
|
||||
{{< note >}}
|
||||
<!--
|
||||
All code snippets in Windows sections are to be run in a PowerShell environment
|
||||
with elevated permissions (Administrator) on the Windows worker node.
|
||||
-->
|
||||
Windows 节的所有代码片段都需要在 PowerShell 环境中执行，并且要求在
|
||||
Windows 工作节点上具有提升的权限（Administrator）。
|
||||
{{< /note >}}
|
||||
|
||||
{{< tabs name="tab-windows-kubeadm-runtime-installation" >}}
|
||||
|
||||
{{% tab name="CRI-containerD" %}}
|
||||
|
||||
<!--
|
||||
#### Install containerD
|
||||
-->
|
||||
#### 安装 containerD
|
||||
|
||||
```powershell
|
||||
curl.exe -LO https://github.com/kubernetes-sigs/sig-windows-tools/releases/latest/download/Install-Containerd.ps1
|
||||
.\Install-Containerd.ps1
|
||||
```
|
||||
|
||||
{{< note >}}
|
||||
<!--
|
||||
To install a specific version of containerD specify the version with -ContainerDVersion.
|
||||
-->
|
||||
要安装特定版本的 containerD，使用参数 -ContainerDVersion 指定版本。
|
||||
|
||||
```powershell
|
||||
# Example
|
||||
.\Install-Containerd.ps1 -ContainerDVersion 1.4.1
|
||||
```
|
||||
<!--
|
||||
If you're using a different interface rather than Ethernet (i.e. "Ethernet0 2") on the Windows nodes, specify the name with `-netAdapterName`.
|
||||
-->
|
||||
如果你在 Windows 节点上使用了与 Ethernet 不同的接口（例如 "Ethernet0 2"），使用参数 `-netAdapterName` 指定名称。
|
||||
|
||||
```powershell
|
||||
# Example
|
||||
.\Install-Containerd.ps1 -netAdapterName "Ethernet0 2"
|
||||
```
|
||||
|
||||
{{< /note >}}
|
||||
|
||||
<!--
|
||||
#### Install wins, kubelet, and kubeadm
|
||||
-->
|
||||
#### 安装 wins、kubelet 和 kubeadm
|
||||
|
||||
```PowerShell
|
||||
curl.exe -LO https://raw.githubusercontent.com/kubernetes-sigs/sig-windows-tools/master/kubeadm/scripts/PrepareNode.ps1
|
||||
.\PrepareNode.ps1 -KubernetesVersion {{< param "fullversion" >}} -ContainerRuntime containerD
|
||||
```
|
||||
<!--
|
||||
Install `crictl` from the [cri-tools project](https://github.com/kubernetes-sigs/cri-tools)
|
||||
which is required so that kubeadm can talk to the CRI endpoint.
|
||||
-->
|
||||
从 [cri-tools](https://github.com/kubernetes-sigs/cri-tools) 项目安装 `crtctl`。
|
||||
`crictl` 是必需的，kubeadm 使用它与 CRI 端点通信。
|
||||
|
||||
<!--
|
||||
#### Run `kubeadm` to join the node
|
||||
|
||||
Use the command that was given to you when you ran `kubeadm init` on a control plane host.
|
||||
If you no longer have this command, or the token has expired, you can run `kubeadm token create --print-join-command`
|
||||
(on a control plane host) to generate a new token and join command.
|
||||
-->
|
||||
#### 运行 `kubeadm` 添加节点
|
||||
|
||||
使用当你在控制面主机上运行 `kubeadm init` 时得到的命令。
|
||||
如果你找不到这个命令，或者命令中对应的令牌已经过期，你可以（在一个控制面主机上）运行
|
||||
`kubeadm token create --print-join-command` 来生成新的令牌和 join 命令。
|
||||
|
||||
|
||||
{{% /tab %}}
|
||||
|
||||
|
||||
{{% tab name="Docker Engine" %}}
|
||||
|
||||
<!--
|
||||
#### Install Docker Engine
|
||||
|
||||
Install the `Containers` feature
|
||||
-->
|
||||
|
||||
#### 安装 Docker Engine
|
||||
|
||||
安装 `Containers` 功能特性
|
||||
|
||||
```powershell
|
||||
Install-WindowsFeature -Name containers
|
||||
```
|
||||
|
||||
<!--
|
||||
Install Docker
|
||||
Instructions to do so are available at [Install Docker Engine - Enterprise on Windows Servers](https://docs.microsoft.com/en-us/virtualization/windowscontainers/quick-start/set-up-environment?tabs=Windows-Server#install-docker).
|
||||
-->
|
||||
|
||||
安装 Docker
|
||||
|
||||
操作指南在
|
||||
[Install Docker Engine - Enterprise on Windows Servers](https://docs.microsoft.com/en-us/virtualization/windowscontainers/quick-start/set-up-environment?tabs=Windows-Server#install-docker)。
|
||||
|
||||
<!--
|
||||
[Install cri-dockerd](https://github.com/Mirantis/cri-dockerd) which is required so that the kubelet
|
||||
can communicate with Docker on a CRI compatible endpoint.
|
||||
-->
|
||||
|
||||
[安装 cri-dockerd](https://github.com/Mirantis/cri-dockerd)。kubelet 可以通过 cri-dockerd
|
||||
在 CRI 兼容的节点上与 Docker 通信。
|
||||
|
||||
{{< note >}}
|
||||
<!--
|
||||
Docker Engine does not implement the [CRI](/docs/concepts/architecture/cri/)
|
||||
which is a requirement for a container runtime to work with Kubernetes.
|
||||
For that reason, an additional service [cri-dockerd](https://github.com/Mirantis/cri-dockerd)
|
||||
has to be installed. cri-dockerd is a project based on the legacy built-in
|
||||
Docker Engine support that was [removed](/dockershim) from the kubelet in version 1.24.
|
||||
-->
|
||||
Docker Engine 没有实现 [CRI](/zh/docs/concepts/architecture/cri/)，
|
||||
而 CRI 是容器运行时能够与 Kubernetes 一起工作的要求。
|
||||
出于这个原因，必须安装一个额外的服务 [cri-dockerd](https://github.com/Mirantis/cri-dockerd)。
|
||||
cri-dockerd 是一个基于原来的内置 Docker Engine 支持的项目，
|
||||
而这一支持在 1.24 版本的 kubelet 中[已被移除](/zh/dockershim)。
|
||||
{{< /note >}}
|
||||
|
||||
<!--
|
||||
Install `crictl` from the [cri-tools project](https://github.com/kubernetes-sigs/cri-tools)
|
||||
which is required so that kubeadm can talk to the CRI endpoint.
|
||||
-->
|
||||
从 [cri-tools](https://github.com/kubernetes-sigs/cri-tools) 项目安装 `crictl`。
|
||||
kubeadm 需要 `crictl` 才能与 CRI 端点通信。
|
||||
|
||||
<!--
|
||||
#### Install wins, kubelet, and kubeadm.
|
||||
-->
|
||||
#### 安装 wins、kubelet 和 kubeadm
|
||||
|
||||
```PowerShell
|
||||
curl.exe -LO https://raw.githubusercontent.com/kubernetes-sigs/sig-windows-tools/master/kubeadm/scripts/PrepareNode.ps1
|
||||
.\PrepareNode.ps1 -KubernetesVersion {{< param "fullversion" >}}
|
||||
```
|
||||
<!--
|
||||
# ### Run `kubeadm` to join the node
|
||||
|
||||
Use the command that was given to you when you ran `kubeadm init` on a control plane host.
|
||||
If you no longer have this command, or the token has expired, you can run `kubeadm token create -print-join-command`
|
||||
(on a control plane host) to generate a new token and join command.
|
||||
-->
|
||||
#### 运行 `kubeadm` 添加节点
|
||||
|
||||
当你在控制面主机上运行 `kubeadm init` 时，输出了一个命令。现在运行这个命令。
|
||||
如果你找不到这个命令，或者命令中对应的令牌已经过期，你可以（在一个控制面主机上）运行
|
||||
`kubeadm token create --print-join-command` 来生成新的令牌和 join 命令。
|
||||
|
||||
{{% /tab %}}
|
||||
{{< /tabs >}}
|
||||
|
||||
<!--
|
||||
#### Verifying your installation
|
||||
|
||||
You should now be able to view the Windows node in your cluster by running:
|
||||
-->
|
||||
#### 检查你的安装 {#verifying-your-installation}
|
||||
|
||||
你现在应该能够通过运行下面的命令来查看集群中的 Windows 节点了：
|
||||
|
||||
```bash
|
||||
kubectl get nodes -o wide
|
||||
```
|
||||
|
||||
<!--
|
||||
If your new node is in the `NotReady` state it is likely because the flannel image is still downloading.
|
||||
You can check the progress as before by checking on the flannel pods in the `kube-system` namespace:
|
||||
-->
|
||||
如果你的新节点处于 `NotReady` 状态，很可能的原因是系统仍在下载 Flannel 镜像。
|
||||
你可以像之前一样，通过检查 `kube-system` 名字空间中的 Flannel Pods 来了解
|
||||
安装进度。
|
||||
|
||||
```shell
|
||||
kubectl -n kube-system get pods -l app=flannel
|
||||
```
|
||||
|
||||
<!--
|
||||
Once the flannel Pod is running, your node should enter the `Ready` state and then be available to handle workloads.
|
||||
-->
|
||||
一旦 Flannel Pod 运行起来，你的节点就应该能进入 `Ready` 状态并可
|
||||
用来处理负载。
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
<!--
|
||||
- [Upgrading Windows kubeadm nodes](/docs/tasks/administer-cluster/kubeadm/upgrading-windows-nodes)
|
||||
-->
|
||||
- [升级 kubeadm 安装的 Windows 节点](/zh/docs/tasks/administer-cluster/kubeadm/upgrading-windows-nodes)
|
||||
|
||||
@@ -0,0 +1,235 @@
|
||||
---
|
||||
title: 配置 cgroup 驱动
|
||||
content_type: task
|
||||
weight: 10
|
||||
---
|
||||
<!--
|
||||
---
|
||||
title: Configuring a cgroup driver
|
||||
content_type: task
|
||||
weight: 10
|
||||
---
|
||||
-->
|
||||
|
||||
<!-- overview -->
|
||||
|
||||
<!--
|
||||
This page explains how to configure the kubelet cgroup driver to match the container
|
||||
runtime cgroup driver for kubeadm clusters.
|
||||
-->
|
||||
本页阐述如何配置 kubelet 的 cgroup 驱动以匹配 kubeadm 集群中的容器运行时的 cgroup 驱动。
|
||||
|
||||
## {{% heading "prerequisites" %}}
|
||||
|
||||
<!--
|
||||
You should be familiar with the Kubernetes
|
||||
[container runtime requirements](/docs/setup/production-environment/container-runtimes).
|
||||
-->
|
||||
你应该熟悉 Kubernetes 的[容器运行时需求](/zh/docs/setup/production-environment/container-runtimes)。
|
||||
<!-- steps -->
|
||||
|
||||
<!--
|
||||
## Configuring the container runtime cgroup driver
|
||||
-->
|
||||
## 配置容器运行时 cgroup 驱动 {#configuring-the-container-runtime-cgroup-driver}
|
||||
|
||||
<!--
|
||||
The [Container runtimes](/docs/setup/production-environment/container-runtimes) page
|
||||
explains that the `systemd` driver is recommended for kubeadm based setups instead
|
||||
of the `cgroupfs` driver, because kubeadm manages the kubelet as a systemd service.
|
||||
-->
|
||||
[容器运行时](/zh/docs/setup/production-environment/container-runtimes)页面提到：
|
||||
由于 kubeadm 把 kubelet 视为一个系统服务来管理，所以对基于 kubeadm 的安装，
|
||||
我们推荐使用 `systemd` 驱动，不推荐 `cgroupfs` 驱动。
|
||||
|
||||
<!--
|
||||
The page also provides details on how to setup a number of different container runtimes with the
|
||||
`systemd` driver by default.
|
||||
-->
|
||||
此页还详述了如何安装若干不同的容器运行时，并将 `systemd` 设为其默认驱动。
|
||||
|
||||
<!--
|
||||
## Configuring the kubelet cgroup driver
|
||||
-->
|
||||
## 配置 kubelet 的 cgroup 驱动
|
||||
|
||||
<!--
|
||||
kubeadm allows you to pass a `KubeletConfiguration` structure during `kubeadm init`.
|
||||
This `KubeletConfiguration` can include the `cgroupDriver` field which controls the cgroup
|
||||
driver of the kubelet.
|
||||
-->
|
||||
kubeadm 支持在执行 `kubeadm init` 时，传递一个 `KubeletConfiguration` 结构体。
|
||||
`KubeletConfiguration` 包含 `cgroupDriver` 字段，可用于控制 kubelet 的 cgroup 驱动。
|
||||
|
||||
<!--
|
||||
In v1.22, if the user is not setting the `cgroupDriver` field under `KubeletConfiguration`,
|
||||
`kubeadm init` will default it to `systemd`.
|
||||
-->
|
||||
|
||||
{{< note >}}
|
||||
在版本 1.22 中，如果用户没有在 `KubeletConfiguration` 中设置 `cgroupDriver` 字段，
|
||||
`kubeadm init` 会将它设置为默认值 `systemd`。
|
||||
{{< /note >}}
|
||||
|
||||
<!--
|
||||
A minimal example of configuring the field explicitly:
|
||||
-->
|
||||
这是一个最小化的示例，其中显式的配置了此字段：
|
||||
|
||||
```yaml
|
||||
# kubeadm-config.yaml
|
||||
kind: ClusterConfiguration
|
||||
apiVersion: kubeadm.k8s.io/v1beta3
|
||||
kubernetesVersion: v1.21.0
|
||||
---
|
||||
kind: KubeletConfiguration
|
||||
apiVersion: kubelet.config.k8s.io/v1beta1
|
||||
cgroupDriver: systemd
|
||||
```
|
||||
|
||||
<!--
|
||||
Such a configuration file can then be passed to the kubeadm command:
|
||||
-->
|
||||
这样一个配置文件就可以传递给 kubeadm 命令了：
|
||||
|
||||
```shell
|
||||
kubeadm init --config kubeadm-config.yaml
|
||||
```
|
||||
|
||||
<!--
|
||||
Kubeadm uses the same `KubeletConfiguration` for all nodes in the cluster.
|
||||
The `KubeletConfiguration` is stored in a [ConfigMap](/docs/concepts/configuration/configmap)
|
||||
object under the `kube-system` namespace.
|
||||
|
||||
Executing the sub commands `init`, `join` and `upgrade` would result in kubeadm
|
||||
writing the `KubeletConfiguration` as a file under `/var/lib/kubelet/config.yaml`
|
||||
and passing it to the local node kubelet.
|
||||
-->
|
||||
{{< note >}}
|
||||
Kubeadm 对集群所有的节点，使用相同的 `KubeletConfiguration`。
|
||||
`KubeletConfiguration` 存放于 `kube-system` 命名空间下的某个
|
||||
[ConfigMap](/zh/docs/concepts/configuration/configmap) 对象中。
|
||||
|
||||
执行 `init`、`join` 和 `upgrade` 等子命令会促使 kubeadm
|
||||
将 `KubeletConfiguration` 写入到文件 `/var/lib/kubelet/config.yaml` 中，
|
||||
继而把它传递给本地节点的 kubelet。
|
||||
|
||||
{{< /note >}}
|
||||
|
||||
<!--
|
||||
## Using the `cgroupfs` driver
|
||||
-->
|
||||
# 使用 `cgroupfs` 驱动
|
||||
|
||||
<!--
|
||||
As this guide explains using the `cgroupfs` driver with kubeadm is not recommended.
|
||||
|
||||
To continue using `cgroupfs` and to prevent `kubeadm upgrade` from modifying the
|
||||
`KubeletConfiguration` cgroup driver on existing setups, you must be explicit
|
||||
about its value. This applies to a case where you do not wish future versions
|
||||
of kubeadm to apply the `systemd` driver by default.
|
||||
-->
|
||||
正如本指南阐述的：不推荐与 kubeadm 一起使用 `cgroupfs` 驱动。
|
||||
|
||||
如仍需使用 `cgroupfs`，
|
||||
且要防止 `kubeadm upgrade` 修改现有系统中 `KubeletConfiguration` 的 cgroup 驱动，
|
||||
你必须显式声明它的值。
|
||||
此方法应对的场景为：在将来某个版本的 kubeadm 中，你不想使用默认的 `systemd` 驱动。
|
||||
|
||||
<!--
|
||||
See the below section on "Modify the kubelet ConfigMap" for details on
|
||||
how to be explicit about the value.
|
||||
|
||||
If you wish to configure a container runtime to use the `cgroupfs` driver,
|
||||
you must refer to the documentation of the container runtime of your choice.
|
||||
-->
|
||||
参阅以下章节“修改 kubelet 的 ConfigMap”，了解显式设置该值的方法。
|
||||
|
||||
如果你希望配置容器运行时来使用 `cgroupfs` 驱动，
|
||||
则必须参考所选容器运行时的文档。
|
||||
|
||||
<!--
|
||||
## Migrating to the `systemd` driver
|
||||
-->
|
||||
## 迁移到 `systemd` 驱动
|
||||
|
||||
<!--
|
||||
To change the cgroup driver of an existing kubeadm cluster to `systemd` in-place,
|
||||
a similar procedure to a kubelet upgrade is required. This must include both
|
||||
steps outlined below.
|
||||
-->
|
||||
要将现有 kubeadm 集群的 cgroup 驱动就地升级为 `systemd`，
|
||||
需要执行一个与 kubelet 升级类似的过程。
|
||||
该过程必须包含下面两个步骤：
|
||||
|
||||
<!--
|
||||
Alternatively, it is possible to replace the old nodes in the cluster with new ones
|
||||
that use the `systemd` driver. This requires executing only the first step below
|
||||
before joining the new nodes and ensuring the workloads can safely move to the new
|
||||
nodes before deleting the old nodes.
|
||||
-->
|
||||
{{< note >}}
|
||||
还有一种方法，可以用已配置了 `systemd` 的新节点替换掉集群中的老节点。
|
||||
按这种方法，在加入新节点、确保工作负载可以安全迁移到新节点、及至删除旧节点这一系列操作之前，
|
||||
只需执行以下第一个步骤。
|
||||
{{< /note >}}
|
||||
|
||||
<!--
|
||||
### Modify the kubelet ConfigMap
|
||||
-->
|
||||
### 修改 kubelet 的 ConfigMap
|
||||
|
||||
<!--
|
||||
- Call `kubectl edit cm kubelet-config -n kube-system`.
|
||||
- Either modify the existing `cgroupDriver` value or add a new field that looks like this:
|
||||
-->
|
||||
- 运行 `kubectl edit cm kubelet-config -n kube-system`。
|
||||
- 修改现有 `cgroupDriver` 的值，或者新增如下式样的字段：
|
||||
|
||||
```yaml
|
||||
cgroupDriver: systemd
|
||||
```
|
||||
<!--
|
||||
This field must be present under the `kubelet:` section of the ConfigMap.
|
||||
-->
|
||||
该字段必须出现在 ConfigMap 的 `kubelet:` 小节下。
|
||||
|
||||
<!--
|
||||
### Update the cgroup driver on all nodes
|
||||
-->
|
||||
### 更新所有节点的 cgroup 驱动
|
||||
|
||||
<!--
|
||||
For each node in the cluster:
|
||||
|
||||
- [Drain the node](/docs/tasks/administer-cluster/safely-drain-node) using `kubectl drain <node-name> --ignore-daemonsets`
|
||||
- Stop the kubelet using `systemctl stop kubelet`
|
||||
- Stop the container runtime
|
||||
- Modify the container runtime cgroup driver to `systemd`
|
||||
- Set `cgroupDriver: systemd` in `/var/lib/kubelet/config.yaml`
|
||||
- Start the container runtime
|
||||
- Start the kubelet using `systemctl start kubelet`
|
||||
- [Uncordon the node](/docs/tasks/administer-cluster/safely-drain-node) using `kubectl uncordon <node-name>`
|
||||
-->
|
||||
对于集群中的每一个节点：
|
||||
|
||||
- 执行命令 `kubectl drain <node-name> --ignore-daemonsets`，以
|
||||
[腾空节点](/zh/docs/tasks/administer-cluster/safely-drain-node)
|
||||
- 执行命令 `systemctl stop kubelet`，以停止 kubelet
|
||||
- 停止容器运行时
|
||||
- 修改容器运行时 cgroup 驱动为 `systemd`
|
||||
- 在文件 `/var/lib/kubelet/config.yaml` 中添加设置 `cgroupDriver: systemd`
|
||||
- 启动容器运行时
|
||||
- 执行命令 `systemctl start kubelet`，以启动 kubelet
|
||||
- 执行命令 `kubectl uncordon <node-name>`，以
|
||||
[取消节点隔离](/zh/docs/tasks/administer-cluster/safely-drain-node)
|
||||
|
||||
<!--
|
||||
Execute these steps on nodes one at a time to ensure workloads
|
||||
have sufficient time to schedule on different nodes.
|
||||
|
||||
Once the process is complete ensure that all nodes and workloads are healthy.
|
||||
-->
|
||||
在节点上依次执行上述步骤，确保工作负载有充足的时间被调度到其他节点。
|
||||
|
||||
流程完成后，确认所有节点和工作负载均健康如常。
|
||||
@@ -0,0 +1,648 @@
|
||||
---
|
||||
title: 使用 kubeadm 进行证书管理
|
||||
content_type: task
|
||||
weight: 10
|
||||
---
|
||||
<!--
|
||||
reviewers:
|
||||
- sig-cluster-lifecycle
|
||||
title: Certificate Management with kubeadm
|
||||
content_type: task
|
||||
weight: 10
|
||||
-->
|
||||
|
||||
<!-- overview -->
|
||||
|
||||
{{< feature-state for_k8s_version="v1.15" state="stable" >}}
|
||||
|
||||
<!--
|
||||
Client certificates generated by [kubeadm](/docs/reference/setup-tools/kubeadm/) expire after 1 year.
|
||||
This page explains how to manage certificate renewals with kubeadm. It also covers other tasks related
|
||||
to kubeadm certificate management.
|
||||
-->
|
||||
由 [kubeadm](/zh/docs/reference/setup-tools/kubeadm/) 生成的客户端证书在 1 年后到期。
|
||||
本页说明如何使用 kubeadm 管理证书续订，同时也涵盖其他与 kubeadm 证书管理相关的说明。
|
||||
|
||||
## {{% heading "prerequisites" %}}
|
||||
|
||||
<!--
|
||||
You should be familiar with [PKI certificates and requirements in Kubernetes](/docs/setup/best-practices/certificates/).
|
||||
-->
|
||||
你应该熟悉 [Kubernetes 中的 PKI 证书和要求](/zh/docs/setup/best-practices/certificates/)。
|
||||
|
||||
<!-- steps -->
|
||||
|
||||
<!--
|
||||
## Using custom certificates {#custom-certificates}
|
||||
|
||||
By default, kubeadm generates all the certificates needed for a cluster to run.
|
||||
You can override this behavior by providing your own certificates.
|
||||
-->
|
||||
|
||||
## 使用自定义的证书 {#custom-certificates}
|
||||
|
||||
默认情况下，kubeadm 会生成运行一个集群所需的全部证书。
|
||||
你可以通过提供你自己的证书来改变这个行为策略。
|
||||
|
||||
<!--
|
||||
To do so, you must place them in whatever directory is specified by the
|
||||
`--cert-dir` flag or the `certificatesDir` field of kubeadm's `ClusterConfiguration`.
|
||||
By default this is `/etc/kubernetes/pki`.
|
||||
-->
|
||||
如果要这样做，你必须将证书文件放置在通过 `--cert-dir` 命令行参数或者 kubeadm 配置中的
|
||||
`certificatesDir` 配置项指明的目录中。默认的值是 `/etc/kubernetes/pki`。
|
||||
|
||||
<!--
|
||||
If a given certificate and private key pair exists before running `kubeadm init`,
|
||||
kubeadm does not overwrite them. This means you can, for example, copy an existing
|
||||
CA into `/etc/kubernetes/pki/ca.crt` and `/etc/kubernetes/pki/ca.key`,
|
||||
and kubeadm will use this CA for signing the rest of the certificates.
|
||||
-->
|
||||
如果在运行 `kubeadm init` 之前存在给定的证书和私钥对，kubeadm 将不会重写它们。
|
||||
例如，这意味着你可以将现有的 CA 复制到 `/etc/kubernetes/pki/ca.crt` 和
|
||||
`/etc/kubernetes/pki/ca.key` 中，而 kubeadm 将使用此 CA 对其余证书进行签名。
|
||||
|
||||
<!--
|
||||
## External CA mode {#external-ca-mode}
|
||||
|
||||
It is also possible to provide only the `ca.crt` file and not the
|
||||
`ca.key` file (this is only available for the root CA file, not other cert pairs).
|
||||
If all other certificates and kubeconfig files are in place, kubeadm recognizes
|
||||
this condition and activates the "External CA" mode. kubeadm will proceed without the
|
||||
CA key on disk.
|
||||
-->
|
||||
|
||||
## 外部 CA 模式 {#external-ca-mode}
|
||||
|
||||
只提供了 `ca.crt` 文件但是不提供 `ca.key` 文件也是可以的
|
||||
（这只对 CA 根证书可用，其它证书不可用）。
|
||||
如果所有的其它证书和 kubeconfig 文件已就绪，kubeadm 检测到满足以上条件就会激活
|
||||
"外部 CA" 模式。kubeadm 将会在没有 CA 密钥文件的情况下继续执行。
|
||||
|
||||
<!--
|
||||
Instead, run the controller-manager standalone with `--controllers=csrsigner` and
|
||||
point to the CA certificate and key.
|
||||
-->
|
||||
否则，kubeadm 将独立运行 controller-manager，附加一个
|
||||
`--controllers=csrsigner` 的参数，并且指明 CA 证书和密钥。
|
||||
|
||||
<!--
|
||||
[PKI certificates and requirements](/docs/setup/best-practices/certificates/) includes guidance on
|
||||
setting up a cluster to use an external CA.
|
||||
-->
|
||||
[PKI 证书和要求](/zh/docs/setup/best-practices/certificates/)包括集群使用外部 CA 的设置指南。
|
||||
|
||||
<!--
|
||||
## Check certificate expiration
|
||||
|
||||
You can use the `check-expiration` subcommand to check when certificates expire:
|
||||
-->
|
||||
## 检查证书是否过期 {#check-certificate-expiration}
|
||||
|
||||
你可以使用 `check-expiration` 子命令来检查证书何时过期
|
||||
|
||||
```shell
|
||||
kubeadm certs check-expiration
|
||||
```
|
||||
|
||||
<!--
|
||||
The output is similar to this:
|
||||
-->
|
||||
输出类似于以下内容：
|
||||
|
||||
```
|
||||
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
|
||||
```
|
||||
|
||||
<!--
|
||||
The command shows expiration/residual time for the client certificates in the `/etc/kubernetes/pki` folder and for the client certificate embedded in the KUBECONFIG files used by kubeadm (`admin.conf`, `controller-manager.conf` and `scheduler.conf`).
|
||||
-->
|
||||
该命令显示 `/etc/kubernetes/pki` 文件夹中的客户端证书以及
|
||||
kubeadm（`admin.conf`、`controller-manager.conf` 和 `scheduler.conf`）
|
||||
使用的 KUBECONFIG 文件中嵌入的客户端证书的到期时间/剩余时间。
|
||||
|
||||
<!--
|
||||
Additionally, kubeadm informs the user if the certificate is externally managed; in this case, the user should take care of managing certificate renewal manually/using other tools.
|
||||
-->
|
||||
另外，kubeadm 会通知用户证书是否由外部管理；
|
||||
在这种情况下，用户应该小心的手动/使用其他工具来管理证书更新。
|
||||
|
||||
<!--
|
||||
`kubeadm` cannot manage certificates signed by an external CA.
|
||||
-->
|
||||
{{< warning >}}
|
||||
`kubeadm` 不能管理由外部 CA 签名的证书
|
||||
{{< /warning >}}
|
||||
|
||||
<!--
|
||||
`kubelet.conf` is not included in the list above because kubeadm configures kubelet
|
||||
for [automatic certificate renewal](/docs/tasks/tls/certificate-rotation/)
|
||||
with rotatable certificates under `/var/lib/kubelet/pki`.
|
||||
To repair an expired kubelet client certificate see
|
||||
[Kubelet client certificate rotation fails](/docs/setup/production-environment/tools/kubeadm/troubleshooting-kubeadm/#kubelet-client-cert).
|
||||
-->
|
||||
{{< note >}}
|
||||
上面的列表中没有包含 `kubelet.conf`，因为 kubeadm 将 kubelet 配置为
|
||||
[自动更新证书](/zh/docs/tasks/tls/certificate-rotation/)。
|
||||
轮换的证书位于目录 `/var/lib/kubelet/pki`。
|
||||
要修复过期的 kubelet 客户端证书，请参阅
|
||||
[kubelet 客户端证书轮换失败](/zh/docs/setup/production-environment/tools/kubeadm/troubleshooting-kubeadm/#kubelet-client-cert)。
|
||||
{{< /note >}}
|
||||
|
||||
<!--
|
||||
On nodes created with `kubeadm init`, prior to kubeadm version 1.17, there is a
|
||||
[bug](https://github.com/kubernetes/kubeadm/issues/1753) where you manually have to modify the contents of `kubelet.conf`. After `kubeadm init` finishes, you should update `kubelet.conf` to point to the
|
||||
rotated kubelet client certificates, by replacing `client-certificate-data` and `client-key-data` with:
|
||||
-->
|
||||
{{< warning >}}
|
||||
在通过 `kubeadm init` 创建的节点上，在 kubeadm 1.17 版本之前有一个
|
||||
[缺陷](https://github.com/kubernetes/kubeadm/issues/1753)，该缺陷
|
||||
使得你必须手动修改 `kubelet.conf` 文件的内容。
|
||||
`kubeadm init` 操作结束之后，你必须更新 `kubelet.conf` 文件
|
||||
将 `client-certificate-data` 和 `client-key-data` 改为如下所示的内容
|
||||
以便使用轮换后的 kubelet 客户端证书：
|
||||
|
||||
```yaml
|
||||
client-certificate: /var/lib/kubelet/pki/kubelet-client-current.pem
|
||||
client-key: /var/lib/kubelet/pki/kubelet-client-current.pem
|
||||
```
|
||||
{{< /warning >}}
|
||||
|
||||
<!--
|
||||
## Automatic certificate renewal
|
||||
|
||||
kubeadm renews all the certificates during control plane [upgrade](/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade/).
|
||||
-->
|
||||
|
||||
## 自动更新证书 {#automatic-certificate-renewal}
|
||||
|
||||
kubeadm 会在控制面
|
||||
[升级](/zh/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade/)
|
||||
的时候更新所有证书。
|
||||
|
||||
<!--
|
||||
This feature is designed for addressing the simplest use cases;
|
||||
if you don't have specific requirements on certificate renewal and perform Kubernetes version upgrades regularly (less than 1 year in between each upgrade), kubeadm will take care of keeping your cluster up to date and reasonably secure.
|
||||
-->
|
||||
这个功能旨在解决最简单的用例；如果你对此类证书的更新没有特殊要求，
|
||||
并且定期执行 Kubernetes 版本升级（每次升级之间的间隔时间少于 1 年），
|
||||
则 kubeadm 将确保你的集群保持最新状态并保持合理的安全性。
|
||||
|
||||
<!--
|
||||
It is a best practice to upgrade your cluster frequently in order to stay secure.
|
||||
-->
|
||||
{{< note >}}
|
||||
最佳的做法是经常升级集群以确保安全。
|
||||
{{< /note >}}
|
||||
|
||||
<!--
|
||||
If you have more complex requirements for certificate renewal, you can opt out from the default behavior by passing `--certificate-renewal=false` to `kubeadm upgrade apply` or to `kubeadm upgrade node`.
|
||||
-->
|
||||
如果你对证书更新有更复杂的需求，则可通过将 `--certificate-renewal=false` 传递给
|
||||
`kubeadm upgrade apply` 或者 `kubeadm upgrade node`，从而选择不采用默认行为。
|
||||
|
||||
<!--
|
||||
Prior to kubeadm version 1.17 there is a [bug](https://github.com/kubernetes/kubeadm/issues/1818)
|
||||
where the default value for `--certificate-renewal` is `false` for the `kubeadm upgrade node`
|
||||
command. In that case, you should explicitly set `--certificate-renewal=true`.
|
||||
-->
|
||||
{{< warning >}}
|
||||
kubeadm 在 1.17 版本之前有一个[缺陷](https://github.com/kubernetes/kubeadm/issues/1818)，
|
||||
该缺陷导致 `kubeadm update node` 执行时 `--certificate-renewal` 的默认值被设置为 `false`。
|
||||
在这种情况下，你需要显式地设置 `--certificate-renewal=true`。
|
||||
{{< /warning >}}
|
||||
|
||||
<!--
|
||||
## Manual certificate renewal
|
||||
|
||||
You can renew your certificates manually at any time with the `kubeadm certs renew` command.
|
||||
-->
|
||||
## 手动更新证书 {#manual-certificate-renewal}
|
||||
|
||||
你能随时通过 `kubeadm certs renew` 命令手动更新你的证书。
|
||||
|
||||
<!--
|
||||
This command performs the renewal using CA (or front-proxy-CA) certificate and key stored in `/etc/kubernetes/pki`.
|
||||
|
||||
After running the command you should restart the control plane Pods. This is required since
|
||||
dynamic certificate reload is currently not supported for all components and certificates.
|
||||
[Static Pods](/docs/tasks/configure-pod-container/static-pod/) are managed by the local kubelet
|
||||
and not by the API Server, thus kubectl cannot be used to delete and restart them.
|
||||
To restart a static Pod you can temporarily remove its manifest file from `/etc/kubernetes/manifests/`
|
||||
and wait for 20 seconds (see the `fileCheckFrequency` value in [KubeletConfiguration struct](/docs/reference/config-api/kubelet-config.v1beta1/).
|
||||
The kubelet will terminate the Pod if it's no longer in the manifest directory.
|
||||
You can then move the file back and after another `fileCheckFrequency` period, the kubelet will recreate
|
||||
the Pod and the certificate renewal for the component can complete.
|
||||
-->
|
||||
此命令用 CA（或者 front-proxy-CA ）证书和存储在 `/etc/kubernetes/pki` 中的密钥执行更新。
|
||||
|
||||
执行完此命令之后你需要重启控制面 Pods。因为动态证书重载目前还不被所有组件和证书支持，所有这项操作是必须的。
|
||||
[静态 Pods](/zh/docs/tasks/configure-pod-container/static-pod/) 是被本地 kubelet 而不是 API Server 管理，
|
||||
所以 kubectl 不能用来删除或重启他们。
|
||||
要重启静态 Pod 你可以临时将清单文件从 `/etc/kubernetes/manifests/` 移除并等待 20 秒
|
||||
（参考 [KubeletConfiguration 结构](/zh/docs/reference/config-api/kubelet-config.v1beta1/) 中的`fileCheckFrequency` 值）。
|
||||
如果 Pod 不在清单目录里，kubelet 将会终止它。
|
||||
在另一个 `fileCheckFrequency` 周期之后你可以将文件移回去，为了组件可以完成 kubelet 将重新创建 Pod 和证书更新。
|
||||
|
||||
<!--
|
||||
If you are running an HA cluster, this command needs to be executed on all the control-plane nodes.
|
||||
-->
|
||||
{{< warning >}}
|
||||
如果你运行了一个 HA 集群，这个命令需要在所有控制面板节点上执行。
|
||||
{{< /warning >}}
|
||||
|
||||
<!--
|
||||
`certs renew` uses the existing certificates as the authoritative source for attributes (Common Name, Organization, SAN, etc.) instead of the kubeadm-config ConfigMap. It is strongly recommended to keep them both in sync.
|
||||
-->
|
||||
{{< note >}}
|
||||
`certs renew` 使用现有的证书作为属性（Common Name、Organization、SAN 等）的权威来源，
|
||||
而不是 kubeadm-config ConfigMap。强烈建议使它们保持同步。
|
||||
{{< /note >}}
|
||||
|
||||
<!--
|
||||
`kubeadm certs renew` provides the following options:
|
||||
-->
|
||||
`kubeadm certs renew` 提供以下选项：
|
||||
|
||||
<!--
|
||||
The Kubernetes certificates normally reach their expiration date after one year.
|
||||
-->
|
||||
Kubernetes 证书通常在一年后到期。
|
||||
|
||||
<!--
|
||||
- `--csr-only` can be used to renew certificates with an external CA by generating certificate signing requests (without actually renewing certificates in place); see next paragraph for more information.
|
||||
- It's also possible to renew a single certificate instead of all.
|
||||
-->
|
||||
|
||||
- `--csr-only` 可用于经过一个外部 CA 生成的证书签名请求来更新证书（无需实际替换更新证书）；
|
||||
更多信息请参见下节。
|
||||
- 可以更新单个证书而不是全部证书。
|
||||
|
||||
<!--
|
||||
## Renew certificates with the Kubernetes certificates API
|
||||
|
||||
This section provides more details about how to execute manual certificate renewal using the Kubernetes certificates API.
|
||||
-->
|
||||
## 用 Kubernetes 证书 API 更新证书 {#renew-certificates-with-the-kubernetes-certificates-api}
|
||||
|
||||
本节提供有关如何使用 Kubernetes 证书 API 执行手动证书更新的更多详细信息。
|
||||
|
||||
<!--
|
||||
These are advanced topics for users who need to integrate their organization's certificate infrastructure into a kubeadm-built cluster. If the default kubeadm configuration satisfies your needs, you should let kubeadm manage certificates instead.
|
||||
-->
|
||||
{{< caution >}}
|
||||
这些是针对需要将其组织的证书基础结构集成到 kubeadm 构建的集群中的用户的高级主题。
|
||||
如果默认的 kubeadm 配置满足了你的需求，则应让 kubeadm 管理证书。
|
||||
{{< /caution >}}
|
||||
|
||||
<!--
|
||||
### Set up a signer
|
||||
|
||||
The Kubernetes Certificate Authority does not work out of the box.
|
||||
You can configure an external signer such as [cert-manager](https://cert-manager.io/docs/configuration/ca/), or you can use the built-in signer.
|
||||
The built-in signer is part of [`kube-controller-manager`](/docs/reference/command-line-tools-reference/kube-controller-manager/).
|
||||
To activate the built-in signer, you must pass the `--cluster-signing-cert-file` and `--cluster-signing-key-file` flags.
|
||||
-->
|
||||
|
||||
### 设置一个签名者（Signer） {#set-up-a-signer}
|
||||
|
||||
Kubernetes 证书颁发机构不是开箱即用。你可以配置外部签名者，例如 [cert-manager](https://cert-manager.io/docs/configuration/ca/)，
|
||||
也可以使用内置签名者。
|
||||
内置签名者是
|
||||
[`kube-controller-manager`](/zh/docs/reference/command-line-tools-reference/kube-controller-manager/) 的一部分。
|
||||
要激活内置签名者，请传递 `--cluster-signing-cert-file` 和 `--cluster-signing-key-file` 参数。
|
||||
|
||||
<!--
|
||||
If you're creating a new cluster, you can use a kubeadm [configuration file](https://pkg.go.dev/k8s.io/kubernetes/cmd/kubeadm/app/apis/kubeadm/v1beta3):
|
||||
-->
|
||||
如果你正在创建一个新的集群，你可以使用 kubeadm 的
|
||||
[配置文件](/zh/docs/reference/config-api/kubeadm-config.v1beta3/)。
|
||||
|
||||
```yaml
|
||||
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
|
||||
```
|
||||
|
||||
<!--
|
||||
### Create certificate signing requests (CSR)
|
||||
-->
|
||||
### 创建证书签名请求 (CSR) {#create-certificate-signing-requests-csr}
|
||||
|
||||
<!--
|
||||
See [Create CertificateSigningRequest](/docs/reference/access-authn-authz/certificate-signing-requests/#create-certificatesigningrequest) for creating CSRs with the Kubernetes API.
|
||||
-->
|
||||
有关使用 Kubernetes API 创建 CSR 的信息，
|
||||
请参见[创建 CertificateSigningRequest](/zh/docs/reference/access-authn-authz/certificate-signing-requests/#create-certificatesigningrequest)。
|
||||
|
||||
<!--
|
||||
## Renew certificates with external CA
|
||||
|
||||
This section provide more details about how to execute manual certificate renewal using an external CA.
|
||||
-->
|
||||
## 通过外部 CA 更新证书 {#renew-certificates-with-external-ca}
|
||||
|
||||
本节提供有关如何使用外部 CA 执行手动更新证书的更多详细信息。
|
||||
|
||||
<!--
|
||||
To better integrate with external CAs, kubeadm can also produce certificate signing requests (CSRs).
|
||||
A CSR represents a request to a CA for a signed certificate for a client.
|
||||
In kubeadm terms, any certificate that would normally be signed by an on-disk CA can be produced as a CSR instead. A CA, however, cannot be produced as a CSR.
|
||||
-->
|
||||
为了更好的与外部 CA 集成，kubeadm 还可以生成证书签名请求（CSR）。
|
||||
CSR 表示向 CA 请求客户的签名证书。
|
||||
在 kubeadm 术语中，通常由磁盘 CA 签名的任何证书都可以作为 CSR 生成。但是，CA 不能作为 CSR 生成。
|
||||
|
||||
<!--
|
||||
### Create certificate signing requests (CSR)
|
||||
|
||||
You can create certificate signing requests with `kubeadm certs renew --csr-only`.
|
||||
|
||||
Both the CSR and the accompanying private key are given in the output.
|
||||
You can pass in a directory with `--csr-dir` to output the CSRs to the specified location.
|
||||
If `--csr-dir` is not specified, the default certificate directory (`/etc/kubernetes/pki`) is used.
|
||||
-->
|
||||
### 创建证书签名请求 (CSR) {#create-certificate-signing-requests-csr-1}
|
||||
|
||||
你可以通过 `kubeadm certs renew --csr-only` 命令创建证书签名请求。
|
||||
|
||||
CSR 和随附的私钥都在输出中给出。
|
||||
你可以传入一个带有 `--csr-dir` 的目录，将 CRS 输出到指定位置。
|
||||
如果未指定 `--csr-dir`，则使用默认证书目录（`/etc/kubernetes/pki`）。
|
||||
|
||||
<!--
|
||||
Certificates can be renewed with `kubeadm certs renew --csr-only`.
|
||||
As with `kubeadm init`, an output directory can be specified with the `--csr-dir` flag.
|
||||
-->
|
||||
证书可以通过 `kubeadm certs renew --csr-only` 来续订。
|
||||
和 `kubeadm init` 一样，可以使用 `--csr-dir` 标志指定一个输出目录。
|
||||
|
||||
CSR 签署证书后，必须将证书和私钥复制到 PKI 目录（默认情况下为 `/etc/kubernetes/pki`）。
|
||||
|
||||
<!--
|
||||
A CSR contains a certificate's name, domains, and IPs, but it does not specify usages.
|
||||
It is the responsibility of the CA to specify [the correct cert usages](/docs/setup/best-practices/certificates/#all-certificates)
|
||||
when issuing a certificate.
|
||||
-->
|
||||
CSR 中包含一个证书的名字，域和 IP，但是未指定用法。
|
||||
颁发证书时，CA 有责任指定[正确的证书用法](/zh/docs/setup/best-practices/certificates/#all-certificates)
|
||||
|
||||
<!--
|
||||
* In `openssl` this is done with the
|
||||
[`openssl ca` command](https://superuser.com/questions/738612/openssl-ca-keyusage-extension).
|
||||
* In `cfssl` you specify
|
||||
[usages in the config file](https://github.com/cloudflare/cfssl/blob/master/doc/cmd/cfssl.txt#L170).
|
||||
-->
|
||||
* 在 `openssl` 中，这是通过
|
||||
[`openssl ca` 命令](https://superuser.com/questions/738612/openssl-ca-keyusage-extension)
|
||||
来完成的。
|
||||
* 在 `cfssl` 中，这是通过
|
||||
[在配置文件中指定用法](https://github.com/cloudflare/cfssl/blob/master/doc/cmd/cfssl.txt#L170)
|
||||
来完成的。
|
||||
|
||||
<!--
|
||||
After a certificate is signed using your preferred method, the certificate and the private key must be copied to the PKI directory (by default `/etc/kubernetes/pki`).
|
||||
-->
|
||||
使用首选方法对证书签名后，必须将证书和私钥复制到 PKI 目录（默认为 `/etc/kubernetes/pki` ）。
|
||||
|
||||
<!--
|
||||
## Certificate authority (CA) rotation {#certificate-authority-rotation}
|
||||
|
||||
Kubeadm does not support rotation or replacement of CA certificates out of the box.
|
||||
|
||||
For more information about manual rotation or replacement of CA, see [manual rotation of CA certificates](/docs/tasks/tls/manual-rotation-of-ca-certificates/).
|
||||
-->
|
||||
## 证书机构（CA）轮换 {#certificate-authority-rotation}
|
||||
|
||||
kubeadm 并不直接支持对 CA 证书的轮换或者替换。
|
||||
|
||||
关于手动轮换或者置换 CA 的更多信息，可参阅
|
||||
[手动轮换 CA 证书](/zh/docs/tasks/tls/manual-rotation-of-ca-certificates/)。
|
||||
|
||||
<!--
|
||||
## Enabling signed kubelet serving certificates {#kubelet-serving-certs}
|
||||
|
||||
By default the kubelet serving certificate deployed by kubeadm is self-signed.
|
||||
This means a connection from external services like the
|
||||
[metrics-server](https://github.com/kubernetes-sigs/metrics-server) to a
|
||||
kubelet cannot be secured with TLS.
|
||||
|
||||
To configure the kubelets in a new kubeadm cluster to obtain properly signed serving
|
||||
certificates you must pass the following minimal configuration to `kubeadm init`:
|
||||
-->
|
||||
## 启用已签名的 kubelet 服务证书 {#kubelet-serving-certs}
|
||||
|
||||
默认情况下，kubeadm 所部署的 kubelet 服务证书是自签名（Self-Signed）。
|
||||
这意味着从 [metrics-server](https://github.com/kubernetes-sigs/metrics-server)
|
||||
这类外部服务发起向 kubelet 的链接时无法使用 TLS 来完成保护。
|
||||
|
||||
要在新的 kubeadm 集群中配置 kubelet 以使用被正确签名的服务证书，
|
||||
你必须向 `kubeadm init` 传递如下最小配置数据：
|
||||
|
||||
```yaml
|
||||
apiVersion: kubeadm.k8s.io/v1beta3
|
||||
kind: ClusterConfiguration
|
||||
---
|
||||
apiVersion: kubelet.config.k8s.io/v1beta1
|
||||
kind: KubeletConfiguration
|
||||
serverTLSBootstrap: true
|
||||
```
|
||||
|
||||
<!--
|
||||
If you have already created the cluster you must adapt it by doing the following:
|
||||
- Find and edit the `kubelet-config-{{< skew latestVersion >}}` ConfigMap in the `kube-system` namespace.
|
||||
In that ConfigMap, the `kubelet` key has a
|
||||
[KubeletConfiguration](/docs/reference/config-api/kubelet-config.v1beta1/#kubelet-config-k8s-io-v1beta1-KubeletConfiguration)
|
||||
document as its value. Edit the KubeletConfiguration document to set `serverTLSBootstrap: true`.
|
||||
- On each node, add the `serverTLSBootstrap: true` field in `/var/lib/kubelet/config.yaml`
|
||||
and restart the kubelet with `systemctl restart kubelet`
|
||||
-->
|
||||
如果你已经创建了集群，你必须通过执行下面的操作来完成适配：
|
||||
|
||||
- 找到 `kube-system` 名字空间中名为 `kubelet-config-{{< skew latestVersion >}}`
|
||||
的 ConfigMap 并编辑之。
|
||||
在该 ConfigMap 中，`kubelet` 键下面有一个
|
||||
[KubeletConfiguration](/zh/docs/reference/config-api/kubelet-config.v1beta1/#kubelet-config-k8s-io-v1beta1-KubeletConfiguration)
|
||||
文档作为其取值。编辑该 KubeletConfiguration 文档以设置
|
||||
`serverTLSBootstrap: true`。
|
||||
- 在每个节点上，在 `/var/lib/kubelet/config.yaml` 文件中添加
|
||||
`serverTLSBootstrap: true` 字段，并使用 `systemctl restart kubelet`
|
||||
来重启 kubelet。
|
||||
|
||||
<!--
|
||||
The field `serverTLSBootstrap: true` will enable the bootstrap of kubelet serving
|
||||
certificates by requesting them from the `certificates.k8s.io` API. One known limitation
|
||||
is that the CSRs (Certificate Signing Requests) for these certificates cannot be automatically
|
||||
approved by the default signer in the kube-controller-manager -
|
||||
[`kubernetes.io/kubelet-serving`](/docs/reference/access-authn-authz/certificate-signing-requests/#kubernetes-signers).
|
||||
This will require action from the user or a third party controller.
|
||||
|
||||
These CSRs can be viewed using:
|
||||
-->
|
||||
字段 `serverTLSBootstrap` 将允许启动引导 kubelet 的服务证书，方式
|
||||
是从 `certificates.k8s.io` API 处读取。这种方式的一种局限在于这些
|
||||
证书的 CSR（证书签名请求）不能被 kube-controller-manager 中默认的
|
||||
签名组件
|
||||
[`kubernetes.io/kubelet-serving`](/zh/docs/reference/access-authn-authz/certificate-signing-requests/#kubernetes-signers)
|
||||
批准。需要用户或者第三方控制器来执行此操作。
|
||||
|
||||
可以使用下面的命令来查看 CSR：
|
||||
|
||||
```shell
|
||||
kubectl get csr
|
||||
```
|
||||
|
||||
```none
|
||||
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
|
||||
```
|
||||
|
||||
<!--
|
||||
To approve them you can do the following:
|
||||
-->
|
||||
你可以执行下面的操作来批准这些请求：
|
||||
|
||||
```shell
|
||||
kubectl certificate approve <CSR-名称>
|
||||
```
|
||||
|
||||
<!--
|
||||
By default, these serving certificate will expire after one year. Kubeadm sets the
|
||||
`KubeletConfiguration` field `rotateCertificates` to `true`, which means that close
|
||||
to expiration a new set of CSRs for the serving certificates will be created and must
|
||||
be approved to complete the rotation. To understand more see
|
||||
[Certificate Rotation](/docs/reference/access-authn-authz/kubelet-tls-bootstrapping/#certificate-rotation).
|
||||
-->
|
||||
默认情况下，这些服务证书上会在一年后过期。
|
||||
kubeadm 将 `KubeletConfiguration` 的 `rotateCertificates` 字段设置为
|
||||
`true`；这意味着证书快要过期时，会生成一组针对服务证书的新的 CSR，而
|
||||
这些 CSR 也要被批准才能完成证书轮换。
|
||||
要进一步了解这里的细节，可参阅
|
||||
[证书轮换](/zh/docs/reference/access-authn-authz/kubelet-tls-bootstrapping/#certificate-rotation)
|
||||
文档。
|
||||
|
||||
<!--
|
||||
If you are looking for a solution for automatic approval of these CSRs it is recommended
|
||||
that you contact your cloud provider and ask if they have a CSR signer that verifies
|
||||
the node identity with an out of band mechanism.
|
||||
-->
|
||||
如果你在寻找一种能够自动批准这些 CSR 的解决方案，建议你与你的云提供商
|
||||
联系，询问他们是否有 CSR 签名组件，用来以带外（out-of-band）的方式检查
|
||||
节点的标识符。
|
||||
|
||||
{{% thirdparty-content %}}
|
||||
|
||||
<!--
|
||||
Third party custom controllers can be used:
|
||||
- [kubelet-csr-approver](https://github.com/postfinance/kubelet-csr-approver)
|
||||
|
||||
Such a controller is not a secure mechanism unless it not only verifies the CommonName
|
||||
in the CSR but also verifies the requested IPs and domain names. This would prevent
|
||||
a malicious actor that has access to a kubelet client certificate to create
|
||||
CSRs requesting serving certificates for any IP or domain name.
|
||||
-->
|
||||
也可以使用第三方定制的控制器：
|
||||
|
||||
- [kubelet-csr-approver](https://github.com/postfinance/kubelet-csr-approver)
|
||||
|
||||
除非既能够验证 CSR 中的 CommonName，也能检查请求的 IP 和域名，
|
||||
这类控制器还算不得安全的机制。
|
||||
只有完成彻底的检查，才有可能避免有恶意的、能够访问 kubelet 客户端证书的第三方
|
||||
为任何 IP 或域名请求服务证书。
|
||||
|
||||
<!--
|
||||
## Generating kubeconfig files for additional users {#kubeconfig-additional-users}
|
||||
-->
|
||||
## 为其他用户生成 kubeconfig 文件 {#kubeconfig-additional-users}
|
||||
|
||||
<!--
|
||||
During cluster creation, kubeadm signs the certificate in the `admin.conf` to have
|
||||
`Subject: O = system:masters, CN = kubernetes-admin`.
|
||||
[`system:masters`](/docs/reference/access-authn-authz/rbac/#user-facing-roles)
|
||||
is a break-glass, super user group that bypasses the authorization layer (e.g. RBAC).
|
||||
Sharing the `admin.conf` with additional users is **not recommended**!
|
||||
-->
|
||||
在集群创建过程中，kubeadm 对 `admin.conf` 中的证书进行签名时，将其配置为
|
||||
`Subject: O = system:masters, CN = kubernetes-admin`。
|
||||
[`system:masters`](/zh/docs/reference/access-authn-authz/rbac/#user-facing-roles)
|
||||
是一个例外的超级用户组，可以绕过鉴权层（例如 RBAC）。
|
||||
强烈建议不要将 `admin.conf` 文件与任何人共享。
|
||||
|
||||
<!--
|
||||
Instead, you can use the [`kubeadm kubeconfig user`](/docs/reference/setup-tools/kubeadm/kubeadm-kubeconfig)
|
||||
command to generate kubeconfig files for additional users.
|
||||
The command accepts a mixture of command line flags and
|
||||
[kubeadm configuration](/docs/reference/config-api/kubeadm-config.v1beta3/) options.
|
||||
The generated kubeconfig will be written to stdout and can be piped to a file
|
||||
using `kubeadm kubeconfig user ... > somefile.conf`.
|
||||
-->
|
||||
你要使用 [`kubeadm kubeconfig user`](/zh/docs/reference/setup-tools/kubeadm/kubeadm-kubeconfig)
|
||||
命令为其他用户生成 kubeconfig 文件，这个命令支持命令行参数和
|
||||
[kubeadm 配置结构](/zh/docs/reference/config-api/kubeadm-config.v1beta3/)。
|
||||
以上命令会将 kubeconfig 打印到终端上，也可以使用 `kubeadm kubeconfig user ... > somefile.conf`
|
||||
输出到一个文件中。
|
||||
|
||||
<!--
|
||||
Example configuration file that can be used with `--config`:
|
||||
-->
|
||||
如下 kubeadm 可以在 `--config` 后加的配置文件示例：
|
||||
|
||||
```yaml
|
||||
# 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"
|
||||
```
|
||||
|
||||
<!--
|
||||
Make sure that these settings match the desired target cluster settings.
|
||||
To see the settings of an existing cluster use:
|
||||
-->
|
||||
确保这些设置与所需的目标集群设置相匹配。可以使用以下命令查看现有集群的设置：
|
||||
|
||||
```shell
|
||||
kubectl get cm kubeadm-config -n kube-system -o=jsonpath="{.data.ClusterConfiguration}"
|
||||
```
|
||||
|
||||
<!--
|
||||
The following example will generate a kubeconfig file with credentials valid for 24 hours
|
||||
for a new user `johndoe` that is part of the `appdevs` group:
|
||||
-->
|
||||
以下示例将为在 `appdevs` 组的 `johndoe` 用户创建一个有效期为 24 小时的 kubeconfig 文件：
|
||||
|
||||
```shell
|
||||
kubeadm kubeconfig user --config example.yaml --org appdevs --client-name johndoe --validity-period 24h
|
||||
```
|
||||
|
||||
<!--
|
||||
The following example will generate a kubeconfig file with administrator credentials valid for 1 week:
|
||||
-->
|
||||
以下示例将为管理员创建一个有效期有一周的 kubeconfig 文件：
|
||||
|
||||
```shell
|
||||
kubeadm kubeconfig user --config example.yaml --client-name admin --validity-period 168h
|
||||
```
|
||||
@@ -0,0 +1,509 @@
|
||||
---
|
||||
title: 重新配置 kubeadm 集群
|
||||
content_type: task
|
||||
weight: 10
|
||||
---
|
||||
<!--
|
||||
reviewers:
|
||||
- sig-cluster-lifecycle
|
||||
title: Reconfiguring a kubeadm cluster
|
||||
content_type: task
|
||||
weight: 10
|
||||
-->
|
||||
|
||||
<!-- overview -->
|
||||
<!--
|
||||
kubeadm does not support automated ways of reconfiguring components that
|
||||
were deployed on managed nodes. One way of automating this would be
|
||||
by using a custom [operator](/docs/concepts/extend-kubernetes/operator/).
|
||||
-->
|
||||
kubeadm 不支持自动重新配置部署在托管节点上的组件的方式。
|
||||
一种自动化的方法是使用自定义的
|
||||
[operator](/zh/docs/concepts/extend-kubernetes/operator/)。
|
||||
|
||||
<!--
|
||||
To modify the components configuration you must manually edit associated cluster
|
||||
objects and files on disk.
|
||||
|
||||
This guide shows the correct sequence of steps that need to be performed
|
||||
to achieve kubeadm cluster reconfiguration.
|
||||
-->
|
||||
要修改组件配置，你必须手动编辑磁盘上关联的集群对象和文件。
|
||||
本指南展示了实现 kubeadm 集群重新配置所需执行的正确步骤顺序。
|
||||
|
||||
## {{% heading "prerequisites" %}}
|
||||
|
||||
<!--
|
||||
- You need a cluster that was deployed using kubeadm
|
||||
- Have administrator credentials (`/etc/kubernetes/admin.conf`) and network connectivity
|
||||
to a running kube-apiserver in the cluster from a host that has kubectl installed
|
||||
- Have a text editor installed on all hosts
|
||||
-->
|
||||
- 你需要一个使用 kubeadm 部署的集群
|
||||
- 拥有管理员凭据（`/etc/kubernetes/admin.conf`）
|
||||
和从安装了 kubectl 的主机到集群中正在运行的 kube-apiserver 的网络连接
|
||||
- 在所有主机上安装文本编辑器
|
||||
|
||||
<!-- steps -->
|
||||
|
||||
<!--
|
||||
## Reconfiguring the cluster
|
||||
kubeadm writes a set of cluster wide component configuration options in
|
||||
ConfigMaps and other objects. These objects must be manually edited. The command `kubectl edit`
|
||||
can be used for that.
|
||||
-->
|
||||
## 重新配置集群
|
||||
|
||||
kubeadm 在 ConfigMap 和其他对象中写入了一组集群范围的组件配置选项。
|
||||
这些对象必须手动编辑，可以使用命令 `kubectl edit`。
|
||||
|
||||
<!--
|
||||
The `kubectl edit` command will open a text editor where you can edit and save the object directly.
|
||||
|
||||
You can use the environment variables `KUBECONFIG` and `KUBE_EDITOR` to specify the location of
|
||||
the kubectl consumed kubeconfig file and preferred text editor.
|
||||
|
||||
For example:
|
||||
-->
|
||||
`kubectl edit` 命令将打开一个文本编辑器，你可以在其中直接编辑和保存对象。
|
||||
你可以使用环境变量 `KUBECONFIG` 和 `KUBE_EDITOR` 来指定 kubectl
|
||||
使用的 kubeconfig 文件和首选文本编辑器的位置。
|
||||
|
||||
例如：
|
||||
```
|
||||
KUBECONFIG=/etc/kubernetes/admin.conf KUBE_EDITOR=nano kubectl edit <parameters>
|
||||
```
|
||||
|
||||
{{< note >}}
|
||||
<!--
|
||||
Upon saving any changes to these cluster objects, components running on nodes may not be
|
||||
automatically updated. The steps below instruct you on how to perform that manually.
|
||||
-->
|
||||
保存对这些集群对象的任何更改后，节点上运行的组件可能不会自动更新。
|
||||
以下步骤将指导你如何手动执行该操作。
|
||||
{{< /note >}}
|
||||
|
||||
{{< warning >}}
|
||||
<!--
|
||||
Component configuration in ConfigMaps is stored as unstructured data (YAML string).
|
||||
This means that validation will not be performed upon updating the contents of a ConfigMap.
|
||||
You have to be careful to follow the documented API format for a particular
|
||||
component configuration and avoid introducing typos and YAML indentation mistakes.
|
||||
-->
|
||||
|
||||
ConfigMaps 中的组件配置存储为非结构化数据（YAML 字符串）。 这意味着在更新
|
||||
ConfigMap 的内容时不会执行验证。 你必须小心遵循特定组件配置的文档化 API 格式，
|
||||
并避免引入拼写错误和 YAML 缩进错误。
|
||||
{{< /warning >}}
|
||||
|
||||
<!--
|
||||
### Applying cluster configuration changes
|
||||
|
||||
#### Updating the `ClusterConfiguration`
|
||||
|
||||
During cluster creation and upgrade, kubeadm writes its
|
||||
[`ClusterConfiguration`](/docs/reference/config-api/kubeadm-config.v1beta3/)
|
||||
in a ConfigMap called `kubeadm-config` in the `kube-system` namespace.
|
||||
|
||||
To change a particular option in the `ClusterConfiguration` you can edit the ConfigMap with this command:
|
||||
|
||||
The configuration is located under the `data.ClusterConfiguration` key.
|
||||
-->
|
||||
### 应用集群配置更改
|
||||
|
||||
#### 更新 `ClusterConfiguration`
|
||||
|
||||
在集群创建和升级期间，kubeadm 将其
|
||||
[`ClusterConfiguration`](/zh/docs/reference/config-api/kubeadm-config.v1beta3/)
|
||||
写入 `kube-system` 命名空间中名为 `kubeadm-config` 的 ConfigMap。
|
||||
|
||||
要更改 `ClusterConfiguration` 中的特定选项，你可以使用以下命令编辑 ConfigMap：
|
||||
|
||||
```shell
|
||||
kubectl edit cm -n kube-system kubeadm-config
|
||||
```
|
||||
|
||||
配置位于 `data.ClusterConfiguration` 键下。
|
||||
|
||||
{{< note >}}
|
||||
<!--
|
||||
The `ClusterConfiguration` includes a variety of options that affect the configuration of individual
|
||||
components such as kube-apiserver, kube-scheduler, kube-controller-manager, CoreDNS, etcd and kube-proxy.
|
||||
Changes to the configuration must be reflected on node components manually.
|
||||
-->
|
||||
`ClusterConfiguration` 包括各种影响单个组件配置的选项， 例如
|
||||
kube-apiserver、kube-scheduler、kube-controller-manager、
|
||||
CoreDNS、etcd 和 kube-proxy。 对配置的更改必须手动反映在节点组件上。
|
||||
{{< /note >}}
|
||||
|
||||
<!--
|
||||
#### Reflecting `ClusterConfiguration` changes on control plane nodes
|
||||
|
||||
kubeadm manages the control plane components as static Pod manifests located in
|
||||
the directory `/etc/kubernetes/manifests`.
|
||||
Any changes to the `ClusterConfiguration` under the `apiServer`, `controllerManager`, `scheduler` or `etcd`
|
||||
keys must be reflected in the associated files in the manifests directory on a control plane node.
|
||||
-->
|
||||
#### 在控制平面节点上反映 `ClusterConfiguration` 更改
|
||||
|
||||
kubeadm 将控制平面组件作为位于 `/etc/kubernetes/manifests`
|
||||
目录中的静态 Pod 清单进行管理。
|
||||
对 `apiServer`、`controllerManager`、`scheduler` 或 `etcd`键下的
|
||||
`ClusterConfiguration` 的任何更改都必须反映在控制平面节点上清单目录中的关联文件中。
|
||||
|
||||
<!--
|
||||
Such changes may include:
|
||||
- `extraArgs` - requires updating the list of flags passed to a component container
|
||||
- `extraMounts` - requires updated the volume mounts for a component container
|
||||
- `*SANs` - requires writing new certificates with updated Subject Alternative Names.
|
||||
|
||||
Before proceeding with these changes, make sure you have backed up the directory `/etc/kubernetes/`.
|
||||
-->
|
||||
|
||||
此类更改可能包括:
|
||||
- `extraArgs` - 需要更新传递给组件容器的标志列表
|
||||
- `extraMounts` - 需要更新组件容器的卷挂载
|
||||
- `*SANs` - 需要使用更新的主题备用名称编写新证书
|
||||
|
||||
在继续进行这些更改之前，请确保你已备份目录 `/etc/kubernetes/`。
|
||||
|
||||
<!--
|
||||
To write new certificates you can use:
|
||||
|
||||
To write new manifest files in `/etc/kubernetes/manifests` you can use:
|
||||
-->
|
||||
|
||||
要编写新证书，你可以使用：
|
||||
|
||||
```shell
|
||||
kubeadm init phase certs <component-name> --config <config-file>
|
||||
```
|
||||
|
||||
要在 `/etc/kubernetes/manifests` 中编写新的清单文件，你可以使用：
|
||||
|
||||
```shell
|
||||
kubeadm init phase control-plane <component-name> --config <config-file>
|
||||
```
|
||||
|
||||
<!--
|
||||
The `<config-file>` contents must match the updated `ClusterConfiguration`.
|
||||
The `<component-name>` value must be the name of the component.
|
||||
-->
|
||||
`<config-file>` 内容必须与更新后的 `ClusterConfiguration` 匹配。
|
||||
`<component-name>` 值必须是组件的名称。
|
||||
|
||||
{{< note >}}
|
||||
<!--
|
||||
Updating a file in `/etc/kubernetes/manifests` will tell the kubelet to restart the static Pod for the corresponding component.
|
||||
Try doing these changes one node at a time to leave the cluster without downtime.
|
||||
-->
|
||||
更新 `/etc/kubernetes/manifests` 中的文件将告诉 kubelet 重新启动相应组件的静态 Pod。
|
||||
尝试一次对一个节点进行这些更改，以在不停机的情况下离开集群。
|
||||
{{< /note >}}
|
||||
|
||||
<!--
|
||||
### Applying kubelet configuration changes
|
||||
|
||||
#### Updating the `KubeletConfiguration`
|
||||
|
||||
During cluster creation and upgrade, kubeadm writes its
|
||||
[`KubeletConfiguration`](/docs/reference/config-api/kubelet-config.v1beta1/)
|
||||
in a ConfigMap called `kubelet-config` in the `kube-system` namespace.
|
||||
|
||||
You can edit the ConfigMap with this command:
|
||||
|
||||
The configuration is located under the `data.kubelet` key.
|
||||
-->
|
||||
### 应用 kubelet 配置更改
|
||||
|
||||
#### 更新 `KubeletConfiguration`
|
||||
|
||||
在集群创建和升级期间，kubeadm 将其
|
||||
[`KubeletConfiguration`](/zh/docs/reference/config-api/kubelet-config.v1beta1/)
|
||||
写入 `kube-system` 命名空间中名为 `kubelet-config` 的 ConfigMap。
|
||||
你可以使用以下命令编辑 ConfigMap：
|
||||
|
||||
```shell
|
||||
kubectl edit cm -n kube-system kubelet-config
|
||||
```
|
||||
|
||||
配置位于 `data.kubelet` 键下。
|
||||
|
||||
<!--
|
||||
#### Reflecting the kubelet changes
|
||||
|
||||
To reflect the change on kubeadm nodes you must do the following:
|
||||
- Log in to a kubeadm node
|
||||
- Run `kubeadm upgrade node phase kubelet-config` to download the latest `kubelet-config`
|
||||
ConfigMap contents into the local file `/var/lib/kubelet/config.conf`
|
||||
- Edit the file `/var/lib/kubelet/kubeadm-flags.env` to apply additional configuration with
|
||||
flags
|
||||
- Restart the kubelet service with `systemctl restart 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 服务
|
||||
|
||||
{{< note >}}
|
||||
<!--
|
||||
Do these changes one node at a time to allow workloads to be rescheduled properly.
|
||||
-->
|
||||
一次执行一个节点的这些更改，以允许正确地重新安排工作负载。
|
||||
{{< /note >}}
|
||||
|
||||
{{< note >}}
|
||||
<!--
|
||||
During `kubeadm upgrade`, kubeadm downloads the `KubeletConfiguration` from the
|
||||
`kubelet-config` ConfigMap and overwrite the contents of `/var/lib/kubelet/config.conf`.
|
||||
This means that node local configuration must be applied either by flags in
|
||||
`/var/lib/kubelet/kubeadm-flags.env` or by manually updating the contents of
|
||||
`/var/lib/kubelet/config.conf` after `kubeadm upgrade`, and then restarting the kubelet.
|
||||
-->
|
||||
在 `kubeadm upgrade` 期间，kubeadm 从 `kubelet-config` ConfigMap
|
||||
下载 `KubeletConfiguration` 并覆盖 `/var/lib/kubelet/config.conf` 的内容。
|
||||
这意味着节点本地配置必须通过`/var/lib/kubelet/kubeadm-flags.env`中的标志或在
|
||||
kubeadm upgrade` 后手动更新`/var/lib/kubelet/config.conf`的内容来应用，然后重新启动 kubelet。
|
||||
{{< /note >}}
|
||||
|
||||
<!--
|
||||
### Applying kube-proxy configuration changes
|
||||
|
||||
#### Updating the `KubeProxyConfiguration`
|
||||
|
||||
During cluster creation and upgrade, kubeadm writes its
|
||||
[`KubeProxyConfiguration`](/docs/reference/config-api/kube-proxy-config.v1alpha1/)
|
||||
in a ConfigMap in the `kube-system` namespace called `kube-proxy`.
|
||||
|
||||
This ConfigMap is used by the `kube-proxy` DaemonSet in the `kube-system` namespace.
|
||||
|
||||
To change a particular option in the `KubeProxyConfiguration`, you can edit the ConfigMap with this command:
|
||||
|
||||
The configuration is located under the `data.config.conf` key.
|
||||
-->
|
||||
### 应用 kube-proxy 配置更改
|
||||
|
||||
#### 更新 `KubeProxyConfiguration`
|
||||
|
||||
在集群创建和升级期间，kubeadm 将其写入
|
||||
[`KubeProxyConfiguration`](/zh/docs/reference/config-api/kube-proxy-config.v1alpha1/)
|
||||
在名为 `kube-proxy` 的 `kube-system` 命名空间中的 ConfigMap 中。
|
||||
|
||||
此 ConfigMap 由 `kube-system` 命名空间中的 `kube-proxy` DaemonSet 使用。
|
||||
|
||||
要更改 `KubeProxyConfiguration` 中的特定选项，你可以使用以下命令编辑 ConfigMap：
|
||||
|
||||
```shell
|
||||
kubectl edit cm -n kube-system kube-proxy
|
||||
```
|
||||
|
||||
配置位于 `data.config.conf` 键下。
|
||||
|
||||
<!--
|
||||
#### Reflecting the kube-proxy changes
|
||||
|
||||
Once the `kube-proxy` ConfigMap is updated, you can restart all kube-proxy Pods:
|
||||
|
||||
Obtain the Pod names:
|
||||
|
||||
Delete a Pod with:
|
||||
|
||||
New Pods that use the updated ConfigMap will be created.
|
||||
-->
|
||||
#### 反映 kube-proxy 的更改
|
||||
|
||||
更新 `kube-proxy` ConfigMap 后，你可以重新启动所有 kube-proxy Pod：
|
||||
|
||||
获取 Pod 名称：
|
||||
|
||||
```shell
|
||||
kubectl get po -n kube-system | grep kube-proxy
|
||||
```
|
||||
|
||||
使用以下命令删除 Pod：
|
||||
|
||||
```shell
|
||||
kubectl delete po -n kube-system <pod-name>
|
||||
```
|
||||
|
||||
将创建使用更新的 ConfigMap 的新 Pod。
|
||||
|
||||
{{< note >}}
|
||||
<!--
|
||||
Because kubeadm deploys kube-proxy as a DaemonSet, node specific configuration is unsupported.
|
||||
-->
|
||||
由于 kubeadm 将 kube-proxy 部署为 DaemonSet，因此不支持特定于节点的配置。
|
||||
{{< /note >}}
|
||||
|
||||
<!--
|
||||
### Applying CoreDNS configuration changes
|
||||
|
||||
#### Updating the CoreDNS Deployment and Service
|
||||
|
||||
kubeadm deploys CoreDNS as a Deployment called `coredns` and with a Service `kube-dns`,
|
||||
both in the `kube-system` namespace.
|
||||
|
||||
To update any of the CoreDNS settings, you can edit the Deployment and
|
||||
Service objects:
|
||||
-->
|
||||
### 应用 CoreDNS 配置更改
|
||||
|
||||
#### 更新 CoreDNS 的 Deployment 和 Service
|
||||
|
||||
kubeadm 将 CoreDNS 部署为名为 `coredns` 的 Deployment，并使用 Service `kube-dns`，
|
||||
两者都在 `kube-system` 命名空间中。
|
||||
|
||||
要更新任何 CoreDNS 设置，你可以编辑 Deployment 和 Service：
|
||||
|
||||
|
||||
```shell
|
||||
kubectl edit deployment -n kube-system coredns
|
||||
kubectl edit service -n kube-system kube-dns
|
||||
```
|
||||
|
||||
<!--
|
||||
#### Reflecting the CoreDNS changes
|
||||
|
||||
Once the CoreDNS changes are applied you can delete the CoreDNS Pods:
|
||||
|
||||
Obtain the Pod names:
|
||||
|
||||
Delete a Pod with:
|
||||
-->
|
||||
#### 反映 CoreDNS 的更改
|
||||
|
||||
应用 CoreDNS 更改后，你可以删除 CoreDNS Pod。
|
||||
|
||||
获取 Pod 名称：
|
||||
|
||||
```shell
|
||||
kubectl get po -n kube-system | grep coredns
|
||||
```
|
||||
|
||||
使用以下命令删除 Pod：
|
||||
|
||||
```shell
|
||||
kubectl delete po -n kube-system <pod-name>
|
||||
```
|
||||
|
||||
<!--
|
||||
New Pods with the updated CoreDNS configuration will be created.
|
||||
-->
|
||||
将创建具有更新的 CoreDNS 配置的新 Pod。
|
||||
|
||||
{{< note >}}
|
||||
<!--
|
||||
kubeadm does not allow CoreDNS configuration during cluster creation and upgrade.
|
||||
This means that if you execute `kubeadm upgrade apply`, your changes to the CoreDNS
|
||||
-->
|
||||
kubeadm 不允许在集群创建和升级期间配置 CoreDNS。
|
||||
这意味着如果执行了 `kubeadm upgrade apply`，你对
|
||||
CoreDNS 对象的更改将丢失并且必须重新应用。
|
||||
{{< /note >}}
|
||||
|
||||
<!--
|
||||
## Persisting the reconfiguration
|
||||
|
||||
During the execution of `kubeadm upgrade` on a managed node, kubeadm might overwrite configuration
|
||||
that was applied after the cluster was created (reconfiguration).
|
||||
-->
|
||||
## 持久化重新配置
|
||||
|
||||
在受管节点上执行 `kubeadm upgrade` 期间，kubeadm
|
||||
可能会覆盖在创建集群（重新配置）后应用的配置。
|
||||
|
||||
<!--
|
||||
### Persisting Node object reconfiguration
|
||||
|
||||
kubeadm writes Labels, Taints, CRI socket and other information on the Node object for a particular
|
||||
Kubernetes node. To change any of the contents of this Node object you can use:
|
||||
-->
|
||||
### 持久化 Node 对象重新配置
|
||||
|
||||
kubeadm 在特定 Kubernetes 节点的 Node 对象上写入标签、污点、CRI
|
||||
套接字和其他信息。要更改此 Node 对象的任何内容，你可以使用：
|
||||
|
||||
```shell
|
||||
kubectl edit no <node-name>
|
||||
```
|
||||
|
||||
<!--
|
||||
During `kubeadm upgrade` the contents of such a Node might get overwritten.
|
||||
If you would like to persist your modifications to the Node object after upgrade,
|
||||
you can prepare a [kubectl patch](/docs/tasks/manage-kubernetes-objects/update-api-object-kubectl-patch/)
|
||||
and apply it to the Node object:
|
||||
-->
|
||||
在 `kubeadm upgrade` 期间，此类节点的内容可能会被覆盖。
|
||||
如果你想在升级后保留对 Node 对象的修改，你可以准备一个
|
||||
[kubectl patch](/zh/docs/tasks/manage-kubernetes-objects/update-api-object-kubectl-patch/)
|
||||
并将其应用到 Node 对象：
|
||||
|
||||
```shell
|
||||
kubectl patch no <node-name> --patch-file <patch-file>
|
||||
```
|
||||
|
||||
<!--
|
||||
#### Persisting control plane component reconfiguration
|
||||
|
||||
The main source of control plane configuration is the `ClusterConfiguration`
|
||||
object stored in the cluster. To extend the static Pod manifests configuration,
|
||||
[patches](/docs/setup/production-environment/tools/kubeadm/control-plane-flags/#patches) can be used.
|
||||
|
||||
These patch files must remain as files on the control plane nodes to ensure that
|
||||
they can be used by the `kubeadm upgrade ... --patches <directory>`.
|
||||
|
||||
If reconfiguration is done to the `ClusterConfiguration` and static Pod manifests on disk,
|
||||
the set of node specific patches must be updated accordingly.
|
||||
-->
|
||||
#### 持久化控制平面组件重新配置
|
||||
|
||||
控制平面配置的主要来源是存储在集群中的 `ClusterConfiguration` 对象。
|
||||
要扩展静态 Pod 清单配置，可以使用
|
||||
[patches](/zh/docs/setup/production-environment/tools/kubeadm/control-plane-flags/#patches)。
|
||||
|
||||
这些补丁文件必须作为文件保留在控制平面节点上，以确保它们可以被
|
||||
`kubeadm upgrade ... --patches <directory>` 使用。
|
||||
|
||||
如果对 `ClusterConfiguration` 和磁盘上的静态 Pod 清单进行了重新配置，则必须相应地更新节点特定补丁集。
|
||||
|
||||
<!--
|
||||
#### Persisting kubelet reconfiguration
|
||||
|
||||
Any changes to the `KubeletConfiguration` stored in `/var/lib/kubelet/config.conf` will be overwritten on
|
||||
`kubeadm upgrade` by downloading the contents of the cluster wide `kubelet-config` ConfigMap.
|
||||
To persist kubelet node specific configuration either the file `/var/lib/kubelet/config.conf`
|
||||
has to be updated manually post-upgrade or the file `/var/lib/kubelet/kubeadm-flags.env` can include flags.
|
||||
The kubelet flags override the associated `KubeletConfiguration` options, but note that
|
||||
some of the flags are deprecated.
|
||||
|
||||
A kubelet restart will be required after changing `/var/lib/kubelet/config.conf` or
|
||||
`/var/lib/kubelet/kubeadm-flags.env`.
|
||||
-->
|
||||
#### 持久化 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。
|
||||
|
||||
{{% heading "whatsnext" %}}
|
||||
|
||||
<!--
|
||||
- [Upgrading kubeadm clusters](/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade)
|
||||
- [Customizing components with the kubeadm API](/docs/setup/production-environment/tools/kubeadm/control-plane-flags)
|
||||
- [Certificate management with kubeadm](/docs/tasks/administer-cluster/kubeadm/kubeadm-certs)
|
||||
-->
|
||||
|
||||
- [升级 kubeadm 集群](/zh/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade)
|
||||
- [使用 kubeadm API 自定义组件](/zh/docs/setup/production-environment/tools/kubeadm/control-plane-flags)
|
||||
- [使用 kubeadm 管理证书](/zh/docs/tasks/administer-cluster/kubeadm/kubeadm-certs)
|
||||
@@ -0,0 +1,646 @@
|
||||
---
|
||||
title: 升级 kubeadm 集群
|
||||
content_type: task
|
||||
weight: 20
|
||||
---
|
||||
<!--
|
||||
reviewers:
|
||||
- sig-cluster-lifecycle
|
||||
title: Upgrading kubeadm clusters
|
||||
content_type: task
|
||||
weight: 20
|
||||
-->
|
||||
|
||||
<!-- overview -->
|
||||
|
||||
<!--
|
||||
This page explains how to upgrade a Kubernetes cluster created with kubeadm from version
|
||||
{{< skew currentVersionAddMinor -1 >}}.x to version {{< skew currentVersion >}}.x, and from version
|
||||
{{< skew currentVersion >}}.x to {{< skew currentVersion >}}.y (where `y > x`). Skipping MINOR versions
|
||||
when upgrading is unsupported. For more details, please visit [Version Skew Policy](https://kubernetes.io/releases/version-skew-policy/).
|
||||
-->
|
||||
本页介绍如何将 `kubeadm` 创建的 Kubernetes 集群从 {{< skew currentVersionAddMinor -1 >}}.x 版本
|
||||
升级到 {{< skew currentVersion >}}.x 版本以及从 {{< skew currentVersion >}}.x
|
||||
升级到 {{< skew currentVersion >}}.y（其中 `y > x`）。略过次版本号的升级是
|
||||
不被支持的。更多详情请访问[版本倾斜政策](https://kubernetes.io/releases/version-skew-policy/)。
|
||||
|
||||
<!--
|
||||
To see information about upgrading clusters created using older versions of kubeadm,
|
||||
please refer to following pages instead:
|
||||
-->
|
||||
要查看 kubeadm 创建的有关旧版本集群升级的信息，请参考以下页面：
|
||||
|
||||
<!--
|
||||
- [Upgrading a kubeadm cluster from {{< skew currentVersionAddMinor -2 >}} to {{< skew currentVersionAddMinor -1 >}}](https://v{{< skew currentVersionAddMinor -1 "-" >}}.docs.kubernetes.io/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade/)
|
||||
- [Upgrading a kubeadm cluster from {{< skew currentVersionAddMinor -3 >}} to {{< skew currentVersionAddMinor -2 >}}](https://v{{< skew currentVersionAddMinor -2 "-" >}}.docs.kubernetes.io/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade/)
|
||||
- [Upgrading a kubeadm cluster from {{< skew currentVersionAddMinor -4 >}} to {{< skew currentVersionAddMinor -3 >}}](https://v{{< skew currentVersionAddMinor -3 "-" >}}.docs.kubernetes.io/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade/)
|
||||
- [Upgrading a kubeadm cluster from {{< skew currentVersionAddMinor -5 >}} to {{< skew currentVersionAddMinor -4 >}}](https://v{{< skew currentVersionAddMinor -4 "-" >}}.docs.kubernetes.io/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade/)
|
||||
-->
|
||||
- [将 kubeadm 集群从 {{< skew currentVersionAddMinor -2 >}} 升级到 {{< skew currentVersionAddMinor -1 >}}](https://v{{< skew currentVersionAddMinor -1 "-" >}}.docs.kubernetes.io/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade/)
|
||||
- [将 kubeadm 集群从 {{< skew currentVersionAddMinor -3 >}} 升级到 {{< skew currentVersionAddMinor -2 >}}](https://v{{< skew currentVersionAddMinor -2 "-" >}}.docs.kubernetes.io/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade/)
|
||||
- [将 kubeadm 集群从 {{< skew currentVersionAddMinor -4 >}} 升级到 {{< skew currentVersionAddMinor -3 >}}](https://v{{< skew currentVersionAddMinor -3 "-" >}}.docs.kubernetes.io/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade/)
|
||||
- [将 kubeadm 集群从 {{< skew currentVersionAddMinor -5 >}} 升级到 {{< skew currentVersionAddMinor -4 >}}](https://v{{< skew currentVersionAddMinor -4 "-" >}}.docs.kubernetes.io/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade/)
|
||||
|
||||
<!--
|
||||
The upgrade workflow at high level is the following:
|
||||
-->
|
||||
升级工作的基本流程如下：
|
||||
|
||||
<!--
|
||||
1. Upgrade a primary control plane node.
|
||||
1. Upgrade additional control plane nodes.
|
||||
1. Upgrade worker nodes.
|
||||
-->
|
||||
1. 升级主控制平面节点
|
||||
1. 升级其他控制平面节点
|
||||
1. 升级工作节点
|
||||
|
||||
## {{% heading "prerequisites" %}}
|
||||
|
||||
<!--
|
||||
- Make sure you read the [release notes](https://git.k8s.io/kubernetes/CHANGELOG) carefully.
|
||||
- The cluster should use a static control plane and etcd pods or external etcd.
|
||||
- Make sure to back up any important components, such as app-level state stored in a database.
|
||||
`kubeadm upgrade` does not touch your workloads, only components internal to Kubernetes, but backups are always a best practice.
|
||||
- [Swap must be disabled](https://serverfault.com/questions/684771/best-way-to-disable-swap-in-linux).
|
||||
-->
|
||||
- 务必仔细认真阅读[发行说明]({{< latest-release-notes >}})。
|
||||
- 集群应使用静态的控制平面和 etcd Pod 或者外部 etcd。
|
||||
- 务必备份所有重要组件，例如存储在数据库中应用层面的状态。
|
||||
`kubeadm upgrade` 不会影响你的工作负载，只会涉及 Kubernetes 内部的组件，但备份终究是好的。
|
||||
- [必须禁用交换分区](https://serverfault.com/questions/684771/best-way-to-disable-swap-in-linux)。
|
||||
|
||||
<!--
|
||||
### Additional information
|
||||
-->
|
||||
### 附加信息 {#additional-information}
|
||||
|
||||
<!--
|
||||
- The instructions below outline when to drain each node during the upgrade process.
|
||||
If you are performing a **minor** version upgrade for any kubelet, you **must**
|
||||
first drain the node (or nodes) that you are upgrading. In the case of control plane nodes,
|
||||
they could be running CoreDNS Pods or other critical workloads. For more information see
|
||||
[Draining nodes](/docs/tasks/administer-cluster/safely-drain-node/).
|
||||
- All containers are restarted after upgrade, because the container spec hash value is changed.
|
||||
-->
|
||||
- 下述说明了在升级过程中何时腾空每个节点。如果你正在对任何 kubelet 进行小版本升级，
|
||||
你需要先腾空待升级的节点（或多个节点）。对于控制面节点，其上可能运行着 CoreDNS Pods
|
||||
或者其它非常重要的负载。更多信息见[腾空节点](/zh/docs/tasks/administer-cluster/safely-drain-node/)。
|
||||
- 升级后，因为容器规约的哈希值已更改，所有容器都会被重新启动。
|
||||
|
||||
<!--
|
||||
- To verify that the kubelet service has successfully restarted after the kubelet has been upgraded,
|
||||
you can execute `systemctl status kubelet` or view the service logs with `journalctl -xeu kubelet`.
|
||||
- Usage of the `--config` flag of `kubeadm upgrade` with
|
||||
[kubeadm configuration API types](/docs/reference/config-api/kubeadm-config.v1beta3)
|
||||
with the purpose of reconfiguring the cluster is not recommended and can have unexpected results. Follow the steps in
|
||||
[Reconfiguring a kubeadm cluster](/docs/tasks/administer-cluster/kubeadm/kubeadm-reconfigure) instead.
|
||||
-->
|
||||
- 要验证 kubelet 服务在升级后是否成功重启，可以执行 `systemctl status kubelet`
|
||||
或 `journalctl -xeu kubelet` 查看服务日志。
|
||||
- 不建议使用 `kubeadm upgrade` 的 `--config` 参数和 [kubeadm 配置 API 类型](/zh/docs/reference/config-api/kubeadm-config.v1beta3)
|
||||
来重新配置集群，这样会产生意想不到的结果。请按照[重新配置 kubeadm 集群](/zh/docs/tasks/administer-cluster/kubeadm/kubeadm-reconfigure)
|
||||
中的步骤来进行。
|
||||
|
||||
<!-- steps -->
|
||||
|
||||
<!--
|
||||
## Determine which version to upgrade to
|
||||
-->
|
||||
## 确定要升级到哪个版本 {#determine-which-version-to-upgrade-to}
|
||||
|
||||
<!--
|
||||
Find the latest patch release for Kubernetes {{< skew currentVersion >}} using the OS package manager:
|
||||
-->
|
||||
使用操作系统的包管理器找到最新的补丁版本 Kubernetes {{< skew currentVersion >}}：
|
||||
|
||||
{{< tabs name="k8s_install_versions" >}}
|
||||
{{% tab name="Ubuntu、Debian 或 HypriotOS" %}}
|
||||
```shell
|
||||
apt update
|
||||
apt-cache madison kubeadm
|
||||
# 在列表中查找最新的 {{< skew currentVersion >}} 版本
|
||||
# 它看起来应该是 {{< skew currentVersion >}}.x-00，其中 x 是最新的补丁版本
|
||||
```
|
||||
{{% /tab %}}
|
||||
{{% tab name="CentOS、RHEL 或 Fedora" %}}
|
||||
```shell
|
||||
yum list --showduplicates kubeadm --disableexcludes=kubernetes
|
||||
# 在列表中查找最新的 {{< skew currentVersion >}} 版本
|
||||
# 它看起来应该是 {{< skew currentVersion >}}.x-0，其中 x 是最新的补丁版本
|
||||
```
|
||||
{{% /tab %}}
|
||||
{{< /tabs >}}
|
||||
|
||||
<!--
|
||||
## Upgrading control plane nodes
|
||||
-->
|
||||
## 升级控制平面节点 {#upgrading-control-plane-nodes}
|
||||
|
||||
<!--
|
||||
The upgrade procedure on control plane nodes should be executed one node at a time.
|
||||
Pick a control plane node that you wish to upgrade first. It must have the `/etc/kubernetes/admin.conf` file.
|
||||
-->
|
||||
控制面节点上的升级过程应该每次处理一个节点。
|
||||
首先选择一个要先行升级的控制面节点。该节点上必须拥有
|
||||
`/etc/kubernetes/admin.conf` 文件。
|
||||
|
||||
<!--
|
||||
### Call "kubeadm upgrade"
|
||||
-->
|
||||
### 执行 “kubeadm upgrade” {#call-kubeadm-upgrade}
|
||||
|
||||
<!--
|
||||
**For the first control plane node**
|
||||
-->
|
||||
**对于第一个控制面节点**
|
||||
|
||||
<!--
|
||||
- Upgrade kubeadm:
|
||||
-->
|
||||
- 升级 kubeadm：
|
||||
|
||||
{{< tabs name="k8s_install_kubeadm_first_cp" >}}
|
||||
{{% tab name="Ubuntu、Debian 或 HypriotOS" %}}
|
||||
```shell
|
||||
# 用最新的补丁版本号替换 {{< skew currentVersion >}}.x-00 中的 x
|
||||
apt-mark unhold kubeadm && \
|
||||
apt-get update && apt-get install -y kubeadm={{< skew currentVersion >}}.x-00 && \
|
||||
apt-mark hold kubeadm
|
||||
```
|
||||
{{% /tab %}}
|
||||
{{% tab name="CentOS、RHEL 或 Fedora" %}}
|
||||
```shell
|
||||
# 用最新的补丁版本号替换 {{< skew currentVersion >}}.x-0 中的 x
|
||||
yum install -y kubeadm-{{< skew currentVersion >}}.x-0 --disableexcludes=kubernetes
|
||||
```
|
||||
{{% /tab %}}
|
||||
{{< /tabs >}}
|
||||
<br />
|
||||
|
||||
<!--
|
||||
- Verify that the download works and has the expected version:
|
||||
-->
|
||||
- 验证下载操作正常，并且 kubeadm 版本正确：
|
||||
|
||||
```shell
|
||||
kubeadm version
|
||||
```
|
||||
|
||||
<!--
|
||||
- Verify the upgrade plan:
|
||||
-->
|
||||
- 验证升级计划：
|
||||
|
||||
```shell
|
||||
kubeadm upgrade plan
|
||||
```
|
||||
|
||||
<!--
|
||||
This command checks that your cluster can be upgraded, and fetches the versions you can upgrade to.
|
||||
It also shows a table with the component config version states.
|
||||
-->
|
||||
此命令检查你的集群是否可被升级，并取回你要升级的目标版本。
|
||||
命令也会显示一个包含组件配置版本状态的表格。
|
||||
|
||||
{{< note >}}
|
||||
<!--
|
||||
`kubeadm upgrade` also automatically renews the certificates that it manages on this node.
|
||||
To opt-out of certificate renewal the flag `--certificate-renewal=false` can be used.
|
||||
For more information see the [certificate management guide](/docs/tasks/administer-cluster/kubeadm/kubeadm-certs).
|
||||
-->
|
||||
`kubeadm upgrade` 也会自动对 kubeadm 在节点上所管理的证书执行续约操作。
|
||||
如果需要略过证书续约操作，可以使用标志 `--certificate-renewal=false`。
|
||||
更多的信息，可参阅[证书管理指南](/zh/docs/tasks/administer-cluster/kubeadm/kubeadm-certs)。
|
||||
{{</ note >}}
|
||||
|
||||
{{< note >}}
|
||||
<!--
|
||||
If `kubeadm upgrade plan` shows any component configs that require manual upgrade, users must provide
|
||||
a config file with replacement configs to `kubeadm upgrade apply` via the `--config` command line flag.
|
||||
Failing to do so will cause `kubeadm upgrade apply` to exit with an error and not perform an upgrade.
|
||||
-->
|
||||
如果 `kubeadm upgrade plan` 给出任何需要手动升级的组件配置，用户必须
|
||||
通过 `--config` 命令行标志向 `kubeadm upgrade apply` 命令提供替代的配置文件。
|
||||
如果不这样做，`kubeadm upgrade apply` 会出错并退出，不再执行升级操作。
|
||||
{{</ note >}}
|
||||
|
||||
<!--
|
||||
- Choose a version to upgrade to, and run the appropriate command. For example:
|
||||
-->
|
||||
- 选择要升级到的目标版本，运行合适的命令。例如：
|
||||
|
||||
<!--
|
||||
```shell
|
||||
# replace x with the patch version you picked for this upgrade
|
||||
sudo kubeadm upgrade apply v{{< skew currentVersion >}}.x
|
||||
```
|
||||
-->
|
||||
```shell
|
||||
# 将 x 替换为你为此次升级所选择的补丁版本号
|
||||
sudo kubeadm upgrade apply v{{< skew currentVersion >}}.x
|
||||
```
|
||||
|
||||
<!--
|
||||
Once the command finishes you should see:
|
||||
-->
|
||||
一旦该命令结束，你应该会看到：
|
||||
|
||||
```console
|
||||
[upgrade/successful] SUCCESS! Your cluster was upgraded to "v{{< skew currentVersion >}}.x". Enjoy!
|
||||
|
||||
[upgrade/kubelet] Now that your control plane is upgraded, please proceed with upgrading your kubelets if you haven't already done so.
|
||||
```
|
||||
|
||||
<!--
|
||||
- Manually upgrade your CNI provider plugin.
|
||||
-->
|
||||
- 手动升级你的 CNI 驱动插件。
|
||||
|
||||
<!--
|
||||
Your Container Network Interface (CNI) provider may have its own upgrade instructions to follow.
|
||||
Check the [addons](/docs/concepts/cluster-administration/addons/) page to
|
||||
find your CNI provider and see whether additional upgrade steps are required.
|
||||
-->
|
||||
你的容器网络接口（CNI）驱动应该提供了程序自身的升级说明。
|
||||
参阅[插件](/zh/docs/concepts/cluster-administration/addons/)页面查找你的 CNI 驱动，
|
||||
并查看是否需要其他升级步骤。
|
||||
|
||||
<!--
|
||||
This step is not required on additional control plane nodes if the CNI provider runs as a DaemonSet.
|
||||
-->
|
||||
如果 CNI 驱动作为 DaemonSet 运行，则在其他控制平面节点上不需要此步骤。
|
||||
|
||||
<!--
|
||||
**For the other control plane nodes**
|
||||
-->
|
||||
**对于其它控制面节点**
|
||||
|
||||
<!--
|
||||
Same as the first control plane node but use:
|
||||
-->
|
||||
与第一个控制面节点相同，但是使用：
|
||||
|
||||
```shell
|
||||
sudo kubeadm upgrade node
|
||||
```
|
||||
|
||||
<!--
|
||||
instead of:
|
||||
-->
|
||||
而不是：
|
||||
|
||||
```shell
|
||||
sudo kubeadm upgrade apply
|
||||
```
|
||||
|
||||
<!--
|
||||
Also calling `kubeadm upgrade plan` and upgrading the CNI provider plugin is no longer needed.
|
||||
-->
|
||||
此外，不需要执行 `kubeadm upgrade plan` 和更新 CNI 驱动插件的操作。
|
||||
|
||||
<!--
|
||||
### Drain the node
|
||||
-->
|
||||
### 腾空节点 {#drain-the-node}
|
||||
|
||||
<!--
|
||||
- Prepare the node for maintenance by marking it unschedulable and evicting the workloads:
|
||||
-->
|
||||
- 通过将节点标记为不可调度并腾空节点为节点作升级准备：
|
||||
|
||||
<!--
|
||||
```shell
|
||||
# replace <node-to-drain> with the name of your node you are draining
|
||||
kubectl drain <node-to-drain> --ignore-daemonsets
|
||||
```
|
||||
-->
|
||||
```shell
|
||||
# 将 <node-to-drain> 替换为你要腾空的控制面节点名称
|
||||
kubectl drain <node-to-drain> --ignore-daemonsets
|
||||
```
|
||||
|
||||
<!--
|
||||
### Upgrade kubelet and kubectl
|
||||
-->
|
||||
### 升级 kubelet 和 kubectl {#upgrade-kubelet-and-kubectl}
|
||||
|
||||
<!--
|
||||
- Upgrade the kubelet and kubectl:
|
||||
-->
|
||||
- 升级 kubelet 和 kubectl：
|
||||
|
||||
{{< tabs name="k8s_install_kubelet" >}}
|
||||
{{% tab name="Ubuntu、Debian 或 HypriotOS" %}}
|
||||
```shell
|
||||
# 用最新的补丁版本替换 {{< skew currentVersion >}}.x-00 中的 x
|
||||
apt-mark unhold kubelet kubectl && \
|
||||
apt-get update && apt-get install -y kubelet={{< skew currentVersion >}}.x-00 kubectl={{< skew currentVersion >}}.x-00 && \
|
||||
apt-mark hold kubelet kubectl
|
||||
```
|
||||
{{% /tab %}}
|
||||
{{% tab name="CentOS、RHEL 或 Fedora" %}}
|
||||
```shell
|
||||
# 用最新的补丁版本号替换 {{< skew currentVersion >}}.x-00 中的 x
|
||||
yum install -y kubelet-{{< skew currentVersion >}}.x-0 kubectl-{{< skew currentVersion >}}.x-0 --disableexcludes=kubernetes
|
||||
```
|
||||
{{% /tab %}}
|
||||
{{< /tabs >}}
|
||||
<br />
|
||||
|
||||
<!--
|
||||
- Restart the kubelet:
|
||||
-->
|
||||
- 重启 kubelet：
|
||||
|
||||
```shell
|
||||
sudo systemctl daemon-reload
|
||||
sudo systemctl restart kubelet
|
||||
```
|
||||
|
||||
<!--
|
||||
### Uncordon the node
|
||||
-->
|
||||
### 解除节点的保护 {#uncordon-the-node}
|
||||
|
||||
<!--
|
||||
- Bring the node back online by marking it schedulable:
|
||||
-->
|
||||
- 通过将节点标记为可调度，让其重新上线：
|
||||
|
||||
<!--
|
||||
```shell
|
||||
# replace <node-to-drain> with the name of your node
|
||||
kubectl uncordon <node-to-drain>
|
||||
```
|
||||
-->
|
||||
```shell
|
||||
# 将 <node-to-drain> 替换为你的节点名称
|
||||
kubectl uncordon <node-to-drain>
|
||||
```
|
||||
|
||||
<!--
|
||||
## Upgrade worker nodes
|
||||
-->
|
||||
## 升级工作节点 {#upgrade-worker-nodes}
|
||||
|
||||
<!--
|
||||
The upgrade procedure on worker nodes should be executed one node at a time or few nodes at a time,
|
||||
without compromising the minimum required capacity for running your workloads.
|
||||
-->
|
||||
工作节点上的升级过程应该一次执行一个节点，或者一次执行几个节点，
|
||||
以不影响运行工作负载所需的最小容量。
|
||||
|
||||
<!--
|
||||
### Upgrade kubeadm
|
||||
-->
|
||||
### 升级 kubeadm {#upgrade-kubeadm}
|
||||
|
||||
<!--
|
||||
- Upgrade kubeadm:
|
||||
-->
|
||||
- 升级 kubeadm：
|
||||
|
||||
{{< tabs name="k8s_install_kubeadm_worker_nodes" >}}
|
||||
{{% tab name="Ubuntu、Debian 或 HypriotOS" %}}
|
||||
```shell
|
||||
# 将 {{< skew currentVersion >}}.x-00 中的 x 替换为最新的补丁版本号
|
||||
apt-mark unhold kubeadm && \
|
||||
apt-get update && apt-get install -y kubeadm={{< skew currentVersion >}}.x-00 && \
|
||||
apt-mark hold kubeadm
|
||||
```
|
||||
{{% /tab %}}
|
||||
{{% tab name="CentOS、RHEL 或 Fedora" %}}
|
||||
```shell
|
||||
# 用最新的补丁版本替换 {{< skew currentVersion >}}.x-00 中的 x
|
||||
yum install -y kubeadm-{{< skew currentVersion >}}.x-0 --disableexcludes=kubernetes
|
||||
```
|
||||
{{% /tab %}}
|
||||
{{< /tabs >}}
|
||||
|
||||
<!--
|
||||
### Call "kubeadm upgrade"
|
||||
-->
|
||||
### 执行 "kubeadm upgrade" {#call-kubeadm-upgrade-1}
|
||||
|
||||
<!--
|
||||
- For worker nodes this upgrades the local kubelet configuration:
|
||||
-->
|
||||
- 对于工作节点，下面的命令会升级本地的 kubelet 配置：
|
||||
|
||||
```shell
|
||||
sudo kubeadm upgrade node
|
||||
```
|
||||
|
||||
<!--
|
||||
### Drain the node
|
||||
-->
|
||||
### 腾空节点 {#drain-the-node-1}
|
||||
|
||||
<!--
|
||||
- Prepare the node for maintenance by marking it unschedulable and evicting the workloads:
|
||||
-->
|
||||
- 将节点标记为不可调度并驱逐所有负载，准备节点的维护：
|
||||
|
||||
<!--
|
||||
```shell
|
||||
# replace <node-to-drain> with the name of your node you are draining
|
||||
kubectl drain <node-to-drain> --ignore-daemonsets
|
||||
```
|
||||
-->
|
||||
```shell
|
||||
# 将 <node-to-drain> 替换为你正在腾空的节点的名称
|
||||
kubectl drain <node-to-drain> --ignore-daemonsets
|
||||
```
|
||||
|
||||
<!--
|
||||
### Upgrade kubelet and kubectl
|
||||
-->
|
||||
### 升级 kubelet 和 kubectl {#upgrade-kubelet-and-kubectl-1}
|
||||
|
||||
<!--
|
||||
- Upgrade the kubelet and kubectl:
|
||||
-->
|
||||
- 升级 kubelet 和 kubectl：
|
||||
|
||||
{{< tabs name="k8s_kubelet_and_kubectl" >}}
|
||||
{{% tab name="Ubuntu、Debian 或 HypriotOS" %}}
|
||||
|
||||
```shell
|
||||
# 将 {{< skew currentVersion >}}.x-00 中的 x 替换为最新的补丁版本
|
||||
apt-mark unhold kubelet kubectl && \
|
||||
apt-get update && apt-get install -y kubelet={{< skew currentVersion >}}.x-00 kubectl={{< skew currentVersion >}}.x-00 && \
|
||||
apt-mark hold kubelet kubectl
|
||||
```
|
||||
|
||||
{{% /tab %}}
|
||||
{{% tab name="CentOS, RHEL or Fedora" %}}
|
||||
|
||||
```shell
|
||||
# 将 {{< skew currentVersion >}}.x-0 x 替换为最新的补丁版本
|
||||
yum install -y kubelet-{{< skew currentVersion >}}.x-0 kubectl-{{< skew currentVersion >}}.x-0 --disableexcludes=kubernetes
|
||||
```
|
||||
|
||||
{{% /tab %}}
|
||||
{{< /tabs >}}
|
||||
<br />
|
||||
|
||||
<!--
|
||||
- Restart the kubelet:
|
||||
-->
|
||||
- 重启 kubelet：
|
||||
|
||||
```shell
|
||||
sudo systemctl daemon-reload
|
||||
sudo systemctl restart kubelet
|
||||
```
|
||||
|
||||
<!--
|
||||
### Uncordon the node
|
||||
-->
|
||||
### 取消对节点的保护 {#uncordon-the-node-1}
|
||||
|
||||
<!--
|
||||
- Bring the node back online by marking it schedulable:
|
||||
-->
|
||||
- 通过将节点标记为可调度，让节点重新上线:
|
||||
|
||||
<!--
|
||||
```shell
|
||||
# replace <node-to-drain> with the name of your node
|
||||
kubectl uncordon <node-to-drain>
|
||||
```
|
||||
-->
|
||||
```shell
|
||||
# 将 <node-to-drain> 替换为当前节点的名称
|
||||
kubectl uncordon <node-to-drain>
|
||||
```
|
||||
|
||||
<!--
|
||||
## Verify the status of the cluster
|
||||
-->
|
||||
## 验证集群的状态 {#verify-the-status-of-the-cluster}
|
||||
|
||||
<!--
|
||||
After the kubelet is upgraded on all nodes verify that all nodes are available again by running
|
||||
the following command from anywhere kubectl can access the cluster:
|
||||
-->
|
||||
在所有节点上升级 kubelet 后，通过从 kubectl 可以访问集群的任何位置运行以下命令，
|
||||
验证所有节点是否再次可用：
|
||||
|
||||
```shell
|
||||
kubectl get nodes
|
||||
```
|
||||
|
||||
<!--
|
||||
The `STATUS` column should show `Ready` for all your nodes, and the version number should be updated.
|
||||
-->
|
||||
`STATUS` 应显示所有节点为 `Ready` 状态，并且版本号已经被更新。
|
||||
|
||||
<!--
|
||||
## Recovering from a failure state
|
||||
-->
|
||||
## 从故障状态恢复 {#recovering-from-a-failure-state}
|
||||
|
||||
<!--
|
||||
If `kubeadm upgrade` fails and does not roll back, for example because of an unexpected shutdown during execution, you can run `kubeadm upgrade` again.
|
||||
This command is idempotent and eventually makes sure that the actual state is the desired state you declare.
|
||||
-->
|
||||
如果 `kubeadm upgrade` 失败并且没有回滚，例如由于执行期间节点意外关闭，
|
||||
你可以再次运行 `kubeadm upgrade`。
|
||||
此命令是幂等的，并最终确保实际状态是你声明的期望状态。
|
||||
|
||||
<!--
|
||||
To recover from a bad state, you can also run `kubeadm upgrade apply --force` without changing the version that your cluster is running.
|
||||
-->
|
||||
要从故障状态恢复，你还可以运行 `kubeadm upgrade apply --force` 而无需更改集群正在运行的版本。
|
||||
|
||||
<!--
|
||||
During upgrade kubeadm writes the following backup folders under `/etc/kubernetes/tmp`:
|
||||
-->
|
||||
在升级期间，kubeadm 向 `/etc/kubernetes/tmp` 目录下的如下备份文件夹写入数据：
|
||||
|
||||
- `kubeadm-backup-etcd-<date>-<time>`
|
||||
- `kubeadm-backup-manifests-<date>-<time>`
|
||||
|
||||
<!--
|
||||
`kubeadm-backup-etcd` contains a backup of the local etcd member data for this control plane Node.
|
||||
In case of an etcd upgrade failure and if the automatic rollback does not work, the contents of this folder
|
||||
can be manually restored in `/var/lib/etcd`. In case external etcd is used this backup folder will be empty.
|
||||
-->
|
||||
`kubeadm-backup-etcd` 包含当前控制面节点本地 etcd 成员数据的备份。
|
||||
如果 etcd 升级失败并且自动回滚也无法修复，则可以将此文件夹中的内容复制到
|
||||
`/var/lib/etcd` 进行手工修复。如果使用的是外部的 etcd，则此备份文件夹为空。
|
||||
|
||||
<!--
|
||||
`kubeadm-backup-manifests` contains a backup of the static Pod manifest files for this control plane Node.
|
||||
In case of a upgrade failure and if the automatic rollback does not work, the contents of this folder can be
|
||||
manually restored in `/etc/kubernetes/manifests`. If for some reason there is no difference between a pre-upgrade
|
||||
and post-upgrade manifest file for a certain component, a backup file for it will not be written.
|
||||
-->
|
||||
`kubeadm-backup-manifests` 包含当前控制面节点的静态 Pod 清单文件的备份版本。
|
||||
如果升级失败并且无法自动回滚，则此文件夹中的内容可以复制到
|
||||
`/etc/kubernetes/manifests` 目录实现手工恢复。
|
||||
如果由于某些原因，在升级前后某个组件的清单未发生变化，则 kubeadm 也不会为之
|
||||
生成备份版本。
|
||||
|
||||
<!--
|
||||
## How it works
|
||||
-->
|
||||
## 工作原理 {#how-it-works}
|
||||
|
||||
<!--
|
||||
`kubeadm upgrade apply` does the following:
|
||||
-->
|
||||
`kubeadm upgrade apply` 做了以下工作：
|
||||
|
||||
<!--
|
||||
- Checks that your cluster is in an upgradeable state:
|
||||
- The API server is reachable
|
||||
- All nodes are in the `Ready` state
|
||||
- The control plane is healthy
|
||||
- Enforces the version skew policies.
|
||||
- Makes sure the control plane images are available or available to pull to the machine.
|
||||
- Generates replacements and/or uses user supplied overwrites if component configs require version upgrades.
|
||||
- Upgrades the control plane components or rollbacks if any of them fails to come up.
|
||||
- Applies the new `CoreDNS` and `kube-proxy` manifests and makes sure that all necessary RBAC rules are created.
|
||||
- Creates new certificate and key files of the API server and backs up old files if they're about to expire in 180 days.
|
||||
-->
|
||||
- 检查你的集群是否处于可升级状态:
|
||||
- API 服务器是可访问的
|
||||
- 所有节点处于 `Ready` 状态
|
||||
- 控制面是健康的
|
||||
- 强制执行版本偏差策略。
|
||||
- 确保控制面的镜像是可用的或可拉取到服务器上。
|
||||
- 如果组件配置要求版本升级，则生成替代配置与/或使用用户提供的覆盖版本配置。
|
||||
- 升级控制面组件或回滚（如果其中任何一个组件无法启动）。
|
||||
- 应用新的 `CoreDNS` 和 `kube-proxy` 清单，并强制创建所有必需的 RBAC 规则。
|
||||
- 如果旧文件在 180 天后过期，将创建 API 服务器的新证书和密钥文件并备份旧文件。
|
||||
|
||||
<!--
|
||||
`kubeadm upgrade node` does the following on additional control plane nodes:
|
||||
-->
|
||||
`kubeadm upgrade node` 在其他控制平节点上执行以下操作：
|
||||
|
||||
<!--
|
||||
- Fetches the kubeadm `ClusterConfiguration` from the cluster.
|
||||
- Optionally backups the kube-apiserver certificate.
|
||||
- Upgrades the static Pod manifests for the control plane components.
|
||||
- Upgrades the kubelet configuration for this node.
|
||||
-->
|
||||
- 从集群中获取 kubeadm `ClusterConfiguration`。
|
||||
- （可选操作）备份 kube-apiserver 证书。
|
||||
- 升级控制平面组件的静态 Pod 清单。
|
||||
- 为本节点升级 kubelet 配置
|
||||
|
||||
<!--
|
||||
`kubeadm upgrade node` does the following on worker nodes:
|
||||
-->
|
||||
`kubeadm upgrade node` 在工作节点上完成以下工作：
|
||||
|
||||
<!--
|
||||
- Fetches the kubeadm `ClusterConfiguration` from the cluster.
|
||||
- Upgrades the kubelet configuration for this node.
|
||||
-->
|
||||
- 从集群取回 kubeadm `ClusterConfiguration`。
|
||||
- 为本节点升级 kubelet 配置。
|
||||
@@ -0,0 +1,173 @@
|
||||
---
|
||||
title: 升级 Windows 节点
|
||||
min-kubernetes-server-version: 1.17
|
||||
content_type: task
|
||||
weight: 40
|
||||
---
|
||||
<!--
|
||||
title: Upgrading Windows nodes
|
||||
min-kubernetes-server-version: 1.17
|
||||
content_type: task
|
||||
weight: 40
|
||||
-->
|
||||
|
||||
<!-- overview -->
|
||||
|
||||
{{< feature-state for_k8s_version="v1.18" state="beta" >}}
|
||||
|
||||
<!--
|
||||
This page explains how to upgrade a Windows node [created with kubeadm](/docs/tasks/administer-cluster/kubeadm/adding-windows-nodes).
|
||||
-->
|
||||
本页解释如何升级[用 kubeadm 创建的](/zh/docs/tasks/administer-cluster/kubeadm/adding-windows-nodes)
|
||||
Windows 节点。
|
||||
|
||||
## {{% heading "prerequisites" %}}
|
||||
|
||||
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
|
||||
|
||||
<!--
|
||||
* Familiarize yourself with [the process for upgrading the rest of your kubeadm
|
||||
cluster](/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade). You will want to
|
||||
upgrade the control plane nodes before upgrading your Windows nodes.
|
||||
-->
|
||||
* 熟悉[更新 kubeadm 集群中的其余组件](/zh/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade)。
|
||||
在升级你的 Windows 节点之前你会想要升级控制面节点。
|
||||
|
||||
<!-- steps -->
|
||||
<!--
|
||||
## Upgrading worker nodes
|
||||
|
||||
### Upgrade kubeadm
|
||||
-->
|
||||
## 升级工作节点 {#upgrading-worker-nodes}
|
||||
|
||||
### 升级 kubeadm {#upgrade-kubeadm}
|
||||
|
||||
<!--
|
||||
1. From the Windows node, upgrade kubeadm:
|
||||
|
||||
```powershell
|
||||
# replace {{< param "fullversion" >}} with your desired version
|
||||
curl.exe -Lo C:\k\kubeadm.exe https://dl.k8s.io/{{< param "fullversion" >}}/bin/windows/amd64/kubeadm.exe
|
||||
```
|
||||
-->
|
||||
1. 在 Windows 节点上升级 kubeadm：
|
||||
|
||||
```powershell
|
||||
# 将 {{< param "fullversion" >}} 替换为你希望的版本
|
||||
curl.exe -Lo C:\k\kubeadm.exe https://dl.k8s.io/{{< param "fullversion" >}}/bin/windows/amd64/kubeadm.exe
|
||||
```
|
||||
|
||||
<!--
|
||||
### Drain the node
|
||||
|
||||
1. From a machine with access to the Kubernetes API,
|
||||
prepare the node for maintenance by marking it unschedulable and evicting the workloads:
|
||||
|
||||
```shell
|
||||
# replace <node-to-drain> with the name of your node you are draining
|
||||
kubectl drain <node-to-drain> -ignore-daemonsets
|
||||
```
|
||||
|
||||
You should see output similar to this:
|
||||
|
||||
```
|
||||
node/ip-172-31-85-18 cordoned
|
||||
node/ip-172-31-85-18 drained
|
||||
```
|
||||
-->
|
||||
### 腾空节点 {#drain-the-node}
|
||||
|
||||
1. 在一个能访问到 Kubernetes API 的机器上，将 Windows 节点标记为不可调度并
|
||||
驱逐其上的所有负载，以便准备节点维护操作：
|
||||
|
||||
```shell
|
||||
# 将 <要腾空的节点> 替换为你要腾空的节点的名称
|
||||
kubectl drain <要腾空的节点> -ignore-daemonsets
|
||||
```
|
||||
|
||||
你应该会看到类似下面的输出：
|
||||
|
||||
```
|
||||
node/ip-172-31-85-18 cordoned
|
||||
node/ip-172-31-85-18 drained
|
||||
```
|
||||
|
||||
<!--
|
||||
### Upgrade the kubelet configuration
|
||||
|
||||
1. From the Windows node, call the following command to sync new kubelet configuration:
|
||||
|
||||
```powershell
|
||||
kubeadm upgrade node
|
||||
```
|
||||
-->
|
||||
### 升级 kubelet 配置 {#upgrade-the-kubelet-configuration}
|
||||
|
||||
1. 在 Windows 节点上，执行下面的命令来同步新的 kubelet 配置：
|
||||
|
||||
```powershell
|
||||
kubeadm upgrade node
|
||||
```
|
||||
|
||||
<!--
|
||||
### Upgrade kubelet
|
||||
|
||||
1. From the Windows node, upgrade and restart the kubelet:
|
||||
|
||||
```powershell
|
||||
stop-service kubelet
|
||||
curl.exe -Lo C:\k\kubelet.exe https://dl.k8s.io/{{< param "fullversion" >}}/bin/windows/amd64/kubelet.exe
|
||||
restart-service kubelet
|
||||
```
|
||||
-->
|
||||
### 升级 kubelet {#upgrade-kubelet}
|
||||
|
||||
1. 在 Windows 节点上升级并重启 kubelet：
|
||||
|
||||
```powershell
|
||||
stop-service kubelet
|
||||
curl.exe -Lo C:\k\kubelet.exe https://dl.k8s.io/{{< param "fullversion" >}}/bin/windows/amd64/kubelet.exe
|
||||
restart-service kubelet
|
||||
```
|
||||
|
||||
<!--
|
||||
### Uncordon the node
|
||||
|
||||
1. From a machine with access to the Kubernetes API,
|
||||
bring the node back online by marking it schedulable:
|
||||
|
||||
```shell
|
||||
# replace <node-to-drain> with the name of your node
|
||||
kubectl uncordon <node-to-drain>
|
||||
```
|
||||
-->
|
||||
### 对节点执行 uncordon 操作 {#uncordon-the-node}
|
||||
|
||||
1. 从一台能够访问到 Kubernetes API 的机器上，通过将节点标记为可调度，使之
|
||||
重新上线：
|
||||
|
||||
```shell
|
||||
# 将 <要腾空的节点> 替换为你的节点名称
|
||||
kubectl uncordon <要腾空的节点>
|
||||
```
|
||||
|
||||
<!--
|
||||
### Upgrade kube-proxy
|
||||
|
||||
1. From a machine with access to the Kubernetes API, run the following,
|
||||
again replacing {{< param "fullversion" >}} with your desired version:
|
||||
|
||||
```shell
|
||||
curl -L https://github.com/kubernetes-sigs/sig-windows-tools/releases/latest/download/kube-proxy.yml | sed 's/VERSION/{{< param "fullversion" >}}/g' | kubectl apply -f -
|
||||
```
|
||||
-->
|
||||
### 升级 kube-proxy {#upgrade-kube-proxy}
|
||||
|
||||
1. 在一台可访问 Kubernetes API 的机器上和，将 {{< param "fullversion" >}} 替换成你
|
||||
期望的版本后再次执行下面的命令：
|
||||
|
||||
```shell
|
||||
curl -L https://github.com/kubernetes-sigs/sig-windows-tools/releases/latest/download/kube-proxy.yml | sed 's/VERSION/{{< param "fullversion" >}}/g' | kubectl apply -f -
|
||||
```
|
||||
|
||||
Reference in New Issue
Block a user