#架构

使用 hub-and-spoke 架构。global 集群提供中央管理平面，而业务集群或第三方集群提供运行应用和集群本地组件的 Kubernetes 环境。

请将下图作为此模型的高层视图。下面的架构细节说明了图中未显示的边界。

有关平台范围内的术语，请参见 词汇表。有关概念性平台模型，请参见 平台模型。

#Hub-And-Spoke 模型

hub-and-spoke 模型描述了 global 集群与其管理的 Kubernetes 环境之间的关系。有关控制平面拓扑（包括 Hosted Control Plane），请参见 集群管理模型。

global 集群是平台的 hub。业务集群和第三方集群是 spoke。一个项目可以跨关联集群展开，而 namespace 可在这些集群内部提供 Kubernetes 资源隔离。

#访问与请求路径

用户和自动化通常通过 Platform Access Address、web 控制台、平台 API、Kubernetes API 或 CLI 工具访问平台。

从高层来看：

1. 用户、CLI、自动化工具或浏览器连接到 Platform Access Address。
2. 负载均衡器、VIP、DNS 记录或 ingress 路径将流量路由到平台入口组件。
3. 平台 API 服务评估认证和授权。
4. 请求由 global 集群处理，或通过已文档化的集群访问路径转发到目标集群。
5. 对目标集群的 Kubernetes API 请求会根据用户的有效 RBAC 权限进行评估。

有关 API 用法，请参见 API 简介。有关 CLI 工具，请参见 CLI 工具。有关集群 KubeConfig 访问，请参见 使用 KubeConfig 访问集群。

#管理路径

global 集群协调平台管理操作：

• 支持的 生命周期管理集群模型的集群创建和生命周期操作。
• 通过导入或注册工作流接入第三方集群。
• 项目、namespace、用户、角色和配额治理。
• Operator 和 Cluster Plugin 的发现、包上传、安装和升级入口。
• 在所需组件已安装时，提供可观测性、审计、资源清单和运维的集中视图。

对于第三方集群，管理路径取决于版本范围、连通性、凭据、提供商前提条件、已安装组件以及 Extension 兼容性。接入第三方集群不会使 成为该集群的 Kubernetes 生命周期、节点生命周期或提供商基础设施生命周期的所有者。

有关模型边界，请参见 集群管理模型。

#状态与数据域

不同的数据域具有不同的保护和恢复路径：

Global Cluster Disaster Recovery 仅保护 可用性与恢复 中记录的 global 控制平面 DR 场景。它不是完整的平台数据 DR，也不是应用数据 DR。

#Core 与 Extension 边界

Core 提供平台管理平面，以及用于管理集群、项目、用户、API 和 Extensions 的框架。

其他能力可能需要单独安装的 Extensions，例如 Operators 和 Cluster Plugins，或者独立产品。示例包括特定的可观测性后端、Registry 插件、API 过滤、合规功能、容器安全、数据服务、GitOps、日志、Immutable Infrastructure 和 Hosted Control Plane。

在将这些能力规划为架构的一部分之前，请查看相应文档中的安装、升级、兼容性和限制。

有关详细信息，请参见 Core 与 Extensions。

#可用性与恢复模型

可用性按拓扑进行规划：

• Single Node 仅用于测试或概念验证。
• 当业务场景适配且已为平台组件和工作负载规划好资源时，Single Cluster 可支持生产使用。
• Multi-Cluster 将 global 集群管理平面与业务集群分离，并且应避免在 global 集群上运行非平台业务工作负载。
• 三个控制平面节点是 HA 基线。五个控制平面节点是容量和可靠性建议，并不是通用的生产门槛。

有关详细规划、容量、组件级高可用性、Global DR 以及备份/恢复入口点，请参见 可用性与恢复。

#继续阅读

• 简介
• 平台模型
• 集群管理模型
• Core 与 Extensions
• 了解更多