从 AML 1.2 升级

安装 Alauda AI 集群组件

WARNING

由于我们是从 AML 1.2 升级，请忽略 创建 Alauda AI 集群实例。

下载 Alauda AI 集群 和 KServeless 的操作员捆绑包。
上传操作员捆绑包到目标集群。
将 Alauda AI 集群操作员安装到目标集群。

升级

以下过程描述了如何从 AML 1.2 升级到 Alauda AI 1.3。

在升级之前，请确保 aml-operator Pod 在 aml-operator 命名空间中已启动并运行：

kubectl -n aml-operator get pod

迁移配置文件资源

由于 Alauda AI 1.3 已删除了对 kubeflow.org 中 Profile 的使用，并引入了一种新的自定义资源定义 (CRD) 叫 AmlNamespace，我们需要将现有的 Profile 资源迁移到 AmlNamespace。

在目标集群中执行以下脚本：

migrate-profile-resources.sh

#!/bin/bash
BASE_DOMAIN=$(kubectl -n kube-public get cm global-info -o jsonpath='{.data.labelBaseDomain}' | sed 's/"//g')
CLUSTER_NAME=$(kubectl -n kube-public get cm global-info -o jsonpath='{.data.clusterName}' | sed 's/"//g')

profiles=$(kubectl get profiles.kubeflow.org -o jsonpath='{.items[*].metadata.name}')

for profile in $profiles; do
  if kubectl get amlnamespace "$profile" &>/dev/null; then
    echo "⚠️  AmlNamespace $profile 已存在。跳过..."
    continue
  fi

  profile_yaml=$(kubectl get profiles.kubeflow.org "$profile" -o yaml)

  build_registry_file=$(mktemp)
  from_registry_file=$(mktemp)
  s3_file=$(mktemp)

  echo "$profile_yaml" | yq '.spec.plugins[] | select(.kind == "AmlConfig") | .spec.buildRegistry' > "$build_registry_file"
  echo "$profile_yaml" | yq '.spec.plugins[] | select(.kind == "AmlConfig") | .spec.fromRegistry' > "$from_registry_file"
  echo "$profile_yaml" | yq '.spec.plugins[] | select(.kind == "AmlConfig") | .spec.s3' > "$s3_file"

  amlnamespace_yaml=$(cat <<EOF
apiVersion: manage.aml.dev/v1alpha1
kind: AmlNamespace
metadata:
  name: $profile
  labels:
    $BASE_DOMAIN/cluster: $CLUSTER_NAME
spec:
  config: {}
EOF
)

  if [[ -s "$build_registry_file" && $(yq 'type' "$build_registry_file") != "null" ]]; then
    amlnamespace_yaml=$(echo "$amlnamespace_yaml" | yq ".spec.config.buildRegistry = load(\"$build_registry_file\")")
  fi

  if [[ -s "$from_registry_file" && $(yq 'type' "$from_registry_file") != "null" ]]; then
    amlnamespace_yaml=$(echo "$amlnamespace_yaml" | yq ".spec.config.fromRegistry = load(\"$from_registry_file\")")
  fi

  if [[ -s "$s3_file" && $(yq 'type' "$s3_file") != "null" ]]; then
    amlnamespace_yaml=$(echo "$amlnamespace_yaml" | yq ".spec.config.s3 = load(\"$s3_file\")")
  fi

  rm -f "$build_registry_file" "$from_registry_file" "$s3_file"

  echo "$amlnamespace_yaml" | kubectl apply -f -
  echo "✅ AmlNamespace $profile 已创建。"
done

迁移 InferenceService 资源

在 Alauda AI 1.3 中，KServe 引入了一个重大变化，要求 InferenceService 资源中的 model.name 必须为 kserve-container。因此，我们需要为 accommodate 这个变化而修补所有在 AML 1.2 中创建的 InferenceService 资源。

在目标集群中执行以下脚本：

migrate-inferenceservice-resources.sh

#!/bin/bash

set -e

