mirror of
https://github.com/rancher/rancher-docs.git
synced 2026-05-05 20:53:33 +00:00
update missing Chinese translation for v2.7
This commit is contained in:
Jacie
@@ -2,68 +2,50 @@
|
||||
title: 一般常见问题解答
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/zh/faq/general-faq"/>
|
||||
</head>
|
||||
|
||||
本文包含了用户常见的 Rancher 2.x 问题。
|
||||
|
||||
有关常见技术问题，请参阅[常见技术问题解答](technical-items.md)。
|
||||
|
||||
<br/>
|
||||
|
||||
**Rancher 2.x 支持 Docker Swarm 和 Mesos 作为环境类型吗？**
|
||||
## Rancher 2.x 支持 Docker Swarm 和 Mesos 作为环境类型吗？
|
||||
|
||||
如果你在 Rancher 2.x 中创建环境，Swarm 和 Mesos 将不再是可选的标准选项。但是，Swarm 和 Mesos 还能继续作为可以部署的商店应用程序。这是一个艰难的决定，但这是大势所趋。比如说，15,000 多个集群可能只有大约 200 个在运行 Swarm。
|
||||
|
||||
<br/>
|
||||
## 是否可以使用 Rancher 2.x 管理 Azure Kubernetes 服务？
|
||||
|
||||
**是否可以使用 Rancher 2.x 管理 Azure Kubernetes 服务？**
|
||||
是的。请参阅我们的[集群管理]((../how-to-guides/new-user-guides/manage-clusters/manage-clusters.md))指南，了解 AKS 上可用的 Rancher 功能，以及相关的 [AKS 的文档](../getting-started/installation-and-upgrade/install-upgrade-on-a-kubernetes-cluster/rancher-on-aks.md)
|
||||
|
||||
是的。
|
||||
## Rancher 是否支持 Windows？
|
||||
|
||||
<br/>
|
||||
Rancher 支持 Windows Server 1809 容器。有关如何使用 Windows Worker 节点设置集群的详细信息，请参阅[为 Windows 配置自定义集群](../how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/use-windows-clusters/use-windows-clusters.md)。
|
||||
|
||||
**Rancher 是否支持 Windows？**
|
||||
|
||||
Rancher 支持 Windows Server 1809 容器。有关如何使用 Windows Worker 节点设置集群的详细信息，请参阅[为 Windows 配置自定义集群](../pages-for-subheaders/use-windows-clusters.md)。
|
||||
|
||||
<br/>
|
||||
|
||||
**Rancher 是否支持 Istio？**
|
||||
## Rancher 是否支持 Istio？
|
||||
|
||||
Rancher 支持 [Istio](../pages-for-subheaders/istio.md)。
|
||||
|
||||
此外，Istio 是在我们的微型 PaaS “Rio” 中实现的，它可以运行在 Rancher 2.x 以及任何符合 CNCF 的 Kubernetes 集群上。详情请参阅[这里](https://rio.io/)。
|
||||
|
||||
<br/>
|
||||
|
||||
**Rancher 2.x 是否支持使用 Hashicorp 的 Vault 来存储密文？**
|
||||
## Rancher 2.x 是否支持使用 Hashicorp 的 Vault 来存储密文？
|
||||
|
||||
密文管理已在我们的 roadmap 上，但我们尚未将该功能分配给特定版本。
|
||||
|
||||
<br/>
|
||||
|
||||
**Rancher 2.x 是否也支持 RKT 容器？**
|
||||
## Rancher 2.x 是否也支持 RKT 容器？
|
||||
|
||||
目前，我们只支持 Docker。
|
||||
|
||||
<br/>
|
||||
|
||||
**Rancher 2.x 是否支持将 Calico、Contiv、Contrail、Flannel、Weave net 等网络插件用于嵌入和已注册的 Kubernetes？**
|
||||
## Rancher 2.x 是否支持将 Calico、Contiv、Contrail、Flannel、Weave net 等网络插件用于嵌入和已注册的 Kubernetes？
|
||||
|
||||
Rancher 开箱即用地为 Kubernetes 集群提供了几个 CNI 网络插件，分别是 Canal、Flannel、Calico 和 Weave。有关官方支持的详细信息，请参阅 [Rancher 支持矩阵](https://rancher.com/support-maintenance-terms/)。
|
||||
|
||||
<br/>
|
||||
|
||||
**Rancher 是否计划支持 Traefik？**
|
||||
## Rancher 是否计划支持 Traefik？
|
||||
|
||||
目前，我们不打算提供嵌入式 Traefik 支持，但我们仍在探索负载均衡方案。
|
||||
|
||||
<br/>
|
||||
|
||||
**我可以将 OpenShift Kubernetes 集群导入 2.x 吗？**
|
||||
## 我可以将 OpenShift Kubernetes 集群导入 2.x 吗？
|
||||
|
||||
我们的目标是运行任何上游 Kubernetes 集群。因此，Rancher 2.x 应该可以与 OpenShift 一起使用，但我们尚未对此进行测试。
|
||||
|
||||
<br/>
|
||||
|
||||
**Rancher 会集成 Longhorn 吗？**
|
||||
## Rancher 会集成 Longhorn 吗？
|
||||
|
||||
是的。Longhorn 已集成到 Rancher 2.5+ 中。
|
||||
|
||||
+1
-1
@@ -159,7 +159,7 @@ Rancher 的一些功能（Helm Chart）需要使用互联网才能使用。你
|
||||
|
||||
不包括敏感数据时，可以使用 `proxy` 或 `extraEnv` Chart 选项。使用 `extraEnv` 时将忽略 `noProxy` Helm 选项。因此，`NO_PROXY` 环境变量也必须设置为 `extraEnv`。
|
||||
|
||||
以下是使用 `extraEnv` Chart 选项设置代理的示例：
|
||||
以下是使用 `proxy` Chart 选项设置代理的示例：
|
||||
|
||||
```plain
|
||||
--set proxy="http://<proxy_url:proxy_port>/"
|
||||
|
||||
+12
-27
@@ -4,38 +4,23 @@ title: 还原 Rancher
|
||||
|
||||
本页概述了如何使用 Rancher 执行恢复。
|
||||
|
||||
:::note 重要提示：
|
||||
在以下情况下，请按照本页中的说明进行操作：
|
||||
- 正在运行的 Rancher 实例与备份时的版本相同。
|
||||
- 上游（本地）集群与备份的位置相同。
|
||||
|
||||
* 请按照此页面上的说明在已备份的同一集群上还原 Rancher。要把 Rancher 迁移到新集群，请参照步骤[迁移 Rancher](migrate-rancher-to-new-cluster.md)。
|
||||
* 在使用相同设置还原 Rancher 时，operator 将在还原开始时缩减 Rancher deployment，还原完成后又会扩展 deployment。因此，Rancher 在还原期间将不可用。
|
||||
:::note 重要提示
|
||||
|
||||
在使用相同设置还原 Rancher 时，operator 将在还原开始时缩减 Rancher deployment，还原完成后又会扩展 deployment。因此，Rancher 在还原期间将不可用。
|
||||
|
||||
:::
|
||||
|
||||
:::tip
|
||||
|
||||
* 按照以下步骤[迁移 Rancher](migrate-rancher-to-new-cluster.md)。
|
||||
* 如果你需要在升级后将 Rancher 还原到先前版本，请参见[回滚](../../../getting-started/installation-and-upgrade/install-upgrade-on-a-kubernetes-cluster/rollbacks.md)。
|
||||
|
||||
:::
|
||||
|
||||
## 使用 Rancher 2.6.4+ 进行回滚的其他步骤
|
||||
|
||||
Rancher v2.6.4 将 cluster-api 模块从 v0.4.4 升级到 v1.0.2。反过来，cluster-api 的 v1.0.2 版本将集群 API 的自定义资源定义 (CRD) 从 `cluster.x-k8s.io/v1alpha4` 升级到 `cluster.x-k8s.io/v1beta1`。当你尝试将 Rancher v2.6.4 回滚到以前版本的 Rancher v2.6.x 时，CRD 升级到 v1beta1 会导致回滚失败。这是因为使用旧 apiVersion (v1alpha4) 的 CRD 与 v1beta1 不兼容。
|
||||
|
||||
要避免回滚失败，你需要在尝试恢复操作或回滚**之前**运行以下 Rancher 脚本：
|
||||
|
||||
* `verify.sh`：检查集群中是否有任何与 Rancher 相关的资源。
|
||||
* `cleanup.sh`：清理集群。
|
||||
|
||||
有关详细信息和源代码，请参阅 [rancher/rancher-cleanup repo](https://github.com/rancher/rancher-cleanup)。
|
||||
|
||||
:::caution
|
||||
|
||||
`cleanup.sh` 运行的时候会有停机时间，这是因为脚本会删除 Rancher 创建的资源。
|
||||
|
||||
:::
|
||||
|
||||
### 从 v2.6.4+ 回滚到较低版本的 v2.6.x
|
||||
|
||||
1. 按照[说明](https://github.com/rancher/rancher-cleanup/blob/main/README.md)运行脚本。
|
||||
1. 按照[说明](../backup-restore-and-disaster-recovery/migrate-rancher-to-new-cluster.md)在现有集群上安装 rancher-backup Helm Chart 并恢复之前的状态。
|
||||
1. 省略步骤 3。
|
||||
1. 执行到步骤 4 时，在要回滚到的 local 集群上安装 Rancher 2.6.x 版本。
|
||||
|
||||
### 创建 Restore 自定义资源
|
||||
|
||||
还原是通过创建 Restore 自定义资源实现的。
|
||||
|
||||
+1
-1
@@ -9,6 +9,6 @@ title: Cluster API (CAPI) 与 Rancher Turtles
|
||||
[Rancher Turtles](https://turtles.docs.rancher.com/) 是一个 [Rancher 扩展](../rancher-extensions.md)，通过提供 Cluster API (CAPI) 和 Rancher 之间的集成来管理配置的 Kubernetes 集群的生命周期。使用 Rancher Turtles，你可以：
|
||||
|
||||
- 通过在 CAPI 配置的集群中安装 Rancher Cluster Agent，将 CAPI 集群导入 Rancher。
|
||||
- 配置 [CAPI Operator](https://turtles.docs.rancher.com/docs/reference-guides/rancher-turtles-chart/values#cluster-api-operator-values)。
|
||||
- 配置 [CAPI Operator](https://turtles.docs.rancher.com/reference-guides/rancher-turtles-chart/values#cluster-api-operator-values)。
|
||||
|
||||
[概述](./overview.md)部分介绍了安装选项、Rancher Turtles 架构和简要 Demo。有关详细信息，请参阅 [Rancher Turtles 文档](https://turtles.docs.rancher.com/)。
|
||||
|
||||
+48
-9
@@ -12,6 +12,12 @@ title: 概述
|
||||
|
||||
|
||||
|
||||
## 安全
|
||||
|
||||
[SLSA](https://slsa.dev/spec/v1.0/about) 是一套由行业共识制定的可逐步采用的供应链安全指南。SLSA 制定的规范对软件生产者和消费者都很有用：生产者可以遵循 SLSA 的指导方针，使他们的软件供应链更加安全，消费者可以使用 SLSA 来决定是否信任软件包。
|
||||
|
||||
Rancher Turtles 满足 [SLSA Level 3](https://slsa.dev/spec/v1.0/levels#build-l3) 对适当的构建平台、一致的构建过程和来源分布的要求。更多信息请参阅 [Rancher Turtles 安全](https://turtles.docs.rancher.com/security/slsa)文档。
|
||||
|
||||
## 先决条件
|
||||
|
||||
在 Rancher 环境中安装 Rancher Turtles 之前，你必须禁用 Rancher 的 `embedded-cluster-api` 功能。这还包括清理 Rancher 专用的 webhook，否则这些 webhook 将与 CAPI 的 webhook 冲突。
|
||||
@@ -21,6 +27,45 @@ title: 概述
|
||||
- 禁用 Rancher 中的 `embedded-cluster-api` 功能。
|
||||
- 删除不再需要的 `mutating-webhook-configuration` 和 `validating-webhook-configuration` webhook。
|
||||
|
||||
这些 webhook 也可以通过 Rancher UI 删除：
|
||||
|
||||
1. 点击左上角 **☰ > 集群管理**。
|
||||
1. 选择你的 local 集群。
|
||||
1. 在左侧导航菜单，选择 **More Resources** > **Admission**。
|
||||
1. 在下拉菜单中，选择资源页面的 `MutatingWebhookConfiguration` 和 `ValidatingWebhookConfiguration`。
|
||||
1. 在相应的资源页面上，点击 `mutating-webhook-configuration` and `validating-webhook-configuration` 后面的 **⋮** 然后选择 **删除**。
|
||||
|
||||
还可以通过在 **Resource Search** 字段中输入 webhook 的名称来访问到具体的 webhook。
|
||||
|
||||
以下的 `kubectl` 命令可以手动删除必要的 webhook：
|
||||
|
||||
```console
|
||||
kubectl delete mutatingwebhookconfiguration.admissionregistration.k8s.io mutating-webhook-configuration
|
||||
```
|
||||
|
||||
```console
|
||||
kubectl delete validatingwebhookconfigurations.admissionregistration.k8s.io validating-webhook-configuration
|
||||
```
|
||||
|
||||
使用以下示例从控制台禁用 `embedded-cluster-api` 功能：
|
||||
|
||||
1. 创建一个 `feature.yaml` 文件，将 `embedded-cluster-api` 设置为 false：
|
||||
|
||||
```yaml title="feature.yaml"
|
||||
apiVersion: management.cattle.io/v3
|
||||
kind: Feature
|
||||
metadata:
|
||||
name: embedded-cluster-api
|
||||
spec:
|
||||
value: false
|
||||
```
|
||||
|
||||
2. 使用 `kubectl` 将 `feature.yaml` 文件应用到集群：
|
||||
|
||||
```bash
|
||||
kubectl apply -f feature.yaml
|
||||
```
|
||||
|
||||
## 安装 Rancher Turtles Operator
|
||||
|
||||
你可以通过 Rancher UI 或使用 Helm 安装 Rancher Turtles operator。对于大多数环境推荐使用第一种方法。
|
||||
@@ -47,7 +92,7 @@ title: 概述
|
||||
1. 点击 **Rancher Turtles - the Cluster API Extension**。
|
||||
1. 点击 **Install > Next > Install**.
|
||||
|
||||
此过程使用 Helm chart 的默认值，这些值适用于大部分的安装场景。如果你的配置需要覆盖其中一些默认值，你可以在安装期间通过 Rancher UI 指定这些值，也可以通过 [Helm 手动安装 Chart](#通过-helm-安装)。有关可用的 values 设置的详细信息，请参阅 Rancher Turtles 的 [Helm chart 参考指南](https://turtles.docs.rancher.com/docs/reference-guides/rancher-turtles-chart/values)。
|
||||
此过程使用 Helm chart 的默认值，这些值适用于大部分的安装场景。如果你的配置需要覆盖其中一些默认值，你可以在安装期间通过 Rancher UI 指定这些值，也可以通过 [Helm 手动安装 Chart](#通过-helm-安装)。有关可用的 values 设置的详细信息，请参阅 Rancher Turtles 的 [Helm chart 参考指南](https://turtles.docs.rancher.com/reference-guides/rancher-turtles-chart/values)。
|
||||
|
||||
安装可能需要几分钟时间，安装完成后，你可以在集群中看到以下新部署：
|
||||
|
||||
@@ -132,7 +177,7 @@ stringData:
|
||||
|
||||
:::info
|
||||
|
||||
有关 chart 支持的 values 及其用法的详细信息，请参阅 [Helm chart 选项](https://turtles.docs.rancher.com/docs/reference-guides/rancher-turtles-chart/values)
|
||||
有关 chart 支持的 values 及其用法的详细信息，请参阅 [Helm chart 选项](https://turtles.docs.rancher.com/reference-guides/rancher-turtles-chart/values)
|
||||
|
||||
:::
|
||||
|
||||
@@ -140,7 +185,7 @@ stringData:
|
||||
|
||||
:::note
|
||||
|
||||
请记住，如果使用此安装选项，你必须自行管理 CAPI Operator 的安装。你可以参照 Rancher Turtles 文档中的 [CAPI Operator 指南](https://turtles.docs.rancher.com/docs/tasks/capi-operator/intro)
|
||||
请记住，如果使用此安装选项，你必须自行管理 CAPI Operator 的安装。你可以参照 Rancher Turtles 文档中的 [CAPI Operator 指南](https://turtles.docs.rancher.com/tasks/capi-operator/intro)
|
||||
|
||||
:::
|
||||
|
||||
@@ -213,9 +258,3 @@ spec:
|
||||
```bash
|
||||
kubectl apply -f feature.yaml
|
||||
```
|
||||
|
||||
## 安全
|
||||
|
||||
[SLSA](https://slsa.dev/spec/v1.0/about) 是一套由行业共识制定的可逐步采用的供应链安全指南。SLSA 制定的规范对软件生产者和消费者都很有用：生产者可以遵循 SLSA 的指导方针，使他们的软件供应链更加安全，消费者可以使用 SLSA 来决定是否信任软件包。
|
||||
|
||||
Rancher Turtles 满足 [SLSA Level 3](https://slsa.dev/spec/v1.0/levels#build-l3) 对适当的构建平台、一致的构建过程和来源分布的要求。更多信息请参阅 [Rancher Turtles 安全](https://turtles.docs.rancher.com/docs/security/slsa)文档。
|
||||
|
||||
+106
-1
@@ -2,10 +2,28 @@
|
||||
title: Rancher Webhook
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/zh/reference-guides/rancher-webhook"/>
|
||||
</head>
|
||||
|
||||
Rancher-Webhook 是 Rancher 的重要组件，它与 Kubernetes 结合使用，用于增强安全性并为 Rancher 管理的集群启用关键功能。
|
||||
|
||||
如 [Kubernetes 文档](https://kubernetes.io/docs/reference/access-authn-authz/extensible-admission-controllers/)中所述，它与 Kubernetes 的可扩展准入控制器集成，允许 Rancher-Webhook 检查发送到 Kubernetes API Server 的特定请求，添加自定义和 Rancher 相关的验证，以及 Rancher 相关请求的变化。Rancher-Webhook 使用 `rancher.cattle.io` `ValidatingWebhookConfiguration` 和 `rancher.cattle.io` `MutatingWebhookConfiguration` 管理要验证的资源，并覆盖任何手动编辑。
|
||||
Rancher 将 Rancher-Webhook 作为单独的 deployment 和服务部署在 local 和下游集群中。Rancher 使用 Helm 管理 Rancher-Webhook。需要注意的是，Rancher 可能会覆盖用户对 Helm 版本所做的修改。
|
||||
|
||||
Rancher 将 Rancher-Webhook 作为单独的 deployment 和服务部署在 local 和下游集群中。Rancher 使用 Helm 管理 Rancher-Webhook。需要注意的是，Rancher 可能会覆盖用户对 Helm 版本所做的修改。要安全地修改这些值，请参阅[自定义 Rancher-Webhook 配置](#自定义-rancher-webhook-配置)
|
||||
|
||||
每个 Rancher 版本都设计为与某个具体版本的 Webhook 兼容，为方便起见，下面提供了各版本的兼容列表。
|
||||
|
||||
**注意：** Rancher 负责管理 webhook 的部署和升级。在多数情况下，不需要用户干预来确保 webhook 版本与你正在运行的 Rancher 版本兼容。
|
||||
|
||||
<!-- releaseTask -->
|
||||
|
||||
| Rancher Version | Webhook Version | Availability in Prime | Availability in Community |
|
||||
| --------------- | --------------- | --------------------- | ------------------------- |
|
||||
| v2.8.3 | v0.4.3 | ✓ | ✓ |
|
||||
| v2.8.2 | v0.4.2 | ✓ | ✓ |
|
||||
| v2.8.1 | v0.4.2 | ✓ | ✓ |
|
||||
| v2.8.0 | v0.4.2 | ✗ | ✓ |
|
||||
|
||||
## 为什么我们需要它？
|
||||
|
||||
@@ -13,6 +31,58 @@ Rancher-Webhook 对于让 Rancher 保护集群免受恶意攻击并启用各种
|
||||
Rancher 依赖 Rancher-Webhook 作为其功能的组成部分。如果没有 Webhook，Rancher 将不是一个完整的产品。
|
||||
它为 Rancher 管理的集群提供了必要的保护，防止安全漏洞并确保集群的一致性和稳定性。
|
||||
|
||||
## Webhook 验证哪些资源?
|
||||
|
||||
你可以在 [webhook 仓库](https://github.com/rancher/webhook/blob/release/v0.4/docs.md)中找到 webhook 当前验证的资源列表。这些文档按组/版本（顶级标题）和资源（下一级标题）进行组织。可以通过查看与特定版本标签关联的 `docs.md` 文件来找到特定于一个版本的检查。请注意，`v0.3.6` 之前的 webhook 版本没有此文件。
|
||||
|
||||
## 绕过 Webhook
|
||||
|
||||
有时，你必须绕过 Rancher 的 webhook 验证才能执行紧急还原操作或修复其他关键问题。避开操作是彻底的，这意味着在使用它时不会应用任何 webhook 验证或更改。不可能指定绕过某些验证，而让其他验证仍然可用。它们要么全部被绕过，要么全部处于活动状态。
|
||||
|
||||
:::danger
|
||||
|
||||
Rancher 的 webhook 提供关键的安全保护。只有在所有其他选项都用尽之后，管理员才需要在特定情况下绕过 webhook。此外，应仔细控制绕过 webhook 的权限，切勿将该权限授予非管理员用户。
|
||||
|
||||
:::
|
||||
|
||||
要绕过 webhook，请模拟 `rancher-webhook-sudo` 服务账号和 `system:masters` 组（两者都是必需的）：
|
||||
|
||||
```bash
|
||||
kubectl create -f example.yaml --as=system:serviceaccount:cattle-system:rancher-webhook-sudo --as-group=system:masters
|
||||
```
|
||||
|
||||
## 自定义 Rancher-Webhook 配置
|
||||
|
||||
你可以通过 Helm 安装 Rancher-Webhook 时添加自定义 Helm values。在 Rancher-Webhook chart 的安装过程中，Rancher 会检查自定义的 Helm values。这些自定义值必须在 `cattle-system` 命名空间中，名称为 `rancher-config` 的 ConfigMap 的 data 属性下，增加 `rancher-webhook` 的配置定义。此键的值必须是有效的 YAML。
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: ConfigMap
|
||||
metadata:
|
||||
name: rancher-config
|
||||
namespace: cattle-system
|
||||
labels:
|
||||
app.kubernetes.io/part-of: "rancher"
|
||||
data:
|
||||
rancher-webhook: '{"port": 9553, "priorityClassName": "system-node-critical"}'
|
||||
```
|
||||
|
||||
Rancher 会在检测到对 ConfigMap 值的更改时重新部署 Rancher-Webhook Chart。
|
||||
|
||||
### 在 Rancher 安装过程中自定义 Rancher-Webhook
|
||||
|
||||
使用 Helm 安装 Rancher chart 时，可以在 local 集群中将自定义的 Helm values 添加到 Rancher-Webhook。Rancher-Webhook Chart 中的所有值都可以通过 `webhook` 名称下的嵌套变量访问。
|
||||
|
||||
这些值在安装过程中会同步到 `rancher-config` ConfigMap 中。
|
||||
|
||||
```bash
|
||||
helm install rancher rancher-<CHART_REPO>/rancher \
|
||||
--namespace cattle-system \
|
||||
...
|
||||
--set webhook.port=9553 \
|
||||
--set webhook.priorityClassName="system-node-critical"
|
||||
```
|
||||
|
||||
## 常见问题
|
||||
|
||||
### 带有 Calico CNI 的 EKS 集群
|
||||
@@ -24,8 +94,11 @@ Rancher 依赖 Rancher-Webhook 作为其功能的组成部分。如果没有 Web
|
||||
helm repo add rancher-charts https://charts.rancher.io
|
||||
helm upgrade --reuse-values rancher-webhook rancher-chart/rancher-webhook -n cattle-system --set global.hostNetwork=true
|
||||
```
|
||||
|
||||
**注意**：这个临时解决方法可能会违反环境的安全策略。此解决方法还要求主机网络上未使用端口 9443。
|
||||
|
||||
**注意：** 默认情况下，Helm 使用 secrets。这是某些 webhook 版本验证用于存储信息的数据类型。在这种情况下，请使用 kubectl 更新 deployment 设置 `hostNetwork=true`，然后按照上述配置更新 webhook。
|
||||
|
||||
### 私有 GKE 集群
|
||||
|
||||
使用私有 GKE 集群时可能会发生错误，导致 Kubernetes API Server 无法与 Webhook 通信。以下错误消息可能会出现：
|
||||
@@ -33,4 +106,36 @@ helm upgrade --reuse-values rancher-webhook rancher-chart/rancher-webhook -n ca
|
||||
```
|
||||
Internal error occurred: failed calling webhook "rancher.cattle.io.namespaces.create-non-kubesystem": failed to call webhook: Post "https://rancher-webhook.cattle-system.svc:443/v1/webhook/validation/namespaces?timeout=10s": context deadline exceeded
|
||||
```
|
||||
|
||||
出现此问题的原因是防火墙规则限制了 API Server 与私有集群之间的通信。要解决此通信问题，你必须通过添加防火墙规则来允许 GKE Control Plane 通过端口 9443 与 Rancher-Webhook 进行通信。请参阅 [GKE 文档](https://cloud.google.com/kubernetes-engine/docs/how-to/private-clusters#add_firewall_rules)，了解更新防火墙规则的详细信息和步骤。
|
||||
|
||||
### 由于 rancher-webhook 阻止访问导致应用部署失败
|
||||
|
||||
webhook 在 [namespaces](https://github.com/rancher/webhook/blob/release/v0.4/docs.md#psa-label-validation) 上提供额外的验证。其中一项验证可确保用户只有在具有适当权限的情况下才能更新 PSA 相关标签（`updatepsa` for `projects` in `management.cattle.io`）。这可能导致特定 operator（如 Tigera 或 Trident）在尝试部署带有 PSA 标签的命名空间时失败。有几种方法可以解决此问题：
|
||||
|
||||
- 将应用程序配置为创建没有 PSA 标签的命名空间。如果用户希望将 PSA 应用于这些命名空间，则可以在配置后将它们添加到具有所需 PSA 的项目中。请参阅[设置 PSS 和 PSA 资源的文档](../how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/pod-security-standards.md)获取更具体的操作方法。
|
||||
- 这是首选选项，但并非所有应用程序都可以以这种方式进行配置。
|
||||
- 手动授予操作员管理命名空间下的 PSA 的权限。
|
||||
- 此选项将引入安全风险，因为运营商现在将能够为其有权访问的命名空间设置 PSA。这可能允许操作员部署特权 Pod，或通过其他方式实现集群接管。
|
||||
- 具有适当权限的用户帐户可以使用适当的配置预先创建命名空间。
|
||||
- 此选项取决于应用程序处理现有资源的能力。
|
||||
|
||||
## 特定版本的问题
|
||||
|
||||
**注意：** 以下是影响特定 Rancher/webhook 版本的高严重性问题的不完整列表。在大多数情况下，这些问题可以通过升级到更新的 Rancher 版本来解决。
|
||||
|
||||
### 回滚到不兼容的 Webhook 版本
|
||||
|
||||
**注意：** 这会影响回滚到 Rancher v2.7.5 或更早版本。
|
||||
|
||||
如果回滚到 Rancher v2.7.5 或更早版本，您可能会看到 webhook 版本太新，无法与运行 v2.7.5 之前版本的 Rancher 的下游集群兼容。这可能会导致各种不兼容问题。例如，项目成员可能无法创建命名空间。此外，当您回滚到下游集群中安装 webhook 之前的版本时，webhook 可能仍保持安装状态，这会导致类似的不兼容问题。
|
||||
|
||||
为了帮助缓解这些问题，您可以在回滚后运行 [adjust-downstream-webhook](https://github.com/rancherlabs/support-tools/tree/master/adjust-downstream-webhook) shell 脚本。该脚本为相应的 Rancher 版本选择并安装正确的 webhook 版本（或完全删除 webhook）。
|
||||
|
||||
### 项目用户无法创建命名空间
|
||||
|
||||
**注意：** 以下内容影响 Rancher v2.7.2 - v2.7.4。
|
||||
|
||||
项目用户可能无法在项目中创建命名空间，这包括项目所有者。此问题是由于 Rancher 自动将 webhook 升级到与当前安装的 Rancher 版本更新的版本不兼容而导致的。
|
||||
|
||||
为了帮助缓解这些问题，您可以在回滚后运行 [adjust-downstream-webhook](https://github.com/rancherlabs/support-tools/tree/master/adjust-downstream-webhook) shell 脚本。该脚本为相应的 Rancher 版本选择并安装正确的 webhook 版本（或完全删除 webhook）。
|
||||
|
||||
Reference in New Issue
Block a user