// the find
Kong/kubernetes-ingress-controller
:gorilla: Kong for Kubernetes: The official Ingress Controller for Kubernetes.
Kong's official Kubernetes ingress controller translates Kubernetes Gateway API and Ingress resources into Kong Gateway configuration. It's for teams already running Kong who want to manage it declaratively through Kubernetes manifests rather than the Kong Admin API directly.
Gateway API conformance badge is real — they've passed the official conformance suite for v1.0.0, which means HTTPRoute, GatewayClass, ReferenceGrant actually work as specified, not just approximately. The controller architecture separates concerns cleanly: admission webhooks validate CRDs before they're accepted, a reference indexer tracks cross-namespace dependencies, and the admin API client has an explicit backoff strategy rather than naive retries. The CI pipeline is unusually thorough — separate workflows for unit, integration, envtest, e2e, conformance, performance, and nightly runs, all composable. Plugin ecosystem integration is the main reason to pick this over nginx-ingress: you get rate limiting, auth, transformations, all configured via KongPlugin CRDs.
The README opens with a notice that active development has moved to Kong Operator — KIC is in maintenance mode. New features go to the Operator; KIC gets bug fixes and support until its EOL date. If you're starting fresh, you're adopting something the vendor is already steering people away from. The CRD proliferation is real: KongPlugin, KongConsumer, KongIngress, KongUpstreamPolicy, KongClusterPlugin, TCPIngress, UDPIngress — all custom types that don't map to standard Kubernetes primitives, which means if you ever swap Kong out, you're rewriting routing config from scratch. Documentation lives in a separate repo, which sounds fine until you're debugging a specific version and the docs have drifted. Multi-gateway setups (the postgres/multi-gw variants) have enough config variants in the kustomize tree to suggest they're not straightforward to get right.