如何从Kubernetes Ingress迁移到Gateway API - Tetrate

Kubernetes网关API、Istio和Ingress的演进

随着Istio 1.22的发布，Istio Kubernetes网关API也更新到了v1.1版本。这标志着Kubernetes流量管理技术的进一步成熟。本文将探讨Ingress API、Istio API和Kubernetes Gateway API之间的联系与差异，并详细介绍如何在实际应用中选择和迁移这些技术。

背景

网关API是Kubernetes入口网关领域的最新发展，通过角色划分实现关注点分离，并支持跨命名空间的功能，使其更适合多云环境。它不仅覆盖了入口网关（南北流量）的功能，还兼具服务网格（东西流量、集群内路由）的能力，为云原生时代的流量管理提供了统一的参考模型。

Ingress API、Gateway API和Istio API均可实现网关功能，但它们的设计目标和适用场景各不相同。本文将揭示它们的核心区别，并提供在Kubernetes环境中选择和迁移网关的策略。

Kubernetes流量管理的演进

随着微服务架构的普及和复杂性的增加，Kubernetes的流量管理工具也在不断发展，以满足不同的技术需求。Ingress API、Istio API和Kubernetes Gateway API分别代表了这一演进过程中的不同阶段。

Ingress API

Ingress API是Kubernetes中最早的流量管理工具，提供了基本的流量管理功能。它允许用户通过简单的路由规则（如HTTP和HTTPS）管理对集群内服务的外部访问。尽管设计简单，但功能有限，主要适用于规模较小、需求不复杂的应用场景。

Istio API

Istio API是服务网格的一部分，提供了高级流量管理功能，如流量镜像、金丝雀发布和断路器等。它适用于需要复杂流量管理的大型微服务架构。

Kubernetes Gateway API

为克服Ingress API的局限性并集成Istio的高级功能，Kubernetes社区开发了Gateway API。它提供了更大的灵活性和可扩展性，并得到了广泛的社区支持。Gateway API被视为连接传统Ingress实现和现代服务网格技术（如Istio）的桥梁，目前大多数主流开源网关都支持或基于Gateway API。

Gateway API v1.1的推出，特别是在与现有Ingress配置兼容性方面的改进，为用户提供了一条平滑的迁移路径，使从传统Ingress解决方案到功能更丰富的Gateway API的过渡更加便捷。

从Ingress迁移到Kubernetes网关API

从Ingress迁移到Gateway API需要以下几个步骤：

1. 理解关键差异

Gateway API引入了一些新的概念和资源类型，如Gateway、HTTPRoute和TLSRoute。这些资源提供了更多的配置选项和灵活性。建议参考官方文档，深入了解这些资源的配置方法。

2. 配置入口点

创建Gateway资源，明确定义如何接收外部流量，包括协议、端口和TLS终止等。

3. 映射旧资源

将现有的Ingress资源映射到相应的Gateway API资源。例如，Ingress中的主机和路径规则需要转换为HTTPRoute中的路由规则。

4. 测试部署

在正式迁移前，建议在测试环境中验证新的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/v1beta1
kind: Gateway
metadata:
  name: example-gateway
spec:
  gatewayClassName: example-gateway-class
  listeners:
  - protocol: HTTP
    port: 80

接着，创建一个HTTPRoute资源来定义流量路由规则：

apiVersion: gateway.networking.k8s.io/v1beta1
kind: HTTPRoute
metadata:
  name: example-route
spec:
  parentRefs:
  - name: example-gateway
  rules:
  - matches:
    - path:
        type: Prefix
        value: /
    backendRefs:
    - name: example-service
      port: 80

在此示例中，Ingress对象的规则被直接映射到HTTPRoute对象。主机名匹配、路径匹配和后端服务配置保持不变，但对象和字段名称有所不同。

迁移中的考虑因素与挑战

尽管从Ingress迁移到Gateway API是可行的，但仍需注意以下挑战：

特征差异

某些Ingress控制器特定的功能可能在Gateway API中没有直接的等效实现。这可能需要额外的配置或通过自定义资源来实现类似功能。

多资源管理

Gateway API引入了更多的资源类型和复杂的配置，这可能会增加管理的复杂性。

迁移建议

• 新部署：建议直接使用Gateway API，以充分利用其高级功能并适应未来的发展趋势。
• 现有部署：如果现有系统运行稳定且不需要高级功能，可以继续使用当前的API。如果希望利用Gateway API的新功能或计划长期开发，建议逐步迁移。

结论

Ingress API、Istio API和Kubernetes Gateway API各有特点，适用于不同的应用场景和需求。选择合适的API并进行有效的规划和管理，可以显著提升系统的灵活性和稳定性。

随着Gateway API的不断发展和成熟，它正逐渐成为流量管理的主流选择。通过结合具体需求和现有架构，合理选择网关技术，可以更好地优化流量管理，确保应用程序的高效稳定运行。

参考文献

原文链接: https://tetrate.io/blog/kubernetes-ingress-to-gateway-api-migration/