Overview

Kong Inc. released version 0.8 of Kong for Kubernetes, its Kubernetes Ingress controller built on top of the Kong API Gateway. The release introduces Knative ingress integration, a new cluster-level Custom Resource Definition (CRD), and annotation changes aimed at simplifying configuration. It also includes breaking changes to path-based routing that existing users will need to address.

What Is Kong for Kubernetes?

Kong for Kubernetes is composed of two tightly coupled components:

• A Kubernetes controller that watches Ingress resources and Kubernetes CRDs, translating them into Kong Gateway configuration.
• The Kong Gateway, an open-source API gateway built on NGINX, which handles the actual processing of incoming API traffic.

Most managed Kubernetes clusters on public clouds default to a vendor-provided Ingress controller tied to the vendor’s load balancer infrastructure. Kong for Kubernetes is an alternative that brings full API gateway capabilities into the Ingress layer, with the added benefit of consistent behavior across cloud providers and on-premises deployments via Kubernetes CRDs.

How Kong Differs from NGINX Ingress Controllers

Although Kong Gateway is itself built on NGINX, Kong for Kubernetes is architecturally distinct from both the community nginx-ingress-controller and NGINX Inc.’s commercial controller. According to Reza Shafii, VP of Products at Kong Inc., the key differentiators are the API management features Kong brings to the Ingress layer:

• OIDC-based authentication
• Advanced rate limiting
• Request caching
• Log and metrics streaming to multiple analytics providers simultaneously
• Support for multiple protocols: REST, GraphQL, gRPC, TCP

Shafii also highlighted performance characteristics cited by Kong Inc., including sub-millisecond latency and support for 25,000+ transactions per second, though independent benchmarks should be consulted before relying on these figures in architectural decisions.

For teams already running Kong Gateway outside Kubernetes, this controller provides a unified API management lifecycle across both Kubernetes and non-Kubernetes workloads — a meaningful operational advantage in hybrid environments.

What’s New in Version 0.8

Knative Ingress Support

The headline feature in 0.8 is support for Knative as an Ingress target. Knative is a Kubernetes-native serverless platform that provides higher-level abstractions for container-based workloads. Its default Ingress backend is Istio, with Gloo as a notable alternative.

Shafii explained the motivation for adding Kong as a Knative Ingress option:

What we have learned from our community and customers is that most use cases don’t require the weight of Istio to run serverless workloads. And in fact, the heavy weight of Istio is one of the reasons that prompted us to initiate the Kuma service mesh project. Kong Gateway’s plugin architecture and focus on extensibility helps keep Knative workloads focused solely on business logic.

Reza Shafii, VP of Products, Kong Inc.

For teams running Knative who find Istio’s operational overhead excessive, Kong for Kubernetes 0.8 offers a lighter alternative with the full plugin ecosystem of Kong Gateway available at the Ingress layer.

New Cluster-Level CRD

Version 0.8 introduces a new cluster-scoped Custom Resource Definition. Cluster-level CRDs are not namespaced, meaning they apply across the entire cluster rather than within a specific namespace. This is useful for global configuration that should not be replicated per namespace — for example, cluster-wide plugin settings or global rate limiting policies.

Annotation Updates

Several annotations have been updated or deprecated in this release to reduce configuration complexity. Users upgrading from previous versions should review the official changelog carefully, as some previously used annotations will no longer function as expected.

Breaking Changes: Path-Based Routing

Version 0.8 includes breaking changes to path-based routing behavior. Any existing Ingress resources that rely on path routing should be tested against the new release before upgrading in production. The full list of breaking changes and migration guidance is available in the official changelog.

Using Cloud Load Balancers with Kong

Kong for Kubernetes does not replace cloud load balancers — it complements them. Shafii described the recommended deployment pattern:

Cloud load balancers provide a way to balance traffic across multiple Kong Gateway nodes, and Kong Gateway nodes help manage traffic to multiple services within a cluster. For most users, we recommend the use of load balancers such as those of AWS or GCP to front Kong Gateways. This provides an endpoint inside the virtual private network in the cloud, which can then be exposed to other networks, partner networks, or directly on the internet.

Reza Shafii, VP of Products, Kong Inc.

In practice this means the typical production topology is: cloud load balancer (AWS ELB/ALB, GCP Load Balancer) → Kong Gateway nodes → individual Kubernetes services. This separates concerns cleanly: the cloud LB handles cross-node traffic distribution and TLS termination at the network edge, while Kong handles API policy enforcement inside the cluster.

Observability and Metrics

Kong for Kubernetes exposes metrics at two levels:

• Traffic metrics (per route and per service): HTTP status codes, error rates, throughput, latency, and ingress/egress bandwidth.
• Gateway health metrics: connections served, active connections, shared memory usage, and cache hit ratio.

These metrics can be exported to the following backends:

• Prometheus
• Datadog
• StatsD
• Zipkin
• Jaeger

This level of observability is comparable to what Istio and Gloo offer, making Kong for Kubernetes a viable choice for teams that need distributed tracing and metrics aggregation without adopting a full service mesh.

Upgrade Considerations

• Review the official changelog for the complete list of deprecated annotations and breaking changes before upgrading.
• Test all Ingress resources that use path-based routing in a staging environment first.
• If you use Knative, verify compatibility with the specific Knative version you are running, as Knative’s own Ingress API has evolved across releases.
• Plan for any CRD migration required by the new cluster-level resource introduced in this release.

Summary

Kong for Kubernetes 0.8 is a meaningful release for teams that want full API gateway capabilities — authentication, rate limiting, protocol flexibility, and rich observability — directly at the Kubernetes Ingress layer. The addition of Knative support gives serverless workloads a lighter-weight Ingress alternative to Istio. However, the breaking changes to path routing mean existing deployments require careful testing before upgrading.