Skip to content

Infrastructure deployment order

The infrastructure components have dependencies on each other — mostly on cert-manager, which issues the internal and public certificates the others use. Deploying them out of order leaves a component unable to start or get its certificate. This topic describes the order to follow, before moving on to the Helm deployment order for Domino Workspace itself.

Step 1: Kubernetes cluster

Stand up the cluster — see the RKE2 example or the chosen distribution's own documentation. Every component below depends on this.

Step 2: Storage and load balancing

No dependency on each other or on anything in Step 1 beyond the cluster itself — deploy in any order, or in parallel:

  • Storage — a StorageClass, needed by any component with a PersistentVolumeClaim (HCL Domino, ClamAV, Chat and Meetings, Loki, kube-prometheus-stack's Prometheus, and others).
  • Load balancer — needed for the APISIX Service (Step 4) to get an external IP. Not needed on a managed Kubernetes offering that already provisions LoadBalancer Services.

Step 3: cert-manager

cert-manager issues the internal cluster-ca certificates used by Linkerd, Loki, and ClamAV, plus (optionally) the public-facing certificate for APISIX. Deploy it before any component below that needs a certificate from it.

Step 4: APISIX

APISIX requires cert-manager (Step 3) for its public-facing certificate, and a working load balancer (Step 2) to become reachable. It also needs the dom-router plugin — installed separately — before HCL Domino is deployed.

Optional: Linkerd

Linkerd requires cert-manager (Step 3) — its identity certificate is issued from the same internal CA — and trust-manager for its trust roots. Not a hard requirement of any Domino Workspace chart.

Optional: observability stack

  • kube-prometheus-stack — requires cert-manager (Step 3) only if Grafana is exposed over HTTPS through APISIX (Step 4). Deploy before Linkerd's control plane if pointing linkerd-viz at this Prometheus instance instead of its bundled one — see Linkerd setup.
  • Loki — requires cert-manager (Step 3) for its gateway certificate, and an S3-compatible bucket.
  • Alloy — requires Loki (above) to be reachable, and the cluster CA ConfigMap distributed by trust-manager if Loki's gateway uses the internal CA. Deploy after Loki.

After infrastructure

Once the cluster, storage, load balancer, cert-manager, and APISIX are in place, continue with the Helm deployment order for HCL Domino and the Domino Workspace applications.