Automating Red Hat OpenShift AI installations with Helm and GitOps

In our previous article, How to manage Red Hat OpenShift AI dependencies with Kustomize and Argo CD, we introduced a GitOps approach to deploying Red Hat OpenShift AI dependencies. Building upon that work, this article explores an alternative, streamlined method.

Red Hat OpenShift AI provides a platform for data science and AI workloads, but installing it on a cluster involves more than just deploying a single operator. A production-ready AI platform requires certificate management, job queuing, GPU operators, and several other dependencies. These components must be installed, configured, and kept in sync. Doing this manually across multiple environments is tedious and error-prone.

To simplify this process, we created the odh-gitops repository. This repository provides Helm charts, a robust package management solution for Kubernetes, that turn this multi-step installation into a single, repeatable command. Specifically, the rhai-on-openshift-chart handles operator installation with Operator Lifecycle Manager (OLM), dependency resolution, and component configuration so you can focus on building AI workloads instead of wrestling with infrastructure.

This guide demonstrates how to use Helm to manage Red Hat OpenShift AI and its dependencies on Red Hat OpenShift, from a full platform installation to a lightweight inference-only deployment.

In this article you learn how to:

Install the full Red Hat OpenShift AI platform on Red Hat OpenShift with a single Helm command
Deploy a lightweight Red Hat AI Inference stack for model serving
Customize components and dependencies using profiles, values files, and tri-state dependency management
Integrate the charts with Argo CD for a GitOps workflow

Prerequisites

Before you begin, make sure you have the following:

An OpenShift cluster (version 4.19.9 or later)
Either the kubectl or oc command
Cluster admin permissions
Helm (version 4) installed

Knowledge prerequisites:

Basic familiarity with Kubernetes concepts (namespaces, operators, CRDs)
Understanding of Helm charts and values files
(Optional) Familiarity with Argo CD if using the GitOps workflow

Understanding the chart architecture

Before diving into the installation steps, it helps to understand what the chart does and how it manages the complexity of a multi-operator deployment.

What the chart installs

The rhai-on-openshift-chart uses the Operator Lifecycle Manager (OLM) to install operators on OpenShift. When you run helm install, the chart creates OLM resources (Namespace, OperatorGroup, Subscription) that tell OLM which operators to install. It then creates the Custom Resources (DataScienceCluster, DSCInitialization, and so on) that configure those operators. The chart supports both Red Hat OpenShift AI and Open Data Hub (ODH) operators. Open Data Hub is the upstream community project for OpenShift AI. Switching between them is as simple as changing a single value:

Type	Operator	Namespace	OLM Source
rhoai	rhods-operator	redhat-ods-operator	redhat-operators
odh	opendatahub-operator	openshift-operators	community-operators

Available components

The chart manages all Red Hat OpenShift AI and ODH components through the DataScienceCluster (DSC) resource. Each component can be independently set to Managed (enabled) or Removed (disabled). Kueue is the only exception because of how it interacts with the operator, you must set it to Unmanaged to successfully enable it or Removed to disable it.

kserve: KServe model serving
aipipelines: AI Pipelines
dashboard: OpenShift AI Dashboard
kueue: Kueue job queuing
modelregistry: Model Registry
ray: Ray distributed computing
trainer: Trainer
trainingoperator: Kubeflow Training Operator
trustyai: TrustyAI explainability
workbenches: Workbenches/notebooks
mlflowoperator: MLflow tracking and model registry
sparkoperator: Spark Operator
feastoperator: Feast feature store
ogx: Open GenAI Stack Operator

How dependency resolution works

One of the chart's most useful features is its tri-state dependency management system. Each dependency operator has an enabled field that accepts three values:

auto (default): Install only if a component needs it
true: Always install, regardless of component state
false: Never install (you already have it)

When you enable a component like KServe, its required dependencies (cert-manager, Red Hat Connectivity Link/Kuadrant) are automatically installed. You never need to manually figure out what depends on what. The chart also resolves transitive dependencies: for example, Red Hat Connectivity Link depends on cert-manager, so enabling Red Hat Connectivity Link automatically pulls cert-manager in as well.

