Dependencies
This guide explains the components the Axual Platform relies on but does not ship, and the job each one does for the platform: the Strimzi operator, cert-manager, Reloader, an ingress controller, ExternalDNS, a Prometheus stack, a relational database and HashiCorp Vault, plus the integrations a production installation is expected to have in place. They are only "external" from the perspective of the namespace the Axual charts install into; several, such as Strimzi and cert-manager, are cluster-wide operators the platform relies on as much as its own components.
Type |
Explanation |
Goal |
Understand what each dependency contributes to an Axual Platform installation, and which parts of the platform depend on it. |
Audience |
Platform Operators and the infrastructure team that provisions cluster-level components. |
When to use |
At the start of an installation, when working out what the cluster needs before the charts run. |
None of these ships as part of the Axual Helm charts, though the Axual Governance charts can deploy a MySQL or Vault instance for a proof of concept. Each is otherwise provided by the infrastructure team or installed from its own official chart. For the cluster requirements each one implies, see Infrastructure Requirements.
| Most of these dependencies install Kubernetes Custom Resource Definitions, which needs elevated cluster permissions. Confirm you have them, or that someone does, before planning the order of work. |
Strimzi
The Streaming layer of the Axual Platform contains the Apache Kafka brokers, and the Strimzi Cluster Operator is what installs and manages them. It maintains Kafka clusters declaratively, which fits the Deployment Strategy the platform follows.
Red Hat is one of the contributors to Strimzi, and in 2024 Strimzi became a CNCF incubator project. Axual does not supply it, so the version to install is the one Axual supports for the chart release you are deploying, stated in Axual Kafka README. That page is generated from the chart, so it is the version to trust when sources disagree.
Cert Manager
TLS secures every connection in the platform. The number of certificates involved, and the regular interval at which each one has to be replaced, make managing them by hand error-prone.
Cert-manager issues and reissues certificates without manual intervention, writing each one into a Kubernetes Secret in the kubernetes.io/tls shape the Axual charts read. TLS Secret Formats Reference describes that shape and the other Secret formats a component can be pointed at.
Reloader
cert-manager reissues certificates and refreshes Secrets, but restarting pods is outside its responsibilities, so a component keeps serving the certificate it loaded at startup until something restarts it. Reloader is not a dependency in its own right; it exists solely to close this gap left by cert-manager.
Stakater Reloader watches the Secret and restarts the pods that mount it once a new certificate lands, which makes certificate rolling automatic end to end.
Ingress
Kubernetes exposes a Service in several ways, such as a LoadBalancer or an OpenShift Route, and an Ingress is the most common. Kubernetes leaves the implementation of Ingress to Ingress Controllers, which have to be installed separately.
The controller an Axual installation needs has to pass TLS through untouched, because the API Gateway and Apicurio Registry authenticate callers with mutual TLS rather than terminating it at the edge. Install an Ingress Controller covers the installation and the controller to use.
External DNS
ExternalDNS synchronises exposed Kubernetes Services and Ingresses with a DNS provider, creating and removing records as the objects change.
An Axual Platform needs a DNS name for every endpoint it exposes, and DNS and Certificate Inventory Reference lists them per component. Those records can be created by hand, which is what a small or static installation usually does, or managed by ExternalDNS from the Ingress objects the charts create. The second option matters most where the hostnames change with the installation, such as a per-tenant or per-environment naming scheme, because a missed record surfaces as an endpoint that resolves nowhere rather than as a failed deployment.
ExternalDNS is optional and Axual does not ship it. Where it is used, the DNS names it manages must match the names on the certificates, since the certificate is issued for the hostname a client resolves.
Prometheus Stack
The Prometheus stack, containing Prometheus, Grafana and AlertManager, is the common way to handle Monitoring & Metrics on a Kubernetes cluster. The Prometheus Operator is the part of it the platform depends on, because the Axual charts ship PodMonitor, ServiceMonitor and PrometheusRule resources that only the operator understands.
An installation that already runs Prometheus can federate the platform’s metrics into it instead of running a second stack. Installing the Monitoring Stack covers both routes.
Database
Self-Service and Keycloak each store their state in a relational database schema, and Apicurio Registry needs a third when it is deployed. A managed database service is preferred in production.
-
MySQL 8 (preferred), or MariaDB 10.3 or higher. Character set UTF8MB4, collation
utf8mb4_0900_ai_ci(MySQL) orutf8mb4_unicode_ci(MariaDB). -
PostgreSQL is also supported.
-
50G of storage, with backups enabled.
The Axual Governance charts can deploy a MySQL instance for a proof of concept, which is the one exception to this page’s rule: everywhere else, provide your own or reuse what the infrastructure already runs. SQL explains what each schema holds.
Vault
Connector credentials and Kafka streaming layer credentials are never stored in Platform Manager’s database. They live in HashiCorp Vault, which the platform uses as two logical Vaults even where both are the same physical server.
A Vault already present in the infrastructure can be reused, or the Axual Governance charts can deploy one, the same exception as the database above. How to Set Up Vault for Governance and How to Set Up the Connector Vault for Kafka Connect cover the setup; Vault explains what each logical Vault stores.
Production-grade integrations
The integrations below are not required to bring a trial installation up, but a production installation is expected to have all of them in place; skip a row here and it comes back later as a gap in identity, change control, secrets handling or observability.
| Category | Requirement | Remarks |
|---|---|---|
Identity Provider |
Integrate an Identity Provider with the Axual Platform, for example Azure Active Directory. Which one you use depends on the infrastructure or cloud solution available. Without one, tenants use Keycloak’s local realm instead. |
|
GitOps facilities |
Axual prefers a GitOps way of working, where Git holds all infrastructure and configuration and a tool such as Argo CD or Terraform applies it. Git repositories for the installation configurations are the minimum requirement. Deployment tooling on top of them is recommended. See Deployment Strategy for why Axual prefers this workflow. |
|
Sensitive Configuration Storage |
The platform configuration holds many sensitive values, such as private keys, database passwords and keystore passwords. A Git repository stores the configuration, so encrypt these values or keep them somewhere else. Helm Secrets with Mozilla SOPS is supported, as are Sealed Secrets and 1Password Secrets. |
Skip this for a POC. |
Monitoring & Alerting |
Axual Platform exposes metrics that Prometheus can scrape directly. Axual recommends feeding these metrics into the operations team’s central Prometheus, Grafana and Alertmanager stack. The charts ship ServiceMonitors, PodMonitors and PrometheusRules for alerting. |
If no Prometheus stack is available, integrate the metrics with your own alerting solution. |
Centralised Logging & Tracing |
A centralised logging or distributed tracing solution improves the platform’s observability. All components comply with OpenTelemetry (OTEL) and can write logs in JSON format. |