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. **Topics** + [Mise à niveau de la version 1.3.x vers la version 1.5](#hp-eks-task-governance-upgrade-v13-to-v15) ## 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 : + `kubectl`configuré 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 par`v1.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" ``` 1. **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. 1. **Supprimez les objets sauvegardés et effacez l'ancienne version stockée de chaque CRD. ** Cela supprime l'entrée `v1alpha1` (ou`v1beta1`) `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-namespaces`ici 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. 1. **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 ``` 1. **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émentaire`ACTIVE`. 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 ``` 1. **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/dev/null 2>&1; then echo "applied $name" else echo "check $name (may already be recreated by the add-on)" fi done done ``` 1. **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` et`v1beta2`), jamais`v1alpha1`. Comparez les objets restaurés avec les fichiers pour vous `$BACKUP_DIR` assurer que les valeurs de configuration restent inchangées.