mirror of
https://github.com/rancher/rancher-docs.git
synced 2026-05-05 04:33:18 +00:00
Add version-2.7 docs
This commit is contained in:
Billy Tat
+84
@@ -0,0 +1,84 @@
|
||||
---
|
||||
title: 在 vSphere 环境中安装 Rancher
|
||||
---
|
||||
|
||||
本指南概述了在 vSphere 环境中在 RKE Kubernetes 集群上安装 Rancher 的参考架构，以及 VMware 记录的标准 vSphere 最佳实践。
|
||||
|
||||
|
||||
<figcaption>解决方案概述</figcaption>
|
||||
|
||||
|
||||
|
||||
## 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 管理节点的虚拟机纳入标准的虚拟机备份策略中。
|
||||
+39
@@ -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 中重复部署步骤。
|
||||
+36
@@ -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 监控框架，在你扩容时建立关键指标的基线。
|
||||
|
||||
+61
@@ -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 的性能将受到节点间距离的反面影响，因为这将减慢网络通信。
|
||||
Reference in New Issue
Block a user