Red Hat packages OpenShift AI installation as a Helm and GitOps workflow

Red Hat has published a Helm-based installation path for Red Hat OpenShift AI that turns a multi-operator platform deployment into a repeatable chart-driven workflow. The guide is built around the rhai-on-openshift-chart and the upstream odh-gitops repository, with options for a full data-science platform or a smaller inference-only stack.

The practical change is not simply replacing YAML with Helm. The chart models the dependencies among OpenShift AI components and the operators around them, including cert-manager, LeaderWorkerSet, JobSet, Red Hat Connectivity Link, Kueue, OpenTelemetry, Node Feature Discovery and NVIDIA’s GPU Operator. That gives platform teams one place to declare which capabilities they want and which dependencies are already managed elsewhere.

What the chart automates

The chart installs operators through Operator Lifecycle Manager and configures their custom resources. It can manage KServe, AI Pipelines, the OpenShift AI dashboard, Kueue, Model Registry, Ray, TrustyAI, workbenches, MLflow, Spark, Feast and other components exposed through the DataScienceCluster resource.

Dependency controls use three states: auto installs an operator only when an enabled component needs it, true installs it unconditionally, and false tells the chart that the dependency already exists. The chart also resolves transitive requirements. For example, enabling KServe can bring in cert-manager and Red Hat Connectivity Link rather than leaving operators to reconstruct that chain manually.

Red Hat also provides an rhaii profile for an inference-focused deployment. It enables KServe with distributed inference using llm-d and installs the dependencies needed for that path, while leaving pipelines, dashboards and workbenches disabled. Teams can start with that profile and then override individual components.

Where operators still need judgment

The guide requires OpenShift 4.19.9 or later, cluster-admin access, Helm 4 and authentication to registry.redhat.io. Each OpenShift AI release has a corresponding chart tag, so the selected chart version needs to match the target platform version.

Custom resource definitions create a sequencing issue. On the first Helm run, OLM resources can be installed while custom resources are skipped because their CRDs do not yet exist. The guide recommends waiting for the required CRDs and running the upgrade again, or automating several retries. Argo CD users must account for the same behavior with skipCrdCheck: true and SkipDryRunOnMissingResource=true.

There is also a separate Authorino TLS step when Red Hat Connectivity Link supplies authentication and rate limiting for KServe. The guide provides a preparation script and verification commands, but that remains an operational dependency rather than a hidden chart detail.

A sensible production rollout

The chart is most useful as a controlled platform artifact, not as an excuse to accept every default. Red Hat recommends pinning operator versions for production environments; specifying an OLM version switches approval to manual unless teams explicitly restore automatic upgrades. That makes development, staging and production easier to keep aligned while upgrades are validated.

A cautious adoption path is to test the inference-only profile first, record the resolved operator set, confirm Authorino TLS and KServe health, and then promote the same values through Argo CD. For a full platform deployment, teams should use a version-controlled values file rather than a long command line and explicitly mark dependencies already owned by the cluster platform team.