集群注册
集群模式概述
Karmada 支持通过 Push 和 Pull 两种模式来管理成员集群。 二者的核心区别在于 Karmada 控制面访问成员集群的方式,包括部署资源、
获取资源状态和集群健康状态等操作。两种模式适用于不同的网络环境和运维需求,在简单性、扩展性和灵活性之间实现平衡。
Push 模式
在 Push 模式下,Karmada 控制面通过直接连接成员集群的 kube-apiserver 以进行推送资源至成员集群、监控成员集群状态、获取资源状态等。 此模式适用于 Karmada 控制面可直接访问成员集群(或通过代理间接访问)且网络延迟较低的场景,例如同一数据中心内的集群管理。
Pull 模式
在 Pull 模式下,成员集群通过部署的 karmada-agent 组件 从 Karmada 控制面拉取清单,并向控制面报告清单状态和集群状态。
每个 karmada-agent 对应一个集群,其职责包括:
- 向 Karmada 控制面注册集群(创建 Cluster 对象)
- 维护集群状态并上报给 Karmada 控制面(更新 Cluster 对象状态)
- 监控 Karmada 执行空间(命名空间 karmada-es-
<集群名称>)中的清单,并将这些资源部署到其所服务的集群。 此模式需要为每个成员集群部署一个karmada-agent组件(部署位置需能同时访问成员集群和 Karmada 控制面)。相比 Push 模式,Pull 模式 引入了额外的运维开销,但因为karmada-agent分担了控制面的压力,性能更优。它特别适用于特殊的网络环境,比如成员集群位于 NAT 或网关后方, Karmada 控制面无法直接访问,或者需要管理超大规模集群。
需要说明的是,该模式大多数情况下,Karmada 无需直接访问成员集群。但某些高级功能,比如 Aggregated Kubernetes API Endpoint
和 Proxy Global Resources,仍需要控制面直接访问
成员集群。此时,用户需要通过 karmada-agent 在注册集群时提供成员集群的访问入口,否则这些功能将受限。