Teilen über


Problembehandlung für Azure Machine Learning-Erweiterung

In diesem Artikel erfahren Sie, wie Sie häufige Probleme beheben, die beim Bereitstellen der Azure Machine Learning-Erweiterung in AKS oder Kubernetes mit Arc-Unterstützung auftreten können.

Installieren der Azure Machine Learning-Erweiterung

Die Azure Machine Learning-Erweiterung wird als Helm-Chart veröffentlicht und von Helm V3 installiert. Alle Komponenten der Azure Machine Learning-Erweiterung werden im Namespace azureml installiert. Sie können den Status der Erweiterung mithilfe der folgenden Befehle überprüfen.

# get the extension status
az k8s-extension show --name <extension-name>

# check status of all pods of Azure Machine Learning extension
kubectl get pod -n azureml

# get events of the extension
kubectl get events -n azureml --sort-by='.lastTimestamp'

Beheben von Bereitstellungsfehlern der Azure Machine Learning-Erweiterung

Fehler: Ein noch verwendeter Name kann nicht wiederverwendet werden.

Dieser Fehler bedeutet, dass der von Ihnen angegebene Name der Erweiterung bereits vorhanden ist. Wenn der Name von der Azure Machine Learning-Erweiterung verwendet wird, müssen Sie etwa eine Stunde warten und es dann erneut versuchen. Wenn der Name von einem anderen Helm-Chart verwendet wird, müssen Sie einen anderen Namen verwenden. Führen Sie helm list -Aa aus, um alle Helm-Charts in Ihrem Cluster aufzulisten.

Fehler: Früherer Vorgang für Helm-Chart noch in Bearbeitung

Warten Sie etwa eine Stunde, und versuchen Sie es nach Abschluss des unbekannten Vorgangs erneut.

Fehler: Im Namespace „azureml“ kann kein neuer Inhalt erstellt werden, weil er zurzeit beendet wird.

Dieser Fehler tritt auf, wenn ein Deinstallationsvorgang nicht abgeschlossen und ein weiterer Installationsvorgang ausgelöst wird. Sie können mit dem Befehl az k8s-extension show den Bereitstellungsstatus der Erweiterung überprüfen und sicherstellen, dass die Erweiterung deinstalliert wurde, bevor Sie weitere Aufgaben ausführen.

Fehler: Fehler beim Herunterladen des Charts, Pfad nicht gefunden

Dieser Fehler tritt auf, wenn Sie eine falsche Erweiterungsversion angeben. Sie müssen sicherstellen, dass die angegebene Version vorhanden ist. Wenn Sie die neueste Version verwenden möchten, müssen Sie --version nicht angeben.

Fehler: Import in aktuelle Version nicht möglich: ungültige Besitzermetadaten

Dieser Fehler bedeutet, dass ein Konflikt zwischen den vorhandenen Clusterressourcen und der Azure Machine Learning-Erweiterung vorliegt. Eine vollständige Fehlermeldung könnte wie folgt aussehen:

CustomResourceDefinition "jobs.batch.volcano.sh" in namespace "" exists and cannot be imported into the current release: invalid ownership metadata; label validation error: missing key "app.kubernetes.io/managed-by": must be set to "Helm"; annotation validation error: missing key "meta.helm.sh/release-name": must be set to "amlarc-extension"; annotation validation error: missing key "meta.helm.sh/release-namespace": must be set to "azureml"

Führen Sie die folgenden Schritte aus, um das Problem zu beheben:

  • Überprüfen Sie, wer der Besitzer der problematischen Ressourcen ist und ob die Ressource gelöscht oder geändert werden kann.

  • Wenn die Ressource nur von der Azure Machine Learning-Erweiterung verwendet wird und gelöscht werden kann, können Sie das Problem durch manuelles Hinzufügen von Beschriftungen entschärfen. Ausgehend von der vorherigen Fehlermeldung können Sie beispielsweise folgende Befehle ausführen:

    kubectl label crd jobs.batch.volcano.sh "app.kubernetes.io/managed-by=Helm" 
    kubectl annotate crd jobs.batch.volcano.sh "meta.helm.sh/release-namespace=azureml" "meta.helm.sh/release-name=<extension-name>"
    

    Wenn die Bezeichnungen und Anmerkungen auf die Ressource festgelegt werden, wird die im Besitz der Azure Machine Learning-Erweiterung befindliche Ressource von Helm verwaltet.

  • Wenn die Ressource auch von anderen Komponenten in Ihrem Cluster verwendet wird und nicht geändert werden kann. können Sie unter Bereitstellen der Azure Machine Learning-Erweiterung nachsehen, ob es eine Konfigurationseinstellung zum Deaktivieren der Konfliktressource gibt.

