View a markdown version of this page

Aggiorna il componente aggiuntivo per la governance delle attività - Amazon SageMaker AI

Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.

Aggiorna il componente aggiuntivo per la governance delle attività

Usa questa sezione per aggiornare il componente aggiuntivo Amazon EKS per la governance delle HyperPod attività tra le versioni. Ogni sottosezione fornisce procedure specifiche per la versione per aggiornare il componente aggiuntivo preservando la configurazione esistente.

Aggiornamento dalla versione 1.5 alla versione 1.6

La versione v1.6.0-eksbuild.1 include i pacchetti Kueue v0.19.2. È possibile eseguire l'aggiornamento direttamente dalla v1.5 con. aws eks update-addon Questo aggiornamento non esegue la migrazione delle versioni di archiviazione CRD (Custom Resource Definition), quindi non è necessario eseguire il backup o ricreare alcun oggetto Kueue.

Per aggiornare il componente aggiuntivo alla versione 1.6 tramite l'interfaccia aggiuntiva Amazon EKS, esegui il comando seguente. Sostituiscilo region con la tua regione e cluster-name con il nome del tuo cluster Amazon EKS.

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

Attendi che lo stato siaACTIVE:

aws eks describe-addon --region region --cluster-name cluster-name \ --addon-name amazon-sagemaker-hyperpod-taskgovernance \ --query 'addon.status' --output text
Topology-aware pianificazione della convalida della dimensione delle slice

A partire dalla versione 1.6 (Kueue v0.19.2), la governance delle attività convalida la dimensione delle slice di pianificazione basate sulla topologia (il numero di pod raggruppati per il posizionamento) quando si invia un lavoro. Se invii un lavoro che imposta l'kueue.x-k8s.io/podset-slice-sizeannotazione su un valore inferiore a, la governance delle attività rifiuta il lavoro con un errore come il seguente: 1

admission webhook "vjob.kb.io" denied the request: spec.template.metadata.annotations[kueue.x-k8s.io/podset-slice-size]: Invalid value: "0": must be greater than or equal to 1

Le versioni precedenti non convalidavano questo valore. Prima di eseguire l'aggiornamento, aggiorna tutti i modelli di lavoro che utilizzano slice di pianificazione basate sulla topologia per impostarli su un valore pari o superiore. kueue.x-k8s.io/podset-slice-size 1

Aggiornamento dalla versione 1.3.x alla versione 1.5 o successiva

Il metodo consigliato per eseguire l'aggiornamento dalla v1.3.x è l'opzione di aggiornamento nella HyperPod console SageMaker AI, che migra automaticamente i CRD Kueue. Usa la procedura manuale in questa sezione solo se non puoi usare la console. Questa procedura supporta la versione 1.5 e successive come versione di destinazione.

Un collegamento diretto aws eks update-addon dalla v1.3.x alla v1.5 o successiva non riesce perché la v1.3.x memorizza alcune definizioni di risorse personalizzate (CRD) di Kueue nella versione API, che la v1.5 rimuove: v1alpha1

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

Questa procedura esegue il backup degli oggetti Kueue e cancella la vecchia versione archiviata. Quindi aggiorna il componente aggiuntivo e ripristina gli oggetti nel nuovo schema.

Impatto e tempistica dei dati

Questa procedura elimina e ricrea gli oggetti di risorse personalizzati Kueue (ClusterQueues,, LocalQueues ResourceFlavors, Topologie e oggetti correlati). Ne esegue prima il backup e poi li ripristina, in modo da non perdere alcuna configurazione. Non elimina alcun namespace, non elimina alcun CRD e non modifica alcun SageMaker AI o record. ComputeQuota ClusterSchedulerConfig

Eseguilo quando non è necessario inviare nuovi carichi di lavoro. I pod in esecuzione generalmente non vengono interrotti, ma consigliamo di non fare affidamento sui carichi di lavoro attivi durante la migrazione. I nuovi carichi di lavoro non possono essere pianificati fino al completamento della procedura. Esegui su un cluster alla volta.

