深度解析：Kong Hybrid 模式与 KIC (Gateway API) 架构演进与核心异同
在企业级 API 网关的技术选型与落地过程中，架构师通常面临两种截然不同的部署范式：面向异构网络的 Kong Hybrid Mode（混合部署模式） 与 面向纯粹云原生的 KIC (Kong Ingress Controller) + K8s Gateway API 模式。
这两种架构虽然底层均依赖 Kong 引擎进行流量代理，但在"控制面（Control Plane）"与"数据面（Data Plane）"的物理映射、状态存储中心（Source of Truth）以及声明式配置流转机制上，存在着本质的架构分歧。本文将对两者进行深度的拓扑对比与心智模型拆解。
一、 Kong Hybrid Mode：跨越网络边界的异构联邦
Hybrid 模式的设计初衷，是为了解决企业在混合云、多数据中心以及"K8s + 传统虚拟机 (VM)"共存时的全局流量调度问题。
1. CP 与 DP 的实体定义
- Control Plane (CP) ：由运行在特定角色 (
role=control_plane) 的 Kong 核心进程组成。CP 必须强依赖于关系型数据库（如 PostgreSQL / Cloud SQL）来持久化全量路由与策略状态。 - Data Plane (DP) ：运行在
role=data_plane的 Kong 核心进程。DP 是绝对无状态的（DB-less），且允许部署在任何算力载体上（GKE、GCE VM、甚至是物理机裸金属）。
2. 配置同步与通信链路
- 状态下发 ：CP 通过暴露特定的集群遥测端口（通常为
8005），利用 WebSocket 建立长连接。DP 启动时主动连接 CP，通过严格的双向证书认证（mTLS）后，将路由树加载至本地内存。 - 运维心智 ：管理员（或 GitOps 管道中的
decK工具）不关心底层计算环境，所有配置均直接推送到 CP 的 Admin API。
二、 KIC + K8s Gateway API：Kubernetes 的原生组件化
KIC 架构彻底抛弃了跨环境的野心，选择了对 Kubernetes 生态的"绝对忠诚"。通过引入 Gateway API 规范，网关被降维成 K8s 内部的一种标准网络基础设施。
1. 架构拓扑重构：CP 与 DP 的云原生映射
如上图所示，在 KIC 模式下，CP 和 DP 的概念被 Kubernetes 的组件模型完全重写：
- 全新的 Control Plane (CP) ：
- Kubernetes API Server 承担了最终的"状态存储"职责，K8s 集群底层的
etcd彻底替代了 Kong Hybrid 模式中的 PostgreSQL。 - Kong Ingress Controller (KIC) 扮演了真正的控制面逻辑计算单元。KIC 本质上是一个 Go 语言编写的 Kubernetes Operator/Controller。它持续监听（Watch）K8s 控制面中的特定 CRD 资源（如
GatewayClass,Gateway,HTTPRoute）。
- Kubernetes API Server 承担了最终的"状态存储"职责，K8s 集群底层的
- 收敛的 Data Plane (DP) ：
- 图中的
Kong Gateway Pods（在某些发行版中亦包含 Envoy Proxy 协同）即为纯粹的数据面。它们以无状态的 DaemonSet 或 Deployment 形式运行在集群内部，前端挂载 K8s 原生的 LoadBalancer 进行公网暴露。
- 图中的
2. 配置同步与流量解耦机制
- 资源定义解耦 ：如图中右上角所示，基础设施团队定义
GatewayClass与Gateway（声明网关的监听端口与 IP）；业务研发团队定义HTTPRoute（声明具体的路由匹配规则matches与后端引用backendRefs）。两者相互解耦，互不干扰。 - 配置翻译与 Sync ：当 KIC 监听到
HTTPRoute的创建时，KIC 内部的逻辑引擎会将其"翻译"为 Kong 原生的 JSON 路由格式，并通过本地回环或 Pod 间通信，直接调用 Kong Data Plane 的 Admin API，将规则强行推入 Kong 的内存中。 - 对业务完全透明：业务用户根本感知不到"Kong"进程的存在，他们面对的只有 K8s 官方标准的 Gateway API 资源对象。
三、 核心维度深度对比分析
| 对比维度 | Kong Hybrid Mode (混合模式) | KIC + Gateway API (云原生模式) |
|---|---|---|
| 控制面实体 (CP) | 独立的 Kong 核心进程 (role=control_plane) |
KIC (Kong Ingress Controller) + K8s API Server |
| 状态存储 (DB) | 强依赖外部 PostgreSQL / Cloud SQL | 完全抛弃关系型数据库，复用 K8s 底层的 etcd |
| 配置入口 | Kong Admin API 或 decK 声明式工具 |
kubectl 提交 YAML (HTTPRoute, Ingress) |
| 适用边界 | 极广：横跨公有云 K8s、私有云 VM、物理机房 | 受限：被严格锁死在单个或由联邦控制的 Kubernetes 集群内部 |
| 租户隔离能力 | 依赖企业版 Workspaces，或 GitOps CI/CD 阶段的逻辑硬隔离 | K8s 原生支持，利用 Namespace 和 Gateway 资源进行天然的强隔离 |
| 研发心智模型 | 网关是一个独立的"外部系统"，需要学习网关专属配置语法 | 网关是 K8s 集群原生网络能力的自然延伸，研发无需额外学习成本 |
四、 架构师选型结论
- 若企业正处于 IT 资产混合期 ：既有历史遗留的庞大 VM 业务群，又有新建的 K8s 微服务，且要求实现全局统一的 API 鉴权、限流与审计监控。👉 必须选择 Kong Hybrid Mode，以此打破网络物理隔离。
- 若企业已实现 100% 云原生化 ：所有业务均运行在 Kubernetes 集群内部，且技术栈严格遵循 K8s 规范，重度依赖 ArgoCD / Flux 等云原生 GitOps 工具。👉 强烈建议选择 KIC + Gateway API，享受最极致的声明式管理体验与最低的运维认知负荷。