Installation and Configuration of Axual Platform
This guide is the entry point for installing the Axual Platform: what to prepare, which of the two paths to take, the order the layers go in, and where to go when a stage fails. For what the platform is made of before any of it is installed, see Axual Architecture & Components.
Type |
Reference |
Goal |
Find the stage of the installation you are at, and the guides that stage needs. |
Audience |
Platform Operators installing or extending an Axual Platform on Kubernetes or OpenShift. |
When to use |
Start here before the first chart is installed, and come back to find the next stage. |
Contents
The sections below follow an installation from an empty cluster to a platform people can use:
The installation order
Every installation moves through the same stages, and each assumes the previous one is finished. The table names each stage, the guides that cover it, and the state the stage leaves behind:
| Stage | Guides | Finished when |
|---|---|---|
Before 1 |
You have decided whether the charts run under Helm or a GitOps workflow, and how many Kafka clusters the installation needs. Both decisions apply to every stage below, which is why they carry no stage number of their own. |
|
1 |
The cluster meets the infrastructure requirements and carries the operators, ingress controller and certificates the Axual charts expect. |
|
2 |
You know whether you are running a trial or a full installation. |
|
3 |
Brokers are reachable, Apicurio Registry answers, and topics can be created. |
|
4 |
Self-Service is reachable through the API Gateway. |
|
5 |
The optional components you need are running. Any subset of them, or none at all. Its five component families do not depend on each other, so install them in any order, at any point after stage 4. |
|
6 |
Keycloak realms, Vault and the first Self-Service resources exist, so people can start using the platform. |
|
7 |
Logs, metrics, traces and alerts reach your monitoring stack. This stage can run alongside stages 3 to 5, and belongs before go-live. |
Stages 3 and 4 install the two halves of the platform separately because they serve different jobs: Streaming is the data plane, the Kafka cluster that holds the data, and Governance is the control plane that manages one or more of those clusters. Each half has its own Helm chart, so a Governance installation can manage a Kafka cluster it did not deploy.
The "Before 1" row is a decision rather than a stage: Helm or GitOps changes how every later stage is applied, so it belongs before the first chart and outside the numbering.
Certificates outlive the installation. Stage 1 only gets the first set in place; Certificate Management covers reading, rotating and replacing them on a platform that is already running.
Two paths through the installation
Stages 3 to 5 install the platform one layer at a time, from a values file you own and can harden for production. That is the path a real environment takes.
Quick Setup is the other path: a guided trial on your own infrastructure, using preconfigured values, in one of three scenarios. It installs the same components with far fewer decisions, and it does not produce a hardened environment.
The two paths differ in who makes the decisions, not in what gets installed:
| Full installation | Quick Setup | |
|---|---|---|
Values |
You write and keep the values file for each chart. |
Preconfigured values files come with the guide. |
Component set |
You choose per layer, and any subset of the runtime components. |
Fixed by the scenario you pick: the full stack, or governance only. |
Secrets and certificates |
Your own, issued and stored the way the environment requires. |
The simple credentials the guide provides, enough for an evaluation. |
Result |
An environment you can harden and run in production. |
A working platform to evaluate, not a hardened one. |
Both paths arrive at the same place. Stage 6 follows either of them, and a trial built through Quick Setup can be rebuilt the long way later without discarding the Self-Service resources that stage 6 created.
When a stage fails
Troubleshooting covers the failures these stages produce, from an ingress that cannot be reached to a connector that starts but moves no data. It is a destination from any stage above rather than a stage of its own.
Once the platform is live, Acting on Alerts is the runbook for an alert that has already fired.