This blog addresses the common challenges organizations face with fragmented API management in Kubernetes environments and presents Kong Konnect combined with the Kong Ingress Controller (KIC) as a comprehensive solution. 

We'll highlight the issues that arise when teams independently choose different API management solutions within Kubernetes clusters (leading to silos and inefficiencies) and showcase how integrating Kong Konnect with KIC addresses these challenges with an easy setup, centralized API management, enhanced monitoring, and an improved developer experience. 

Read on to learn about how KIC can be used to streamline your API management processes, improve operational efficiency, and maintain control and visibility across their services.

Challenges with API management at scale

So, do you think this whole cloud deployment, containerization, Kubernetes malarkey might catch on? Just kidding, of course.

If you work in an organization today that has some technology footprint, you probably have worked in some containerized environment. In today’s fast-paced digital landscape, organizations are rapidly adopting microservices and cloud native architectures to stay competitive. However, this shift often leads to a new set of challenges such as fragmented API management, inconsistent security policies, lack of business insights, and complex operational overhead.

Consider a technology organization that recently shifted to microservices and adopted Kubernetes for its deployments. Each development team, working independently, chose different API management tools that best suited their immediate needs. Over time, this leads to a patchwork of API gateways and management solutions across the organization. Things get even trickier when moving to a multi-cloud strategy. The complex fabric of a technicolor overcoat comes to mind.

As organizations scale, individual teams often adopt their own tools and practices for API management within Kubernetes clusters. They might start leveraging the built-in ingress controller to manage different rules. This often lacks enterprise-grade capabilities when being applied to these routing rules. While Kubernetes offers powerful capabilities for container orchestration, managing APIs across multiple clusters and teams can become chaotic. Here's what we typically see at Kong:

• Inconsistent policies: Without a unified management platform, enforcing consistent security and governance policies is difficult. Think about protecting your resources from being over-consumed by leveraging rate limiting or applying advanced authentication and authorization policies with your identity provider.
• Operational complexity: Multiple API gateways and management solutions increase the operational burden on DevOps teams. This requires training in multiple different solutions. Different solutions do things differently. Work in different ways. 
• Lack of visibility: Monitoring and analytics are scattered, making it hard to gain insights into API performance and usage. Also, how are the APIs being used? Who is using the APIs? The performance of the APIs. Are the products and capabilities being provided growing year to year?

The solution? Unifying API management

Kong Konnect, combined with the Kong Ingress Controller (KIC) for Kubernetes, offers a robust solution to these challenges. By associating your KIC deployments with Kong Konnect, you can visualize and manage your Kubernetes-native resources while enjoying the centralized control and visibility that Kong Konnect offers out of the box.

So what is KIC in Kong Konnect? The Kong Ingress Controller configures Kong Gateway using Kubernetes-native resources like Ingress and Gateway API. It extends beyond simple traffic proxying to offer advanced features through a policy layer (we call them plugins at Kong) to provide functionality such as advanced traffic routing, traffic control, security, authentication/authorization, observability, and integrations with other platforms. Automatic load balancing and health checks are also provided within this deployment topology. 

By setting up KIC with Konnect, it's important to mention that you configure your Ingress and Kong-related CRDs within your Kubernetes cluster. In this mode, the control plane becomes read-only. The control plane will allow you to view your Kong Gateway entities, such as ingress rules and plugins, from your Kubernetes resources directly within Konnect. Pretty awesome, right? This gives you a sleek user interface to visualize what ingress rules are set and what policies you have enabled for them. 

See the diagram below for a high-level look at this from an architecture standpoint. We have the fully managed control plane completely managed by Kong. The yellow box illustrates all the different components that get installed within your Kubernetes environment.

How to set up KIC with Konnect

Here's how to get up and running in just a few minutes.

Prerequisites

• A Konnect organization (Haven’t you signed up? Register here.)
• A Kubernetes cluster with a load balancer
• kubectl or oc (if you’re working with OpenShift) installed and configured to communicate with your Kubernetes TLS
• Helm 3 installed
• Because Kong Ingress Controller calls Konnect’s APIs, outbound traffic from Kong Ingress Controller’s pods must be allowed to reach Konnect’s *.konghq.com hosts

Kubernetes is known for being complex, but setting up the Kong Ingress Controller (KIC) with Konnect makes it refreshingly simple. Let’s walk through getting KIC up and running with just a few steps. First, let’s log into Konnect and create a Konnect control plane. Select Gateway in the top right.

Once the selection menu appears, choose Kubernetes Ingress Controller. Provide a name for your setup. I opted for something fun (Super-Awesome-KIC), then hit Next Step.

