K8s HTTPS 升级：Ingress 到 Gateway API 的平滑迁移指南

随着 Kubernetes 版本的迭代，Gateway API 作为 Ingress 的下一代标准，提供了更强大、更灵活的流量管理能力。本文将详细介绍如何将现有的 Kubernetes HTTPS 服务从 Ingress 迁移到 Gateway API，并分享一些实战中的避坑经验。在进行 Kubernetes HTTPS迁移 时，我们需要考虑诸多因素，包括证书管理、路由规则、流量平滑切换等。本文将通过一个完整的示例，帮助大家理解和掌握迁移过程。

问题场景重现：Ingress 的局限性

在传统的 Kubernetes 环境中，Ingress 是最常用的 HTTP(S) 流量入口。然而，Ingress 也存在一些局限性：

• 配置复杂性：对于复杂的路由规则，Ingress 的配置会变得非常冗长和难以维护。尤其是涉及到基于 Header 的路由、重定向等高级功能时，需要编写大量的 annotation，可读性差。
• 扩展性不足：Ingress Controller 的种类繁多，但功能和性能各异。选择合适的 Ingress Controller 需要花费大量时间进行评估。而且，不同 Ingress Controller 之间的配置方式也存在差异，增加了学习成本。
• 多团队协作困难：在多团队协作的场景下，Ingress 的权限管理粒度较粗，容易出现配置冲突。

例如，使用 Nginx Ingress Controller 时，我们经常需要修改 nginx.conf 文件来实现一些自定义的需求，但这会导致配置文件的管理变得混乱。此外，对于需要高并发连接数的应用，Nginx Ingress Controller 的性能也可能成为瓶颈。这时，可以考虑使用 OpenResty 作为 Ingress Controller，或者通过调整 worker 进程数、连接超时时间等参数来优化性能。

Gateway API 的优势

Gateway API 旨在解决 Ingress 的局限性，提供更强大、更灵活的流量管理能力。它具有以下优势：

• 功能更强大：Gateway API 支持更多的协议和功能，例如 gRPC、TCP、UDP 等。它还提供了更丰富的路由规则，例如基于 Header、Query Parameter 的路由。
• 扩展性更好：Gateway API 定义了一套标准的 API 规范，允许不同的 Gateway Controller 实现不同的功能。这意味着我们可以根据自己的需求选择合适的 Gateway Controller，而无需担心兼容性问题。
• 多团队协作更友好：Gateway API 引入了 GatewayClass、Gateway、HTTPRoute 等资源对象，可以将流量管理的职责分配给不同的团队。每个团队可以独立管理自己的路由规则，而无需担心影响其他团队。

Gateway API 核心概念

在进行迁移之前，我们需要了解 Gateway API 的核心概念：

• GatewayClass：定义了一类 Gateway 的模板。它指定了使用的 Gateway Controller，以及一些默认的配置。
• Gateway：代表一个实际的 Gateway 实例。它指定了监听的端口、协议、TLS 证书等。
• HTTPRoute：定义了 HTTP 流量的路由规则。它指定了匹配的 Hostname、Path、Headers 等，以及流量转发的目标 Service。

实战：从 Ingress 迁移到 Gateway API

下面，我们将通过一个示例，演示如何将一个使用 Ingress 的 HTTPS 服务迁移到 Gateway API。

1. 安装 Gateway API CRD

首先，我们需要安装 Gateway API 的 CRD：

kubectl apply -f https://github.com/kubernetes-sigs/gateway-api/releases/download/v0.8.0/standard-install.yaml

2. 安装 Gateway Controller

这里我们选择 Contour 作为 Gateway Controller。Contour 是一个基于 Envoy 的高性能 Ingress Controller，它支持 Gateway API。

kubectl apply -f https://raw.githubusercontent.com/projectcontour/contour/main/examples/contour.yaml

3. 创建 GatewayClass

创建一个 GatewayClass 对象，指定使用的 Gateway Controller 为 Contour：

# gatewayclass.yaml
apiVersion: gateway.networking.k8s.io/v1beta1
kind: GatewayClass
metadata:
  name: contour
spec:
  controllerName: projectcontour.io/contour # 指定 Contour 作为 Gateway Controller

kubectl apply -f gatewayclass.yaml

4. 创建 Gateway

创建一个 Gateway 对象，指定监听的端口、协议、TLS 证书等：

# gateway.yaml
apiVersion: gateway.networking.k8s.io/v1beta1
kind: Gateway
metadata:
  name: my-gateway
spec:
  gatewayClassName: contour # 指定使用的 GatewayClass
  listeners:
  - name: https
    protocol: HTTPS
    port: 443
    tls:
      certificateRefs:
      - name: my-tls-secret # 指定 TLS 证书 Secret
        namespace: default

kubectl apply -f gateway.yaml

确保 my-tls-secret 已经存在，并且包含正确的 TLS 证书和私钥。

5. 创建 HTTPRoute

创建一个 HTTPRoute 对象，定义 HTTP 流量的路由规则：

# httproute.yaml
apiVersion: gateway.networking.k8s.io/v1beta1
kind: HTTPRoute
metadata:
  name: my-httproute
spec:
  parentRefs:
  - name: my-gateway # 指定关联的 Gateway
  hostnames:
  - "example.com"
  rules:
  - matches:
    - path:
        type: PathPrefix
        value: /
    backendRefs:
    - name: my-service # 指定流量转发的目标 Service
      port: 80

kubectl apply -f httproute.yaml

6. 删除 Ingress

确认 Gateway API 已经正常工作后，可以删除原有的 Ingress 对象。

实战避坑经验总结

• 证书管理：确保 TLS 证书的 Secret 存在，并且包含正确的证书和私钥。可以使用 cert-manager 自动管理证书。
• 流量平滑切换：在删除 Ingress 之前，可以先将一小部分流量切换到 Gateway API，观察一段时间，确认没有问题后再逐步增加流量。
• 监控和日志：配置 Gateway Controller 的监控和日志，以便及时发现和解决问题。可以利用 Prometheus 和 Grafana 搭建监控系统，使用 Fluentd 或 Elasticsearch 收集日志。
• 兼容性问题：不同版本的 Gateway API CRD 可能会存在兼容性问题，建议使用最新版本的 CRD，并仔细阅读官方文档。

在实际迁移过程中，可能会遇到各种各样的问题，例如路由规则不生效、TLS 证书验证失败等。遇到问题时，可以查看 Gateway Controller 的日志，或者使用 kubectl describe 命令查看资源对象的详细信息，以便快速定位问题。

总结

本文详细介绍了如何将 Kubernetes HTTPS 服务从 Ingress 迁移到 Gateway API。通过本文的学习，相信大家已经掌握了迁移的基本步骤和一些实战中的避坑经验。Gateway API 作为 Ingress 的下一代标准，具有更强大、更灵活的流量管理能力，值得我们积极探索和应用。希望本文对大家有所帮助！