One of the major challenges in Kubernetes is the task of bridging the gap between the internal infrastructure of your cluster and the outside world. This is achieved by deploying your application as pods, which are the building blocks of deployment in Kubernetes. The goal is to make these pods accessible to your customers, users, and end-users.

Exposing Kubernetes applications traditionally relies on a variety of methods, and these methods have their own challenges and limitations. Some of these traditional methods include:

  • Service load balancers are a common choice for exposing pods externally, however, they are often tied to specific cloud controllers, leading to portability challenges and complex load balancer management. Creating service objects as load balancers demands in-depth cloud provider knowledge, hindering the desired Kubernetes-level abstraction.
  • Cloud controller managers limit Kubernetes' flexibility by associating it with specific cloud providers, hindering workload migration.
  • Ingress controllers are more of a Kubernetes-native method of controlling application exposure in response to these difficulties, although they are mostly concerned with providing a minimal feature set and HTTP routing. This limits support for non-HTTP protocols such as gRPC.

The next development in Kubernetes application exposure is represented by the Gateway API. It provides capabilities such as traffic splitting, header-based matching, and supports a range of backends in addition to services. This guarantees compatibility between different Kubernetes implementations and effectively addresses the drawbacks of traditional service exposure methods and Ingress controllers.

This tutorial provides a hands-on exploration of the Gateway API, offering insights into its architecture, components, and practical implementation. We'll explore the specifications for creating a Gateway Class, define controllers for Gateways, and establish HTTP routes.

Prerequisites

Before you follow along with this tutorial, you will need a base understanding of the following concepts:

You will also need to have the following set up to follow along:

Getting started with the Gateway API

The Gateway API is a collection of resources that model service networking in Kubernetes. These resources include GatewayClass, Gateway, HTTPRoute, and Kubernetes Service resource. The goal of the Gateway API is to advance Kubernetes service networking through widely supported, widely deployed, expressive, extendable, and role-oriented interfaces.

The API Gateway is an evolving project overseen by Kubernetes SIG-Network. It is used by products such as Gloo Edge and orchestrated by the Gateway Controller, which is similar to the Ingress Controller. The Gateway class defines the appearance and framework of gateways, with individual Gateway objects specified for specific HTTP routes across various applications, enabling smart routing based on predefined rules. It is expected that as Kubernetes develops further, the API Gateway will follow suit, adding a host of additional capabilities and improvements to meet the demands of contemporary applications.

API Gateway

There are three key personas in the Gateway API framework, and each one has distinct duties. These roles are made to make managing and exposing apps in Kubernetes easier. Let's examine each of these personas in more detail and offer instances to highlight their duties:

  1. Infrastructure Provider: The Gateway Class, which outlines the properties and organization of gateways, is largely created by the infrastructure provider. Their main focus is on the low-level infrastructure elements and settings that influence gateway behavior. An example is Civo – We are a cloud service that provides Kubernetes services and takes the role of an infrastructure provider by defining the load balancing, routing settings, and gateway integration with our cloud architecture.
  2. Cluster Operator: Cluster operators in a Kubernetes environment customize Gateway objects tailored to the unique requirements of a project and define routing policies and access control rules to ensure the smooth operation of the gateway infrastructure.
  3. Application Developer: The routes to apps within the Kubernetes cluster are what application developers are concentrating on establishing. They have an in-depth understanding of the specifications of the application and how traffic should be routed to get the best results.

Defining Specifications for Creating a Gateway Class

The Gateway Class is an essential object within the Kubernetes system that functions as a gateway into a cluster. Its definition, along with others, is outlined in the specifications section. Each controller within this system has a specific purpose, which you can find detailed in the controller section.

Occasionally, a controller might need additional settings. These can be supplied through parameters, which could include reference parameters, a specific configuration, IP pools, and data regarding where the gateways can locate the IPs assigned to them.

To establish these gateways, at least one gateway definition is necessary.

You'll need to apply the following YAML configuration to your cluster to create a Gateway class:

# GatewayClass for Gateways that define Internet-facing applications:
kind: GatewayClass
metadata:
      name: internet
spec:
      controllerName: “example.net/gateway-controller”
      parametersRef:
      group: example.net/v1alpha1
      kind: Config
      name: internet-gateway-config
- - - 
kind: Config
apiVersion: example.net/v1alpha1
metadata:
      name: internet-gateway-config
spec: 
      ip-address-pool: internet-vips
- - -

In this sample code for defining a Gateway class, the controller is defined by controller, and the parameters for this controller are defined by the paremetersRef, and Config commands. Additionally, the ip-address-pool houses the IP pool where the gateway picks up IP addresses from.

Configuring a Gateway using Controllers

A Gateway is in charge of handling and directing network traffic in Kubernetes. The properties and behavior of a sample Gateway are defined by the YAML configuration below:

kind: Gateway
apiVersion: gateway.networking.k8s.io/v1
metadata:
      name: prod-web
spec: 
      gatewayClassName: acme-lb
      listeners:
      -  protocol: HTTP
      port: 80
      routes:
         kind: HTTPRoute
         selector: 
    matchLabels:
         gateway: prod-web-gw

In this YAML configuration, the Gateway is defined by its class name in the command gatewayClassName. The listeners command provides parameters for the Gateway traffic and for the port it listens to.

In this code, the listeners are generated from the Gateway class name: acme-lb to listen to port: 80 for HTTP traffic, and to match the route that has the prod-web-gw.

Configuring HTTP Routes in the Gateway API

Kubernetes defines an HTTP route using a YAML file with properties such as the kind, API version, name, and spec. The hostname is specified in the YAML file, and incoming traffic that matches it is redirected to a designated service according to the rules specified in the rules section. This service then forwards the traffic to the corresponding pod, completing the networking process.

kind: HTTPRoute
apiVersion: gateway.networking.k8s.io/v1
metadata:
      name: foo-route
      labels:
         gateway: prod-web-gw
spec: 
    hostnames: 
    -   foo.example.com
    rules:
    -   matches:
        - path:
              type: Prefix
              value: /login
        forwardTo:
        - serviceName:  foo-svc
          port: 8080

In that configuration, the HTTP Route is created by matching the traffic for the hostname. In this sample, the hostname is foo.example.com, and the corresponding traffic is prod-web-gw which is defined by the gateway command. The rules command in the code sample is used to port forward a service to port: 8080. In this sample, the serviceName is foo-svc

Summary

The Gateway API in Kubernetes offers a powerful way to expose your application, boasting advantages such as enhanced features, advanced routing, and extensive protocol support, providing an alternative to traditional methods such as Ingress controllers. With clearly defined roles for infrastructure providers, cluster operators, and application developers, the Gateway API ensures efficient deployment processes. Although creating gateways and HTTP routes involves a detailed process, the end result is a smarter, streamlined application.

With flexibility and adaptability at its core, the Gateway API future-proofs your application deployments.

Further resources

If you want to know more about Networking and the Kubernetes Gateway API, take a look at these resources: