Add version-2.7 docs

2026-05-05 04:33:18 +00:00 · 2023-06-05 10:54:11 -07:00
parent ae741d3b8b
commit 754bfdcab5
868 changed files with 136645 additions and 0 deletions
@@ -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 监控文档](../../../pages-for-subheaders/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 的选项。此外，你还可以在 [promcat.io](https://promcat.io/) 和 [ExporterHub](https://exporterhub.io/) 上找到一个由 SysDig 策划的 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 这样的服务网格（可以通过[单击](https://rancher.com/docs/rancher/v2.6/en/istio/)在 Rancher 中安装）可以自动完成这项工作，并提供所有 Service 之间流量的丰富的遥测数据。
+
+## 真实用户监控
+
+监控所有内部工作负载的可用性和性能对于稳定、可靠和快速地运行应用至关重要。但这些指标只能向你展示部分情况。要想获得一个完整的视图，还必须知道你的最终用户是如何实际感知的。为此，你可以研究各种[真实用户监控解决方案](https://en.wikipedia.org/wiki/Real_user_monitoring)。
+
+## 安全监控
+
+除了通过监控工作负载来检测性能、可用性或可扩展性之外，你还应该监控集群和运行在集群中的工作负载，来发现潜在的安全问题。一个好的做法是经常运行 [CIS 扫描](../../../pages-for-subheaders/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 文档中心](../../../pages-for-subheaders/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,52 @@
+---
+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 文档确定虚拟机的大小
+
+请参阅[安装要求](../../../pages-for-subheaders/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,39 @@
+---
+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,36 @@
+---
+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.4/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 集群应该尽可能满足[系统和硬件要求](../../../pages-for-subheaders/installation-requirements.md)。越偏离系统和硬件要求，你可能面临的风险就越大。
+
+但是，已发布的要求已经考虑了各种工作负载类型，因此，基于指标来规划容量应该是扩展 Rancher 的最佳实践。
+
+你可以将 Rancher 集成业界领先的开源监控解决方案 Prometheus 以及能可视化 Prometheus 指标的 Grafana，来监控集群节点、Kubernetes 组件和软件部署的状态和过程。
+
+在集群中[启用监控](../../../pages-for-subheaders/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.4/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 的性能将受到节点间距离的反面影响，因为这将减慢网络通信。