4. Kong Helm Chart 架构：目录结构、核心组件与依赖关系
Kong 官方 Helm Chart 是部署 Kong 网关到 Kubernetes 集群的标准方式。理解其目录结构、核心组件及依赖关系，是进行资源配额模型设计和架构适配的前提。本章将深入剖析官方 Chart 的内部组织方式与运行机制。
4.1 官方 Helm Chart 目录结构
官方 Chart 的目录结构遵循 Helm 标准规范，同时针对 Kong 的多组件特性进行了扩展。以下为典型结构（以 chart 版本 2.x 为例）：
kong/
├── Chart.yaml # Chart 元数据（名称、版本、依赖等）
├── values.yaml # 全局默认配置值
├── values.schema.json # values.yaml 的 JSON Schema 校验文件
├── charts/ # 子 Chart 依赖（如 postgresql、ingress-nginx）
├── templates/ # Go 模板文件目录
│ ├── _helpers.tpl # 通用模板辅助函数
│ ├── NOTES.txt # 安装后的使用说明
│ ├── controller-*.yaml # Controller 相关资源模板
│ ├── proxy-*.yaml # Proxy 相关资源模板
│ ├── crd-*.yaml # CRD 资源模板
│ ├── migrations-*.yaml # 数据库迁移 Job 模板
│ ├── ingress-*.yaml # Ingress 资源模板
│ ├── service-*.yaml # Service 资源模板
│ ├── hpa-*.yaml # HorizontalPodAutoscaler 模板
│ ├── pdb-*.yaml # PodDisruptionBudget 模板
│ └── serviceaccount-*.yaml # ServiceAccount 与 RBAC 模板
└── crds/ # 独立 CRD 定义目录（Helm 3.2+ 特性）
├── kong-clusterplugins.yaml
├── kong-consumers.yaml
├── kong-ingresses.yaml
└── kong-plugins.yamlcrds/目录中的 CRD 定义会在 Chart 安装时优先于模板渲染被应用到集群，且 Helm 不会自动删除它们（需手动清理）。templates/目录中的模板文件通过values.yaml中的条件控制（如.Values.controller.enabled）来决定是否生成对应资源。
4.2 核心组件：Controller、Proxy、CRDs
Kong Helm Chart 将网关功能拆分为三个核心组件，每个组件在 Kubernetes 中以独立的 Deployment 或 DaemonSet 运行，并通过 Service 暴露。
| 组件 | Kubernetes 资源类型 | 核心职责 | 默认副本数 |
|---|---|---|---|
| Controller | Deployment | 运行 Kong Ingress Controller (KIC)，监听 Kubernetes Ingress/CRD 资源变化，动态更新 Kong 配置。 | 1 |
| Proxy | Deployment 或 DaemonSet | 运行 Kong Gateway 数据面，处理实际的 API 流量转发、负载均衡、插件执行。 | 2 |
| CRDs | CustomResourceDefinition | 定义 Kong 特有的资源类型（如 KongIngress、KongPlugin、KongConsumer），扩展 Kubernetes API。 | — |
4.2.1 Controller（控制面）
Controller 组件运行 Kong Ingress Controller (KIC)，它是整个架构的“大脑”。KIC 通过 watch Kubernetes API 中的 Ingress、Service、Secret 以及 Kong CRD 资源，将声明式配置转换为 Kong 的 Admin API 调用，最终写入 Kong 数据面。
- 配置同步流程： KIC 监听资源变化 → 生成 Kong 配置（Routes、Services、Upstreams）→ 调用 Kong Admin API 更新。
- 高可用： 支持多副本部署，通过 leader election 机制确保同一时间只有一个 Controller 执行配置推送。
- 资源需求： 通常为 CPU 密集型，建议根据管理的 Ingress/CRD 数量调整资源配额。
4.2.2 Proxy（数据面）
Proxy 组件运行 Kong Gateway 实例，负责处理客户端请求。它从本地文件或内存中加载由 Controller 推送的配置，执行路由匹配、插件链、负载均衡等操作。
- 部署模式： 默认使用 Deployment（适合云环境），也可配置为 DaemonSet（适合边缘节点或需要每节点固定性能的场景）。
- 流量入口： 通过 Kubernetes Service（类型可为 ClusterIP、NodePort、LoadBalancer）暴露。
- 资源需求： 内存和网络 I/O 密集型，需根据预期 QPS 和插件复杂度规划。
4.2.3 CRDs（自定义资源定义）
CRDs 是 Kong 与 Kubernetes 生态深度集成的关键。它们允许用户使用 kubectl 和 Kubernetes 原生 API 来管理 Kong 配置，无需直接调用 Admin API。
- 核心 CRD 列表：
kongingresses.configuration.konghq.com— 增强型 Ingress，支持高级路由规则。kongplugins.configuration.konghq.com— 声明式插件绑定。kongconsumers.configuration.konghq.com— 消费者与认证凭据管理。kongclusterplugins.configuration.konghq.com— 集群级全局插件。
- 生命周期： CRD 定义在
crds/目录中，安装 Chart 时自动创建；删除 Chart 时需手动清理 CRD 及其关联的自定义资源实例。
4.3 组件依赖关系与数据流
下图展示了 Controller、Proxy、CRDs 以及外部依赖（数据库、Kubernetes API）之间的交互关系：
4.4 依赖关系清单
Kong Helm Chart 在安装时，除了自身组件外，还会依赖以下外部服务或子 Chart：
| 依赖项 | 类型 | 默认启用 | 说明 |
|---|---|---|---|
| PostgreSQL | 子 Chart（bitnami/postgresql） | 是 | Kong 的配置存储后端。可替换为外部数据库。 |
| Ingress Controller | 子 Chart（ingress-nginx） | 否 | 可选依赖，用于将 Kong Proxy Service 暴露到集群外部。 |
| Kubernetes API | 外部服务 | — | Controller 必须依赖，用于监听资源变化。 |
| Secret 存储 | 外部服务 | — | 用于管理证书、等敏感信息。 |
- 如果禁用内置 PostgreSQL 子 Chart，必须在
values.yaml中配置postgresql.enabled=false并提供外部数据库连接信息（env.database_*）。 - Ingress Controller 子 Chart 默认关闭，建议在已有 Ingress 基础设施的环境中手动管理 Kong Proxy 的暴露方式。
- CRD 的版本必须与 Controller 版本兼容。升级 Chart 时，CRD 不会自动更新，需手动应用新版本 CRD 定义。
4.5 组件间通信端口与协议
了解组件间的通信端口有助于网络策略配置和安全加固：
| 通信方向 | 源组件 | 目标组件 | 端口 | 协议 | 用途 |
|---|---|---|---|---|---|
| 配置推送 | Controller | Proxy | 8001 | HTTP | Admin API 配置更新 |
| 健康检查 | Controller | Proxy | 8100 | HTTP | Proxy 健康状态探测 |
| 数据库读写 | Proxy / Controller | PostgreSQL | 5432 | TCP | 配置持久化存储 |
| Kubernetes API | Controller | API Server | 6443 | HTTPS | 监听资源变化 |
| 客户端流量 | 外部客户端 | Proxy | 8000 / 8443 | HTTP/HTTPS | API 请求入口 |
通过以上分析可以看出，Kong Helm Chart 的架构设计遵循了控制面与数据面分离的云原生原则，CRDs 则作为 Kubernetes 生态的“适配层”，使得 Kong 的配置管理完全融入声明式运维体系。理解这些组件及其依赖关系，是后续进行资源配额建模和性能调优的基础。