The available dependency operators are:

certManager: Cert Manager operator
leaderWorkerSet: Leader Worker Set operator
- Dependency: certManager
jobSet: Job Set operator
rhcl: Red Hat Connectivity Link (Kuadrant) operator
- Dependency: certManager, leaderWorkerSet
kueue: Kueue operator
- Dependency: certManager
customMetricsAutoscaler: Custom Metrics Autoscaler (KEDA)
clusterObservability: Cluster Observability operator
- Dependency: opentelemetry
opentelemetry: OpenTelemetry operator
tempo: Tempo operator
- Dependency: opentelemetry
nfd: Node Feature Discovery
nvidiaGPUOperator: NVIDIA GPU Operator
- Dependency: nfd

Step 1: Authenticate to the Red Hat registry

The chart is hosted on the Red Hat container registry, which requires authentication. Log in using your Red Hat credentials or a registry service account token (recommended for CI/CD):

helm registry login registry.redhat.io

You're prompted for your username and password. For CI/CD pipelines, use a registry service account token instead of personal credentials.

Each version of Red Hat OpenShift AI has a dedicated tag (for example, v3.4, v3.5). Always select the tag that corresponds to your target version.

Step 2: Deploy the full platform

To install the full RHOAI platform with all components enabled, use the provided example values file:

export CHART_VERSION=v3.4  # match your target version
helm upgrade --install rhoai \
 oci://registry.redhat.io/rhai/rhai-on-openshift-chart \
 --version ${CHART_VERSION} \
 -n rhoai-gitops --create-namespace \
 --set components.aipipelines.dsc.managementState=Managed \
 --set components.dashboard.dsc.managementState=Managed \
 --set components.feastoperator.dsc.managementState=Managed \
 --set components.kserve.dsc.managementState=Managed \
 --set components.kserve.dsc.nim.managementState=Managed \
 --set components.kserve.dsc.modelsAsService.managementState=Managed \
 --set components.kserve.dsc.wva.managementState=Managed \
 --set components.kserve.modelsAsService.gatewayClass.create=true \
 --set components.kserve.modelsAsService.gateway.create=true \
 --set components.kueue.dsc.managementState=Unmanaged \
 --set components.mlflowoperator.dsc.managementState=Managed \
 --set components.modelregistry.dsc.managementState=Managed \
 --set components.ogx.dsc.managementState=Managed \
 --set components.ray.dsc.managementState=Managed \
 --set components.sparkoperator.dsc.managementState=Managed \
 --set components.trainer.dsc.managementState=Managed \
 --set components.trainingoperator.dsc.managementState=Managed \
 --set components.trustyai.dsc.managementState=Managed \
 --set components.workbenches.dsc.managementState=Managed \
 --set services.monitoring.dsci.managementState=Managed

This enables every component: AI Pipelines, Dashboard, KServe (with NIM and Model-as-a-Service), Kueue, Model Registry, Ray, Trainer, Training Operator, TrustyAI, Workbenches, MLflow, Spark Operator, LlamaStack Operator, and Feast.

The same pattern (--set components.<name>.dsc.managementState=Managed) applies to any future components that may be added to the chart. Check the chart's values.yaml or run helm show values oci://registry.redhat.io/rhai/rhai-on-openshift-chart --version ${CHART_VERSION} to see all available components and their configuration options. For complex configurations, consider using a local values file (-f my-values.yaml) instead of multiple --set flags (see Using custom values files below).

It is important to note that due to CRD dependencies, the first run of your Helm command installs the operators with OLM (Namespaces, OperatorGroups, Subscriptions). The Custom Resources (DataScienceCluster, Kuadrant, and so on) are skipped because their CRDs do not exist yet. After the operators are ready and have registered their CRDs, subsequent runs create those CRs. You can automate this with a loop:

for i in {1..5}; dohelm upgrade --install rhoai \
 oci://registry.redhat.io/rhai/rhai-on-openshift-chart \
 --version ${CHART_VERSION} \
 -n rhoai-gitops --create-namespace \
 --set components.aipipelines.dsc.managementState=Managed \
 --set components.dashboard.dsc.managementState=Managed \
 --set components.feastoperator.dsc.managementState=Managed \
 --set components.kserve.dsc.managementState=Managed \
 --set components.kserve.dsc.nim.managementState=Managed \
 --set components.kserve.dsc.modelsAsService.managementState=Managed \
 --set components.kserve.dsc.wva.managementState=Managed \
 --set components.kserve.modelsAsService.gatewayClass.create=true \
 --set components.kserve.modelsAsService.gateway.create=true \
 --set components.kueue.dsc.managementState=Unmanaged \
 --set components.mlflowoperator.dsc.managementState=Managed \
 --set components.modelregistry.dsc.managementState=Managed \
 --set components.ogx.dsc.managementState=Managed \
 --set components.ray.dsc.managementState=Managed \
 --set components.sparkoperator.dsc.managementState=Managed \
 --set components.trainer.dsc.managementState=Managed \
 --set components.trainingoperator.dsc.managementState=Managed \
 --set components.trustyai.dsc.managementState=Managed \
 --set components.workbenches.dsc.managementState=Managed \
 --set services.monitoring.dsci.managementState=Managed  sleep 60done

Or you can wait for specific CRDs before re-running:

kubectl wait --for=condition=Established \  crd/datascienceclusters.datasciencecluster.opendatahub.io --timeout=300skubectl wait --for=condition=Established \  crd/dscinitializations.dscinitialization.opendatahub.io --timeout=300s

Then run helm upgrade again to create the CRs.

Alternative Step 2: Deploy the inference-only stack

In case you need to install only a specific subset of the Red Hat OpenShift AI platform, it is possible using the profiles. The only profile existent today is the Red Hat AI Inference profile.

Red Hat AI Inference provides consistent, cost-effective inference at scale by optimizing workloads across hybrid cloud environments. The rhaii profile support the installation of just the inference stack (KServe with distributed inference with llm-d):

helm upgrade --install rhaii \
 oci://registry.redhat.io/rhai/rhai-on-openshift-chart \
 --version ${CHART_VERSION} \
 --set profile=rhaii \
 -n rhaii-gitops --create-namespace

The rhaii profile automatically enables KServe and installs only the dependencies it requires: cert-manager, Leader Worker Set, and RHCL (Kuadrant/Authorino). Components like pipelines, dashboards, and workbenches remain disabled.

Step 3: Enable Authorino TLS

If you plan to use Red Hat Connectivity Link for authentication and rate limiting, enable Authorino TLS. After the Kuadrant operator has created the Authorino resource, you must enable TLS for KServe to function correctly:

curl -sO https://raw.githubusercontent.com/red-hat-data-services/odh-gitops/refs/heads/rhoai-3.4/scripts/prepare-authorino-tls.sh
chmod +x prepare-authorino-tls.sh
KUSTOMIZE_MODE=false ./prepare-authorino-tls.sh

This script waits for the Authorino service, annotates it to trigger TLS certificate generation, waits for the TLS secret, and patches the Authorino CR to enable TLS.

Step 4: Customize your deployment

Profiles preconfigure which components and dependencies to install with a single flag:

default

Components: None (all Removed)
Dependencies: None

rhaii

Components: KServe
Dependencies: cert-manager, RHCL

Profiles are composable with explicit overrides – you can start from a profile and adjust individual settings:

# Start with the rhaii profile, but also enable workbenches
helm upgrade --install rhoai \
  oci://registry.redhat.io/rhai/rhai-on-openshift-chart \
  --version ${CHART_VERSION} \
  -n rhoai-gitops --create-namespace \
  --set profile=rhaii \
  --set components.workbenches.dsc.managementState=Managed

Using custom values files

For more complex configurations, create a values file:

