Skip to main content
We recommend deploying Conduktor Gateway on Kubernetes using the official Helm chart for the best experience and supportability. Kubernetes keeps stateless services like Gateway highly available with built-in routing, scaling and self-healing.

​
Local example

We recommend running the local-stack example from our Conduktor Reference Architecture repository. This stack creates a production-like local deployment of the entire Conduktor Platform using k3d as a local Kubernetes cluster. It includes:
Gateway will only start if a valid license is provided (version 3.18+). If you’d like to evaluate Gateway, contact us.

​
Helm values

Inspect the helm values for Gateway. The sensitive configurations are provided by reference to a Kubernetes Secret.
In production, manage secrets with a dedicated secret manager. Don’t store them unencrypted in a git repository.

​
Configure listeners with Helm

The Gateway Helm chart defines listeners under gateway.listeners, which has two slots: internal and external. The chart turns them into GATEWAY_LISTENER_* environment variables and creates a Kubernetes Service for each. Don’t try to override these generated listener variables in gateway.env: the chart’s values take precedence.
  • The internal listener is enabled by default and exposed through a ClusterIP Service.
  • To expose Gateway outside the Kubernetes cluster, set gateway.listeners.external.enable: true, set advertisedHost, and choose the Service type with service.external.type.
  • Keep the local ports of both listeners separate. The default internal range 9092-9098 overlaps the default external port 9092, so move one of them.
  • Ports use the ADVERTISED:LOCAL format, for example "443:9092".
This example exposes an internal SASL_PLAINTEXT listener and an external SASL_SSL listener with SNI routing through an AWS Network Load Balancer:
values.yaml
The keystore certificate has to cover bootstrap.kafka.example.com and *.kafka.example.com, and your DNS has to point both to the load balancer. With SNI routing, the external listener accepts exactly one port, such as 9092 or 443:9092: port ranges aren’t supported. Find out more about TLS through a network load balancer.

​
Run Gateway in high availability

The chart deploys two replicas by default. For production, we recommend setting gateway.replicas to 3 or more, so that Gateway keeps serving clients while one pod restarts or its node fails. The chart prefers to schedule Gateway pods on different nodes but doesn’t require it. To spread pods across availability zones, set topologySpreadConstraints. The chart doesn’t create a PodDisruptionBudget: if your cluster drains nodes, add one with extraDeploy.

​
Run Gateway on OpenShift

Gateway runs under the default restricted-v2 security context constraint (SCC), without a custom SCC. The Gateway image runs as a non-root user, so let OpenShift assign the user ID (UID):
  • Don’t set runAsUser, runAsGroup or fsGroup in gateway.securityContext or podSecurityContext. The chart leaves them empty by default.
  • Features that write local files, such as the disk cache of the large message handling Interceptor, need a writable volume.
  • If you enable the debug sidecar, set gateway.debugSidecar.securityContext to a security context without a fixed UID, such as {runAsNonRoot: true, allowPrivilegeEscalation: false, capabilities: {drop: [ALL]}}. When it’s empty, the sidecar runs with the fixed UID 1001, which restricted-v2 rejects.
  • Expose Kafka traffic with a LoadBalancer Service, as described in Configure listeners with Helm. OpenShift Routes carry HTTP and TLS on ports 80 and 443 by default: we recommend a LoadBalancer Service for Gateway’s Kafka traffic.

​
Preserving client IP address

By default, the Kubernetes load balancer changes the client IP address to its own. See Capturing the client IP address for how to preserve it, using externalTrafficPolicy on the Gateway Helm chart or HAProxy Protocol.

​
Next steps

​
Chart dependencies

All charts in this repository depend on bitnami-common .

​
Compatibility matrix

This compatibility matrix is a resource to help you find which versions of Conduktor Gateway work on which version of our Conduktor Gateway Helm chart.
We recommend you use the version of Gateway that comes pre-configured with the Helm chart. You can adjust the version in your values property according to the supported Gateway version, if required. Notes column only lists chart-level changes. See Conduktor release notes to determine whether there are breaking changes within the artifacts.

​
Helm chart compatibility

Breaking changes: 🟡 - breaks additional services / small behavior changes (e.g. Grafana dashboard changes) 🔴 - breaks overall deployment of the product (e.g. renaming variables in .values, major product releases)