Share via


Informazioni di riferimento per la configurazione del cluster Kubernetes per Azure Machine Learning

Questo articolo contiene informazioni di riferimento per la configurazione di Kubernetes con Azure Machine Learning.

Versione e area di Kubernetes supportate

  • I cluster Kubernetes che installano l'estensione Azure Machine Learning hanno una finestra di supporto della versione "N-2", allineata ai criteri di supporto della versione del servizio Azure Kubernetes servizio Azure Kubernetes(AKS), in cui 'N' è la versione secondaria ga più recente di servizio Azure Kubernetes.

    • Ad esempio, se il servizio Azure Kubernetes introduce la versione 1.20.a, 1.20.b, 1.19.c, 1.19.d, 1.18.e e 1.18.f sono supportati.

    • Se i clienti eseguono una versione kubernetes non supportata, viene richiesto di eseguire l'aggiornamento quando si richiede il supporto per il cluster. I cluster che eseguono versioni Kubernetes non supportate non sono coperti dai criteri di supporto delle estensioni di Azure Machine Learning.

  • Disponibilità dell'area dell'estensione di Azure Machine Learning:

    • L'estensione Azure Machine Learning può essere distribuita nel servizio Azure Kubernetes o in Kubernetes abilitato per Azure Arc nelle aree supportate elencate nel supporto dell'area Kubernetes con abilitazione di Azure Arc.

Quando si distribuisce l'estensione Azure Machine Learning, alcuni servizi correlati vengono distribuiti nel cluster Kubernetes per Azure Machine Learning. La tabella seguente elenca i servizi correlati e il relativo utilizzo delle risorse nel cluster:

Distribuire/Daemonset Replica # Formazione Inferenza Richiesta CPU (m) Limite CPU (m) Richiesta di memoria (mi) Limite di memoria (Mi)
metrics-controller-manager 1 10 100 20 300
prometheus-operator 1 100 400 128 512
Prometeo 1 100 1000 512 4096
kube-state-metrics 1 10 100 32 256
gateway 1 50 500 256 2048
fluent-bit 1 per nodo 10 200 100 300
inference-operator-controller-manager 1 N/D 100 1000 128 1024
amlarc-identity-controller 1 N/D 200 1000 200 1024
amlarc-identity-proxy 1 N/D 200 1000 200 1024
azureml-ingress-nginx-controller 1 N/D 100 1000 64 512
azureml-fe-v2 1 (a scopo di test)
o
3 (a scopo di produzione)
N/D 900 2000 800 1200
distribuzione online 1 per distribuzione Creato dall'utente N/D <definizione utente> <definizione utente> <definizione utente> <definizione utente>
online-deployment/identity-sidecar 1 per distribuzione N/D 10 50 100 100
aml-operator 1 N/D 20 1020 124 2168
ammissione di vulcano 1 N/D 10 100 64 256
vulcano-controller 1 N/D 50 500 128 512
volcano-schedular 1 N/D 50 500 128 512

Se si escludono distribuzioni/pod personalizzati, i requisiti minimi delle risorse di sistema sono i seguenti:

Scenario Inferenza abilitata Training abilitato Richiesta CPU (m) Limite CPU (m) Richiesta di memoria (mi) Limite di memoria (Mi) Numero di nodi Dimensioni minime consigliate per le macchine virtuali SKU di macchina virtuale del servizio Azure Kubernetes corrispondente
Per il test N/D 1780 8300 2440 12296 1 nodo 2 vCPU, 7 GiB Memory, 6400 IOPS, 1500Mbps BW DS2v2
Per il test N/D 410 4420 1492 10960 1 nodo 2 vCPU, 7 GiB Memory, 6400 IOPS, 1500Mbps BW DS2v2
Per il test 1910 10420 2884 15744 1 nodo 4 vCPU, 14 GiB Memory, 12800 IOPS, 1500Mbps BW DS3v2
Per la produzione N/D 3600 12700 4240 15296 3 Nodi 4 vCPU, 14 GiB Memory, 12800 IOPS, 1500Mbps BW DS3v2
Per la produzione N/D 410 4420 1492 10960 1 nodi 8 vCPU, 28GiB Memroy, 25600 IOPs, 6000Mbps BW DS4v2
Per la produzione 3730 14820 4684 18744 3 Nodi 4 vCPU, 14 GiB Memory, 12800 IOPS, 1500Mbps BW DS4v2

