Gateway API for Service Mesh Management & Administration — GAMMA
Navigating Service Mesh Evolution with GAMMA: Exploring Use Cases
The initial focus of the Kubernetes Gateway API was primarily centred on addressing N-S traffic, which pertains to traffic flowing from outside a cluster to inside a cluster & vice versa.
A year ago, I authored an article delving into the Kubernetes Gateway API, and you can refer to it quickly here: https://medium.com/@sanjimoh/kubernetes-gateway-api-a-successor-to-existing-kubernetes-ingress-19bb3bebbb74.
As time has passed, the rising popularity of Service Mesh has driven efforts toward developing GAMMA, which stands for Gateway API for Mesh Management and Administration.
GAMMA’s objectives are as follows —
- To establish how the Gateway API can be utilised to configure a service mesh, aiming to keep alterations to the Gateway API to a minimum & always upholding its role-oriented nature.
- To promote consistency in the implementation of the Gateway API across various service mesh projects, regardless of their technology stack or proxy.
Note: The Gateway API for Service Mesh (GAMMA) initiative is still in its early stages, marked as experimental in v0.8.0. While it holds promising potential, it’s not yet recommended for production environments.
Use cases
Navigating Service Mesh with GAMMA
Basic East-West Use Case —
- Consider Ana, a developer who has deployed a workload within a cluster equipped with a GAMMA-compliant service mesh. She aims to leverage the mesh’s capabilities to safeguard her workload by:
- Rejecting incoming calls with invalid URL paths.
- Enforcing timeouts for all requests received by her workload.
2. Chihiro and Ian, the cluster administrators, have already set up the service mesh, eliminating the need for Ana to engage them.
3. Ana crafts an HTTPRoute resource that defines acceptable routes and timeouts, associating it with her workload’s Service via a parentRef. Upon applying the HTTPRoute within her workload’s Namespace, the service mesh automatically enforces the routing policy specified in the resource.
Below is an example indicating how HTTPRoute is parent referenced to a Service and not to a Gateway. This scenario exemplifies the separation of concerns enabled by GAMMA, allowing Ana to harness the service mesh’s features, including custom routing logic, without hindering requests directed to Chihiro or Ian.
kind: HTTPRoute
metadata:
name: smiley-route
namespace: faces
spec:
parentRefs:
- name: smiley
kind: Service
group: core
port: 80
rules:
...
timeouts:
request: 100msGateway and Mesh Use Case
Similar to the basic east-west use case, this scenario combines the concepts of multiple applications behind a single Gateway and basic east-west use cases.
- Chihiro and Ian, the cluster administrators, establish a cluster, a GatewayClass, and a Gateway.
- Ana and Allison, the developers, deploy their applications in the respective Namespaces.
- Ana and Allison then apply appropriate HTTPRoute resources.
Two crucial changes arise due to the involvement of a service mesh —
- If Chihiro has deployed a gateway controller configured for Service routing, they may need to switch it to endpoint routing.
- Ana and/or Allison must associate HTTPRoutes with their respective workloads’ Services to configure mesh routing logic. These could be dedicated HTTPRoutes solely for the mesh or combined HTTPRoutes that bind to both the Gateway and a Service.
The overarching principle behind this separation of concerns remains the same:
- Chihiro can enforce centralised policies like TLS at the Gateway,
- While Ana and Allison retain independent control over routing logic, traffic splitting rollout, and other aspects of both north-south & east-west routing.
GAMMA Streamlines Service Mesh Integration with Gateway API
The Gateway API for Service Mesh (GAMMA) initiative has successfully integrated service mesh capabilities into the Gateway API with minimal modifications.
The primary change involves associating individual route resources, such as HTTPRoute, directly with Service resources when configuring a service mesh. This approach is justified by the assumption that there will typically be only one active mesh within a cluster, rendering the Gateway and GatewayClass resources unnecessary for mesh management. Consequently, the Service resource becomes the most suitable binding point for routing information.
This direct binding mechanism offers several advantages:
- Simplified Configuration: The direct association between Route and Service resources streamlines the configuration process, making it more intuitive and less error-prone.
- Reduced Complexity: By eliminating the need for Gateway and GatewayClass resources, GAMMA’s approach reduces the overall complexity of service mesh configuration.
- Enhanced Flexibility: The direct binding mechanism provides greater flexibility in defining routing behaviour, allowing for more granular control over traffic management.
Producer Routes vs. Consumer Routes
The relationship between the Route’s Namespace and the Service’s Namespace plays a crucial role in distinguishing between producer routes and consumer routes.
Producer Routes
Definition: A producer route resides in the same Namespace as the Service it governs.
Purpose: Producer routes are typically created by the workload’s developer to define acceptable usage patterns for the workload.
Impact: All requests originating from any client of the workload, regardless of Namespace, are affected by the producer route.
Consumer Routes
Definition: A consumer route resides in a different Namespace than the Service it governs.
Purpose: Consumer routes are typically created by consumers of the workload to refine how they interact with the workload.
Impact: Consumer routes only affect requests originating from workloads within the same Namespace as the Route.
For example, this HTTPRoute would cause all clients of the smiley workload in the fast-clients Namespace to have a 100ms timeout —
kind: HTTPRoute
metadata:
name: smiley-route
namespace: fast-clients
spec:
parentRefs:
- name: smiley
namespace: faces
kind: Service
group: core
port: 80
rules:
...
timeouts:
request: 100msUnderstanding the Request Flow in a GAMMA-Compliant Mesh Environment
In the context of a GAMMA-compliant mesh environment, the typical flow of an east/west API request follows a structured sequence —
- Initiation: A client workload initiates a request directed towards
http://foo.ns.service.cluster.local. - Request Identification: The mesh data plane intercepts the incoming request, recognising it as traffic destined for the
fooService within thensNamespace. - Route Processing:The data plane proceeds to identify Routes associated with the
fooService.
The following scenarios govern the handling of the request —
a. No Associated Routes: In the absence of any associated Routes, the request is unconditionally permitted, and the ‘’ workload itself is considered the target destination.
b. Associated Routes Exist: If there are associated Routes, and the request aligns with at least one of them, the data plane uses the backendRefs from the highest-priority matching Route to determine the destination workload.
c. Unmatched Request: However, in instances where associated Routes exist but the request fails to match any of them, the data plane rejects the request.
- Request Routing: Subsequently, the data plane directs the request towards the designated destination workload. While endpoint routing is the primary method, the data plane retains the flexibility to utilise Service routing as per the defined configuration.
Current Implementation Status of Service Mesh Solutions
- Istio — For users navigating service meshes, Istio seamlessly integrates with the GAMMA initiative’s experimental Gateway API, facilitating comprehensive east-west traffic management within the mesh. Istio 1.16 and later versions support GAMMA. This means that you can use GAMMA to configure service mesh routing in Istio 1.16 and later versions.
- Kuma — Kuma 2.3 and later support the GAMMA initiative’s experimental Gateway API support for east-west traffic management within the mesh.
- Linkerd — Linkerd 2.14 and later support the GAMMA initiative’s experimental Gateway API support for east-west traffic management within the mesh.
Parting thoughts
As service mesh technologies continue to evolve, initiatives like GAMMA push the boundaries of what’s possible in managing complex networking architectures!
While the experimental nature of GAMMA’s integration in different service mesh providers signals potential changes on the horizon, it also signifies a promising direction toward refining service mesh capabilities. GAMMA’s journey across service mesh providers serves as a testament to the collaborative efforts steering the future of service mesh, inviting practitioners and developers to contribute and shape the next phase of networking excellence.
