Kong Ingress Controller: Kubernetes API Gateway
/kubernetes-ingress-controller
Kong Ingress Controller for Kubernetes (KIC) turns Kubernetes CRDs into live routing config for Kong Gateway, covering both Ingress and the newer Gateway API. Kong's README says new feature work now goes to the Kong Operator, with KIC kept in support-only mode. Reach for it if you already run Kong Gateway and want CRD-driven routing today; skip it for a brand-new cluster, since Kong is steering new users to the Operator.
What is the Kong Ingress Controller?
Kong Ingress Controller for Kubernetes (KIC) is the official controller that lets Kong Gateway read Kubernetes Ingress and Gateway API resources and turn them into live routing configuration. Beyond plain HTTP it handles TLS, gRPC, TCP, and UDP through the same gateway across multiple namespaces, per the README, and layers Kong's plugin system on top for authentication, request and response transforms, and rate limiting.
Key Features for Kubernetes Traffic Management
- โGateway API support: configures Kong through Gateway API resources, the documented successor to Ingress, with native routing for TLS, gRPC, TCP, and UDP alongside HTTP/HTTPS, shared across namespaces on one gateway.
- โIngress support: still configures Kong through the standard Kubernetes Ingress resource for clusters not yet on Gateway API.
- โDeclarative CRD configuration: expresses Kong's own feature set as Kubernetes Custom Resource Definitions instead of a separate config file or direct admin API calls.
- โAutomated scaling of Kong Gateway replicas to keep routing available, described in the README as operating Kong for you rather than by hand.
- โActive and passive health checks paired with load balancing across backend pods.
- โPlugin-driven traffic control: Kong plugins for authentication, request/response transformation, and rate limiting, attached declaratively per the README.
- โTwo install paths documented side by side: a Helm chart from charts.konghq.com, or the Kong Operator as an alternative deployment method.
- โRelease images published on Docker Hub for linux/amd64 and linux/arm64, plus nightly main-branch builds from a separate nightly-ingress-controller repository.
Installing Kong Ingress Controller
The documented path uses Helm. First install the Gateway API CRDs with kubectl apply against the kubernetes-sigs/gateway-api v1.0.0 standard-install.yaml manifest (or the experimental-install.yaml variant if you need TCPRoute and UDPRoute support), then install Kong Ingress Controller itself with `helm install kong --namespace kong --create-namespace --repo https://charts.konghq.com ingress`. The README suggests testing locally on Minikube or Kind, or on a hosted cluster such as GKE, and lists the Kong Operator as an alternative to the Helm install. Kong Enterprise users are pointed to a separate enterprise setup guide rather than the standard Helm command.
Configuring APIs and Traffic with KIC
Once installed, Kong Ingress Controller for Kubernetes watches Ingress or Gateway API objects - GatewayClass, Gateway, HTTPRoute, and ReferenceGrant, per the README - and pushes matching routes into Kong Gateway automatically. Plugin behavior such as authentication, request/response transforms, and rate limiting is attached through CRDs rather than Kong's admin API. The README doesn't include worked configuration examples itself; it points to guides in the separate kong/developer.konghq.com documentation repository for the actual CRD manifests and plugin syntax.
Strengths
- โCovers both Kubernetes Ingress and Gateway API in the same controller, so teams can migrate between the two without swapping gateways.
- โRoutes more than HTTP - TCP, UDP, TLS, and gRPC traffic all run through the same gateway, per the README's feature list.
- โKong's plugin system - authentication, transforms, rate limiting - attaches to routes declaratively through CRDs instead of a separate admin API call.
- โTwo supported install paths, Helm chart or Kong Operator, plus published Docker images for linux/amd64 and linux/arm64.
- โApache-2.0 licensed with active support channels - GitHub discussions, issues, a Kubernetes Slack channel, and monthly community meetups, per the README.
KIC's Future and Considerations
- โณKong is directing all new feature development toward the Kong Operator; the README describes KIC as continuing under support only, so future capability lands elsewhere first.
- โณEnterprise setup is deferred to a separate enterprise guide the README links to, rather than documented inline for this repository.
- โณWorked CRD and YAML configuration examples aren't in the README - it defers to the developer.konghq.com docs repository for actual manifest syntax.
- โณRelease container images are only published for linux/amd64 and linux/arm64, so other architectures aren't covered.
- โณPreview and experimental features sit behind feature gates documented only in this repo's own FEATURE_GATES.md and FEATURE_PREVIEW_DOCUMENTATION.md files, not on Kong's main documentation site.
Alternatives to Kong Ingress Controller
Common Questions about Kong Ingress Controller
Kong Ingress Controller for Kubernetes is the standalone controller that turns Kubernetes CRDs into Kong Gateway configuration. The README says all new Kong-on-Kubernetes development is moving into the Kong Operator, which combines KIC's job and Kong Gateway Operator's job into one deployment path, while KIC continues under support only.
Kong Ingress Controller for Kubernetes supports the Gateway API as the documented successor to Ingress, with native routing for TLS, gRPC, TCP, UDP, and HTTP/HTTPS through GatewayClass, Gateway, HTTPRoute, and ReferenceGrant resources, per the README.
The README names authentication, request/response transformation, and rate limiting as example plugin categories Kong Ingress Controller for Kubernetes applies through Kong's plugin system, attached declaratively via CRDs.
The documented path installs the Gateway API CRDs first, then runs `helm install kong --namespace kong --create-namespace --repo https://charts.konghq.com ingress`; the README also lists the Kong Operator as an alternative to the Helm install.
The README points Kong Enterprise users to a separate enterprise setup guide, so Kong Ingress Controller for Kubernetes does support enterprise deployments, just through a different documented path than the open-source Helm install.
Kong Ingress Controller for Kubernetes is released under the Apache-2.0 license, as listed on its GitHub repository.
The problem it solves
Teams running Kong Gateway inside a Kubernetes cluster need routes, plugins, and health checks to stay in sync with cluster state without hand-editing Kong's admin API or maintaining a separate declarative config file outside Kubernetes. Kong Ingress Controller for Kubernetes solves that by watching Kubernetes Ingress and Gateway API objects directly and pushing the resulting configuration into Kong Gateway, so a route change applied with kubectl takes effect without a separate push against Kong itself.
Best use cases
- โขRunning Kong Gateway as the entry point for a Kubernetes cluster and wanting routes, TLS, and plugins defined as CRDs instead of a separate config push.
- โขMigrating from Ingress-only setups toward the Gateway API while keeping the same gateway, since KIC supports both resource types side by side per the README.
- โขServing traffic beyond plain HTTP - gRPC, TLS, TCP, and UDP - through one gateway across namespaces instead of standing up separate ingress objects per protocol.
- โขApplying Kong's plugin system for authentication, request/response transformation, or rate limiting to Kubernetes-native workloads without calling Kong's admin API directly.
- โขKong Enterprise teams who want the same CRD-driven model with enterprise-only functionality layered on, following the README's separate enterprise setup guide.
Who should try it โ and who should skip
Reach for Kong Ingress Controller for Kubernetes if your team already runs Kong Gateway and needs CRD-driven Ingress or Gateway API routing plus its plugin ecosystem for auth, rate limiting, or request transforms. It's also a fit if you need one gateway to serve HTTP alongside TCP, UDP, TLS, and gRPC traffic across namespaces instead of separate ingress objects per protocol. Skip it if you're choosing a gateway for a brand-new cluster with no existing Kong investment, since Kong itself is directing new deployments to the Kong Operator instead of KIC.
Related repositories
Still deciding about kubernetes-ingress-controller?
One click hands the question to an AI along with this page โ see what it says about kubernetes-ingress-controller.