随着 Istio 1.22 版本的发布，Istio API 已正式升级至 v1 版本，同期，Kubernetes Gateway API 也更新至 v1.1 版本。本篇文章旨在深入探索 Ingress API、Istio API 与 Kubernetes Gateway API 之间的联系与区别，并详述它们在现实应用中的选择及迁移策略。

前言

之前，我曾撰写一篇文章，讨论了 为何 Gateway API 是 Kubernetes 与服务网格入口中的未来方向。文章中指出，作为 Kubernetes 的初始入口网关，Ingress 的资源模型由于过于简单，难以满足当下的可编程网络需求。作为其接班人，Gateway API 近年来发展迅速，获得了广泛支持，包括众多新兴的开源网关项目如 Envoy Gateway 也选择基于 Gateway API 开发。此外，一些传统网关项目也开始适配 Gateway API，或通过 ingress2gateway 这样的工具进行迁移。

Gateway API，作为 Kubernetes 入口网关的最新成果，通过角色划分来分离关注点，并支持跨 namespace，更适合多云环境。它整合了入口网关（南北向）与服务网格（东西向，集群内路由）的重叠功能，为云原生时代的统一流量管理提供了新的参考模型。

Ingress API、Gateway API 与 Istio API 都能实现网关功能，它们之间具体有何联系与区别？本文将为你揭晓这一迷题，并提供 Kubernetes 环境中网关的选择和迁移策略。

Kubernetes 中的流量管理

随着微服务架构的广泛应用和日益增长的复杂性，Kubernetes 的流量管理工具也在不断演进以适应各种技术需求。Ingress API、Istio API 与 Kubernetes Gateway API 分别标志着这一演变的不同阶段。

Ingress API 提供了 Kubernetes 的基本流量管理功能，允许用户通过定义简单的路由规则（例如 HTTP 和 HTTPS）来管理外部访问集群内服务的流量。其设计虽简洁，但功能有限，主要适用于规模较小、结构较简单的应用场景。

相比之下，Istio API 作为服务网格的一部分，提供了一系列高级流量管理功能，如流量镜像、金丝雀发布和断路器，适合于需要复杂流量管理的大规模微服务架构。

为了克服 Ingress API 的局限性并集成类似 Istio 的高级功能，Kubernetes Gateway API 因应而生。它不仅在设计上提供了更高的灵活性和扩展性，还通过社区的广泛支持，成为连接传统 Ingress 实现和现代服务网格技术如 Istio 的桥梁，目前主流的开源网关都是基于 Gateway API 或已进行适配。

以下表格概述了这三者的核心特点和推荐使用场景：

Gateway API v1.1 的推出，特别是其在提升与现有 Ingress 配置兼容性方面的改进，为用户提供了一个平稳的迁移途径，使从传统的 Ingress 解决方案向更现代的、功能更全面的 Gateway API 的过渡变得更为顺畅。

从 Ingress 迁移到 Kubernetes Gateway API

若想从 Ingress 迁移到 Gateway API，请按以下步骤操作：

1. 理解关键差异：与 Ingress 相比，Gateway API 引入了多种新的概念和资源类型，如 Gateway、HTTPRoute 和 TLSRoute。这些资源提供了更多的配置选项和灵活性，请参阅 Gateway API 文档以了解其配置。
2. 配置入口点：创建 Gateway 资源配置，明确定义如何接收外部流量，包括配置协议、端口和 TLS 终端。
3. 映射旧资源：将现有的 Ingress 资源映射到对应的 Gateway API 资源。例如，Ingress 中的 host 和 path 规则需要转换为 HTTPRoute 中的路由规则。
4. 测试与部署：在正式迁移之前，在测试环境中验证新的 Gateway API 配置，确保所有流量路由正常，无安全漏洞。

为了简化迁移过程，你可以使用工具如 ingress2gateway，该工具能自动将 Ingress 配置转换为 Gateway API 格式。

实际迁移示例

以下是一个简单的 HTTP 网关配置示例，展示了如何将 Ingress 迁移到 Gateway API。

假设现有一个 Ingress 配置如下：

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: example-ingress
spec:
  rules:
  - host: example.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: example-service
            port:
              number: 80

要将其迁移到 Gateway API，首先需要创建一个 Gateway 对象：

apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: example-gateway
spec:
  gatewayClassName: example-gateway-class
  listeners:
    - name: http
      protocol: HTTP
      port: 80
      allowedRoutes:
        kinds
          - kind: HTTPRoute

请确保 gatewayClassName 指向你集群中配置的有效 GatewayClass。GatewayClass 通常由集群管理员设置，是一个为 Gateway 提供配置的资源。

接下来，创建 HTTPRoute 资源来定义路由规则，将流量路由到后端服务：

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: example-httproute
spec:
  parentRefs:
  - name: example-gateway
  hostnames:
  - "example.com"
  rules:
  - matches:
    - path:
        type: PathPrefix
        value: "/"
    backendRefs:
    - name: example-service
      port: 80

在此示例中，我们看到：

• Ingress 对象中的规则被直接映射到 HTTPRoute 对象中。
• 路由规则中的主机名匹配、路径匹配以及后端服务配置保持不变，只是对象和字段名称有所不同。

考虑的挑战

虽然可以将 Ingress 迁移到 Gateway API，并可能同时运行它们，但需要考虑以下挑战和迁移的必要性：

• 功能差异：某些 Ingress 控制器的特定功能可能在 Gateway API 中没有直接对应，可能需要通过额外的配置或自定义资源来实现。
• 多资源管理：Gateway API 的使用可能涉及比 Ingress 更多的资源类型和更复杂的配置，这可能增加管理的复杂性。

对于现有的 Ingress 和 Istio API 用户，是否需要迁移到 Gateway API 取决于具体情况。以下是一些迁移建议：

• 新部署：建议直接采用 Gateway API，以便利用其先进特性和预见未来的发展。
• 现有部署：如果现有系统运行稳定且无需高级特性，可以继续使用现有 API；如果希望利用 Gateway API 的新特性或计划未来长期发展，逐步迁移则是一个理智的选择。

对于不同网关对 Gateway API 的支持情况，可以参考 Gateway API 实现项目的一致性报告了解详细信息。

总结

Ingress API、Istio API 和 Kubernetes Gateway API 各具特色，适应不同的应用场景和需求。选择合适的 API，进行合理的规划和管理，可以显著提高系统的灵活性和稳定性。随着 Gateway API 的持续发展和成熟，它将越来越成为未来流量管理的主流选择。

选择合适的网关技术，结合你的具体需求和现有架构，可以更好地管理和优化流量，确保应用的高效和稳定运行。随着技术的进步和社区的发展，Gateway API 提供了一个强大且灵活的框架，使得从传统的 Ingress 迁移到更现代的解决方案变得更为简单和高效。

参考

• Migrating from Ingress - gateway-api.sigs.k8s.io
• Extending Gateway API support in Istio - istio.io