Kong — Creating a fallback route

Fed up of Kongs generic “no Route matched with those values”? I was!

I decided to read the documentation on how to create a fallback route, if a route isn’t matched. It’s a safe to say it was difficult to find the right information, the Kong docs are really good! but very extensive.

The journey was dangerous with indentation errors and outdated documentation, round every corner! I had to tread carefully…

It was Sunday, the weather was grey, office cold, the elements were against me… but as usual, I got stuck in and with a little logic and trial and error, I got it working.

To achieve a fallback we need to essentially do two steps:

1. Define a fallback service
2. Define an ingress that acts as an upstream. I.E when a request doesn’t match any route, default to the ingress that doesn’t have any routes defined, so it’ll just route to the service.

Here is a practical example, none of this demo s***t

Fallback Service

---
apiVersion: apps/v1
kind: Deployment
metadata:
name: fallback-svc
namespace: app
spec:
replicas:
selector:
matchLabels:
app: fallback-svc
template:
metadata:
labels:
app: fallback-svc
spec:
containers:
- image: 12345678910112.dkr.ecr.eu-west-2.amazonaws.com/app:v1.0 #getting the docker image from aws ecr. You can relace this with #whatever you use to store your images. I use ecr as it works really #well with automated deployments via GitHub actions.
imagePullPolicy: Always
name: fallback-svc
ports:
- containerPort: 80
livenessProbe:
tcpSocket:
port: 80
initialDelaySeconds: 30
periodSeconds: 5
timeoutSeconds: 2
resources:
limits:
cpu: 512m
memory: 1024Mi
requests:
cpu: 256m
memory: 512Mi
---
apiVersion: v1
kind: Service
metadata:
namespace: app
name: fallback-svc
spec:
type: NodePort #allow external traffic to each my service.
selector:
app: fallback-svc
ports:
- port: 80
targetPort: 80
protocol: TCP

The upstream — fallback

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
name: fallback-ing-svc
namespace: app
annotations:
kubernetes.io/ingress.class: kong
spec:
rules:
- http:
paths:
- backend:
serviceName: fallback-svc
servicePort: 80

To see the manifests with correct indentation etc see repo: https://github.com/jjcallis/kong-fallback-service

So what does it do? In a nutshell, the fallback service using the Ingress resource, will receive all requests that don’t match against any of your defined rules within a different Ingress. such as

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
name: ing-one
namespace: app
annotations:
kubernetes.io/ingress.class: kong
spec:
hosts:
- example.com
rules:
- host: example.com
- http:
paths:
- path: /health
backend:
serviceName: app-nginx
servicePort: 80
- path: /api/v1/awesome
backend:
serviceName: app-nginx
servicePort: 80

So, when none of the above routes are matched. Your ‘upstream’ service will kick in and route all traffic to your app for you to handle the route not found how you like and removes the default “no Route matched with those values” that kong does.