Adding preview for v2.12 Rancher documentation.

Signed-off-by: Sunil Singh <sunil.singh@suse.com>
2026-05-05 20:53:33 +00:00 · 2025-06-23 14:10:05 -07:00
parent 4def8a407e
commit 8ed7881920
917 changed files with 147322 additions and 0 deletions
@@ -0,0 +1,21 @@
+---
+title: 最佳实践
+---
+
+<head>
+  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/zh/reference-guides/best-practices"/>
+</head>
+
+本节介绍 Rancher 实现的最佳实践，其中包括对 Kubernetes、Docker、容器等技术的使用建议。最佳实践旨在利用 Rancher 及其客户的运营经验，助你更好地实现 Rancher。
+
+如果你对用例的实际应用有任何疑问，请联系客户成功经理或支持中心。
+
+你可以在左侧导航栏快速找到管理和部署 Rancher Server 的最佳实践。
+
+如需查看更多最佳实践指南，请参见：
+
+- [安全类文档](../rancher-security/rancher-security.md)
+- [Rancher 博客](https://www.suse.com/c/rancherblog/)
+- [Rancher 论坛](https://forums.rancher.com/)
+- [Rancher 用户的 Slack 群组](https://slack.rancher.io/)
+- [B 站](https://space.bilibili.com/430496045/)
@@ -0,0 +1,19 @@
+---
+title: Best Practices for Disconnected Clusters
+---
+
+<head>
+  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/reference-guides/best-practices/disconnected-clusters"/>
+</head>
+
+Rancher supports managing clusters that may not always be online due to network disruptions, control plane availability, or because all cluster nodes are down. At the moment there are no known issues with disconnected clusters in the latest released Rancher version.
+
+While a managed cluster is disconnected from Rancher, management operations will be unavailable, and the Rancher UI will not allow navigation to the cluster. However, once the connection is reestablished, functionality is fully restored.
+
+### Best Practices for Managing Disconnected Clusters
+
+- **Cluster Availability During Rancher Upgrades**: It is recommended to have all, or at least most, managed clusters online during a Rancher upgrade. The reason is that upgrading Rancher automatically upgrades the Rancher agent software running on managed clusters. Keeping the agent and Rancher versions aligned ensures consistent functionality. Any clusters that are disconnected during the upgrade will have their agents updated as soon as they reconnect.
+
+- **Cleaning Up Disconnected Clusters**: Regularly remove clusters that will no longer reconnect to Rancher (e.g., clusters that have been decommissioned or destroyed). Keeping such clusters in the Rancher management system consumes unnecessary resources, which could impact Rancher's performance over time.
+
+- **Certificate Rotation Considerations**: When designing processes that involve regularly shutting down clusters, whether connected to Rancher or not, take into account certificate rotation policies. For example, RKE/RKE2/K3s clusters may rotate certificates on startup if they exceeded their lifetime.
@@ -0,0 +1,88 @@
+---
+title: Logging 最佳实践
+---
+
+本指南介绍了集群级别日志和应用日志的最佳实践。
+
+- [集群级别日志](#集群级别日志)
+- [应用日志](#应用日志)
+- [通用最佳实践](#通用最佳实践)
+
+在 Rancher 2.5 之前，Rancher 的 Logging 是一个静态集成。可供选择的聚合器是固定的（包括 ElasticSearch、Splunk、Kafka、Fluentd 和 Syslog），而且只有两个配置级别可供选择（集群级别和项目级别）。
+
+现在，Rancher 的日志聚合更加灵活。通过新的 Logging 的功能，管理员和用户都可以部署符合细粒度收集标准的日志记录，同时提供更多的目标和配置选项。
+
+Rancher Logging 使用的是 [Logging Operator](https://github.com/kube-logging/logging-operator)。我们让你可以管理这个 operator 及其资源，并将它的管理功能和 Rancher 集群管理联系起来。
+
+## 集群级别日志
+
+### 抓取集群内日志
+
+某些用户可能想从集群中运行的每个容器中抓取日志。但是你的安全团队可能要求你从所有执行点收集所有日志。
+
+在这种情况下，我们建议你至少创建两个 _ClusterOutput_ 对象 - 一个用于安全团队（如果需要），另一个用于你自己，即集群管理员。创建这些对象时，请选择一个可以处理整个集群的大量日志的输出端点。此外，你还需要选择合适的索引来接收这些日志。
+
+创建这些 _ClusterOutput_ 对象后，创建一个 _ClusterFlow_ 来收集所有日志。不要在此 flow 上定义任何 _Include_ 或 _Exclude_ 规则。这可以确保你能收集整个集群的所有日志。如果你有两个 _ClusterOutputs_，请确保它们都能收到日志。
+
+### Kubernetes 组件
+
+_ClusterFlows_ 能够收集 Kubernetes 集群中所有主机上所有容器的日志。如果这些容器包含在 Kubernetes Pod 中，这个方法是适用的。但是，RKE 容器不存在于 Kubernetes 内。
+
+目前，Rancher 能搜集 RKE 容器的日志，但不能轻易过滤。这是因为这些日志不包含源容器的信息（例如 `etcd` 或 `kube-apiserver`）。
+
+Rancher 的未来版本将包含源容器名称，来支持过滤这些组件的日志。该功能实现之后，你将能够自定义 _ClusterFlow_ 来**仅**检索 Kubernetes 组件日志，并将日志发送到适当的输出位置。
+
+## 应用日志
+
+对于 Kubernetes 和所有基于容器的应用而言，最佳实践是将应用日志引导到 `stdout`/`stderr`。容器运行时将捕获这些日志并用它们进行**某些操作** - 通常是将它们写入文件。根据容器运行时（及其配置），这些日志可以放置在任意数量的位置。
+
+在将日志写入文件的情况下，Kubernetes 通过在每个主机上创建一个 `/var/log/containers` 目录来提供帮助。这个目录将日志文件符号链接到它们的实际目的地（可能因为配置或容器运行时而有所不同）。
+
+Rancher 的 Logging 将读取 `/var/log/containers` 中的所有日志条目，确保所有容器的所有日志条目（假设使用默认配置）均能被收集和处理。
+
+### 特定日志文件
+
+日志收集仅从 Kubernetes 中的 Pod 中检索 `stdout`/`stderr` 日志。但是，我们也可能想从应用生成的其他文件中收集日志。在这种情况下，你可以使用一个（或两个）日志流 Sidecar。
+
+设置日志流 Sidecar 的目的是获取写入磁盘的日志文件，并将其内容传输到 `stdout`。这样一来，Logging Operator 就可以接收这些日志，并把日志发送到目标输出位置。
+
+要进行设置，编辑你的工作负载资源（例如 Deployment）并添加以下 Sidecar 定义：
+
+```yaml
+...
+containers:
+- args:
+  - -F
+  - /path/to/your/log/file.log
+  command:
+  - tail
+  image: busybox
+  name: stream-log-file-[name]
+  volumeMounts:
+  - mountPath: /path/to/your/log
+    name: mounted-log
+...
+```
+
+这将添加一个容器到你的工作负载定义中，用于将 `/path/to/your/log/file.log` 的内容（在本示例中）传输到 `stdout`。
+
+然后将根据你设置的 _Flows_ 或 _ClusterFlows_ 自动收集该日志流。你还可以通过使用容器的名称，专门为该日志文件创建一个 _Flow_。示例如下：
+
+```yaml
+...
+spec:
+  match:
+  - select:
+      container_names:
+      - stream-log-file-name
+...
+```
+
+
+## 通用最佳实践
+
+- 尽量输出结构化日志条目（例如 `syslog`、JSON）。这些格式已经有了解析器，因此你可以更轻松地处理日志条目。
+- 尽量在日志条目内提供创建该日志条目的应用的名称。这可以使故障排除更容易。这是因为 Kubernetes 并不总是将应用的名称作为对象名称。例如，某个 Pod ID 可能是 `myapp-098kjhsdf098sdf98`，从这个 ID 中我们不能获取运行在容器内的应用的太多信息。
+- 除了在集群范围内收集所有日志的情况外，尽量严格限定 _Flow_ 和 _ClusterFlow_ 对象的范围。这使得在出现问题时更容易进行故障排除，并且还有助于确保不相关的日志条目不会出现在你的聚合器中。严格限定范围的一个例子是将 _Flow_ 限制在命名空间中的单个 _Deployment_，甚至是 _Pod_ 中的单个容器。
+- 除非要进行故障排除，否则不要让日志太详细。太详细的日志会带来许多问题，其中最主要的是**带来干扰**，即重要事件可能会淹没在海量 `DEBUG` 信息中。你可以通过使用自动告警和脚本来缓解这种问题，但太详细的日志仍然给日志管理基础设施带来过大的压力。
+- 如果可能，尽量在日志条目中提供事务或请求 ID。这可以使跨日志源追踪应用活动变得更容易，尤其是在处理分布式应用时。
@@ -0,0 +1,111 @@
+---
+title: 监控最佳实践
+---
+
+配置合理的监控和告警规则对于安全、可靠地运行生产环境中的工作负载至关重要。在使用 Kubernetes 和 Rancher 时也是如此。幸运的是，你可以使用集成的监控和告警功能来简化整个过程。
+
+[Rancher 监控文档](../../../integrations-in-rancher/monitoring-and-alerting/monitoring-and-alerting.md)描述了如何设置完整的 Prometheus 和 Grafana。这是开箱即用的功能，它将从集群中的所有系统和 Kubernetes 组件中抓取监控数据，并提供合理的仪表板和告警。但为了实现可靠的设置，你还需要监控你的工作负载并使 Prometheus 和 Grafana 适应你的特定用例和集群规模。本文档将为你提供这方面的最佳实践。
+
+## 监控内容
+
+Kubernetes 本身以及运行在其内部的应用构成了一个分布式系统，不同的组件之间能够进行交互。对于整个系统和每个单独的组件，你必须确保其性能、可用性、可靠性和可扩展性。详情请参见 Google 免费的 [Site Reliability Engineering Book](https://sre.google/sre-book/table-of-contents/)，尤其是关于 [Monitoring distributed systems](https://sre.google/sre-book/monitoring-distributed-systems/) 的章节。
+
+## 配置 Prometheus 资源使用
+
+在安装集成监控时，Rancher 允许进行一些配置，这些配置取决于你的集群规模和其中运行的工作负载。本章将更详细地介绍这些内容。
+
+### 存储和数据保留
+
+Prometheus 所需的存储空间取决于你存储的时间序列和标签的数量，以及你配置的数据保留量。需要注意的是，Prometheus 并不是用来长期存储指标的。数据通常只保留几天，而不是几周或几个月。这是因为 Prometheus 不会对存储的指标进行任何聚合。不聚合的好处是避免稀释数据，但这也意味着不设置保留时长的话，所需的存储空间随着时间的推移线性增长。
+
+以下是计算所需存储空间的一种方法。首先，通过以下查询来查看 Prometheus 中存储块的平均大小：
+
+```
+rate(prometheus_tsdb_compaction_chunk_size_bytes_sum[1h]) / rate(prometheus_tsdb_compaction_chunk_samples_sum[1h])
+```
+
+接下来，找出每秒的数据引入速率：
+
+```
+rate(prometheus_tsdb_head_samples_appended_total[1h])
+```
+
+然后与保留时间相乘，并添加几个百分点作为缓冲区：
+
+```
+平均块大小（以字节为单位）x 每秒的数据引入速率 x 保留时间（以秒为单位）x 1.1 = 必需的存储空间（以字节为单位）
+```
+
+你可以访问[这篇博客](https://www.robustperception.io/how-much-disk-space-do-prometheus-blocks-use)了解关于如何计算必须的存储空间的更多信息。
+
+你可以参见 [Prometheus 官方文档](https://prometheus.io/docs/prometheus/latest/storage)来进一步了解 Prometheus 的存储概念。
+
+### CPU 和内存的请求和限制
+
+在较大的 Kubernetes 集群中，Prometheus 会消耗大量内存。Prometheus 需要的内存与它存储的时间序列和标签的数量以及抓取间隔有关。
+
+你可以访问[这篇博客](https://www.robustperception.io/how-much-ram-does-prometheus-2-x-need-for-cardinality-and-ingestion)了解关于如何计算必须的内存的更多信息。
+
+所需的 CPU 数量与你正在执行的查询数量相关。
+
+### 长期储存
+
+Prometheus 不是用于长期存储指标的，它只用于短期存储。
+
+如果想要长时间存储部分或全部指标，你可以利用 Prometheus 的[远程读/写](https://prometheus.io/docs/prometheus/latest/storage/#remote-storage-integrations)功能将其连接到 [Thanos](https://thanos.io/)，[InfluxDB](https://www.influxdata.com/) 或 [M3DB](https://www.m3db.io/) 等存储系统。你可以访问[这篇博客](https://rancher.com/blog/2020/prometheus-metric-federation)找到设置示例。
+
+## 抓取自定义工作负载
+
+虽然集成的 Rancher Monitoring 已经可以从集群的节点和系统组件中抓取系统指标，但你也需要为部署在 Kubernetes 上的自定义工作负载抓取数据。为此，你可以配置 Prometheus，让它在一定的时间间隔内对你应用的端点进行 HTTP 请求。然后，这些端点会以 Prometheus 格式返回指标。
+
+一般来说，你会从集群中运行的所有工作负载中抓取数据，然后将数据用于告警或调试问题。一般情况下，你只有在具体事件发生后才需要某些指标数据。如果数据已经被抓取并存储了，那就好办了。由于 Prometheus 只是短期存储指标，因此抓取和存储大量数据的成本并不是那么高。如果你使用的是 Prometheus 的长期存储方案，那么你也可以决定持久存储哪些数据。
+
+### 关于 Prometheus Exporters
+
+许多第三方工作负载（如数据库、队列或 Web 服务器）要么已经支持以 Prometheus 格式公开指标，要么有所谓的 exporter，来对工具的指标格式和 Prometheus 理解的指标格式进行转换。通常，你可以将这些 exporter 作为额外的 Sidecar 容器添加到工作负载的 Pod 中。很多 Helm Chart 已经包含了部署 exporter 的选项。此外，你还可以在 [ExporterHub](https://exporterhub.io/) 上找到一个策划的 exporter 列表。
+
+### Prometheus 的编程语言和框架支持
+
+要想把你的自定义应用指标放到 Prometheus 中，你必须直接从你的应用代码中收集和暴露这些指标。幸运的是，对于大多数流行的编程语言和框架来说，已经有一些库和集成来帮助解决这个问题。其中一个例子是 [Spring 框架](https://docs.spring.io/spring-metrics/docs/current/public/prometheus)中的 Prometheus 支持。
+
+### ServiceMonitor 和 PodMonitor
+
+一旦所有工作负载都以 Prometheus 格式公开了指标后，你必须配置 Prometheus 来抓取数据。Rancher 使用 [prometheus-operator](https://github.com/prometheus-operator/prometheus-operator)，这使得使用 ServiceMonitors 和 PodMonitors 来添加其他抓取目标变得容易。很多 Helm Chart 已经包含直接创建这些监控器的选项。你也可以在 Rancher 文档中找到更多信息。
+
+### Prometheus 推送网关（Pushgateway）
+
+有些工作负载的指标很难被 Prometheus 抓取，就像 Jobs 和 CronJobs 这样的短期工作负载，或者是不允许在单个处理的传入请求之间共享数据的应用，如 PHP 应用。
+
+要想获得这些用例的指标，你可以设置 [prometheus-pushgateways](https://github.com/prometheus/pushgateway)。CronJob 或 PHP 应用将把指标更新推送到 pushgateway。pushgateway 汇总并通过 HTTP 端点暴露它们，然后可以由 Prometheus 抓取。
+
+### Prometheus Blackbox 监控
+
+有时，你可能需要从外部监控工作负载。为此，你可以使用 [Prometheus blackbox-exporter](https://github.com/prometheus/blackbox_exporter)，它允许通过 HTTP、HTTPS、DNS、TCP 和 ICMP 探测任何类型的端点。
+
+## 在（微）服务架构中进行监控
+
+如果你有一个（微）服务架构，在该架构中集群的多个单独的工作负载相互通信，那么拥有这些流量的详细指标和跟踪是非常重要的，因为这可以帮助你了解所有这些工作负载之间的通信方式，以及问题或瓶颈可能出现的地方。
+
+当然，你可以监控所有工作负载中的所有内部流量，并将这些指标暴露给 Prometheus，但这相当耗费精力。像 Istio 这样的服务网格（可以通过[单击](../../../integrations-in-rancher/istio/istio.md)在 Rancher 中安装）可以自动完成这项工作，并提供所有 Service 之间流量的丰富的遥测数据。
+
+## 真实用户监控
+
+监控所有内部工作负载的可用性和性能对于稳定、可靠和快速地运行应用至关重要。但这些指标只能向你展示部分情况。要想获得一个完整的视图，还必须知道你的最终用户是如何实际感知的。为此，你可以研究各种[真实用户监控解决方案](https://en.wikipedia.org/wiki/Real_user_monitoring)。
+
+## 安全监控
+
+除了通过监控工作负载来检测性能、可用性或可扩展性之外，你还应该监控集群和运行在集群中的工作负载，来发现潜在的安全问题。一个好的做法是经常运行 [CIS 扫描](../../../how-to-guides/advanced-user-guides/cis-scan-guides/cis-scan-guides.md)并发出告警，来检查集群是否按照安全最佳实践进行配置。
+
+对于工作负载，你可以查看 Kubernetes 和 Container 安全解决方案，例如 [NeuVector](https://www.suse.com/products/neuvector/)、[Falco](https://falco.org/)、[Aqua Kubernetes Security](https://www.aquasec.com/solutions/kubernetes-container-security/) 和 [SysDig](https://sysdig.com/)。
+
+## 设置告警
+
+将所有的指标纳入监控系统并在仪表板中可视化是很好的做法，但你也希望在出现问题时能主动收到提醒。
+
+集成的 Rancher 监控已经配置了一套合理的告警，这些告警在任何 Kubernetes 集群中都是可用的。你可以扩展告警，来覆盖特定的工作负载和用例。
+
+在设置告警时，你需要为对你应用非常关键的工作负载配置告警，但同时也要确保告警不会太频繁。理想情况下，你收到的每一个告警都应该是一个你需要关注并解决的问题。如果你一直收到不太关键的告警，你就有可能开始完全忽略告警信息，然后错过真正重要的告警。因此，少量的告警可能会更好。首先，你可以关注真正重要的指标，例如应用离线等。之后，解决出现的所有问题，然后再创建更详细的告警。
+
+如果告警开始发送，但你暂时无法处理，你也可以将告警静默一定时间，以便以后查看。
+
+如果需要了解更多关于如何设置告警和通知通道的信息，请访问 [Rancher 文档中心](../../../integrations-in-rancher/monitoring-and-alerting/monitoring-and-alerting.md)。
@@ -0,0 +1,58 @@
+---
+title: Rancher 管理 vSphere 集群的最佳实践
+---
+
+本指南概述了在 vSphere 环境中配置下游 Rancher 集群的参考架构，以及 VMware 记录的标准 vSphere 最佳实践。
+
+- [1. 虚拟机注意事项](#1-虚拟机注意事项)
+- [2. 网络注意事项](#2-网络注意事项)
+- [3. 存储注意事项](#3-存储注意事项)
+- [4. 备份和灾难恢复](#4-备份和灾难恢复)
+
+<figcaption>解决方案概述</figcaption>
+
+![解决方案概述](/img/solution_overview.drawio.svg)
+
+## 1. 虚拟机注意事项
+
+### 利用虚拟机模板来构建环境
+
+为了保证跨环境部署的虚拟机的一致性，你可以考虑使用虚拟机模板形式的黄金镜像（golden image）。你可以使用 Packer 来实现，从而增加更多自定义选项。
+
+### 利用 DRS 反亲和规则（可能的话）在 ESXi 主机上分离下游集群节点
+
+这样可以确保节点虚拟机分布在多台 ESXi 主机上，从而防止主机级别的单点故障。
+
+### 利用 DRS 反亲和规则（可能的话）在 Datastore 上分离下游集群节点
+
+这样可以确保节点虚拟机分布在多个 Datastore 上，从而防止 Datastore 级别的单点故障。
+
+### 为 Kubernetes 配置合适的虚拟机
+
+在部署节点时，请遵循 K8s 和 etcd 的最佳实践，其中包括禁用 swap，检查集群中的所有主机之间是否有良好的网络连接，为每个节点使用唯一的主机名、MAC 地址和 `product_uuids`。
+
+## 2. 网络注意事项
+
+### 利用 ETCD 节点之间的低延迟和高带宽连接
+
+尽可能在单个数据中心内部署 etcd 成员，来避免延迟开销并减少网络分区的可能性。大多数情况下，1Gb 的连接就足够了。对于大型集群，10Gb 的连接可以缩短恢复备份所需的时间。
+
+### 为虚拟机提供固定的 IP 地址
+
+你可以为使用的所有节点都配置一个静态 IP。如果使用 DHCP，则每个节点都应该有一个 DHCP 预留，以确保节点分配到相同的 IP 地址。
+
+## 3. 存储注意事项
+
+### 在 ETCD 节点上使用 SSD 磁盘
+
+ETCD 对写入延迟非常敏感。因此，你可以尽量使用 SSD 磁盘来提高写入性能。
+
+## 4. 备份和灾难恢复
+
+### 定期备份下游集群
+
+Kubernetes 使用 etcd 来存储其所有数据，包括配置、状态和元数据。在灾难恢复的情况下，备份这些数据是至关重要的。
+
+### 备份下游节点虚拟机
+
+将 Rancher 下游节点的虚拟机纳入标准的虚拟机备份策略中。
@@ -0,0 +1,27 @@
+---
+title: Rancher 管理集群的最佳实践
+---
+
+<head>
+  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/zh/reference-guides/best-practices/rancher-managed-clusters"/>
+</head>
+
+## Logging
+
+有关集群级别日志和应用日志的建议，请参见 [Logging 最佳实践](logging-best-practices.md)。
+
+## Monitoring
+
+配置合理的监控和告警规则对于安全、可靠地运行生产环境中的工作负载至关重要。有关更多建议，请参阅[最佳实践](monitoring-best-practices.md)。
+
+### Disconnected clusters
+
+Rancher supports managing clusters that may not always be online due to network disruptions, control plane availability, or because all cluster nodes are down. Refer to this [guide](disconnected-clusters.md) for our recommendations.
+
+## 设置容器的技巧
+
+配置良好的容器可以极大地提高环境的整体性能和安全性。有关容器设置的建议，请参见[设置容器的技巧](tips-to-set-up-containers.md)。
+
+## Rancher 管理 vSphere 集群的最佳实践
+
+[Rancher 管理 vSphere 集群的最佳实践](rancher-managed-clusters-in-vsphere.md)概述了在 vSphere 环境中配置下游 Rancher 集群的参考架构，以及 VMware 记录的标准 vSphere 最佳实践。
@@ -0,0 +1,57 @@
+---
+title: 设置容器的技巧
+---
+
+配置良好的容器可以极大地提高环境的整体性能和安全性。
+
+本文介绍一些设置容器的技巧。
+
+如果你需要了解容器安全的详细信息，也可以参见 Rancher 的[容器安全指南](https://rancher.com/complete-guide-container-security)。
+
+## 使用通用容器操作系统
+
+在可能的情况下，你应该尽量在通用的容器基础操作系统上进行标准化。
+
+Alpine 和 BusyBox 等较小的发行版减少了容器镜像的大小，并且通常具有较小的漏洞。
+
+流行的发行版如 Ubuntu、Fedora 和 CentOS 等都经过了大量的测试，并提供了更多的功能。
+
+## 使用 From scratch 容器
+
+如果你的微服务是一个独立的静态二进制，你应该使用 `From scratch` 容器。
+
+`FROM scratch` 容器是一个[官方 Docker 镜像](https://hub.docker.com/_/scratch)，它是空的，这样你就可以用它来设计最小的镜像。
+
+这个镜像这将具有最小的攻击层和最小的镜像大小。
+
+## 以非特权方式运行容器进程
+
+在可能的情况下，在容器内运行进程时使用非特权用户。虽然容器运行时提供了隔离，但仍然可能存在漏洞和攻击。如果容器以 root 身份运行，无意中或意外的主机挂载也会受到影响。有关为 Pod 或容器配置安全上下文的详细信息，请参见 [Kubernetes 文档](https://kubernetes.io/docs/tasks/configure-pod-container/security-context/)。
+
+## 定义资源限制
+
+你应该将 CPU 和内存限制应用到你的 Pod 上。这可以帮助管理 worker 节点上的资源，并避免发生故障的微服务影响其他微服务。
+
+在标准 Kubernetes 中，你可以设置命名空间级别的资源限制。在 Rancher 中，你可以设置项目级别的资源限制，项目内的所有命名空间都会继承这些限制。详情请参见 Rancher 官方文档。
+
+在设置资源配额时，如果你在项目或命名空间上设置了任何与 CPU 或内存相关的内容（即限制或预留），所有容器都需要在创建期间设置各自的 CPU 或内存字段。为了避免在创建工作负载期间对每个容器设置这些限制，可以在命名空间上指定一个默认的容器资源限制。
+
+有关如何在[容器级别](https://kubernetes.io/docs/concepts/configuration/manage-compute-resources-container/#resource-requests-and-limits-of-pod-and-container)和命名空间级别设置资源限制的更多信息，请参见 Kubernetes 文档。
+
+## 定义资源需求
+
+你应该将 CPU 和内存要求应用到你的 Pod 上。这对于通知调度器需要将你的 pod 放置在哪种类型的计算节点上，并确保它不会过度配置该节点资源至关重要。在 Kubernetes 中，你可以通过在 pod 的容器规范的资源请求字段中定义 `resources.requests` 来设置资源需求。详情请参见 [Kubernetes 文档](https://kubernetes.io/docs/concepts/configuration/manage-compute-resources-container/#resource-requests-and-limits-of-pod-and-container)。
+
+:::note
+
+如果你为 pod 所部署的命名空间设置了资源限制，而容器没有特定的资源请求，则不允许启动 pod。为了避免在创建工作负载期间对每个容器设置这些字段，可以在命名空间上指定一个默认的容器资源限制。
+
+:::
+
+建议在容器级别上定义资源需求，否则，调度器会认为集群加载对你的应用没有帮助。
+
+## 配置存活和就绪探测器
+
+你可以为你的容器配置存活探测器和就绪探测器。如果你的容器不是完全崩溃，Kubernetes 是不会知道它是不健康的，除非你创建一个可以报告容器状态的端点或机制。或者，确保你的容器在不健康的情况下停止并崩溃。
+
+Kubernetes 文档展示了如何[为容器配置存活和就绪探测器](https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-probes/)。
@@ -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,41 @@
+---
+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/)。
+
+## 使用 RKE 时：备份状态文件（Statefile）
+
+RKE 将集群状态记录在一个名为 `cluster.rkestate` 的文件中，该文件对集群的恢复和/或通过 RKE 维护集群非常重要。由于这个文件包含证书材料，我们强烈建议在备份前对该文件进行加密。请在每次运行 `rke up` 后备份状态文件。
+
+## 在同一个数据中心运行集群中的所有节点
+
+为达到最佳性能，请在同一地理数据中心运行所有三个节点。如果你在云（如 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 部署的 RKE、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 节点部署在一起。