mirror of
https://github.com/rancher/rancher-docs.git
synced 2026-09-24 20:18:18 +00:00
Update translations for v2.7
This commit is contained in:
@@ -22,13 +22,13 @@ title: 一般常见问题解答
|
||||
|
||||
**Rancher 是否支持 Windows?**
|
||||
|
||||
从 Rancher 2.3.0 开始,我们支持 Windows Server 1809 容器。有关如何使用 Windows Worker 节点设置集群的详细信息,请参阅[为 Windows 配置自定义集群](../pages-for-subheaders/use-windows-clusters.md)。
|
||||
Rancher 支持 Windows Server 1809 容器。有关如何使用 Windows Worker 节点设置集群的详细信息,请参阅[为 Windows 配置自定义集群](../pages-for-subheaders/use-windows-clusters.md)。
|
||||
|
||||
<br/>
|
||||
|
||||
**Rancher 是否支持 Istio?**
|
||||
|
||||
从 Rancher 2.3.0 开始,我们支持 [Istio.](../pages-for-subheaders/istio.md)
|
||||
Rancher 支持 [Istio](../pages-for-subheaders/istio.md)。
|
||||
|
||||
此外,Istio 是在我们的微型 PaaS “Rio” 中实现的,它可以运行在 Rancher 2.x 以及任何符合 CNCF 的 Kubernetes 集群上。详情请参阅[这里](https://rio.io/)。
|
||||
|
||||
|
||||
+1
-1
@@ -27,7 +27,7 @@ title: 卸载 Rancher
|
||||
|
||||
如果你[在 Kubernetes 集群上安装了 Rancher](../pages-for-subheaders/install-upgrade-on-a-kubernetes-cluster.md),你可以使用 [Rancher Cleanup](https://github.com/rancher/rancher-cleanup) 工具删除 Rancher。
|
||||
|
||||
从 Rancher 2.5.8 开始,在高可用性 (HA) 模式下卸载 Rancher 还将删除所有 `helm-operation-*` Pod 和以下应用程序:
|
||||
在高可用 (HA) 模式下卸载 Rancher 还将删除所有 `helm-operation-*` Pod 和以下应用程序:
|
||||
|
||||
- fleet
|
||||
- fleet-agent
|
||||
|
||||
-2
@@ -138,8 +138,6 @@ ingress-nginx-controller LoadBalancer 10.0.116.18 40.31.180.83 80:31229
|
||||
|
||||
安装 Rancher 时,使用上一步获取的 DNS 名称作为 Rancher Server 的 URL。它可以作为 Helm 选项传递进来。例如,如果 DNS 名称是 `rancher.my.org`,你需要使用 `--set hostname=rancher.my.org` 选项来运行 Helm 安装命令。
|
||||
|
||||
**_v2.6.7 新功能_**
|
||||
|
||||
在此设置之上安装 Rancher 时,你还需要将以下值传递到 Rancher Helm 安装命令,以设置与 Rancher 的 Ingress 资源一起使用的 Ingress Controller 的名称:
|
||||
|
||||
```
|
||||
|
||||
+1
-34
@@ -2,41 +2,10 @@
|
||||
title: 在 Amazon EKS 上安装 Rancher
|
||||
---
|
||||
|
||||
本文介绍了在 EKS 上安装 Rancher 的两种方法。
|
||||
|
||||
第一种方法是使用 CloudFormation 在 EKS 集群上部署 Rancher Server。该方法的指南是与 Amazon Web Services 合作创建的,旨在展示如何按照最佳实践部署 Rancher。
|
||||
|
||||
第二种方法是使用命令行工具安装带有 Ingress 的 EKS 集群。如果你想在 EKS 上使用 Rancher 时使用较少的资源,请使用此方法。
|
||||
本文介绍了如何在 Amazon EKS 集群上安装 Rancher。你也可以[通过 AWS Marketplace 安装 Rancher](../../quick-start-guides/deploy-rancher-manager/aws-marketplace.md)。
|
||||
|
||||
如果你已经有一个 EKS Kubernetes 集群,请直接跳转到[安装 Ingress](#5-安装-ingress)这个步骤。然后按照[此处](../../../pages-for-subheaders/install-upgrade-on-a-kubernetes-cluster.md#安装-rancher-helm-chart)的步骤安装 Rancher Helm Chart。
|
||||
|
||||
|
||||
## 使用 AWS 最佳实践的快速入门
|
||||
|
||||
Rancher 和 Amazon Web Services 合作编写了一份快速入门指南,用于按照 AWS 的最佳实践,在 EKS 集群上部署 Rancher。详情请参见[部署指南](https://aws-quickstart.github.io/quickstart-eks-rancher/)。
|
||||
|
||||
快速入门指南提供了在 EKS 上部署 Rancher 的三个选项:
|
||||
|
||||
- **将 Rancher 部署到新的 VPC 和新的 Amazon EKS 集群中**:该选项构建了一个由 VPC、子网、NAT 网关、安全组、堡垒主机、Amazon EKS 集群和其他基础设施组件组成的全新 AWS 环境。然后将 Rancher 部署到这个新的 EKS 集群中。
|
||||
- **将 Rancher 部署到现有 VPC 和新的 Amazon EKS 集群中**:此选项在现有 AWS 基础架构中配置 Rancher。
|
||||
- **将 Rancher 部署到现有的 VPC 和现有的 Amazon EKS 集群中**。此选项在现有 AWS 基础架构中配置 Rancher。
|
||||
|
||||
使用默认参数为新的 Virtual Private Cloud(VPC)和新的 Amazon EKS 集群按照此快速入门部署,会在 AWS Cloud 中构建以下 Rancher 环境:
|
||||
|
||||
- 跨越三个可用区的高可用架构。\*
|
||||
- 根据 AWS 最佳实践,配置有公共和私有子网的 VPC,为你提供 AWS 上你自己的虚拟网络。\*
|
||||
- 在公共子网中:
|
||||
- 管理网络地址转换(NAT)网关,以允许资源的出站互联网访问。\*
|
||||
- 自动扩缩组中的 Linux 堡垒主机,允许对公共和私有子网中的 Amazon Elastic Compute Cloud (Amazon EC2) 实例进行入站安全 Shell (SSH) 访问。\*
|
||||
- 私有子网中:
|
||||
- 自动扩缩组中的 Kubernetes 节点。\*
|
||||
- 网络负载均衡器(未显示),用于访问 Rancher 控制台。
|
||||
- 使用 AWS Systems Manager 自动化进行 Rancher 部署。
|
||||
- 用于 EKS 集群的 Amazon EKS 服务,它提供了 Kubernetes controlplane。\*
|
||||
- 用于访问 Rancher 部署的 Amazon Route 53 DNS 记录。
|
||||
|
||||
\* 将快速启动部署到现有 Amazon EKS 集群中的 CloudForm 模板会跳过标有星号(\*)的组件,并提示你查看现有 VPC 配置。
|
||||
|
||||
## 为 Rancher Server 创建 EKS 集群
|
||||
|
||||
在本节中,你将使用命令行工具安装一个带有 Ingress 的 EKS 集群。如果你想在 EKS 上使用 Rancher 时使用较少的资源,请使用此方法。
|
||||
@@ -173,8 +142,6 @@ ingress-nginx-controller LoadBalancer 10.100.90.18 a904a952c73bf4f668a17c4
|
||||
|
||||
安装 Rancher 时,使用上一步获取的 DNS 名称作为 Rancher Server 的 URL。它可以作为 Helm 选项传递进来。例如,如果 DNS 名称是 `rancher.my.org`,你需要使用 `--set hostname=rancher.my.org` 选项来运行 Helm 安装命令。
|
||||
|
||||
**_v2.6.7 新功能_**
|
||||
|
||||
在此设置之上安装 Rancher 时,你还需要将以下值传递到 Rancher Helm 安装命令,以设置与 Rancher 的 Ingress 资源一起使用的 Ingress Controller 的名称:
|
||||
|
||||
```
|
||||
|
||||
+19
@@ -127,6 +127,15 @@ hostname: rancher.my.org
|
||||
|
||||
:::
|
||||
|
||||
:::tip
|
||||
Deployment 的名称可能会有所不同。例如,如果你通过 AWS Marketplace 部署 Rancher,则 Deployment 的名称为“rancher-stable”。
|
||||
因此:
|
||||
```
|
||||
helm get values rancher-stable -n cattle-system
|
||||
|
||||
hostname: rancher.my.org
|
||||
```
|
||||
:::
|
||||
|
||||
如果要将 cert-manager 从 v1.5 或更早的版本升级到最新版本,请参阅 [cert-manager upgrade docs](../resources/upgrade-cert-manager.md#选项-c升级-15-及以下版本的-cert-manager) 了解如何在不卸载或重新安装 Rancher 的情况下升级 cert-manager。否则,请按照以下[ Rancher 升级步骤](#rancher-升级步骤)进行操作。
|
||||
|
||||
@@ -150,6 +159,16 @@ helm upgrade rancher rancher-<CHART_REPO>/rancher \
|
||||
|
||||
:::
|
||||
|
||||
:::tip
|
||||
如果你通过 AWS Marketplace 部署 Rancher,则 Deployment 的名称为“rancher-stable”。
|
||||
因此:
|
||||
```
|
||||
helm upgrade rancher-stable rancher-<CHART_REPO>/rancher \
|
||||
--namespace cattle-system \
|
||||
--set hostname=rancher.my.org
|
||||
```
|
||||
:::
|
||||
|
||||
另外,你也可以将当前的值导出到一个文件中,并在升级时引用该文件。例如,如果你只需要改变 Rancher 的版本:
|
||||
|
||||
1. 将当前值导出到文件:
|
||||
|
||||
-2
@@ -139,8 +139,6 @@ sudo systemctl restart docker
|
||||
|
||||
#### 离线代理
|
||||
|
||||
_v2.6.4 的新功能_
|
||||
|
||||
你现在可以在配置的离线集群中配置主机驱动集群,以使用代理进行出站连接。
|
||||
|
||||
除了为代理服务器设置默认规则外,你还需要额外添加如下所示的规则,以从代理的 Rancher 环境中配置主机驱动集群。
|
||||
|
||||
-1
@@ -260,7 +260,6 @@ cert-manager-webhook-787858fcdb-nlzsq 1/1 Running 0 2m
|
||||
## Cert-Manager API 变更和数据迁移
|
||||
|
||||
---
|
||||
_v2.6.4 的新功能_
|
||||
|
||||
Rancher 现在支持 cert-manager 1.6.2 和 1.7.1。推荐使用 v1.7.x,因为 v 1.6.x 将在 2022 年 3 月 30 日结束生命周期。详情请参见 [cert-manager 文档](../../../pages-for-subheaders/install-upgrade-on-a-kubernetes-cluster.md#4-安装-cert-manager)。有关将 cert-manager 从 1.5 升级到 1.6 的说明,请参见上游的 [cert-manager 文档](https://cert-manager.io/docs/installation/upgrading/upgrading-1.5-1.6/)。有关将 cert-manager 从 1.6 升级到 1.7 的说明,请参见上游的 [cert-manager 文档](https://cert-manager.io/docs/installation/upgrading/upgrading-1.6-1.7/)。
|
||||
|
||||
|
||||
+1
-1
@@ -92,7 +92,7 @@ RKE v1.1.0 改变了集群升级的方式。
|
||||
|
||||
:::note
|
||||
|
||||
从 Rancher v2.4.0 开始出现了一个[已知问题](https://github.com/rancher/rancher/issues/25478),即使 etcd 和 controlplane 正在被清空, Rancher UI 不会将它们的状态显示为已清空。
|
||||
目前存在一个[已知问题](https://github.com/rancher/rancher/issues/25478),即使 etcd 和 controlplane 正在被清空, Rancher UI 也不会将它们的状态显示为 drained。
|
||||
|
||||
:::
|
||||
|
||||
|
||||
+9
-20
@@ -29,7 +29,7 @@ title: Rancher Equinix Metal 快速入门
|
||||
|
||||
### 1. 配置 Equinix Metal 主机
|
||||
|
||||
开始部署 Equinix Metal 主机。你可以使用 Equinix Metal 控制台,API 或 CLI 来配置 Equinix Metal Server。如果你需要了解如何部署每种类型的 deployment,请参见 [Equinix Metal 部署](https://metal.equinix.com/developers/docs/deploy/on-demand/)。以下链接介绍 Equinix Metal Server 的类型以及价格。
|
||||
开始部署 Equinix Metal 主机。你可以使用 Equinix Metal 控制台,API 或 CLI 来配置 Equinix Metal Server。如果你需要了解每种 Deployment 类型的说明,请参见 [Equinix Metal 部署](https://metal.equinix.com/developers/docs/deploy/on-demand/)。以下链接介绍 Equinix Metal Server 的类型以及价格:
|
||||
- [Equinix Metal Server 类型](https://metal.equinix.com/developers/docs/servers/about/)
|
||||
- [Equinix Metal 价格](https://metal.equinix.com/developers/docs/servers/server-specs/)
|
||||
|
||||
@@ -77,25 +77,14 @@ title: Rancher Equinix Metal 快速入门
|
||||
|
||||
1. 点击 **☰ > 集群管理**。
|
||||
1. 在**集群**页面,点击**创建**。
|
||||
2. 选择**自定义**。
|
||||
|
||||
3. 输入**集群名称**。
|
||||
|
||||
4. 跳过**成员角色**和**集群选项**。此部分我们稍后会详细介绍。
|
||||
|
||||
5. 点击**下一步**。
|
||||
|
||||
6. 在**节点角色**中,选择 _全部_ 角色,即 **etcd**,**Control** 和 **Worker**。
|
||||
|
||||
7. **可选**:Rancher 会自动检测用于 Rancher 通信和集群通信的 IP 地址。你可以使用**节点地址**处的`公有地址`和`内网地址`进行覆盖。
|
||||
|
||||
8. 跳过**标签**部分的内容。这部分内容暂时不重要。
|
||||
|
||||
9. 将屏幕上显示的命令复制到剪贴板。
|
||||
|
||||
10. 使用你惯用的 shell(例如 PuTTy 或远程终端)登录到你的 Linux 主机。粘贴剪贴板的命令并运行。
|
||||
|
||||
11. 在 Linux 主机上运行完命令后,单击**完成**。
|
||||
1. 选择**自定义**。
|
||||
1. 输入**集群名称**。
|
||||
1. 点击**下一步**。
|
||||
1. 在**节点角色**中,选择 _全部_ 角色,即 **etcd**,**Control** 和 **Worker**。
|
||||
- **可选**:Rancher 会自动检测用于 Rancher 通信和集群通信的 IP 地址。你可以使用**节点地址**处的`公有地址`和`内网地址`进行覆盖。
|
||||
1. 将注册命令复制到剪贴板。
|
||||
1. 使用你惯用的 shell(例如 PuTTy 或远程终端)登录到你的 Linux 主机。粘贴剪贴板的命令并运行。
|
||||
1. 在 Linux 主机上运行完命令后,单击**完成**。
|
||||
|
||||
**结果**:
|
||||
|
||||
|
||||
+1
-1
@@ -208,7 +208,7 @@ docker run -d --restart=unless-stopped \
|
||||
rancher/rancher:latest
|
||||
```
|
||||
|
||||
Rancher 2.5 开始需要[特权访问](../../pages-for-subheaders/rancher-on-a-single-node-with-docker.md#rancher-特权访问)。
|
||||
此操作需要 [privileged 访问](../../pages-for-subheaders/rancher-on-a-single-node-with-docker.md#rancher-特权访问)。
|
||||
|
||||
这个 7 层 NGINX 配置已经在 NGINX 1.13(Mainline)和 1.14(Stable)版本上进行了测试。
|
||||
|
||||
|
||||
+1
-1
@@ -2,7 +2,7 @@
|
||||
title: 持续交付
|
||||
---
|
||||
|
||||
从 Rancher 2.5 开始,[Fleet](../../../how-to-guides/new-user-guides/deploy-apps-across-clusters/fleet.md) 已经预装在 Rancher 中,且从 Rancher 2.6 开始,Fleet 不能再完全禁用。但是,你可以使用 `continuous-delivery` 功能开关来禁用 GitOps 持续交付的 Fleet 功能。
|
||||
Rancher 中预装的 [Fleet](../../../how-to-guides/new-user-guides/deploy-apps-across-clusters/fleet.md) 无法完全禁用。但是,你可以使用 `continuous-delivery` 功能开关来禁用 GitOps 持续交付的 Fleet 功能。
|
||||
|
||||
如需启用或禁用此功能,请参见[启用实验功能主页](../../../pages-for-subheaders/enable-experimental-features.md)中的说明。
|
||||
|
||||
|
||||
-13
@@ -31,26 +31,13 @@ title: 定制品牌
|
||||
|
||||
### 固定横幅
|
||||
|
||||
<Tabs>
|
||||
<TabItem value="Rancher 版本低于 v2.6.4">
|
||||
|
||||
在页眉、页脚或两者中显示自定义固定横幅。
|
||||
|
||||
</TabItem>
|
||||
<TabItem value="Rancher v2.6.4+">
|
||||
|
||||
在页眉、页脚或两者中显示自定义固定横幅。
|
||||
|
||||
从 Rancher v2.6.4 开始,固定横幅的配置已从**公司品牌**选项卡移动到**横幅**选项卡。
|
||||
|
||||
要配置横幅:
|
||||
|
||||
1. 单击**☰ > 全局设置**。
|
||||
2. 点击**横幅**。
|
||||
|
||||
</TabItem>
|
||||
</Tabs>
|
||||
|
||||
## 自定义导航链接
|
||||
|
||||
在本节中,你将了解如何配置**集群仪表板**左侧导航栏中的链接。要访问集群仪表板:
|
||||
|
||||
+158
-10
@@ -4,7 +4,7 @@ title: 备份集群
|
||||
|
||||
在 Rancher UI 中,你可以轻松备份和恢复 [Rancher 启动的 Kubernetes 集群](../../../pages-for-subheaders/launch-kubernetes-with-rancher.md)的 etcd。
|
||||
|
||||
Rancher 建议为所有生产集群配置定期 `etcd` 快照。此外,你还可以轻松创建单次快照。
|
||||
Rancher 建议为所有生产集群配置定期 `etcd` 快照。此外,你还可以创建单次快照。
|
||||
|
||||
etcd 数据库的快照会保存在 [etcd 节点](#本地备份目标)或 [S3 兼容目标](#s3-备份目标)上。配置 S3 的好处是,如果所有 etcd 节点都丢失了,你的快照会保存到远端并能用于恢复集群。
|
||||
|
||||
@@ -12,6 +12,9 @@ etcd 数据库的快照会保存在 [etcd 节点](#本地备份目标)或 [S3
|
||||
|
||||
### 快照组件
|
||||
|
||||
<Tabs groupId="k8s-distro">
|
||||
<TabItem value="RKE">
|
||||
|
||||
Rancher 创建快照时,快照里包括三个组件:
|
||||
|
||||
- etcd 中的集群数据
|
||||
@@ -20,24 +23,57 @@ Rancher 创建快照时,快照里包括三个组件:
|
||||
|
||||
由于 Kubernetes 版本现在包含在快照中,因此你可以将集群恢复到原本的 Kubernetes 版本。
|
||||
|
||||
</TabItem>
|
||||
<TabItem value="RKE2/K3s">
|
||||
|
||||
Rancher 将快照创建任务委托给下游 Kubernetes 引擎。Kubernetes 引擎创建快照时包括了三个组件:
|
||||
|
||||
- etcd 中的集群数据
|
||||
- Kubernetes 版本
|
||||
- 集群配置
|
||||
|
||||
由于 Kubernetes 版本包含在快照中,因此你可以将集群还原到之前的 Kubernetes 版本,同时还原 etcd 快照。
|
||||
|
||||
</TabItem>
|
||||
</Tabs>
|
||||
|
||||
如果你需要使用快照恢复集群,快照的多个组件允许你选择:
|
||||
|
||||
- **仅恢复 etcd 内容**:类似于在 Rancher v2.4.0 之前版本中的使用快照恢复。
|
||||
- **恢复 etcd 和 Kubernetes 版本**:如果 Kubernetes 升级导致集群失败,并且你没有更改任何集群配置,则应使用此选项。
|
||||
- **恢复 etcd、Kubernetes 版本和集群配置**:如果你在升级时同时更改了 Kubernetes 版本和集群配置,则应使用此选项。
|
||||
|
||||
始终建议在升级之前创建一个快照。
|
||||
建议你在执行配置更改或升级之前创建新快照。
|
||||
|
||||
|
||||
### 从 etcd 节点生成快照
|
||||
|
||||
<Tabs groupId="k8s-distro">
|
||||
<TabItem value="RKE">
|
||||
|
||||
集群中的每个 etcd 节点都会检查 etcd 集群的健康状况。如果节点报告 etcd 集群是健康的,则会从中创建一个快照,并可选择上传到 S3。
|
||||
|
||||
快照存储在 `/opt/rke/etcd-snapshots` 中。如果该目录在节点上配置为共享挂载,它将被覆盖。由于所有 etcd 节点都会上传快照并保留最后一个,因此 S3 上始终会保留最后一个上传的节点的快照。
|
||||
|
||||
在存在多个 etcd 节点的情况下,任何快照都是在集群健康检查通过后创建的,因此这些快照可以认为是 etcd 集群中数据的有效快照。
|
||||
|
||||
</TabItem>
|
||||
<TabItem value="RKE2/K3s">
|
||||
|
||||
快照是默认启动的。
|
||||
|
||||
快照目录默认为 `/var/lib/rancher/<RUNTIME>/server/db/snapshots`,其中 `<RUNTIME>` 可以是 `rke2` 或 `k3s`。
|
||||
|
||||
在 RKE2 中,快照会存储在每个 etcd 节点上。如果你有多个 etcd 或 etcd + control plane 节点,你将拥有本地 etcd 快照的多个副本。
|
||||
|
||||
</TabItem>
|
||||
</Tabs>
|
||||
|
||||
### 快照命名规则
|
||||
|
||||
<Tabs groupId="k8s-distro">
|
||||
<TabItem value="RKE">
|
||||
|
||||
快照的名称是自动生成的。在使用 RKE CLI 创建一次性快照时,你可以使用 `--name` 选项来指定快照的名称。
|
||||
|
||||
Rancher 在创建 RKE 集群的快照时,快照名称是基于快照创建类型(手动快照或定期快照)和目标(快照是保存在本地还是上传到 S3)决定的。命名规则如下:
|
||||
@@ -54,8 +90,39 @@ Rancher 在创建 RKE 集群的快照时,快照名称是基于快照创建类
|
||||
- c-9dmxz-ms-t6bjb
|
||||
- c-9dmxz-rs-8gxc8
|
||||
|
||||
</TabItem>
|
||||
<TabItem value="RKE2/K3s">
|
||||
|
||||
快照的名称是自动生成的。使用 RKE2 或 K3s CLI 创建一次性快照时,`--name` 选项可用于覆盖快照的基本名称。
|
||||
|
||||
Rancher 在创建 RKE2 或 K3s 集群的快照时,快照名称是基于快照创建类型(手动快照或定期快照)和目标(快照是保存在本地还是上传到 S3)决定的。命名规则如下:
|
||||
|
||||
`<name>-<node>-<timestamp>`
|
||||
|
||||
`<name>`:`--name` 设置的基本名称,可以是以下之一:
|
||||
|
||||
- `etcd-snapshot`:位于定期快照前面
|
||||
- `on-demand`:位于手动按需快照之前
|
||||
|
||||
`<node>`:创建快照的节点的名称。
|
||||
|
||||
`<timestamp>`:快照创建日期的 unix 时间戳。
|
||||
|
||||
快照名称示例如下:
|
||||
|
||||
- `on-demand-my-super-rancher-k8s-node1-1652288934`
|
||||
- `on-demand-my-super-rancher-k8s-node2-1652288936`
|
||||
- `etcd-snapshot-my-super-rancher-k8s-node1-1652289945`
|
||||
- `etcd-snapshot-my-super-rancher-k8s-node2-1652289948`
|
||||
|
||||
</TabItem>
|
||||
</Tabs>
|
||||
|
||||
### 从快照恢复的工作原理
|
||||
|
||||
<Tabs groupId="k8s-distro">
|
||||
<TabItem value="RKE">
|
||||
|
||||
在恢复时会发生以下过程:
|
||||
|
||||
1. 如果配置了 S3,则从 S3 检索快照。
|
||||
@@ -64,8 +131,34 @@ Rancher 在创建 RKE 集群的快照时,快照名称是基于快照创建类
|
||||
4. 其他 etcd 节点会下载快照并验证校验和,以便都能使用相同的快照进行恢复。
|
||||
5. 集群已恢复,恢复后的操作将在集群中完成。
|
||||
|
||||
</TabItem>
|
||||
<TabItem value="RKE2/K3s">
|
||||
|
||||
在还原时,Rancher 会提供几组执行还原的计划。期间将包括以下阶段:
|
||||
|
||||
- Started
|
||||
- Shutdown
|
||||
- Restore
|
||||
- RestartCluster
|
||||
- Finished
|
||||
|
||||
如果 etcd 快照还原失败,阶段将设置为 `Failed`。
|
||||
|
||||
1. 收到 etcd 快照还原请求后,根据 `restoreRKEConfig` 协调集群配置和 Kubernetes 版本。
|
||||
1. 该阶段设置为 `Started`。
|
||||
1. 该阶段设置为 `Shutdown`,并使用运行 `killall.sh` 脚本的计划来关闭整个集群。一个新的初始节点会被选举出来。如果还原的快照是本地快照,则选择该快照所在的节点作为初始节点。如果使用 S3 还原快照,将使用现有的初始节点。
|
||||
1. 该阶段设置为 `Restore`,并且快照将还原到初始节点上。
|
||||
1. 该阶段设置为 `RestartCluster`,集群将重启并重新加入到具有新还原的快照信息的新初始节点。
|
||||
1. 该阶段设置为 `Finished`,集群被视为已成功还原。`cattle-cluster-agent` 将重新连接,集群将完成协调。
|
||||
|
||||
</TabItem>
|
||||
</Tabs>
|
||||
|
||||
## 配置定期快照
|
||||
|
||||
<Tabs groupId="k8s-distro">
|
||||
<TabItem value="RKE">
|
||||
|
||||
选择创建定期快照的频率以及要保留的快照数量。时间的单位是小时。用户可以使用时间戳快照进行时间点恢复。
|
||||
|
||||
默认情况下,[Rancher 启动的 Kubernetes 集群](../../../pages-for-subheaders/launch-kubernetes-with-rancher.md)会配置为创建定期快照(保存到本地磁盘)。为防止本地磁盘故障,建议使用 [S3 目标](#s3-备份目标)或复制磁盘上的路径。
|
||||
@@ -81,30 +174,89 @@ Rancher 在创建 RKE 集群的快照时,快照名称是基于快照创建类
|
||||
| 定期 etcd 快照的创建周期 | 定期快照之间的间隔(以小时为单位) | 12 小时 |
|
||||
| 定期 etcd 快照的保留数量 | 要保留的快照数量 | 6 |
|
||||
|
||||
</TabItem>
|
||||
<TabItem value="RKE2/K3s">
|
||||
|
||||
设置创建定期快照的方式以及要保留的快照数量。该计划采用传统的 Cron 格式。保留策略规定了在每个节点上要保留的匹配名称的快照数量。
|
||||
|
||||
默认情况下,[Rancher 启动的 Kubernetes 集群](../../../pages-for-subheaders/launch-kubernetes-with-rancher.md)从凌晨 12 点开始每 5 小时创建一次定期快照(保存到本地磁盘)。为了防止本地磁盘故障,建议使用 [S3 目标](#s3-备份目标)或复制磁盘上的路径。
|
||||
|
||||
在集群配置或编辑集群期间,你可以在**集群配置**下找到快照配置。单击 **etcd**。
|
||||
|
||||
| 选项 | 描述 | 默认值 |
|
||||
| --- | ---| --- |
|
||||
| 启用定期 etcd 快照 | 启用/禁用定期快照 | 是 |
|
||||
| 定期 etcd 快照的创建周期 | 定期快照的 Cron 计划 | `0 */5 * * *` |
|
||||
| 定期 etcd 快照的保留数量 | 要保留的快照数量 | 5 |
|
||||
|
||||
</TabItem>
|
||||
</Tabs>
|
||||
|
||||
## 单次快照
|
||||
|
||||
<Tabs groupId="k8s-distro">
|
||||
<TabItem value="RKE">
|
||||
|
||||
除了定期快照之外,你可能还想创建“一次性”快照。例如,在升级集群的 Kubernetes 版本之前,最好备份集群的状态以防止升级失败。
|
||||
|
||||
1. 在左上角,单击 **☰ > 集群管理**。
|
||||
1. 在**集群**页面上,导航到要在其中创建一次性快照的集群。
|
||||
1. 单击 **⋮ > 拍摄快照**。
|
||||
|
||||
</TabItem>
|
||||
<TabItem value="RKE2/K3s">
|
||||
|
||||
除了定期快照之外,你可能还想创建“一次性”快照。例如,在升级集群的 Kubernetes 版本之前,最好备份集群的状态以防止升级失败。
|
||||
|
||||
1. 在左上角,单击 **☰ > 集群管理**。
|
||||
1. 在**集群**页面上,导航到要在其中创建一次性快照的集群。
|
||||
1. 导航至`快照`选项卡,然后单击`立即创建快照`
|
||||
|
||||
### 创建一次性快照的工作原理
|
||||
|
||||
在创建一次性快照时,Rancher 会传递几组计划来执行快照创建。期间将包括以下阶段:
|
||||
|
||||
- Started
|
||||
- RestartCluster
|
||||
- Finished
|
||||
|
||||
如果 etcd 快照创建失败,阶段将设置为 `Failed`。
|
||||
|
||||
1. 收到 etcd 快照创建请求。
|
||||
1. 该阶段设置为 `Started`。集群中的所有 etcd 节点都会根据集群配置收到创建 etcd 快照的计划。
|
||||
1. 该阶段设置为 `RestartCluster`,并且每个 etcd 节点上的计划都将重置为 etcd 节点的原始计划。
|
||||
1. 该阶段设置为 `Finished`。
|
||||
|
||||
</TabItem>
|
||||
</Tabs>
|
||||
|
||||
**结果**:根据你的[快照备份目标](#快照备份目标)创建一次性快照,并将其保存在选定的备份目标中。
|
||||
|
||||
## 快照备份目标
|
||||
|
||||
Rancher 支持两种不同的备份目标:
|
||||
|
||||
* [本地目标](#本地备份目标)
|
||||
* [S3 目标](#s3-备份目标)
|
||||
- [本地目标](#本地备份目标)
|
||||
- [S3 目标](#s3-备份目标)
|
||||
|
||||
### 本地备份目标
|
||||
|
||||
<Tabs groupId="k8s-distro">
|
||||
<TabItem value="RKE">
|
||||
|
||||
默认情况下会选择 `local` 备份目标。此选项的好处是不需要进行外部配置。快照会在本地自动保存到 [Rancher 启动的 Kubernetes 集群](../../../pages-for-subheaders/launch-kubernetes-with-rancher.md)中 etcd 节点的 `/opt/rke/etcd-snapshots` 中。所有定期快照都是按照配置的时间间隔创建的。使用 `local` 备份目标的缺点是,如果发生全面灾难并且丢失 _所有_ etcd 节点时,则无法恢复集群。
|
||||
|
||||
</TabItem>
|
||||
<TabItem value="RKE2/K3s">
|
||||
|
||||
默认情况下会选择 `local` 备份目标。此选项的好处是不需要进行外部配置。快照会自动保存到 [Rancher 启动的 Kubernetes 集群](../../../pages-for-subheaders/launch-kubernetes-with-rancher.md)中的本地 etcd 节点上的 `/var/lib/rancher/<runtime>/server/db/snapshots` 中,其中 `<runtime>` 可以是 `k3s` 或 `rke2`。所有定期快照均按照 Cron 计划进行。使用 `local` 备份目标的缺点是,如果发生全面灾难并且丢失 _所有_ etcd 节点时,则无法恢复集群。
|
||||
|
||||
</TabItem>
|
||||
</Tabs>
|
||||
|
||||
### S3 备份目标
|
||||
|
||||
`S3` 备份目标允许用户配置与 S3 兼容的后端来存储快照。此选项的主要好处是,如果集群丢失了所有 etcd 节点,由于快照存储在外部,集群仍然可以恢复。Rancher 推荐使用 `S3` 备份这类外部目标。但是它的配置要求进行额外的操作,这也应该被考虑在其中。
|
||||
`S3` 备份目标允许用户配置与 S3 兼容的后端来存储快照。此选项的主要好处是,如果集群丢失了所有 etcd 节点,由于快照存储在外部,集群仍然可以恢复。Rancher 推荐使用 `S3` 备份这类外部目标。但是它的配置要求进行额外的操作,这也应该被考虑在其中。由于 Rancher 会为群集配置的 S3 存储桶/文件夹中列出的任何可用快照填充快照信息,因此建议你确保每个集群都具有唯一的存储桶或文件夹。
|
||||
|
||||
| 选项 | 描述 | 必填 |
|
||||
|---|---|---|
|
||||
@@ -138,14 +290,10 @@ Rancher UI 中提供了集群所有可用快照的列表:
|
||||
1. 在**集群**页面中,转到要查看快照的集群并单击其名称。
|
||||
1. 单击**快照**选项卡来查看已保存快照的列表。这些快照包括创建时间的时间戳。
|
||||
|
||||
## 安全时间戳
|
||||
## 安全时间戳(RKE)
|
||||
|
||||
快照文件带有时间戳,从而简化使用外部工具和脚本处理文件的过程。但在某些与 S3 兼容的后端中,这些时间戳无法使用。
|
||||
|
||||
添加了选项 `safe_timestamp` 以支持兼容的文件名。当此标志设置为 `true` 时,快照文件名时间戳中的所有特殊字符都将被替换。
|
||||
|
||||
此选项不能直接在 UI 中使用,只能通过`以 YAML 文件编辑`使用。
|
||||
|
||||
## 为使用 Rancher v2.2.0 之前的版本创建的集群启用快照功能
|
||||
|
||||
如果你有使用 v2.2.0 之前版本创建的 Rancher 启动的 Kubernetes 集群,升级 Rancher 后,你必须[编辑集群](../../../pages-for-subheaders/cluster-configuration.md)并 _保存_ 它,以启用更新的快照功能。即使你已经在 v2.2.0 之前创建了快照,你也必须执行此步骤,因为旧的快照将无法用于[通过 UI 备份和恢复 etcd](restore-rancher-launched-kubernetes-clusters-from-backup.md)。
|
||||
|
||||
+129
@@ -0,0 +1,129 @@
|
||||
---
|
||||
title: 备份恢复使用指南
|
||||
---
|
||||
|
||||
Rancher Backups Chart 是我们的灾难恢复和迁移解决方案。此 Chart 用于备份 Kubernetes 资源并将其保存到各种持久存储位置。
|
||||
|
||||
这个 Chart 是一个非常简单的工具,适用于 Rancher 生态系统的许多不同领域。但是,也因此出现了未记录功能的边缘用例。本文档旨在强调 Rancher Backups 正确的用法,并讨论我们遇到的一些边缘情况。
|
||||
|
||||
## 功能概述
|
||||
|
||||
### 备份
|
||||
|
||||
该 Operator 将 Chart 中的 resourceSet 捕获的所有资源收集为内存中的非结构化对象。收集资源后,资源的 tar 包将保存为 JSON 格式的清单集合,然后上传到用户定义的对象存储。该备份可以按重复计划进行,也可以进行加密。由于某些资源是敏感的,并且值以未加密的明文形式存储,因此此加密选项很重要。
|
||||
|
||||
有关配置备份的选项(包括加密),请参阅[备份配置文档](../../../reference-guides/backup-restore-configuration/backup-configuration.md)。
|
||||
|
||||
:::note
|
||||
|
||||
如[备份 Rancher 文档](./back-up-rancher.md)所述,你必须手动保存加密配置文件的内容,因为 Operator **不会**备份它。
|
||||
|
||||
:::
|
||||
|
||||
### 还原
|
||||
|
||||
有两种主要的还原场景:还原正在运行 Rancher 的集群以及还原新集群。只有将备份还原到该备份的源集群,且在还原过程中启用了 [`prune` 选项](../../../reference-guides/backup-restore-configuration/restore-configuration.md#在还原期间修剪)时,你才能还原正在运行 Rancher 的集群。还原具有与备份类似的输入。它需要备份文件名、encryptionConfigSecret 名称和存储位置。
|
||||
|
||||
资源按以下顺序还原:
|
||||
|
||||
1. 自定义资源定义(CRD)
|
||||
2. 集群范围资源
|
||||
3. 命名空间资源
|
||||
|
||||
有关配置还原的选项,请参阅[还原配置文档](../../../reference-guides/backup-restore-configuration/restore-configuration.md)。
|
||||
|
||||
### 资源集
|
||||
|
||||
ResourceSet 确定了 backup-restore-operator 在备份中收集哪些资源。它是一组 ResourceSelector,使用键/值对匹配、正则表达式匹配或 Kubernetes 客户端 labelSelector 来定义选择要求。
|
||||
|
||||
以下是可用于 resourceSelector 的字段:
|
||||
|
||||
- apiVersion
|
||||
- excludeKinds
|
||||
- excludeResourceNameRegexp
|
||||
- kinds
|
||||
- kindsRegexp
|
||||
- labelSelectors
|
||||
- namespaceRegexp
|
||||
- namespaces
|
||||
- resourceNameRegexp
|
||||
- resourceNames
|
||||
|
||||
Rancher Backups Chart 包含了一个[默认 resourceSet](https://github.com/rancher/backup-restore-operator/tree/release/v3.0/charts/rancher-backup/files/default-resourceset-contents),它是安装 Chart 时附加到一个大型 resourceSet 的 YAML 文件组合。文件顺序并不重要。不同版本的 resourceSet 可能有所不同。
|
||||
|
||||
:::caution
|
||||
|
||||
如果你希望编辑 resourceSet,请在安装 Chart 之前进行**编辑**。
|
||||
|
||||
:::
|
||||
|
||||
## 正确使用
|
||||
|
||||
本节概述了如何根据用例正确使用 Rancher Backups Chart。
|
||||
|
||||
### 所有案例
|
||||
|
||||
- Rancher Backups 必须安装在 local 集群上。
|
||||
- 注意:Rancher Backups 只会处理安装了它的集群。它可能会还原 local 集群上的集群资源,但不会联系或备份下游集群。
|
||||
- 要还原的 Rancher 版本必须与备份中的 Rancher 版本匹配。
|
||||
- 由于你可能需要还原已过时的资源(要还原的 Kubernetes 版本已弃用的资源),因此你需要考虑 Kubernetes 版本。
|
||||
|
||||
### 备份
|
||||
|
||||
- 用户生成的某些资源不会被备份,除非这些资源可以被默认 resourceSet 捕获,或者 resourceSet 已被更改为捕获这些资源。
|
||||
- 我们提供了一个 `resources.cattle.io/backup:true` 标签,将该标签添加到任何命名空间中的 Secret 时,命名空间将被备份。
|
||||
- 备份是不可改变的
|
||||
- 仅备份 local 集群
|
||||
|
||||
### 还原
|
||||
|
||||
- 还原是指将备份还原到原来的集群。可以在安装了 Rancher 的情况下进行(**必须启用 prune**),也可以在未安装 Rancher 的情况下进行(无特殊说明)。
|
||||
- 还原时需要注意的一件事是,你可能需要“擦除”集群中的所有 Rancher 资源。你可以通过将 [Rancher cleanup script](https://github.com/rancher/rancher-cleanup) 脚本作为 job 部署到集群来完成这点。这样,你可以再次安装 Rancher Backups 并还原到全新的集群。
|
||||
- 确保使用了 kubectl 来部署脚本。
|
||||
|
||||
### 迁移
|
||||
|
||||
由于我们要还原到不同的集群,因此对应的迁移有一些细微差别。以下是需要记住但又容易被忘记的事情。
|
||||
|
||||
- 迁移时 Rancher 域必须相同。换言之,你旧集群的域名现在必须指向新集群。
|
||||
- Rancher **不应该**已运行在你要迁移到的集群,这可能会导致 Rancher 备份和某些 Rancher 服务出现许多问题。
|
||||
- **还原备份后**,安装与备份**相同**的 Rancher 版本。
|
||||
- 在其他 Kubernetes 版本上配置新集群可能会出现各种不受支持的情况,这是因为可用的 Kubernetes API 可能与你备份的 API 不同。这可能会导致已弃用的资源被恢复,从而导致问题。
|
||||
- 在迁移期间**不要**执行任何升级操作。
|
||||
|
||||
## 边缘案例和不当使用
|
||||
|
||||
以下是 Rancher Backups 的一些**不当**使用示例。
|
||||
|
||||
### 升级
|
||||
|
||||
- 使用 Rancher Backups 来升级 Rancher 版本不是一个有效用法。推荐的做法是:先备份当前版本,然后按照[说明](../../../getting-started/installation-and-upgrade/install-upgrade-on-a-kubernetes-cluster/upgrades)升级你的 Rancher 实例,在升级完成后再进行**另一个**备份。这样,如果升级失败,你就有一个可以用来还原的备份,而第二个备份将能用于还原到升级后的 Rancher 版本。
|
||||
- 使用 Rancher Backups 来升级 Kubernetes 版本也不是一个有效用法。由于 Kubernetes API 以及可用资源与版本相关,因此使用备份还原的方法来进行升级可能会导致资源集不对齐的问题,这些资源可能已被弃用、不受支持或已更新。升级集群版本的方式取决于其配置方式,但建议使用上述的流程(备份、升级、备份)。
|
||||
|
||||
### ResourceSet
|
||||
|
||||
- 由于不同团队的资源和服务会不断发展,开发人员应要注意是否需要向默认 resourceSet 添加或删除新资源。
|
||||
- Rancher Backups 仅备份默认 resourceSet 捕获的内容(除非进行编辑)。我们为用户创建的 Secret 添加了特定标签,无论 Secret 的名称是什么,无论它属于哪个命名空间,具有该标签 Secret 都会被备份(请参阅[备份的正确用法](#备份))。
|
||||
|
||||
### 下游集群
|
||||
|
||||
- Rancher Backups **仅**备份 local 集群上的 Kubernetes 资源。换言之,除了存在于 local 集群中的资源,下游集群**不会**被触及或备份。下游集群的更新和通信由 rancher-agent 和 rancher-webhook 负责。
|
||||
|
||||
### 还原已删除的资源
|
||||
|
||||
- 有些资源会产生外部结果,例如会配置下游集群。删除下游集群并还原 local 集群上的集群资源**不会**导致 Rancher 重新配置所述集群。某些资源可能无法通过还原回到可用状态。
|
||||
- “还原已删除的集群”**不是**受支持的功能。涉及下游集群时,无论集群是配置的还是导入的,删除集群都会执行一系列清理任务,导致我们无法还原已删除的集群。配置的集群节点以及与 Rancher 相关的配置资源将被销毁,而导入的集群的 Rancher Agent 以及与 local 集群注册相关的其他资源/服务可能会被销毁。
|
||||
|
||||
:::caution
|
||||
|
||||
尝试删除和还原下游集群可能会导致 Rancher、Rancher Backups、rancher-webhook、Fleet 等出现各种问题。因此,我们不建议你这样做。
|
||||
|
||||
:::
|
||||
|
||||
### Fleet、Harvester 和其他服务
|
||||
|
||||
由 Rancher Backups 支持的其他服务会经常发生变化和发展。发生这种情况时,他们的资源和备份需求也可能会发生变化。有些资源可能根本不需要备份。团队需要在开发过程中考虑这一点,并评估相关 resourceSet 是否能正确捕获正确的资源集来还原其服务。
|
||||
|
||||
## 结论
|
||||
|
||||
Rancher Backups 是一个非常有用的工具,但它的使用范围和使用目的有限的。为了避免出现问题,请遵循本文所述的流程来确保 Chart 能正确运作。
|
||||
+58
-6
@@ -37,12 +37,68 @@ Rancher UI 中提供了集群所有可用快照的列表:
|
||||
1. 在左上角,单击 **☰ > 集群管理**。
|
||||
1. 在**集群**页面中,转到要查看快照的集群并点击集群名称。
|
||||
1. 单击**快照**选项卡来查看已保存快照的列表。
|
||||
1. 转到要恢复的快照,然后单击 **⋮ > 还原快照**。
|
||||
1. 转到要恢复的快照,然后单击 **⋮ > 还原**。
|
||||
1. 选择一个**还原类型**。
|
||||
1. 点击**还原**。
|
||||
|
||||
**结果**:集群将进入 `updating` 状态,然后将开始使用快照恢复 `etcd` 节点。集群会在返回到 `active` 状态后被恢复。
|
||||
|
||||
## 在没有快照的情况下恢复 etcd
|
||||
## Control Plane/etcd 完全不可用时使用快照还原集群
|
||||
|
||||
在灾难恢复场景中,下游集群中 Rancher 管理的 Control Plane 和 etcd 节点可能不再可用或运行。你可以通过再次添加 Control Plane 和 etcd 节点来重建集群,然后使用可用快照来进行还原。
|
||||
|
||||
<Tabs groupId="k8s-distro">
|
||||
<TabItem value="RKE">
|
||||
|
||||
请按照 [SUSE 知识库](https://www.suse.com/support/kb/doc/?id=000020695)中描述的流程进行操作。
|
||||
|
||||
</TabItem>
|
||||
<TabItem value="RKE2/K3s">
|
||||
|
||||
如果集群完全故障,则必须从集群中删除所有 etcd 节点和机器,然后才能添加新的 etcd 节点来进行还原。
|
||||
|
||||
:::note
|
||||
|
||||
由于[已知问题](https://github.com/rancher/rancher/issues/41080),此过程需要 Rancher v2.7.5 或更高版本。
|
||||
|
||||
:::
|
||||
|
||||
:::note
|
||||
|
||||
如果你使用[本地快照](./back-up-rancher-launched-kubernetes-clusters.md#本地备份目标),那么请**务必**从要删除的 etcd 节点上的 `/var/lib/rancher/<k3s/rke2>/server/db/snapshots/` 文件夹中备份要还原的快照。你可以将快照复制到 `/var/lib/rancher/<k3s/rke2>/server/db/snapshots/` 文件夹中的新节点上。此外,如果使用本地快照并还原到新节点,目前还无法通过 UI 进行还原。
|
||||
|
||||
:::
|
||||
|
||||
1. 从集群中删除所有 etcd 节点。
|
||||
|
||||
1. 在左上角,单击 **☰ > 集群管理**。
|
||||
1. 在**集群**页面中,转到要删除节点的集群。
|
||||
1. 在**主机**选项卡中,找到要删除的每个节点并单击 **⋮ > 删除**。开始时,节点会挂在 `deleting` 状态,所有 etcd 节点都被删除后,它们将被一起删除。这是因为 Rancher 发现所有 etcd 节点都在删除,并开始 "短路" etcd 安全删除逻辑。
|
||||
|
||||
1. 删除所有 etcd 节点后,添加要用于还原的新 etcd 节点。
|
||||
|
||||
- 对于自定义集群,请转到**注册**选项卡,然后在节点上复制并运行注册命令。如果该节点之前已在集群中使用过,请先[清理该节点](../manage-clusters/clean-cluster-nodes.md#清理节点)。
|
||||
- 对于主机驱动集群,则会自动配置新节点。
|
||||
|
||||
此时,Rancher 会提示你需要使用 etcd 快照进行还原。
|
||||
|
||||
1. 使用 etcd 快照还原。
|
||||
|
||||
- 对于 S3 快照,使用 UI 进行还原。
|
||||
1. 单击**快照**选项卡来查看已保存快照的列表。
|
||||
1. 转到要恢复的快照,然后单击 **⋮ > 还原**。
|
||||
1. 选择一个**还原类型**。
|
||||
1. 点击**还原**。
|
||||
- 对于本地快照,使用 UI 进行还原**不**可用。
|
||||
1. 单击右上角的 **⋮> 编辑 YAML**。
|
||||
1. 将 `spec.cluster.rkeConfig.etcdSnapshotRestore.name` 定义为 `/var/lib/rancher/<k3s/rke2>/server/db/snapshots/` 中磁盘上快照的文件名。
|
||||
|
||||
1. 还原成功后,你可以将 etcd 节点扩展至所需的冗余。
|
||||
|
||||
</TabItem>
|
||||
</Tabs>
|
||||
|
||||
## 在没有快照的情况下恢复 etcd(RKE)
|
||||
|
||||
如果 etcd 节点组失去了仲裁(quorum),由于没有操作(例如部署工作负载)可以在 Kubernetes 集群中执行,Kubernetes 集群将报告失败。集群需要有三个 etcd 节点以防止仲裁丢失。如果你想恢复你的 etcd 节点集,请按照以下说明操作:
|
||||
|
||||
@@ -71,7 +127,3 @@ Rancher UI 中提供了集群所有可用快照的列表:
|
||||
5. 运行修改后的命令。
|
||||
|
||||
6. 在单个节点启动并运行后,Rancher 建议向你的集群添加额外的 etcd 节点。如果你有一个[自定义集群](../../../pages-for-subheaders/use-existing-nodes.md),并且想要复用旧节点,则需要先[清理节点](../manage-clusters/clean-cluster-nodes.md),然后再尝试将它们重新添加到集群中。
|
||||
|
||||
## 为使用 Rancher v2.2.0 之前的版本创建的集群启用快照功能
|
||||
|
||||
如果你有使用 v2.2.0 之前版本创建的 Rancher 启动的 Kubernetes 集群,升级 Rancher 后,你必须[编辑集群](../../../pages-for-subheaders/cluster-configuration.md)并 _保存_ 它,以启用更新的快照功能。即使你已经在 v2.2.0 之前创建了快照,你也必须执行此步骤,因为旧的快照将无法用于[通过 UI 备份和恢复 etcd](restore-rancher-launched-kubernetes-clusters-from-backup.md)。
|
||||
|
||||
-2
@@ -2,8 +2,6 @@
|
||||
title: 多集群应用
|
||||
---
|
||||
|
||||
> Rancher v2.5 开始已弃用多集群应用。我们现在建议使用 [Fleet](fleet.md) 来跨集群部署应用。
|
||||
|
||||
通常,大多数应用都部署在单个 Kubernetes 集群上,但有时你可能需要跨不同集群和/或项目部署同一应用的多个副本。在 Rancher 中,_多集群应用_ 指的是使用 Helm Chart 跨多个集群部署的应用。由于能够跨多个集群部署相同的应用,因此可以避免在每个集群上重复执行相同的应用配置操作而引入的人为错误。使用多集群应用,你可以通过自定义在所有项目/集群中使用相同的配置,并根据你的目标项目更改配置。由于多集群应用被视为单个应用,因此更容易管理和维护。
|
||||
|
||||
全局应用商店中的任何 Helm Chart 都可用于部署和管理多集群应用。
|
||||
|
||||
+4
-3
@@ -56,15 +56,16 @@ title: 配置 NGINX 负载均衡器
|
||||
proxy_pass rancher_servers_http;
|
||||
}
|
||||
|
||||
}
|
||||
|
||||
http {
|
||||
|
||||
upstream rancher_servers_https {
|
||||
least_conn;
|
||||
server <IP_NODE_1>:443 max_fails=3 fail_timeout=5s;
|
||||
server <IP_NODE_2>:443 max_fails=3 fail_timeout=5s;
|
||||
server <IP_NODE_3>:443 max_fails=3 fail_timeout=5s;
|
||||
}
|
||||
}
|
||||
|
||||
http {
|
||||
server {
|
||||
listen 443 ssl;
|
||||
proxy_pass rancher_servers_https;
|
||||
|
||||
-2
@@ -2,8 +2,6 @@
|
||||
title: 为 Rancher 设置高可用的 RKE2 Kubernetes 集群
|
||||
---
|
||||
|
||||
_已在 2.5.6 版本测试_
|
||||
|
||||
本文介绍了如何根据 [Rancher Server 环境的最佳实践](../../../reference-guides/rancher-manager-architecture/architecture-recommendations.md#kubernetes-安装环境)安装 Kubernetes 集群。
|
||||
|
||||
## 先决条件
|
||||
|
||||
+6
@@ -116,6 +116,12 @@ Windows 节点只能用于 Worker 节点。请参阅[配置 Windows 自定义集
|
||||
|
||||
在[下游集群端口要求](../../../getting-started/installation-and-upgrade/installation-requirements/port-requirements.md#下游-kubernetes-集群节点)中,你可以找到在各种情况下使用的端口的详细信息。
|
||||
|
||||
:::caution
|
||||
|
||||
不要使用与现有节点相同的主机名或 IP 地址来注册节点。这样做会导致 RKE 阻止节点加入,并导致配置挂起。主机驱动和自定义集群都可能发生这种情况。如果节点必须重用现有节点的主机名或 IP,则必须在注册节点之前设置 `hostname_override` [RKE 选项](https://rke.docs.rancher.com/config-options/nodes#overriding-the-hostname),以便节点能够正确加入。
|
||||
|
||||
:::
|
||||
|
||||
## 可选:安全注意事项
|
||||
|
||||
如果你要配置符合 CIS(互联网安全中心)Kubernetes 基准的 Kubernetes 集群,我们建议你在安装 Kubernetes 之前按照我们的强化指南来配置节点。
|
||||
|
||||
+2
-2
@@ -20,7 +20,7 @@ Rancher 不管理集群模板的版本控制。版本控制在包含模板的 He
|
||||
|
||||
## RKE2 集群模板
|
||||
|
||||
RKE2 集群模板的示例仓库在[这里](https://github.com/rancher/cluster-template-examples)。从 Rancher 2.6.0 开始,我们提供了一个 RKE2 集群模板,未来可能会添加更多模板。
|
||||
请参阅 [RKE2 集群模板](https://github.com/rancher/cluster-template-examples)的示例仓库。
|
||||
|
||||
## 向 Rancher 添加集群模板
|
||||
|
||||
@@ -33,7 +33,7 @@ RKE2 集群模板的示例仓库在[这里](https://github.com/rancher/cluster-t
|
||||
|
||||
:::
|
||||
|
||||
1. 转到集群模板示例仓库。你可以在[此 GitHub 仓库](https://github.com/rancher/cluster-template-examples)中找到 Rancher 的示例。从 Rancher 2.6.0 开始,我们提供了一个 RKE2 集群模板,未来可能会添加更多模板。
|
||||
1. 转到集群模板示例仓库。Rancher 的示例位于[此 GitHub 仓库中](https://github.com/rancher/cluster-template-examples)。
|
||||
1. 复刻仓库。
|
||||
1. 可选:通过编辑 `values.yaml` 文件来编辑集群选项。有关编辑文件的帮助,请参阅集群模板的 Helm Chart 自述文件。
|
||||
1. 将 Chart 仓库添加到 Rancher。点击 **☰ > 集群管理**。
|
||||
|
||||
+1
-1
@@ -9,7 +9,7 @@ description: Rancher Projects 减轻了集群的管理负担并支持多租户
|
||||
|
||||
:::note
|
||||
|
||||
从 Rancher v2.6 开始,项目不再强调 UI,因为不再需要在项目范围内创建任何 Kubernetes 资源。但是,如果启用了旧版功能开关,则仍可以在项目范围内创建诸如 [Secrets](../../new-user-guides/kubernetes-resources-setup/secrets.md#在项目中创建密文) 之类的资源。
|
||||
UI 上不再强调项目,因为不需要在项目范围内创建 Kubernetes 资源。但是,如果启用了旧版功能开关,则仍可以在项目范围内创建诸如 [Secrets](../../new-user-guides/kubernetes-resources-setup/secrets.md#在项目中创建密文) 之类的资源。
|
||||
|
||||
:::
|
||||
|
||||
|
||||
+1
-7
@@ -4,12 +4,6 @@ title: Harvester 集成
|
||||
|
||||
Harvester 是 Rancher 2.6.1 新增的功能,[Harvester](https://docs.harvesterhci.io/) 是基于 Kubernetes 构建的开源超融合基础架构 (HCI) 软件。Harvester 安装在裸金属服务器上,提供集成的虚拟化和分布式存储功能。虽然 Harvester 使用 Kubernetes 运行,但它不需要用户了解 Kubernetes 概念,因此是一个更加用户友好的应用。
|
||||
|
||||
---
|
||||
**_v2.6.3 的新功能_**
|
||||
|
||||
Harvester 已 GA。有关所有更新,请参阅 [Harvester 发行说明](https://github.com/harvester/harvester/releases)。
|
||||
|
||||
---
|
||||
### 功能开关
|
||||
|
||||
你可以使用 Harvester 的功能开关来管理 Harvester 在 Rancher 虚拟化管理页面的访问,用户可以在该页面直接导航到 Harvester 集群并访问 Harvester UI。Harvester 的功能开关是默认启用的。如需了解 Rancher 中功能开关的更多详细信息,请单击[此处](../pages-for-subheaders/enable-experimental-features.md)。
|
||||
@@ -26,7 +20,7 @@ Harvester 已 GA。有关所有更新,请参阅 [Harvester 发行说明](https
|
||||
|
||||
### Harvester 主机驱动
|
||||
|
||||
从 Rancher v2.6.3 开始,[Harvester 主机驱动](https://docs.harvesterhci.io/v1.1/rancher/node/node-driver/) 已在 Rancher 的 RKE 和 RKE2 选项中 GA。无论 Harvester 功能开关是否启用,主机驱动都是可用的。请注意,默认情况下主机驱动是关闭的。用户只能通过**集群管理**页面在 Harvester 上创建 RKE 或 RKE2 集群。
|
||||
[Harvester 主机驱动](https://docs.harvesterhci.io/v1.1/rancher/node/node-driver/) 通常可用于 Rancher 中的 RKE 和 RKE2 选项。无论 Harvester 功能开关是否启用,主机驱动都是可用的。请注意,默认情况下主机驱动是关闭的。用户只能通过**集群管理**页面在 Harvester 上创建 RKE 或 RKE2 集群。
|
||||
|
||||
Harvester 允许通过 Harvester UI 上传和显示 `.ISO` 镜像,但 Rancher UI 不支持。这是因为 `.ISO` 镜像通常需要额外的设置,这会干扰干净的部署(即无需用户干预),并且它们通常不用于云环境。
|
||||
|
||||
|
||||
+1
-5
@@ -4,7 +4,7 @@ title: NeuVector 集成
|
||||
|
||||
### Rancher 中的 NeuVector 集成
|
||||
|
||||
[NeuVector 5.x](https://open-docs.neuvector.com/) 是一个开源的,以容器为中心的安全应用程序,Rancher 2.6.5 现已集成 NeuVector。NeuVector 在运行时为关键应用程序和数据提供实时的合规、可见和保护功能。NeuVector 提供具有 CIS Benchmark 和漏洞扫描的防火墙、容器进程/文件系统监控和安全审计。有关 Rancher 安全性的更多信息,请参阅[安全文档](../pages-for-subheaders/rancher-security.md)。
|
||||
[NeuVector 5.x](https://open-docs.neuvector.com/) 是一个开源的,以容器为中心的安全应用程序,Rancher 已集成 NeuVector。NeuVector 在运行时为关键应用程序和数据提供实时的合规、可见和保护功能。NeuVector 提供具有 CIS Benchmark 和漏洞扫描的防火墙、容器进程/文件系统监控和安全审计。有关 Rancher 安全性的更多信息,请参阅[安全文档](../pages-for-subheaders/rancher-security.md)。
|
||||
|
||||
NeuVector 可以通过 Helm Chart 启用。你可以在 **Apps** 或 Rancher UI 中的 **Cluster Tools** 中安装该 Chart。安装 Helm Chart 后,用户可以轻松地[在 Rancher 中部署和管理 NeuVector 集群](https://open-docs.neuvector.com/deploying/rancher#deploy-and-manage-neuvector-through-rancher-apps-marketplace)。
|
||||
|
||||
@@ -108,8 +108,6 @@ NeuVector 安全解决方案包含四种类型的安全容器,分别是 Contro
|
||||
|
||||
- 如果 PSP 设置为 true,则所有 NeuVector 组件都是可部署的。
|
||||
|
||||
**_v2.6.7 新功能_**
|
||||
|
||||
你需要为强化集群环境进行额外的配置,如下所示:
|
||||
|
||||
1. 点击 **☰ > 集群管理**。
|
||||
@@ -141,8 +139,6 @@ kubectl patch cronjob neuvector-updater-pod -n cattle-neuvector-system --patch '
|
||||
```
|
||||
<br/>
|
||||
|
||||
**_v2.6.7 新功能_**
|
||||
|
||||
你需要为强化集群环境进行额外的配置。
|
||||
|
||||
> **注意**:你必须更新 RKE2 和 K3s 强化集群中的配置,如下所示。
|
||||
|
||||
+1
-1
@@ -4,4 +4,4 @@ title: 云市场集成
|
||||
|
||||
Rancher 提供与云市场的集成,让你能轻松购买云提供商上的安装支持。此外,该集成还支持生成 supportconfig bundle,你可以将该 bundle 提供给 Rancher。
|
||||
|
||||
从 Rancher 2.6.7 开始,此集成仅支持 AWS。
|
||||
此集成仅支持 AWS。
|
||||
|
||||
+4
-11
@@ -4,18 +4,12 @@ title: Rancher 中的 Helm Chart
|
||||
|
||||
在本节中,你将学习如何在 Rancher 中管理 Helm Chart 仓库和应用。你可以在 **Apps** 中管理 Helm Chart 仓库。它使用类似目录的系统从仓库中导入 Chart 包,然后使用这些 Chart 来部署自定义 Helm 应用或 Rancher 工具(例如监控和 Istio)。Rancher 工具以预加载仓库的方式提供,并能部署为独立的 Helm Chart 。其他仓库只会添加到当前集群。
|
||||
|
||||
### Rancher 2.6 变更
|
||||
### 版本控制方案
|
||||
|
||||
Rancher 2.6.0 实现了功能 Chart 的新版本控制方案。变更主要是 Chart 的主要版本和上游 Chart 的 +up 注释(如果适用)。
|
||||
Rancher 功能 Chart 版本控制方案以 Chart 的主要版本和上游 Chart 的 `+up` 注释(如果适用)为中心。
|
||||
|
||||
**主要版本**:Chart 的主要版本与 Rancher 次要版本相关联。当你升级到新的 Rancher 次要版本时,你应该确保你的所有 **Apps** Chart 也升级到 Chart 的正确发行版本。
|
||||
|
||||
:::note
|
||||
|
||||
如果你的主要版本低于下表中提到的版本,则请使用 2.5 及以下版本。例如,建议你不要在 2.6.x+ 中使用 <100.x.x 版本的 Monitoring。
|
||||
|
||||
:::
|
||||
|
||||
**功能 Chart**:
|
||||
|
||||
| **Name** | **支持的最低版本** | **支持的最高版本** |
|
||||
@@ -104,12 +98,11 @@ Chart 页面包含所有 Rancher、Partner 和自定义 Chart 。
|
||||
[...]
|
||||
```
|
||||
|
||||
|
||||
:::note
|
||||
|
||||
带有身份验证的 Helm Chart 仓库
|
||||
|
||||
从 Rancher 2.6.3 开始,Repo.Spec 中添加了一个新值 `disableSameOriginCheck`。它允许用户绕过相同源的检查,将仓库身份验证信息作为基本 Auth 标头与所有 API 调用一起发送。不建议采用这种做法,但这可以用作非标准 Helm Chart 仓库(例如重定向到不同源 URL 的仓库)的临时解决方案。
|
||||
Repo.Spec 包含一个 `disableSameOriginCheck`,能允许用户绕过相同源的检查,将仓库身份认证信息作为基本 Auth 标头与所有 API 调用一起发送。不建议采用这种做法,但这可以用作非标准 Helm Chart 仓库(例如重定向到不同源 URL 的仓库)的临时解决方案。
|
||||
|
||||
要将此功能用于现有 Helm Chart 仓库,请单击 <b>⋮ > 编辑 YAML</b>。在 YAML 文件的 `spec` 部分,添加 `disableSameOriginCheck` 并将其设置为 `true`:
|
||||
|
||||
@@ -147,7 +140,7 @@ spec:
|
||||
|
||||
:::
|
||||
|
||||
#### Rancher 2.6.3 变更
|
||||
#### 旧版应用
|
||||
|
||||
**Apps > Installed Apps** 页面中,旧版应用的升级按钮已被移除。
|
||||
|
||||
|
||||
+2
-2
@@ -24,9 +24,9 @@ Rancher 可以安装在以下主要架构上:
|
||||
|
||||
我们建议使用 Kubernetes 包管理器 Helm 在专用的 Kubernetes 集群上安装 Rancher。在 RKE 集群中,需要使用三个节点才能实现高可用集群。在 K3s 集群中,只需要两个节点即可。
|
||||
|
||||
### 在 Amazon EKS 上部署 Rancher 的快速入门
|
||||
### 通过 AWS Marketplace 在 EKS 上安装 Rancher
|
||||
|
||||
Rancher 和 Amazon Web Services 合作编写了一份快速入门指南,用于按照 AWS 的最佳实践,在 EKS Kubernetes 集群上部署 Rancher。详情请参见[部署指南](https://aws-quickstart.github.io/quickstart-eks-rancher/)。
|
||||
你可以[通过 AWS Marketplace](../getting-started/quick-start-guides/deploy-rancher-manager/aws-marketplace.md) 将 Rancher 安装到 Amazon Elastic Kubernetes Service (EKS) 上。部署的 EKS 集群已生产就绪,并遵循 AWS 最佳实践。
|
||||
|
||||
### 单节点 Kubernetes 安装
|
||||
|
||||
|
||||
-9
@@ -17,13 +17,6 @@ Windows 集群的其他要求如下:
|
||||
|
||||
有关支持 Windows 的 Kubernetes 功能摘要,请参阅[在 Windows 中使用 Kubernetes 支持的功能和限制](https://kubernetes.io/docs/setup/production-environment/windows/intro-windows-in-kubernetes/#supported-functionality-and-limitations)的 Kubernetes 文档,或[在 Kubernetes 中调度 Windows 容器的指南](https://kubernetes.io/docs/setup/production-environment/windows/user-guide-windows-containers/)。
|
||||
|
||||
|
||||
## Rancher 2.6 变更
|
||||
|
||||
Rancher 2.6 支持直接使用 Rancher UI 配置 [RKE2](https://docs.rke2.io/) 集群。RKE2,也称为 RKE Government,是一个完全符合标准的 Kubernetes 发行版,它专注于安全性和合规性。
|
||||
|
||||
在 Rancher 2.6.5 中,RKE2 已经 GA。
|
||||
|
||||
### RKE2 Windows
|
||||
|
||||
RKE2 配置功能还包括在 Windows 集群上安装 RKE2。RKE2 的 Windows 功能包括:
|
||||
@@ -41,8 +34,6 @@ RKE2 配置功能还包括在 Windows 集群上安装 RKE2。RKE2 的 Windows
|
||||
|
||||
:::
|
||||
|
||||
**_Rancher v2.6.7 新功能_**
|
||||
|
||||
- Kubernetes v1.24.1 及更高版本支持 Windows RKE2 中的 HostProcess 容器。有关详细信息,请参阅[上游文档](https://kubernetes.io/docs/tasks/configure-pod-container/create-hostprocess-pod/)。
|
||||
|
||||
## Windows 集群的要求
|
||||
|
||||
-3
@@ -34,9 +34,6 @@ title: EC2 节点模板配置
|
||||
|
||||
请参考[使用主机驱动时的 Amazon EC2 安全组](../../../../getting-started/installation-and-upgrade/installation-requirements/port-requirements.md#rancher-aws-ec2-安全组),了解 `rancher-nodes` 安全组中创建的规则。
|
||||
|
||||
---
|
||||
**_v2.6.4 的新功能_**
|
||||
|
||||
如果你自行为 EC2 实例提供安全组,Rancher 不会对其进行修改。因此,你需要让你的安全组允许 [Rancher 配置实例所需的端口](../../../../getting-started/installation-and-upgrade/installation-requirements/port-requirements.md#rke-上-rancher-server-节点的端口)。有关使用安全组控制 EC2 实例的入站和出站流量的更多信息,请参阅[这里](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_SecurityGroups.html#WorkingWithSecurityGroups)。
|
||||
|
||||
### 实例选项
|
||||
|
||||
+1
-25
@@ -40,37 +40,13 @@ Alerting Drivers 为 Alertmanager 将告警代理到非原生接收器,例如
|
||||
|
||||
### 分组
|
||||
|
||||
<Tabs>
|
||||
<TabItem value="Rancher v2.6.5+">
|
||||
|
||||
:::note
|
||||
|
||||
从 Rancher 2.6.5 开始,`分组依据`开始接受字符串列表而不是键值对。有关详细信息,请参阅[上游文档](https://github.com/prometheus-operator/prometheus-operator/blob/main/Documentation/api.md#route)。
|
||||
|
||||
:::
|
||||
|
||||
| 字段 | 默认 | 描述 |
|
||||
|-------|--------------|---------|
|
||||
| 分组依据 | N/A | 用于分组的标签列表。标签不得重复(在列表内)。如果提供了特殊标签“...”(由所有可能的标签聚合),标签必须在列表中是唯一的元素。 |
|
||||
| 分组依据 | N/A | 用于分组的标签列表。标签必须是唯一的。如果提供了特殊标签“...”(由所有可能的标签聚合),标签必须在列表中是唯一的元素。接受字符串列表。有关详细信息,请参阅[上游文档](https://github.com/prometheus-operator/prometheus-operator/blob/main/Documentation/api.md#route)。 |
|
||||
| 组等待时长 | 30s | 在发送之前,缓冲同一组告警的等待时间。 |
|
||||
| 组间隔 | 5m | 等待多长时间才发送已添加到告警组的告警,其中该告警组的初次通知已被发送。 |
|
||||
| 重复间隔 | 4h | 等待多长时间后,才重新发送已发送的告警。 |
|
||||
|
||||
</TabItem>
|
||||
<TabItem value="Rancher 版本低于 v2.6.5">
|
||||
|
||||
| 字段 | 默认 | 描述 |
|
||||
|-------|--------------|---------|
|
||||
| 分组依据 | N/A | 将传入告警进行分组的标签。例如,`[ group_by: '[' <labelname>, ... ']' ]`。针对 `cluster=A` 和 `alertname=LatencyHigh` 等标签的多个告警可以批处理到一个组中。要按所有可能的标签进行聚合,请使用特殊值 `'...'` 作为唯一标签名称,如 `group_by: ['...']`。以 `...` 进行分组能有效地完全禁用聚合,并按原样传递所有告警。除非你的告警量非常低或者你的上游通知系统能执行分组,否则你不太需要这样做。 |
|
||||
| 组等待时长 | 30s | 在发送之前,缓冲同一组告警的等待时间。 |
|
||||
| 组间隔 | 5m | 等待多长时间才发送已添加到告警组的告警,其中该告警组的初次通知已被发送。 |
|
||||
| 重复间隔 | 4h | 等待多长时间后,才重新发送已发送的告警。 |
|
||||
|
||||
</TabItem>
|
||||
</Tabs>
|
||||
|
||||
|
||||
|
||||
### 匹配
|
||||
|
||||
**Match** 字段指一组相等匹配器,用于根据告警上定义的标签来识别要发送到指定路由的告警。在 Rancher UI 中添加键值对时,它们对应于以下格式的 YAML:
|
||||
|
||||
+1
-1
@@ -103,4 +103,4 @@ RKE 每个角色至少需要一个节点,但并不强制每个节点只能有
|
||||
|
||||
如果你在负载均衡器上使用了私有 CA 签发的证书,你需要提供 CA 证书,这个证书会包含在生成的 kubeconfig 文件中,以校验证书链。详情请参见 [kubeconfig 文件](../../how-to-guides/new-user-guides/manage-clusters/access-clusters/use-kubectl-and-kubeconfig.md)和 [API 密钥](../user-settings/api-keys.md#创建-api-密钥)的相关文档。
|
||||
|
||||
在 Rancher 2.6.3 中,注册的 RKE2 和 K3s 集群可以使用 ACE 支持。点击[这里](../../how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/register-existing-clusters.md#对-rke2-和-k3s-集群的授权集群端点支持)了解在下游集群中开启 ACE 的步骤。
|
||||
注册的 RKE2 和 K3s 集群可以使用 ACE 支持。点击[这里](../../how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/register-existing-clusters.md#对-rke2-和-k3s-集群的授权集群端点支持)了解在下游集群中开启 ACE 的步骤。
|
||||
|
||||
-2
@@ -46,8 +46,6 @@ docker run -d --restart=unless-stopped \
|
||||
|
||||
### 离线代理配置
|
||||
|
||||
_v2.6.4 的新功能_
|
||||
|
||||
你现在可以在配置的离线集群中配置主机驱动集群,以使用代理进行出站连接。
|
||||
|
||||
除了如上为代理服务器设置默认规则外,你还需要额外添加如下所示的规则,以从代理的 Rancher 环境中配置主机驱动集群。
|
||||
|
||||
+21
-3
@@ -280,11 +280,29 @@ docker exec etcd etcdctl alarm disarm
|
||||
docker exec etcd etcdctl alarm list
|
||||
```
|
||||
|
||||
## 日志级别
|
||||
## 配置日志级别
|
||||
|
||||
etcd 的日志级别可以通过 API 来动态更改。你可以使用以下命令来配置调试日志。
|
||||
:::note
|
||||
|
||||
你无法再动态更改 etcd v3.5 或更高版本中的日志级别。
|
||||
|
||||
:::
|
||||
|
||||
### etcd v3.5 及更高版本
|
||||
|
||||
要配置 etcd 的日志级别,请编辑集群 YAML:
|
||||
|
||||
```
|
||||
services:
|
||||
etcd:
|
||||
extra_args:
|
||||
log-level: "debug"
|
||||
```
|
||||
|
||||
### etcd v3.4 及更早版本
|
||||
|
||||
在早期的 etcd 版本中,你可以使用 API 动态更改日志级别。使用以下命令来配置调试日志:
|
||||
|
||||
命令:
|
||||
```
|
||||
docker run --net=host -v $(docker inspect kubelet --format '{{ range .Mounts }}{{ if eq .Destination "/etc/kubernetes" }}{{ .Source }}{{ end }}{{ end }}')/ssl:/etc/kubernetes/ssl:ro appropriate/curl -s -XPUT -d '{"Level":"DEBUG"}' --cacert $(docker exec etcd printenv ETCDCTL_CACERT) --cert $(docker exec etcd printenv ETCDCTL_CERT) --key $(docker exec etcd printenv ETCDCTL_KEY) $(docker exec etcd printenv ETCDCTL_ENDPOINTS)/config/local/log
|
||||
```
|
||||
|
||||
Reference in New Issue
Block a user