The Kong Gateway Operator (KGO) enables provisioning and lifecycle management of Kong Gateways on Kubernetes and also includes automation for various related components (such as optional control-planes like the Kong Kubernetes Ingress Controller (KIC)) and configuration management to deploy the Kong Gateway in various deployment topologies.
The subsections that follow are a list of the current capabilities for this operator which are actively developed & maintained.
If you're interested in tracking or creating proposals for new features and capabilities, please see our KEPs. If you'd like to track the progress of development for active features or get involved and contribute in them, check our Github milestones and issues.
We support the ability to create (and destroy) Gateways using the Kubernetes
resource of the same name from Kubernetes Gateway API. A Gateway is
comprised of multiple sub-components "under the hood" including the Kong
Gateway (implemented via the DataPlane API) and the Kong
Kubernetes Ingress Controller (KIC) (implemented via the ControlPlane
API).
Declarative configuration management for Gateways and the underlying
sub-components is provided by our GatewayConfiguration API which
includes (non-exhaustively) configuration options for the ControlPlane
and DataPlane. The GatewayConfiguration API can be attached to any
number of Gateways, enabling lifecycle management for a single Gateway
or for a group of Gateways from a single configuration. Multiple groups of
Gateways which need different and independent configuration can be managed
using multiple GatewayConfigurations.
The DataPlane (e.g. the Kong Gateway) can be configured and deployed
according to its available deployment topologies using the
GatewayConfiguration API. The following topologies are currently supported:
More configurations and topologies may become available in future releases.
Note: We currently don't support traditional mode for the Kong Gateway as managing an independent database server in a Kubernetes cluster is non-trivial and out of scope for community support.
Note: While we don't currently support the Kong Gateway configured in hybrid mode control-plane configuration, we do support hybrid mode data-plane configuration using the
DataPlaneAPI. See below sections for details.
We support user-triggered upgrades and downgrades of the ControlPlane
and DataPlane sub-components of Gateways by configuring the
corresponding versioning information in the GatewayConfiguration.
Upgrades and downgrades of sub-components include transitions where existing
routes do not fail as automation is in place to "smoothly" wait for health
and DataPlane configuration before traffic is pivoted to the new version.
We support user-triggered scaling of DataPlanes for Gateway deployments,
where the number of Pods can be adjusted up and down as needed according to
DataPlane resource utilization and traffic.
Warning: Currently this only affects the
DataPlanePodscaling.ControlPlanePodscaling is a consideration for future releases.
The Kong Gateway can be deployed in hybrid mode which allows
multiple gateways to be joined together for scaling and resiliency. This
operator supports attaching a hybrid mode dataplane to an [existing
hybrid mode control-plane using the DataPlane API. A quick start for
this feature can be in the docs.
We provide an AIGateway resource which can be used to deploy the Kong
Gateway with our AI Plugins automatically configured and
enabled, to provide managed access to various AI models such as those provided
by OpenAI (e.g. ChatGPT).
Note: this feature is currently considered experimental and is not enabled by default. The CRD must be deployed manually (it is not provided as part of our
kustomizebundle):kubectl apply -f config/crd/bases/gateway-operator.konghq.com_aigateways.yaml
Then see our
config/samples/aigateway.yamlexample to get started.