We're continuing our efforts to make Kong Gateway Operator (KGO) the preferred way to install, upgrade, scale, and manage a Kong Gateway or Kubernetes Ingress — whether you’re managing from Kong Konnect or Kubernetes. With this latest release, we're: 

• - Making it easier for customers that have one team managing control plane provisioning and another managing gateway configuration and lifecyle, with mirror control planes
• - Supporting AWS Transit Gateways to simplify cloud networking
• - Improving support for multi-tenant Kubernetes clusters with different gateway scopes
• - Supporting NodePort as an additional ingress service type to support developer deployments

As ever, we’re continuously addressing issues raised by the community. You’ll find the complete list of improvements in the [KGO changelog](https://docs.konghq.com/gateway-operator/changelog/)KGO changelog .

Let’s dig into some of the more important changes to see how they can benefit your Kong Gateway deployment.

## KGO with existing Konnect control planes

Previously, if you wanted to use KGO with Konnect, you had to define the Konnect control plane using KGO and configure it from there. If you have existing Konnect-managed Gateways with existing entities configured, this made it difficult to adopt KGO.

You can now reference existing Konnect control planes in your KGO setup using an existing KonnectID and setting `KongGatewayControlPlane` to type `mirror`. You can manage configuration directly in Konnect and also [manage configuration with KGO](https://docs.konghq.com/gateway-operator/1.6.x/guides/konnect-entities/architecture/)manage configuration with KGO, although entities are read-only in Kubernetes. Learn more about this new capability [here](https://docs.konghq.com/gateway-operator/1.6.x/guides/konnect-entities/gatewaycontrolplane/#refer-to-existing-konnect-gateway-control-plane)here. 

If you aren’t already using [KGO](https://docs.konghq.com/gateway-operator/latest/)KGO as your management tool of choice for Kong Gateway, maybe it’s time to take a look.

## Support for Transit Gateways on hosted Konnect Dedicated Cloud Gateways (DCGW)

Dedicated Cloud Gateways (DCGW) are Kong Gateways that are fully managed by Kong in the cloud and region of your choice, connected into your cloud VPC network. Transit Gateways in AWS simplify cloud networking by centralizing routing through a central hub, reducing the need for multiple point-to-point peering connections. 

Konnect already supports [Transit Gateways in AWS](https://docs.konghq.com/konnect/gateway-manager/dedicated-cloud-gateways/transit-gateways/)Transit Gateways in AWS for hosted Kong Gateways, and this is a common deployment pattern for Dedicated Cloud Gateways in AWS. KGO now [supports this configuration](https://docs.konghq.com/gateway-operator/1.6.x/guides/konnect-entities/cloud-gateways-transit-gateway/)supports this configuration option through the `KonnectCloudGatewayTransitGateway` entity.

## Watch a subset of Kubernetes namespaces

Limiting the Kubernetes namespaces KGO watches is important for resource efficiency and security in shared cluster environments. By configuring the `spec.WatchNamespace` setting in the `ControlPlane` and `GatewayConfiguration` CRDs , you can restrict KGO's synchronization of routes and service configurations to only the designated namespaces relevant to your Kong Gateway deployment. This focused approach prevents unnecessary processing and potential exposure of configurations across different teams or applications within the same cluster. You can learn more about this [here](https://docs.konghq.com/gateway-operator/1.6.x/reference/custom-resources/#controlplaneoptions)here.

## Nodeport as a new ingress service type

When you're developing new applications, you may not have full access to the networking setup that you have in higher environments. With this change, you can configure your Kong Gateway[ DataPlane as a NodePort](https://docs.konghq.com/gateway-operator/1.6.x/reference/custom-resources/#dataplaneserviceoptions) DataPlane as a NodePort service in addition to ClusterIP and LoadBalancer configurations, which are already supported. This should make it easier for developers to build solutions using Kong Gateway and KGO.

## Try Kong Gateway Operator today

Kong Gateway Operator 1.6 focuses on delivering practical improvements, especially for customers leveraging Konnect and AWS Transit Gateways. 

Try out the new features and give us feedback by visiting the Kong community forums or opening an issue in the[ Kong Gateway Operator repository,](https://github.com/kong/gateway-operator) Kong Gateway Operator repository, and help us make KGO even better.