Freigeben über

Referenz zum Konfigurieren von Kubernetes-Clustern für Azure Machine Learning

  • Artikel

Dieser Artikel enthält Referenzinformationen für das Konfigurieren von Kubernetes mit Azure Machine Learning.

Unterstützte Kubernetes-Version und Region

  • Kubernetes-Cluster, in denen die Azure Machine Learning-Erweiterung installiert ist, weisen ein Versionssupportfenster von „N-2“ auf, das an der Supportrichtlinie für Azure Kubernetes Service (AKS) ausgerichtet ist, wobei „N“ die neueste allgemein verfügbare Nebenversion von Azure Kubernetes Service ist.

    • Bei Einführung von AKS-Version „1.20.a“ werden die Versionen „1.20.a“, „1.20.b“, „1.19.c“, „1.19.d“, „1.18.e“ und „1.18.f“ weiterhin unterstützt.

    • Wenn Kunden eine nicht unterstützte Kubernetes-Version verwenden, werden sie aufgefordert, ein Upgrade vorzunehmen, sobald sie Support für den Cluster anfordern. Die Supportrichtlinien für Azure Machine Learning-Erweiterungen gelten nicht für Cluster, in denen nicht unterstützte Kubernetes-Releases ausgeführt werden.

  • Regionsverfügbarkeit für die Azure Machine Learning-Erweiterung:

    • Die Azure Machine Learning-Erweiterung kann in AKS oder in Kubernetes mit Azure Arc-Unterstützung in bereitgestellt werden. Die hierfür unterstützten Regionen sind in der Liste unter Verfügbare Produkte nach Region aufgeführt.

Wenn Sie die Azure Machine Learning-Erweiterung bereitstellen, werden einige zugehörige Dienste in Ihrem Kubernetes-Cluster für Azure Machine Learning bereitgestellt. In der folgenden Tabelle finden Sie eine Auflistung der zugehörigen Dienste und ihrer Ressourcennutzung im Cluster:

Bereitstellung/DaemonSet Replikatanzahl Training Rückschluss CPU-Anforderung (m) CPU-Limit (m) Speicheranforderung (Mi) Arbeitsspeicherlimit (Mi)
metrics-controller-manager 1 ✓ ✓ 10 100 20 300
prometheus-operator 1 ✓ ✓ 100 400 128 512
prometheus 1 ✓ ✓ 100 1000 512 4096
kube-state-metrics 1 ✓ ✓ 10 100 32 256
gateway 1 ✓ ✓ 50 500 256 2048
fluent-bit 1 pro Knoten ✓ ✓ 10 200 100 300
inference-operator-controller-manager 1 ✓ – 100 1000 128 1024
amlarc-identity-controller 1 ✓ – 200 1000 200 1024
amlarc-identity-proxy 1 ✓ – 200 1000 200 1024
azureml-ingress-nginx-controller 1 ✓ – 100 1000 64 512
azureml-fe-v2 1 (für Testzwecke)
oder
3 (für Produktionszwecke)		 ✓ – 900 2000 800 1200
online-deployment 1 pro Bereitstellung Vom Benutzer erstellt – <user-define> <user-define> <user-define> <user-define>
online-deployment/identity-sidecar 1 pro Bereitstellung ✓ – 10 50 100 100
aml-operator 1 – ✓ 20 1020 124 2168
volcano-admission 1 – ✓ 10 100 64 256
volcano-controller 1 – ✓ 50 500 128 512
volcano-schedular 1 – ✓ 50 500 128 512

Ohne Berücksichtigung Ihrer eigenen Bereitstellungen/Pods gelten die folgenden Mindestanforderungen an die Systemressourcen:

