Routing Director 实施
若要确定实施 Routing Director 所需的资源，必须了解 Routing Director 底层基础架构的基础知识。
Routing Director 是一系列微服务，通过 API 相互交互，并在 Kubernetes 群集的容器内运行。Kubernetes 群集是一组运行容器化应用的节点或虚拟机 （VM）。
Kubernetes 群集由一个或多个主节点和工作节点组成。
-
控制平面（主）节点 — 主节点执行 Kubernetes 控制平面功能。
-
计算（工作）节点 - 工作节点提供运行 Pod 的资源。工作节点不具备控制平面功能。
这两种类型的节点可以单独部署，也可以位于同一虚拟机中。如果单个节点可以同时用作主节点和辅助节点，则这两个角色所需的组件都安装在同一节点中。
在 Routing Director 中，默认情况下，主节点还充当工作节点。
您需要考虑预期系统的容量（要管理的设备数量、用例等）、所需的可用性级别以及预期系统的性能，以确定以下群集参数：
- 群集中的节点总数
- 每个节点上的资源量（CPU、内存和磁盘空间）
- 充当主节点和工作节点的节点数
本指南稍后的 Routing Director 系统要求中介绍了每个节点上的资源量。
Routing Director 实施
Routing Director 是在 Kubernetes 群集之上实施的，该由一个或多个主节点以及一个或多个工作节点组成。
对于生产部署，功能群集至少需要三个同时用作主节点和工作节点的节点。这种实现不仅提高了性能，还允许在群集内实现高可用性：
-
控制平面高可用性 — 同时用作主节点和工作节点的三个节点提供所需的控制平面冗余。我们不支持超过三个主节点。
-
工作负载高可用性 - 为了获得工作负载高可用性和工作负载性能，您必须有多个工作人员。在 Routing Director 中，同时充当主节点和工作节点的三个节点提供所需的工作负载高可用性。如果群集包含四个节点，则第四个节点将充当仅工作节点，从而提供额外的工作负载高可用性。
-
存储高可用性 — 为了实现存储高可用性，所有节点都提供 Ceph 存储。
Routing Director 可以作为单节点或多节点群集实现。建议实现四节点群集，其中三个节点充当主节点和工作节点，一个节点充当仅工作节点。
您还可以在三节点群集上部署 Routing Director，其中所有三个节点都作为主节点和工作节点运行。
此外，在实验室环境、概念验证和小规模部署中，您可以将 Routing Director 部署在单个节点上，在这些环境中，只需管理极少数量的设备（小于 10 台设备）。只有当可扩展性或可用性要求远不如生产部署严格时，才必须使用单节点部署。单节点部署无法实现高可用性。
单节点和三节点群集的安装过程与四节点群集的安装过程相同，但配置硬件资源要求和 Kubernetes 节点索引的位置除外。
本文档的其余部分重点介绍安装和配置四节点群集。配置三节点群集或单节点部署的任何差异都会在相应的安装步骤中显式说明。
群集节点和服务器高可用性
当单个节点发生故障且节点之间的最大往返延迟小 于 25 毫秒时，多节点 Routing Director 部署 群集 仍可正常运行。
若要确保群集在服务器发生故障时保持正常运行，请在单独的服务器上实现群集。 图 2 说明了保持服务器和节点高可用性的推荐实施。这可确保即使其中一台服务器发生故障，群集也能保持正常运行。
请注意，在本例中，10.1.2.7 是 GUI 的 VIP 地址，位于 10.1.2.0/24 网络上。您可以通过 10.1.2.0/24 网络本地访问 10.1.2.7。您还可以使用 NAT 将外部 IP 地址转换为 10.1.2.7，从而从外部访问 10.1.2.7。
该图显示了一个四节点群集，其中群集节点和 VIP 地址都在同一子网中。群集可以有三个节点，节点和 VIP 地址也可以位于不同的子网中。