Install Alauda AI
Alauda AI now offers flexible deployment options. Starting with Alauda AI 1.4, the Knative capability is an optional feature, allowing for a more streamlined installation if it's not needed.
To begin, you will need to deploy the Alauda AI Operator. This is the core engine for all Alauda AI products. By default, it uses the KServe Standard mode for the inference backend, which is particularly recommended for resource-intensive generative workloads. This mode provides a straightforward way to deploy models and offers robust, customizable deployment capabilities by leveraging foundational Kubernetes functionalities.
If your use case requires Knative functionality, which enables advanced features like scaling to zero on demand for cost optimization, you can optionally install the Knative Operator. This operator is not part of the default installation and can be added at any time to enable Knative functionality.
Recommended deployment option: For generative inference workloads, the Standard approach (previously known as RawKubernetes Deployment) is recommended as it provides the most control over resource allocation and scaling.
TOC
DownloadingUploadingInstalling Alauda AI OperatorEnabling Knative Functionality1. Installing the Knative Operator2. Creating Knative Serving InstanceCreating Alauda AI InstanceMigrating to Knative Operator1. Remove Legacy Serving Instance2. Install Knative Operator and Create Serving InstanceReplace GitLab Service After InstallationFAQ1. Configure the audit output directory for aml-skipperDownloading
Operator Components:
-
Alauda AI Operator
Alauda AI Operator is the main engine that powers Alauda AI products. It focuses on two core functions: model management and inference services, and provides a flexible framework that can be easily expanded.
Download package: aml-operator.xxx.tgz
-
Knative Operator
Knative Operator provides serverless model inference.
Download package: knative-operator.ALL.v1.x.x-yymmdd.tgz
You can download the app named 'Alauda AI' and 'Knative Operator' from the Marketplace on the Customer Portal website.
Uploading
We need to upload both Alauda AI and Knative Operator to the cluster where Alauda AI is to be used.
Downloading the violet tool
First, we need to download the violet tool if not present on the machine.
Log into the Web Console and switch to the Administrator view:
- Click Marketplace / Upload Packages.
- Click Download Packaging and Listing Tool.
- Locate the right OS / CPU architecture under Execution Environment.
- Click Download to download the
violettool. - Run
chmod +x ${PATH_TO_THE_VIOLET_TOOL}to make the tool executable.
Uploading package
Save the following script in uploading-ai-cluster-packages.sh first, then read the comments below to update environment variables for configuration in that script.
${PLATFORM_ADDRESS}is your ACP platform address.${PLATFORM_ADMIN_USER}is the username of the ACP platform admin.${PLATFORM_ADMIN_PASSWORD}is the password of the ACP platform admin.${CLUSTER}is the name of the cluster to install the Alauda AI components into.${AI_CLUSTER_OPERATOR_NAME}is the path to the Alauda AI Cluster Operator package tarball.${KNATIVE_OPERATOR_PKG_NAME}is the path to the Knative Operator package tarball.${REGISTRY_ADDRESS}is the address of the external registry.${REGISTRY_USERNAME}is the username of the external registry.${REGISTRY_PASSWORD}is the password of the external registry.
After configuration, execute the script file using bash ./uploading-ai-cluster-packages.sh to upload both Alauda AI and Knative Operator.
Installing Alauda AI Operator
Procedure
In Administrator view:
-
Click Marketplace / OperatorHub.
-
At the top of the console, from the Cluster dropdown list, select the destination cluster where you want to install Alauda AI.
-
Select Alauda AI, then click Install.
Install Alauda AI window will pop up.
-
Then in the Install Alauda AI window.
-
Leave Channel unchanged.
-
Check whether the Version matches the Alauda AI version you want to install.
-
Leave Installation Location unchanged, it should be
aml-operatorby default. -
Select Manual for Upgrade Strategy.
-
Click Install.
Verification
Confirm that the Alauda AI tile shows one of the following states:
Installing: installation is in progress; wait for this to change toInstalled.Installed: installation is complete.
Enabling Knative Functionality
Knative functionality is an optional capability that requires an additional operator and instance to be deployed.
If you plan to use Knative functionality, you MUST install the Knative Operator and create the Knative Serving instance BEFORE creating the Alauda AI instance to ensure the required CRDs are available in the cluster.
1. Installing the Knative Operator
Starting from Knative Operator, the Knative networking layer switches to Kourier, so installing Istio is no longer required.
Procedure
In Administrator view:
-
Click Marketplace / OperatorHub.
-
At the top of the console, from the Cluster dropdown list, select the destination cluster where you want to install.
-
Search for and select Knative Operator, then click Install.
Install Knative Operator window will pop up.
-
Then in the Install Knative Operator window.
-
Leave Channel unchanged.
-
Check whether the Version matches the Knative Operator version you want to install.
-
Leave Installation Location unchanged.
-
Select Manual for Upgrade Strategy.
-
Click Install.
Verification
Confirm that the Knative Operator tile shows one of the following states:
Installing: installation is in progress; wait for this to change toInstalled.Installed: installation is complete.
2. Creating Knative Serving Instance
Once Knative Operator is installed, you need to create the KnativeServing instance manually.
Procedure
-
Create the
knative-servingnamespace. -
In the Administrator view, navigate to Operators -> Installed Operators.
-
Select the Knative Operator.
-
Under Provided APIs, locate KnativeServing and click Create Instance.
-
Switch to YAML view.
-
Replace the content with the following YAML:
-
Click Create.
-
For ACP 4.0, keep the version as "1.18.1". For ACP 4.1 and above, change the version to "1.19.6".
-
private-registryis a placeholder for your private registry address. You can find this in the Administrator view, then click Clusters, selectyour cluster, and check the Private Registry value in the Basic Info section.
Creating Alauda AI Instance
Once Alauda AI Operator (and optionally, Knative Operator) is installed, you can create an Alauda AI instance.
Procedure
In Administrator view:
-
Click Marketplace / OperatorHub.
-
At the top of the console, from the Cluster dropdown list, select the destination cluster where you want to install the Alauda AI Operator.
-
Select Alauda AI, then Click.
-
In the Alauda AI page, click All Instances from the tab.
-
Click Create.
Select Instance Type window will pop up.
-
Locate the AmlCluster tile in Select Instance Type window, then click Create.
Create AmlCluster form will show up.
-
Keep
defaultunchanged for Name. -
Select Deploy Flavor from dropdown:
single-nodefor non HA deployments.ha-clusterfor HA cluster deployments (Recommended for production).
-
Set KServe Mode to Managed.
-
Input a valid domain for Domain field.
INFOThis domain is used by ingress gateway for exposing model serving services. Most likely, you will want to use a wildcard name, like *.example.com.
You can specify the following certificate types by updating the Domain Certificate Type field:
ProvidedSelfSignedACPDefaultIngress
By default, the configuration uses
SelfSignedcertificate type for securing ingress traffic to your cluster, the certificate is stored in theknative-serving-certsecret that is specified in the Domain Certificate Secret field. -
(Optional) If you want to enable Knative functionality, in the Serverless Configuration section, set Knative Serving Provider to Operator.
INFOIf you installed the Knative Operator to enable Serverless functionality in the previous steps, provide the following parameters to integrate it:
- APIVersion:
operator.knative.dev/v1beta1 - Kind:
KnativeServing - Name:
knative-serving - Namespace:
knative-serving
If you are not using Knative functionality, leave the Knative Serving Provider as
Removed(or empty) and the remaining parameters blank. - APIVersion:
-
Under Gitlab section:
- Type the URL of self-hosted Gitlab for Base URL.
- Type
cpaas-systemfor Admin Token Secret Namespace. - Type
aml-gitlab-admin-tokenfor Admin Token Secret Name.
-
Review above configurations and then click Create.
Verification
Check the status field from the AmlCluster resource which named default:
Should returns Ready:
Now, the core capabilities of Alauda AI have been successfully deployed. If you want to quickly experience the product, please refer to the Quick Start.
Migrating to Knative Operator
In the 1.x series of products, the serverless capability for inference services was provided by the Alauda AI Model Serving operator. In the 2.x series, this capability is provided by the Knative Operator. This section guides you through migrating your serverless capability from the legacy operator to the new one.
1. Remove Legacy Serving Instance
Procedure
In Administrator view:
- Click Marketplace / OperatorHub.
- At the top of the console, from the Cluster dropdown list, select the destination cluster where Alauda AI is installed.
- Select Alauda AI, then click the All Instances tab.
- Locate the
defaultinstance and click Update. - In the update form, locate the Serverless Configuration section.
- Set BuiltIn Knative Serving to
Removed. - Click Update to apply the changes.
2. Install Knative Operator and Create Serving Instance
Install the Knative Operator from the Marketplace and create the KnativeServing instance. For detailed instructions, refer to the Enabling Knative Functionality section.
Once the above steps are completed, the migration of the Knative serving control plane is complete.
- If you are migrating from the Alauda AI 2.0 + Alauda AI Model Serving combination, the migration is fully complete here. Business services will automatically switch their configuration shortly.
- If you are migrating from the Alauda AI 1.x + Alauda AI Model Serving combination, please ensure that Alauda AI is simultaneously upgraded to version 2.x.
Replace GitLab Service After Installation
If you want to replace GitLab Service after installation, follow these steps:
-
Reconfigure GitLab Service Refer to the Pre-installation Configuration and re-execute its steps.
-
Update Alauda AI Instance
- In Administrator view, navigate to Marketplace > OperatorHub
- From the Cluster dropdown, select the target cluster
- Choose Alauda AI and click the All Instances tab
- Locate the 'default' instance and click Update
-
Modify GitLab Configuration In the Update default form:
- Locate the GitLab section
- Enter:
- Base URL: The URL of your new GitLab instance
- Admin Token Secret Namespace:
cpaas-system - Admin Token Secret Name:
aml-gitlab-admin-token
-
Restart Components Restart the
aml-controllerdeployment in thekubeflownamespace. -
Refresh Platform Data In Alauda AI management view, re-manage all namespaces.
- In Alauda AI view, navigate to Admin view from Business View
- On the Namespace Management page, delete all existing managed namespaces
- Use "Managed Namespace" to add namespaces requiring Alauda AI integration
INFOOriginal models won't migrate automatically Continue using these models:
- Recreate and re-upload in new GitLab OR
- Manually transfer model files to new repository
FAQ
1. Configure the audit output directory for aml-skipper
The default audit output path is /cpaas/audit on the host. However, on some operating systems (e.g., MicroOS), the root path of the host is read-only, and the /cpaas directory cannot be created. In this case, users need to modify the audit output path.
To modify the audit output path, update the AmlCluster default resource and add the amlSkipper.auditLogHostPath.path configuration under spec.values. For example:
The specific path should be consistent with the collection configuration of Alauda Container Platform Log Collector.