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

I also have Helm 3 installed on my computer.

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.

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.

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

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.

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

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.

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

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.

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

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

We’ll add the 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.

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.

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

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

Set Up a Request Validator Policy

Another thing we could do is enable Kong’s 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.

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:

• Automating Your Developer Pipeline With APIOps (DevOps + GitOps)
• Service Design Guidelines Part 2: API Versioning
• “Gateway Mode” in Kuma and Kong Mesh