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.

Pianificazione delle risorse consigliata

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:

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

Prerequisiti per i cluster ARO o OCP

Disabilitare Security Enhanced Linux (SELinux)

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

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.

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

2. 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

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:

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 contaminare
  • amlarc system contaminare
• 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 contaminare
  • amlarc workloads contaminare
• 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 contaminare
  • amlarc resource group (has this <workspace X>) contaminare
  • amlarc <workspace X> contaminare
• 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 contaminare
  • amlarc resource group (has this <workspace X>) contaminare
  • amlarc workspace (has this <compute X>) contaminare
  • amlarc <compute X> contaminare

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.
  • Creare un controller di base: se si inizia da zero, fare riferimento a queste istruzioni.
• 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. Distribuire ing-azureml-fe.yaml eseguendo:

   kubectl apply -f ing-azureml-fe.yaml
   

2. Controllare il log del controller in 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 l'ingresso seguente. Nell'ingresso, specificare il nome del segreto nella sezione secretName.

   # 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 file ing-azureml-fe-tls.yaml.

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

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

4. Controllare il log del controller in 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