Introducing  Gateway API , Ingress gateway and Service Mesh in Kubernetes

The article discusses how to handle incoming traffic to your Kubernetes cluster. It uses examples from Kubernetes Ingress, Istio, and Envoy Gateway to explain the concept of an entry gateway and the Gateway API in Kubernetes.

Additionally, it covers the latest developments in the Gateway API that allow for smoother integration between Kubernetes and service mesh entry gateways.

Personal Viewpoint

• Kubernetes Ingress is outdated for current network complexities.
• Gateway API enhances Kubernetes, introducing role-based separation and cross-namespace support for multi-cloud environments, gaining wide adoption.
• Gateway API resolves the functional overlap between ingress gateways and service meshes, offering a cohesive strategy for managing all cluster traffic.

The history of Kubernetes Ingress Gateways

Kubernetes, open-sourced in June 2014, initially relied on NodePort and LoadBalancer Service types for exposing services. The Ingress API, introduced later, entered Beta in Kubernetes 1.2 and achieved General Availability in Kubernetes 1.19, evolving slowly to remain lightweight and portable. Ingress allows for simple exposure of HTTP(S) routes to services within the cluster, supporting multiple Ingress Controllers.

The following figure shows the workflow of Kubernetes Ingress.

Here’s a condensed version of the process:

1. A Kubernetes cluster administrator deploys an Ingress Controller.
2. This Ingress Controller then monitors for changes in IngressClass and Ingress objects within the Kubernetes API Server.
3. Administrators deploy gateways using IngressClass and Ingress.
4. The Ingress Controller sets up the ingress gateway and routing rules based on these configurations.
5. In cloud environments, clients access the service through the load balancer of the ingress gateway.
6. The gateway directs traffic to the appropriate backend service based on the HTTP request’s host and path.

Istio supports both Ingress and Gateway APIs. The following is a configuration example using the Istio ingress gateway. The configuration will be created using the Gateway API later in the article.

apiVersion: networking.k8s.io/v1
kind: IngressClass
metadata:
  name: istio
spec:
  controller: istio.io/ingress-controller
---
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: ingress
spec:
  ingressClassName: istio
  rules:
  - host: httpbin.example.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: httpbin
            port: 8000

Note: The ingressClassName must be specified in the Ingress spec field; otherwise, the corresponding ingress gateway will not be created.

Limitations of Kubernetes Ingress

While Kubernetes Ingress allows for the separation of the entry gateway from its underlying implementation, it still faces significant limitations:

• The Ingress configuration is overly simplistic, supporting only HTTP protocol routing.
• HTTP routing is limited to host and path matching, lacking built-in support for more advanced routing capabilities. These can only be added via annotations. For instance, to implement URL redirection with the Nginx Ingress Controller, you must use the nginx.ingress.kubernetes.io/rewrite-target annotation, which falls short of the needs for programmable routing.
• In practice, there may be a need to bind services across different namespaces to the same gateway. However, Kubernetes Ingress does not support sharing an entry gateway across multiple namespaces.
• The responsibilities for creating and managing ingress gateways are not clearly defined. This often leads to developers being tasked with not only configuring gateway routing but also with the creation and management of the gateways themselves.”

Kubernetes Gateway API

The Gateway API introduces a set of API resources, including GatewayClass, Gateway, HTTPRoute, TCPRoute, ReferenceGrant, among others. This API offers a versatile proxy API that supports a wider range of protocols beyond HTTP, and represents additional infrastructure components. This broader functionality enhances deployment and management capabilities for cluster operations.

Moreover, the Gateway API facilitates configuration decoupling by segregating resource objects, allowing for management by individuals in varied roles.

Below is an example of using the Gateway API with Istio.

apiVersion: gateway.networking.k8s.io/v1alpha2
kind: Gateway
metadata:
  name: gateway
  namespace: istio-ingress
spec:
  gatewayClassName: istio
  listeners:
  - name: default
    hostname: "*.example.com"
    port: 80
    protocol: HTTP
    allowedRoutes:
      namespaces:
        from: All
---
apiVersion: gateway.networking.k8s.io/v1alpha2
kind: HTTPRoute
metadata:
  name: http
  namespace: default