Nota

  • A scopo di test, è necessario fare riferimento alla richiesta di risorsa.
  • A scopo di produzione, è necessario fare riferimento al limite delle risorse.

Importante

Ecco alcune altre considerazioni per riferimento:

  • Per una maggiore larghezza di banda di rete e prestazioni di I/O del disco migliori, è consigliabile uno SKU più grande.
    • Prendere DV2/DSv2 come esempio, l'uso dello SKU di grandi dimensioni può ridurre il tempo di pull dell'immagine per migliorare le prestazioni di rete/archiviazione.
    • Altre informazioni sulla prenotazione del servizio Azure Kubernetes sono disponibili nella prenotazione del servizio Azure Kubernetes.
  • Se si usa il cluster del servizio Azure Kubernetes, potrebbe essere necessario considerare il limite di dimensioni per un'immagine del contenitore nel servizio Azure Kubernetes. Altre informazioni sono disponibili nel limite di dimensioni delle immagini del contenitore del servizio Azure Kubernetes.

Prerequisiti per i cluster ARO o OCP

Disabilitare Linux avanzato per la sicurezza (edizione Standard Linux)

Il set di dati di Azure Machine Learning (una funzionalità SDK v1 usata nei processi di training di Azure Machine Learning) non è supportata nei computer con edizione Standard Linux abilitato. È quindi necessario disabilitare selinux in tutti i ruoli di lavoro per usare il set di dati di Azure Machine Learning.

Configurazione con privilegi per ARO e OCP

Per la distribuzione dell'estensione Azure Machine Learning nel cluster ARO o OCP, concedere l'accesso con privilegi agli account del servizio Azure Machine Learning, eseguire oc edit scc privileged il comando e aggiungere gli account di servizio seguenti in "users:":

  • 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

Nota

  • {EXTENSION-NAME}: è il nome dell'estensione specificato con il comando dell'interfaccia della az k8s-extension create --name riga di comando.
  • {KUBERNETES-COMPUTE-NAMESPACE}: è lo spazio dei nomi dell'ambiente di calcolo Kubernetes specificato quando si collega l'ambiente di calcolo all'area di lavoro di Azure Machine Learning. Ignorare la system:serviceaccount:{KUBERNETES-COMPUTE-NAMESPACE}:default configurazione se KUBERNETES-COMPUTE-NAMESPACE è default.

Dettagli del log raccolti

Alcuni log sui carichi di lavoro di Azure Machine Learning nel cluster verranno raccolti tramite componenti di estensione, ad esempio stato, metriche, ciclo di vita e così via. L'elenco seguente mostra tutti i dettagli del log raccolti, inclusi il tipo di log raccolti e la posizione in cui sono stati inviati o archiviati.

Pod Descrizione risorsa Informazioni di registrazione dettaglio
amlarc-identity-controller Richiedere e rinnovare il token BLOB/Registro Azure Container di Azure tramite l'identità gestita. Utilizzato solo quando viene impostato durante enableInference=true l'installazione dell'estensione. Include log di traccia per lo stato per ottenere l'identità per gli endpoint per l'autenticazione con il servizio Azure Machine Learning.
amlarc-identity-proxy Richiedere e rinnovare il token BLOB/Registro Azure Container di Azure tramite l'identità gestita. Utilizzato solo quando viene impostato durante enableInference=true l'installazione dell'estensione. Include i log di traccia per lo stato per ottenere l'identità per l'autenticazione del cluster con il servizio Azure Machine Learning.
aml-operator Gestire il ciclo di vita dei processi di training. I log contengono lo stato del pod del processo di training di Azure Machine Learning nel cluster.
azureml-fe-v2 Componente front-end che indirizza le richieste di inferenza in ingresso ai servizi distribuiti. Accedere ai log a livello di richiesta, inclusi l'ID richiesta, l'ora di inizio, il codice di risposta, i dettagli dell'errore e le durate per la latenza della richiesta. Log di traccia per le modifiche ai metadati del servizio, il servizio che esegue lo stato integro e così via per scopi di debug.
gateway Il gateway viene usato per comunicare e inviare dati avanti e indietro. Tracciare i log sulle richieste dai servizi di Azure Machine Learning ai cluster.
healthcheck -- I log contengono azureml lo stato della risorsa dello spazio dei nomi (estensione Azure Machine Learning) per diagnosticare ciò che rende l'estensione non funzionale.
inference-operator-controller-manager Gestire il ciclo di vita degli endpoint di inferenza. I log contengono l'endpoint di inferenza di Azure Machine Learning e lo stato del pod di distribuzione nel cluster.
metrics-controller-manager Gestire la configurazione per Prometheus. Log di traccia per lo stato del caricamento delle metriche di distribuzione del processo di training e dell'inferenza sull'utilizzo della CPU e della memoria.
server di inoltro Il server di inoltro è necessario solo nel cluster connesso ad arco e non verrà installato nel cluster del servizio Azure Kubernetes. Il server di inoltro funziona con Inoltro di Azure per comunicare con i servizi cloud. I log contengono informazioni sul livello di richiesta dall'inoltro di Azure.

