In this TechUp we will take a look at how to build an API Gateway with the Gateway API and why it makes sense to use them together. In addition, we will take a closer look at the Cilium Gateway API Implementation using a concrete example. 🚀

What is API-Gateway?

An API gateway is the central component of a microservice architecture that manages traffic to different backend systems.

You can think of an API gateway like a traffic controller; all green cars are sent in one direction, all yellow cars in another direction. Furthermore, cars without roofs are rejected (rain is reported) and pedestrians are blocked completely.

Figure: Basic Architecture

Basic tasks of an API Gateway:

Simplify and centrally manage communication connections.

Without an API Gateway, every consumer, frontend, etc. would have to know every address of, for example, all microservices. That becomes problematic if you want to split an existing service, because each client has to implement the new address. Thus, an API Gateway implements a loose coupling between two services.

Same-Origin-Policy.

With the use of an API Gateway, annoying CORS (Cross-Origin Resource Sharing) problems and exceptions are eliminated, since all traffic can be made “path-based”.

Protection of specific API resources

An API Gateway can easily determine whether a client is granted access to a path or not. This is done based on various characteristics such as domain name, namespace, headers, tokens or other authentication information. Protection against attacks through rate limiting, for instance, are also important functions of an API Gateway.

Routing

Simply put, an API Gateway is a powerful reverse proxy: It forwards traffic to the appropriate destination instance.

In this context, an API Gateway can also perform traffic splitting (such as Canary or Blue-Green rollouts) or, for example, route only 10% of the requests to a new version of a backend microservice.

Supervision, Monitoring

A permanent monitoring of all API interfaces is also a key component. This enables the very rapid detection and interception of malfunctions, performance problems or failures.

You can find more information about proxies in this TechUp here. 😁

When does the use of an API-Gateway make sense?

Even on a “small scale”, i.e. for smaller projects and architectures, the use of an API Gateway makes perfect sense! Consumers of APIs have a familiar point of contact - to put it bluntly, they don’t care about things like management, structure, tools, systems, and above all the addresses behind them.

What is Gateway API?

Wait, we were just talking about an API Gateway, and now we’re talking about Gateway API? 🤯

The Kubernetes Gateway API is an open source project run by the SIG-Network community. In it, they define different resources to model service networking in Kubernetes in a standardized way. We are “only” talking about Custom Resource Definitions (CRDs), which independently standardize Layer 4 and Layer 7 routing for Kubernetes. The goal is to create a standardized layer to implement different API Gateway functionalities in a Kubernetes cluster without having to do a complete “vendor lock-in”.

So, in simple terms, with Gateway API we can define API Gateways in a standardized format.

Gateway API has been in beta since July 2022 and is currently available in a v1beta1 version, with the first release going back to 2020.

Gateway API Specification

The following components are described in the Gateway API Spec (among others):

• GatewayClasses: A template that allows an Infrastructure Provider to define templates (for example, Internet or Private as a template, depending on whether the traffic is public or not).
• Gateway: The instance of a GatewayClass, e.g. a TLS Gateway, which directly stores the correct certificates.
• HTTPRoute (Layer 7): An HTTP route is used to multiplex HTTP requests. Routing can happen for example based on a header
• GRPCRoute (Layer 7): Used to route gRPC requests.
• TLSRoute: Routing of TLS, e.g. HTTPS traffic where verification of HTTP request is not necessary
• TCPRoute/UDPRoute (Layer 4): Used to map a port to a backend.
• ReferenceGrant: A kind of handshake to allow cross-namespace communication, so that e.g. the gateway in one namespace is allowed to read and use the routes of another namespace.
• Service: The Kubernetes service that ultimately receives the traffic.

Gateway and Routes are created separately from each other. This allows the gateway controller to be replaced without having to do anything to the routes. This modular structure results in clearly defined areas of responsibility for an Infrastructure Provider, a Cluster Operator and an Application Developer.

Let’s take a look at the components using an example:

Figure: Source: https://gateway-api.sigs.k8s.io/