spec:
  parentRefs:
  - name: gateway
    namespace: istio-ingress
  hostnames: ["httpbin.example.com"]
  rules:
  - matches:
    - path:
        type: PathPrefix
        value: /
    backendRefs:
    - name: httpbin
      port: 8000

Similar to Ingress, the Gateway specification uses gatewayClassName to specify the controller it employs. This controller must be predefined by the platform administrator and enables the handling of requests to domain names matching *.example.com.

Application developers are then able to define routing rules within the namespace of their services (for instance, default) and link these rules to the Gateway using parentRefs and setting allowRoutes accordingly.

Once the configuration is applied, Istio automatically sets up a load balancing gateway. The operation of the Gateway API is illustrated in the subsequent figure.

The detailed process is as follows:

1. Infrastructure providers supply GatewayClass and Gateway controllers.
2. Platform operators deploy Gateway instances, which can be multiple and may use different GatewayClass objects.
3. The Gateway Controller continuously monitors for changes to GatewayClass and Gateway objects within the Kubernetes API Server.
4. Based on configurations set by platform operations, the Gateway Controller then creates the appropriate gateway.
5. Application developers configure xRoute resources to define routing rules and bind them to their services.
6. In cloud environments, clients access services through the load balancer associated with the ingress gateway.
7. The gateway directs traffic to the appropriate backend service according to the request’s matching conditions.

Based on the outlined steps, it’s evident that the Gateway API offers a distinct separation of responsibilities compared to Ingress. This architecture allows routing rules to be independent from the gateway configuration, significantly enhancing management flexibility

The figure below shows the flow of processing after the traffic enters the gateway.

From the figure, it’s shown that the route is linked to the gateway, typically deployed within the same namespace as its backend service. If located in a different namespace, the route must be explicitly granted cross-namespace referencing permissions through ReferenceGrant.

For instance, a fooHTTPRoute in the foo namespace can reference services in the bar namespace, given the proper permissions.

kind: HTTPRoute
metadata:
  name: foo
  namespace: foo
spec:
  rules:
  - matches:
    - path: /bar
    forwardTo:
      backend:
      - name: bar
        namespace: bar
---
kind: ReferenceGrant
metadata:
  name: bar
  namespace: bar
spec:
  from:
  - group: networking.gateway.k8s.io
    kind: HTTPRoute
    namespace: foo
  to:
  - group: ""
    kind: Service

As of now, the Gateway API officially supports HTTPRoute, TCPRoute, UDPRoute, and TLSRoute, while GRPCRoute is still in the experimental phase. Many gateway and service mesh projects have adopted the Gateway API. For the latest information on support and implementation status, it’s recommended to consult the official Gateway API documentation.

Ingress gateway and Service Mesh

Service meshes are primarily concerned with managing east-west traffic, meaning the internal traffic moving laterally within the Kubernetes cluster. However, many service mesh solutions also offer ingress gateway capabilities to manage incoming external traffic. For example, Istio provides extensive ingress functionalities, but its features and API can be complex.

SMI (Service Mesh Interface) is a CNCF incubation project launched in 2019, aiming to establish a standardized, vendor-neutral interface for service meshes on Kubernetes. This standardization facilitates easier interaction and integration between different service mesh implementations and Kubernetes workloads.

The relationship between the ingress gateway and the service mesh, and how they interact with each other, can be further elucidated by a diagram (not provided here) showing the areas where the Gateway API and the Service Mesh API intersect. This visualization would highlight how both APIs contribute to a more cohesive and flexible network traffic management strategy within Kubernetes environments.

The figure indicates that there’s a significant overlap between the Gateway API and SMI, particularly in the aspects that define traffic specifications. This redundancy means that certain functionalities might need to be implemented twice: once in the Gateway API and once within the service mesh framework.

Such overlaps can lead to inefficiencies and complicate the management of traffic rules and routing within Kubernetes environments.

Istio Service Mesh

Istio, not fully aligned with the SMI (Service Mesh Interface) standard, is a leading service mesh implementation known for its comprehensive traffic management capabilities. Unlike some service meshes that may develop separate policy APIs for various functions, Istio integrates these functionalities within VirtualService and DestinationRule configurations. Here’s a brief overview:

VirtualService

• Routing: Supports advanced routing techniques like canary releases, routing based on user identity, URI, headers, etc.
• Error Injection: Allows for the injection of HTTP error codes and delays to test the resilience of applications.
• Traffic Segmentation: Enables routing based on traffic percentages for A/B testing or gradual rollouts.
• Traffic Mirroring: Facilitates sending a copy of live traffic to another cluster for testing.
• Timeouts: Sets request timeouts to prevent system overload from long-running requests.
• Retries: Implements retry logic with customizable conditions, retry counts, and intervals.

DestinationRule

• Load Balancing: Configures load balancing strategies, from simple round-robin to sophisticated region-aware and weighted distribution.
• Circuit Breaking: Automatically removes failing nodes from the pool to maintain system stability, using outlier detection and connection pool settings.

In summary, VirtualService focuses on the dynamic routing of traffic, while DestinationRule deals with the management of service endpoints, including load balancing and node health. Together, these Istio configurations offer a robust framework for controlling how traffic flows through and interacts with applications within a Kubernetes cluster.

Gateway API : An entry gateway integrating Kubernetes and service mesh

The Gateway API serves as a bridging framework that integrates Kubernetes with service mesh technologies, acknowledging the functional overlaps that exist between the two.

To address the redundancy and foster a unified approach to handling common network traffic concerns, the Gateway API working group initiated the GAMMA (Gateway API Mesh Management and Administration) initiative.

The GAMMA initiative aims to streamline advanced traffic management features—like timeouts, retries, and health checks—that differ across various gateway implementations. These functionalities are to be uniformly provided across different platforms through a concept known as Policy Attachment.

apiVersion: networking.acme.io/v1alpha1
kind: RetryPolicy
metadata:
  name: foo
spec:
  override:
    maxRetries: 10
  default:
    maxRetries: 5
  targetRef:
    group: gateway.networking.k8s.io/v1alpha2
    kind: HTTPRoute
    name: foo

In the given example, a retry policy is attached to resources named foo and HTTPRoute. Policy attachments can be associated with various resource objects, each having different levels of precedence. For instance, GatewayClass is a cluster-level resource, meaning if a policy attachment is associated with it, this policy will be prioritized and applied before others.

Policies can be configured with override and default values, establishing a hierarchy of precedence across different resources within both the gateway and the service mesh infrastructure. This hierarchical model ensures that specific policies can be applied universally or overridden at more granular levels, depending on the operational requirements or design architecture.

The Gateway API is presently being investigated for its ability to manage service mesh traffic, with a number of design proposals already on the table.

Envoy Gateway

The first open-source release of Envoy Gateway, version 0.2, was launched in October 2022. Developed on the Envoy proxy and aligning with the Gateway API, this project, with Tetrate as a key initiator, aims to simplify the adoption of Envoy as an API gateway.

Envoy Gateway is designed to appeal to a wider user base by offering an expressive, extensible, and role-centric API for managing ingress and routing both L4 and L7 traffic. This foundation enables vendors to create added-value products atop the API gateway.

Envoy has long been a preferred cloud-native proxy, widely used across various applications even before the Envoy Gateway was introduced. Its adoption in numerous gateway solutions and as the default sidecar proxy within the Istio service mesh, which configures distributed agents through the xDS protocol, highlights its significance.

Envoy Gateway continues this trend by utilizing xDS for configuring the Envoy clusters, underpinning its robust architecture as depicted in the ensuing diagram.

The infrastructure provider will supply you with GatewayClass. You can initiate an Envoy Gateway by declaring a Gateway. The routing rules and policy attachments defined in your Gateway will be communicated to the Envoy cluster via the xDS protocol.

Conclusion

The Gateway API marks a leap forward from Kubernetes’ Ingress API, providing clearer guidelines for gateway providers and enhancing ingress functionality with portability in mind. It also simplifies gateway management through a clear separation of duties.

The GAMMA initiative aims to merge service mesh ingress with the Gateway API, potentially expanding its use to manage internal cluster traffic. With policy attachments in play, the Gateway API’s future in facilitating both north-south and east-west traffic flows is promising.