

Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

# Aktualisieren Sie das Task-Governance-Add-on
<a name="sagemaker-hyperpod-eks-operate-console-ui-governance-upgrade"></a>

Verwenden Sie diesen Abschnitt, um das Amazon EKS-Add-on zur HyperPod Aufgabenverwaltung zwischen den Versionen zu aktualisieren. Jeder Unterabschnitt enthält versionsspezifische Verfahren für das Upgrade Ihres Add-ons unter Beibehaltung Ihrer vorhandenen Konfiguration.

**Topics**
+ [Führen Sie ein Upgrade von v1.5 auf v1.6 durch](#hp-eks-task-governance-upgrade-v15-to-v16)
+ [Führen Sie ein Upgrade von Version 1.3.x auf Version 1.5 oder höher durch](#hp-eks-task-governance-upgrade-v13-to-v15)

## Führen Sie ein Upgrade von v1.5 auf v1.6 durch
<a name="hp-eks-task-governance-upgrade-v15-to-v16"></a>

Version v1.6.0-eksbuild.1 Pakete Kueue v0.19.2. Sie können direkt von v1.5 aktualisieren mit. `aws eks update-addon` Bei diesem Upgrade werden keine Speicherversionen mit benutzerdefinierten Ressourcendefinitionen (CRD) migriert, sodass Sie keine Kueue-Objekte sichern oder neu erstellen müssen.

Um das Add-on über die Amazon EKS-Add-On-Schnittstelle auf Version 1.6 zu aktualisieren, führen Sie den folgenden Befehl aus. {{region}}Ersetzen Sie durch Ihre Region und {{cluster-name}} durch Ihren Amazon EKS-Clusternamen.

```
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
```

Warten Sie, bis der Status lautet`ACTIVE`:

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

**Topology-aware Planung der Validierung der Segmentgröße**  
Ab Version 1.6 (Kueue v0.19.2) validiert Task Governance die topologieabhängige Scheduling-Slice-Größe (die Anzahl der Pods, die zur Platzierung gruppiert wurden), wenn Sie einen Job einreichen. Wenn Sie einen Job einreichen, bei dem die `kueue.x-k8s.io/podset-slice-size` Anmerkung auf einen Wert unter 0 gesetzt wird, lehnt Task Governance den Job mit einer `1` Fehlermeldung wie der folgenden ab:  

```
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
```
In früheren Versionen wurde dieser Wert nicht validiert. Aktualisieren Sie vor dem Upgrade alle Jobvorlagen, die topologieorientierte Planungsbereiche verwenden, auf einen Wert `kueue.x-k8s.io/podset-slice-size` oder höher. `1`

## Führen Sie ein Upgrade von Version 1.3.x auf Version 1.5 oder höher durch
<a name="hp-eks-task-governance-upgrade-v13-to-v15"></a>

Die empfohlene Methode für ein Upgrade von v1.3.x ist die Upgrade-Option in der SageMaker HyperPod AI-Konsole, die die Kueue-CRDs automatisch migriert. Verwenden Sie das manuelle Verfahren in diesem Abschnitt nur, wenn Sie die Konsole nicht verwenden können. Dieses Verfahren unterstützt Version 1.5 und höher als Zielversion.

Eine direkte Übertragung `aws eks update-addon` von v1.3.x auf v1.5 oder höher schlägt fehl, weil v1.3.x einige benutzerdefinierte Kueue-Ressourcendefinitionen (CRDs) unter der API-Version speichert, die in Version 1.5 entfernt wird: `v1alpha1`

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

Dieses Verfahren sichert Ihre Kueue-Objekte und löscht die alte gespeicherte Version. Anschließend wird das Add-on aktualisiert und Ihre Objekte unter dem neuen Schema wiederhergestellt.

**Auswirkung und Zeitpunkt der Daten**  
Dieses Verfahren löscht Ihre benutzerdefinierten Kueue-Ressourcenobjekte (ClusterQueues,, LocalQueues ResourceFlavors, Topologien und verwandte Objekte) und erstellt sie neu. Sie werden zuerst gesichert und wiederhergestellt, sodass keine Konfiguration verloren geht. Es löscht keinen Namespace, löscht keine CRD und ändert keine SageMaker KI ComputeQuota oder ClusterSchedulerConfig keinen Datensatz.  
Führen Sie dies aus, wenn keine neuen Workloads eingereicht werden müssen. Laufende Pods werden in der Regel nicht unterbrochen, wir empfehlen jedoch, sich während der Migration nicht auf aktive Workloads zu verlassen. Neue Workloads können erst geplant werden, wenn das Verfahren abgeschlossen ist. Führen Sie die Ausführung jeweils für einen Cluster aus.

### Voraussetzungen
<a name="hp-eks-task-governance-upgrade-v13-to-v15-prerequisites"></a>

Stellen Sie vor dem Beginn sicher, dass Sie über das Folgende verfügen:
+ `kubectl`konfiguriert für den Amazon EKS-Zielcluster mit Cluster-Administratorzugriff
+ Die für das Konto und die Region des Clusters AWS CLI konfigurierte
+ `jq` installiert
+ Das Add-on befindet sich derzeit auf Version 1.3.x mit Status oder `ACTIVE` `DEGRADED`

Ersetzen Sie es durchgehend {{region}} durch Ihre Region und {{cluster-name}} durch Ihren Amazon EKS-Clusternamen.

Gehen Sie wie folgt vor, um das Add-on von Version 1.3.x auf Version 1.5 zu aktualisieren:

1. **Bestätigen Sie die aktuelle Add-on-Version und legen Sie ein Arbeitsverzeichnis fest. **

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

   Bestätigen Sie, dass die Ausgabe mit beginnt`v1.3.`. Stellen Sie dann `BACKUP_DIR` einen absoluten Pfad in einem beschreibbaren Verzeichnis ein und erstellen Sie ihn. Spätere Schritte lesen aus dieser Variablen und schreiben in sie. Führen Sie daher jeden Schritt in derselben Shell-Sitzung aus.

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

1. **Sichern Sie jede benutzerdefinierte Kueue-Ressource in lokalen Dateien. **

   ```
   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
   ```
**Überprüfen Sie das Backup, bevor Sie fortfahren**  
Vergewissern Sie sich, dass das Backup-Verzeichnis eine JSON-Datei für jede benutzerdefinierte Ressource im vorherigen Befehl enthält und dass die Anzahl der Objekte in der Befehlsausgabe mit der Anzahl der Objekte in Ihrem Cluster übereinstimmt. Fahren Sie nicht fort, wenn eine Datei fehlt oder leer ist.

1. **Löschen Sie die gesicherten Objekte und löschen Sie die alte gespeicherte Version von jeder CRD. **

   Dadurch wird der Eintrag `v1alpha1` (oder`v1beta1`) entfernt, `status.storedVersions` sodass die CRDs der Version 1.5 oder höher installiert werden können. Die Objekte sind in Ihrem Backup sicher und werden in einem späteren Schritt wiederhergestellt.

   ```
   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
   ```
**Über --all-namespaces und --wait=false**  
`--all-namespaces`wählt hier benutzerdefinierte Ressourcen in allen Namespaces zum Löschen aus; es wird kein Namespace gelöscht. `--wait=false`vermeidet das Blockieren von Finalizern. Das Add-On-Update im nächsten Schritt behebt sie.

1. **Aktualisieren Sie das Add-on auf Ihre Zielversion (v1.5.0-eksbuild.1 oder höher). **

   {{target-version}}Ersetzen Sie durch die Ziel-Add-On-Version, zum Beispiel `v1.5.0-eksbuild.1` oder`v1.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
   ```

   Warten Sie, bis der Status lautet`ACTIVE`:

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

1. **Warten Sie, bis die neue Installation abgeschlossen ist, bevor Sie sie wiederherstellen. **

   Stellen Sie das Gerät nicht sofort wieder her, nachdem das Add-on gemeldet wurde`ACTIVE`. Warten Sie, bis der Controller, sein Webhook und die Jobs nach der Installation fertig sind. Andernfalls kann die Wiederherstellung im nächsten Schritt hängen bleiben.

   ```
   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. **Stellen Sie Ihre Objekte unter dem neuen Schema wieder her. **

   Dadurch wird jedes gesicherte Objekt in das Schema v1.5 oder höher (`v1beta2`) umgewandelt und erneut angewendet.

   ```
   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
   ```

1. **Überprüfen Sie das Ergebnis. **

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

   Eine Beispielausgabe sieht wie folgt aus (Ihre `version` entspricht den {{target-version}} in Schritt 4 eingestellten Werten).

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

   Vergewissern Sie sich, dass Ihre Objekte vorhanden sind und keine CRD-Liste `v1alpha1` immer noch vorhanden ist:

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

   Die `storedVersions` Ausgabe darf nur `v1beta2` (oder `v1beta1` und`v1beta2`) enthalten, niemals`v1alpha1`. Vergleichen Sie die wiederhergestellten Objekte mit den Dateien in, `$BACKUP_DIR` um sicherzustellen, dass Ihre Konfigurationswerte unverändert sind.