Integritätsüberprüfung der Erweiterung

Wenn die Installation fehlgeschlagen ist und keine der oben genannten Fehlermeldungen angezeigt wurde, können Sie die Erweiterung mithilfe der integrierten Integritätsprüfung umfassend überprüfen. Die Azure Machine Learning-Erweiterung umfasst einen HealthCheck-Auftrag, mit dem Sie vorab die Bereitschaft Ihres Clusters prüfen können, wenn Sie die Erweiterung installieren, aktualisieren oder löschen möchten. Der HealthCheck-Auftrag gibt einen Bericht aus, der in einer Configmap mit dem Namen arcml-healthcheck im Namespace azureml gespeichert wird. Die Fehlercodes und mögliche Lösungen für den Bericht werden in Fehlercodes von HealthCheck aufgeführt.

Führen Sie diesen Befehl aus, um den HealthCheck-Bericht abzurufen:

kubectl describe configmap -n azureml arcml-healthcheck

Die Integritätsprüfung wird immer dann ausgelöst, wenn Sie die Erweiterung installieren, aktualisieren oder löschen. Der Bericht zur Integritätsprüfung ist in mehrere Teile gegliedert: pre-install, pre-rollback, pre-upgrade und pre-delete.

  • Wenn es beim Installieren der Erweiterung zu einem Fehler gekommen ist, sollten Sie sich pre-install und pre-delete ansehen.
  • Wenn es beim Aktualisieren der Erweiterung zu einem Fehler gekommen ist, sollten Sie sich pre-upgrade und pre-rollback ansehen.
  • Wenn es beim Löschen der Erweiterung zu einem Fehler gekommen ist, sollten Sie sich pre-delete ansehen.

Wenn Sie Support anfordern, empfehlen wir Ihnen, den folgenden Befehl auszuführen und die Datei healthcheck.logs an uns zu senden, da wir das Problem so besser lokalisieren können.

kubectl logs healthcheck -n azureml

Fehlercodes von HealthCheck

In dieser Tabelle finden Sie Hinweise zur Fehlerbehebung für die im HealthCheck-Bericht zurückgegebenen Fehlercodes.

Fehlercode Fehlermeldung BESCHREIBUNG
E40001 LOAD_BALANCER_NOT_SUPPORT Der Lastenausgleich wird in Ihrem Cluster nicht unterstützt. Sie müssen den Lastenausgleich in Ihrem Cluster konfigurieren oder in Betracht ziehen, inferenceRouterServiceType auf nodePort oder clusterIP festzulegen.
E40002 INSUFFICIENT_NODE Sie haben inferenceRouterHA aktiviert, wofür mindestens drei Knoten in Ihrem Cluster benötigt werden. Deaktivieren Sie die Hochverfügbarkeit, wenn Sie über weniger als drei Knoten verfügen.
E40003 INTERNAL_LOAD_BALANCER_NOT_SUPPORT Derzeit unterstützt nur AKS den internen Lastenausgleich, und es wird nur den Typ azure unterstützt. Legen Sie internalLoadBalancerProvider nur fest, wenn Sie über einen AKS-Cluster verfügen.
E40007 INVALID_SSL_SETTING Der SSL-Schlüssel oder das Zertifikat ist ungültig. Der CNAME muss mit dem Zertifikat kompatibel sein.
E45002 PROMETHEUS_CONFLICT Der installierte Prometheus-Operator steht in Konflikt mit Ihrem vorhandenen Prometheus-Operator. Weitere Informationen finden Sie unter Prometheus-Operator.
E45003 BAD_NETWORK_CONNECTIVITY Sie müssen die Netzwerkanforderungen erfüllen.
E45004 AZUREML_FE_ROLE_CONFLICT Die Azure Machine Learning-Erweiterung wird im Legacy-AKS nicht unterstützt. Um die Azure Machine Learning-Erweiterung zu installieren, müssen Sie die Legacykomponenten für „azureml-fe“ löschen.
E45005 AZUREML_FE_DEPLOYMENT_CONFLICT Die Azure Machine Learning-Erweiterung wird im Legacy-AKS nicht unterstützt. Um die Azure Machine Learning-Erweiterung zu installieren, müssen Sie den Befehl unter diesem Formular ausführen, um die älteren azureml-fe-Komponenten zu löschen. Weitere Details finden Sie unter hier.

