Kong Ingress Controller for Kubernetes: Gateway API, CRDs and a Managed Migration Path

What Kong Ingress Controller Actually Does

Kong Ingress Controller (KIC) is the official ingress controller that lets Kubernetes resources configure Kong Gateway. The README frames it as a way to use Kong for Gateway API or Ingress, and to configure plugins, health checking and load balancing through Custom Resource Definitions and Kubernetes-native tooling. That last phrase is the whole design: the controller is not a proxy. It watches Kubernetes objects and translates them into Kong configuration. The traffic itself never passes through the controller process; Kong Gateway handles it.

The audience follows from that split. If you already run Kong Gateway and want its plugin catalogue (authentication, request and response transformations, rate limiting, as the README lists) driven from the cluster, KIC is the supported path. If you want a self-contained ingress controller that terminates traffic with no separate gateway product, this is more moving parts than you asked for.

One fact changes how you read everything else. The README states that all new development of Kong products on Kubernetes will land in the Kong Operator, which combines KIC and Kong Gateway Operator into a single way to deploy, manage and configure Kong products. KIC is still supported, per the linked KIC Support page, but the README says new feature requests should go to the Kong Operator GitHub page. That is a maintenance posture worth pricing in before you build on it.

The Data Flow: Kubernetes Objects In, Kong Config Out

The repository layout shows a Go controller (module github.com/kong/kubernetes-ingress-controller/v3, Go 1.25.11 per go.mod) built around two dependency families. The first is Kong's own client and reconciliation stack: github.com/kong/go-kong and github.com/kong/go-database-reconciler. The second is the Kubernetes controller machinery, including the Gateway API work reflected in the conformance badge for Gateway API v1.0.0 against Kong Ingress Controller 3.0.

That dependency split describes the mechanism. The controller watches Kubernetes resources, builds a desired Kong configuration, and hands it to the database reconciler, which applies it to Kong Gateway through the Admin API. Because configuration is declarative and reconciled rather than pushed imperatively, the controller can retry a failed apply and converge later. The examples directory shows the breadth of what can be expressed: gateway-httproute.yaml, gateway-tcproute.yaml, gateway-udproute.yaml, gateway-tlsroute.yaml, gateway-grpcroute-via-http.yaml, plus Kong-specific objects such as kong-upstream-policy-httproute.yaml and kong-custom-entity.yaml.

The feature list claims native support for TCP, UDP, TLS, gRPC and HTTP/HTTPS, with reuse of the same gateway across protocols and namespaces. Two example filenames suggest how far that goes in practice: gateway-referencegrant-httproute.yaml for cross-namespace references, and cross-namespace-plugin-grant.yaml for plugin grants across namespaces. There is also a pair of fallback examples (gateway-httproute-broken-plugin-fallback.yaml and ingress-broken-plugin-fallback.yaml), which implies the controller has defined behaviour when a plugin configuration is invalid instead of dropping the route entirely. The README does not document the details of that fallback, so read the examples rather than assuming.

Installing from Helm and Routing Your First HTTPRoute

The README gives a Helm-based quick start. It assumes a cluster (Minikube or Kind locally, or a hosted service such as GKE) and begins with the Gateway API CRDs. This first command installs the resources that have graduated to GA or beta, including GatewayClass, Gateway, HTTPRoute and ReferenceGrant.

kubectl apply -f https://github.com/kubernetes-sigs/gateway-api/releases/download/v1.0.0/standard-install.yaml

The README notes an alternative bundle if you want experimental resources and fields such as TCPRoute and UDPRoute; that one is the experimental-install.yaml file from the same release. Pick one, not both, and pick the experimental bundle only if you actually need those route types.

With the CRDs in place, install the controller and a Kong Gateway instance from Kong's Helm repository. This single command creates the kong namespace and installs the ingress chart into it.

helm install kong --namespace kong --create-namespace --repo https://charts.konghq.com ingress

After that, the README points to the Getting Started guide on the Kong docs site rather than reproducing route examples in the repository. For a first real use, the repository's own examples are the more direct reference: examples/gateway-httproute.yaml is a minimal HTTPRoute, and examples/gateway-httproute-rewrite-path.yaml shows path rewriting. Apply one with kubectl apply -f and watch the Kong configuration converge. The README does not document the expected output of that convergence, so verify against your Kong Admin API rather than a documented log line.

Enterprise users are directed to a separate setup guide, and there is a second installation route through the Kong Operator quick start guide if you would rather not use Helm. Nightly builds of the main branch are published as kong/nightly-ingress-controller:nightly, which the README describes as containing unreleased features for upcoming minor and major releases. Release images are on Docker Hub under kong/kubernetes-ingress-controller for Linux amd64 and arm64.