Szenario Rückschluss aktiviert Training aktiviert CPU-Anforderung (m) CPU-Limit (m) Speicheranforderung (Mi) Arbeitsspeicherlimit (Mi) Knotenanzahl Empfohlene VM-Mindestgröße Entsprechende AKS-VM-SKU
Tests ✓ – 1780 8300 2440 12296 1 Knoten 2 vCPUs, 7 GiB Arbeitsspeicher, 6400 IOPS, 1500 MBit/s BW DS2v2
Tests – ✓ 410 4420 1492 10960 1 Knoten 2 vCPUs, 7 GiB Arbeitsspeicher, 6400 IOPS, 1500 MBit/s BW DS2v2
Tests ✓ ✓ 1910 10420 2884 15744 1 Knoten 4 vCPUs, 14 GiB Arbeitsspeicher, 12800 IOPS, 1500 MBit/s BW DS3v2
Produktion ✓ – 3600 12700 4240 15296 3 Knoten 4 vCPUs, 14 GiB Arbeitsspeicher, 12800 IOPS, 1500 MBit/s BW DS3v2
Produktion – ✓ 410 4420 1492 10960 1 Knoten 8 vCPUs, 28 GiB Arbeitsspeicher, 25600 IOPs, 6000 MBit/s BW DS4v2
Produktion ✓ ✓ 3730 14820 4684 18744 3 Knoten 4 vCPUs, 14 GiB Arbeitsspeicher, 12800 IOPS, 1500 MBit/s BW DS4v2

Hinweis

  • Für Testzwecke sollten Sie die Ressourcenanforderung berücksichtigen.
  • Für Produktionszwecke sollten Sie das Ressourcenlimit berücksichtigen.

Wichtig

Nachfolgend finden Sie einige weitere Aspekte, die berücksichtigt werden sollten:

  • Für eine höhere Netzwerkbandbreite und eine verbesserte Datenträger-E/A-Leistung empfehlen wir eine größere SKU.
    • Ein Beispiel dafür ist DV2/DSv2. Die Verwendung einer großen SKU kann die Zeit für den Abruf eines Images verkürzen und die Netzwerk-/Speicherleistung verbessern.
    • Weitere Informationen zur AKS-Reservierung finden Sie unter AKS-Reservierung.
  • Wenn Sie einen AKS-Cluster verwenden, müssen Sie möglicherweise die Größenbeschränkung für ein Containerimage in AKS beachten. Weitere Informationen finden Sie unter Größenbeschränkung für AKS-Containerimages.

Voraussetzungen für ARO- oder OCP-Cluster

Deaktivieren von Security Enhanced Linux (SELinux)

Das Azure Machine Learning-Dataset (ein in Azure Machine Learning-Trainingsaufträgen verwendetes SDK v1-Feature) wird auf Computern, auf denen SELinux aktiviert ist, nicht unterstützt. Daher muss selinux für alle Worker deaktiviert werden, um das Azure Machine Learning-Dataset verwenden zu können.

Privilegierte Einrichtung für ARO und OCP

Gewähren Sie bei einer Bereitstellung der Azure Machine Learning-Erweiterung in ARO- oder OCP-Clustern privilegierten Zugriff auf Azure Machine Learning-Dienstkonten, führen Sie den Befehl oc edit scc privileged aus, und fügen Sie folgende Dienstkonten unter „users:“ hinzu:

  • system:serviceaccount:azure-arc:azure-arc-kube-aad-proxy-sa
  • system:serviceaccount:azureml:{EXTENSION-NAME}-kube-state-metrics
  • system:serviceaccount:azureml:prom-admission
  • system:serviceaccount:azureml:default
  • system:serviceaccount:azureml:prom-operator
  • system:serviceaccount:azureml:load-amlarc-selinux-policy-sa
  • system:serviceaccount:azureml:azureml-fe-v2
  • system:serviceaccount:azureml:prom-prometheus
  • system:serviceaccount:{KUBERNETES-COMPUTE-NAMESPACE}:default
  • system:serviceaccount:azureml:azureml-ingress-nginx
  • system:serviceaccount:azureml:azureml-ingress-nginx-admission

Hinweis

  • {EXTENSION-NAME} ist der mit dem Azure CLI-Befehl az k8s-extension create --name angegebene Erweiterungsname.
  • {KUBERNETES-COMPUTE-NAMESPACE} ist der Namespace der Kubernetes-Computeressource, die beim Anfügen der Computeressource an den Azure Machine Learning-Arbeitsbereich angegeben wird. Überspringen Sie die Konfiguration von system:serviceaccount:{KUBERNETES-COMPUTE-NAMESPACE}:default, wenn KUBERNETES-COMPUTE-NAMESPACE = default ist.

Gesammelte Protokolldetails

Einige Protokolle zu Azure Machine Learning-Workloads im Cluster (etwa zu Status, Metriken, Lebenszyklus usw.) werden über Erweiterungskomponenten gesammelt. Die folgende Liste enthält alle gesammelten Protokolldetails, einschließlich des Typs der gesammelten Protokolle und des Speicherorts, an den sie gesendet oder an dem sie gespeichert wurden.

Pod Ressourcenbeschreibung Detaillierte Protokollierungsinformationen
amlarc-identity-controller Anfordern und Erneuern eines Blob-/Azure Container Registry-Tokens über eine verwaltete Identität. Wird nur verwendet, wenn bei der Installation der Erweiterung enableInference=true festgelegt wird. Es enthält Ablaufverfolgungsprotokolle für den Status beim Abrufen der Identität für Endpunkte zur Authentifizierung beim Azure Machine Learning-Dienst.
amlarc-identity-proxy Anfordern und Erneuern eines Blob-/Azure Container Registry-Tokens über eine verwaltete Identität. Wird nur verwendet, wenn bei der Installation der Erweiterung enableInference=true festgelegt wird. Es enthält Ablaufverfolgungsprotokolle für den Status beim Abrufen der Identität für den Cluster zur Authentifizierung beim Azure Machine Learning-Dienst.
aml-operator Verwalten des Lebenszyklus von Trainingsaufträgen. Die Protokolle enthalten den Status des Azure Machine Learning-Trainingsauftragspods im Cluster.
azureml-fe-v2 Die Front-End-Komponente, die eingehende Rückschlussanforderungen an bereitgestellte Dienste weiter leitet. Zugriffsprotokolle auf Anforderungsebene, einschließlich Anforderungs-ID, Startzeit, Antwortcode, Fehlerdetails und Dauer der Anforderungslatenz. Ablaufverfolgungsprotokolle für Änderungen an Dienstmetadaten, Integritätsstatus der ausgeführten Dienste usw. zu Debugzwecken.
gateway Das Gateway wird für die Kommunikation und die bidirektionale Übertragung von Daten verwendet. Ablaufverfolgungsprotokolle für Anforderungen von Azure Machine Learning-Diensten an die Cluster.
healthcheck -- Die Protokolle enthalten den Status der azureml-Namespaceressource (Azure Machine Learning-Erweiterung), um zu diagnostizieren, warum die Erweiterung nicht funktioniert.
inference-operator-controller-manager Verwalten des Lebenszyklus von Rückschlussendpunkten. Die Protokolle enthalten den Status der Azure Machine Learning-Rückschlussendpunkte und der Bereitstellungspods im Cluster.
metrics-controller-manager Verwalten der Konfiguration für Prometheus Ablaufverfolgungsprotokolle zum Uploadstatus von Trainingsaufträgen und Rückschlussbereitstellungsmetriken zur CPU-Auslastung und Arbeitsspeicherauslastung.
Relayserver Ein Relayserver ist nur in einem Cluster mit Arc-Verbindung erforderlich und wird nicht im AKS-Cluster installiert. Relayserver verwenden Azure Relay für die Kommunikation mit den Clouddiensten. Die Protokolle enthalten Informationen zur Anforderungsebene von Azure Relay.