# my-values.yaml
operator:  type: rhoaicomponents:  kserve:    dsc:      managementState: Managed      nim:        managementState: Managed  workbenches:    dsc:      managementState: Managed  modelregistry:    dsc:      managementState: Managedservices:  monitoring:    dsci:      managementState: Managed

Then install with:

helm upgrade --install rhoai \
  oci://registry.redhat.io/rhai/rhai-on-openshift-chart \
  --version ${CHART_VERSION} \
  -n rhoai-gitops --create-namespace \
  -f my-values.yaml

Skipping dependencies you already have

If cert-manager is already installed on your cluster, tell the chart to skip it:

dependencies:  certManager:    enabled: false  # skip, already installed

Pinning operator versions

To lock an operator to a specific version (useful for consistent deployments across environments):

dependencies:  rhcl:    olm:      channel: stable      version: v1.2.1  # install exactly this version

When you specify a version, the chart automatically sets installPlanApproval: Manual to prevent automatic upgrades. This is useful for testing with a known-good version or ensuring consistent deployments across environments. If you want to set a minimum version while still allowing automatic upgrades, you can explicitly override the approval mode:

dependencies:  rhcl:    olm:      version: v1.2.1  # minimum version      installPlanApproval: Automatic  # still allow auto-upgrades

Step 5 (optional): Integrate with Argo CD

The chart works with Argo CD but requires two specific settings because Argo CD renders Helm templates without cluster access:

skipCrdCheck: true: The chart uses Helm's lookup function to check whether CRDs exist before rendering CRs. Argo CD does not have cluster access during template rendering, so lookup always returns empty. Setting skipCrdCheck to true renders all CRs unconditionally.
SkipDryRunOnMissingResource=true: Argo CD performs dry-run validation before applying. CRs whose CRDs do not exist yet will fail this validation. This sync option skips the dry-run for missing resource types.

Here is a complete Argo CD Application manifest:

apiVersion: argoproj.io/v1alpha1kind: Applicationmetadata:  name: rhoai-platformspec:  project: default  source:
    repoURL: registry.redhat.io/rhai
    chart: rhai-on-openshift-chart
    targetRevision: v3.5    helm:      values: |        global:          skipCrdCheck: true        operator:          type: rhoai        components:          kserve:            dsc:              managementState: Managed  destination:    server: https://kubernetes.default.svc    namespace: rhoai-gitops  syncPolicy:    automated:      prune: true      selfHeal: true    syncOptions:      - SkipDryRunOnMissingResource=true      - CreateNamespace=true

Note: To pull from registry.redhat.io, configure Argo CD with registry credentials. Create a repository secret:

 argocd repo add registry.redhat.io \
   --type helm \
   --enable-oci \
   --username <your-username> \
   --password <your-password>

Or use a Kubernetes secret with argocd.argoproj.io/secret-type: repository label in the argocd namespace.

Argo CD automatically retries failed resources, so after operators install their CRDs, subsequent syncs apply the CRs successfully.

To enable Authorino TLS in an Argo CD-managed deployment:

# Annotate the service to trigger TLS certificate generation
kubectl annotate svc/authorino-authorino-authorization \  service.beta.openshift.io/serving-cert-secret-name=authorino-server-cert \  -n kuadrant-system

Once the secret is created, add dependencies.rhcl.config.tlsEnabled: true to your Argo CD application values.

Step 6: Verify the installation

Check the operator status:

# Verify operators are installedkubectl get csv -A | grep -E "(cert-manager|leader-worker|rhcl|opendatahub|rhods)"# Check DataScienceCluster statuskubectl get datasciencecluster -o jsonpath='{.items[0].status.phase}'

Comprehensive verification

Check that DSC and DSCI resources are ready:

kubectl get dsci,dsc -o jsonpath='{range .items[]}{.kind}/{.metadata.name}{": "}{range .status.conditions[?(@.type=="Ready")]}{.status}{end}{"\n"}{end}'

That should print:

DSCInitialization/default-dsci: True
DataScienceCluster/default-dsc: True