Befehle zum Löschen der älteren azureml-fe-Komponenten im AKS-Cluster:

kubectl delete sa azureml-fe
kubectl delete clusterrole azureml-fe-role
kubectl delete clusterrolebinding azureml-fe-binding
kubectl delete svc azureml-fe
kubectl delete svc azureml-fe-int-http
kubectl delete deploy azureml-fe
kubectl delete secret azuremlfessl
kubectl delete cm azuremlfeconfig

Integration von Open-Source-Komponenten

Die Azure Machine Learning-Erweiterung verwendet einige Open-Source-Komponenten, darunter Prometheus-Operator, Volcano-Planer und DCGM-Exporter. Wenn im Kubernetes-Cluster bereits einige dieser Komponenten installiert sind, finden Sie in den folgenden Abschnitten Informationen zum Integrieren Ihrer vorhandenen Komponenten in die Azure Machine Learning-Erweiterung.

Prometheus-Operator

Der Prometheus-Operator ist ein Open-Source-Framework zum Aufbau eines Metriküberwachungssystems in Kubernetes. Die Azure Machine Learning-Erweiterung nutzt den Prometheus-Operator außerdem, um die Ressourcenverwendung von Aufträgen zu überwachen.

Wenn der Prometheus-Operator von einem anderen Dienst im Cluster installiert wurde, können Sie installPromOp=false angeben, um den Operator in der Azure Machine Learning-Erweiterung zu deaktivieren. So vermeiden Sie einen Konflikt zwischen zwei Prometheus-Operatoren. In diesem Fall werden alle Prometheus-Instanzen vom vorhandenen Prometheus-Operator verwaltet. Damit Prometheus ordnungsgemäß funktioniert, müssen Sie die folgenden Punkte beachten, wenn Sie den Prometheus-Operator in der Azure Machine Learning-Erweiterung deaktivieren.

  1. Überprüfen Sie, ob Prometheus im Namespace „azureml“ vom Prometheus-Operator verwaltet wird. In einigen Szenarien ist der Prometheus-Operator so konfiguriert, dass er nur bestimmte Namespaces überwacht. Falls ja, vergewissern Sie sich, dass der Namespace „azureml“ in der Positivliste enthalten ist. Weitere Informationen finden Sie unter Befehlsflags.
  2. Überprüfen Sie, ob „kubelet-service“ im Prometheus-Operator aktiviert ist. „kubelet-service“ enthält alle Endpunkte von Kubelet. Weitere Informationen finden Sie unter Befehlsflags. Außerdem müssen Sie sicherstellen, dass „kubelet-service“ über eine Bezeichnung k8s-app=kubelet verfügt.
  3. Erstellen Sie „ServiceMonitor“ für „kubelet-service“. Führen Sie den folgenden Befehl mit ersetzten Variablen aus:
    cat << EOF | kubectl apply -f -
    apiVersion: monitoring.coreos.com/v1
    kind: ServiceMonitor
    metadata:
      name: prom-kubelet
      namespace: azureml
      labels:
        release: "<extension-name>"     # Please replace to your Azure Machine Learning extension name
    spec:
      endpoints:
      - port: https-metrics
        scheme: https
        path: /metrics/cadvisor
        honorLabels: true
        tlsConfig:
          caFile: /var/run/secrets/kubernetes.io/serviceaccount/ca.crt
          insecureSkipVerify: true
        bearerTokenFile: /var/run/secrets/kubernetes.io/serviceaccount/token
        relabelings:
        - sourceLabels:
          - __metrics_path__
          targetLabel: metrics_path
      jobLabel: k8s-app
      namespaceSelector:
        matchNames:
        - "<namespace-of-your-kubelet-service>"  # Please change this to the same namespace of your kubelet-service
      selector:
        matchLabels:
          k8s-app: kubelet    # Please make sure your kubelet-service has a label named k8s-app and it's value is kubelet
    
    EOF
    

