With Kong Ingress Controller, when your Control Plane was hosted in Kong Konnect, and you were using Kubernetes Gateway API, your dataplane, routes, and services were in read-only mode.

When using Kong Ingress Controller with Kubernetes Gateway API, Kubernetes serves as the authoritative source of truth for configuration, with Konnect reflecting and enforcing that declarative state.

With KO 2.1, the authority is still Kubernetes, but Konnect is also able to share responsibility for its offerings. You are now able to take advantage of the full Konnect ecosystem, including Dev Portal, Service Catalog, and Gateway Debugger — all while configuration is being driven through Gateway API within Kubernetes.

We have introduced support for cross namespace references for Plugins and secrets (we already support cross namespace routes / services to the Gateway object). This is a continuation of the persona driven architecture of Gateway API, allowing you to codify the separation of concerns around authentication and plugin configuration using a KongReferenceGrant.

If you have created Services, Routes, or Services in Konnect prior to using Kong Operator, you can adopt these entities within the Operator so you have a central, Kubernetes-centric place to manage them. Take a look at the documentation to see how you can carry out the migration.

With the community announcement around the deprecation of NGINX Ingress, we continue to support Ingress through Kong Operator. This provides an enterprise-supported and well-maintained platform for customers to migrate to. Being able to support both Gateway API and Ingress provides a low-risk migration path to continue the support for your critical infrastructure. For more information on Ingress support on Kong Operator, take a look at our dedicated documentation.

We will shortly be releasing a migration tool to help you migrate from NGINX Ingress to either Kong Ingress or Gateway API. This Open Source tool will help to migrate from NGINX Ingress annotations as well as Ingress definitions to using Kong Plugins where appropriate to give you more power when migrating and land on a platform that is supported for the long term.

This will combine any rules with same combination of backend services (the combination of namespace, name, port, and weight in backendRefs of rules) in all HTTPRoutes within the same namespace and translate them into one Kong Gateway Service.