I processi di Azure Machine Learning si connettono con l'archiviazione dati personalizzata

Il volume permanente (PV) e l'attestazione di volume persistente (PVC) sono il concetto di Kubernetes, consentendo all'utente di fornire e utilizzare varie risorse di archiviazione.

  1. Creare pv, accettare NFS come esempio
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. Creare PVC nello stesso spazio dei nomi Kubernetes con carichi di lavoro ml. In metadataè necessario aggiungere un'etichetta ml.azure.com/pvc: "true" da riconoscere da Azure Machine Learning e aggiungere annotazione ml.azure.com/mountpath: <mount path> per impostare il percorso di montaggio.
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

Importante

  • Solo il processo/componente del comando, il processo/componente hyperdrive e la distribuzione batch supportano l'archiviazione dei dati personalizzata da PVC/s. > * L'endpoint online in tempo reale, il processo AutoML e il processo PRS non supportano l'archiviazione dati personalizzata da PVC/s.
  • Inoltre, solo i pod nello stesso spazio dei nomi Kubernetes con i PVC verranno montati nel volume. Il data scientist è in grado di accedere all'oggetto mount path specificato nell'annotazione PVC nel processo. AutoML job and Prs job will not have access to the PVC(s).

Taint e tolleranze di Azure Machine Learning supportati

Taint e Toleration sono concetti di Kubernetes che interagiscono per garantire che i pod non siano pianificati in nodi inappropriati.

I cluster Kubernetes integrati con Azure Machine Learning (inclusi i cluster AKS e Arc Kubernetes) supportano ora contenitori e tolleranze di Azure Machine Learning specifici, consentendo agli utenti di aggiungere nodi specifici di Azure Machine Learning nei nodi dedicati di Azure Machine Learning, per evitare che i carichi di lavoro non di Azure Machine Learning vengano pianificati in questi nodi dedicati.

È supportato solo l'inserimento ditaints specifici dell'amlarc nei nodi, definiti come segue:

Macchia Chiave valore Effetto Descrizione
amlarc complessivamente ml.azure.com/amlarc true NoSchedule, NoExecute o PreferNoSchedule Tutti i carichi di lavoro di Azure Machine Learning, inclusi i pod del servizio di sistema di estensione e i pod dei carichi di lavoro di Machine Learning tollerano questo amlarc overall taint.
sistema amlarc ml.azure.com/amlarc-system true NoSchedule, NoExecute o PreferNoSchedule Solo i pod dei servizi di sistema delle estensioni di Azure Machine Learning tollerano questo amlarc system taint.
carico di lavoro amlarc ml.azure.com/amlarc-workload true NoSchedule, NoExecute o PreferNoSchedule Solo i pod del carico di lavoro di Machine Learning tollerano questo amlarc workload taint.
gruppo di risorse amlarc ml.azure.com/resource-group <nome del gruppo di risorse> NoSchedule, NoExecute o PreferNoSchedule Solo i pod del carico di lavoro di Machine Learning creati dal gruppo di risorse specifico tollerano questo amlarc resource group taint.
area di lavoro amlarc ml.azure.com/workspace <nome dell'area di lavoro> NoSchedule, NoExecute o PreferNoSchedule Solo i pod del carico di lavoro di Machine Learning creati dall'area di lavoro specifica tollerano questo amlarc workspace taint.
calcolo amlarc ml.azure.com/compute <nome calcolo> NoSchedule, NoExecute o PreferNoSchedule Solo i pod del carico di lavoro di Machine Learning creati con la destinazione di calcolo specifica tollerano questo amlarc compute taint.

