Kong Operator 2.2 is now available.
This release continues our work to make Kubernetes the central place to manage more of the Kong ecosystem. In 2.1, we expanded what customers could do with Konnect and Gateway API.
With 2.2, we're building on that foundation by bringing [_Kong Event Gateway_](https://developer.konghq.com/event-gateway/)_Kong Event Gateway_ and [_Dev Portal_](https://developer.konghq.com/dev-portal/)_Dev Portal_ resources into the Operator, alongside continued improvements to Gateway API and day-to-day platform operations.
Kong Operator 2.2 introduces support for [_Kong Event Gateway_](https://developer.konghq.com/event-gateway/)_Kong Event Gateway_.
This allows customers to manage Kong Event Gateway resources directly from Kubernetes, whilst still using Konnect as the managed control plane. For teams already using Kubernetes as the source of truth, this means Event Gateway can now follow the same declarative and GitOps-friendly model as the rest of their platform.
Support includes:
`Event Gateway Control Plane``Event Gateway Backend Cluster``Event Gateway Virtual Cluster``Event Gateway Listener``Event Gateway Listener Policy``Event Gateway VirtualCluster Consume Policy``Event Gateway VirtualCluster Produce Policy``Event Gateway Dataplane deployment and lifecycle management`With these resources, you can define backend Kafka connectivity, virtual clusters, listeners, and policy configuration from Kubernetes.
This release also opens up two clear deployment patterns for Kong Event Gateway. For simpler environments, you can use port mapping and for more production-oriented deployments, Kong Operator 2.2 supports exposing Kong Event Gateway through Kubernetes Gateway API and `TLSRoute`, enabling SNI-based routing for Kafka traffic.
To get started, take a look at the [_Kong Event Gateway getting started guide for Kong Operator_](https://developer.konghq.com/operator/get-started/event-gateway/install/)_Kong Event Gateway getting started guide for Kong Operator_.
This is a major step in bringing event-driven use cases into the same Kubernetes-native operating model as API traffic.
Kong Operator 2.2 also adds support for [_Dev Portal_](https://developer.konghq.com/dev-portal/)_Dev Portal_ resources.
You can now manage key Dev Portal resources declaratively from Kubernetes, including:
`Portal``Portal Page``Portal Customization``Portal Email Config``Portal Team``Portal Custom Domain``Portal Identity Provider Request`This means platform teams can bring Dev Portal configuration into the same workflows they already use for the rest of their Kubernetes infrastructure: version control, peer review, GitOps pipelines and auditability.
As more customers standardise on Kubernetes as the operational centre of their platform, this becomes increasingly important. Dev Portal is no longer something managed separately from the rest of the stack. It can now sit alongside gateway, networking and application configuration as part of a single operating model.
To get started, take a look at the [_Dev Portal getting started guide for Kong Operator_](https://developer.konghq.com/operator/get-started/dev-portal/install/)_Dev Portal getting started guide for Kong Operator_.
Kong Operator 2.2 updates support to Gateway API 1.5.1.
This is especially important for Kong Event Gateway deployments using `TLSRoute`, as `TLSRoute` has now graduated into the Standard channel. That gives customers a stronger and more production-ready foundation for TCP and TLS routing patterns built on upstream Kubernetes APIs.
Gateway API continues to be a core part of the Kong Operator direction. We want customers to be able to use Kubernetes-native APIs where they make sense, whilst still connecting those workflows to the broader Kong and Konnect ecosystem.
If you are new to Kong Operator and Gateway API, start with the [_Gateway API installation guide_](https://developer.konghq.com/operator/get-started/gateway-api/install/)_Gateway API installation guide_.
We have also added support for infrastructure labels and Kubernetes Service annotations.
These additions give platform teams more control over how Kong-managed infrastructure fits into the wider Kubernetes environment. Labels help with ownership, automation, policy and inventory. Service annotations are often essential for cloud load balancer configuration, DNS integration, observability tooling and environment-specific networking requirements.
apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
name: kong
namespace: kong
spec:
gatewayClassName: kong
infrastructure:
labels:
app.kubernetes.io/team: platform
app.kubernetes.io/environment: production
cost-center: edge
listeners:
- name: http
protocol: HTTP
port: 80
allowedRoutes:
namespaces:This will make it easier to integrate Kong Operator into existing platform standards without workarounds, and follows the Gateway API standards.
We have continued to improve the Konnect experience in Kong Operator.
In 2.2, this includes better support for cross-namespace authentication references through `KonnectAPIAuthConfiguration` and `KongReferenceGrant`. This makes it easier for teams to separate concerns across namespaces whilst still managing Konnect-backed resources in a secure and structured way.
This continues the broader direction introduced in 2.1: Kubernetes remains the authoritative source of truth, whilst Konnect is able to participate more fully in the overall platform experience.
A key theme in Kong Operator 2.2 is simple: Kubernetes is no longer just where traffic is configured. It's increasingly where the wider Kong platform is managed.
With Kong Event Gateway and Dev Portal support now part of Kong Operator, customers can bring more of their Kong estate into a single Kubernetes-native workflow:
That gives teams a clearer path to standardisation, and reduces the operational gap between different parts of the platform.
If you're already using Kong Operator, take a look at the upgrade documentation and release notes. If you are new to Kong Operator, the getting started guides now cover [_Gateway API_](https://developer.konghq.com/operator/get-started/gateway-api/install/)_Gateway API_, [_Konnect CRDs_](https://developer.konghq.com/operator/get-started/konnect-crds/install/)_Konnect CRDs_, [_Kong Event Gateway_](https://developer.konghq.com/operator/get-started/event-gateway/install/)_Kong Event Gateway_ and [_Dev Portal_](https://developer.konghq.com/operator/get-started/dev-portal/install/)_Dev Portal_.
Simplify operations and scale with confidence To unlock Kubernetes’ full potential, many enterprises are relying on three key building blocks available in Kong Konnect today: Kubernetes Ingress Controllers: Ingress controllers are used for managing
Kong Gateway Operator (KGO) is the most effective way to install, upgrade, scale, and manage a Kong Gateway or Kubernetes Ingress. The latest release of the Kong Gateway Operator brings several updates that streamline integration with Kong Konnect
Kong Mesh 2.14 also introduces improvements to the mesh-scoped zone proxy deployment model. This makes it easier to configure and operate zone proxies for specific meshes, including Helm support for mesh zone proxy configuration. For customers runni
kongctl was built with the modern development stack in mind. Developers working in a terminal want the ability to query systems quickly to verify state, behaviors, and capabilities. Coding harnesses need well defined tools and accurate schemas for
The widespread adoption of Kafka and event streaming platforms is evident across several enterprises, where they serve as the backbone of critical operations, ranging from financial transactions to AI inference pipelines. However, in the domains of
While Kubernetes has become the standard platform for container orchestration, managing complex application lifecycles can still be a challenge. That's where Kubernetes Operators and Helm Charts come in. This guide dives into both of these too