从 0 到 1 实操 K8s Gateway API+Istio：告别 Ingress，用新标准实现域名访问

一、前言：为什么要学 Gateway API？

在 Kubernetes 中，Ingress 一直是处理七层 HTTP 流量的标准方式。但随着业务复杂度提升，Ingress 暴露出了不少问题：功能依赖不同控制器的自定义注解、各实现间兼容性差、扩展性弱。

为了解决这些痛点，Kubernetes 社区推出了 Gateway API，它被称为 Ingress 的下一代标准，提供了更模块化、更通用、更可扩展的流量管理能力。

本文将带你从理论到实操，完整走一遍 Gateway API 的安装、配置过程，并结合 Istio 实现一个基于域名的服务访问。

二、Gateway API 核心概念与组件

在动手之前，我们先搞懂 Gateway API 的三大核心组件，这是理解其工作原理的关键。

1. GatewayClass

• 作用：集群级资源，定义网关的实现类型，指定由哪个控制器（如 Istio、Contour、Envoy Gateway）来管理对应的 Gateway 资源。
• 类比：它就像一个 "驱动程序" 声明，告诉 K8s 集群 "我要用 Istio 来实现网关功能"。

2. Gateway

• 作用：命名空间级资源，代表一个具体的流量入口实例。它绑定一个 GatewayClass，并配置监听器（端口、协议、域名、TLS 证书等）。
• 类比：它是一个物理上的网关设备，定义了流量从哪里进来、监听什么端口、支持什么域名。

3. Route（如 HTTPRoute）

• 作用：命名空间级资源，定义 L7 路由规则。它将 Gateway 监听到的流量，根据域名、路径、Header 等匹配规则，转发到后端的 Service。
• 类比：它是网关里的路由表，定义了 "什么样的请求该转发到哪个服务"。

三者关系 ：GatewayClass → Gateway → HTTPRoute → Service，这种分层解耦的设计，让基础设施团队和开发团队的职责更清晰。

三、环境准备与实操步骤

我们的目标是：搭建一个 Istio+Gateway API 环境，通过域名test.yinling.cloud访问集群内的 Nginx 服务。

1. 安装 Gateway API CRD

首先，需要在集群中安装 Gateway API 的标准资源定义，让 K8s 能识别Gateway、HTTPRoute等资源。

# 从国内镜像源安装，速度更快
kubectl kustomize "https://gitee.com/cncfclub/gateway-api/config/crd?ref=v1.1.0" | kubectl apply -f -

2. 安装 Istio 作为 Gateway API 控制器

Istio 是目前对 Gateway API 支持最完善的实现之一。我们先下载并安装istioctl工具。

# 下载istioctl
wget https://gitee.com/cncfclub/k8s/releases/download/1.33/istioctl-1.23.2-linux-amd64.tar.gz
tar xf istioctl-1.23.2-linux-amd64.tar.gz -C /usr/local/bin

# 创建命名空间并安装极简版Istio控制面
kubectl create namespace istio-system
istioctl manifest generate --set profile=minimal > minimal.yaml
kubectl create -f minimal.yaml

# 验证安装
kubectl get pod -n istio-system
kubectl get gatewayclasses.gateway.networking.k8s.io

执行成功后，你会看到一个名为istio的GatewayClass，这说明 Istio 已经成功接入 Gateway API。

3. 部署测试应用

我们部署一个简单的 Nginx 服务，作为后续访问的后端应用。

# deployment-service.yml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: k8sgateway-test
  labels:
    app: nginx
spec:
  replicas: 1
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx
        imagePullPolicy: IfNotPresent
        ports:
        - containerPort: 80

kubectl create -f deployment-service.yml
# 创建Service暴露Nginx
kubectl expose deployment k8sgateway-test --port=9000 --name=gw-service --target-port=80
kubectl get svc

4. 配置 Gateway 与 HTTPRoute

这是最核心的一步，我们来定义流量入口和路由规则。

# gatewayandhttproute.yml
apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: yl-gateway
spec:
  gatewayClassName: istio
  listeners:
  - name: default
    hostname: "*.yinling.cloud"
    port: 80
    protocol: HTTP
    allowedRoutes:
      namespaces:
        from: All
---
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: yl-http
spec:
  parentRefs:
  - name: yl-gateway
  hostnames: ["test.yinling.cloud"]
  rules:
  - matches:
    - path:
        type: PathPrefix
        value: /
    backendRefs:
    - name: gw-service
      port: 9000

kubectl apply -f gatewayandhttproute.yml

# 验证资源
kubectl get gateways.gateway.networking.k8s.io
kubectl get httproutes.gateway.networking.k8s.io

5. 验证与测试

此时，Istio 会自动为我们的 Gateway 创建一个LoadBalancer类型的 Service。在本地集群中，这个外部 IP 通常由MetalLB提供。

kubectl get service

你会看到类似如下输出：

NAME                TYPE           CLUSTER-IP       EXTERNAL-IP     PORT(S)
yl-gateway-istio    LoadBalancer   10.104.141.141   192.168.30.240  80:30509/TCP...

这个192.168.30.240就是我们的网关入口 IP。接下来，配置本地域名解析并测试访问：

echo 192.168.30.240 test.yinling.cloud >> /etc/hosts
curl http://test.yinling.cloud

如果成功返回 Nginx 的欢迎页面，说明我们的 Gateway API 配置已经完全生效！

四、原理剖析：流量是怎么走的？

很多同学会疑惑，我们配置了 Gateway 和 HTTPRoute，最终是怎么通过域名访问到 Nginx 的？整个链路是这样的：

1. Istio 自动创建网关 Service ：当我们创建Gateway资源时，Istio 控制器会自动创建一个istio-ingressgateway的 Deployment 和对应的LoadBalancer Service，也就是我们看到的yl-gateway-istio。
2. MetalLB 分配外部 IP ：在本地集群中，MetalLB为这个LoadBalancer Service 分配了一个外部可达的 IP192.168.30.240。
3. HTTPRoute 配置路由规则 ：我们定义的HTTPRoute，会被 Istio 转换成 Envoy 代理的配置，告诉它如何将test.yinling.cloud的请求转发到gw-service。
4. 用户访问链路 ： 用户 → test.yinling.cloud → 192.168.30.240 → Istio网关Pod → 根据HTTPRoute规则转发 → gw-service → Nginx Pod

五、Gateway API vs Ingress：区别与优势

为了让你更清晰地理解 Gateway API 的价值，我们来对比一下它和传统 Ingress 的区别：

对比项	Ingress	Gateway API
组件模型	单资源模型，规则定义在一个 Ingress 中	分层模型：GatewayClass → Gateway → Route
扩展性	依赖各控制器的自定义注解，兼容性差	标准化 API，不同实现（Istio、Contour）兼容
功能	仅支持 HTTP/HTTPS 路径域名转发	原生支持 HTTP、GRPC、TCP、TLS 等多种协议路由
职责分离	基础设施和开发团队职责耦合	网关由基础设施团队管理，路由由开发团队管理

六、总结与展望

通过本文的实操，我们不仅学会了如何使用 Gateway API，更理解了其背后的设计思想。Gateway API 作为 Kubernetes 官方主推的流量管理标准，未来会逐步取代 Ingress，成为云原生应用南北向流量的首选方案。

掌握 Gateway API，不仅是应对面试的加分项，更是你理解云原生流量治理、Istio 等服务网格技术的基础。