Deployment Prerequisites

This section covers what a cluster needs before installing RMS with Helm. For the install/upgrade workflow itself, see Kubernetes Deployment with Helm.

Cluster requirements

• Kubernetes cluster (1.24+)
• Helm 3.x
• NGC account and API key - for pulling the chart and images from NGC
• A container image registry the cluster can pull from. If it requires authentication, provision an imagePullSecret (via ESO, ArgoCD, or manually) and reference it in global.imagePullSecrets.

Persistence strategy

RMS persists firmware-object state, cached artifact metadata, job tracking, and apply history (never rack topology). Choose one of three modes via databaseMode:

For external and standalone modes, RMS applies its embedded sqlx migrations automatically on API-server startup - no separate migration job is required.

Firmware storage

The firmware download filesystem defaults to a node hostPath (apiServer.firmwareStoragePath). For durable storage that survives pod rescheduling, set apiServer.firmwarePersistentVolumeClaim to an existing claim in a site values file (keep it empty in the chart base). When apiServer.replicaCount > 1, use a volume that supports mounting from every scheduled pod (ReadWriteMany); ReadWriteOnce block volumes attach to only one node and cause Multi-Attach errors on additional replicas.

Certificates

An RMS deployment needs a component that issues, rotates, and distributes certificates from a CA - for example cert-manager. There are two distinct categories of certificate:

1. Inbound (RMS API server mTLS) - secures traffic between RMS clients and the RMS gRPC API. Clients must present certificates issued by the same CA. The CA must issue the server certificate with Subject Alternative Names (SANs) matching the RMS service URL, bottom-up:
   • rms-api-server
   • rms-api-server.<namespace>
   • rms-api-server.<namespace>.svc
   • rms-api-server.<namespace>.svc.cluster.local
2. Outbound (switch mTLS) - secures traffic between RMS and switch service APIs (NVUE, NMX-C). The switch must serve a cert reflecting its SAN, and RMS must hold client certs signed by an authority the switch trusts. See Configuring RMS: [switches] for the on-disk layout RMS expects.

Chart-managed certificates

When cert-manager and a site issuer are already present, the Helm chart can issue all three certificates itself. Set certificates.enabled: true and certificates.issuerRef.name — the issuer name is required and has no default, so the chart fails to render until a site supplies it — and the chart creates the API server Certificate plus one per switchCertCertificates and clientTlsCertificates entry, each named after and writing to the secret the entry already references. The issuer, SPIFFE trust domain, lifetimes, key algorithm, and SANs are all values, so they can vary per site. See Certificate automation for the full override surface. The rest of this section covers issuing them outside the chart.

Chart-managed certificates are issued and renewed automatically, but only the switch client material is picked up automatically. The API server reads its certificate once at startup and needs a pod restart; switches keep the certificate last installed on them and need ConfigureSwitchCertificate re-run. Plan a redistribution cadence at least as short as certificates.duration before enabling this - see Rotation and renewal.

cert-manager example

A self-signed root can bootstrap both categories. This issues a CA, an RMS server cert (referenced by apiServer.tls.existingSecret), and switch server/client certs (referenced by switchCertCertificates / clientTlsCertificates):

1
# 1. SelfSigned ClusterIssuer (bootstraps the CA cert)
2
apiVersion: cert-manager.io/v1
3
kind: ClusterIssuer
4
metadata:
5
  name: selfsigned-cluster-issuer
6
spec:
7
  selfSigned: {}
8
---
9
# 2. CA Certificate - the shared root of trust for RMS and its clients
10
apiVersion: cert-manager.io/v1
11
kind: Certificate
12
metadata:
13
  name: rms-ca
14
  namespace: rack-manager
15
spec:
16
  isCA: true
17
  commonName: rms-ca
18
  secretName: rms-ca
19
  duration: 87600h   # 10 years
20
  renewBefore: 720h
21
  privateKey:
22
    algorithm: ECDSA
23
    size: 256
24
  issuerRef:
25
    name: selfsigned-cluster-issuer
26
    kind: ClusterIssuer
27
---
28
# 3. CA Issuer backed by the rms-ca secret above
29
apiVersion: cert-manager.io/v1
30
kind: Issuer
31
metadata:
32
  name: rms-ca-issuer
33
  namespace: rack-manager
34
spec:
35
  ca:
36
    secretName: rms-ca
37
---
38
# 4. RMS server cert - referenced by apiServer.tls.existingSecret
39
apiVersion: cert-manager.io/v1
40
kind: Certificate
41
metadata:
42
  name: rms-api-server-tls
43
  namespace: rack-manager
44
spec:
45
  secretName: rms-api-server-tls
46
  duration: 8760h    # 1 year
47
  renewBefore: 720h
48
  dnsNames:
49
    - rms-api-server
50
    - rms-api-server.rack-manager
51
    - rms-api-server.rack-manager.svc
52
    - rms-api-server.rack-manager.svc.cluster.local
53
  issuerRef:
54
    name: rms-ca-issuer
55
    kind: Issuer
56
---
57
# 5. Switch-side server certs - referenced by switchCertCertificates
58
apiVersion: cert-manager.io/v1
59
kind: Certificate
60
metadata:
61
  name: rms-nmxc-server-certificate
62
  namespace: rack-manager
63
spec:
64
  additionalOutputFormats:
65
    - type: CombinedPEM
66
  secretName: rms-nmxc-server-certificate
67
  duration: 8760h
68
  renewBefore: 720h
69
  privateKey:
70
    algorithm: ECDSA
71
    size: 384
72
  dnsNames:
73
    - myrack.example.com
74
  issuerRef:
75
    name: rms-ca-issuer
76
    kind: Issuer
77
---
78
# 6. RMS-side switch client certs - referenced by clientTlsCertificates
79
apiVersion: cert-manager.io/v1
80
kind: Certificate
81
metadata:
82
  name: rms-nmxc-client-certificate
83
  namespace: rack-manager
84
spec:
85
  secretName: rms-nmxc-client-certificate
86
  duration: 8760h
87
  renewBefore: 720h
88
  privateKey:
89
    algorithm: ECDSA
90
    size: 384
91
  subject:
92
    organizations:
93
      - rms
94
  commonName: rms
95
  usages:
96
    - client auth
97
  issuerRef:
98
    name: rms-ca-issuer
99
    kind: Issuer

Generating local test certificates without cert-manager

For local testing off-cluster, you can generate a self-signed CA plus server and client certificates with openssl. Use organization-approved tooling in production. The two material sets RMS needs are the RMS API server mTLS material (cert/key/ca) and the NVLink switch mTLS material laid out per domain (see Configuring RMS: switch certificate directory layout).

Database credentials Secret

For external/standalone Postgres, RMS reads credentials from a Kubernetes Secret and builds DATABASE_URL from them (the password never lands in a ConfigMap). Use External Secrets Operator with a ClusterSecretStore, or pre-create the Secret and reference it via database.credentialsSecret. For a quick standalone-mode Secret:

$
kubectl create secret generic rms-postgres-auth \
>
  --namespace rack-manager \
>
  --from-literal=username=postgres \
>
  --from-literal=password=<password> \
>
  --from-literal=POSTGRES_PASSWORD=<password>

Keep credentials, database URLs, TLS keys, client certificates, and artifact tokens out of source control - prefer secret managers or Kubernetes Secrets.