Skip to main content

Introduction

This page lists the parts of the Kubernetes Gateway API that Tyk Operator supports, from Gateway listeners to HTTPRoute matches, backends and filters. It then describes how Tyk Operator translates routes into Tyk OAS APIs, how it manages them, and how it reports problems. For an introduction, see the Overview. The information on this page applies to Tyk Operator 1.6.0.

Gateways and Listeners

Gateway Address

Tyk Operator doesn’t deploy Tyk Gateways or load balancers. It reports the address of the Gateway from the Kubernetes Service named in dataPlane.serviceRef: Tyk Operator ignores spec.addresses on the Gateway.

Listeners

Each listener must:
  • use the HTTP or HTTPS protocol
  • use a port that the Kubernetes Service of the data plane exposes, unless the Service has no ports (ExternalName)
  • not conflict with another listener on the same port, by protocol or hostname
Tyk Operator uses the listener port only to check it against the Service. It doesn’t change the ports that Tyk Gateway listens on.

TLS Certificates

For an HTTPS listener, each entry in tls.certificateRefs must refer to a Kubernetes Secret of type kubernetes.io/tls that holds a matching certificate and key. To refer to a Secret in another namespace, the owner of that namespace must create a ReferenceGrant. Tyk Operator uploads the certificates to the Tyk Certificate Store, and attaches them to the APIs of routes that have an effective hostname.
Tyk Operator doesn’t delete certificates from the Tyk Certificate Store when you remove them from a listener.

Matches

To make Tyk Gateway match paths by segment, so that /orders doesn’t also match /orders-archive, set http_server_options.enable_strict_routes to true on your Tyk Gateways.

Backends

Tyk Gateway sends requests to upstream services over plain HTTP, using the cluster DNS name of the Service. The Tyk Gateways must be able to resolve *.svc.cluster.local.
If Tyk Operator can’t resolve a backend reference, it still creates the API, with the upstream URL http://unresolved.backend.invalid. The API then responds with 500 Internal Server Error. Check the ResolvedRefs condition of the route.

Filters

Tyk Gateway applies its middleware in a fixed order, so the order of the filters in a rule has no effect.

Unsupported Features

Tyk Operator rejects any part of a route that it can’t translate, and reports the reason in the route status. These rule fields are not supported:
  • timeouts
  • retry
  • sessionPersistence
Rules that match the same path must use the same backends and, for overlapping methods, the same filters. If they don’t, Tyk Operator rejects them. How Tyk Operator reports a rejection depends on how much of the route it can still serve:
  • If it can serve none of the route, Accepted is False with the reason UnsupportedValue.
  • If it can serve some paths, Accepted is True, and PartiallyInvalid is True with the reason UnsupportedValue. The message lists the rules that it dropped.
The message names the field and the reason, for example spec.rules[1].retry: ....

How Routes Become APIs

API Identity

Tyk Operator creates one Tyk OAS API for each combination of:
  • parent Gateway (from parentRefs)
  • effective hostname
  • path value in the route matches
The effective hostname is the intersection of the hostnames of the route and the hostname of the listener. If neither sets a hostname, the API has no custom domain. The ID of each API is gwapi- followed by 20 hexadecimal characters. Tyk Operator derives it from the namespace and name of the route, the path, the parent Gateway and the hostname. The ID doesn’t depend on the order of the rules, so you can reorder rules without changing it. Rules that match the same path become one API, with one operation for each HTTP method that they match. Requests with a method that no rule matches receive 404 Not Found.

API Configuration

Each API gets this configuration. The settings are in the Tyk Vendor Extension (x-tyk-api-gateway), except where the table says otherwise. To add authentication and other settings, see Secure and Extend Routes.

Lifecycle

Gateways Without a Data Plane Context

If a Gateway has no infrastructure.parametersRef, Tyk Operator still creates APIs for its routes, but the APIs have no Gateway tags. The Gateway reports Programmed as False with the reason UnsupportedAddress.
Always set infrastructure.parametersRef on a Gateway, and set dataPlane.tags in its OperatorContext. Otherwise, every Tyk Gateway that isn’t segmented loads the APIs of its routes, including Tyk Gateways that you didn’t intend to serve them.

Updating and Deleting Routes

Tyk Operator updates the APIs of a route when you change the route. Tyk Operator adds a finalizer to each HTTPRoute. When you delete a route, Tyk Operator deletes its APIs from Tyk Dashboard, then removes the finalizer. If Tyk Operator can’t delete the APIs, for example because Tyk Dashboard is unreachable, it keeps the finalizer and tries again. The route stays in the Terminating state until the APIs are deleted. Tyk Operator reports the problem as an event on the route. If you disable Kubernetes Gateway API support in Tyk Operator while HTTPRoute resources exist, Tyk Operator can’t delete them. Delete your routes before you disable it.

Status and Troubleshooting

Tyk Operator reports the result of each resource in its status.conditions. To see them, run:

GatewayClass Conditions

You can’t delete a GatewayClass while Gateway resources use it.

Gateway Conditions

Tyk Operator reports the conditions of each listener in status.listeners:

HTTPRoute Conditions

Tyk Operator reports the conditions for each parent Gateway in status.parents: Tyk Operator also reports some problems as Kubernetes events on the route, such as CertUploadFailed, DeletionFailed and CleanupBlocked. To see them, run kubectl describe httproute <name> -n <namespace>.

TykOasApiDefinition Conditions

Tyk Operator reports the result of an attached definition in the Accepted condition of the TykOasApiDefinition: