Howdy folks! Martin here, Founder of Tyk Open Source API Gateway. It’s my pleasure to today be officially launching the brand-spanking new Tyk Kubernetes Ingress Controller.
Don’t have time to read my blog? Watch my 5 minute introduction to the Tyk Kubernetes Ingress Controller below.
The Tyk ingress controller does two pretty cool things:
- Act as an Ingress Controller: Use Ingress Specs to push service definitions to your gateway
- Act as a Sidecar Injector: Use Tyk to act as the middle-man and security layer between your services (beta) – we’ll be discussing this in a different post.
How to use the Tyk ingress controller
To use the ingress controller is pretty straightforward, all you need to do is make sure you have Tyk installed in your K8s cluster. If you haven’t done that yet, it’s pretty straightforward with our Helm chart.
Once you have Tyk up and Running (the helm chart will install the controller too), all you need to do is annotate your ingress appropriately:
``` apiVersion: extensions/v1beta1 kind: Ingress metadata: name: cafe-ingress annotations: kubernetes.io/ingress.class: tyk spec: rules: - host: cafe.example.com http: paths: - path: /tea backend: serviceName: tea-svc servicePort: 80 - path: /coffee backend: serviceName: coffee-svc servicePort: 80 ```
This will then generate an API definition in your dashboard and make it live on your gateways.
You will probably want to make this API protected, by default the ingress will just proxy the service and add a request ID to the headers using the API gateway context variables and request transformation features. To do that is pretty straightforward:
``` apiVersion: extensions/v1beta1 kind: Ingress metadata: name: cafe-ingress annotations: kubernetes.io/ingress.class: tyk bool.service.tyk.io/use_standard_auth: "true" bool.service.tyk.io/use_keyless: "false" spec: rules: - host: cafe.example.com http: paths: - path: /tea backend: serviceName: tea-svc servicePort: 80 - path: /coffee backend: serviceName: coffee-svc servicePort: 80 ```
You can see the two new annotations that are making use of the ` bool.service.tyk.io/` processor directive, this is essentially a simple way for you to set values in the generated API definition. There are multiple directives you can use to set any dot-notated value:
- `bool.service.tyk.io/` for “true” or “false” values
- `string.service.tyk.io/` for anything that is just a string (e.g. a name)
- `num.service.tyk.io/` for any value that requires a number (assumes integer)
- `object.service.tyk.io` Will set a whole JSON object
- `array.service.tyk.io/`Will set an Array value
Each of the above directives takes the dot-notation path as it’s resource, for example:
``` metadata: name: cafe-ingress annotations: kubernetes.io/ingress.class: tyk bool.service.tyk.io/use_basic_auth: "true" bool.service.tyk.io/use_keyless: "false" num.service.tyk.io/basic_auth.cache_ttl: "60" ```
This enables you to set almost any value you want in the controller to control how to deploy the API to the gateway. Note that all values must be strings here, otherwise `kubectl` might throw a validation error.
What next?
In the next few controller releases you will also see a templating feature enabled where you can supply a set of templates with your controller configuration, and have the controller use these templates instead of the default, this can make “typing” services easier so that you do not need to set individual values as annotations.
Contribute to the development of our controller here, and if you want to take it for a spin, take a look at our Tyk helm chart here, which installs it for you.
