服务网格技术在国产化信创环境中的落地需求越来越普遍，中标麒麟操作系统作为国内主流的服务器操作系统之一，其上运行的Kubernetes集群经常需要承载微服务治理能力。Istio作为使用最广泛的服务网格之一，早期主要依靠Ingress Gateway暴露入口流量，而随着Kubernetes官方推出Gateway API并逐步进入稳定阶段，Istio也提供了对Gateway API的原生支持。本文将结合中标麒麟环境的特点，完整讲解如何基于Gateway API实现Istio的入口流量管理。
一、为什么选择Gateway API而不是传统Ingress
Istio最初的入口方案是Istio Ingress Gateway，配合Gateway和VirtualService两个CRD使用。这套方案在功能上没有明显短板，但它属于Istio自定义的资源模型，无法与其他遵循Gateway API规范的网格或控制器复用。Kubernetes社区推出Gateway API的初衷，就是解决Ingress规范能力不足、各厂商注解碎片化的问题，把角色划分为基础设施提供方与集群使用方，实现关注点分离。
Gatway API带来了几个核心优势。第一是标准化，HTTPRoute、TCPRoute等资源是Kubernetes官方SIG-Network维护的规范，编写的配置可以迁移到支持该规范的任意实现；第二是可移植性，在中标麒麟这种信创环境中，业务系统往往需要适配多种底层平台，标准化的路由模型能显著降低迁移成本；第三是 RBAC 友好，Gateway资源可以声明允许哪些命名空间的路由挂载，便于多团队协作。
Istio从1.18版本开始默认支持Gateway API，并在新版本中逐步将Gateway API作为推荐方式。Istio对Gateway API有两种处理模式：一种是直接复用默认的istio-ingressgateway部署，另一种是通过Kubernetes Gateway API控制器动态管理网关实例。理解这两种模式的差异，是在中标麒麟环境落地前的第一步。
二、前置环境与Istio安装
假设你已经在中标麒麟（如V10 SP2/SP3）上通过Kubernetes或KubeSphere搭建了集群。需要注意中标麒麟基于Linux内核，部分发行版默认的防火墙与SELinux策略可能拦截节点间端口，安装前建议执行systemctl stop firewalld或放行相关端口段，并确认容器运行时工作正常。
首先安装Gateway API的CRD。Istio要求先在集群中注册Gateway API资源，如果集群版本较低（如1.24以下），需要手动安装实验版或标准版CRD；Kubernetes 1.25及以上可直接安装官方GA版本的CRD：
# 下载 Gateway API 标准版 CRD 并安装 kubectl kustomize "github.com/kubernetes-sigs/gateway-api/config/crd?ref=v1.0.0" \ | kubectl apply -f - # 验证 CRD 是否注册成功 kubectl get crd | grep -E "gateways.gateway.networking|httproutes.gateway.networking"
接着安装Istio。可以通过istioctl以最小配置安装，并显式开启Gateway API支持：
# 下载并解压 istioctl 后执行 istioctl install --set profile=minimal --skip-confirmation # 查看 istiod 是否识别到 Gateway API kubectl get pods -n istio-system kubectl get gatewayclass
安装完成后，Istio会自动创建一个名为istio的GatewayClass，状态为Accepted，表示istiod已经接管了Gateway API的实现。如果这个资源不存在或状态异常，通常是CRD版本与Istio版本不匹配导致的，需要核对Istio官方文档中要求的Gateway API版本。
三、配置Gateway与HTTPRoute实现流量接入
下面用一个实际例子演示完整流程。场景是在default命名空间部署一个测试应用，通过Gateway API将域名demo.ipipp.com的流量转发到该服务。首先创建Gateway资源，它负责声明监听端口、协议以及允许挂载路由的命名空间：
apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
name: demo-gateway
namespace: istio-system
spec:
gatewayClassName: istio
listeners:
- name: http
port: 80
protocol: HTTP
allowedRoutes:
namespaces:
from: All
---
apiVersion: v1
kind: Service
metadata:
name: demo-app
namespace: default
spec:
selector:
app: demo-app
ports:
- port: 80
targetPort: 8080当这个Gateway被提交后，Istio会根据部署模式决定行为。在Kubernetes Gateway API控制器模式下，istiod会自动创建一个与之对应的Deployment和Service，pod名称类似default/demo-gateway-istio；如果只是使用复用模式，则流量会走已经存在的istio-ingressgateway。无论哪种模式，都可以通过kubectl get gateway demo-gateway查看分配的地址。
接下来创建HTTPRoute定义路由规则。下面的示例将根路径流量转发到demo-app服务的80端口，并对以api开头的请求进行路径重写：
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
name: demo-route
namespace: default
spec:
parentRefs:
- name: demo-gateway
namespace: istio-system
hostnames:
- demo.ipipp.com
rules:
- matches:
- path:
type: PathPrefix
value: /api
filters:
- type: URLRewrite
urlRewrite:
path:
type: ReplacePrefixMatch
replacePrefixMatch: /
backendRefs:
- name: demo-app
port: 80
- backendRefs:
- name: demo-app
port: 80这里有几个细节需要注意。parentRefs中必须正确填写Gateway所在的命名空间，否则路由无法挂载，HTTPRoute状态中的ResolvedRefs条件会提示引用错误。hostnames支持通配符，例如*.ipipp.com可以匹配所有子域名。backendRefs指向的Service必须与HTTPRoute在同一个命名空间，跨命名空间引用需要通过ReferenceGrant显式授权。
验证时可以找到网关对应的Service外部地址，配置本地hosts解析后用curl测试：
# 获取网关地址
kubectl get gateway demo-gateway -n istio-system -o jsonpath='{.status.addresses[0].value}'
# 配置 hosts 后测试连通性
curl -H "Host: demo.ipipp.com" http://<网关地址>/api/health四、Istio高级特性与Gateway API的结合
Gateway API规范本身只定义了通用的路由能力，而Istio允许通过扩展字段补充网格特有的功能。例如可以在HTTPRoute中添加destination中间件实现请求改写，也可以直接编写Istio原生的HTTPRouteFilter等扩展资源。对于已在使用VirtualService的团队，Istio提供了平滑兼容方案：VirtualService可以通过delegate机制与HTTPRoute配合工作，网关层使用标准的Gateway资源，内部细粒度治理仍交给VirtualService，实现渐进式迁移。
证书管理方面，Gateway的listener可以引用Secret配置HTTPS终止。在中标麒麟环境中，如果使用国密证书，需要确认网关代理容器内的相关算法支持情况，必要时通过自定义网关镜像或配置Envoy的TLS上下文来适配，这是信创场景中经常被忽略但十分关键的一点。
可观测性上，Gateway API创建的网关实例与普通Envoy代理一致，会正常上报遥测数据到Istio的指标体系，Prometheus与Kiali中的展示方式与传统Ingress Gateway没有区别，运维监控体系可以无缝沿用。
五、常见问题与排查思路
实际部署中最常见的问题有三类。一是Gateway状态长时间为空，通常是istiod没有正确识别Gateway API CRD，检查istiod日志中是否有gateway api相关的警告，并确认CRD版本；二是HTTPRoute的parentRef挂载失败，查看kubectl describe httproute输出中的Parents条件，多数是命名空间或allowedRoutes配置问题；三是访问返回404或503，这往往是backendRefs指向的服务不存在或端口不匹配，可以通过istioctl proxy-config命令检查网关实例的实际路由配置。
另外提醒一点，如果选择自动部署网关实例的模式，要关注节点资源压力。每个Gateway默认会拉起独立的代理Pod，在中标麒麟环境的小规模集群中，建议合理规划副本数，或通过注解定制网关的Deployment参数，避免资源浪费。
整体来看，在中标麒麟上基于Gateway API实现Istio入口管理，与主流Linux发行版上的操作步骤基本一致，重点在于确认操作系统层面的网络策略不阻塞、Gateway API CRD版本与Istio匹配，以及理解Istio两种网关部署模式的选择。完成从Ingress到Gateway API的迁移后，路由配置的标准化程度和团队协作效率都会有明显提升，也为后续接入更多符合Gateway API规范的治理能力打下基础。
中标麒麟IstioGateway API修改时间：2026-09-15 06:44:36