#Installation

MLflow is delivered as an OLM Operator (the MLflow Operator) and installed from the platform OperatorHub. Installing the tracking server is a two-step flow: install the operator, then create one MLflow custom resource that reconciles the tracking-server stack.

#Prerequisites

• Alauda AI installed on the target cluster. The operator and its images ship both linux/amd64 and linux/arm64.

• Operator Lifecycle Manager (OLM) available on the target cluster (provided by the platform).

• A PostgreSQL database reachable from the cluster, holding a database named mlflow for MLflow metadata. Have the host, port, username, and password ready, and create the database before you install:

  CREATE DATABASE mlflow;

  Use a highly available PostgreSQL service for production (see High availability and storage).

• The platform OAuth / OIDC provider (provided by Alauda AI) — the OAuth proxy in front of the tracking server uses it for single sign-on.

• For multi-tenancy, the default workspace namespace must already exist and carry the label mlflow-enabled=true before the tracking server first starts. Otherwise the server crash-loops with Workspace '<name>' not found in the Kubernetes cluster.

  kubectl create namespace finetune
  kubectl label namespace finetune mlflow-enabled=true

#Upload Operator

Download the MLflow Operator bundle from the Customer Portal / Marketplace (e.g. mlflow.ALL.xxxx.tgz), then publish it to the platform repository with the violet command-line tool:

violet push \
  --platform-address=<platform-access-address> \
  --platform-username=<platform-admin> \
  --platform-password=<platform-admin-password> \
  mlflow.ALL.xxxx.tgz

#Install Operator

In the Administrator view:

1. Click Marketplace / OperatorHub.
2. At the top of the console, from the Cluster dropdown, select the destination cluster.
3. Search for and select MLflow Operator, then click Install.
4. Leave Channel unchanged (stable).
5. Check that the Version matches the release you want to install (e.g. v3.10.2).
6. Leave Installation Location unchanged — it defaults to the mlflow-operator namespace.
7. Choose an Upgrade Strategy (Manual is recommended for production).
8. Click Install.

Confirm the operator is ready before continuing:

# the CSV reports Succeeded
kubectl get csv -n mlflow-operator | grep mlflow-operator

# the operator controller-manager pod is Running
kubectl get pods -n mlflow-operator

#Create the MLflow tracking server

The operator does nothing until you create an MLflow custom resource (mlflow.alauda.io/v1alpha1). You can create it two ways:

• kubectl — apply an MLflow manifest.
• Alauda Console UI — from Administrator → Marketplace → OperatorHub → MLflow Operator → All instances → Create.

Both create the same resource; use whichever fits your workflow.

#Method A — using kubectl

Set the database connection and multi-tenancy fields, then apply:

apiVersion: mlflow.alauda.io/v1alpha1
kind: MLflow
metadata:
  name: mlflow
spec:
  # Namespace the tracking server is deployed into (chart-mandated: kubeflow).
  namespace: kubeflow

  # External PostgreSQL for MLflow metadata — the `mlflow` database must already exist.
  pgHost: postgresql.database.svc
  pgPort: 5432
  pgUsername: mlflow
  pgPassword: <db-password>

  # Multi-tenancy: map Kubernetes namespaces to MLflow workspaces.
  multitenancy:
    enabled: true
    defaultWorkspace: finetune                 # must exist and be labelled before first boot
    workspaceLabelSelector: mlflow-enabled=true

  # Run-artifact location (see High availability and storage below).
  artifacts:
    defaultArtifactRoot: /mlflow/artifacts

Save as mlflow.yaml and apply:

kubectl apply -f mlflow.yaml

#Method B — using the Alauda Console UI

1. In the Administrator view, go to Marketplace → OperatorHub.
2. From the Cluster dropdown at the top, select the target cluster.
3. Open the installed MLflow Operator.
4. Switch to the All instances tab and click Create (choose MLflow if prompted).
5. Fill in the form, or switch to YAML view and paste the manifest from Method A. Set the PostgreSQL connection and, for multi-tenancy, the defaultWorkspace and label selector.
6. Click Create.

#Verification

Verify the tracking server reconciled in the configured namespace (kubeflow):

# the operand exists
kubectl get mlflow

# the tracking-server Deployment is Available (two containers: the server + oauth2-proxy)
kubectl -n kubeflow get deploy mlflow-tracking-server

# its pod is Running
kubectl -n kubeflow get pods -l app.kubernetes.io/name=mlflow-tracking-server

Then open Alauda AI → Tools → MLFlow. The run owner and visible workspaces reflect the identity you sign in as.

#High availability and storage

• Database. MLflow stores all experiment/run/registry metadata in the external PostgreSQL you configured. Use a highly available PostgreSQL service for production; the tracking server itself is stateless with respect to metadata.
• Artifacts. The default artifacts.defaultArtifactRoot: /mlflow/artifacts is local to the tracking-server pod (an emptyDir) and is intended for development and testing only — it is not durable, and clients that upload large artifacts can hit pod disk limits. For production, configure an S3-compatible object store as the artifact root before users store experiment artifacts.
• Replicas. The default deployment is single-replica. It is not a multi-replica high-availability deployment unless your release notes state otherwise.

#Enable bearer-token clients (optional)

By default the OAuth proxy accepts the browser session cookie. To let the MLflow Python SDK authenticate with a Dex id token (MLFLOW_TRACKING_TOKEN), the proxy must be configured to accept JWT bearer tokens (--skip-jwt-bearer-tokens / OAUTH2_PROXY_SKIP_JWT_BEARER_TOKENS=true). See Platform setup for the token method in the SDK guide. The cookie method needs no change.

#Troubleshooting

• If the MLFlow Tools-menu entry is missing, verify that the aml-mlflow-menu-config ConfigMap exists in the tracking-server namespace and has the label aml.cpaas.io/centralMenuItem: "true".
• If the server does not start and the pod logs Workspace '<name>' not found, the defaultWorkspace namespace does not exist or is not labelled mlflow-enabled=true. Create and label it, then restart the pod.
• If the server does not start for another reason, verify PostgreSQL connectivity, that the mlflow database exists, and that the credentials in spec.pg* are correct.
• If a workspace is not visible, verify that its namespace matches the configured workspaceLabelSelector.
• If requests are denied (403 PERMISSION_DENIED), check the user's Kubernetes RoleBinding in the workspace namespace — see Workspaces and access control.