Kong Enterprise 3.3 delivers enhanced security, usability, and platform reliability. Learn more
Engineering

Configuring a Kubernetes Application on Kong Konnect

Hello, everyone! Viktor Gamov, a developer advocate with Kong here. In this article, I would like to show you how to set up service connectivity using Kong Konnect and Kubernetes. I will deploy an application in Kubernetes, configure a runtime through Konnect and demonstrate some management capabilities like enabling plugins. 

Let’s dive right in!

 

Set Up Konnect, Kubernetes and Helm

As a prerequisite, I have created an account set up in Konnect. If you don’t already have one, you can sign up for free and follow our getting started documentation, blog post or video.

Also, I have prepared my three-node Kubernetes cluster in GCP.

Kubectl get nodes

Kong Konnect Kubernetes Ingress Controller Pods


I also have Helm 3 installed on my computer.

Helm 3 Installation

Kong provides you with Helm Charts for Kong Gateway and Ingress Controller.

Follow this documentation to add the Kong repository to your computer.


Next, we’ll securely establish a connection between our control plane and our data plane. To do this, click
Generate Certificate in the Runtimes section of Konnect. 

You need to copy the certificate, root certificate and server private key to your files system.

We will deploy those to Kubernetes in a few steps.

Kong Konnect and Kubernetes Deployment: Generate Certificate

Connect the Runtime in Kubernetes

Next, we should connect the runtime to our data plane. Then, we need to create secrets inside our Kubernetes cluster. One secret for the Kong cluster certificate and the other for the Kong cluster certificate code. There’s more detail on this in the Kong Konnect documentation.

Note: Make sure you’ve created the namespace.

$ kubectl create secret tls kong-cluster-cert -n kong \
   --cert=/<path-to-file>/tls.crt \
   --key=/<path-to-file>/tls.key
$ kubectl create secret generic kong-cluster-ca -n kong \
   --from-file=ca.crt=/<path-to-file>/ca.crt


The next thing we’ll need is the values.yaml
 file.

We can put all our customizations for Kong Helm Charts. 

In case you are interested in customizing this installation, take a look at a repository of examples. In your case, it might contain different links because you might be using different URLs.

image:
   repository: kong/kong-gateway
   tag: "2.4.1.1-alpine"

 secretVolumes:
 - kong-cluster-cert
 - kong-cluster-ca

 admin:
   enabled: false

 env:
   role: data_plane
   database: "off"
   anonymous_reports: off
   vitals_ttl_days: 732
   cluster_mtls: pki
   cluster_control_plane: <example.cp.konnect.foo>:443
   cluster_server_name: <kong-cpoutlet-example.service>
   cluster_telemetry_endpoint: <example.tp.konnect.foo>:443
   cluster_telemetry_server_name: <kong-telemetry-example.service>
   cluster_ca_cert: /etc/secrets/kong-cluster-ca/ca.crt
   cluster_cert: /etc/secrets/kong-cluster-cert/tls.crt
   cluster_cert_key: /etc/secrets/kong-cluster-cert/tls.key
   lua_ssl_trusted_certificate: /etc/secrets/kong-cluster-ca/ca.crt

 ingressController:
   enabled: false
   installCRDs: false


Apply the values.yaml file.

$ helm install my-kong kong/kong -n kong \
   --values ./values.yaml

To get Helm access to Kong, we need to get the external IP address. For example, when creating a service with a load balancer in Google Cloud, Google Cloud will provide us with an external address. So to communicate with our application service, we need this address.

$ kubectl get service my-kong-kong-proxy -n kong
NAME         TYPE           CLUSTER-IP     EXTERNAL-IP     PORT(S)                      AGE
kong-proxy   LoadBalancer   10.63.254.78   35.233.198.16   80:32697/TCP,443:32365/TCP   22h


Next, let’s make sure we have a connection to this runtime in Konnect and K9s. 

It’s connected in my Konnect Runtime Manager.

Kong Konnect Runtime Manager

Here’s my pod in K9s. It’s connected to my control plane.

Kong Service in K9s Pod


Now we have our data plane, our applications are running and our
API gateway is running. Next, we need to manage this API gateway from the outside world.

Create the Mock Service in Konnect

We’ll create a new service in Konnect ServiceHub called mock service. I’m creating a service that will proxy the request to this Mockbin through my Kong Gateway.

Kong Konnect: Create a New Service

To create a new implementation, we’ll go into our current version for the mock service and click Add New Implementation.