You’ll receive detailed instructions for installation. Just follow the simple steps provided. For this demo, I’m using a GKE (Google Kubernetes Engine) cluster in Google Cloud. Feel free to use any Kubernetes environment you’re familiar with. 

Once you've installed it, to verify that everything is running correctly, it should look similar to the below.

$ kubectl get po,svc -n kong

NAME                                  READY   STATUS    RESTARTS   AGE
pod/kong-controller-558f9ffb9-h8w5g   1/1     Running   0          2m29s
pod/kong-gateway-66bcd6c4fb-bqbsb     1/1     Running   0          2m29s

NAME                                         TYPE           CLUSTER-IP       EXTERNAL-IP       PORT(S)                         AGE
service/kong-controller-validation-webhook   ClusterIP      34.118.225.94    <none>            443/TCP                         2m30s
service/kong-gateway-admin                   ClusterIP      None             <none>            8444/TCP                        2m30s
service/kong-gateway-manager                 NodePort       34.118.226.245   <none>            8002:30179/TCP,8445:31265/TCP   2m30s
service/kong-gateway-proxy                   LoadBalancer   34.118.236.88    162.222.178.170   80:31776/TCP,443:31384/TCP
          2m54s

To ensure the proxy is exposed correctly, you can try hitting the endpoint using curl.

$ curl 162.222.178.170


{
  "message":"no Route matched with those values",
  "request_id":"1767c01b7c507d23a9ebec1c199e7738"
}

Navigating to the Konnect control plane provides visibility into your Kong Ingress Controller deployment. 

That’s it! Kong Ingress Controller should now be up and running. Now let‘s deploy a sample application.

Deploying a sample application

Let's deploy a sample echo service to test with on your terminal. Let's add a bunch of different ingress endpoints. (Link to resources here.)

$ kubectl apply -f 1-create-echo.yaml

namespace/testing created
service/echo created
deployment.apps/echo created
ingress.networking.k8s.io/accounts-ing created
ingress.networking.k8s.io/posts-ing created
ingress.networking.k8s.io/comments-ing created
ingress.networking.k8s.io/users-ing created
ingress.networking.k8s.io/categories-ing created
ingress.networking.k8s.io/tags-ing created
ingress.networking.k8s.io/search-ing created

What’s happening here:

• Deployed six ingress resources: /posts, /comments, /users, /categories, /tags, and /search.
• These ingress paths connect to the echo service on port 80, giving us a basic framework for testing.

Head back to the Konnect control plane to view your deployed ingress resources in Gateway Manager:

This offers us a central place to see what ingress rules we have exposed for our APIs.

Let's test some of our endpoints to see if we get a successful response back.

$ curl 162.222.178.170/accounts


Hostname: echo-d4f957dc6-jd6rs

Pod Information:
        node name:      gke-cluster-3-default-pool-471b6e72-369h
        pod name:       echo-d4f957dc6-jd6rs
        pod namespace:  testing
        pod IP: 10.104.2.6

Server values:
        server_version=nginx: 1.12.2 - lua: 10010

Request Information:
        client_address=10.104.0.6
        method=GET
        real path=/accounts
        query=
        request_version=1.1
        request_scheme=http
        request_uri=http://162.222.178.170:8080/accounts