Suggerimento

  1. Per servizio Azure Kubernetes(servizio Azure Kubernetes), è possibile seguire l'esempio in Procedure consigliate per le funzionalità avanzate dell'utilità di pianificazione in servizio Azure Kubernetes (servizio Azure Kubernetes) per applicare i vincoli ai pool di nodi.
  2. Per i cluster Kubernetes Arc, ad esempio i cluster Kubernetes locali, è possibile usare il kubectl taint comando per aggiungeretaints ai nodi. Per altri esempi, vedere la documentazione di Kubernetes.

Procedure consigliate

In base ai requisiti di pianificazione dei nodi dedicati di Azure Machine Learning, è possibile aggiungere piùtaint specifici di amlarc per limitare l'esecuzione dei carichi di lavoro di Azure Machine Learning nei nodi. Vengono elencate le procedure consigliate per l'uso ditaints amlarc:

  • Per impedire l'esecuzione di carichi di lavoro non di Azure Machine Learning in nodi/pool di nodi dedicati ad Azure Machine Learning, è sufficiente aggiungere il aml overall taint a questi nodi.
  • Per impedire l'esecuzione di pod non di sistema in nodi/pool di nodi dedicati ad Azure Machine Learning, è necessario aggiungere i seguenti taints:
    • amlarc overall Macchia
    • amlarc system Macchia
  • Per impedire l'esecuzione di carichi di lavoro non ml in nodi/pool di nodi dedicati ad Azure Machine Learning, è necessario aggiungere i seguenti taints:
    • amlarc overall Macchia
    • amlarc workloads Macchia
  • Per evitare che i carichi di lavoro non creati dall'area di lavoro X vengano eseguiti in nodi/pool di nodi dedicati di Azure Machine Learning, è necessario aggiungere i seguenti taints:
    • amlarc overall Macchia
    • amlarc resource group (has this <workspace X>) Macchia
    • amlarc <workspace X> Macchia
  • Per evitare che i carichi di lavoro non creati dalla destinazione di calcolo X vengano eseguiti nei pool di nodi/nodi dedicati di Azure Machine Learning, è necessario aggiungere le condizioni seguenti:
    • amlarc overall Macchia
    • amlarc resource group (has this <workspace X>) Macchia
    • amlarc workspace (has this <compute X>) Macchia
    • amlarc <compute X> Macchia

Integrare altri controller di ingresso con l'estensione Azure Machine Learning su HTTP o HTTPS

Oltre al servizio di inferenza di Azure Machine Learning predefinito azureml-fe, è anche possibile integrare altri servizi di bilanciamento del carico con l'estensione Azure Machine Learning su HTTP o HTTPS.

Questa esercitazione illustra come integrare il controller di ingresso Nginx o il gateway di app Azure lication.

Prerequisiti

  • Distribuire l'estensione Di Azure Machine Learning con inferenceRouterServiceType=ClusterIP e allowInsecureConnections=True, in modo che il controller di ingresso Nginx possa gestire la terminazione TLS autonomamente anziché distribuirla ad azureml-fe quando il servizio viene esposto tramite HTTPS.
  • Per l'integrazione con il controller di ingresso Nginx, è necessaria una configurazione del cluster Kubernetes con il controller di ingresso Nginx.
  • Per l'integrazione con app Azure lication Gateway, è necessaria una configurazione del cluster Kubernetes con app Azure lication Gateway Ingress Controller.
    • Distribuzione di Greenfield: se si inizia da zero, fare riferimento a queste istruzioni.
    • Distribuzione brownfield: se si dispone di un cluster del servizio Azure Kubernetes esistente e gateway applicazione, vedere queste istruzioni.
  • Se si vuole usare HTTPS in questa applicazione, è necessario un certificato x509 e la relativa chiave privata.

Esporre i servizi tramite HTTP

Per esporre azureml-fe, si userà la risorsa di ingresso seguente:

# 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

Questo ingresso espone il azureml-fe servizio e la distribuzione selezionata come back-end predefinito del controller di ingresso Nginx.

# 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

Questo ingresso espone il azureml-fe servizio e la distribuzione selezionata come back-end predefinito del gateway applicazione.

Salvare la risorsa in ingresso precedente come ing-azureml-fe.yaml.

  1. Eseguire la distribuzione ing-azureml-fe.yaml eseguendo:

    kubectl apply -f ing-azureml-fe.yaml
    
  2. Controllare il log del controller di ingresso per verificare lo stato della distribuzione.

  3. A questo punto l'applicazione azureml-fe dovrebbe essere disponibile. È possibile controllare visitando:

    • Controller di ingresso Nginx: indirizzo LoadBalancer pubblico del controller di ingresso Nginx
    • app Azure lication Gateway: indirizzo pubblico del gateway applicazione.
  4. Creare un processo di inferenza e richiamare.

    Nota

    Sostituire l'ip in scoring_uri con l'indirizzo LoadBalancer pubblico del controller di ingresso Nginx prima di richiamare.

Esporre i servizi tramite HTTPS

  1. Prima di distribuire l'ingresso, è necessario creare un segreto kubernetes per ospitare il certificato e la chiave privata. È possibile creare un segreto kubernetes eseguendo

    kubectl create secret tls <ingress-secret-name> -n azureml --key <path-to-key> --cert <path-to-cert>
    
  2. Definire i dati di ingresso seguenti. Nell'ingresso specificare il nome del segreto nella secretName sezione .

    # 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
    

    Nota

    Sostituire <domain> e <ingress-secret-name> nella risorsa in ingresso precedente con il dominio che punta a LoadBalancer del controller di ingresso Nginx/gateway applicazione e il nome del segreto. Archiviare la risorsa in ingresso precedente in un nome ing-azureml-fe-tls.yamlfile .

  3. Distribuire ing-azureml-fe-tls.yaml eseguendo

    kubectl apply -f ing-azureml-fe-tls.yaml
    
  4. Controllare il log del controller di ingresso per verificare lo stato della distribuzione.

  5. Ora l'applicazione azureml-fe è disponibile su HTTPS. È possibile verificarne il contenuto visitando l'indirizzo LoadBalancer pubblico del controller di ingresso Nginx.

  6. Creare un processo di inferenza e richiamare.

    Nota

    Sostituire il protocollo e l'IP in scoring_uri con https e il dominio che puntano a LoadBalancer del controller di ingresso Nginx o al gateway applicazione prima di richiamare.

Usare il modello di ARM per distribuire l'estensione

L'estensione nel cluster gestito può essere distribuita con il modello di Resource Manager. Un modello di esempio è disponibile in deployextension.json, con un file di parametri demo deployextension.parameters.json

Per usare il modello di distribuzione di esempio, modificare il file di parametri con il valore corretto, quindi eseguire il comando seguente:

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

Altre informazioni sull'uso del modello di Resource Manager sono disponibili nella documentazione del modello di Resource Manager

Nota sulla versione dell'estensione AzuremML

Nota

Le nuove funzionalità vengono rilasciate in un calendario biweekly.