Check Authorino TLS

kubectl get authorino authorino -n kuadrant-system \  -o jsonpath='{.spec.listener.tls}'

Authorino TLS issues

If KServe is not functioning correctly after installation, check that the Authorino service annotation exists:

kubectl get svc authorino-authorino-authorization -n kuadrant-system \  -o jsonpath='{.metadata.annotations}'

Check that the TLS secret was created:

kubectl get secret authorino-server-cert -n kuadrant-system

Re-run the TLS preparation script if needed:

KUSTOMIZE_MODE=false ./scripts/prepare-authorino-tls.sh

Tips and best practices

Let the chart manage your dependencies. The tri-state dependency system is designed to eliminate the manual work of tracking which operators depend on which. Set dependencies to auto (the default) and the chart installs them only when a component needs them. If you have pre-installed an operator outside of Helm (for example, cert-manager was already deployed by your platform team), set its dependency to false so the chart does not attempt to reinstall it. Avoid setting dependencies to true unless you explicitly want an operator installed even when no component requires it.

Pin operator versions in production

In a production environment, unexpected operator upgrades can introduce breaking changes or untested behavior. Use the olm.version field to lock operators to specific, tested versions. This ensures that all environments (development, staging, production) run the same operator versions and that upgrades happen only when you are ready to validate them.

Wrap up

In this article you learned how to deploy Red Hat OpenShift AI and its dependencies on OpenShift using the Helm chart from the odh-gitops repository:

Installing the full platform with all components enabled
Deploying the inference-only stack for model serving as defined by the Red Hat AI Inference profile
Customizing deployments with profiles, values files, and tri-state dependency management
Integrating with Argo CD for a GitOps workflow
Verifying your installation and troubleshooting common issues

The rhai-on-openshift-chart eliminates the manual, error-prone process of deploying a dozen operators and their configurations. Whether you need a minimal KServe deployment for inference or a full AI platform with pipelines, workbenches, and model registry, the same chart handles it with a single Helm command.

Do you want to install the Red Hat AI Inference on vanilla kubernetes? We'll publish a new blog post about it soon.

Get started with Red Hat OpenShift AI

Ready to deploy your AI platform? Try Red Hat OpenShift AI and see how it simplifies building, deploying, and managing AI/ML models at scale.

To learn more, check out these resources:

odh-gitops repository: Source code and documentation for all charts
Red Hat OpenShift AI documentation: Official product documentation
Open Data Hub community: The upstream community project
Inference Only Stack Guide: Detailed guide for the minimal KServe deployment
Helm documentation: Official Helm documentation for chart management
Argo CD documentation: GitOps continuous delivery for Kubernetes

Automating Red Hat OpenShift AI installations with Helm and GitOps

Automate Red Hat OpenShift AI installations with Helm and GitOps: Streamline deployment of AI workloads on OpenShift

Prerequisites

Understanding the chart architecture

What the chart installs

Available components

How dependency resolution works

Step 1: Authenticate to the Red Hat registry

Step 2: Deploy the full platform

Alternative Step 2: Deploy the inference-only stack

Step 3: Enable Authorino TLS

Step 4: Customize your deployment

default

rhaii

Using custom values files

Skipping dependencies you already have

Pinning operator versions

Step 5 (optional): Integrate with Argo CD

Step 6: Verify the installation

Comprehensive verification

Check Authorino TLS

Authorino TLS issues

Tips and best practices

Pin operator versions in production

Wrap up

Get started with Red Hat OpenShift AI

Automating Red Hat OpenShift AI installations with Helm and GitOps

Red Hat OpenShift autoscaling with Cluster Autoscaler

Run LoRA fine-tuning on Red Hat OpenShift AI with Ray

Improved failure reports on Red Hat OpenShift with the event-driven diagnostic operator

Red Hat Ansible development workspaces for governed automation content creation

Platforms

Build

Quicklinks

Communicate

RED HAT DEVELOPER

Red Hat legal and privacy links

Red Hat legal and privacy links