Request Headers:
        accept=*/*  
        connection=keep-alive  
        host=162.222.178.170  
        user-agent=curl/8.7.1  
        via=1.1 kong/3.8.0.0-enterprise-edition  
        x-forwarded-for=10.128.15.217  
        x-forwarded-host=162.222.178.170
        x-forwarded-path=/accounts  
        x-forwarded-port=80  
        x-forwarded-proto=http  
        x-kong-request-id=07d74b03b0c0c657de370d3ce70a4c18  
        x-real-ip=10.128.15.217  

Request Body:
        -no body in request-

Adding policies (rate limiting and authentication plugins)

Now, let’s introduce some basic security and traffic management policies. We’ll set up rate-limiting and simple key-based authentication to keep things secure and manageable. Here is a link to the yaml you need to apply.

$ kubectl apply -f 2-apply-plugins.yaml 

kongplugin.configuration.konghq.com/key-auth unchanged
secret/jason-apikey configured
kongconsumer.configuration.konghq.com/jason created
kongplugin.configuration.konghq.com/rate-limiting-plugin unchanged
ingress.networking.k8s.io/comments-ing unchanged
ingress.networking.k8s.io/users-ing unchanged
ingress.networking.k8s.io/categories-ing unchanged
ingress.networking.k8s.io/tags-ing unchanged
ingress.networking.k8s.io/search-ing unchanged

Navigate back to your Konnect Control plane, we can now see all the security and traffic control policies that we have applied.

You can also see what’s enabled on each ingress (route in Kong).

If we try to access an endpoint protected with the key authentication without a valid key we get an error message.

$ curl http://162.222.178.170/accounts
{
  "message":"No API key found in request",
  "request_id":"b134e31917d36a4350ebc63f0e995900"
}

If we send too many requests, we get a rate limited exceeded error.

 $ for i in {1..10}; do curl 162.222.178.170/accounts?apikey=jasonkey; done

...

{
  "message":"API rate limit exceeded",
  "request_id":"29dcb8396edc344255a2ff0acbd12d0d"
}

By integrating rate-limiting and key-based authentication policies in your Kubernetes environment with KIC (Kong Ingress Controller) and Konnect, you gain many advantages. We're enhnancing security with Kong’s key-based authentication. We also support a ton more options when it comes to authentication and authorization. We have better insight into traffic control and reliability. And rate-limiting ensures that no single user or service can overwhelm your API, maintaining the stability and reliability of your application. 

Konnect provides a single interface to manage and visualize all security and traffic control policies across your APIs. This centralized approach makes it easier for teams to apply, update, and audit policies, saving time and reducing complexity.

Analytics

When using Kong Ingress Controller (KIC) in combination with Konnect, the integration delivers powerful analytics, giving your business deep insights into its API traffic. Metrics such as the number of requests, latency, success and error rates, and overall performance are readily available. This data can be filtered by specific APIs, giving you a granular view of how different parts of your system are operating. You can also gather specific user or consumer-based metrics right at your fingertips. 

Here’s a quick script to generate some random requests for analysis. Replace “162.222.178.170” with your proxy endpoint.

#!/bin/bash

# Function to make requests for a given key and endpoint
make_requests() {
  local key=$1
  local endpoint=$2
  local max_requests=$3
  for i in $(seq 1 $max_requests); do
    curl "162.222.178.170${endpoint}?apikey=${key}"
    echo # Print a newline for readability
  done
}

# Random number of requests for each endpoint
# Jason's requests
make_requests "jasonkey" "/posts" $((RANDOM % 10 + 1))
make_requests "jasonkey" "/comments" $((RANDOM % 10 + 1))
make_requests "jasonkey" "/users" $((RANDOM % 10 + 1))
make_requests "jasonkey" "/categories" $((RANDOM % 10 + 1))
make_requests "jasonkey" "/tags" $((RANDOM % 10 + 1))
make_requests "jasonkey" "/search" $((RANDOM % 10 + 1))

# Declan's requests
make_requests "declankey" "/posts" $((RANDOM % 10 + 1))
make_requests "declankey" "/comments" $((RANDOM % 10 + 1))
make_requests "declankey" "/users" $((RANDOM % 10 + 1))
make_requests "declankey" "/categories" $((RANDOM % 10 + 1))
make_requests "declankey" "/tags" $((RANDOM % 10 + 1))
make_requests "declankey" "/search" $((RANDOM % 10 + 1))

With Konnect, you get an overall summary of the API health within a specific cluster. Key metrics, such as the number of requests, error rate, and latency. It also provides insights from the graphs for total traffic and latency over time. You can also see how long requests are spent in kong vs your upstream API. This can be extremely useful when trying to identify bottlenecks.

Konnect provides detailed API analytics, showing you how each endpoint is being used and by how much. Below we can see that the /user endpoint is being used the most.

Additionally, we can further break things down based on different users or consumers, gaining operation insight into who is using the APIs and how much. The below shows the requests over time for the last seven days on which consumers are using our APIs the most. (It looks like Jason is marginally sending more requests than Declan.)

Conclusion

We explored the common challenges organizations face with fragmented API management in Kubernetes environments, such as inconsistent policies, operational complexity, and lack of visibility. We also introduced Kong Konnect combined with the Kong Ingress Controller (KIC) as a comprehensive solution for centralizing API management, simplifying setup, and improving monitoring and the developer experience.

Key challenges discussed include teams using different API tools, leading to inefficiencies and governance issues. By using Kong Konnect with KIC, organizations can enforce consistent security policies, streamline operations, and gain deep insights into API performance and usage through powerful analytics.

Want to learn more about how using Kong Konnect with KIC can streamline your API management processes, improve operational efficiency, and maintain control and visibility across services? Request a demo today!

Appendix: Supporting documentation

• Konnect Documentation | https://docs.konghq.com/konnect/
• KIC Documentation | https://docs.konghq.com/konnect/gateway-manager/kic/
• Analytics | https://docs.konghq.com/konnect/analytics/
• Kong Plugins | https://docs.konghq.com/hub/