Verbindung von Azure Machine Learning-Aufträgen mit benutzerdefiniertem Datenspeicher

Persistent Volume (PV) und Persistent Volume Claim (PVC) sind Kubernetes-Konzepte, die es dem Benutzer ermöglichen, verschiedene Speicherressourcen bereitzustellen und zu nutzen.

  1. Erstellen Sie ein PV mit NFS als Beispiel.
apiVersion: v1
kind: PersistentVolume
metadata:
  name: nfs-pv 
spec:
  capacity:
    storage: 1Gi 
  accessModes:
    - ReadWriteMany 
  persistentVolumeReclaimPolicy: Retain
  storageClassName: ""
  nfs: 
    path: /share/nfs
    server: 20.98.110.84 
    readOnly: false
  1. Erstellen Sie einen PVC im gleichen Kubernetes-Namespace wie ML-Workloads. In metadatamüssen Sie die Beschriftung ml.azure.com/pvc: "true" für die Erkennung durch Azure Machine Learning sowie die Anmerkung ml.azure.com/mountpath: <mount path> zum Festlegen des Einbindungspfads hinzufügen.
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: nfs-pvc  
  namespace: default
  labels:
    ml.azure.com/pvc: "true"
  annotations:
    ml.azure.com/mountpath: "/mnt/nfs"
spec:
  storageClassName: ""
  accessModes:
  - ReadWriteMany      
  resources:
     requests:
       storage: 1Gi

Wichtig

  • Nur Befehlsauftrag/Komponente, Hyperdrive-Auftrag/Komponente und Batchbereitstellung unterstützen die benutzerdefinierte Datenspeicherung von PVC(s). > *Echtzeit-Onlineendpunkt, AutoML-Auftrag und PRS-Auftrag unterstützen keine benutzerdefinierte Datenspeicherung von PVC(s).
  • Außerdem werden nur die Auftragspods im gleichen Kubernetes-Namespace wie die PVC(s) im Volume eingebunden. Der Data Scientist kann auf den in der PVC-Anmerkung angegebenen mount path zugreifen. AutoML-Auftrag und Prs-Auftrag haben keinen Zugriff auf die PVC(s).

Unterstützte Azure Machine Learning-Taints und -Toleranzen

Taints und Toleranzen sind Kubernetes-Konzepte, die gemeinsam dafür sorgen, dass Pods nicht auf ungeeigneten Knoten geplant werden.

In Azure Machine Learning integrierte Kubernetes-Cluster (einschließlich AKS und Kubernetes-Cluster mit Arc-Unterstützung) unterstützen jetzt spezifische Azure Machine Learning-Taints und -Toleranzen. Dadurch können Benutzer spezifische Azure Machine Learning-Taints auf den dedizierten Azure Machine Learning-Knoten hinzuzufügen, um zu verhindern, dass Azure Machine Learning-fremde Workloads auf diesen dedizierten Knoten geplant werden.

Wir unterstützen nur das Platzieren der amlarc-spezifischen Taints auf Ihren Knoten, die wie folgt definiert sind:

Taint Schlüssel Wert Auswirkung Beschreibung
amlarc overall ml.azure.com/amlarc true NoSchedule, NoExecute oder PreferNoSchedule Diesen amlarc overall-Taint würden alle Azure Machine Learning-Workloads tolerieren, einschließlich der Pods für Erweiterungssystemdienste und der Pods für Machine Learning-Workloads.
amlarc system ml.azure.com/amlarc-system true NoSchedule, NoExecute oder PreferNoSchedule Diesen amlarc system-Taint würden nur Pods der Azure Machine Learning-Erweiterungssystemdienste tolerieren.
amlarc workload ml.azure.com/amlarc-workload true NoSchedule, NoExecute oder PreferNoSchedule Diesen amlarc workload-Taint würden nur Pods der Machine Learning-Workloads tolerieren.
amlarc resource group ml.azure.com/resource-group <Name_der_Ressourcengruppe> NoSchedule, NoExecute oder PreferNoSchedule Diesen amlarc resource group-Taint würden nur Pods der Machine Learning-Workloads tolerieren, die anhand der spezifischen Ressourcengruppe erstellt wurden.
amlarc workspace ml.azure.com/workspace <Name_des_Arbeitsbereichs> NoSchedule, NoExecute oder PreferNoSchedule Diesen amlarc workspace-Taint würden nur Pods der Machine Learning-Workloads tolerieren, die anhand des spezifischen Arbeitsbereich erstellt wurden.
amlarc compute ml.azure.com/compute <Computename> NoSchedule, NoExecute oder PreferNoSchedule Diesen amlarc compute-Taint würden nur Pods der Machine Learning-Workloads tolerieren, die mit dem spezifischen Computeziel erstellt wurden.

Tipp

  1. Für Azure Kubernetes Service (AKS) können Sie das Beispiel in Best Practices für erweiterte Schedulerfunktionen in Azure Kubernetes Service (AKS) verwenden, um Taints auf Knotenpools anzuwenden.
  2. Für Arc Kubernetes-Cluster, z. B. lokale Kubernetes-Cluster, können Sie den Befehl kubectl taintverwenden, um Taints zu Knoten hinzuzufügen. Weitere Beispiele finden Sie in der Kubernetes-Dokumentation.

Bewährte Methoden

Je nach Ihren Anforderungen an die Planung der Azure Machine Learning-dedizierten Knoten können Sie durch das Hinzufügen mehrerer amlarc-spezifische Taints einschränken, welche Azure Machine Learning-Workloads auf den Knoten ausgeführt werden können. Im Folgenden finden Sie eine Liste bewährter Methoden für die Verwendung von amlarc-Taints:

  • Um zu verhindern, dass Nicht-Azure-Machine-Learning-Workloads auf Azure Machine Learning-dedizierten Knoten/Knotenpools ausgeführt werden, können Sie diesen Knoten einfach den aml overall-Taint hinzufügen.
  • Um zu verhindern, dass systemfremde Pods auf Azure Machine Learning-dedizierten Knoten/Knotenpools ausgeführt werden, müssen Sie die folgenden Taints hinzufügen:
    • amlarc overall-Taint
    • amlarc system-Taint
  • Um zu verhindern, dass Machine-Learning-fremde Pods auf Azure Machine Learning-dedizierten Knoten/Knotenpools ausgeführt werden, müssen Sie die folgenden Taints hinzufügen:
    • amlarc overall-Taint
    • amlarc workloads-Taint
  • Um zu verhindern, dass nicht über Workspace X erstellte Workloads auf Azure Machine Learning-dedizierten Knoten/Knotenpools ausgeführt werden, müssen Sie die folgenden Taints hinzufügen:
    • amlarc overall-Taint
    • amlarc resource group (has this <workspace X>)-Taint
    • amlarc <workspace X>-Taint
  • Um zu verhindern, dass nicht über Computeziel X erstellte Workloads auf Azure Machine Learning-dedizierten Knoten/Knotenpools ausgeführt werden, müssen Sie die folgenden Taints hinzufügen:
    • amlarc overall-Taint
    • amlarc resource group (has this <workspace X>)-Taint
    • amlarc workspace (has this <compute X>)-Taint
    • amlarc <compute X>-Taint

Integrieren anderer Eingangsdatencontroller mit der Azure Machine Learning-Erweiterung über HTTP oder HTTPS

Zusätzlich zum standardmäßigen Azure Machine Learning-Rückschlusslastenausgleich azureml-fe können Sie auch andere Lastenausgleichsmodule über HTTP oder HTTPS in die Azure Machine Learning-Erweiterung integrieren.

In diesem Tutorial wird veranschaulicht, wie Sie den Nginx-Eingangsdatencontrollers oder Azure Application Gateway integrieren.

