APIs on Kubernetes with Kong . Part I

During the last 3 years of my work I had taken a break from the world of APIs at MuleSoft to focus on containers, orchestration, and Kubernetes at CoreOS (and then Red Hat). As my understanding of containerized infrastructure improved, it became clear to me that a new way of thinking about the lifecycle of APIs was required. One of the reasons that I joined Kong Inc, was because I felt that Kong is greatly positioned for this new way of looking at APIs in the Kubernetes era. With 3 months of learning at Kong under my belt, I am feeling emboldened to write a series of blog entries to hopefully showcase Kong’s product capabilities on Kubernetes.

I will start with Kong for Kubernetes (K4K8S), which is Kong Inc’s Kubernetes Ingress Controller that is available as an Open Source Project as well as part of Kong’s product, Kong Enterprise. But to call K4K8S an Ingress Controller would be akin to calling Sushi dead fish… it is so much more than that! So, without further ado, let’s start with a first blog entry to tip our toes in showcasing K4K8S’s capabilities.

This is going to be a hands-on blog. To be able to follow along, I recommend that you do 3 things:

1. Install Minikube. I am going to assume Minikube as the target environment with all my examples, so you should have it installed, running and started. Obviously that doesn’t mean that they won’t work on other Kubernetes environments, but I won’t have tested this first blog’s steps anywhere else, though I am hoping to progress on to other actual Kubernetes cluster deployments with upcoming blog entries. Also, make sure to run Minikube tunnel which ensures that services can have externally exposed IPs.
2. Clone this repo. It has the kube manifests that I will be using, and having them locally will allow you to play around with configs beyond the rails of the path that I am walking through here.
3. Get Insomnia. Yes, I am biased since it is the open source product acquired by Kong Inc, but I do mean it when It say that it is a great HTTP client tool and I am going to be using it in this walkthrough. That being said, you can obviously replicate all of the HTTP client steps with any tool you would like.

Let’s get started by installing K4K8S the ingress controller itself. To do that, all you have to do is to create the Kubernetes objects listed in the manifests here, as shown here:

The second command above should show that the service kong-proxy is created and listening on an external IP. That external IP address will be the endpoint at which the Kong API gateway will be listening and through which you can control/manage all API traffic into your cluster. An obvious and common use case where this is needed is for backend service APIs which need to be accessed by Web or Mobile front-ends. Partner API access is another common scenario for such control on incoming API access and traffic is needed. Needless to say that there are many more such use cases since unlike what some might make you believe, no Kubernetes cluster is an island, communication into and out of the cluster is necessary and that communication needs management. So at this point, we have something like this set-up.

Ok, nothing earth-shatteringly exciting so far, I admit, but promise you this is about to get interesting. Let’s now create an actual application with an API to be protected, along with an Ingress rule and K4K8S objects that specify its protection parameters. We do that by first creating the actual Kong plugin objects that we would like to use in order to protect the API:

What is cool here is that we have just created the Kong gateway plugin objects as Kubernetes CRDs. In fact, we created two of these, an API Key Authentication Plugin (httpbin-auth) and a Rate Limiting (rl-by-ip) plugin. You can have a look a the actual Kubernetes manifest file for these plugins to see how they are configured, but the fact that these plugins are configured through Kubernetes manifest, and that they are reconciled by K4K8S is itself pretty awesome — that means that any changes you want to make to these plugin’s configurations going forward can be done by modifying the plugin configuration YAML files and doing a kubectl apply, or of course by making that change through your CI/CD flow for non-dev environments (more on that in an upcoming blog in this series).

Ok, so we have the plugin objects created, but still no API to be protected and no configuration to make that protection happen. That is the next step. Let’s do that by applying the hello-api.yaml file and playing around a bit:

What we just did was to create a proxy configuration on the Kong gateway that serves as an ingress controller, and associated that configuration with an instance of the two plugin types we had just created (i.e. API key authentication and rate limiting), so now our previously boring picture looks something like this.

A study of the manifest should shed more light on how all of this works, but what is great here is that the configuration of the routes, the plugins applied, and the consumers (and their AuthN keys) is all managed through first class Kubernetes objects, with K4K8S acting as a controller to apply/modify the configuration on the ingress point accordingly. Once we have built this setup, it’s time to test drive it a bit. Let’s start by hitting the Kong proxy endpoint with Insomnia. Note that the Hello API simply expects a /hello path with a request header called “name”, and it responds with a request body of “Hello <name>”. Also note that the IP address I am using below is that of the K4K8S proxy which you can get through the ‘kubectl -n kong get services’ command we walked through earlier.

Things are working as expected. The key authentication plugin is kicking in at the ingress point and not letting my calls go through with a proper key. If I now supply that key, things should work.

And checking the header tab should show me the Kong Rate Limiting plugin’s headers.

My requests are being authenticated and rate limited, and I can manage the lifecycle of the plugins and the associated configuration as Kubernetes objects. For example, if I wanted to modify the rate limiting configuration, this would simply require the modification of a the hello-plugin.yaml file and a ‘kubectl -f apply’ to make it happen… no database, no extra API management servers, no separate REST APIs or UIs to deal with, just me and my kubernetes manifests… life is beautiful!

Hoping that this was a useful walk through of the basic of K4K8S. Note that the entirety of this walkthrough was done with Kong’s Open Source projects which is pretty amazing. The cool thing is that this is just the tip of the iceberg. In upcoming blogs, I am hoping to walk through K4K8S other capabilities such as its load balancing configurations, its integration with Prometheus, how to ensure consistent configuration across multiple clusters, how to expose the APIs through a Portal, and more. Stay tuned!

PS —If you want to learn more about K4K8S beyond this blog series, check out the awesome guides here, as well as Kong’s great live tutorials here.