Infrastructure Requirements

This reference lists what the Axual Platform needs from the infrastructure it runs on: the Kubernetes cluster requirements, and the DNS names and certificates a deployment has to have in place.

Type

Reference

Goal

Check whether a target cluster meets what the platform needs, before designing a deployment.

Audience

Infrastructure engineers and Platform Operators designing or reviewing a deployment.

When to use

At the start of an installation, and when reviewing an existing cluster against the requirements.

The platform runs on Kubernetes and on OpenShift. Both are supported and run production workloads, and the platform is listed on the Red Hat Ecosystem Catalog. For how the platform behaves under failure, see Resilience.

The examples throughout this documentation use kubectl. The equivalent OpenShift commands work the same way: replace kubectl with oc.

The sections below cover each area in this reference:

Requirements
DNS names and certificates

Requirements

Treat these as the starting point for the infrastructure design of a new installation, to be refined with the team that owns the cluster. They group into three kinds: what the cluster itself must provide, what you must be able to reach or be granted, and prerequisites significant enough to have their own guide. Services the platform needs running somewhere, such as a database and Vault, the integrations a production installation is expected to have in place, such as an identity provider or a GitOps workflow, and every other dependency Axual does not ship, are covered in Dependencies instead.

Cluster capacity

What the Kubernetes or OpenShift cluster itself must provide, independent of the Axual Platform.

Category	Requirement	Remarks
Kubernetes Version	> 1.24	EKS, AKS, GKE, Rancher, OpenShift are supported.
Kubernetes Nodes	A Production environment needs three groups of Nodes: 3 dedicated Nodes for Kafka brokers and controllers: 8 CPU, 32GB Nodes are a common choice. Scale horizontally by adding groups of 3 brokers. Place the 3 Nodes in different Availability Zones, so the deployment stays highly available. Taint them, so other platform components avoid them and the Kafka Nodes stay dedicated. 2 or 3 Misc Nodes for all other Axual Platform components: 4 CPU, 16GB, non-dedicated Nodes. 3 Nodes for Connect or Axual Distributor, or both: Combine these with the Axual Platform components, replacing the Misc Nodes above. Place the 3 Nodes in different Availability Zones, so the deployment stays highly available.	For a proof of concept (POC), 4 nodes of 4 CPU, 16G are enough. Further reading on Kafka cluster setups: Apache Kafka design covers the broker architecture, replication and durability guarantees these figures assume.
Persistent Volumes	Kafka brokers perform best with a dedicated SSD or spinning disk per broker. The faster the disk, the faster the Kafka cluster. Prefer block devices over NFS, because Apache Kafka is sensitive to storage latency. Size the volumes from the expected retention period, and the number and size of records. Dedicating volumes to Availability Zones or racks is essential for disaster recovery. These volumes need no backup, because Kafka replicates the data internally. The data is real-time, so restoring a backup is not feasible. See Storage & State for how each component uses the storage it is given.
Network Connectivity	Kafka requires low latency connections between brokers. The Kubernetes cluster must run a NetworkPolicy implementation such as Calico, which rules out AWS VPC CNI on EKS. API Gateway, Kafka brokers, Apicurio Registry and Rest Proxy must be reachable from every part of the company that uses the event streaming platform, including all DevOps team environments. Service Meshes are supported

Access grants

What you must be able to reach or be granted, rather than a capacity to size.

Category	Requirement	Remarks
Kubernetes permissions	Installing the Strimzi Kafka Operator requires Kubernetes cluster administrator privileges, because it installs Custom Resource Definitions (CRDs), Cluster Roles and Cluster Role Bindings. Either grant that access, or have the Kubernetes team install the operator. Between two and three namespaces are required: one for the Axual Platform, one for the Strimzi Operator, a third to host a HashiCorp Vault cluster, when the infrastructure does not already provide one. See Preparations for creating the namespace and its image pull Secret.
Helm Chart Repository	Axual distributes the platform as Helm charts, so the Helm chart repository must be reachable from the Kubernetes cluster or from a deployment tool. Axual Helm charts are available publicly (with authentication) at registry.axual.io An internal Helm repository can proxy Axual’s public Helm repository. Where a Helm repository is not an option, push the charts into any Git repository. The charts must be reachable from the CI/CD system, such as Argo CD or GitLab. See Working with Helm Charts for getting access and pulling a chart.
Image Registry	Axual Platform components ship as images only, based on Red Hat Universal Base Images. You must be able to pull these images from inside the Kubernetes cluster. Axual Platform images are available publicly (with authentication) at registry.axual.io If that is not possible, provide an internal image registry that proxies Axual’s public image registry. If proxying is not possible either, pull every relevant Axual Platform image by hand and push it to an internal registry. Repeat this at every upgrade, so the new Axual images are available locally.

Prerequisites with their own guide

These three are significant enough to have a dedicated how-to rather than a table row. Listed here so the requirement is not invisible from this reference, each points at the guide instead of repeating it.

Load Balancers or Ingress: expose Kafka brokers, the Kafka bootstrap and Rest Proxy through load balancers or another highly available technology, because an ingress controller can be a single point of failure. Non-critical components, including the API Gateway and Apicurio Registry, can go through Ingresses instead; both need SSL passthrough on ports 80 and 443, because callers authenticate with mutual TLS (mTLS). Nginx Ingress Controller and OpenShift Routes are supported. See Install an Ingress Controller.

The community-maintained ingress-nginx controller was deprecated in March 2026, so the controller to use on a new cluster is not the one the older instructions install.
Certificates: every connection between Axual components is authenticated with mutual TLS, so a component has nothing to start with until its certificate exists. Provide a root Certificate Authority (CA) the platform adds to its truststore, and one every client application can obtain a certificate from; cert-manager and Stakater Reloader are supported and preferred for issuing and renewing them. See How to Prepare Certificates and DNS Before Installing.
DNS: every exposed component needs a name that resolves from inside the Kubernetes cluster and from anywhere in the company that reaches it, including employee desktops for Self-Service and every server running a producer or consumer application. A certificate is issued for the hostname a client resolves, so DNS and Certificates are prepared together. See the same guide, How to Prepare Certificates and DNS Before Installing.

DNS names and certificates

The DNS names to register and the certificates to request are listed separately, because they are an inventory the infrastructure team works from rather than a design constraint. See DNS and Certificate Inventory Reference.

Resilience covers how the platform behaves when a node or an Availability Zone fails, which is what the node layout above is sized for.
Storage & State covers what each component writes to the volumes this reference asks you to provide.