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 集群内的入站流量(南北)和服务网格(东西)流量。
该规范建议应用所有者应通过使用 Kubernetes Service 资源作为 parentRef 配置 Route resource(有时称为 xRoute),来配置网格服务的流量规则。此方法取决于 Kubernetes Service 的“frontend”和“backend”角色(如 GEP-1324:Gateway API 中的 Service Mesh 中所定义),其中“frontend”角色用作 parentRef,而 Service 的“backend”角色用作 backendRef。符合规范的实现使用 Service 名称来匹配规范 IP 地址的流量和 backendRef 端点。
适用于 Mesh 的 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 服务网格实现之间(无论底层技术或代理如何)促进一致性的重要性。
[[["易于理解","easyToUnderstand","thumb-up"],["解决了我的问题","solvedMyProblem","thumb-up"],["其他","otherUp","thumb-up"]],[["很难理解","hardToUnderstand","thumb-down"],["信息或示例代码不正确","incorrectInformationOrSampleCode","thumb-down"],["没有我需要的信息/示例","missingTheInformationSamplesINeed","thumb-down"],["翻译问题","translationIssue","thumb-down"],["其他","otherDown","thumb-down"]],["最后更新时间 (UTC):2025-09-04。"],[],[],null,["# Overview\n========\n\nCloud Service Mesh provides service networking capabilities to your\napplications, including advanced traffic management, observability, and security.\nHowever, configuring and operating a service mesh is a complex task. This page\ndescribes configuring Cloud Service Mesh with the Kubernetes\nGateway APIs. These APIs are designed to simplify and improve your overall mesh\nconfiguration experience.\n\nThe Kubernetes Gateway APIs for Mesh let you configure Cloud Service Mesh for\nboth proxyless gRPC and Envoy proxy deployments. The Gateway API for Mesh model\nenables several key benefits:\n\n- Gateway APIs provide a single, consistent interface for managing both ingress (north-south) and service mesh (east-west) traffic within your Kubernetes cluster.\n- Service meshes enable advanced traffic routing patterns. Gateway APIs allow you to design and manage complex routing rules.\n- With Gateway APIs, developers can focus on defining high-level routing rules and policies to their microservice without needing in depth knowledge of the underlying service mesh implementation.\n- The API is designed to be extensible, allowing for future enhancements and support for new protocols and use cases.\n- Gateway APIs have strong community backing and are supported by a growing ecosystem of service mesh providers and tools.\n\nThe [GAMMA initiative](https://gateway-api.sigs.k8s.io/mesh/gamma/) work for\nsupporting service mesh use cases has been part of the Standard Channel since\nv1.1.0 and is considered GA.\n\nThe [spec](https://gateway-api.sigs.k8s.io/geps/gep-1426/#implementation-details-and-constraints)\nproposes that an application owner should configure traffic rules for a mesh\nservice by configuring a `Route resource` (sometimes referred to as `xRoute`)\nwith a Kubernetes `Service` resource as `parentRef`. The approach depends on\nKubernetes `Service`'s \"frontend\" and \"backend\" roles as defined in\n[GEP-1324: Service Mesh in Gateway API](https://gateway-api.sigs.k8s.io/geps/gep-1324/#service),\nwhere the \"frontend\" role is used as a `parentRef` and the \"backend\" role of\n`Service` is used as a `backendRef`. The conformant implementation uses the\n`Service` name to match traffic and `backendRef` endpoints for the canonical IP\naddresses.\n\nGateway API for Mesh\n--------------------\n\n[Gateway API](https://gateway-api.sigs.k8s.io/#introduction), a Kubernetes\nproject, focuses on Layer 4 and 7 routing within Kubernetes. It succeeds Ingress,\nLoad Balancing, and Service Mesh APIs. Designed to be versatile, descriptive,\nand role-centric, its configurations are primarily in the Routing layer.\nProtocol-specific resources like `HTTPRoute` and `GRPCRoute` enable advanced\ningress and mesh routing.\n\nThe [GAMMA Initiative](https://gateway-api.sigs.k8s.io/mesh/gamma/) (Gateway API\nfor Service Mesh) defines how Gateway API may also be used for inter-service\nor [East/West traffic](https://gateway-api.sigs.k8s.io/concepts/glossary/#eastwest-traffic)\nwithin the same cluster. GAMMA aims to establish how to use the Gateway API to\nconfigure a service mesh with minimal modifications to the Gateway API while\nupholding its [role-oriented](https://gateway-api.sigs.k8s.io/concepts/roles-and-personas/)\nnature. GAMMA also emphasizes the importance of promoting consistency among\nvarious service mesh implementations of the Gateway API, regardless of their\nunderlying technology or proxy.\n\nGAMMA leverages existing extensibility points in the Gateway API spec, requiring\nno API changes or new resources. This is done by extending the route resource\ndefinitions ([GRPCRoute](https://gateway-api.sigs.k8s.io/api-types/grpcroute/)\nor [HTTPRoute](https://gateway-api.sigs.k8s.io/api-types/httproute/) in the\nGateway API) to signal the service mesh use-case, specifically by associating\nthe route resources with Service resources as described in\n[Gateway API for Service Mesh](https://gateway-api.sigs.k8s.io/mesh/#how-the-gateway-api-works-for-service-mesh).\n\nThe following example illustrates the mesh use-case in the use of HTTPRoute: \n\n apiVersion: gateway.networking.k8s.io\n kind: HTTPRoute\n metadata:\n name: echo-route\n spec:\n parentRefs:\n - kind: Service\n group: \"\"\n name: echo-service\n rules:\n - backendRefs:\n - name: echo-v1\n port: 80\n weight: 9\n - backendRefs:\n - name: echo-v2\n port: 80\n weight: 1\n\nThe HTTPRoute references a `Service` as its `parentRef`, which signals that the\nHTTPRoute route is configured for service mesh use case. In the previous example,\nthe echo-service Service is specified as the `parentRef`, which means the\nHTTPRoute is attached to the frontend of echo-service. Any traffic sent to\necho-service by a client is routed according to the HTTPRoute echo-route.\n\nGRPCRoute is another Kubernetes Gateway API resource, which is used to route\ngRPC traffic to Kubernetes services. Users choose to use GRPCRoute instead of\nHTTPRoute when they want to specifically route gRPC traffic and take advantage\nof features tailored for gRPC, such as gRPC method and service matching.\n\nThe following example illustrates the use of GRPCRoute: \n\n apiVersion: gateway.networking.k8s.io\n kind: GRPCRoute\n metadata:\n name: echo-route\n spec:\n parentRefs:\n - kind: Service\n group: \"\"\n name: echo-service\n rules:\n - matches:\n - method:\n service:echo_basic.grpcecho.GrpcEcho\n method: Echo\n backendRefs:\n - name: grpc-infra-backend-v1\n port: 8080\n - matches:\n - method:\n service:echo_basic.grpcecho.GrpcEcho\n method: EchoTwo\n backendRefs:\n - name: grpc-infra-backend-v2\n port: 8080\n\nJust like the HTTPRoute example, this GRPCRoute is configured for service mesh\nuse cases. Any traffic sent to `xds:///echo-service.default.svc.cluster.local:8080`\nby a proxyless gRPC client is routed according to the GRPCRoute echo-route. The\nroute rules in this example match to a gRPC method and route the traffic to a\nspecific `backendRef`. GRPCRoutes can also be used to route requests from\nproxied clients with sidecar injections, like Envoy, when the `xds:///` prefix\nis dropped.\n| **Note:** With Kubernetes Gateway API for Mesh, all services within the Cloud Service Mesh are required to reside in a single cluster.\n\nWhat's next\n-----------\n\n- [Prepare a gateway](/service-mesh/v1.24/docs/gateway/prepare-gateway)\n- [Gateway Reference](/service-mesh/v1.24/docs/gateway/reference)"]]