Runtime Installation
This guide introduces the runtime components: the parts of Axual that are deployed on their own, separately from the Streaming and Governance charts, and that a working platform does not require. Each is installed only if the platform needs what it does. For what each one is, see Runtime Components.
Type |
Reference |
Goal |
Find the guide for the runtime component you need, and skip the ones you do not. |
Audience |
Platform Operators with access to the target namespace and, for most components, to Vault. |
When to use |
Stage 5 of The installation order, after the streaming and governance layers exist. Install any subset, in any order. |
Moving data in and out of Kafka
Install Kafka Connect to run Kafka connectors. It gives every tenant its own Connect cluster, deployed with the kafka-connect Helm chart and managed by the Strimzi operator.
Don’t install Axual Connect on a new platform: it’s deprecated (see Why Kafka Connect replaces Axual Connect for the timeline).
Follow How to Deploy a Kafka Connect Cluster to install it. It depends on two prerequisites, done in this order first: How to Prepare the Kafka Broker for Kafka Connect and How to Set Up the Connector Vault for Kafka Connect. To surface connector logs in Self-Service, switch on log reading in the Runtime Provisioner with How to Enable Kafka Connect Log Reading. Kafka Connect: Concepts and Architecture explains how these pieces fit together, and Kafka Connect Helm Readme lists every chart value.
The two differ in how many clusters exist and who runs them:
| Kafka Connect | Axual Connect | |
|---|---|---|
Clusters |
One per tenant, sized independently. |
One shared by every tenant on the instance. |
Who runs the pods |
The Strimzi operator, from a |
Its own Helm release, installed directly. |
Connector plugins |
Added per cluster. |
Shared across every tenant on the instance. |
Lifecycle |
What new installations use. |
Deprecated. See the timeline. |
Platforms that already run Axual Connect should move to Kafka Connect with Migrating from Axual Connect to Kafka Connect. Until then, Axual Connect Installation stays available to maintain the existing deployment.
Replicating data between clusters
The Axual Distributor copies records, consumer offsets and, for the legacy registry, schemas from one Kafka cluster to the others in the same instance. A single-cluster platform does not need it, and How to Deploy the Axual Distributor installs it where it does.
Distribution Between Kafka Clusters describes what gets copied where. Read it before you configure the chart, because the cluster names it uses are fixed once data has been distributed.
Stream processing and AI access
The Runtime Provisioner runs the stream-processing applications that Self-Service users define in YAML, and How to Deploy the Runtime Provisioner installs it. The provisioner is the operator-installed component; users create the applications themselves. How to Customise KSML Application Deployments changes where and how it deploys them.
Flink SQL applications run on a Ververica Platform deployment, which you install and operate separately from Axual. Once it’s running, How to Enable Flink in Axual Governance switches on the Flink screens in Self-Service. Flink describes how Platform Manager connects to Ververica Platform.
How to Deploy the Axual MCP Server exposes the platform to an AI client through the Model Context Protocol. One server is deployed per tenant, unlike the components above, which serve every tenant on the instance. It authenticates through two Keycloak clients, created in How to Configure Keycloak for the MCP Server, which comes first.
Each component has its own failure modes, and Troubleshooting lists them alongside the two Connect-specific troubleshooting pages.