Add v2.14 preview docs (#2212)

2026-09-25 20:48:11 +00:00 · 2026-03-05 12:30:57 -08:00
parent 4a0d71b3f3
commit 2dcfa6f6b8
874 changed files with 92618 additions and 0 deletions
@@ -0,0 +1,84 @@
+---
+title: 在 vSphere 环境中安装 Rancher
+---
+
+本指南概述了在 vSphere 环境中在 RKE Kubernetes 集群上安装 Rancher 的参考架构，以及 VMware 记录的标准 vSphere 最佳实践。
+
+
+<figcaption>解决方案概述</figcaption>
+
+![解决方案概述](/img/rancher-on-prem-vsphere.svg)
+
+## 1. 负载均衡器注意事项
+
+你需要使用一个负载均衡器将流量转发到 RKE 节点上的 Rancher 工作负载。
+
+### 利用容错和高可用性
+
+请充分利用具有继承高可用功能的外部（硬件或软件）负载均衡器（如：F5、NSX-T、Keepalived 等）。
+
+### 备份负载均衡器配置
+
+在灾难恢复时，可用的负载均衡器配置可以加快恢复过程。
+
+### 配置健康检查
+
+让负载均衡器在健康检查失败时自动将节点标记为不可用。例如，NGINX 可以通过以下配置来实现这一功能：
+
+`max_fails=3 fail_timeout=5s`
+
+### 利用外部负载均衡器
+
+避免在管理集群内使用软件负载均衡器。
+
+### 安全访问 Rancher
+
+将防火墙/ACL 规则配置为只允许 Rancher 访问。
+
+## 2. 虚拟机注意事项
+
+### 根据 Rancher 文档确定虚拟机的大小
+
+请参阅[安装要求](../../../getting-started/installation-and-upgrade/installation-requirements/installation-requirements.md)。
+
+### 利用虚拟机模板来构建环境
+
+为了保证跨环境部署的虚拟机的一致性，你可以考虑使用虚拟机模板形式的黄金镜像（golden image）。你可以使用 Packer 来实现，从而增加更多自定义选项。
+
+### 利用 DRS 反亲和规则（可能的话）在 ESXi 主机上分离 Rancher 集群节点
+
+这样可以确保节点虚拟机分布在多台 ESXi 主机上，从而防止主机级别的单点故障。
+
+### 利用 DRS 反亲和规则（可能的话）在 Datastore 上分离 Rancher 集群节点
+
+这样可以确保节点虚拟机分布在多个 Datastore 上，从而防止 Datastore 级别的单点故障。
+
+### 为 Kubernetes 配置合适的虚拟机
+
+在部署节点时，请遵循 K8s 和 etcd 的最佳实践，其中包括禁用 swap，检查集群中的所有主机之间是否有良好的网络连接，为每个节点使用唯一的主机名、MAC 地址和 `product_uuids`。
+
+## 3. 网络注意事项
+
+### 利用 ETCD 节点之间的低延迟和高带宽连接
+
+尽可能在单个数据中心内部署 etcd 成员，来避免延迟开销并减少网络分区的可能性。大多数情况下，1Gb 的连接就足够了。对于大型集群，10Gb 的连接可以缩短恢复备份所需的时间。
+
+### 为虚拟机提供固定的 IP 地址
+
+你可以为使用的所有节点都配置一个静态 IP。如果使用 DHCP，则每个节点都应该有一个 DHCP 预留，以确保节点分配到相同的 IP 地址。
+
+## 4. 存储注意事项
+
+### 在 ETCD 节点上使用 SSD 磁盘
+
+ETCD 对写入延迟非常敏感。因此，你可以尽量使用 SSD 磁盘来提高写入性能。
+
+## 5. 备份和灾难恢复
+
+### 定期备份管理集群
+
+Rancher 将数据存储在它所在的 Kubernetes 集群的 ETCD datastore 中。与其它 Kubernetes 集群一样，你需要对该集群进行频繁且经过测试的备份。
+
+### 备份 Rancher 集群节点虚拟机
+
+将 Rancher 管理节点的虚拟机纳入标准的虚拟机备份策略中。
@@ -0,0 +1,36 @@
+---
+title: Rancher 部署策略
+---
+
+本文提供 Rancher 实例的两种部署策略，用于管理下游 Kubernetes 集群。每种策略都有优缺点。请按照你的实际情况选择最适合的部署策略。
+
+## 中心辐射型策略
+---
+
+在中心辐射型部署中，一个 Rancher 实例就可以管理遍布全球的 Kubernetes 集群。Rancher 实例运行在高可用 Kubernetes 集群上，并且会受延迟影响。
+
+### 优点
+
+* 可以通过一个 controlplane 界面查看所有区域和环境。
+* Kubernetes 不需要 Rancher 进行操作，并且可以容忍与 Rancher 实例断开连接。
+
+### 缺点
+
+* 受限于网络延迟。
+* 如果 Rancher 出现故障，在恢复之前不可以在全球范围内创建新服务。但是每个 Kubernetes 集群都可以继续单独管理。
+
+## 区域型策略
+---
+在区域型部署模型中，Rancher 实例部署在靠近下游 Kubernetes 集群的位置。
+
+### 优点
+
+* 如果某个区域的 Rancher 实例出现故障，其他区域内的 Rancher 功能仍然可以保持正常。
+* Rancher 和下游集群之间的网络延迟大大降低，提高了 Rancher 的性能。
+* 你可以在每个区域内独立升级 Rancher。
+
+### 缺点
+
+* 管理多个 Rancher 安装的开销较大。
+* 需要在多个界面中查看不同区域的 Kubernetes 集群。
+* 在 Rancher 中部署多集群应用时，需要在每个 Rancher Server 中重复部署步骤。
@@ -0,0 +1,21 @@
+---
+title: Rancher Server 的最佳实践
+---
+
+<head>
+  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/zh/reference-guides/best-practices/rancher-server"/>
+</head>
+
+本指南介绍了让 Rancher 管理下游 Kubernetes 集群的 Rancher Server 运行建议。
+
+## 推荐的架构和基础设施
+
+有关在高可用 Kubernetes 集群上设置 Rancher Server 的通用建议，请参见[本指南](tips-for-running-rancher.md)。
+
+## 部署策略
+
+[本指南](rancher-deployment-strategy.md)旨在帮助你选择部署策略（区域部署/中心辐射型部署），来让 Rancher Server 更好地管理下游 Kubernetes 集群。
+
+## 在 vSphere 环境中安装 Rancher
+
+[本指南](on-premises-rancher-in-vsphere.md)介绍了在 vSphere 环境中安装 Rancher 的参考架构，以及 VMware 记录的标准 vSphere 最佳实践。
@@ -0,0 +1,37 @@
+---
+title: Rancher 运行技巧
+---
+
+本指南适用于使用 Rancher 管理下游 Kubernetes 集群的用例。高可用设置可以防止 Rancher Server 不可用时无法访问下游集群。
+
+高可用 Rancher 安装指将 Rancher 安装到至少有三个节点的 Kubernetes 集群上，适用于所有生产环境以及重要的安装场景。在多个节点上运行多个 Rancher 实例能够实现单节点安装无法提供的高可用性。
+
+如果你在 vSphere 环境中安装 Rancher，请参见[最佳实践文档](on-premises-rancher-in-vsphere.md)。
+
+在设置高可用 Rancher 安装时，请考虑以下事项。
+
+## 在单独的集群上运行 Rancher
+
+不要在安装了 Rancher 的 Kubernetes 集群上运行其他工作负载或微服务。
+
+## 确保 Kubernetes 节点配置正确
+
+在部署节点时，请遵循 K8s 和 etcd 的最佳实践，其中包括禁用 swap，检查集群中的所有主机之间是否有良好的网络连接，为每个节点使用唯一的主机名、MAC 地址和 `product_uuids`，检查所需端口是否已经打开，并使用配置 SSD 的 etcd 进行部署。详情请参见 [kubernetes 官方文档](https://kubernetes.io/docs/setup/production-environment/tools/kubeadm/install-kubeadm/#before-you-begin)和 [etcd 性能操作指南](https://etcd.io/docs/v3.5/op-guide/performance/)。
+
+## 在同一个数据中心运行集群中的所有节点
+
+为达到最佳性能，请在同一地理数据中心运行所有三个节点。如果你在云（如 AWS）上运行节点，请在不同的可用区（AZ）中运行这三个节点。例如，在 us-west-2a 中运行节点 1，在 us-west-2b 中运行节点 2，在 us-west-2c 中运行节点 3。
+
+## 保证开发和生产环境的相似性
+
+强烈建议为运行 Rancher 的 Kubernetes 集群配备 “staging” 或 “pre-production” 环境。这个环境的软件和硬件配置应该尽可能接近你的生产环境。
+
+## 监控集群以规划容量
+
+Rancher Server 的 Kubernetes 集群应该尽可能满足[系统和硬件要求](../../../getting-started/installation-and-upgrade/installation-requirements/installation-requirements.md)。越偏离系统和硬件要求，你可能面临的风险就越大。
+
+但是，已发布的要求已经考虑了各种工作负载类型，因此，基于指标来规划容量应该是扩展 Rancher 的最佳实践。
+
+你可以将 Rancher 集成业界领先的开源监控解决方案 Prometheus 以及能可视化 Prometheus 指标的 Grafana，来监控集群节点、Kubernetes 组件和软件部署的状态和过程。
+
+在集群中[启用监控](../../../integrations-in-rancher/monitoring-and-alerting/monitoring-and-alerting.md)后，你可以通过设置告警通知，来了解集群容量的使用情况。你还可以使用 Prometheus 和 Grafana 监控框架，在你扩容时建立关键指标的基线。
@@ -0,0 +1,61 @@
+---
+title: Rancher 扩展技巧
+---
+
+本指南介绍了扩展 Rancher 时应该考虑的方法，以及这样做的难度。随着系统的增长，性能自然会降低，但我们可以采取一些措施来最大限度地减少 Rancher 的负载，并优化 Rancher 处理这些大型设置的能力。
+
+## 优化 Rancher 性能的技巧
+* 建议及时更新 Rancher 的补丁版本。在次要版本的整个生命周期中，我们都会进行性能改进和错误修复。你可以查看发行说明决定是否需要升级，但在大多数情况下，我们建议你使用最新版本。
+
+* 性能会受 Rancher 的基础设施和下游集群的基础设施之间的延迟影响（例如，地理距离）。如果用户需要遍布全球或分布在许多地区的集群/节点，最好使用多个 Rancher。
+
+* 请始终尝试逐渐扩大规模，同时监控和观察变化。通常情况下，性能问题越早解决越好，而且在其他问题出现之前更容易解决。
+
+## 最小化本地集群的负载
+扩展 Rancher 最大的瓶颈是本地 Kubernetes 集群中的资源增长。local 集群包含所有下游集群的信息。下游集群的许多操作将在 local 集群中创建新对象，并需要使用 local 集群中运行的处理程序进行计算。
+
+### 管理对象数量
+ETCD 最终会遇到存储的 Kubernetes 资源数量超过限制的问题。暂时没有这些数字的确切记录。根据内部观察，一旦单个资源类型的对象数量超过 60k（通常是 Rolebindings），就很有可能遇到性能问题。
+
+Rolebindings 是在 local 集群中创建的，是许多操作的结果。
+
+尝试减少 local 集群中的 rolebindings 时需要注意：
+* 仅在必要时将用户添加到集群和项目中
+* 删除不需要的集群和项目
+* 仅在必要时使用自定义角色
+* 在自定义角色中使用尽可能少的规则
+* 考虑给用户添加角色是否多余
+* 使用更少但更强大的集群可能更高效
+* 检查是否能通过创建新项目或新集群为你的用例减少 rolebindings。
+
+### 使用新版应用程序而不是旧版应用程序
+Rancher 使用了两个应用程序 kubernetes 资源，分别是 apps.projects.cattle.io 和 apps.cattle.cattle.io。旧版应用程序 apps.projects.cattle.io 最初是在 Cluster Manager 中引入的，现在已经过时。新版应用程序 apps.catalog.cattle.io 可在其各自集群的 Cluster Explorer 中找到。新版应用程序更受欢迎，因为它们位于下游集群中，而旧版应用程序位于 local 集群中。
+
+我们建议删除 Cluster Manager 中出现的应用程序，如有必要，可以为目标集群替换为 Cluster Explorer 中的应用程序，并仅在集群的 Cluster Explorer 中创建后续的应用程序。
+
+### 使用授权集群端点（ACE）
+Rancher 配置的 RKE1、RKE2 和 K3s 集群有一个 _授权集群端点_ 选项。启用后，会在为集群生成的 kubeconfigs 中添加一个上下文，该上下文使用一个直接到集群的端点，并绕过 Rancher。但是，仅启用此选项是不够的。Kubeconfig 的用户需要使用 `kubectl use-context <ace context name>` 才能开始使用它。
+
+如果不使用 ACE，所有 kubeconfig 请求都会先通过 Rancher 进行路由。
+
+### 实验功能：减少事件处理程序执行的选项
+Rancher 的大部分逻辑都发生在事件处理程序上。每当更新对象以及启动 Rancher 时，这些事件处理程序都会在对象上运行。此外，当缓存同步时，它们每 15 小时会运行一次。在缩放设置中，由于每个处理程序都会在每个适用对象上运行，因此运行这些计划会消耗巨大的性能。但是，你可以使用 `CATTLE_SYNC_ONLY_CHANGED_OBJECTS` 环境变量来禁用处理程序的这些计划执行。如果在大约 15 小时的间隔内看到资源分配峰值，则此设置可能有帮助。
+
+环境变量的值可以是以下选项的逗号分隔列表。这些值指的是控制器的类型（包含和运行处理程序的 struct）及其处理程序。如果将控制器类型添加到变量中，那么该组控制器将无法在重新同步缓存时运行其处理程序。
+
+* `mgmt` 指的是只运行在一个 Rancher 节点上的管理控制器。
+* `user` 指的是为每个集群运行的用户控制器。其中一些运行在与管理控制器相同的节点上，而其他则运行在下游集群中。该选项针对前者。
+* `scaled` 指的是在每个 Rancher 节点上运行的缩放控制器。由于缩放处理程序负责的关键功能，因此不建议设置。
+
+简而言之，如果你发现 CPU 使用率每 15 小时出现一次峰值，请将 `CATTLE_SYNC_ONLY_CHANGED_OBJECTS` 环境变量添加到你的 Rancher 部署中，其值为 `mgmt,user`。
+
+## Rancher 之外的优化
+影响性能的一个重要因素是 local 集群及其配置方式。该集群可能会在 Rancher 运行之前引入瓶颈。当 Rancher 节点出现资源占用过高的情况时，你可以使用 top 命令来判断是 Rancher 还是 Kubernetes 组件在超额消耗资源。
+
+### 保持使用最新版本的 Kubernetes
+与 Rancher 版本类似，我们建议让你的 kubernetes 集群保持使用最新版本。这将确保你的集群能包含可用的性能增强或错误修复。
+
+### 优化 ETCD
+[ETCD 性能](https://etcd.io/docs/v3.5/op-guide/performance/)的两个主要瓶颈是磁盘速度和网络速度。对任何一个进行优化都应该能提高性能。有关 ETCD 性能的信息，请参阅 [etcd 性能慢（性能测试和优化）](https://www.suse.com/support/kb/doc/?id=000020100)和[为大型安装调优 etcd](https://docs.ranchermanager.rancher.io/how-to-guides/advanced-user-guides/tune-etcd-for-large-installs)。有关磁盘的信息，你也可以参阅[我们的文档](https://docs.Ranchermanager.Rancher.io/v2.5/pages-for-subheaders/installation-requirements#disks)。
+
+理论上，ETCD 集群中的节点越多，由于复制要求 [source](https://etcd.io/docs/v3.3/faq)，它就会越慢。这可能与常见的缩放方法相悖。我们还可以推断，ETCD 的性能将受到节点间距离的反面影响，因为这将减慢网络通信。
@@ -0,0 +1,117 @@
+---
+title: Rancher 大规模部署的调优和最佳实践
+---
+
+<head>
+  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/zh/reference-guides/best-practices/rancher-server/tuning-and-best-practices-for-rancher-at-scale"/>
+</head>
+
+本指南介绍了扩容 Rancher 相关场景的最佳实践和调优方法。随着系统规模的不断增长，性能自然会降低，但是可以采取一些步骤将 Rancher 的负载最小化，以优化 Rancher 管理较大基础设施的能力。
+
+## 优化 Rancher 性能
+
+* 及时升级 Rancher 的 Patch 更新。我们会不断的对 Rancher 进行性能增强和错误修复，最新的 Rancher 版本包含了基于开发人员和用户反馈的所有性能和稳定性的优化改进。
+* 逐渐的执行扩容操作，在操作的过程中观察并监控任何变化，在性能刚出现异常时发现问题并修复，避免其他干扰因素。
+* 尽可能地减少上游 Rancher 集群和下游集群之间的网络延时。需要注意的是，排除掉其他因素，延时与地理距离成正比，如果你的集群或节点分布在全球各地，请考虑改为安装多个 Rancher。
+
+## 最小化上游集群的负载
+
+在 Rancher 扩容时，一个典型的性能瓶颈是上游（local）Kubernetes 集群的资源增长。上游集群包含所有下游集群的数据信息，许多对下游集群的操作会在上游集群中创建新的对象，并需要在上游集群中进行计算处理。
+
+### 最大限度地减少上游集群上的第三方软件
+
+大规模运行 Rancher 可能会给内部 Kubernetes 组件（例如 `etcd` 或 `kubeapiserver`）带来大量负载。如果第三方软件干扰了这些组件或 Rancher 的性能，则可能会出现性能问题。
+
+每个第三方软件都存在干扰性能的风险。为了防止上游集群出现性能问题，你应该避免运行除 Kubernetes 系统组件和 Rancher 本身之外的任何应用程序或组件。
+
+以下类别的软件通常不会干扰 Rancher 或 Kubernetes 系统性能：
+ * Rancher 内部组件，例如 Fleet
+ * Rancher 扩展
+ * 集群 API 组件
+ * CNI 网络插件
+ * 云控制器管理器
+ * 观察和监控工具（`prometheus-rancher-exporter` 除外）
+
+除此之外，已发现以下软件会在 Rancher 扩容时影响性能：
+  * [CrossPlane](https://www.crossplane.io/)
+  * [Argo CD](https://argoproj.github.io/cd/)
+  * [Flux](https://fluxcd.io/)
+  * [prometheus-rancher-exporter](https://github.com/David-VTUK/prometheus-rancher-exporter)（请参阅 [issue 33](https://github.com/David-VTUK/prometheus-rancher-exporter/issues/33)）
+
+### 管理你的 Object 计数
+
+Etcd 是 Kubernetes 和 Rancher 的后端数据库，该数据库可能会遇到单个 Kubernetes 资源类型数量的限制，确切的限制因素各不相同，取决于诸多因素。经验表明，一旦单个资源类型的对象数量超过 60000，通常会出现性能问题，通常该资源类型是 RoleBinding 对象。
+
+这在 Rancher 中很常见，因为许多操作会在上游集群中创建新的 RoleBinding 对象。
+
+你可以通过以下方法减少上游集群的 `RoleBinding` 数量：
+* 减少使用 [Restricted Admin（受限管理员）](../../../how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/manage-role-based-access-control-rbac/global-permissions.md#受限管理员) 角色，改为使用其他角色。
+* 如果你使用了 [外部认证](../../../how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/authentication-config/authentication-config.md)，配置其按组分配角色。
+* 仅在必要情况下将用户添加到集群和项目中。
+* 移除不需要的集群和项目。
+* 仅在必要情况下使用自定义角色。
+* 在自定义角色中，尽可能的减少规则数量。
+* 避免为用户添加多余的角色。
+* 考虑使用数量更少，但性能更强大的集群。
+* Kubernetes 权限始终是 “附加”（允许列表）而不是“减去”（拒绝列表）。尽量减少允许访问集群、项目或命名空间等方面的配置，因为这将导致创建大量的 RoleBinding 对象。
+* 实验一下，创建新项目或集群后，在你的特定用例场景是否表现出更少的 RoleBinding 的效果。
+
+### RoleBinding 计数估计
+
+预测给定的配置将创建多少个 RoleBinding 对象很复杂，但是以下注意事项可以提供粗略的估算：
+* 对于最小的数量估计，请使用公式 `32C + U + 2UaC + 8P + 5Pa`。
+   * `C` 是集群数量。
+   * `U` 是用户数量。
+   * `Ua` 是集群中具有成员资格的用户的平均数量。
+   * `P` 是项目总数。
+   * `Pa` 是项目中具有成员资格的平均用户数。
+* 受限管理员角色（Restricted Admin）遵循不同的公式，因为具有此角色的每个用户都会额外产生至少 `7C + 2P + 2` 个 `RoleBinding` 对象。
+* * `RoleBinding` 的数量会随着集群、项目和用户的数量线性增加。
+
+### 使用新的应用代替旧版应用
+
+Rancher 使用两个 Kubernetes 应用程序资源：`apps.projects.cattle.io` 和 `apps.cattle.cattle.io`。以`apps.projects.cattle.io` 为代表的旧版应用程序在低版本的 Cluster Manager UI 中引入，现已弃用。新的应用程序（由 `apps.catalog.cattle.io` 表示）可以在 Cluster Explorer UI 中安装部署。新的 `apps.cattle.cattle.io` 应用程序数据保存在下游集群中，这可以减少上游集群中的资源数量。
+
+你应当删除 Cluster Manager UI 中遗留的所有旧版应用程序，并将其替换为 Cluster Explorer UI 中的应用程序。只在 Cluster Explorer UI 中创建任何新应用程序。
+
+### 使用授权集群端点 (ACE)
+
+[授权集群端点](../../../reference-guides/rancher-manager-architecture/communicating-with-downstream-user-clusters.md#4-授权集群端点) (ACE) 提供了 Rancher 部署的 RKE2 和 K3s 集群的 Kubernetes API 访问。启用后，ACE 会为生成的 `kubeconfig` 文件配置直接访问下游集群 Endpoint，从而绕过 Rancher 代理。在可以直接访问下游集群 Kubernetes API 的场景下，可以减少 Rancher 负载。有关更多信息，请参阅[授权集群端点](../../../reference-guides/rancher-manager-architecture/communicating-with-downstream-user-clusters.md#4-授权集群端点)配置说明。
+
+### 减少 Event Handler 执行
+
+Rancher 的大部分逻辑发生在 Event Handler 上。每当资源对象产生更新或 Rancher 启动时，这些资源对应的 Event Handler 都会执行。除此之外，它们会每隔 15 小时在 Rancher 计划的同步缓存时再运行一次，这可能会导致 Rancher 运行过程中出现大量性能消耗。可使用 `CATTLE_SYNC_ONLY_CHANGED_OBJECTS` 环境变量禁用计划的 Handler 处理程序执行。如果每 15 小时出现一次性能资源高峰，此设置会有所帮助。
+
+`CATTLE_SYNC_ONLY_CHANGED_OBJECTS` 的值可被设置为以下内容，以逗号分隔。这些值代表了处理程序的种类，将处理程序添加到该变量会禁止其在定期的缓存重新同步过程中运行。
+
+* `mgmt`：在 Rancher 节点上运行的 Management 管理控制器。
+* `user`：所有集群运行的用户控制器。其中一部分与 Management 管理控制器运行在同一节点上，而另一部分运行在下游集群中，该选项针对的是前者。
+* `scaled`：每个 Rancher 节点上运行的规模控制器。因规模控制器负责关键功能，应当避免设置此值。如果设置可能会破坏集群稳定。
+
+简而言之，如果你发现 CPU 使用率每 15 小时出现一次峰值，请将 `CATTLE_SYNC_ONLY_CHANGED_OBJECTS` 环境变量添加到 Rancher Deployment 中（添加至 `spec.containers.env` 列表），其值为 `mgmt,user`。
+
+## Rancher 之外的优化
+
+集群底层自身的配置也是影响性能的重要因素。如果上游集群存在错误配置，会带来 Rancher 软件所无法解决的性能瓶颈。
+
+### 使用 RKE2 直接管理上游集群节点
+
+由于 Rancher 对上游集群的要求非常高，尤其是在大规模部署场景，你需要拥有上游集群和节点的所有管理员权限，要找出资源消耗过高的根本原因，请使用标准的 Linux 故障排除工具，这有助于区分是 Rancher、Kubernetes 还是操作系统组件出现的问题。
+
+尽管托管 Kubernetes 服务使部署和运行 Kubernetes 集群变得更加容易，但在大规模场景中，不鼓励将其用于上游集群。 托管 Kubernetes 服务通常会限制对单个节点和服务配置的访问。
+
+建议在大规模用例场景中使用 RKE2 集群。
+
+### 及时更新 Kubernetes 版本
+
+你应当及时更新上游集群的 Kubernetes 版本，以确保你的集群具备最新的性能增强和问题修复。
+
+### 优化 Etcd
+
+Etcd 是 Kubernetes 和 Rancher 的后端数据库，在 Rancher 性能中扮演重要的角色。
+
+[Etcd 性能](https://etcd.io/docs/v3.5/op-guide/performance/)的两个主要瓶颈是磁盘和网络速度。Etcd 应当在具有高速网络和高读写速度 (IOPS) SSD 硬盘的专用节点上运行。有关 etcd 性能的更多信息，请参阅 [etcd 性能缓慢（性能测试和优化）](https://www.suse.com/support/kb/doc/?id=000020100)和[为大型安装进行 etcd 调优](../../../how-to-guides/advanced-user-guides/tune-etcd-for-large-installs.md)。有关磁盘的信息可以在[安装要求](../../../getting-started/installation-and-upgrade/installation-requirements/installation-requirements.md#磁盘)中找到。
+
+根据 etcd 的[复制机制](https://etcd.io/docs/v3.5/faq/#what-is-maximum-cluster-size)，建议在三个节点上运行 etcd，运行在更多的节点上反而会降低速度。
+
+Etcd 性能也会受节点之间的网络延迟影响，因此 etcd 节点应与 Rancher 节点部署在一起。