Here we can see that a gateway “foo” knows different HTTPRoutes in different namespaces, and routes the traffic to the correct service accordingly.

At this point it should be mentioned that Gateway API is not a replacement for the Kubernetes Ingress API. Unlike Gateway API, Ingress API mostly aims at exposing different HTTP routes. Gateway API, on the other hand, offers multiple options than just HTTP and is better integrated with infrastructure components, which should provide better management for cluster providers.

For example, current implementations include the following:

• Cilium
• Istio
• Envoy Gateway
• Emissary-Ingress (Ambassador API-Gateway)
• HashiCorp Consul
• Google Kubernetes Engine
• HAProxy
• NGINX Kubernetes Gateway

Cilium Gateway API

We will now take a closer look at the Cilium Gateway API implementation. At this point it should be mentioned that its status is still in the “work in progress” phase.

If you are not familiar with Cilium, eBPF and the like, here is everything you need to know!

• eBPF-based networking with Cilium - What is it and what can it do?
• Easily build and share eBPF logic with Bumblebee
• Strengthen your system with Tetragon’s eBPF-based security-observability and runtime-enforcement capabilities

With the currently available version of Cilium 1.12, support for Gateway API was added in July 2022, and is under continuous development. With version 1.13 there will be numerous updates. Stay tuned!

Cilium Service Mesh

Cilium itself uses Gateway API as part of its Service Mesh concept. The goal is to make Cilium compatible with other service mesh providers like Istio via this open standard.

Figure: Source: https://isovalent.com/blog/post/cilium-service-mesh/

Cilium Gateway API Example

What exactly does it mean to set up Cilium as a Gateway API implementation?

Prerequisites:

• Latest Cilium version, e.g. v1.13.0-rc5
• Cilium must be used as CNI.
• Cilium must act as a KubeProxyReplacement (mode partial or strict).
• The Gateway API CRDs must be installed beforehand.

Cilium will then automatically install a GatewayClass, behind which is the “io.cilium/gateway-controller”.

After that we can create our first gateway and HTTP route:

• We define a gateway with a listener on port 80, which listens to all routes in the same namespace.
• Using the “gatewayClassName” we reference the Cilium implementation.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14

---
apiVersion: gateway.networking.k8s.io/v1beta1
kind: Gateway
metadata:
  name: my-b-nova-gateway
spec:
  gatewayClassName: cilium
  listeners:
  - protocol: HTTP
    port: 80
    name: web-b-nova-gw
    allowedRoutes:
      namespaces:
        from: Same

• Then we define two HTTP Routes for our gateway (via parentRefs)
• hello route
  • traffic on /hello (on port 80, defined in the gateway) is routed to the hello service on port `9080
• b-nova-page route
  • traffic coming to / with user=tom header and secretcode=123 queryparam is routed to b-nova-page service on port `9080

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33

---
apiVersion: gateway.networking.k8s.io/v1beta1
kind: HTTPRoute
metadata:
  name: http-b-nova-app-1
spec:
  parentRefs:
  - name: my-b-nova-gateway
    namespace: default
  rules:
  - matches:
    - path:
        type: PathPrefix
        value: /hello
    backendRefs:
    - name: hello
      port: 9080
  - matches:
    - headers:
      - type: Exact
        name: user
        value: tom
      queryParams:
      - type: Exact
        name: secretcode
        value: 123
      path:
        type: PathPrefix
        value: /
      method: GET
    backendRefs:
    - name: b-nova-page
      port: 9080

Want to learn more about the Gateway API, Cilium, or DevSevOps and Cloud Native topics in general? Listen to our podcast decodify or contact us directly! 🎉

Conclusion

Use Gateway API! 👌

Even though the Kubernetes Gateway API is still in its infancy or beta phase, we already recommend using it now, as more and more providers, frameworks, plugins and tools support the standard. The Role Base Model facilitates the management of central gateways with dedicated routes in individual namespaces and thus ensures a clear separation of responsibilities. The cluster admin can completely change the gateway, load balancing etc. without the developer or the service itself noticing or even having to change anything!

Stay tuned for more exciting Cilium topics! :)