inferenceservices=$(kubectl get inferenceservice --all-namespaces -o jsonpath='{range .items[*]}{.metadata.namespace}{" "}{.metadata.name}{"\n"}{end}')

while IFS=" " read -r namespace svc; do
    model_name=$(kubectl -n "$namespace" get inferenceservice "$svc" -o jsonpath='{.spec.predictor.model.name}')
    if [ "$model_name" != "kserve-container" ]; then
        echo ">> 更新 $namespace/$svc..."
        kubectl -n "$namespace" patch inferenceservice "$svc" --type=json -p='[{
          "op": "replace",
          "path": "/spec/predictor/model/name",
          "value": "kserve-container"
        }]'
    fi
done <<< "$inferenceservices"

迁移 Knative CRD

由于 Knative CRD 的重大变化，您需要在升级之前将 CRD 迁移到新版本。

# 将 domainmappings 的 storageVersion 从 v1alpha1 迁移到 v1beta1
kubectl patch crd domainmappings.serving.knative.dev --type='json' -p='[
  {"op": "replace", "path": "/spec/versions/0/storage", "value": true},
  {"op": "replace", "path": "/spec/versions/1/storage", "value": false}
]'

kubectl exec -n aml-operator -it deploy/aml-operator -- /app/storageversion-migrate \
  domainmappings.serving.knative.dev

等待命令完成，命令输出应类似于：

INFO    storageversion/main.go:61       迁移组资源       {"len": 1}
INFO    storageversion/main.go:64       迁移组资源        {"resource": "domainmappings.serving.knative.dev"}
INFO    storageversion/main.go:74       迁移完成

修复 Knative 配置中的意外密钥

运行以下命令以删除 Knative 配置中的 _example 密钥，这会阻止升级。

CONFIGMAPS=(
  $(kubectl -n knative-serving get configmaps -l app.kubernetes.io/name=knative-serving -o jsonpath='{.items[*].metadata.name}')
)

# 请忽略类似 `请求无效：...` 的错误消息
for cm in "${CONFIGMAPS[@]}"; do
  kubectl -n knative-serving patch configmap "$cm" --type='json' -p='[{"op": "remove", "path": "/data/_example"}]'
done

清理 Knative Serving 资源

一些 Knative Serving 资源阻止升级，因此需要手动操作。

执行以下脚本以删除有问题的资源：

cleanup-resources.sh

kubectl -n knative-serving delete pdb activator-pdb webhook-pdb

kubectl -n knative-serving patch configmap config-istio --type=json -p='[{
  "op": "remove",
  "path": "/data/gateway.knative-serving.knative-local-gateway"
}]'

kubectl -n knative-serving patch gateways.networking.istio.io knative-local-gateway --type=json -p='[{
  "op": "replace",
  "path": "/spec/selector",
  "value": {"knative": "ingressgateway"}
}]'

kubectl -n istio-system patch service knative-local-gateway --type=json -p='[{
  "op": "replace",
  "path": "/spec/selector",
  "value": {"knative": "ingressgateway"}
}]'

检索 AML 1.2 值

INFO

如果未安装，则应在集群节点上安装 helm 和 yq 工具。

在 AML 集群中，您可以使用以下 helm 命令检索 AML 1.2 的值：

helm get values aml -n kubeflow -o yaml | tee /tmp/aml-values.yaml

请在升级过程中保留生成的 /tmp/aml-values.yaml 文件。

创建 GitLab 管理员令牌秘密

我们需要为 GitLab 管理员令牌创建一个秘密，这是运行 Alauda AI 集群 所必需的。

请按照预配置中的说明进行操作。

创建 MySQL 秘密

我们还需要为 Alauda AI 集群 创建一个 MySQL 秘密。

运行以下命令：

MYSQL_PASSWORD=$(kubectl -n kubeflow get secret mysql-secret -o jsonpath='{.data.password}' | base64 -d)  