Voraussetzungen

Bereitstellen von Diensten über HTTP

Sie verwenden die folgende Eingangsressource, um azureml-fe verfügbar zu machen:

# Nginx Ingress Controller example
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: azureml-fe
  namespace: azureml
spec:
  ingressClassName: nginx
  rules:
  - http:
      paths:
      - path: /
        backend:
          service:
            name: azureml-fe
            port:
              number: 80
        pathType: Prefix

Diese Eingangsressource stellt den azureml-fe-Dienst und die ausgewählte Bereitstellung als Standard-Back-End des Nginx-Eingangsdatencontrollers bereit.

# Azure Application Gateway example
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: azureml-fe
  namespace: azureml
spec:
  ingressClassName: azure-application-gateway
  rules:
  - http:
      paths:
      - path: /
        backend:
          service:
            name: azureml-fe
            port:
              number: 80
        pathType: Prefix

Diese Eingangsressource stellt den azureml-fe-Dienst und die ausgewählte Bereitstellung als Standard-Back-End von Application Gateway bereit.

Speichern Sie die oben genannte Eingangsressource als ing-azureml-fe.yaml.

  1. Stellen Sie ing-azureml-fe.yaml bereit, indem Sie Folgendes ausführen:

    kubectl apply -f ing-azureml-fe.yaml

  2. Überprüfen Sie das Protokoll des Eingangscontrollers bezüglich des Bereitstellungsstatus.

  3. Nun sollte die azureml-fe-Anwendung verfügbar sein. Dies können Sie an folgender Stelle überprüfen:

    • Nginx-Eingangsdatencontroller: die öffentliche LoadBalancer-Adresse des Nginx-Eingangsdatencontrollers
    • Azure Application Gateway: die öffentliche Adresse von Application Gateway

  4. Erstellen Sie einen Rückschlussauftrag, und rufen Sie ihn auf.

    Hinweis

    Ersetzen Sie vor dem Aufrufen die IP-Adresse in „scoring_uri“ durch die öffentliche LoadBalancer-Adresse des Nginx-Eingangsdatencontrollers.

Bereitstellen von Diensten über HTTPS

  1. Vor dem Bereitstellen der Eingangsressource müssen Sie ein Kubernetes-Geheimnis erstellen, um das Zertifikat und den privaten Schlüssel zu hosten. Sie können ein Kubernetes-Geheimnis erstellen, indem Sie Folgendes ausführen:

    kubectl create secret tls <ingress-secret-name> -n azureml --key <path-to-key> --cert <path-to-cert>

  2. Definieren Sie die folgende Eingangsressource. Geben Sie in der Eingangsressource den Namen des Geheimnisses im Abschnitt secretName an.

    # Nginx Ingress Controller example
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: azureml-fe
  namespace: azureml
spec:
  ingressClassName: nginx
  tls:
  - hosts:
    - <domain>
    secretName: <ingress-secret-name>
  rules:
  - host: <domain>
    http:
      paths:
      - path: /
        backend:
          service:
            name: azureml-fe
            port:
              number: 80
        pathType: Prefix

    # Azure Application Gateway example
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: azureml-fe
  namespace: azureml
spec:
  ingressClassName: azure-application-gateway
  tls:
  - hosts:
    - <domain>
    secretName: <ingress-secret-name>
  rules:
  - host: <domain>
    http:
      paths:
      - path: /
        backend:
          service:
            name: azureml-fe
            port:
              number: 80
        pathType: Prefix

    Hinweis

    Ersetzen Sie <domain> und <ingress-secret-name> in der obigen Eingangsressource durch die Domäne, die auf LoadBalancer des Nginx-Eingangsdatencontrollers/von Application Gateway verweist, und den Namen Ihres Geheimnisses. Speichern Sie die oben angegebene Eingangsressource unter dem Dateinamen ing-azureml-fe-tls.yaml.

  3. Stellen Sie „ing-azureml-fe-tls.yaml“ bereit, indem Sie Folgendes ausführen:

    kubectl apply -f ing-azureml-fe-tls.yaml

  4. Überprüfen Sie das Protokoll des Eingangscontrollers bezüglich des Bereitstellungsstatus.

  5. Nun ist die azureml-fe-Anwendung für HTTPS verfügbar. Sie können dies überprüfen, indem Sie die öffentliche LoadBalancer-Adresse des Nginx-Eingangsdatencontrollers aufrufen.

  6. Erstellen Sie einen Rückschlussauftrag, und rufen Sie ihn auf.

    Hinweis

    Ersetzen Sie vor dem Aufrufen das Protokoll und die IP-Adresse in „scoring_uri“ durch HTTPS und die Domäne, die auf LoadBalancer des Nginx-Eingangsdatencontrollers oder auf Application Gateway verweist.

Verwenden der ARM-Vorlage zum Bereitstellen der Erweiterung

Die Erweiterung für einen verwalteten Cluster kann mit der ARM-Vorlage bereitgestellt werden. Eine Beispielvorlage finden Sie in deployextension.json und eine Demoparameterdatei in deployextension.parameters.json.

Um die Beispielbereitstellungsvorlage zu nutzen, bearbeiten Sie die Parameterdatei mit dem richtigen Wert, und führen Sie dann den folgenden Befehl aus:

az deployment group create --name <ARM deployment name> --resource-group <resource group name> --template-file deployextension.json --parameters deployextension.parameters.json

Weitere Informationen zur Verwendung der ARM-Vorlage finden Sie in der Dokumentation zu ARM-Vorlagen.

Versionshinweise zur AzureML-Erweiterung

Hinweis

Neue Features werden im zweiwöchigen Rhythmus veröffentlicht.

Date Version Versionsbeschreibung
26. September 2024 1.1.64 Sicherheitsrisiken wurden behoben.
21. November 2023 1.1.39 Sicherheitsrisiken wurden behoben. Eingeschränkte Fehlermeldung. Erhöhte Stabilität für die Relayserver-API.
1. Nov. 2023 1.1.37 Aktualisieren Der Datenebenen-Voyversion.
11. Oktober 2023 1.1.35 Behebung gefährdeter Images Bug beheben.
25. August 2023 1.1.34 Behebung gefährdeter Images Geben Sie einen detaillierteren Identitätsfehler zurück. Bug beheben.
18. Juli 2023 1.1.29 Fügen Sie neue Identitätsoperatorfehler hinzu. Fehlerbehebungen.
4. Juni 2023 1.1.28 Verbesserung der automatischen Skalierung, um mehrere Knotenpools zu verarbeiten. Fehlerbehebungen.
18. April 2023 1.1.26 Behebung von Fehlern und Sicherheitsrisiken
27. März 2023 1.1.25 Hinzufügen einer Drosselung für Azure Machine Learning-Aufträge. Schneller Fehler bei Trainingsauftrag, wenn die SSH-Einrichtung fehlgeschlagen ist. Reduzierung des Prometheus-Auslesenintervalls auf 30 s. Verbesserung der Fehlermeldungen für Rückschlüsse. Behebung gefährdeter Images
7. März 2023 1.1.23 Änderung des Standardinstanztyps für die Verwendung von 2Gi-Arbeitsspeicher. Update der Metrikkonfigurationen für scoring-fe, um scrape_interval von 15 s hinzuzufügen. Hinzufügung der Ressourcenspezifikation für MDC-Sidecar. Behebung gefährdeter Images Fehlerbehebungen.
14. Februar 2023 1.1.21 Fehlerbehebungen.
7. Februar 2023 1.1.19 Verbesserung der Fehlerrückgabemeldung für Rückschlüsse. Aktualisierung des Standardinstanztyps, sodass das Speicherlimit von 2Gi verwendet wird. Durchführen einer Überprüfung der Clusterintegrität auf Podintegrität, Ressourcenkontingent, Kubernetes-Version und Erweiterungsversion. Behebung von Programmfehlern
27. Dezember 2022 1.1.17 Fluent Bit wurde von DaemonSet in Sidecars verschoben. MDC-Unterstützung wurde hinzugefügt. Fehlermeldungen wurden optimiert. Unterstützung von Clustermodusaufträgen (Windows, Linux). Behebung von Programmfehlern
29. November 2022 1.1.16 Instanztypüberprüfung durch neue CRD hinzugefügt. Toleranzunterstützung. Gekürzter SVC-Name. Workloadkernstunde. Mehrere Fehlerbehebungen und Verbesserungen.
13. September 2022 1.1.10 Fehlerbehebungen.
29. August 2022 1.1.9 Die Logik der Integritätsprüfung wurde verbessert. Fehlerbehebungen.
23. Juni 2022 1.1.6 Fehlerbehebungen.
15. Juni 2022 1.1.5 Das Training wurde aktualisiert, um die neue allgemeine Runtime zum Ausführen von Aufträgen zu verwenden. Die Azure Relay-Verwendung für die AKS-Erweiterung wurde entfernt. Die Service Bus-Nutzung wurde aus der Erweiterung entfernt. Die Verwendung des Sicherheitskontexts wurde aktualisiert. Rückschluss azureml-fe auf v2 aktualisiert. Update zur Verwendung von Volcano als Planer für Trainingsaufgaben. Fehlerbehebungen.
14. Oktober 2021 1.0.37 Unterstützung der Einbindung von PV/PVC-Volumes im AMLArc-Trainingsauftrag.
16. September 2021 1.0.29 Neue Regionen verfügbar: WestUS, CentralUS, NorthCentralUS, KoreaCentral. Erweiterbarkeit der Auftragswarteschlange. Sehen Sie sich die Details zur Auftragswarteschlange in Azure Machine Learning Workspace Studio an. Richtlinie zur automatischen Zerstörung. Unterstützung von „max_run_duration_seconds“ in ScriptRunConfig. Das System versucht, die Ausführung automatisch abzubrechen, wenn dieser Wert überschritten wird. Leistungsverbesserung durch Unterstützung der automatischen Skalierung von Clustern. Arc-Agent- und ML-Erweiterungsbereitstellung aus der lokalen Containerregistrierung.
24. August 2021 1.0.28 Unterstützung des Compute-Instanztyps in der Auftrags-YAML. Zuweisen einer verwalteten Identität zu AMLArc-Compute.
10. August 2021 1.0.20 Neue Kubernetes-Distributionsunterstützung: K3S – Lightweight Kubernetes. Stellen Sie die Azure Machine Learning-Erweiterung in Ihrem AKS-Cluster bereit, ohne eine Verbindung über Azure Arc herzustellen. Automatisiertes maschinelles Lernen (AutoML) über das Python SDK. Verwenden Sie die Version 2.0 der CLI, um den Kubernetes-Cluster an den Azure Machine Learning-Arbeitsbereich anzufügen. Optimierte Auslastung der CPU-/Arbeitsspeicherressourcen der Azure Machine Learning-Erweiterungskomponenten.
2. Juli 2021 1.0.13 Unterstützung neuer Kubernetes-Distributionen, OpenShift Kubernetes und GKE (Google Kubernetes Engine). Unterstützung der automatischen Skalierung. Wenn für den vom Benutzer verwalteten Kubernetes-Cluster die automatische Skalierung aktiviert ist, wird der Cluster je nach Umfang der aktiven Ausführungen und Bereitstellungen automatisch verkleinert oder vergrößert. Leistungsverbesserung beim Auftragsstart, wodurch sich die Ausführungszeit von Aufträgen erheblich verkürzt.