規格建議應用程式擁有者應透過 Kubernetes Service 資源設定 parentRef,為網格服務設定 Route resource (有時稱為 xRoute) 的流量規則。具體做法取決於 Kubernetes Service 的「前端」和「後端」角色,如 GEP-1324:Gateway API 中的服務網格所述,其中「前端」角色用做 parentRef,而「後端」角色則用做 backendRef。Service相容的實作項目會使用 Service 名稱來比對流量,並使用 backendRef 端點做為標準 IP 位址。
GAMMA 計畫 (Service Mesh 的 Gateway API) 定義 Gateway API 如何用於同一叢集內的服務間或東/西向流量。GAMMA 的目標是確立如何使用 Gateway API 設定服務網格,同時盡量減少 Gateway API 的修改,並維持其以角色為導向的本質。GAMMA 也強調,無論 Gateway API 的基礎技術或 Proxy 為何,都應在各種服務網格實作項目中推動一致性。
GAMMA 會利用 Gateway API 規格中的現有擴充點,因此不需要變更 API 或新增資源。方法是擴充路徑資源定義 (Gateway API 中的 GRPCRoute 或 HTTPRoute),以發出服務網格用途的信號,具體做法是將路徑資源與服務資源建立關聯,如「服務網格的 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"]],["上次更新時間:2025-09-04 (世界標準時間)。"],[],[],null,["# Overview\n========\n\n|\n| **Preview**\n|\n|\n| This product or feature is subject to the \"Pre-GA Offerings Terms\" in the General Service Terms section\n| of the [Service Specific Terms](/terms/service-terms#1).\n|\n| Pre-GA products and features are available \"as is\" and might have limited support.\n|\n| For more information, see the\n| [launch stage descriptions](/products#product-launch-stages).\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.21/docs/gateway/prepare-gateway)\n- [Gateway Reference](/service-mesh/v1.21/docs/gateway/reference)"]]