Where Kong Ingress Controller Is the Wrong Choice

The clearest limitation is lifecycle, not code. The README is explicit that new development of Kong products on Kubernetes will land in the Kong Operator, and that new feature requests should be made against the Kong Operator GitHub page. Support continues under the KIC Support page, but if you are choosing an ingress layer for the next several years, you are choosing a project whose feature work has been redirected. That is a legitimate reason to pick the Operator instead, and the README presents it as an alternative installation path, not a replacement you have to adopt today.

Second, KIC configures Kong Gateway; it does not replace it. If your team has no Kong deployment and no need for Kong-specific plugins, you are adding a gateway product, an Admin API surface and a reconciliation loop to solve a problem that a single-binary ingress controller solves more simply. The plugin catalogue is the reason to be here. Without that need, the CRD surface (KongUpstreamPolicy, KongPlugin, KongConsumer and friends, judging by the examples) is overhead.

Third, the repository itself warns that some features are experimental. The README's Preview and Experimental Features section says KIC may include features or options that are not enabled by default and are not available on the Kong documentation site, and points readers to the preview features documentation and FEATURE_GATES.md. Building on a preview feature means accepting a configuration surface that the main docs do not cover. Check FEATURE_GATES.md before you depend on anything you found in a blog post.

Finally, the documentation lives elsewhere. The README states that all KIC documentation is in the kong/developer.konghq.com repository. The README is a pointer, not a manual, so expect to read two repositories to answer a question.

Kong Ingress Controller Compared with NGINX and Traefik

The most common comparison is with NGINX Ingress Controller, and the difference is architectural rather than cosmetic. NGINX Ingress Controller generates NGINX configuration from Ingress and annotation-driven settings; the proxy and the controller ship as one unit. KIC keeps the controller and the data plane separate: the controller reconciles desired state into Kong Gateway through its Admin API, and Kong plugins are first-class objects in that state rather than annotations. If your requirements are plain host and path routing, the NGINX approach has fewer pieces. If you need authentication, transformation or rate limiting expressed as declarative Kubernetes objects with a plugin ecosystem behind them, KIC's model fits better.

Traefik takes a third position: it is a proxy that watches Kubernetes natively and exposes middleware through its own CRDs, with no separate gateway product and no database reconciler. The trade-off is the reverse of Kong's. Traefik is simpler to stand up, while KIC inherits Kong's plugin catalogue and its separation between control plane and data plane, which is what lets you scale Kong Gateway replicas independently.

The comparison that matters most for a new deployment is Gateway API. The README calls Gateway API the official successor of Ingress resources, and KIC supports both. Its conformance badge covers Gateway API v1.0.0 against Kong Ingress Controller 3.0. If you are starting fresh and want the successor API, KIC supports it today. The question is whether you want the Kong Operator to be the thing supporting it in a year.

Upgrade Cost, Version Support and Licence

Upgrades are versioned and the release cadence is visible. The recent releases list shows v3.5.13 and v3.4.20 published on 2026-08-07, and v3.5.12 on 2026-07-30. Two maintained minor lines receiving patches on the same day suggests a backport policy rather than a single supported branch, though the README does not state the support window; the KIC Support page is the source for that.

The upgrade cost is mostly a compatibility question between three moving parts: the controller version, the Kong Gateway version it configures, and the Gateway API CRD version. The README pins v1.0.0 for the CRD bundle in its quick start, and the conformance badge names Gateway API v1.0.0 against KIC 3.0. When you upgrade KIC, check the CRD bundle version at the same time. The go.mod file also shows a dependency on github.com/kong/kubernetes-configuration/v2 at v2.0.0-alpha.1, which is worth noting: alpha-versioned configuration types can change shape between releases.

On licensing, the repository is Apache-2.0, and the README's licence badge points at the Kong repository's LICENSE file. That covers the controller code. It does not tell you anything about Kong Gateway itself, which is a separate product with its own licence and its own enterprise edition (the README has a dedicated enterprise setup guide). Read the licence of each component you deploy, and treat the Apache-2.0 badge as covering only what is in this repository. Nothing here is legal advice.

Editorial conclusion

Adopt Kong Ingress Controller if Kong Gateway is already your data plane and you want Ingress, Gateway API and Kong CRDs to drive it from the cluster. Do not adopt it as a greenfield API gateway if you have no Kong deployment and no need for Kong plugins, because the README states that all new development of Kong products on Kubernetes lands in the Kong Operator. Before committing, verify three things: that the Gateway API CRD bundle you apply matches the version the controller expects, that the Kong version you run is covered by the KIC Support page, and that the plugins you depend on are documented on the Kong docs site rather than listed only under preview features.

Frequently asked questions

Official sources

1. Kong/kubernetes-ingress-controller on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases