
文章目录
-
- 前言
- [1. 核心概念回顾:为什么要转向 Gateway API?](#1. 核心概念回顾:为什么要转向 Gateway API?)
- [2. 环境准备](#2. 环境准备)
- [3. 部署步骤](#3. 部署步骤)
-
- [3.1 安装 Gateway API 标准 CRD](#3.1 安装 Gateway API 标准 CRD)
- [3.2 安装网关控制器 (Envoy Gateway)](#3.2 安装网关控制器 (Envoy Gateway))
- [3.3 定义 GatewayClass 和 Gateway](#3.3 定义 GatewayClass 和 Gateway)
- [4. 实际应用场景:金丝雀发布实践](#4. 实际应用场景:金丝雀发布实践)
-
- [4.1 部署后端服务](#4.1 部署后端服务)
- [4.2 配置 HTTPRoute 权重路由](#4.2 配置 HTTPRoute 权重路由)
- [5. 进阶应用:基于 Header 的路由](#5. 进阶应用:基于 Header 的路由)
- [6. 安全与观测性最佳实践](#6. 安全与观测性最佳实践)
-
- [6.1 强制 HTTPS (TLS 终止)](#6.1 强制 HTTPS (TLS 终止))
- [6.2 流量治理建议](#6.2 流量治理建议)
- [7. 总结](#7. 总结)
前言
随着 Kubernetes 业务规模的扩大,传统的 Ingress API 在面对复杂的流量治理(如蓝绿发布、金丝雀测试、多租户隔离)时,往往需要依赖特定厂商的 Annotations,这导致了配置的碎片化和厂商锁定。
为了解决这些痛点,社区推出了 Gateway API。它不仅是 Ingress 的演进,更是一套角色导向、富有表现力且可扩展的流量建模标准。本文将带您实战部署基于 Envoy Gateway 实现的 Kubernetes Gateway API。
1. 核心概念回顾:为什么要转向 Gateway API?
在 Gateway API 的设计哲学中,配置被解耦为三个独立的层级,对应不同的角色:
- GatewayClass (基础设施提供者):定义网关的类型(如 Envoy, Istio, Nginx)。
- Gateway (集群管理员):定义入口点(IP、端口、TLS 证书),负责网关的生命周期。
- HTTPRoute (应用开发者):定义具体的路由规则(转发路径、Header 修改、流量权重)。
这种解耦使得权限控制更加精细,符合企业内部的运维流程。
2. 环境准备
在开始之前,请确保您的环境满足以下条件:
- Kubernetes 集群:版本 v1.26+。
- Helm:用于安装组件。
- 负载均衡器支持 :如果是公有云环境(如 AWS/Azure/GCP),集群需支持 LoadBalancer;如果是私有化环境,建议安装 MetalLB。
3. 部署步骤
3.1 安装 Gateway API 标准 CRD
由于 Gateway API 是可插拔的,首先需要安装官方定义的自定义资源(CRDs)。
bash
kubectl apply -f https://github.com/kubernetes-sigs/gateway-api/releases/download/v1.0.0/standard-install.yaml
3.2 安装网关控制器 (Envoy Gateway)
我们选择 Envoy Gateway 作为实现,它是目前社区最受推崇的轻量级、高性能网关方案。
bash
helm install eg oci://docker.io/envoyproxy/gateway-helm --version v0.0.0-latest -n envoy-gateway-system --create-namespace
注:请在生产环境中使用具体的版本号替代 latest。
3.3 定义 GatewayClass 和 Gateway
首先,我们需要创建一个网关实例。
yaml
# gateway-setup.yaml
apiVersion: gateway.networking.k8s.io/v1
kind: GatewayClass
metadata:
name: eg
spec:
controllerName: gateway.envoyproxy.io/gatewayclass-controller
---
apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
name: my-gateway
namespace: default
spec:
gatewayClassName: eg
listeners:
- name: http
protocol: HTTP
port: 80
allowedRoutes:
namespaces:
from: All
应用配置:
bash
kubectl apply -f gateway-setup.yaml
此时,Envoy Gateway 会自动为你创建一个 Service (Type: LoadBalancer)。你可以通过 kubectl get svc 查看分配的外部 IP。
4. 实际应用场景:金丝雀发布实践
假设我们有一个应用 my-service,现在需要上线 v2 版本,并要求将 10% 的流量切往新版本。
4.1 部署后端服务
yaml
# apps.yaml
apiVersion: v1
kind: Service
metadata:
name: web-v1
spec:
selector:
app: web
version: v1
ports:
- port: 80
---
apiVersion: v1
kind: Service
metadata:
name: web-v2
spec:
selector:
app: web
version: v2
ports:
- port: 80
4.2 配置 HTTPRoute 权重路由
这是 Gateway API 的精髓所在,通过 HTTPRoute 实现精细化控制。
yaml
# route.yaml
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
name: web-route
namespace: default
spec:
parentRefs:
- name: my-gateway
hostnames:
- "example.com"
rules:
- backendRefs:
- name: web-v1
port: 80
weight: 90
- name: web-v2
port: 80
weight: 10
应用路由:
bash
kubectl apply -f route.yaml
5. 进阶应用:基于 Header 的路由
在实际测试中,我们可能需要内部员工优先访问 v2 版本。Gateway API 可以轻松实现:
yaml
rules:
- matches:
- headers:
- name: "x-user-role"
value: "tester"
backendRefs:
- name: web-v2
port: 80
- backendRefs:
- name: web-v1
port: 80
6. 安全与观测性最佳实践
6.1 强制 HTTPS (TLS 终止)
在 Gateway 资源中,您可以直接引用 Secret 来配置 TLS,不再需要在每个 Ingress 中重复配置。
6.2 流量治理建议
- 超时与重试 :利用 Gateway API 的
Filter功能或 Envoy Gateway 的扩展配置,定义请求的超时时间。 - 跨域设置 (CORS) :直接在
HTTPRoute的filters字段中定义,无需繁琐的 Annotations。
7. 总结
从 Ingress 迁移到 Gateway API 是迈向云原生架构成熟的重要一步。它不仅提供了跨供应商的标准接口,更通过角色解耦极大地提升了团队协作效率。
为什么现在就开始使用?
- 标准化:不再依赖特定的 Nginx/Traefik 注解。
- 灵活性:内置支持流量拆分、Header 改写等高级功能。
- 未来向:Kubernetes 官方主推,生态支持日益完善。
如果您正在构建新集群或进行架构升级,Gateway API + Envoy Gateway 是目前的推荐组合。
作者简介 :某大厂云原生架构师,专注于 K8s 流量治理与 Service Mesh。
发布渠道 :CSDN / 知乎 / 个人博客。
关键词:Kubernetes, Gateway API, Envoy Gateway, 云原生, 流量控制.