Howdy folks! Martin here, Founder of Open Source API Gateway. It’s my pleasure to today be officially launching the brand-spanking new Kubernetes Ingress Controller.

Don’t have time to read my blog? Watch my 5 minute introduction to the Kubernetes Ingress Controller below.

The ingress controller does two pretty cool things:

1. Act as an Ingress Controller: Use Ingress Specs to push service definitions to your gateway
2. Act as a Sidecar Injector: Use 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 ingress controller

To use the ingress controller is pretty straightforward, all you need to do is make sure you have installed in your K8s cluster. If you haven’t done that yet, it’s pretty straightforward with our Helm chart.

Once you have up and Running (the helm chart will install the controller too), all you need to do is annotate your ingress appropriately:

Copy to clipboard
```
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
name: cafe-ingress
annotations:
kubernetes.io/ingress.class: 
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:

Copy to clipboard
```
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
name: cafe-ingress
annotations:
kubernetes.io/ingress.class: 
bool.service..io/use_standard_auth: "true"
bool.service..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..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..io/` for “true” or “false” values
• `string.service..io/` for anything that is just a string (e.g. a name)
• `num.service..io/` for any value that requires a number (assumes integer)
• `object.service..io` Will set a whole JSON object
• `array.service..io/`Will set an Array value

Each of the above directives takes the dot-notation path as it’s resource, for example:

Copy to clipboard
```
metadata:
name: cafe-ingress
annotations:
kubernetes.io/ingress.class: 
bool.service..io/use_basic_auth: "true"
bool.service..io/use_keyless: "false"
num.service..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 helm chart here, which installs it for you.

Create, secure & test APIs Faster API deployment Monitor, troubleshoot & update APIs