Data Versione Descrizione della versione
21 novembre 2023 1.1.39 Correzione delle vulnerabilità. Messaggio di errore perfezionato. Maggiore stabilità per l'API relayserver.
1 novembre 2023 1.1.37 Aggiornare la versione di envoy del piano dati.
11 ott. 2023 1.1.35 Correggere l'immagine vulnerabile. Correzioni di bug.
25 ag. 2023 1.1.34 Correggere l'immagine vulnerabile. Restituisce un errore di identità più dettagliato. Correzioni di bug.
18 luglio 2023 1.1.29 Aggiungere nuovi errori dell'operatore Identity. Correzioni di bug.
4 giugno 2023 1.1.28 Migliorare il ridimensionamento automatico per gestire più pool di nodi. Correzioni di bug.
Apr 18 , 2023 1.1.26 Correzioni di bug e correzioni di vulnerabilità.
27 mar. 2023 1.1.25 Aggiungere la limitazione del processo di Azure Machine Learning. Errore rapido per il processo di training quando l'installazione di SSH non è riuscita. Ridurre l'intervallo di raschiatura prometheus a 30 secondi. Migliorare i messaggi di errore per l'inferenza. Correggere l'immagine vulnerabile.
7 marzo 2023 1.1.23 Modificare il tipo di istanza predefinito per usare la memoria 2Gi. Aggiornare le configurazioni delle metriche per il punteggio fe che aggiungono 15 scrape_interval. Aggiungere la specifica della risorsa per mdc sidecar. Correggere l'immagine vulnerabile. Correzioni di bug.
14 febbraio 2023 1.1.21 Correzioni di bug.
7 febbraio 2023 1.1.19 Migliorare il messaggio di restituzione degli errori per l'inferenza. Aggiornare il tipo di istanza predefinito per usare il limite di memoria 2Gi. Eseguire il controllo dell'integrità del cluster per l'integrità dei pod, la quota delle risorse, la versione di Kubernetes e la versione dell'estensione. Correzioni di bug
27 dicembre 2022 1.1.17 Spostare fluent-bit da DaemonSet a sidecar. Aggiungere il supporto MDC. Perfezionare i messaggi di errore. Supportare i processi in modalità cluster (Windows, Linux). Correzioni di bug
29 novembre 2022 1.1.16 Aggiungere la convalida del tipo di istanza in base al nuovo CRD. Tolleranza di supporto. Abbreviare il nome SVC. Ora core del carico di lavoro. Correzioni e miglioramenti di più bug.
13 settembre 2022 1.1.10 Correzioni di bug.
29 agosto 2022 1.1.9 Logica di controllo dell'integrità migliorata. Correzioni di bug.
23 giugno 2022 1.1.6 Correzioni di bug.
15 giugno 2022 1.1.5 Aggiornamento del training per l'uso di common runtime per l'esecuzione di processi. Rimozione dell'utilizzo dell'inoltro di Azure per l'estensione servizio Azure Kubernetes. Rimozione dell'utilizzo del bus di servizio dall'estensione. Aggiornamento dell'utilizzo del contesto di sicurezza. Aggiornamento dell'inferenza azureml-fe alla versione 2. Aggiornato per usare Volcano come utilità di pianificazione del processo di training. Correzioni di bug.
14 ottobre 2021 1.0.37 Supporto del montaggio del volume PV/PVC nel processo di training AMLArc.
16 settembre 2021 1.0.29 Nuove aree disponibili, WestUS, CentralUS, NorthCentralUS, KoreaCentral. Espandibilità della coda di processi. Vedere i dettagli della coda dei processi in Azure Machine Learning Workspace Studio. Criteri di eliminazione automatica. Supporto max_run_duration_seconds in ScriptRunConfig. Il sistema tenta di annullare automaticamente l'esecuzione se è necessario più tempo del valore dell'impostazione. Miglioramento delle prestazioni sul supporto del ridimensionamento automatico del cluster. Distribuzione dell'agente Arc e dell'estensione ML dal registro contenitori locale.
24 agosto 2021 1.0.28 Il tipo di istanza di calcolo è supportato in YAML del processo. Assegnare l'identità gestita al calcolo AMLArc.
10 agosto 2021 1.0.20 Nuovo supporto per la distribuzione di Kubernetes, K3S - Lightweight Kubernetes. Distribuire l'estensione Azure Machine Learning nel cluster del servizio Azure Kubernetes senza connettersi tramite Azure Arc. Machine Learning automatizzato (AutoML) tramite Python SDK. Usare l'interfaccia della riga di comando 2.0 per collegare il cluster Kubernetes all'area di lavoro di Azure Machine Learning. Ottimizzare l'utilizzo delle risorse cpu/memoria dei componenti dell'estensione di Azure Machine Learning.
2 luglio 2021 1.0.13 Supporto delle nuove distribuzioni Kubernetes, OpenShift Kubernetes e GKE (Google Kubernetes Engine). Supporto per la scalabilità automatica. Se il cluster Kubernetes gestito dall'utente abilita la scalabilità automatica, il cluster viene automaticamente ridimensionato o ridimensionato in base al volume di esecuzioni e distribuzioni attive. Miglioramento delle prestazioni sull'utilità di avvio del processo, che riduce notevolmente il tempo di esecuzione del processo.