Kong Operator 2.1, released on February 10, arrives as the Kubernetes community winds down the long-serving NGINX Ingress controller, leaving a large installed base of API traffic on a component with a shrinking future. The release is Kong's pitch for where that traffic should go, and its most useful move is letting teams keep their existing Ingress running under enterprise support while they migrate to the newer Gateway API on their own schedule rather than in a single risky cutover.
The headline change is that Gateway API users on Kubernetes can now reach the full Konnect control plane, including the Dev Portal, Service Catalog, and Gateway Debugger, without leaving a declarative workflow. Kong keeps the boundary clear on where authority sits: Kubernetes stays the source of truth for configuration, and Konnect reflects and enforces that state rather than competing with it. A new entity-adoption feature also pulls services and routes that already exist in Konnect into the Operator, so a cluster can manage them centrally instead of stranding them outside the Kubernetes workflow.
Two smaller additions target the messier parts of running APIs at scale. Cross-namespace references for plugins and secrets arrive through a new KongReferenceGrant resource, which Kong frames as an extension of Gateway API's persona-driven design, keeping the platform team's plugin and authentication concerns separate from the application teams that own individual routes. Combining HTTP routes is now on by default, so rules that share the same backend service configuration within a namespace collapse into a single Kong Gateway service instead of proliferating.
The catch is that the migration story is only half told. Kong says an open-source tool to convert NGINX Ingress annotations and Ingress definitions into Kong plugins is coming, but it is not in this release, and annotation translation is where NGINX migrations usually get painful. Kong Operator 2.1 makes the destination attractive and lowers the risk of moving; whether teams actually leave NGINX Ingress in volume will hinge on how well that forthcoming tool handles the annotations they have already accumulated.
