4. 云原生网关核心组件：Ingress Controller、API Gateway、Service Mesh Sidecar

在云原生架构中，流量入口与内部通信的治理由多个网关组件分层承载。理解这些组件的职责边界与协作关系，是诊断证书更新延迟、定位回归故障的前提。本章聚焦三类核心组件：Ingress Controller、API Gateway（以 Kong/APISIX/Envoy 为代表）以及 Service Mesh Sidecar。

4.1 组件分层与职责对比

三类组件在证书生命周期管理中的关注点不同：Ingress Controller 负责集群入口的 TLS 终止；API Gateway 承担更细粒度的路由、认证与证书策略；Sidecar 则处理服务间 mTLS 与证书轮换。下表从多个维度进行对比：

4.2 组件协作架构与证书更新路径

下图展示了在典型云原生部署中，三类组件如何协作处理一次证书更新，以及流量路径上的延迟风险点。

4.3 核心组件详解

4.3.1 Ingress Controller

Ingress Controller 是 Kubernetes 集群的流量入口标准组件。它监听 Ingress 资源，将 TLS 证书（以 Secret 形式）加载到代理层。证书更新时，Controller 需要检测 Secret 变更并触发重载。

• 证书加载机制： 通过挂载 Secret 卷或 watch API 实现。
• 重载策略： 优雅重载（如 nginx -s reload）或热更新（如动态 SSL 证书 API）。
• 回归检查要点： 重载期间连接中断计数、旧证书缓存残留时间。

4.3.2 API Gateway（Kong / APISIX / Envoy）

API Gateway 在 Ingress 基础上提供更丰富的流量治理能力。证书管理通常通过 Admin API 或控制面动态下发。

4.3.3 Service Mesh Sidecar

Sidecar 代理（通常为 Envoy 或 Linkerd-proxy）处理服务间通信的 mTLS 加密。证书由控制面（如 Istiod）通过 SDS 或 CSR 流程下发，轮换周期通常较短（如 24 小时）。

• 证书身份： 基于 SPIFFE 标准，每个服务拥有唯一身份。
• 轮换流程： 旧证书过期前，控制面推送新证书 → Sidecar 热替换 → 旧连接优雅关闭。
• 回归检查要点： 证书轮换是否在过期前完成、新旧证书重叠期连接是否中断、mTLS 握手失败率。

4.4 组件选择对证书更新延迟的影响

不同组件组合在证书更新延迟上的表现差异显著。以下场景基于实际生产案例总结：

1. Ingress Controller + 后端直连： 证书更新仅影响入口 TLS，延迟较低，但缺少细粒度路由策略。
2. Ingress Controller + API Gateway： 证书更新需同步到两层，Ingress 终止外部证书，Gateway 可能处理内部 mTLS，延迟叠加。
3. Ingress Controller + Service Mesh： 入口证书由 Ingress 管理，内部 mTLS 由 Sidecar 自动轮换，控制面与数据面同步成为关键。
4. 全链路 API Gateway + Service Mesh： 证书管理最复杂，Gateway 和 Sidecar 各有独立的证书生命周期，回归检查需覆盖两层。

4.5 回归检查清单（组件视角）

针对三类核心组件，证书更新回归检查应包含以下项目：