View a markdown version of this page

Mettre à niveau le module complémentaire de gouvernance des tâches - Amazon SageMaker AI
Mise à niveau de la version 1.3.x vers la version 1.5

Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Mettre à niveau le module complémentaire de gouvernance des tâches

Utilisez cette section pour mettre à niveau le module complémentaire Amazon EKS de gouvernance des HyperPod tâches entre les versions. Chaque sous-section fournit des procédures spécifiques à la version pour mettre à niveau votre module complémentaire tout en préservant votre configuration existante.

Mise à niveau de la version 1.3.x vers la version 1.5

La méthode recommandée pour passer de la version 1.3.x à la version 1.5 est l'option de mise à niveau dans la HyperPod console SageMaker AI, qui migre automatiquement les CRD Kueue. Utilisez la procédure manuelle de cette section uniquement si vous ne pouvez pas utiliser la console.

Un passage direct aws eks update-addon de la v1.3.x à la v1.5 échoue car la v1.3.x stocke certaines définitions de ressources personnalisées (CRD) de Kueue sous la version API, que la v1alpha1 v1.5 supprime :

CustomResourceDefinition.apiextensions.k8s.io "cohorts.kueue.x-k8s.io" is invalid:
status.storedVersions[0]: Invalid value: "v1alpha1": missing from spec.versions

Cette procédure sauvegarde vos objets Kueue et efface l'ancienne version stockée. Il met ensuite à niveau le module complémentaire et restaure vos objets selon le nouveau schéma.

Impact des données et calendrier

Cette procédure supprime et recrée vos objets de ressources personnalisés Kueue (ClusterQueues,, LocalQueues ResourceFlavors, Topologies et objets associés). Il les sauvegarde d'abord et les restaure, de sorte qu'aucune configuration n'est perdue. Il ne supprime aucun espace de noms, ne supprime aucun CRD et ne modifie aucune SageMaker IA ComputeQuota ni ClusterSchedulerConfig aucun enregistrement.

Exécutez-le lorsqu'aucune nouvelle charge de travail n'a besoin d'être soumise. Les pods en cours d'exécution ne sont généralement pas interrompus, mais nous vous recommandons de ne pas vous fier aux charges de travail actives pendant la migration. Les nouvelles charges de travail ne peuvent pas être planifiées tant que la procédure n'est pas terminée. Exécutez sur un cluster à la fois.

Conditions préalables

Avant de commencer, assurez-vous de disposer des éléments suivants :

  • kubectlconfiguré pour le cluster Amazon EKS cible avec un accès administrateur de cluster

  • La AWS CLI configuration pour le compte et la région du cluster

  • L’jq doit être installée.

  • Le module complémentaire est actuellement à la version 1.3.x avec le statut ou ACTIVE DEGRADED

Tout au long, region remplacez-le par votre région et cluster-name par le nom de votre cluster Amazon EKS.

Pour mettre à niveau le module complémentaire de la version 1.3.x à la version 1.5, procédez comme suit :

  1. Vérifiez la version actuelle du module complémentaire et définissez un répertoire de travail. 

    aws eks describe-addon --region region --cluster-name cluster-name \
  --addon-name amazon-sagemaker-hyperpod-taskgovernance \
  --query 'addon.addonVersion' --output text

    Vérifiez que la sortie commence parv1.3.. Définissez BACKUP_DIR ensuite un chemin absolu dans un répertoire accessible en écriture et créez-le. Les étapes suivantes permettent de lire et d'écrire dans cette variable. Exécutez donc chaque étape dans la même session shell.

    export BACKUP_DIR=/absolute/path/to/backup-dir
mkdir -p "$BACKUP_DIR"

  2. Sauvegardez chaque ressource personnalisée Kueue dans des fichiers locaux. 

    for crd in admissionchecks clusterqueues cohorts localqueues multikueueclusters \
           multikueueconfigs provisioningrequestconfigs resourceflavors topologies \
           workloadpriorityclasses workloads; do
  kubectl get "${crd}.kueue.x-k8s.io" --all-namespaces -o json \
    > "$BACKUP_DIR/${crd}.json" 2>/dev/null
  echo "${crd}: $(jq '.items | length' "$BACKUP_DIR/${crd}.json" 2>/dev/null || echo 0)"
done
    Vérifiez la sauvegarde avant de continuer

    Vérifiez que le répertoire de sauvegarde contient un fichier JSON pour chaque ressource personnalisée de la commande précédente et que le nombre d'objets dans la sortie de la commande correspond à celui de votre cluster. Ne poursuivez pas si un fichier est vide ou manquant.

  3. Supprimez les objets sauvegardés et effacez l'ancienne version stockée de chaque CRD.

    Cela supprime l'entrée v1alpha1 (ouv1beta1) status.storedVersions pour que les CRD v1.5 puissent être installés. Les objets sont en sécurité dans votre sauvegarde et sont restaurés ultérieurement.

    for crd in admissionchecks clusterqueues cohorts localqueues multikueueclusters \
           multikueueconfigs provisioningrequestconfigs resourceflavors topologies \
           workloadpriorityclasses workloads; do
  kubectl get crd "${crd}.kueue.x-k8s.io" >/dev/null 2>&1 || continue
  kubectl delete "${crd}.kueue.x-k8s.io" --all --all-namespaces \
    --ignore-not-found=true --wait=false --request-timeout=30s
  kubectl patch crd "${crd}.kueue.x-k8s.io" --subresource=status --type=merge \
    --request-timeout=30s -p '{"status":{"storedVersions":["v1beta2"]}}'
