|
本文档采用自动化机器翻译技术翻译。 尽管我们力求提供准确的译文，但不对翻译内容的完整性、准确性或可靠性作出任何保证。 若出现任何内容不一致情况，请以原始 英文 版本为准，且原始英文版本为权威文本。 |
在大规模下的调优与SUSE Rancher Prime最佳实践
本指南描述了扩展Rancher设置的最佳实践和调优方法，以及由此带来的相关挑战。随着系统的增长，性能自然会下降，但可以采取一些措施来减少对Rancher的负载，并优化Rancher管理更大基础设施的能力。
优化Rancher性能
-
保持Rancher为最新补丁版本。我们不断通过性能增强和Bug 修复来改进Rancher。最新的Rancher版本包含所有累积的性能和稳定性改进，以及基于开发者经验和用户反馈的更新。
-
始终逐步扩展，并在此过程中监控和观察任何行为变化。通常，尽早解决性能问题会更容易，最好在其他问题掩盖根本原因之前进行。
-
尽可能减少上游Rancher集群与下游集群之间的网络延迟。请注意，延迟是多种因素的函数，其中包括地理距离——如果您需要在全球范围内部署集群或节点，请考虑多个Rancher安装。
减少上游集群的负载
在扩展Rancher时，一个典型的瓶颈是上游（本地）Kubernetes集群中的资源增长。上游集群包含所有下游集群的信息。许多适用于下游集群的操作会在上游集群中创建新对象，并需要上游集群中运行的处理程序进行计算。
减少上游集群中的第三方软件
在高规模环境中，一般Rancher建议中概述的建议尤为重要。
管理您的对象计数
Etcd是Kubernetes和Rancher的后端数据库。数据库最终可能会遇到存储单个Kubernetes资源类型的数量限制。确切的限制因多种因素而异。然而，经验表明，一旦单个资源类型的对象数量超过60,000，性能问题往往会出现。通常该类型是`RoleBinding`。
在Rancher中这是典型的，因为许多操作会在上游集群中作为副作用创建新的`RoleBinding`对象。
您可以通过以下方式减少上游集群中的`RoleBindings`数量：
-
仅在必要时向集群和项目添加用户。
-
当集群和项目不再需要时，请将其去除。
-
仅在必要时使用自定义角色。
-
在自定义角色中尽可能少地使用规则。
-
考虑将角色添加到用户是否冗余。
-
考虑使用更少但更强大的集群。
-
Kubernetes权限始终是"累加的"（允许列表），而不是"减法的"（拒绝列表）。尽量减少配置，这些配置允许访问集群、项目或命名空间的所有方面，除了一个，因为这将导致创建大量`RoleBinding`对象。
-
尝试查看在您的特定用例中，创建新项目或集群是否会减少`RoleBindings`。
使用外部身份验证
如果您有五十个或更多用户，您应该配置一个外部身份验证提供者。这对于更好的性能是必要的。
在配置外部身份验证后，请确保将权限分配给组，而不是单个用户。这有助于减少`RoleBinding`对象的数量。
角色绑定计数估算
预测给定配置将创建多少个`RoleBinding`对象是复杂的。然而，以下考虑因素可以提供一个粗略的估算：
-
对于最小估算，请使用公式`32C + U + 2UaC + 8P + 5Pa`。
-
`C`是集群的总数。
-
`U`是用户的总数。
-
`Ua`是每个集群中拥有会员资格的用户的平均数量。
-
`P`是项目的总数。
-
`Pa`是每个项目中拥有会员资格的用户的平均数量。
-
-
`RoleBindings`的数量随着集群、项目和用户的数量线性增加。
使用新APP替代旧APP
Rancher使用两个Kubernetes APP资源：apps.projects.cattle.io`和`apps.cattle.cattle.io。旧APP，由`apps.projects.cattle.io`表示，是通过以前的集群管理UI引入的，现在已经过时。当前APP，由`apps.catalog.cattle.io`表示，可以在各自集群的Cluster Explorer UI中找到。Apps.cattle.cattle.io APP更可取，因为它们的数据位于下游集群中，从而释放了上游集群的资源。
您应该去除在集群管理UI中出现的任何剩余旧APP，并用Cluster Explorer UI中的APP替换它们。仅在Cluster Explorer UI中创建任何新APP。
减少事件处理程序执行
Rancher的大部分逻辑发生在事件处理程序上。这些事件处理程序在对象更新时以及Rancher启动时运行。此外，它们在Rancher同步缓存时每10小时运行一次。在扩展的设置中，这些计划运行会带来巨大的性能成本，因为每个处理程序都在每个适用的对象上运行。然而，可以通过`CATTLE_SYNC_ONLY_CHANGED_OBJECTS`环境变量禁用计划的处理程序执行。如果每10小时出现资源分配峰值，此设置可能会有所帮助。
`CATTLE_SYNC_ONLY_CHANGED_OBJECTS`的值可以是以下选项的逗号分隔列表。这些值指的是处理程序和控制器的类型（包含和运行处理程序的结构）。将控制器类型添加到变量中会禁用该组控制器作为缓存重新同步的一部分运行其处理程序。
-
`mgmt`指的是仅在一个Rancher节点上运行的管理控制器。
-
`user`指的是为每个集群运行的用户控制器。其中一些在与管理控制器相同的节点上运行，而其他则在下游集群中运行。此选项针对前者。
-
`scaled`指的是在每个Rancher节点上运行的扩展控制器。您应该避免设置此值，因为扩展处理程序负责关键功能，变更可能会破坏集群稳定性。
简而言之，如果您注意到每10小时处理器使用率峰值，请将`CATTLE_SYNC_ONLY_CHANGED_OBJECTS`环境变量添加到您的Rancher部署中（在`spec.containers.env`列表中），值为`mgmt,user`。
Rancher外部的优化
重要的影响因素是底层集群自身的性能和配置。如果上游集群配置错误，可能会引入瓶颈，而Rancher软件无法解决。
使用SUSE® Rancher Prime: RKE2直接管理上游集群节点。
由于Rancher对上游集群的要求很高，尤其是在大规模情况下，您应该对集群的配置和节点拥有完全的管理控制。要识别资源消耗过多的根本原因，请使用标准的Linux故障排除技术和工具。这有助于区分是Rancher、Kubernetes还是操作系统组件导致的问题。
尽管托管的Kubernetes服务使得部署和运行Kubernetes集群变得更容易，但在大规模场景中不建议使用它们作为上游集群。托管的Kubernetes服务通常限制对单个节点和服务的配置和洞察的访问。
在大规模用例中使用RKE2。
保持所有上游集群节点共址。
为了提供高可用性，Kubernetes被设计为在不同区域运行节点和控制组件。然而，如果节点和控制平面组件位于不同区域，网络流量可能会变慢。
Rancher组件与Kubernetes API之间的流量对网络延迟特别敏感，节点之间的etcd流量也是如此。
为了提高性能，请在同一位置运行所有上游节点集群。特别是，确保etcd节点与Rancher之间的延迟尽可能低。
优化etcd。
Etcd是Kubernetes和Rancher的后端数据库。它在Rancher性能中扮演着非常重要的角色。
对 etcd性能的两个主要瓶颈是磁盘和网络速度。Etcd应该在专用节点上运行，配备快速的网络设置和具有高输入/输出操作每秒（IOPS）的SSD。有关etcd性能的更多信息，请参见 慢速etcd性能（性能测试和优化）和为大型安装调整etcd。有关磁盘的信息也可以在安装要求中找到。
最好在恰好三个节点上运行etcd，因为添加更多节点会降低操作速度。这可能与常见的扩展方法相悖，但这是由于etcd的 复制机制。
etcd性能还会受到节点之间网络延迟的负面影响，因为这会减慢网络通信。etcd节点应与Rancher节点一起放置。