4. 成员集群代理与网络通道
在 Fleet 架构中，控制面（Hub）与成员集群（Member Cluster）之间并不存在一条天然可信、长期稳定的网络路径。成员集群可能位于不同 VPC、不同云厂商、甚至边缘机房，网络地址不可直达，防火墙策略也不允许 Hub 主动拨入。因此，Fleet 的成员接入能力几乎全部落在“成员集群侧主动发起的 agent”这一设计上。理解 agent 的部署模式、它建立的通道类型、断连后的恢复行为，以及证书与心跳机制，是判断多集群可靠性边界的关键。
一、agent 部署模式：为什么是“成员侧主动出站”
Fleet 的成员代理通常以 Deployment 形式部署在成员集群的 fleet-system 命名空间中，核心组件包括 fleet-agent（负责与控制面通信、注册、心跳、证书轮换）以及可选的 fleet-agent-bootstrap（一次性 Job，用于首次注册并写入 kubeconfig 凭据）。这种“Hub 不主动连成员”的模式带来三个直接结果：
- 网络方向单一：成员集群只需能出站访问 Hub 的 API Server 或网关地址，无需开放任何入站端口，天然适配 NAT、企业防火墙和边缘网络。
- 凭据在成员侧：agent 使用一份受限的 ServiceAccount 凭据向 Hub 认证，Hub 侧不需要保存成员集群的 kubeconfig，降低了凭据集中泄露的风险。
- 可水平扩展：agent 以 Deployment 运行，副本数可调，但需注意同一成员集群的多个副本会竞争注册与心跳，通常建议单副本或配合 leader election。
部署时最容易被忽略的是 bootstrap 阶段。首次注册需要一份“引导凭据”，它通常由 Hub 侧生成并作为 Secret 下发到成员集群。引导完成后，agent 会向 Hub 申请正式证书，后续通信不再依赖引导凭据。因此，引导 Secret 的生命周期应短于正式证书，并在注册成功后及时清理。
二、双向流、隧道与网关：通道到底长什么样
agent 与 Hub 之间并非简单的 HTTP 轮询，而是建立一条双向流。在这条流上，Hub 可以向成员集群下发资源变更（如 Placement 决策后的 Work 对象），成员集群也可以向 Hub 上报状态（如 Work 的可用性、资源健康度）。这种双向能力使得 Fleet 既能做“下发”，也能做“回传”，而不需要 Hub 主动拨入成员集群。
当成员集群无法直接访问 Hub 的 API Server 时，会引入网关或隧道。常见形态有两种：
- 反向代理网关：Hub 侧暴露一个统一入口（如 ingress 或 LoadBalancer），agent 通过该入口建立长连接，网关将流量转发到 Hub 内部的服务。此时 agent 配置的是网关地址，而非 API Server 地址。
- 隧道模式：在 Hub 与成员之间建立一条加密隧道（如基于 TLS 的 WebSocket 或 gRPC 流），所有控制面消息封装在隧道内传输。隧道模式对中间网络更友好，但需要额外关注隧道自身的健康检查与超时设置。
无论哪种形态，通道的核心语义是一致的：成员侧发起、长连接保持、双向消息复用。这也意味着，通道的稳定性直接决定了 Fleet 的下发时效和状态回传时效。
三、断连重连：从“失联”到“恢复”的行为链
长连接一定会断。网络抖动、网关重启、证书过期、Hub 滚动升级，都会导致 agent 与 Hub 之间的流中断。Fleet 的可靠性设计并不假设“永不断连”，而是定义清楚断连后的行为：
- 检测：agent 侧通过心跳发送失败或流读写错误感知断连；Hub 侧通过心跳超时（如连续多个周期未收到心跳）将成员标记为不可用。
- 退避重连：agent 不会立即高频重试，而是采用指数退避（如 1s、2s、4s、8s……上限 60s），避免 Hub 故障恢复瞬间被大量成员同时冲击。
- 状态收敛：重连成功后，agent 会重新同步本地 Work 状态，Hub 也会重新下发未确认的变更。此时可能出现短暂的“状态不一致窗口”，需要依赖幂等设计来消除副作用。
- 判定：如果成员长时间无法恢复，Hub 侧会将其标记为
NotReady，Placement 决策可能将工作负载迁移到其他可用成员。
实际运维中，最需要关注的不是“是否断连”，而是“断连后多久恢复”以及“恢复后状态是否收敛”。建议在 Hub 侧对成员心跳间隔、超时阈值、重连退避上限做统一配置，并在监控中区分“短暂抖动”和“持续失联”。
四、证书轮换与心跳：通道的“生命体征”
证书是通道的信任基础。Fleet 中 agent 使用的证书通常有明确有效期（例如 1 年或更短），到期前需要自动轮换。轮换流程一般包括：agent 生成新的私钥与 CSR，向 Hub 提交签名请求，Hub 审批后签发新证书，agent 加载新证书并重建连接。整个过程应尽量在线完成，避免因证书过期导致通道中断。
心跳则是通道的“生命体征”。agent 按固定周期（如 10s 或 30s）向 Hub 发送心跳，携带成员标识、时间戳和基本健康信息。Hub 侧根据心跳判断成员是否在线，并更新 LastSeen 等状态字段。心跳间隔与超时阈值需要权衡：间隔太短会增加 Hub 压力，太长则故障发现延迟高。一个常见的经验值是“心跳间隔 10～30s，超时阈值取 3 倍心跳间隔”。
五、关键参数与判断依据（示例）
下表给出一组可用于教学或初始部署的示例参数，实际值需根据集群规模和网络质量调整。这些数值属于合理假设，并非实测结果。
| 参数 | 示例值 | 作用 | 异常判断 |
|---|---|---|---|
| 心跳间隔 | 15s | agent 上报存活 | 连续 3 次未上报 → 疑似断连 |
| 心跳超时 | 45s | Hub 判定成员失联 | 超过 45s 未收到 → 标记 NotReady |
| 重连退避上限 | 60s | 控制重试频率 | 长期停留在上限 → 检查网络或证书 |
| 证书有效期 | 90 天 | 限制凭据暴露窗口 | 剩余 < 15 天 → 应触发轮换 |
| 轮换提前量 | 30 天 | 在线完成证书替换 | 轮换失败 → 通道将在到期后中断 |
当成员集群出现“Hub 显示 NotReady 但集群本身正常”时，排查顺序建议为：先看 agent Pod 是否运行、再看 agent 日志中的连接错误、然后确认证书是否临近过期、最后检查网关或隧道是否可达。多数断连问题最终落在网络路径、证书有效期和心跳配置这三类原因上。
把 agent 部署、双向流、隧道网关、断连重连、证书轮换和心跳放在一起看，会发现它们共同构成了一条“成员集群接入可靠性链”。这条链上任何一环失效，都会表现为成员不可用或状态滞后。因此，在生产实践中，应把 agent 的健康状态、心跳时间戳、证书剩余有效期和重连次数纳入统一监控，而不是等到 Placement 决策异常时才回头排查。