dcgm-exporter

dcgm-exporter ist das offizielle, von NVIDIA empfohlene Tool zur Erfassung von GPU-Metriken. Wir haben ihn in die Azure Machine Learning-Erweiterung integriert. Standardmäßig ist „dcgm-exporter“ jedoch nicht aktiviert, und es werden keine GPU-Metriken gesammelt. Sie können das Flag installDcgmExporter auf true festlegen, um das Tool zu aktivieren. Da es sich um das offizielle Tool von NVIDIA handelt, ist es möglicherweise bereits in Ihrem GPU-Cluster installiert. In diesem Fall können Sie installDcgmExporter auf false festlegen und die folgenden Schritte ausführen, um die vorhandene dcgm-exporter-Installation in die Azure Machine Learning-Erweiterung zu integrieren. Eine weitere Besonderheit ist, dass der Benutzer mithilfe von „dcgm-exporter“konfigurieren kann, welche Metriken veröffentlicht werden sollen. Stellen Sie für die Azure Machine Learning-Erweiterung sicher, dass die Metriken DCGM_FI_DEV_GPU_UTIL, DCGM_FI_DEV_FB_FREE und DCGM_FI_DEV_FB_USED verfügbar gemacht werden.

  1. Stellen Sie sicher, dass Sie die AzureML-Erweiterung und „dcgm-exporter“ erfolgreich installiert haben. „dcgm-exporter“ kann über das Helm-Chart „dcgm-exporter“ oder das Helm-Chart „gpu-operator“ installiert werden.

  2. Überprüfen Sie, ob es einen Dienst für „dcgm-exporter“ gibt. Wenn kein Dienst vorhanden ist oder Sie nicht wissen, wie Sie dies überprüfen, führen Sie den folgenden Befehl aus, um einen Dienst zu erstellen:

    cat << EOF | kubectl apply -f -
    apiVersion: v1
    kind: Service
    metadata:
      name: dcgm-exporter-service
      namespace: "<namespace-of-your-dcgm-exporter>" # Please change this to the same namespace of your dcgm-exporter
      labels:
        app.kubernetes.io/name: dcgm-exporter
        app.kubernetes.io/instance: "<extension-name>" # Please replace to your Azure Machine Learning extension name
        app.kubernetes.io/component: "dcgm-exporter"
      annotations:
        prometheus.io/scrape: 'true'
    spec:
      type: "ClusterIP"
      ports:
      - name: "metrics"
        port: 9400  # Please replace to the correct port of your dcgm-exporter. It's 9400 by default
        targetPort: 9400  # Please replace to the correct port of your dcgm-exporter. It's 9400 by default
        protocol: TCP
      selector:
        app.kubernetes.io/name: dcgm-exporter  # Those two labels are used to select dcgm-exporter pods. You can change them according to the actual label on the service
        app.kubernetes.io/instance: "<dcgm-exporter-helm-chart-name>" # Please replace to the helm chart name of dcgm-exporter
    EOF
    
  3. Überprüfen Sie, ob der Dienst aus dem vorherigen Schritt ordnungsgemäß eingerichtet ist.

    kubectl -n <namespace-of-your-dcgm-exporter> port-forward service/dcgm-exporter-service 9400:9400
    # run this command in a separate terminal. You will get a lot of dcgm metrics with this command.
    curl http://127.0.0.1:9400/metrics
    
  4. Richten Sie „ServiceMonitor“ ein, um den Dienst „dcgm-exporter“ für die Azure Machine Learning-Erweiterung verfügbar zu machen. Wenn Sie den folgenden Befehl ausführen, wird er innerhalb weniger Minuten wirksam.

    cat << EOF | kubectl apply -f -
    apiVersion: monitoring.coreos.com/v1
    kind: ServiceMonitor
    metadata:
      name: dcgm-exporter-monitor
      namespace: azureml
      labels:
        app.kubernetes.io/name: dcgm-exporter
        release: "<extension-name>"   # Please replace to your Azure Machine Learning extension name
        app.kubernetes.io/component: "dcgm-exporter"
    spec:
      selector:
        matchLabels:
          app.kubernetes.io/name: dcgm-exporter
          app.kubernetes.io/instance: "<extension-name>"   # Please replace to your Azure Machine Learning extension name
          app.kubernetes.io/component: "dcgm-exporter"
      namespaceSelector:
        matchNames:
        - "<namespace-of-your-dcgm-exporter>"  # Please change this to the same namespace of your dcgm-exporter
      endpoints:
      - port: "metrics"
        path: "/metrics"
    EOF
    

