For many years, Kubernetes users have wanted more advanced routing capabilities to be configurable in a Kubernetes API. With Google leadership, Gateway API has been developed to dramatically increase the number of features available. This API enables many new features in Kubernetes, including traffic splitting, header modification, and forwarding traffic to backends in different namespaces, just to name a few.
Since the project was originally proposed, Googlers have helped lead the open source efforts. Two of the top contributors to the project are from Google, while more than 10 engineers from Google have contributed to the API.
This week, the API has graduated from alpha to beta. This marks a significant milestone in the API and reflects new-found stability. There are now over a dozen implementations of the API and many are passing a comprehensive set of conformance tests. This ensures that users will have a consistent experience when using this API, regardless of environment or underlying implementation.
A Simple Example
To highlight some of the new features this API enables, it may help to walk through an example. We’ll start with a Gateway:
| apiVersion: gateway.networking.k8s.io/v1beta1 kind: Gateway metadata: name: store-xlb spec: gatewayClassName: gke-l7-gxlb listeners: - name: http protocol: HTTP port: 80 |
This Gateway uses the gke-l7-gxlb Gateway Class, which means a new external load balancer will be provisioned to serve this Gateway. Of course, we still need to tell the load balancer where to send traffic. We’ll use an HTTPRoute for this:
| apiVersion: gateway.networking.k8s.io/v1beta1 kind: HTTPRoute metadata: name: store spec: parentRefs: - name: store-xlb rules: - matches: - path: type: PathPrefix value: / backendRefs: - name: store-svc port: 3080 weight: 9 - name: store-canary-svc port: 3080 weight: 1 |
This simple HTTPRoute tells the load balancer to route traffic to one of the “store-svc” or “store-canary-svc” on port 3080. We’re using weights to do some basic traffic splitting here. That means that approximately 10% of requests will be routed to our canary Service.
Now, imagine that you want to provide a way for users to opt in or out of the canary service. To do that, we’ll add an additional HTTPRoute with some header matching configuration:
| apiVersion: gateway.networking.k8s.io/v1beta1 kind: HTTPRoute metadata: name: store-canary-option spec: parentRefs: - name: store-xlb rules: - matches: - header: name: env value: stable backendRefs: - name: store-svc port: 3080 - matches: - header: name: env value: canary backendRefs: - name: store-canary-svc port: 3080 |
This HTTPRoute works in conjunction with the first route we created. If any requests set the env header to “stable” or “canary” they’ll be routed directly to their preferred backend.
Getting Started
Unlike previous Kubernetes APIs, you don’t need to have the latest version of Kubernetes to use this API. Instead, this API is built with Custom Resource Definitions (CRDs) that can be installed in any Kubernetes cluster, as long as it is version 1.16 or newer (released almost 3 years ago).
To try this API on GKE, refer to the
GKE specific installation instructions. Alternatively, if you’d like to use this API with another implementation, refer to the
OSS getting started page.
What’s next for Gateway API?
As the core capabilities of Gateway API are stabilizing, new features and concepts are actively being explored. Ideas such as Route Delegation and a new GRPCRoute are deep in the design process. A new
service mesh workstream has been established specifically to build consensus among mesh implementations for how this API can be used for service-to-service traffic. As with many open source projects, we’re trying to find the right balance between enabling new use cases and achieving API stability. This API has already accomplished a lot, but we’re most excited about what’s ahead.
By Rob Scott – GKE Networking
