Distributor Helm Readme
- Distributor
- Installing the Chart
- Distributor Support
- Upgrading to Distributor 5.5.2 with Strimzi 0.49.x
- Upgrading to Distributor 5.5.3 with Strimzi 0.51.0
- Upgrading to Distributor 5.6.0 (Strimzi 1.0.0+ is optional)
- Upgrading to Distributor 5.5.0 and Strimzi 0.46.1 or newer from earlier versions
- Deployment Kafka Connect with Distributor plugins
- Distribution configuration
- Useful Links
Distributor
Installing the Chart
The distributor helm charts are stored in a public registry maintained by Axual. To access the Helm chart and the images you need an account to access it.
Contact the Axual support team to request access.
To install Axual Distributor Chart with a single values.yaml
helm registry login -u [your-user] registry.axual.io/axual-charts
helm upgrade --install local-distributor oci://registry.axual.io/axual-charts/distributor --version 5.5.2 -f values.yaml
Distributor Support
Prerequisite: Following services should be up and running before starting distributor:
-
Strimzi Operator
-
Kafka Brokers
Also, distributor topics with proper ACLs have to be created before starting the distributor. An initialisation function is available to allow the Helm Charts to do this. A secret containing a super user certificate and trusted CA certificates are needed for this to work.
Strimzi Compatibility
Distributor is deployed by the Strimzi Cluster Operator and is available for several Strimzi Releases.
This table contains the distributor version and corresponding Strimzi operators that are supported and the corresponding configuration values.
The connect.image.tag column refers to the value of that configuration property.
Distributor |
Strimzi |
|
5.3.0* |
0.35.1, 0.36.0, 0.36.1, 0.37.0, 0.38.0, 0.39.0 |
|
5.3.1* |
0.35.1, 0.36.0, 0.36.1, 0.37.0, 0.38.0, 0.39.0 |
|
5.3.2 |
0.35.1, 0.36.0, 0.36.1, 0.37.0, 0.38.0, 0.39.0, 0.40, 0.41.0, 0.42.0, 0.43.0 |
|
5.3.3 |
0.35.1, 0.36.0, 0.36.1, 0.37.0, 0.38.0, 0.39.0, 0.40, 0.41.0, 0.42.0, 0.43.0 |
|
5.3.4 |
0.35.1, 0.36.0, 0.36.1, 0.37.0, 0.38.0, 0.39.0, 0.40, 0.41.0, 0.42.0, 0.43.0 |
|
5.3.5 |
0.35.1, 0.36.0, 0.36.1, 0.37.0, 0.38.0, 0.39.0, 0.40, 0.41.0, 0.42.0, 0.43.0 |
|
5.3.6 |
0.35.1, 0.36.0, 0.36.1, 0.37.0, 0.38.0, 0.39.0, 0.40, 0.41.0, 0.42.0, 0.43.0 |
|
5.4.0 |
0.35.1**, 0.36.0**, 0.36.1**, 0.37.0**, 0.38.0**, 0.39.0**, 0.40, 0.41.0, 0.42.0, 0.43.0, 0.44.0, 0.45.0 |
|
5.4.1 |
0.35.1**, 0.36.0**, 0.36.1**, 0.37.0**, 0.38.0**, 0.39.0**, 0.40, 0.41.0, 0.42.0, 0.43.0, 0.44.0, 0.45.0 |
|
5.4.2 |
0.35.1**, 0.36.0**, 0.36.1**, 0.37.0**, 0.38.0**, 0.39.0**, 0.40, 0.41.0, 0.42.0, 0.43.0, 0.44.0, 0.45.0 |
|
* 5.3.0 and 5.3.1 do not have Strimzi specific images
** Deprecated, support will be removed in a future release
Distributor |
Strimzi |
|
|
5.6.0 |
0.40***, 0.41.0***, 0.42.0***, 0.43.0***, 0.44.0, 0.45.0, 0.46.1, 0.47.0, 0.48.0, 0.49.0, 0.49.1, 0.50.0, 0.50.1, 0.51.0, 1.0.0, 1.0.1, 1.1.0 |
|
|
5.5.4 |
0.40***, 0.41.0***, 0.42.0***, 0.43.0***, 0.44.0, 0.45.0, 0.46.1, 0.47.0, 0.48.0, 0.49.0, 0.49.1, 0.50.0, 0.50.1, 0.51.0 |
|
|
5.5.3 |
0.40***, 0.41.0***, 0.42.0***, 0.43.0***, 0.44.0, 0.45.0, 0.46.1, 0.47.0, 0.48.0, 0.49.0, 0.49.1, 0.50.0, 0.50.1, 0.51.0 |
|
|
5.5.2 |
0.40***, 0.41.0***, 0.42.0***, 0.43.0***, 0.44.0, 0.45.0, 0.46.1, 0.47.0, 0.48.0, 0.49.0, 0.49.1 |
|
|
5.5.1 |
0.40***, 0.41.0***, 0.42.0***, 0.43.0***, 0.44.0, 0.45.0, 0.46.1, 0.47.0, 0.48.0 |
|
|
5.5.0 |
0.40***, 0.41.0***, 0.42.0***, 0.43.0***, 0.44.0, 0.45.0, 0.46.1, 0.47.0 |
|
|
* Distributor 5.5.0+ determines the correct image tag from the configuration strimzi.version
Using the configuration connect.image.tag will override the automatic tag selection based on strimzi.version
* Deprecated, support will be removed in a future release
Upgrading to Distributor 5.5.2 with Strimzi 0.49.x
TLS Certificate Chain Configuration
When upgrading to Distributor 5.5.2 with Strimzi 0.49.0/0.49.1 (Kafka 4.1.1), you may encounter TLS handshake failures:
sun.security.validator.ValidatorException: PKIX path building failed:
sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
Cause: Strimzi 0.49.x requires the complete certificate chain (root + intermediate CA) in the caCerts configuration. Previous versions (e.g., Distributor 5.5.1 with Strimzi 0.48.0) worked with only the root certificate.
Fix: Add the intermediate CA certificate to distribution.sourceCluster.tls.caCerts and distribution.clusters.<target>.tls.caCerts. Retrieve the full chain from your cluster CA secret:
kubectl get secret <cluster>-cluster-ca-cert -n kafka -o jsonpath='{.data.ca\.crt}' | base64 -d
This returns both intermediate and root certificates. Include both in your caCerts configuration.
API Deprecation Warnings
When deploying, you will see warnings about deprecated Strimzi API versions:
W1217 14:39:07.651758 29765 warnings.go:70] Version v1beta2 of the KafkaConnect API is deprecated. Please use the v1 version instead.
W1217 14:39:07.653912 29765 warnings.go:70] Version v1beta2 of the KafkaConnector API is deprecated. Please use the v1 version instead.
These warnings are expected on Strimzi 0.49.x - 0.51.x, where both the v1 and v1beta2 CRD APIs exist and v1beta2 is deprecated. From Distributor 5.6.0 the chart selects the CRD apiVersion automatically from strimzi.version: kafka.strimzi.io/v1 for Strimzi >= 1.0.0 (which serve only v1) and kafka.strimzi.io/v1beta2 for older versions. So one chart supports the whole range (0.40 - 1.1.0) and existing installations are not changed. On Strimzi 1.0.0+ only v1 exists, so these warnings no longer appear. See Upgrading to Distributor 5.6.0 below for crossing the 1.0.0 boundary.
Upgrading to Distributor 5.5.3 with Strimzi 0.51.0
Kubernetes Version Requirement
Strimzi 0.51.0 requires Kubernetes 1.30 or newer. Strimzi 0.51 dropped support for Kubernetes 1.27, 1.28, and 1.29. Verify your cluster runs a supported Kubernetes version before upgrading the Strimzi operator to 0.51.0.
Upgrading to Distributor 5.6.0 (Strimzi 1.0.0+ is optional)
Distributor 5.6.0 is backwards compatible. It works on every Strimzi version from 0.40 to 1.1.0, so upgrading the chart to 5.6.0 does not require any Strimzi change - stay on your current Strimzi and nothing more is needed. On top of that, 5.6.0 adds support for the newer Strimzi 1.0.0, 1.0.1 and 1.1.0, and a new value strimzi.apiVersion (auto | v1 | v1beta2, default auto) to control the CRD apiVersion the chart emits.
The rest of this section applies only if you also choose to move Strimzi to 1.0.0 or newer. Strimzi 1.0.0 drops the old v1beta2 API and keeps only v1. Moving your cluster and its resources to the v1 API is Strimzi’s job, not the Distributor’s. Strimzi’s tool changes all Strimzi resources in the namespace at once - the Distributor’s KafkaConnect and KafkaConnector are changed with everything else - so there is no separate step just for the Distributor. Use Strimzi’s official guide for the full steps: Upgrading from versions earlier than 1.0.0 (change your resources to v1, move the stored CRD version with crd-upgrade, upgrade the operator, and apply the v1 CRDs).
What you need to do just for the Distributor:
-
Your data is safe and distribution does not stop. The Distributor keeps no state of its own. Its internal topics (config, status, offset, timestamps) live in Kafka, and the API change does not touch them. Strimzi changes the running
KafkaConnect/KafkaConnectortov1in place, so the connectors keep working during the whole upgrade. -
Fix the Distributor’s Helm release before you upgrade the operator to 1.0.0. There are two copies of each
KafkaConnect/KafkaConnector: the live one in the cluster, and a record that Helm keeps of what it installed (saved in a Kubernetes Secret). Strimzi’s conversion changes the live one tov1, but it does not change Helm’s record - that record still saysv1beta2.This only matters if you first installed the Distributor on Strimzi 0.49 - 0.51 and then upgrade the operator to 1.0.0. You will not notice it during the upgrade; it shows up the next time you run any
helmcommand on this release. By thenv1beta2is gone from the cluster, so Helm cannot read its own record, and bothhelm upgradeandhelm uninstallfail withno matches for kind "KafkaConnect" in version "kafka.strimzi.io/v1beta2". Your data is fine and distribution keeps running on thev1live resources, but you cannot manage the release with Helm until the record is fixed.To avoid this, move Helm’s record to
v1while you are still on Strimzi 0.49 - 0.51 (bothv1beta2andv1work there), then upgrade the operator as usual. Tell the chart to usev1(chart >= 5.6.0) - this is an in-place change with no downtime:helm upgrade <release> <chart> -n <namespace> -f values.yaml --set strimzi.apiVersion=v1Keep your current
strimzi.version.v1beta2still works here, so Helm moves over without trouble. In a GitOps setup, setstrimzi.apiVersion: v1in your values file instead of--set. -
Last resort - only if you skipped the step above and are already stuck on 1.0.0. If you upgraded the operator before moving the Helm release to
v1, Helm can no longer read its own release, so bothhelm upgradeandhelm uninstallfail (a half-finishedhelm uninstallcan also leave the release in anuninstallingstate). There is no rush - distribution keeps running the whole time. To get Helm working again, recreate the release. The two resources deleted below are the Distributor’s ownKafkaConnect/KafkaConnector(created and managed by this chart) - not your Kafka clusters, and they hold no data. The Distributor is stateless (its internal topics stay in Kafka), so it only stops for the short gap between the delete and the reinstall:# 1. delete this release's own KafkaConnect/KafkaConnector (chart-managed, stateless) kubectl delete kafkaconnect,kafkaconnector -l app.kubernetes.io/instance=<release> -n <namespace> # 2. delete Helm's stored release, so it forgets the old v1beta2 record kubectl delete secret -l owner=helm,name=<release> -n <namespace> # 3. install again on the new version (the chart now writes v1) helm install <release> <chart> -n <namespace> -f values.yaml --set strimzi.version=1.0.0 # + matching image tag -
Check the result: the
KafkaConnect/KafkaConnectorresources usekafka.strimzi.io/v1, the connectors areRUNNING, and messages still move between clusters.
Upgrading to Distributor 5.5.0 and Strimzi 0.46.1 or newer from earlier versions
Distributor 5.5.0 contains several changes to support the Kafka 4 based Strimzi images of 0.46.0 and newer.
This guide assumes the new Strimzi operator is not yet installed, and you’re on a Strimzi version supported by Distributor 5.5.0.
Follow this guide to upgrade:
-
Update the chart dependency to 5.5.0
-
Update the values.yaml
-
Add a new configuration property
strimzi.versionand set it to a value matching your Strimzi operator -
Remove the value
connect.image.tagif set. Keeping this value would force the chart to load the specific image. -
Remove the value
init.image.tagif set. Keeping this value would force the chart to load the specific image for running the init scripts.
-
-
Apply the update
-
Verify the updated distributor. The update should result in the 5.5.0 images being used, with no changes in logging.
-
-
Update to the new Strimzi operator after checking distributor compatibility
-
Update the values.yaml
-
Set the configuration property
strimzi.versionto match your Strimzi operator version -
Update the content of
connect.loggingto Log4J2 format if specified. If not specified the default inline logging will be used
-
-
Apply the update
-
Verify that the image used is for the correct Distributor and Strimzi version and that the output logging is working as expected
-
Converting inline loggers from Log4J to Log4J2
Kafka 4.0.0 has removed support for Log4J and uses Log4J2 instead. The configuration field names have changed, and the logger name and level are configured separately.
The following code blocks contain the same logger configurations in both formats.
Log4J example inline loggers (Strimzi < 0.46.1):
log4j.rootLogger: "INFO"
log4j.logger.io.axual.distributor.common: "INFO"
log4j.logger.io.axual.distributor.message: "INFO"
log4j.logger.io.axual.distributor.offset: "INFO"
log4j.logger.io.axual.distributor.schema: "INFO"
log4j.logger.org.apache.kafka.clients.consumer: "WARN"
log4j.logger.org.apache.kafka.clients.producer: "WARN"
log4j.logger.org.apache.kafka.clients.admin: "WARN"
Log4J2 example inline loggers (Strimzi >= 0.46.1):
rootLogger.level: "INFO"
logger.distributorCommon.name: "io.axual.distributor.common"
logger.distributorCommon.level: "INFO"
logger.distributorMessage.name: "io.axual.distributor.message"
logger.distributorMessage.level: "INFO"
logger.distributorOffset.name: "io.axual.distributor.offset"
logger.distributorOffset.level: "INFO"
logger.distributorSchema.name: "io.axual.distributor.schema"
logger.distributorSchema.level: "INFO"
logger.kafkaConsumer.name: "org.apache.kafka.clients.consumer"
logger.kafkaConsumer.level: "WARN"
logger.kafkaProducer.name: "org.apache.kafka.clients.producer"
logger.kafkaProducer.level: "WARN"
logger.kafkaAdmin.name: "org.apache.kafka.clients.admin"
logger.kafkaAdmin.level: "WARN"
Deployment Kafka Connect with Distributor plugins
These charts can install a Kafka Connect cluster with distributor plugins. The Kafka Connect cluster is dedicated for a single Axual Tenant and Instance, because Strimzi Kafka Connect will reuse the authentication settings with all connectors Prerequisites:
-
A namespace to install the Kafka Connect cluster resources in
-
A Strimzi Cluster Operator that watches the namespace
-
The Strimzi Cluster Operator is set up to read from the registry.axual.io repository
-
A known bootstrap server endpoint for the source Kafka cluster
-
A secret containing a client certificate for a Kafka user that can create Kafka topics and access control lists
The following example configuration will start a Connect Cluster with three replicas for the tenant axual and instance dta It connects using a client certificate with a Kafka cluster named cluster01
global:
# Globally override the registry to pull images from.
imageRegistry: "registry.axual.io"
# Globally override the list of ImagePullSecrets provided, used for init containers
imagePullSecrets: []
# Configure the Strimzi Cluster Operator version installed. Used to determine the correct image tag and default logging to use
strimzi:
version: "0.48.0"
connect:
# Contains the image to use for connect
image:
repository: "axual/distributor"
# Specify the exact tag to override version deduction from strimzi.version value
# tag: "5.5.2-0.48.0"
# The number of connect replicas to spin up
replicas: 3
# Should connector resources, or Connector CRDs be used, needs to be true
useConnectorResources: true
# Use Strimzi Rack Awareness
rack:
enabled: true
topologyKey: topology.kubernetes.io/zone
#The bootstrap url used to connect to the kafka cluster
bootstrapServers: "cluster01-kafka-bootstrap:9093"
# The consumer group identifier used by this Kafka Connect cluster
groupId: "_rbsoft-multi-distributor-group"
# Contains the internal connect topics settings
topics:
# Set this to the replication factor to use on the source Kafka cluster
replicationFactor: 1
config:
# Name of the Kafka Connect config topic
name: "_axual-dta-distributor-config"
status:
# Name of the Kafka Connect status topic
name: "_axual-dta-distributor-status"
# Set the number of partitions used for the status topic
partitions: 2
offset:
# Name of the Kafka Connect offset topic
name: "_axual-dta-distributor-offset"
# Set the number of partitions used for the offset topic
partitions: 25
# Control the standard way Kafka Connect discovers available plugins
# Available modes:
# - ONLY_SCAN: Legacy behavior, scans all classes (slowest but most compatible) (Default for Distributor)
# - HYBRID_WARN: Uses both methods, warns about plugins missing ServiceLoader manifests
# - HYBRID_FAIL: Like HYBRID_WARN but fails on missing manifests (used in test environments)
# - SERVICE_LOAD: Uses only ServiceLoader (fastest but requires all plugins to have manifests)
# Note: All modes introduced in Kafka 3.6.0. Prior versions only support classpath scanning.
pluginDiscovery: SERVICE_LOAD
# Set the rest of the Kafka Connect configuration
config:
key.converter: JsonConverter
value.converter: JsonConverter
# Use this if you need SASL authentication for the source cluster
# sasl:
# # Set to true to enable a SASL connection
# enabled: false
# type: "PLAIN" # only PLAIN and SCRAM-SHA-512 are supported
# username: ""
# password: ""
# Contains the TLS settings for connecting to the kafka cluster
tls:
enabled: true
createCaCertsSecret: false
# if createTruststoreCaSecret is true, set the CA certs below
# caCerts:
# one_ca.crt: |
# -----BEGIN CERTIFICATE-----
# other_ca.crt: |
# -----BEGIN CERTIFICATE-----
# if createTruststoreCaSecret is false, the caCerts need to be set
# with an existing secret (name) and the name of the cert inside the
# secret
# caSecret:
# secretName: your_custom_ca_secret
# keyForCertificate: your_custom_ca_cert
caSecret:
secretName: "cluster01-cluster-ca-cert"
keyForCertificate: "ca.crt"
# Configure authentication using a client certificate
authentication:
enabled: true
createTlsClientSecret: false
# clientCert: |
# -----BEGIN CERTIFICATE-----
# -----END CERTIFICATE-----
# clientKey: |
# -----BEGIN PRIVATE KEY-----
# -----END PRIVATE KEY-----
# if a TLS secret already exists with the client credentials, provide the name here
secretName: "axual-cluster01-distributor"
# Set logging rules, the different types and formats can be found in Strimzi documentation
# If logging is not set, a default version will be deduced from the value of strimzi.version
logging:
type: inline
loggers:
rootLogger.level: "INFO"
logger.distributorCommon.name: "io.axual.distributor.common"
logger.distributorCommon.level: "INFO"
logger.distributorMessage.name: "io.axual.distributor.message"
logger.distributorMessage.level: "INFO"
logger.distributorOffset.name: "io.axual.distributor.offset"
logger.distributorOffset.level: "INFO"
logger.distributorSchema.name: "io.axual.distributor.schema"
logger.distributorSchema.level: "INFO"
logger.kafkaConsumer.name: "org.apache.kafka.clients.consumer"
logger.kafkaConsumer.level: "WARN"
logger.kafkaProducer.name: "org.apache.kafka.clients.producer"
logger.kafkaProducer.level: "WARN"
logger.kafkaAdmin.name: "org.apache.kafka.clients.admin"
logger.kafkaAdmin.level: "WARN"
# Used for creating the required Kafka ACLs and topics on the Kafka cluster
init:
enabled: true
# A list of Kafka principal names that should be used in the ACLS
principals:
- "User:CN=rbsoft distributor client for multi instance,OU=Development,O=Axual,L=Utrecht,ST=Utrecht,C=NL"
# Secrets containing the TLS certificates for applying topics and acl to kafka
tls:
# -- Existing Keypair secret name
keypairSecretName: "axual-remote-2-super-user-cert"
# -- Existing Keypair key name
keypairSecretKeyName: "tls.key"
# -- Existing Keypair certificate name
keypairSecretCertName: "tls.crt"
# -- Existing Truststore secret name
truststoreCaSecretName: "cluster01-cluster-ca-cert"
# -- Existing Truststore certificate name
truststoreCaSecretCertName: "ca.crt"
Metrics and Alerts
The distributor can be configured using to expose metrics, which can be exposed using a PodMonitor. Add the following configuration for metrics
# Axual registration data, should match short names in Self Service
tenantShortName: "axual"
instanceShortName: "dta"
connect:
metrics:
enabled: true
# Setting for the podmonitor
podMonitor:
enabled: true
interval: 60s
scrapeTimeout: 12s
# Use this to enable default alerts and add custom alerts
prometheusRule:
enabled: true
rules:
# Alert definition
- alert: MyCustomAlertRuleName
annotations:
message: '{{ "{{ $labels.connector }}" }} send rate has dropped to 0'
expr: sum by (connector) ( kafka_connect_sink_task_sink_record_send_rate{connector=~".*-message-distributor-.*"}) == 0
for: 5m
labels:
severity: high
callout: false
Exposing and securing the Connect REST API
Strimzi restricts access to the REST API to prevent other applications in Kubernetes to modify connector settings.
This restriction can be removed by instructing Strimzi to NOT manage connectors. Since this leaves the API open to all applications a custom network policy can be enabled.
The following example allows a specific ingress controller in the
namespace local-ingress to connect
# Axual registration data, should match short names in Self Service
tenantShortName: "axual"
instanceShortName: "dta"
connect:
# Turns off Strimzi Managed connectors. KafkaConnector Resources cannot be used
useConnectorResources: false
# Settings for the custom network policy
networkPolicy:
# The REST API will not be reachable if network policy is not enabled, AND useConnectorResources is true
enabled: true
from:
# A pod needs to meet ALL the requirements of AT LEAST ONE entry in this list to be able to access the Connect REST API.
- podSelector:
matchLabels:
# The pod must be called ingress-nginx and be part of instance ingress.
# This is a setup to match the labels of the nginx ingress controller.
# NOTE: The community ingress-nginx controller was deprecated in March 2026.
# Axual has migrated to a supported, enterprise-grade ingress controller.
# Update these labels to match the ingress controller pods in your cluster.
app.kubernetes.io/instance: ingress
app.kubernetes.io/name: ingress-nginx
namespaceSelector:
matchLabels:
# The pod must run in the namespace local-ingress
kubernetes.io/metadata.name: local-ingress
Defining an ingress for the Connect REST API
Strimzi does not provide an Ingress resource to be able to reach the Connect REST API, as this should not be used when using managed connector resources (KafkaConnector resource).
A custom Ingress can be defined to expose the service. The following example uses nginx for ingress.
The className: nginx value and nginx-specific annotations in the example below refer to the community ingress-nginx controller, which was deprecated in March 2026. Axual has migrated to a supported, enterprise-grade ingress controller. Update the class name and any ingress-specific annotations to match the ingress controller configured in your cluster.
|
# Axual registration data, should match short names in Self Service
tenantShortName: "axual"
instanceShortName: "dta"
connect:
# Turns off Strimzi Managed connectors. KafkaConnector Resources cannot be used
# If set to true, then the network policy must be configured for the ingress to reach the service
useConnectorResources: false
# Settings for the custom Ingress
ingress:
enabled: true
className: nginx
annotations:
# The example rewrites the target URL using nginx configuration
nginx.ingress.kubernetes.io/use-regex: "true"
nginx.ingress.kubernetes.io/rewrite-target: /$2
hosts:
- host: examples.dev
paths:
# Use the distributor path to be able to call http://examples.dev/distributor/xyz
# The service is called with path /xyz because of the pattern and rewrite annotation
- path: /distributor(/|$)(.*)
pathType: ImplementationSpecific
tls:
- hosts:
- examples.dev
secretName: examples-dev-server-cert-secret
Changing Strimzi Kafka Connect settings
The distributor helm charts allows the following Strimzi configurations for Kafka Connect. See the Strimzi documentation for details
connect:
resources:
limit:
cpu: 500m
memory: 750Mi
jmxOptions:
# JMX Options
jvmOptions:
# Java VM Options
livenessProbe:
# Strimzi Connect liveness probe options
readinessProbe:
# Strimzi Connect readiness probe options
tracing:
# Strimzi Connect tracing options
templateOverride:
# Strimzi Connect template options
externalConfiguration:
# Strimzi Connect external configuration options
Changing Image Registry, Repository or Tag
To change the globally used registry, change the global config. This is useful when you use a custom registry to mirror the content of the Axual registry
global:
# -- Globally override the registry to pull images from.
imageRegistry: "local.image.registry:5000"
# -- Globally override the list of ImagePullSecrets provided.
imagePullSecrets:
- name: custerDockerSecret1
- name: custerDockerSecret2
It is also possible to set the registry, repository and tag for Connect and Init directly
connect:
# Contains the image to use for connect
image:
# Set the specific registry to use for the init containers
registry: "local.image.registry:5000"
# Set the specific repository to use for the init containers
repository: "axual/distributor"
# Override the specific tag, else the Charts appVersion combined with the strimziVersion is used
tag: "5.5.2-0.48.0"
# Specify the docker secrets that can be used to pull the image from the registry
pullSecrets:
- name: custerDockerSecret3
- name: custerDockerSecret4
Changing the default key and certificate names
The names of the TLS key and certificate default to tls.key and tls.crt respectively. It is possible to override these names as follows:
tls:
# Configure authentication using a client certificate
authentication:
secret:
privateKeyName: "my_tls.key"
certificateName: "my_tls.crt"
Distribution configuration
The configuration for distribution is combined into a single block. All cluster information is configured separate from the distributor, which refer to specific cluster registration.
It is possible to override the internal Kafka Connect Task consumer properties, for example to override the maximum number of records polled.
This can be set in the consumerOverrides properties
The following example defines:
-
Three clusters
-
Cluster01, the source cluster for this distributor installation
-
Cluster02
-
Cluster03
-
-
Offset Committer to commit offsets to the source cluster
-
Uses consumer override to poll a maximum of 5 messages at a time
-
-
Offset Distributor levels
-
Level 1 to Cluster02 — uses consumer override to poll a maximum of 6 messages at a time
-
Level 2 to Cluster03 — uses consumer override to poll a maximum of 7 messages at a time
-
-
Message Distributor levels
-
Level 1 to Cluster02 — uses consumer override to poll a maximum of 8 messages at a time
-
Level 2 to Cluster03 — uses consumer override to poll a maximum of 9 messages at a time
-
-
Confluent Schema Distribution to Cluster02 and Cluster03 — uses consumer override to poll a maximum of 10 messages at a time
# Contains the distribution settings
distribution:
enabled: true
# Axual registration data
tenantShortName: "axual"
instanceShortName: "dta"
# Prefix values for topic and group ACLs
prefixAclSettings:
topicPrefix: "rbsoft-dual-"
groupPrefix: "rbsoft-dual-"
sourceCluster:
name: cluster01
# Contains instance topic information for the cluster
topics:
replicationFactor: 1
# Timestamps topic for offset distribution
timestamps:
# Use name override to not use default name of _<tenant>-<instance>-consumer-timestamps
nameOverride: ""
partitions: 25
# Schema topic for schema distribution
schemas:
# Use name override to not use default name of _<tenant>-<instance>-schemas
nameOverride: ""
topicPattern: '{tenant}-{instance}-{environment}-{topic}'
groupPattern: '{tenant}-{instance}-{environment}-{group.id}'
patternDefaultValues:
environment: test3
# Connection information, useful for connectors that use source as target
bootstrapServers: "cluster01-kafka-bootstrap:9093"
securityProtocol: "SSL"
additionalClientConfigs:
ssl.enabled.protocols: TLSv1.2
# Use this if the connection to the source cluster should use SASL
#sasl:
# mechanism: SCRAM-SHA-512
# username: my-user
# password: my-password
tls:
# CA Certificates that might be used in this cluster
caCerts:
- |
-----BEGIN CERTIFICATE-----
-----END CERTIFICATE-----
- |
-----BEGIN CERTIFICATE-----
-----END CERTIFICATE-----
clientCert: |
-----BEGIN CERTIFICATE-----
-----END CERTIFICATE-----
clientKey: |
-----BEGIN PRIVATE KEY-----
-----END PRIVATE KEY-----
# No password, unencrypted clientKey
#clientKeyPassword: ""
# Information about target clusters
clusters:
# information about cluster 02
cluster02:
name: cluster02
# Contains instance topic information for the cluster
topics:
replicationFactor: 1
timestamps:
nameOverride: ""
partitions: 25
schemas:
nameOverride: ""
topicPattern: '{tenant}-{instance}-{environment}-{topic}'
groupPattern: '{tenant}-{instance}-{environment}-{group.id}'
patternDefaultValues:
environment: test3
bootstrapServers: "cluster02-kafka-bootstrap:9093"
securityProtocol: "SSL"
additionalClientConfigs:
ssl.enabled.protocols: TLSv1.2
tls:
caCerts:
- |
-----BEGIN CERTIFICATE-----
-----END CERTIFICATE-----
- |
-----BEGIN CERTIFICATE-----
-----END CERTIFICATE-----
clientCert: |
-----BEGIN CERTIFICATE-----
-----END CERTIFICATE-----
clientKey: |
-----BEGIN PRIVATE KEY-----
-----END PRIVATE KEY-----
#clientKeyPassword: ""
# information about cluster 03
cluster03:
name: cluster03
topics:
replicationFactor: 1
timestamps:
nameOverride: ""
partitions: 25
schemas:
nameOverride: ""
topicPattern: '{tenant}-{instance}-{environment}-{topic}'
groupPattern: '{tenant}-{instance}-{environment}-{group.id}'
patternDefaultValues:
environment: test3
bootstrapServers: "cluster03-kafka-bootstrap:9093"
securityProtocol: "SSL"
additionalClientConfigs:
ssl.enabled.protocols: TLSv1.2
tls:
caCerts:
- |
-----BEGIN CERTIFICATE-----
-----END CERTIFICATE-----
- |
-----BEGIN CERTIFICATE-----
-----END CERTIFICATE-----
clientCert: |
-----BEGIN CERTIFICATE-----
-----END CERTIFICATE-----
clientKey: |
-----BEGIN PRIVATE KEY-----
-----END PRIVATE KEY-----
#clientKeyPassword: ""
# Settings for the Offset Committer connector
offsetCommitter:
enabled: true
# Determine the number of connect tasks to run for the offset committer
maxTasks: 1
# Use the override to use a custom consumer group for this connector
#groupIdOverride: ""
# Do not perform a connectivity check on starting the connector
skipConnectionValidation: true
# The amount of time subtracted from the received timestamp to ensure the offset commit points to a record that was distributed before the timestamp
distributionOffsetMs: 15000
# Set the number of items in the topic and group resolve cache
topicCacheSize: 200
groupCacheSize: 200
# Reinitialisation trigger settings for the internal senders when continuous errors occur
reinitializeOnContinuousError:
maximumCount: 500
maximumTimeMs: 10000
# Any additional client configs needed to connect to the source cluster to commit the offsets
additionalClientConfigs:
ssl.enabled.protocols: TLSv1.2,TLSv1.3
ssl.endpoint.identification.algorithm: ''
# Override the default Kafka Connect Sink Task Consumer settings
consumerOverrides:
max.poll.size: 5
# Settings for the Schema Distributor connector
# NOTE: Only for the Confluent-based Legacy Schema Registry. Leave disabled when using Apicurio.
schemaDistributor:
enabled: false
# Schemas are distributed one way to the following clusters
targetClusterNames:
- "cluster02"
- "cluster03"
additionalClientConfigs:
acks: all
retries: 0
max.in.flight.requests.per.connection: 1
enable.idempotence: false
ssl.enabled.protocols: TLSv1.2,TLSv1.3
ssl.endpoint.identification.algorithm: ''
consumerOverrides:
max.poll.size: 10
# Axual uses a multi level distribution model to make sure records and offsets arrive at the correct cluster
# This is a dictionary containing the distribution levels relevant to the source cluster.
# The level number is 1 to 32
levels:
1:
targetClusterName: "cluster02"
messageDistributor:
enabled: true
maxTasks: 2
groupIdOverride: ""
topicRegex: 'axual-dta-.*'
topicCacheSize: 1000
additionalTargetClientConfigs: {}
consumerOverrides:
max.poll.size: 8
offsetDistributor:
enabled: true
maxTasks: 2
groupIdOverride: ""
windowSizeMs: 15000
topicCacheSize: 1000
groupCacheSize: 1000
additionalLocalClientConfigs: {}
additionalTargetClientConfigs: {}
consumerOverrides:
max.poll.size: 6
2:
targetClusterName: "cluster03"
messageDistributor:
enabled: true
maxTasks: 2
groupIdOverride: ""
topicRegex: 'axual-dta-.*'
topicCacheSize: 1000
additionalTargetClientConfigs: {}
consumerOverrides:
max.poll.size: 9
offsetDistributor:
enabled: true
maxTasks: 2
groupIdOverride: ""
windowSizeMs: 15000
topicCacheSize: 1000
groupCacheSize: 1000
additionalLocalClientConfigs: {}
additionalTargetClientConfigs: {}
consumerOverrides:
max.poll.size: 7
Useful Links
After distributor installation with desired message/schema distributor settings, you can check the connectors with the instructions below.
-
Use port forwarding or the ingress to enable access distributor application. (ex: port 8083)
-
To reach the list of connectors use the link
http://localhost:{port}/connectors/http://localhost:8083/connectors/ -
To reach one of your schema or message distributors and their configurations using the name listed
http://localhost:8083/connectors/{listed-connector-name} -
To check its status with
http://localhost:8083/connectors/{your-connector-name}/status -
To check its configs with
http://localhost:8083/connectors/{your-connector-name}/config -
You can check its tasks with
http://localhost:8083/connectors/{your-connector-name}/tasks