volcano-scheduler

Wenn in Ihrem Cluster bereits die Volcano-Suite installiert ist, können Sie installVolcano=false festlegen, damit der Volcano-Planer nicht durch die Erweiterung installiert wird. Der Volcano-Planer und -Controller sind für die Übermittlung und Planung von Trainingsaufträgen erforderlich.

Die von der Azure Machine Learning-Erweiterung verwendete Konfiguration für den Volcano-Planer lautet:

volcano-scheduler.conf: |
    actions: "enqueue, allocate, backfill"
    tiers:
    - plugins:
        - name: task-topology
        - name: priority
        - name: gang
        - name: conformance
    - plugins:
        - name: overcommit
        - name: drf
        - name: predicates
        - name: proportion
        - name: nodeorder
        - name: binpack

Sie müssen dieselben Konfigurationseinstellungen verwenden und den Webhook job/validate in den Volcano-Zugangseinstellungen deaktivieren, wenn Sie eine niedrigere Volcano-Version als 1.6 verwenden, damit Azure Machine Learning-Trainingsworkloads ordnungsgemäß ausgeführt werden können.

Integration des Volcano-Planers mit Unterstützung der automatischen Clusterskalierung

Wie in diesem Thread erläutert, funktioniert das gang-Plug-In nicht gut mit der automatischen Clusterskalierung (Cluster Autoscaler, CA) und der automatischen Knotenskalierung in AKS.

Wenn Sie die Volcano-Version verwenden, die über die Einstellung installVolcano=true mit der Azure Machine Learning-Erweiterung bereitgestellt wird, verfügt die Erweiterung standardmäßig über eine Planerkonfiguration, die das gang-Plug-In konfiguriert, um Auftragsdeadlocks zu verhindern. Daher wird die automatische Clusterskalierung im AKS-Cluster nicht unterstützt, wenn Volcano über die Erweiterung installiert wurde.

Wenn die automatische Skalierung von AKS-Clustern normal funktionieren soll, können Sie für diesen Fall den Parameter volcanoScheduler.schedulerConfigMap konfigurieren, indem Sie die Erweiterung aktualisieren, und eine benutzerdefinierte Konfiguration vom Typ no gang für den Volcano-Planer dafür angeben, z. B.:

volcano-scheduler.conf: |
    actions: "enqueue, allocate, backfill"
    tiers:
    - plugins:
      - name: sla 
        arguments:
        sla-waiting-time: 1m
    - plugins:
      - name: conformance
    - plugins:
        - name: overcommit
        - name: drf
        - name: predicates
        - name: proportion
        - name: nodeorder
        - name: binpack

