多节点架构和设计注意事项

使用 Kubernetes 在 Linux 上运行的 Automation Suite 的多节点架构和设计注意事项。

以下架构图描述了在 Linux 上部署 Automation Suite，其中 Kubernetes 安装在六台计算机上，并设有一个负载均衡器和数据存储。有多种计算机类型：三种服务器节点、两种代理节点和一种专用代理节点。

服务器节点

服务器节点托管Kubernetes 控制平面，该控制平面控制整个 Kubernetes 集群。在典型的多节点部署中，需要奇数个服务器节点，最少服务器数量为三个。此限制是由于etcd组件所致，该组件是 Kubernetes 控制平面的一部分。有关详细信息，请参阅《etcd 文档》 。

出于同样的原因，大多数服务器节点必须在任何时候都可用，以保持集群的正常运行。

这些节点还在节点上托管需要数据存储的组件，例如 Prometheus、集群内对象存储 Ceph、UiPath Insights 和集群内 Docker 注册表。

代理节点

代理节点有时称为工作器节点。这些节点旨在托管 UiPath™ 服务和其他共享套件功能。由于没有数据磁盘连接到这些节点，因此它们无法托管需要磁盘存储的组件。

代理节点不对在任何时间点可用的节点数量施加任何限制。只要生成的集群有足够的容量来托管丢失节点中的所有 Pod，集群就会按预期工作，而不会出现任何中断。

专用代理节点

这些节点是专用于特殊任务的特殊代理节点，例如用于机器人执行的 Automation Suite 机器人节点和用于 Document Understanding 模型的 GPU 节点。您不能在这些节点上托管其他 UiPath™ 服务。

Load balancer

负载均衡器安装在 Automation Suite 外部，可用作访问 Automation Suite 集群上托管的应用程序的入口点。负载均衡器必须能够承受节点容错。需要在负载均衡器上配置所有服务器节点，但也可以选择配置代理节点。但是，专门的代理节点不是必需的。

当机器人尝试访问 Orchestrator 时，调用到达负载均衡器，然后传递到任何可用节点。每个节点还托管名为 Istio 的网络组件，这是一个服务网格，也充当负载均衡器。当节点上运行的 Istio 收到调用时，它会尝试在整个集群上找到 Orchestrator 实例。找到后，它会将调用重定向到该实例。

如何设计部署

是使用更多小型计算机，还是减少大型计算机？

是否要使用更多的小型计算机或更少的大型计算机，完全取决于您，这两个选项都有各自的优点和缺点。与较少数量的大型计算机相比，较多的小型计算机可提供更好的节点容错能力。同时，它也带来了额外的管理开销。

例如，如果您的 Automation Suite 集群需要 96 个 vCPU，则可以选择以下任一选项：

• 选项 1：6 台计算机，每台具有 16 个 vCPU。

  • 影响：失去一台计算机只会使集群的容量减少 16 个 vCPU，因此，仅当生成的集群没有容量来托管所有 Pod 时，才会影响服务。但是，管理 6 台计算机意味着需要付出更大的努力。

• 选项 2：3 台计算机，每台具有 32vCPU

  • 影响：丢失计算机会使集群容量减少 32vCPU，这对 Automation Suite 产生重大影响。但是，管理 3 台计算机意味着更少的工作量。

总之，部署设计取决于目标。如果目标是更好的容错能力，则可以选择更小的计算机。但是，如果目标是减少管理开销，则应选择数量较少的大型计算机。

所有服务器节点而非代理节点？

是否选择所有服务器节点而不是代理节点取决于您的 RTO 或 RPO。

例如，假设您的 Automation Suite 需要 80 个 vCPU。您可以通过以下方式实现此目的：

• 选项 1： 5 台服务器计算机，每台具有 16 个 vCPU。在这里，您最多可以丢失 2 个服务器节点。

  • 如果目标是防止数据丢失，则推荐使用。即使丢失 2 个服务器节点，数据也将保持不变，并且可以从剩余的副本中重建。

• 选项 2： 3 个服务器节点和 2 个代理节点，每个节点具有 16 个 vCPU。在这里，您可以失去 1 个服务器节点和两个代理节点，因此总共 3 个计算机。

  • 如果目标是恢复节点可用性，则推荐使用。即使没有 3 台计算机，集群仍将可用，但功能仍将有限，一旦节点恢复，整个集群将恢复。但是，由于存储连接到服务器节点，此设置更容易丢失数据。如果 2 个服务器节点完全丢失，则在不从备份中恢复数据的情况下可能很难再次重建数据。