done
    À propos de --all-namespaces et de --wait=false

    --all-namespacesici sélectionne les ressources personnalisées dans tous les espaces de noms à supprimer ; il ne supprime aucun espace de noms. --wait=falseévite le blocage sur les finaliseurs. La mise à jour du module complémentaire à l'étape suivante les résout.

  4. Mettez à jour le module complémentaire vers la version 1.5. 

    aws eks update-addon --region region --cluster-name cluster-name \
  --addon-name amazon-sagemaker-hyperpod-taskgovernance \
  --addon-version v1.5.0-eksbuild.1 --resolve-conflicts OVERWRITE

    Attendez que le statut soit ACTIVE :

    aws eks describe-addon --region region --cluster-name cluster-name \
  --addon-name amazon-sagemaker-hyperpod-taskgovernance \
  --query 'addon.status' --output text

  5. Attendez que la nouvelle installation soit terminée avant de procéder à la restauration.

    Ne restaurez pas immédiatement après les rapports du module complémentaireACTIVE. Attendez que le contrôleur, son webhook et les tâches de post-installation soient prêts, sinon la restauration à l'étape suivante risque de se bloquer.

    kubectl rollout status deploy/kueue-controller-manager -n kueue-system --timeout=300s
    until [ -n "$(kubectl get endpoints -n kueue-system kueue-webhook-service \
              -o jsonpath='{.subsets[*].addresses[*].ip}' 2>/dev/null)" ]; do
  echo "waiting for kueue webhook endpoint..."; sleep 5
done
    kubectl wait --for=condition=complete job -l app.kubernetes.io/name=kueue \
  -n kueue-system --timeout=180s || true

  6. Restaurez vos objets selon le nouveau schéma.

    Cela transforme chaque objet sauvegardé en schéma v1.5 (v1beta2) et le réapplique.

    transform() {
  jq '
    .apiVersion = "kueue.x-k8s.io/v1beta2"
    | del(.status)
    | del(.metadata.resourceVersion, .metadata.uid, .metadata.creationTimestamp,
          .metadata.generation, .metadata.managedFields, .metadata.selfLink)
    | del(.metadata.annotations."kubectl.kubernetes.io/last-applied-configuration")
    | if .kind == "Cohort" and (.spec.parent != null)
        then .spec.parentName = (.spec.parentName // .spec.parent) | del(.spec.parent) else . end
    | if .kind == "ClusterQueue" and (.spec.cohort != null)
        then .spec.cohortName = (.spec.cohortName // .spec.cohort) | del(.spec.cohort) else . end
    | if .kind == "ClusterQueue" then del(.spec.admissionChecks) else . end
    | if .kind == "AdmissionCheck" then del(.spec.retryDelayMinutes) else . end
  '
}

for crd in resourceflavors topologies workloadpriorityclasses admissionchecks cohorts \
           provisioningrequestconfigs multikueueclusters multikueueconfigs \
           clusterqueues localqueues workloads; do
  f="$BACKUP_DIR/${crd}.json"
  [ -s "$f" ] || continue
  count=$(jq '.items | length' "$f")
  for (( i=0; i<count; i++ )); do
    obj=$(jq -c ".items[$i]" "$f" | transform)
    name=$(printf '%s' "$obj" | jq -r '.kind + "/" + .metadata.name')
    if printf '%s' "$obj" | kubectl apply --request-timeout=30s -f - >/dev/null 2>&1; then
      echo "applied $name"
    else
      echo "check $name (may already be recreated by the add-on)"
    fi
  done
done

  7. Vérifiez le résultat. 

    aws eks describe-addon --region region --cluster-name cluster-name \
  --addon-name amazon-sagemaker-hyperpod-taskgovernance \
  --query 'addon.{version:addonVersion,status:status}'

    L'exemple qui suit illustre un résultat.

    {
    "version": "v1.5.0-eksbuild.1",
    "status": "ACTIVE"
}

    Vérifiez que vos objets sont présents et qu'aucun CRD n'est toujours v1alpha1 répertorié :

    kubectl get clusterqueues
kubectl get localqueues --all-namespaces
kubectl get crd clusterqueues.kueue.x-k8s.io -o jsonpath='{.status.storedVersions}'

    La storedVersions sortie ne doit contenir que v1beta2 (ou v1beta1 etv1beta2), jamaisv1alpha1. Comparez les objets restaurés avec les fichiers pour vous $BACKUP_DIR assurer que les valeurs de configuration restent inchangées.