Simplified controller configuration

When using the Kong Ingress Controller, a significant amount of effort was needed to apply configuration to the controller by setting environment variables. The new ControlPlane resource greatly simplifies this and allows you to set configuration once at the Control Plane level using native Kubernetes resources. For example, if you wanted to enable Combine HTTP Routes in KIC, you would need to set the environment variable:

ingressController:
  enabled: true
  installCRDs: true
  env:
    combined_services_from_different_httproutes: "true"
  

But in KO 2.0, this is set at the Controller level as a configuration in the Control Plane spec:

apiVersion: konnect.konghq.com/v2alpha1
kind: KonnectGatewayControlPlane
metadata:
  name: gateway-control-plane
  namespace: kong
spec:
  name: gateway-control-plane
  watchNamespaces:
    type: list        
    list:
      - default
      - apps
  translation:
    combinedServicesFromDifferentHTTPRoutes: enabled

Having this configuration in one central CRD with other options like watchNamespaces greatly simplifies configuration, linting, and validation of your Kong Gateways.

Reduced role-based configuration

A significant advantage for customers stems from Kong Operator's direct embedding of Kong Ingress Controller (KIC) instances within its own process. This architectural shift removes the requirement for the operator to request cluster-wide privileges each time a new KIC deployment is created. Previously, every ControlPlane reconciler needed permissions to create, update, or delete ClusterRoles, ClusterRoleBindings, and ServiceAccounts.

Now, KIC instances inherit their permissions from the service account linked to Kong Operator. This offers customers two key benefits:

• Reduced complexity: The proliferation of RBAC objects created per deployment is eliminated. Everything is streamlined under a single, predictable service account.
• Improved security posture: By removing the need for repeated creation of highly privileged resources, the overall attack surface is reduced. Customers can be confident that KIC instances operate strictly within the boundaries of the operator’s role definitions.

Saying goodbye to TCPIngress and UDPIngress

As the Kubernetes ecosystem has evolved, so has Kong Operator. TCPIngress and UDPIngress custom resources are officially deprecated, and they've been removed in Kong Operator 2.0.

These resources were introduced to fill gaps in the early days of the Kubernetes Ingress API, providing much-needed flexibility for routing TCP and UDP traffic. But with the rise and broad adoption of the Gateway API, those gaps are now closed. The Gateway API delivers a richer, standardized way to configure networking across clusters, making TCPIngress and UDPIngress both redundant and a source of potential confusion.

By retiring these older resources, we’re streamlining the experience and encouraging customers to embrace the Gateway API as the modern, future-proof path forward. This means clearer configurations, stronger ecosystem alignment, and less fragmentation for everyone.

Kong Konnect and Gateway API

While this is a significant change for the better for our Kubernetes customers, we know there is more to do. When using Konnect and KIC, your Gateway is marked as Read Only. This is because the configuration control is in Kubernetes configuration. With Kong Operator 2.1, we will be bringing support for the Kubernetes Gateway API to Konnect control planes. This unlocks the entire Kong API ecosystem to our customers, including Dev Portal, Service Catalog, and Debuggability, while giving you Gateway API support — the best of both worlds!

Meet us at API Summit 2025

Mattia Lavacca and I will be talking about building a first-class Kubernetes experience in Konnect at API Summit 2025. Don't have your tickets yet? Register for API Summit now!