概览

Cloud Service Mesh 为您的应用提供服务网络功能，包括高级流量管理、可观测性和安全性。但是，配置和运营服务网格是一项复杂的任务。本页介绍了如何使用 Kubernetes Gateway API 配置 Cloud Service Mesh。这些 API 旨在简化和改进整体网格配置体验。

借助适用于 Mesh 的 Kubernetes Gateway API，您可以为无代理 gRPC 和 Envoy 代理部署配置 Cloud Service Mesh。适用于 Mesh 的 Gateway API 模型具有多项关键优势：

Gateway API 提供了一个一致的单一接口，用于管理 Kubernetes 集群中的入站（南北）流量和服务网格（东西）流量。
服务网格支持高级流量路由模式。借助网关 API，您可以设计和管理复杂的路由规则。
借助 Gateway API，开发者可以专注于为其微服务定义高级路由规则和政策，而无需深入了解底层服务网格实现。
该 API 旨在实现可扩展性，以便未来进行增强并支持新协议和用例。
Gateway API 拥有强大的社区支持，并由不断壮大的服务网格提供商和工具生态系统提供支持。

从 1.1.0 版开始，用于支持服务网格用例的 GAMMA 计划已纳入标准渠道，并被视为 GA 版本。

规范建议应用所有者应通过将 Route resource（有时称为 xRoute）配置为 Kubernetes Service 资源并将其设置为 parentRef，为网格服务配置流量规则。此方法取决于 GEP-1324：Gateway API 中的服务网格中定义的 Kubernetes Service 的“前端”和“后端”角色，其中“前端”角色用作 parentRef，Service 的“后端”角色用作 backendRef。符合规范的实现使用 Service 名称来匹配规范 IP 地址的流量和 backendRef 端点。

适用于网格的 Gateway API

Gateway API 是一个 Kubernetes 项目，专注于 Kubernetes 中的第 4 层和第 7 层路由。它继承了 Ingress、负载均衡和 Service Mesh API。该模型旨在实现多用途、描述性和以角色为中心，其配置主要位于路由层。HTTPRoute 和 GRPCRoute 等特定于协议的资源可实现高级入站和网格路由。

GAMMA 计划（适用于服务网格的 Gateway API）定义了如何将 Gateway API 用于同一集群内的服务间流量或东西向流量。GAMMA 旨在确定如何使用 Gateway API 配置服务网格，同时尽可能减少对 Gateway API 的修改，并保持其以角色为导向的特性。GAMMA 还强调了促进 Gateway API 的各种服务网格实现之间的一致性的重要性，无论其底层技术或代理如何。

GAMMA 利用 Gateway API 规范中的现有可扩展性点，无需进行任何 API 更改或创建新资源。为此，您可以扩展路由资源定义（Gateway API 中的 GRPCRoute 或 HTTPRoute）以指示服务网格用例，具体方法是将路由资源与服务资源相关联，如适用于服务网格的 Gateway API 中所述。

以下示例展示了使用 HTTPRoute 时的网格用例：

apiVersion:  gateway.networking.k8s.io
kind: HTTPRoute
metadata:
  name: echo-route
spec:
  parentRefs:
  - kind: Service
    group: ""
    name: echo-service
  rules:
  - backendRefs:
    - name: echo-v1
      port: 80
      weight: 9
  - backendRefs:
    - name: echo-v2
      port: 80
      weight: 1

HTTPRoute 图

HTTPRoute 将 Service 引用为其 parentRef，这表示 HTTPRoute 路由已针对服务网格用例进行配置。在上面的示例中，echo-service 服务被指定为 parentRef，这意味着 HTTPRoute 已附加到 echo-service 的前端。客户端发送到 echo-service 的所有流量都会根据 HTTPRoute echo-route 进行路由。

GRPCRoute 是另一个 Kubernetes Gateway API 资源，用于将 gRPC 流量路由到 Kubernetes 服务。当用户想要专门路由 gRPC 流量并利用专为 gRPC 量身定制的功能（例如 gRPC 方法和服务匹配）时，会选择使用 GRPCRoute 而非 HTTPRoute。

以下示例展示了 GRPCRoute 的使用：

apiVersion:  gateway.networking.k8s.io
kind: GRPCRoute
metadata:
  name: echo-route
spec:
  parentRefs:
  - kind: Service
    group: ""
    name: echo-service
  rules:
   - matches:
    - method:
        service:echo_basic.grpcecho.GrpcEcho
        method: Echo
    backendRefs:
    - name: grpc-infra-backend-v1
      port: 8080
  - matches:
    - method:
        service:echo_basic.grpcecho.GrpcEcho
        method: EchoTwo
    backendRefs:
    - name: grpc-infra-backend-v2
      port: 8080

GRPCRoute 图

与 HTTPRoute 示例一样，此 GRPCRoute 配置为服务网格用例。无代理 gRPC 客户端向 xds:///echo-service.default.svc.cluster.local:8080 发送的任何流量都会根据 GRPCRoute 回声路由进行路由。此示例中的路由规则与 gRPC 方法匹配，并将流量路由到特定的 backendRef。当 xds:/// 前缀被舍弃时，GRPCRoutes 还可用于路由来自具有 Sidecar 注入（例如 Envoy）的代理客户端的请求。

单集群网格示意图

概览

适用于网格的 Gateway API

后续步骤