Kubernetes Gateway API 在 Helm 中的标准化实践

Kubernetes Gateway API 作为新一代流量管理标准，正在逐步取代传统的 Ingress 控制器。然而在实际应用中，我们发现其与 Helm 生态的整合仍存在标准化不足的问题，这直接影响了开发者的采用体验。

现状分析

目前 Helm 官方模板默认支持 Ingress 资源，通过简单的 values.yaml 配置即可快速暴露服务：

ingress:
  enabled: true
  hosts:
    - grafana.example.org

但对于 Gateway API 的 HTTPRoute 资源，开发者需要手动编写 CRD 模板，这种不一致性导致：

1. 新用户学习成本增加
2. 现有 Helm 图表迁移困难
3. 生态系统碎片化

技术挑战

核心矛盾在于 API 形态的差异：

• Ingress 是 Kubernetes 内置 API
• Gateway API 通过 CRD 实现
• 部分关键功能（如存储快照）也采用 CRD 方式

这种设计差异引发了关于原生 Kubernetes 支持的讨论，直接影响工具链的默认支持策略。

标准化建议

社区提出了 HTTPRoute 的标准化 values 规范：

httpRoute:
  enabled: true
  hostname: app.example.com
  hostnames:
    - alt.example.com
  parentRef:
    name: production-gateway
    namespace: gateway-system

该设计特点包括：

1. 保持与 Ingress 相似的配置体验
2. 支持多主机名配置
3. 提供显式的 Gateway 关联机制
4. 保留扩展性字段

实施路径

建议采取分阶段实施方案：

1. 短期方案：

   • 在 Gateway API 文档中定义标准 values 规范
   • 提供参考模板供图表开发者使用

2. 中期方案：

   • 推动 Helm 官方支持 helm create 生成 HTTPRoute 模板
   • 建立 Helm 插件机制自动注入 CRD

3. 长期方案：

   • 推动 Gateway API 成为 Kubernetes 内置 API
   • 实现 Helm 对标准 API 的无缝支持

最佳实践

对于应用开发者：

• 同时支持 Ingress 和 HTTPRoute 配置
• 使用条件判断确保兼容性

{{- if .Values.httpRoute.enabled }}
apiVersion: gateway.networking.k8s.io/v1beta1
kind: HTTPRoute
{{- end }}

对于集群管理员：

• 预先安装 Gateway API CRD
• 配置默认 Gateway 实例
• 提供标准化 values 覆盖示例

未来展望

随着 Gateway API 的成熟，我们预期：

1. 将成为 Kubernetes 流量管理的标准接口
2. Helm 生态将全面适配
3. 出现自动化迁移工具
4. 多云环境下配置实现真正统一

这种演进需要社区共同努力，特别是在工具链标准化方面持续投入。