Kong Konnect: Create a New Implementation

Kong Konnect: Create a New Route

From Mockbin, we can try testing with foo and bar (http://mockbin.com/request?foo=bar&foo=baz), and I get the following response.

{
  "startedDateTime": "2021-06-28T21:26:17.519Z",
  "clientIPAddress": "69.119.63.202",
  "method": "GET",
  "url": "http://mockbin.com/request?foo=bar&foo=baz",
  "httpVersion": "HTTP/1.1",
  "cookies": {},
  "headers": {
    "host": "mockbin.com",
    "connection": "close",
    "accept-encoding": "gzip",
    "x-forwarded-for": "69.119.63.202, 172.70.110.190",
    "cf-ray": "6669fe174b5317ad-EWR",
    "x-forwarded-proto": "http",
    "cf-visitor": "{\"scheme\":\"http\"}",
    "upgrade-insecure-requests": "1",
    "user-agent": "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/91.0.4472.114 Safari/537.36",
    "accept": "text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9",
    "accept-language": "en-US,en;q=0.9",
    "cf-connecting-ip": "69.119.63.202",
    "cdn-loop": "cloudflare",
    "cf-request-id": "0af61d228a000017ad618f1000000001",
    "x-request-id": "b665811b-5c7e-433a-9648-532aca7f22d1",
    "x-forwarded-port": "80",
    "via": "1.1 vegur",
    "connect-time": "0",
    "x-request-start": "1624915577517",
    "total-route-time": "0"
  },
  "queryString": {
    "foo": [
      "bar",
      "baz"
    ]
  },
  "postData": {
    "mimeType": "application/octet-stream",
    "text": "",
    "params": []
  },
  "headersSize": 859,
  "bodySize": 0
}


If we try to hit the same URL through Kong, we’ll see some extra headers.

Kong Hit Mock URL in Insomnia


We should also be able to see this traffic in our
Konnect Vitals data. I just hit once, so there’s one spike.

Kong Konnect Vitals Traffic


So far, in the Konnect UI, we configured a mock service
. That configuration propagated into our data plane that deployed in Kubernetes. We didn’t configure anything in Kubernetes, but suddenly our Kong Gateway service running inside Kubernetes started understanding the mock URL.

Configure the Service in Kubernetes

I wrote a small application called Quote Service that shows random quotes from Back to the Future. Once the application deploys, we’ll create the port forwarding. Then, once port forwarding is enabled, we’ll get responses from the service.

Kubernetes Service Port Forwarding with Kong

We’ll hit this Kubernetes service through service discovery. So this Quote Service is now available on port 8080.

Kubernetes Services


We’ll go back to Konnect and create a new service and implementation again.

Kong Konnect: Create Kubernetes Service

Kong Konnect: Create Kubernetes Service Implementation


We’ll add the route.

Kong Konnect: Add Kubernetes Route


When we hit this now, it immediately goes through our
Kong Ingress Controller. That’s because the communication between the Konnect control plane and the data plane in Kubernetes is super fast.

Enable a Rate Limiting Policy

If we continue hitting this with requests on repeat, we should see that in the Konnect Vitals graph.

Kong Konnect Vitals: Kubernetes Service Requests

What should we do in real life to prevent this type of situation? That’s where rate limiting policies come in.


We can quickly enable
Kong’s rate limiting plugin. Let’s allow one request per second.

Kong Konnect Set Rate Limiting Config Limit

Kong Konnect: Rate Limiting Plugin Configure Policy

Kong Konnect: Rate Limiting Configure Second


If we start getting too many requests, our mock service will push back with a 429.

Insomnia Test Rate Limiting: Too Many Requests 429 Error


And in Kong Vitals, we should be able to see errors in red.

Kong Konnect Vitals: Traffic Status Code

Set Up a Request Validator Policy

Another thing we could do is enable Kong’s request validator plugin.

Kong Konnect: Configure Request Validator Plugin


When our application starts getting bad requests, we’ll get a Bad Request
 that says, “request body doesn’t conform to the schema.” 

However, when I enter the magic_word, the application works as it should.

Insomnia Test Request Validator Plugin


All of these plugins are on the runtime and don’t require changing the application service. I think that’s pretty powerful.

Ready to Try Out Kong Konnect?

Start a free trial, or contact us if you have any questions as you’re getting set up.

Once you’ve set up Kong Konnect and Kubernetes, you may find these other tutorials helpful:

 

Share Post

Subscribe to Our Newsletter!