Prerequisiti

Prima di iniziare, assicurati di disporre di:

  • kubectlconfigurato per il cluster Amazon EKS di destinazione con accesso da amministratore del cluster

  • La AWS CLI configurazione per l'account e la regione del cluster

  • jq installato

  • L'add-on è attualmente nella versione 1.3.x con stato o ACTIVE DEGRADED

Sostituiscilo definitivamente region con la tua regione e cluster-name con il nome del tuo cluster Amazon EKS.

Per aggiornare il componente aggiuntivo dalla versione 1.3.x alla versione 1.5, completa i seguenti passaggi:

  1. Conferma la versione corrente del componente aggiuntivo e imposta una directory di lavoro.

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

    Verificare che l'output inizi conv1.3.. Quindi imposta BACKUP_DIR un percorso assoluto in una directory scrivibile e crealo. I passaggi successivi leggono e scrivono su questa variabile, quindi esegui ogni passaggio nella stessa sessione di shell.

    export BACKUP_DIR=/absolute/path/to/backup-dir mkdir -p "$BACKUP_DIR"
  2. Esegui il backup di ogni risorsa personalizzata di Kueue su file locali.

    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
    Verifica il backup prima di continuare

    Verifica che la directory di backup contenga un file JSON per ogni risorsa personalizzata nel comando precedente e che il conteggio degli oggetti nell'output del comando corrisponda a quello del cluster. Non procedere se manca un file o è vuoto.

  3. Elimina gli oggetti di cui è stato eseguito il backup e cancella la vecchia versione archiviata da ogni CRD.

    Questo rimuove la voce v1alpha1 (ov1beta1) da status.storedVersions cui è possibile installare i CRD v1.5 o successivi. Gli oggetti sono al sicuro nel backup e vengono ripristinati in una fase successiva.

    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
    Informazioni su --all-namespaces e --wait=false

    --all-namespacesqui seleziona le risorse personalizzate in tutti i namespace da eliminare; non elimina alcun namespace. --wait=falseevita il blocco dei finalizzatori. L'aggiornamento del componente aggiuntivo nel passaggio successivo li risolve.

  4. Aggiorna il componente aggiuntivo alla versione di destinazione (v1.5.0-eksbuild.1 o successiva).

    Sostituisci target-version con la versione aggiuntiva di destinazione, ad esempio v1.5.0-eksbuild.1 ov1.6.0-eksbuild.1.

    aws eks update-addon --region region --cluster-name cluster-name \ --addon-name amazon-sagemaker-hyperpod-taskgovernance \ --addon-version target-version --resolve-conflicts OVERWRITE

    Attendi che lo stato siaACTIVE:

    aws eks describe-addon --region region --cluster-name cluster-name \ --addon-name amazon-sagemaker-hyperpod-taskgovernance \ --query 'addon.status' --output text
  5. Attendi che la nuova installazione si risolva prima del ripristino.

    Non eseguire il ripristino immediatamente dopo i report ACTIVE del componente aggiuntivo. Attendi che il controller, il relativo webhook e i processi di post-installazione siano pronti, altrimenti il ripristino nella fase successiva potrebbe bloccarsi.

    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. Ripristina i tuoi oggetti con il nuovo schema.

    Questo trasforma ogni oggetto di cui è stato eseguito il backup nello schema v1.5 o successivo (v1beta2) e lo applica nuovamente.

    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. Verifica il risultato.

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

    Un esempio di output è il seguente (il tuo version corrisponde a target-version quello impostato nel passaggio 4).

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

    Verifica che i tuoi oggetti siano presenti e che nessun CRD sia ancora v1alpha1 elencato:

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

    L'storedVersionsoutput deve contenere solo v1beta2 (o v1beta1 ev1beta2), maiv1alpha1. Confronta gli oggetti ripristinati con i file in esso contenuti $BACKUP_DIR per confermare che i valori di configurazione siano invariati.