Um diese Konfiguration in Ihrem AKS-Cluster zu verwenden, müssen Sie die folgenden Schritte ausführen:

  1. Erstellen Sie eine configMap-Datei mit der obigen Konfiguration im azureml-Namespace. Dieser Namespace wird in der Regel erstellt, wenn Sie die Azure Machine Learning-Erweiterung installieren.
  2. Legen Sie volcanoScheduler.schedulerConfigMap=<configmap name> in der Erweiterungskonfiguration fest, um diese configMap-Datei anzuwenden. Außerdem müssen Sie die Ressourcenüberprüfung überspringen, wenn Sie die Erweiterung installieren, indem Sie amloperator.skipResourceValidation=true konfigurieren. Beispiel:
    az k8s-extension update --name <extension-name> --extension-type Microsoft.AzureML.Kubernetes --config volcanoScheduler.schedulerConfigMap=<configmap name> amloperator.skipResourceValidation=true --cluster-type managedClusters --cluster-name <your-AKS-cluster-name> --resource-group <your-RG-name> --scope cluster
    

Hinweis

Da das gang-Plug-In entfernt wurde, besteht die Möglichkeit, dass der Deadlock auftritt, wenn Volcano den Auftrag plant.

  • Um diese Situation zu vermeiden, können Sie denselben Instanztyp für alle Aufträge verwenden.

Beachten Sie, dass Sie den Webhook job/validate in den Volcano-Zugangseinstellungen deaktivieren müssen, wenn Sie eine niedrigere Volcano-Version als 1.6 verwenden.

Nginx-Eingangsdatencontroller

Die Installation der Azure Machine Learning-Erweiterung enthält standardmäßig eine Nginx-Eingangsdatencontrollerklasse k8s.io/ingress-nginx. Wenn Sie bereits über einen Nginx-Eingangsdatencontroller in Ihrem Cluster verfügen, müssen Sie eine andere Controllerklasse verwenden, um Installationsfehler zu vermeiden.

Sie haben zwei Möglichkeiten:

  • Ändern Sie Ihre vorhandene Controllerklasse in etwas anderes als k8s.io/ingress-nginx.
  • Erstellen oder aktualisieren Sie unsere Azure Machine Learning-Erweiterung mit einer benutzerdefinierten Controllerklasse, die sich von Ihrer unterscheidet, indem Sie die folgenden Beispiele befolgen.

So erstellen Sie beispielsweise die Erweiterung mit einer benutzerdefinierten Controllerklasse:

az ml extension create --config nginxIngress.controller="k8s.io/amlarc-ingress-nginx"

So aktualisieren Sie die Erweiterung mit einer benutzerdefinierten Controllerklasse:

az ml extension update --config nginxIngress.controller="k8s.io/amlarc-ingress-nginx"

Der mit der Azure Machine Learning-Erweiterung installierte NGINX-Eingangsdatencontroller stürzt aufgrund von Fehlern mit nicht genügend Arbeitsspeicher (Out-Of-Memory, OOM) ab

Symptom

Der mit der Azure Machine Learning-Erweiterung installierte NGINX-Eingangsdatencontroller stürzt aufgrund von Fehlern mit nicht genügend Arbeitsspeicher (Out-Of-Memory, OOM) ab, selbst wenn keine Workload vorhanden ist. Die Controllerprotokolle zeigen keine nützlichen Informationen zur Diagnose des Problems.

Mögliche Ursache

Dieses Problem kann auftreten, wenn der NGINX-Eingangsdatencontroller auf einem Knoten mit vielen CPUs ausgeführt wird. Standardmäßig erzeugt der NGINX-Eingangsdatencontroller Workerprozesse entsprechend der Anzahl von CPUs, was mehr Ressourcen verbrauchen und OOM-Fehler auf Knoten mit mehr CPUs verursachen kann. Dies ist ein bekanntes Problem, das auf GitHub gemeldet ist

Lösung

Um dieses Problem zu beheben, können Sie:

  • Passen Sie die Anzahl der Workerprozesse an, indem Sie die Erweiterung mit dem Parameter nginxIngress.controllerConfig.worker-processes=8 installieren.
  • Erhöhen Sie das Arbeitsspeicherlimit, indem Sie den Parameter nginxIngress.resources.controller.limits.memory=<new limit> verwenden.

Stellen Sie sicher, dass Sie diese beiden Parameter entsprechend Ihren spezifischen Knotenspezifikationen und Workloadanforderungen anpassen, um Ihre Workloads effektiv zu optimieren.

Nächste Schritte