How the k8s Gateway API enables Multi-cluster Backend development

Kubernetes is a great environment to run backends for modern mobile and single page applications, but it presents some challenges for ongoing development. The production environment contains the released versions of backends, what about development and test versions? Development environments have different requirements than production, they could be running on a different cloud, on-premise or on a developers desktop. In-cluster solutions such as service meshes or external API Gateways can be configured to achieve traffic splitting but the solutions are bespoke and complicated.

The new Kubernetes Gateway API solves the multi-cluster/multi-cloud traffic splitting problem when combined with a Gateway situated outside of the clusters.

The Gateway API is an evolution of the Ingress and LoadBalancer API under development by the Kubernetes Network SIG addressing many cluster access shortcomings. It provides a unified k8s API for routing traffic to clusters and increases functionality enabling the configuration of API Gateways.

Traffic splitting using headers is a simple way to add a development backend to an existing application. A custom header added to the request using modheader is matched by the API Gateway and forwarded to the specified backend.

Note the pod name and nodename

The demonstration shown above is a simple React application. The original page is loaded from the first location and on load the use-effect hook fetches POD information from a second location. In the second instance, a custom header is added, epic:dev and when the page is reloaded, the request is routed to a different backend location. In this case the simulated production version is hosted at Google Cloud and the development version on a local server.

The Gateway API implements resources that are referenced to create the gateway and routing structure.

Routes are the key resource connecting Gateways and Services; HTTPRoute, TLSRoute, TCPRoute and UDPRoute are currently available. For backend traffic splitting, a HTTPRoute is used. The HTTPRoute below provides access to the backend using the URL path prefix of /api with the service name epic-apisrv.

apiVersion: gateway.networking.k8s.io/v1alpha2
kind: HTTPRoute
metadata:
  name: demoapi
  namespace: demoapi
  resourceVersion: "61796"
  uid: ce81f74b-6512-4e18-826c-fe1a9ebb4a0c
spec:
  parentRefs:
  - group: gateway.networking.k8s.io
    kind: Gateway
    name: uswest-gtwapi
  rules:
  - backendRefs:
    - group: ""
      kind: Service
      name: epic-apisrv
      port: 8080
      weight: 1
    matches:
    - path:
        type: PathPrefix
        value: /api

The benefit of using the Gateway API is that this configuration is undertaken by the developer in their namespace. Below is the HTTPRoute for the developer’s backend that includes the headers required to match this route.

apiVersion: gateway.networking.k8s.io/v1alpha2
kind: HTTPRoute
metadata:
  name: apidevdemo
  namespace: demodevapi
spec:
  parentRefs:
  - group: gateway.networking.k8s.io
    kind: Gateway
    name: uswest-gtwapi
    namespace: demoapi
  rules:
  - backendRefs:
    - group: ""
      kind: Service
      name: epic-apisrv
      port: 8080
      weight: 1
    matches:
    - headers:
      - name: epic
        type: Exact
        value: dev
      path:
        type: PathPrefix
        value: /api

When the downstream gateway is Acnodal EPIC, the new routing rule shown below for the development backend is merged with the production rules. EPIC and its associated Gateway Controller look after getting request to the PODs. In this manner, the developer receives the production version of the application integrated with their development backend. Many permutations of mixing components can be implemented.

The configuration pattern follows the standard Gateway API with two exceptions:

1. The EPIC Gateway Template has sharing enabled.
2. Both clusters have identical GatewayClassConfig and GatewayClass configured

apiVersion: gateway.networking.k8s.io/v1alpha2
kind: Gateway
metadata:
  annotations:
    acnodal.io/epic-sharing-key: b7cc09b1-25e2-4dc3-a823-3dd8fa1f78b3
  name: uswest-gtwapi
  namespace: demoapi
spec:
  gatewayClassName: uswest-gtwapi
  listeners:
  - allowedRoutes:
      namespaces:
        from: All
    name: gwapi
    port: 443
    protocol: HTTPS
status:
  addresses:
  - type: IPAddress
    value: 72.52.101.1
  - type: Hostname
    value: uswest-gtwapi-demoapi-epictest-uswest.epick8sgw.net
  conditions:
  - lastTransitionTime: "2022-04-11T14:29:38Z"
    message: Announced to EPIC
    observedGeneration: 1
    reason: Valid
    status: "True"
    type: Ready

To add a HTTPRoute for the development cluster, create a Gateway that includes a sharing key that is provided from the original gateway owner. The Gateway in the development cluster will be created and attached to the initial Gateway as shown by sharing the same IP address and FQDN. To add the development destination add a Route with the overrides required, in this case custom headers.

If you’re interested in trying traffic splitting yourself, you can learn more and try the Open Source EPIC platform at https://www.epic-gateway.org/

The purpose of this article is to raise awareness of the Kubernetes Gateway API and the functionality that it enables. We used the Gateway platform that we have developed for that purpose.