Skip to main content

​
Availability

​
Introduction

The Kubernetes Gateway API is a set of Kubernetes resources that describe how traffic from outside a cluster reaches the services inside it. Kubernetes Ingress is frozen, and new routing features go into the Kubernetes Gateway API instead. The Kubernetes Gateway API separates the responsibilities of the people involved:
  • A platform team defines which gateway implementations are available, and runs the gateways.
  • Application teams define routes that send traffic from a gateway to their services.
Tyk Operator implements the Kubernetes Gateway API. You use the standard GatewayClass, Gateway and HTTPRoute resources, and Tyk Operator turns each route into Tyk OAS APIs on your Tyk Gateways. You can then add Tyk features, such as authentication and rate limits, to those APIs.
In this documentation, Kubernetes Gateway API means the Kubernetes specification. The Tyk Gateway API is the REST API that manages a Tyk Gateway.
Kubernetes Gateway API support requires Tyk Dashboard, and you must enable it in Tyk Operator. To enable it, see Get Started.

​
Choosing How to Manage APIs in Kubernetes

Tyk Operator gives you three ways to manage APIs in Kubernetes: You can use all three in the same cluster. With the Kubernetes Gateway API and Kubernetes Ingress, Tyk Operator creates the APIs for you. With the Tyk custom resources, you write the API definitions yourself.

​
How Tyk Operator Implements the Kubernetes Gateway API

Each Kubernetes Gateway API resource maps to a part of your Tyk deployment: You link the Kubernetes resources to your Tyk deployment with OperatorContext resources:
  • The GatewayClass refers to an OperatorContext that holds the connection details of Tyk Dashboard.
  • Each Gateway refers to an OperatorContext that identifies its data plane. This OperatorContext names the Kubernetes Service in front of the Tyk Gateways, and the API sharding tags that those Tyk Gateways load.

​
What Tyk Operator Supports

Tyk Operator supports part of the Kubernetes Gateway API: Tyk Operator creates one Tyk OAS API for each combination of parent Gateway, hostname and path in a route. Each API has an ID that starts with gwapi-. For how Tyk Operator builds each API, and the full list of supported fields, see the Kubernetes Gateway API Reference.

​
Adding Tyk Features to a Route

An API that Tyk Operator creates from a route contains only routing configuration. To add authentication, rate limits and other Tyk features, attach a Tyk OAS API definition to the route. To apply the same features to every route on a Gateway, attach the definition to the Gateway instead. A platform team can then set standard security for a whole Gateway, while application teams keep control of their routes. To give clients access, reference the route in a Policy. For the details, see Secure and Extend Routes.

​
How Tyk Operator Reports Results

Tyk Operator reports what it has done in the status of each resource, using the standard Kubernetes Gateway API conditions:
  • The GatewayClass and the Gateway report whether Tyk Operator accepts them, and the address of the Gateway.
  • Each HTTPRoute reports, for each parent Gateway, whether Tyk Operator has created its APIs, and whether it can resolve its upstream services.
  • Each attached TykOasApiDefinition reports whether it applies to its target.
If a rule uses a feature that Tyk doesn’t support, Tyk Operator rejects that rule, and gives the field and the reason in the route status. If it can still serve the other rules, it creates their APIs and marks the route as partially invalid. For the full list of conditions, see Status and Troubleshooting.