① 背景与问题（解决了什么痛点）

在 Kubernetes 生态中，Ingress 是一个核心的网络组件，用于管理对外暴露的服务。然而，随着 Ingress-NGINX 的退役计划（2026 年 3 月），许多依赖其进行流量管理的企业和开发者面临一个关键问题：如何平滑过渡到新的网络解决方案？

传统的 Ingress 实现虽然功能丰富，但存在一些局限性：

• 协议支持有限：Ingress 主要支持 HTTP/HTTPS 协议，对 TCP、UDP 等更底层协议的支持较弱。
• 配置复杂：Ingress 配置通常需要通过 YAML 文件定义，对于复杂的路由规则或安全策略，维护成本较高。
• 缺乏统一标准：不同 Ingress 控制器（如 Nginx、HAProxy、Istio）的配置方式不一致，导致跨平台迁移困难。

与此同时，Kubernetes 官方正在推动 Gateway API 的标准化，以提供更强大、灵活的网络管理能力。然而，从传统 Ingress 迁移到 Gateway API 需要大量重构工作，这无疑增加了企业的迁移成本。

为了解决这一问题，社区推出了 Ingress2Gateway 1.0，它是一个工具，旨在帮助用户将现有的 Ingress 配置无缝迁移到 Gateway API 中，从而实现平滑过渡。

本篇文章将围绕 Ingress2Gateway 1.0 展开，深入讲解其技术原理、使用场景，并通过实战案例展示如何将其应用到实际项目中。

---

② 核心概念/技术原理

什么是 Ingress2Gateway？

Ingress2Gateway 是一个自动化工具，它可以将 Kubernetes 中的 Ingress 资源转换为符合 Gateway API 规范的资源。它不仅保留了原有 Ingress 的配置逻辑，还引入了 Gateway API 的新特性，如更细粒度的路由控制、多协议支持等。

技术原理

Ingress2Gateway 的核心思想是 解析 Ingress 资源并生成对应的 Gateway API 资源，具体流程如下：

1. 读取 Ingress 资源：从 Kubernetes API 中获取所有 Ingress 对象。
2. 解析路由规则：提取每个 Ingress 的路径、主机名、服务端口等信息。
3. 生成 Gateway API 资源：
   • 将 Ingress 的 Host 和 Path 映射为 HTTPRoute。
   • 将 Ingress 的 Backend 服务映射为 ServiceReference。
   • 自动处理 TLS 配置，生成 TLS 字段。
4. 部署 Gateway API 资源：将生成的 Gateway API 资源提交到 Kubernetes 集群中。

支持的特性

• 自动迁移：无需手动编写 Gateway API 配置。
• 兼容性：支持大多数常见的 Ingress 配置。
• 扩展性：支持自定义模板，允许用户按需调整生成的 Gateway API 资源。

注意：目前 Ingress2Gateway 仅支持 HTTP 类型的 Ingress，未来版本可能扩展对 TCP、UDP 的支持。

---

③ 实战案例/代码示例

③.1 准备环境

为了演示 Ingress2Gateway 的使用，我们需要准备以下环境：

• 一个 Kubernetes 集群（建议使用 kubeadm 或 minikube）
• 已部署的 Ingress 控制器（例如 Nginx Ingress Controller）
• 一个简单的 Web 应用，用于测试流量转发

步骤 1：部署示例应用

我们先部署一个简单的 Web 应用，比如 nginx：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  replicas: 1
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:latest
        ports:
        - containerPort: 80
---
apiVersion: v1
kind: Service
metadata:
  name: nginx-service
spec:
  selector:
    app: nginx
  ports:
    - protocol: TCP
      port: 80
      targetPort: 80

保存为 nginx.yaml，然后执行：

kubectl apply -f nginx.yaml

步骤 2：创建 Ingress 资源

接下来，创建一个 Ingress 资源，用于将流量指向我们的 nginx-service：

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: nginx-ingress
  annotations:
    nginx.org/ssl-redirect: "false"
spec:
  rules:
  - http:
      paths:
      - path: /hello
        pathType: Prefix
        backend:
          service:
            name: nginx-service
            port:
              number: 80

保存为 ingress.yaml，然后执行：

kubectl apply -f ingress.yaml

现在，访问 http://<your-cluster-ip>/hello 应该可以看到 Nginx 默认页面。

③.2 使用 Ingress2Gateway 转换 Ingress

安装 Ingress2Gateway

Ingress2Gateway 可以通过 Helm 安装。首先确保你已安装 Helm：

helm repo add ingress2gateway https://kubernetes-sigs.github.io/ingress2gateway/
helm repo update

然后安装 Ingress2Gateway：

helm install ingress2gateway ingress2gateway/ingress2gateway --namespace ingress2gateway

生成 Gateway API 资源

Ingress2Gateway 提供了一个命令行工具 ingress2gateway，可以将现有 Ingress 资源转换为 Gateway API 资源。

运行以下命令：

ingress2gateway convert --namespace default --output-dir ./gateway-api

该命令会将 default 命名空间下的所有 Ingress 资源转换为 Gateway API 资源，并保存在 ./gateway-api 目录中。

查看生成的 Gateway API 资源

进入 ./gateway-api 目录，你会看到类似如下的文件：

apiVersion: gateway.networking.k8s.io/v1beta1
kind: HTTPRoute
metadata:
  name: nginx-ingress
spec:
  parentRefs:
  - name: ingress-gateway
    namespace: gateway-system
  hostnames:
  - example.com
  rules:
  - matches:
    - path:
        type: PathPrefix
        value: /hello
    backends:
    - name: nginx-service
      port: 80

注意：这里假设你已经部署了 Gateway API 控制器（如 gateway-controller），并且 ingress-gateway 是其默认的 Gateway。

部署 Gateway API 资源

将生成的 Gateway API 资源部署到 Kubernetes 集群中：

kubectl apply -f ./gateway-api/

③.3 测试 Gateway API 路由

现在，你可以通过 Gateway API 访问之前配置的 /hello 路径：

curl http://<your-cluster-ip>/hello

你应该仍然能看到 Nginx 默认页面，说明 Gateway API 已经成功接管了流量。

③.4 高级配置示例

添加 TLS 支持

如果你在原始 Ingress 中配置了 TLS，Ingress2Gateway 会自动将其转换为 TLS 字段。

例如，原始 Ingress 包含以下内容：

spec:
  tls:
  - hosts:
    - example.com
    secretName: tls-secret

转换后的 HTTPRoute 会包含：

spec:
  tls:
    certificateRefs:
    - name: tls-secret
      namespace: default

自定义模板

如果你希望对生成的 Gateway API 资源进行自定义，可以使用模板。例如，修改 HTTPRoute 的 hostnames：

apiVersion: gateway.networking.k8s.io/v1beta1
kind: HTTPRoute
metadata:
  name: nginx-ingress
spec:
  hostnames:
  - yourdomain.com
  rules:
  - matches:
    - path:
        type: PathPrefix
        value: /hello
    backends:
    - name: nginx-service
      port: 80

Ingress2Gateway 支持通过 --template 参数指定自定义模板路径。

---

④ 架构设计/方案对比

④.1 Ingress2Gateway 的架构图

④.2 方案对比

方案	优点	缺点
传统 Ingress + Nginx	简单易用，生态成熟	协议支持有限，配置复杂
直接使用 Gateway API	支持多协议，配置灵活	学习曲线高，迁移成本大
Ingress2Gateway + Gateway API	自动迁移，降低学习成本	依赖 Gateway API 控制器，功能受限于当前版本

④.3 最佳实践

• 逐步迁移：不要一次性将所有 Ingress 转换为 Gateway API，建议分批次进行。
• 验证流量：在正式切换前，使用测试环境验证 Gateway API 的行为是否与原有 Ingress 一致。
• 监控与日志：确保 Gateway API 控制器具备完善的监控和日志功能，以便快速定位问题。

---

⑤ 优劣势评估/选型建议

⑤.1 优势

• 简化迁移过程：Ingress2Gateway 大幅降低了从 Ingress 到 Gateway API 的迁移难度。
• 保持原有配置：不需要重新编写配置，只需一次转换即可完成。
• 兼容性强：支持大多数常见的 Ingress 配置，适合企业级应用。

⑤.2 劣势

• 功能限制：目前仅支持 HTTP 类型的 Ingress，不支持 TCP/UDP。
• 依赖 Gateway API 控制器：需要额外部署 Gateway API 控制器，增加运维复杂度。
• 模板灵活性有限：虽然支持自定义模板，但灵活性仍不如手动编写配置。

⑤.3 选型建议

场景	推荐方案	说明
拥有大量 Ingress 配置	Ingress2Gateway + Gateway API	快速迁移，减少人工干预
有复杂网络需求	直接使用 Gateway API	更灵活，支持多协议
无特殊网络需求	传统 Ingress + Nginx	简单易用，适合小型项目

---

⑥ 总结与延伸

Ingress2Gateway 1.0 的发布标志着 Kubernetes 网络架构的一次重要升级。它不仅解决了传统 Ingress 向 Gateway API 迁移的难题，还为开发者提供了更高效的网络管理工具。

通过本文的实战演练，我们展示了如何使用 Ingress2Gateway 将现有的 Ingress 配置转换为 Gateway API 资源，并验证了其在实际场景中的可用性。

未来，随着 Gateway API 的进一步发展，Ingress2Gateway 可能会支持更多协议、更丰富的配置选项。对于企业而言，及时拥抱这一变化，将有助于提升 Kubernetes 网络的灵活性和可维护性。

如果你正在考虑从 Ingress 过渡到 Gateway API，不妨尝试 Ingress2Gateway，它可能是你通往未来网络架构的第一步。

---

📌 附录：参考链接

• Ingress2Gateway GitHub
• Gateway API 官方文档
• Kubernetes Ingress 文档