kubectl create secret generic aml-mysql-secret \
  --from-literal="password=${MYSQL_PASSWORD}" \
  -n cpaas-system

从之前安装的 AML 1.2 秘密资源中检索 MySQL 密码。
创建名为 aml-mysql-secret 的 MySQL 管理员令牌秘密。
密码保存在 password 密钥下。
该秘密在 cpaas-system 命名空间下创建。

创建 Alauda AI 集群实例

最后，我们为 Alauda AI 集群 创建一个名为 default 的 AmlCluster 资源以完成升级。

创建一个名为 aml-cluster.yaml 的 yaml 文件，内容如下：

aml-cluster.yaml

apiVersion: amlclusters.aml.dev/v1alpha1
kind: AmlCluster
metadata:
  name: default
spec:
  values:
    global:
      # 单节点或高可用集群
      deployFlavor: single-node
      gitlabBaseUrl: "${GITLAB_BASE_URL}"
      gitlabAdminTokenSecretRef:
        name: aml-gitlab-admin-token
        namespace: cpaas-system
      mysql:
        host: "${MYSQL_HOST}"
        port: 3306
        user: "${MYSQL_USER}"
        database: aml
        passwordSecretRef:
          name: aml-mysql-secret
          namespace: cpaas-system
    buildkitd:
      storage:
        type: emptyDir
  components:
    kserve:
      managementState: Managed
    knativeServing:
      managementState: Managed
      ingressGateway:
        domain: "*.example.com"
        certificate:
          secretName: knative-serving-cert
          type: SelfSigned

之前创建的 GitLab 管理员令牌秘密的 name 和 namespace。
之前创建的 MySQL 秘密的 name 和 namespace。
将 kserve 的管理状态设为 Managed，这意味着 KServe 将由 Alauda AI 集群 安装和管理。
将 knativeServing 的管理状态设为 Managed，这意味着 Knative Serving 将由 Alauda AI 集群 安装和管理。
用于暴露推理服务的通配符 domain。现在，保持原样。

执行以下命令以从 AML 1.2 检索必要的上下文，然后安装 Alauda AI 集群：

# 从 AML 1.2 值文件中检索 GitLab 主机方案和基本信息。
GITLAB_HOST_SCHEME=$(yq -r .global.gitScheme < /tmp/aml-values.yaml)
GITLAB_HOST_BASE=$(yq -r .global.gitBase < /tmp/aml-values.yaml)
export GITLAB_BASE_URL="${GITLAB_HOST_SCHEME}://${GITLAB_HOST_BASE}"

# 从 AML 1.2 值文件中检索 MySQL 主机、端口和用户。
export MYSQL_HOST=$(yq -r .global.mysqlHost < /tmp/aml-values.yaml)
export MYSQL_PORT=$(yq -r .global.mysqlPort < /tmp/aml-values.yaml)
export MYSQL_USER=$(yq -r .global.mysqlUsername < /tmp/aml-values.yaml)

yq '((.. | select(tag == "!!str")) |= envsubst) | (.spec.values.global.mysql.port = env(MYSQL_PORT))' aml-cluster.yaml \
  | kubectl apply -f -

在之前创建的 aml-cluster.yaml 文件中插入环境变量。
创建 AmlCluster 资源以安装 Alauda AI 集群。

验证

检查名为 default 的 AmlCluster 资源的状态字段：

kubectl get amlcluster default

应返回 Ready：

NAME      READY   REASON
default   True    Succeeded

安装 Alauda AI 基础组件

请访问 Alauda AI 基础组件获取安装说明。

#从 AML 1.2 升级

#目录

#安装 Alauda AI 集群组件

#升级

#迁移配置文件资源

#迁移 InferenceService 资源

#迁移 Knative CRD

#修复 Knative 配置中的意外密钥

#清理 Knative Serving 资源

#检索 AML 1.2 值

#创建 GitLab 管理员令牌秘密

#创建 MySQL 秘密

#创建 Alauda AI 集群实例

#验证

#安装 Alauda AI 基础组件