Informations de référence sur la configuration d’un cluster Kubernetes pour Azure Machine Learning
Cet article contient des informations de référence pour la configuration de Kubernetes avec Azure Machine Learning.
Version et région de Kubernetes prises en charge
Les clusters Kubernetes qui installent l’extension Azure Machine Learning ont une fenêtre de prise en charge de version « N-2 », alignée sur la stratégie de prise en charge des version d’Azure Kubernetes Service (AKS), « N » correspondant à la dernière version mineure en disponibilité générale d’Azure Kubernetes Service.
Par exemple, si AKS introduit la version 1.20.a aujourd’hui, les versions 1.20.a, 1.20.b, 1.19.c, 1.19.d, 1.18.e et 1.18.f sont prises en charge.
Si les clients utilisent une version de Kubernetes non prise en charge, ils sont invités à effectuer une mise à niveau lorsqu’ils demandent une assistance pour le cluster. Les clusters exécutant des versions de Kubernetes non prises en charge ne sont pas couverts par les stratégies de prise en charge de l’extension Azure Machine Learning.
Disponibilité par région de l’extension Azure Machine Learning :
- L’extension Azure Machine Learning peut être déployée sur AKS ou Kubernetes avec Azure Arc dans les régions prises en charge listées dans Régions prises en charge pour Kubernetes avec Azure Arc.
Planification des ressources recommandée
Lorsque vous déployez l’extension Azure Machine Learning, certains services connexes sont déployés dans votre cluster Kubernetes pour Azure Machine Learning. Le tableau suivant liste les services associés et leur utilisation des ressources dans le cluster :
| Déploiement/Daemonset | N° de réplica | Entrainement | Inférence | Demande de processeur (m) | Limite de processeur (m) | Demande de mémoire (Mi) | Limite de mémoire (Mi) |
|---|---|---|---|---|---|---|---|
| metrics-controller-manager | 1 | ✓ | ✓ | 10 | 100 | 20 | 300 |
| prometheus-operator | 1 | ✓ | ✓ | 100 | 400 | 128 | 512 |
| prometheus | 1 | ✓ | ✓ | 100 | 1 000 | 512 | 4096 |
| kube-state-metrics | 1 | ✓ | ✓ | 10 | 100 | 32 | 256 |
| passerelle | 1 | ✓ | ✓ | 50 | 500 | 256 | 2 048 |
| fluent-bit | 1 par nœud | ✓ | ✓ | 10 | 200 | 100 | 300 |
| inference-operator-controller-manager | 1 | ✓ | N/A | 100 | 1 000 | 128 | 1 024 |
| amlarc-identity-controller | 1 | ✓ | N/A | 200 | 1 000 | 200 | 1 024 |
| amlarc-identity-proxy | 1 | ✓ | N/A | 200 | 1 000 | 200 | 1 024 |
| azureml-ingress-nginx-controller | 1 | ✓ | N/A | 100 | 1 000 | 64 | 512 |
| azureml-fe-v2 | 1 (à des fins de test) ou 3 (à des fins de production) |
✓ | N/A | 900 | 2000 | 800 | 1200 |
| online-deployment | 1 par déploiement | Créé par l’utilisateur | N/A | <user-define> | <user-define> | <user-define> | <user-define> |
| online-deployment/identity-sidecar | 1 par déploiement | ✓ | N/A | 10 | 50 | 100 | 100 |
| aml-operator | 1 | N/A | ✓ | 20 | 1020 | 124 | 2168 |
| volcano-admission | 1 | N/A | ✓ | 10 | 100 | 64 | 256 |
| volcano-controller | 1 | N/A | ✓ | 50 | 500 | 128 | 512 |
| volcano-schedular | 1 | N/A | ✓ | 50 | 500 | 128 | 512 |
À l’exception de vos propres déploiements/pods, les ressources système minimales requises sont les suivantes :
| Scénario | Inférence activée | Entraînement activé | Demande de processeur (m) | Limite de processeur (m) | Demande de mémoire (Mi) | Limite de mémoire (Mi) | Nombre de nœuds | Taille de machine virtuelle minimale recommandée | Référence SKU de machine virtuelle AKS correspondante |
|---|---|---|---|---|---|---|---|---|---|
| Pour les tests | ✓ | N/A | 1 780 | 8 300 | 2 440 | 12 296 | 1 nœud | 2 processeurs virtuels, 7 Gio de mémoire, 6 400 IOPS, 1 500 Mbit/s de bande passante | DS2v2 |
| Pour les tests | N/A | ✓ | 410 | 4420 | 1 492 | 10 960 | 1 nœud | 2 processeurs virtuels, 7 Gio de mémoire, 6 400 IOPS, 1 500 Mbit/s de bande passante | DS2v2 |
| Pour les tests | ✓ | ✓ | 1910 | 10420 | 2 884 | 15 744 | 1 nœud | 4 processeurs virtuels, 14 Gio de mémoire, 12 800 IOPS, 1 500 Mbit/s de bande passante | DS3v2 |
| Pour la production | ✓ | N/A | 3600 | 12 700 | 4 240 | 15296 | 3 nœud(s) | 4 processeurs virtuels, 14 Gio de mémoire, 12 800 IOPS, 1 500 Mbit/s de bande passante | DS3v2 |
| Pour la production | N/A | ✓ | 410 | 4420 | 1 492 | 10 960 | 1 nœud(s) | 8 processeurs virtuels, 28 Gio de mémoire, 25 600 IOPS, 6 000 Mbits/s de bande passante | DS4v2 |
| Pour la production | ✓ | ✓ | 3730 | 14 820 | 4 684 | 18 744 | 3 nœud(s) | 4 processeurs virtuels, 14 Gio de mémoire, 12 800 IOPS, 1 500 Mbit/s de bande passante | DS4v2 |
Notes
- À des fins de test, vous devez faire référence à la requête de la ressource.
- À des fins de production, vous devez faire référence à la limite de la ressource.
Important
Voici d’autres points à prendre en compte pour référence :
- Pour une bande passante réseau plus élevée et de meilleures performances des E/S de disque, nous vous recommandons une référence SKU plus grande.
- Prenons l’exemple de DV2/DSv2. L’utilisation d’une référence SKU plus grande peut réduire le temps d’extraction de l’image pour de meilleures performances au niveau du réseau/stockage.
- Vous trouverez plus d’informations sur la réservation AKS dans Réservation AKS.
- Si vous utilisez le cluster AKS, vous devrez éventuellement tenir compte de la taille limite d’une image de conteneur dans AKS, plus d’informations sont disponibles dans Limite de taille d’image de conteneur AKS.
Prérequis pour les clusters ARO ou OCP
Désactiver SELinux (Security Enhanced Linux)
Le jeu de données Azure Machine Learning (fonctionnalité du SDK v1 utilisée dans les travaux d’entraînement Azure Machine Learning) n’est pas pris en charge sur les machines avec SELinux activé. Vous devez donc désactiver selinux sur tous les Workers pour pouvoir utiliser le jeu de données Azure Machine Learning.
Configuration privilégiée pour ARO et OCP
Pour le déploiement de l’extension Azure Machine Learning sur un cluster ARO ou OCP, accordez un accès privilégié aux comptes de service Azure Machine Learning, exécutez la commande oc edit scc privileged et ajoutez les comptes de service suivants sous « users: » :
system:serviceaccount:azure-arc:azure-arc-kube-aad-proxy-sasystem:serviceaccount:azureml:{EXTENSION-NAME}-kube-state-metricssystem:serviceaccount:azureml:prom-admissionsystem:serviceaccount:azureml:defaultsystem:serviceaccount:azureml:prom-operatorsystem:serviceaccount:azureml:load-amlarc-selinux-policy-sasystem:serviceaccount:azureml:azureml-fe-v2system:serviceaccount:azureml:prom-prometheussystem:serviceaccount:{KUBERNETES-COMPUTE-NAMESPACE}:defaultsystem:serviceaccount:azureml:azureml-ingress-nginxsystem:serviceaccount:azureml:azureml-ingress-nginx-admission
Notes
{EXTENSION-NAME}est le nom de l’extension spécifié avec la commande CLIaz k8s-extension create --name.{KUBERNETES-COMPUTE-NAMESPACE}est l’espace de noms du calcul Kubernetes spécifié au moment d’attacher le calcul à l’espace de travail Azure Machine Learning. Passez la configuration desystem:serviceaccount:{KUBERNETES-COMPUTE-NAMESPACE}:defaultsiKUBERNETES-COMPUTE-NAMESPACEa la valeurdefault.
Détails des journaux collectés
Certains journaux sur les charges de travail Azure Machine Learning dans le cluster sont collectés via des composants d’extension, comme l’état, les métriques, le cycle de vie, etc. La liste suivante montre tous les détails des journaux collectés, notamment le type de journaux collectés et où ils ont été envoyés ou stockés.
| Pod | Description de la ressource | Informations de journalisation des détails |
|---|---|---|
| amlarc-identity-controller | Demander et renouveler le jeton Blob Azure/Azure Container Registry par le biais d’une identité managée. | Utilisé uniquement lorsque enableInference=true est défini lors de l’installation de l’extension. Il contient des journaux de trace pour l’état de l’obtention de l’identité des points de terminaison à authentifier auprès du service Azure Machine Learning. |
| amlarc-identity-proxy | Demander et renouveler le jeton Blob Azure/Azure Container Registry par le biais d’une identité managée. | Utilisé uniquement lorsque enableInference=true est défini lors de l’installation de l’extension. Il contient des journaux de trace pour l’état de l’obtention de l’identité du cluster à authentifier auprès du service Azure Machine Learning. |
| aml-operator | Gérer le cycle de vie des travaux d’apprentissage. | Les journaux contiennent l’état du pod de travail d’entraînement Azure Machine Learning dans le cluster. |
| azureml-fe-v2 | Composant frontal qui achemine les demandes d’inférence entrantes vers les services déployés. | Journaux d’accès au niveau de la requête, y compris l’ID de requête, l’heure de début, le code de réponse, les détails des erreurs et les durées de latence de la requête. Journaux de trace pour les modifications de métadonnées de service, l’état sain de l’exécution des services, etc., à des fins de débogage. |
| passerelle | Passerelle sert à communiquer et à envoyer les données dans les deux sens. | Journaux de trace sur les demandes de services Azure Machine Learning auprès de clusters. |
| healthcheck | -- | Les journaux contiennent l’état des ressources de l’espace de noms azureml (extension Azure Machine Learning) pour diagnostiquer les causes du non-fonctionnement de l’extension. |
| inference-operator-controller-manager | Gérer le cycle de vie des points de terminaison d’inférence. | Les journaux contiennent le point de terminaison d’inférence Azure Machine Learning et l’état du pod de déploiement dans le cluster. |
| metrics-controller-manager | Gérer la configuration pour Prometheus. | Journaux de trace pour l’état du chargement des métriques de déploiement d’inférence et de travail d’entraînement lors de l’utilisation du processeur et de la mémoire. |
| relay server | Le serveur de relais n’est nécessaire que dans un cluster connecté à Arc et ne sera pas installé dans le cluster AKS. | relayserver et Azure Relay fonctionnent ensemble pour communiquer avec les services cloud. Les journaux contiennent des informations au niveau de la requête provenant d’Azure Relay. |
Les tâches Azure Machine Learning se connectent au stockage de données personnalisé
Le volume persistant (PV) et la revendication de volume persistant (PVC) sont des concepts Kubernetes, qui permettent à l’utilisateur de fournir et de consommer différentes ressources de stockage.
- Créez un volume persistant, prenez NFS comme exemple,
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
- Créez une revendication PVC dans le même espace de noms Kubernetes avec les charges de travail ML. Dans
metadata, vous devez ajouter l’étiquetteml.azure.com/pvc: "true"pour la faire reconnaître à Azure Machine Learning et ajouter l’annotationml.azure.com/mountpath: <mount path>pour définir le chemin de montage.
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
Important
- Seuls le travail/composant de commande, le travail/composant Hyperdrive et le déploiement par lots prennent en charge le stockage de données personnalisé à partir d’un ou de plusieurs PVC. > * Le point de terminaison en ligne et en temps réel, le travail AutoML et le travail PRS ne prennent pas en charge le stockage de données personnalisé à partir d’un ou de plusieurs PVC.
- De plus, seuls les pods du même espace de noms Kubernetes avec la ou les revendications PVC seront montés sur le volume. Un scientifique des données peut accéder au
mount pathspécifiée dans l’annotation PVC du travail. Les travaux AutoML et Prs ne vont pas avoir accès à un ou plusieurs PVC.
Prise en charge des répulsions et attractions Azure Machine Learning
Répulsion et attraction sont des concepts Kubernetes qui fonctionnent ensemble pour s’assurer que les pods ne sont pas planifiés sur des nœuds inappropriés.
Les clusters Kubernetes intégrés à Azure Machine Learning (notamment les clusters AKS et Arc Kubernetes) prennent désormais en charge les répulsions et attractions Azure Machine Learning spécifiques. Ainsi, les utilisateurs peuvent ajouter des répulsions Azure Machine Learning spécifiques aux nœuds dédiés Azure Machine Learning pour empêcher la planification de charges de travail non Azure Machine Learning sur ces nœuds dédiés.
Nous prenons en charge uniquement le placement des répulsions amlarc spécifiques sur vos nœuds, qui sont définies comme suit :
| Répulsion | Clé | Valeur | Effet | Description |
|---|---|---|---|---|
| amlarc overall (ensemble amlarc) | ml.azure.com/amlarc | true | NoSchedule, NoExecute ou PreferNoSchedule |
Toutes les charges de travail Azure Machine Learning, dont les pods de service de système d’extension et les pods de charge de travail d’apprentissage automatique, toléreraient cette répulsion amlarc overall. |
| amlarc system (système amlarc) | ml.azure.com/amlarc-system | true | NoSchedule, NoExecute ou PreferNoSchedule |
Seuls les pods de services de système d’extension Azure Machine Learning toléreraient cette répulsionamlarc system. |
| charge de travail amlarc | ml.azure.com/amlarc-workload | true | NoSchedule, NoExecute ou PreferNoSchedule |
Seuls les pods de charge de travail de machine learning tolèrent cette répulsion amlarc workload. |
| amlarc resource group (groupe de ressources amlarc) | ml.azure.com/resource-group | <nom du groupe de ressources> | NoSchedule, NoExecute ou PreferNoSchedule |
Seuls les pods de charge de travail de machine learning créés à partir du groupe de ressources spécifique tolèrent cette répulsion amlarc resource group. |
| amlarc workspace (espace de travail amlarc) | ml.azure.com/workspace | <nom de l’espace de travail> | NoSchedule, NoExecute ou PreferNoSchedule |
Seuls les pods de charge de travail de machine learning créés à partir de l’espace de travail spécifique tolèrent cette répulsion amlarc workspace. |
| amlarc compute (calcul amlarc) | ml.azure.com/compute | <nom de la capacité de calcul> | NoSchedule, NoExecute ou PreferNoSchedule |
Seuls les pods de charge de travail de machine learning créés avec la cible de calcul spécifique tolèrent cette répulsion amlarc compute. |
Conseil
- Pour AKS (Azure Kubernetes Service), vous pouvez suivre l’exemple fourni dans Bonnes pratiques relatives aux fonctionnalités avancées du planificateur dans Azure Kubernetes Service (AKS) afin d’appliquer des répulsions aux pools de nœuds.
- Pour les clusters Kubernetes avec Arc, par exemple les clusters Kubernetes locaux, vous pouvez utiliser la commande
kubectl taintpour ajouter des répulsions aux nœuds. Pour obtenir plus d’exemples, consultez la documentation de Kubernetes.
Bonnes pratiques
Selon vos exigences de planification des nœuds dédiés à Azure Machine Learning, vous pouvez ajouter plusieurs répulsions spécifiques à l’amlarc pour restreindre les charges de travail Azure Machine Learning qui peuvent s’exécuter sur les nœuds. Nous listons les bonnes pratiques liées à l’utilisation des répulsions amlarc :
- Pour empêcher les charges de travail non-Azure Machine Learning de s’exécuter sur les nœuds/pools de nœuds dédiés à Azure Machine Learning, vous pouvez simplement ajouter la répulsion
aml overallà ces nœuds. - Pour empêcher les pods non-système de s’exécuter sur les nœuds dédiés à Azure Machine Learning/pools de nœuds, vous devez ajouter les répulsions suivantes :
- Répulsion
amlarc overall - Répulsion
amlarc system
- Répulsion
- Pour empêcher les charges de travail non-ml de s’exécuter sur les nœuds/pools de nœuds dédiés à Azure Machine Learning, vous devez ajouter les répulsions suivantes :
- Répulsion
amlarc overall - Répulsion
amlarc workloads
- Répulsion
- Pour empêcher les charges de travail non créées à partir de espace de travail X de s’exécuter sur les nœuds/pools de nœuds dédiés à Azure Machine Learning, vous devez ajouter les répulsions suivantes :
- Répulsion
amlarc overall - Répulsion
amlarc resource group (has this <workspace X>) - Répulsion
amlarc <workspace X>
- Répulsion
- Pour empêcher les charges de travail non créées par cible de calcul X de s’exécuter sur des nœuds/pools de nœuds dédiés à Azure Machine Learning, vous devez ajouter les répulsions suivantes :
- Répulsion
amlarc overall - Répulsion
amlarc resource group (has this <workspace X>) - Répulsion
amlarc workspace (has this <compute X>) - Répulsion
amlarc <compute X>
- Répulsion
Intégrer d’autres contrôleurs d’entrée à l’extension Azure Machine Learning sur HTTP ou HTTPS
En plus de l’équilibreur de charge d’inférence Azure Machine Learning par défaut azureml-fe, vous pouvez intégrer d’autres équilibreurs de charge avec l’extension Azure Machine Learning sur HTTP ou HTTPS.
Ce tutoriel montre comment intégrer Nginx Ingress Controller ou Azure Application Gateway.
Prérequis
- Déployez l’extension Azure Machine Learning avec
inferenceRouterServiceType=ClusterIPetallowInsecureConnections=True, afin que Nginx Ingress Controller puisse gérer la terminaison TLS par lui-même au lieu de la remettre à azureml-fe quand le service est exposé sur HTTPS. - Pour l’intégration au Contrôleur d’entrée Nginx, vous avez besoin d’une configuration de cluster Kubernetes avec le contrôleur d’entrée Nginx.
- Créez un contrôleur de base : si vous partez de zéro, reportez-vous à ces instructions.
- Pour l’intégration à Azure Application Gateway, vous avez besoin d’une configuration de cluster Kubernetes avec le contrôleur d’entrée Azure Application Gateway.
- Déploiement greenfield : si vous partez de zéro, reportez-vous à ces instructions.
- Déploiement brownfield : Si vous avez un cluster AKS et Application Gateway, reportez-vous à ces instructions.
- Si vous souhaitez utiliser le protocole HTTPS sur cette application, vous avez besoin d’un certificat x509 et de sa clé privée.
Exposer des services via HTTP
Pour exposer azureml-fe, nous utiliserons la ressource d’entrée suivante :
# 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
Cette entrée expose le service azureml-fe et le déploiement sélectionné en tant que backend par défaut du contrôleur d’entrée 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
Cette entrée expose le service azureml-fe et le déploiement sélectionné en tant que backend par défaut d’Application Gateway.
Enregistrez la ressource d’entrée ci-dessus sous ing-azureml-fe.yaml.
Déployez
ing-azureml-fe.yamlen l’exécutant :kubectl apply -f ing-azureml-fe.yamlVérifiez l’état du déploiement dans le journal du contrôleur d’entrée.
L’application
azureml-fedevrait maintenant être disponible. Vous pouvez vérifier en visitant :- Nginx Ingress Controller : adresse LoadBalancer publique de Nginx Ingress Controller
- Azure Application Gateway : adresse publique d’Application Gateway.
Créez un travail d’inférence et appelez.
Notes
Remplacez l’IP dans scoring_uri par l’adresse LoadBalancer publique de Nginx Ingress Controller avant d’appeler.
Exposer des services via HTTPS
Avant de déployer l’entrée, vous devez créer un secret Kubernetes pour héberger le certificat et la clé privée. Vous pouvez créer un secret Kubernetes en l’exécutant
kubectl create secret tls <ingress-secret-name> -n azureml --key <path-to-key> --cert <path-to-cert>Définissez l’entrée suivante. Dans l’entrée, indiquez le nom du secret dans la section
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: PrefixNotes
Remplacez
<domain>et<ingress-secret-name>dans la Ressource d’entrée ci-dessus par le domaine pointant vers le LoadBalancer de Nginx ingress controller/Application Gateway et le nom de votre secret. Stockez la ressource d’entrée ci-dessus dans un nom de fichiering-azureml-fe-tls.yaml.Déployez ing-azureml-fe-tls.yaml en exécutant
kubectl apply -f ing-azureml-fe-tls.yamlVérifiez l’état du déploiement dans le journal du contrôleur d’entrée.
L’application
azureml-feest désormais disponible sur HTTPS. Vous pouvez le vérifier en accédant à l’adresse LoadBalancer publique de Nginx Ingress Controller.Créez un travail d’inférence et appelez.
Notes
Remplacez le protocole et l’IP dans scoring_uri par https et le domaine pointant vers LoadBalancer de Nginx Ingress Controller ou d’Application Gateway avant d’appeler.
Utiliser un modèle ARM pour déployer l’extension
L’extension sur un cluster managé peut être déployée avec un modèle ARM. Vous trouverez un exemple de modèle dans deployextension.json, avec un fichier de paramètres de démonstration deployextension.parameters.json
Pour utiliser l’exemple de modèle de déploiement, modifiez le fichier de paramètres avec la valeur correcte, puis exécutez la commande suivante :
az deployment group create --name <ARM deployment name> --resource-group <resource group name> --template-file deployextension.json --parameters deployextension.parameters.json
Pour plus d’informations sur l’utilisation du modèle ARM, consultez la documentation sur les modèles ARM.
Notes de publication de l’extension AzureML
Notes
Les nouvelles fonctionnalités sont publiées toutes les deux semaines.
| Date | Version | Description de la version |
|---|---|---|
| 26 septembre 2024 | 1.1.64 | Correction des vulnérabilités. |
| 21 novembre 2023 | 1.1.39 | Correction des vulnérabilités. Message d’erreur affiné. Stabilité accrue pour l’API relayserver. |
| 1er novembre 2023 | 1.1.37 | Mettre à jour la version d’envoy du plan de données. |
| 11 octobre 2023 | 1.1.35 | Correctif de l’Image vulnérable. Correctifs de bogues. |
| 25 Août 2023 | 1.1.34 | Correctif de l’Image vulnérable. Retourner une erreur d’identité plus détaillée. Correctifs de bogues. |
| 18 juillet 2023 | 1.1.29 | Ajouter de nouvelles erreurs de l’opérateur d’identité. Résolution des bogues. |
| 4 juin 2023 | 1.1.28 | Améliorez la mise à l’échelle automatique pour gérer plusieurs pools de nœuds. Résolution des bogues. |
| 18 avril 2023 | 1.1.26 | Correctifs de bogues et correctifs de vulnérabilités. |
| 27 mars 2023 | 1.1.25 | Ajouter une limitation de travail Azure Machine Learning. Échec rapide du travail d’entraînement en cas d’échec de la configuration SSH. Réduisez l’intervalle d’extraction Prometheus à 30 s. Améliorez le message d’erreur pour l’inférence. Correctif de l’Image vulnérable. |
| 7 mars 2023 | 1.1.23 | Modifiez le type d’instance par défaut pour utiliser la mémoire 2Gi. Mettez à jour les configurations de métriques pour le scoring-fe qui ajoutent 15 scrape_interval. Ajouter une caractéristique de la ressource pour le sidecar mdc. Correctif de l’Image vulnérable. Résolution des bogues. |
| 14 février 2023 | 1.1.21 | Résolution des bogues. |
| 7 février 2023 | 1.1.19 | Améliorez le message retournant une erreur pour l’inférence. Mettez à jour le type d’instance par défaut pour utiliser la limite de mémoire de 2 Gi. Vérifiez l’intégrité du cluster quant à l’intégrité des pods, le quota de ressources, la version de Kubernetes et la version de l’extension. Résolution des bogues |
| 27 décembre 2022 | 1.1.17 | Déplacement de Fluent-bit de DaemonSet à sidecars. Ajout de la prise en charge de MDC. Amélioration des messages d’erreur. Prise en charge des travaux en mode cluster (windows, linux). Résolution des bogues |
| 29 novembre 2022 | 1.1.16 | Ajout de la validation du type d’instance par le nouveau CRD. Prise en charge de la tolérance. Raccourcissement du nom SVC. Cœur-heure des charges de travail. Résolutions de plusieurs bogues et améliorations. |
| 13 septembre 2022 | 1.1.10 | Corrections de bogues. |
| 29 août 2022 | 1.1.9 | Amélioration de la logique de contrôle d’intégrité. Corrections de bogues. |
| 23 juin 2022 | 1.1.6 | Corrections de bogues. |
| 15 juin 2022 | 1.1.5 | Mise à jour de l’entraînement pour utiliser le nouveau runtime commun dans le cadre de l’exécution des travaux. Suppression de l’utilisation d’Azure Relay pour l’extension AKS. Suppression de l’utilisation de Service Bus dans l’extension. Mise à jour de l’utilisation du contexte de sécurité. Mise à jour de l’inférence azureml-fe vers v2. Mise à jour de l’utilisation de Volcano en tant que planificateur de travaux d’entraînement. Corrections de bogues. |
| 14 octobre 2021 | 1.0.37 | Prise en charge du montage de volumes PV/PVC dans le travail d’entraînement AMLArc. |
| 16 septembre 2021 | 1.0.29 | Nouvelles régions disponibles : WestUS, CentralUS, NorthCentralUS, KoreaCentral. Extensibilité de la file d’attente des travaux. Consultez les détails de la file d’attente des travaux dans l’interface Studio de l’espace de travail Azure Machine Learning. Stratégie de suppression automatique. Prise en charge de max_run_duration_seconds dans ScriptRunConfig. Le système tente d’annuler automatiquement l’exécution si elle a duré plus longtemps que la valeur définie. Amélioration des performances de la prise en charge de la mise à l’échelle automatique des clusters. Déploiement de l’agent Arc et de l’extension ML à partir du registre de conteneurs local. |
| 24 août 2021 | 1.0.28 | Le type d’instance de calcul est pris en charge dans le travail YAML. Affectation d’une identité managée au calcul AMLArc. |
| 10 août 2021 | 1.0.20 | Prise en charge de la nouvelle distribution Kubernetes, K3S - Kubernetes léger. Déployez l’extension Azure Machine Learning sur votre cluster AKS sans vous connecter via Azure Arc. Azure Machine Learning (AutoML) via le kit SDK Python. Utilisez l’interface CLI 2.0 pour attacher le cluster Kubernetes à l’espace de travail Azure Machine Learning. Optimisation de l’utilisation des ressources processeur/mémoire des composants de l’extension Azure Machine Learning. |
| 2 juillet 2021 | 1.0.13 | Prise en charge des nouvelles distributions Kubernetes, d’OpenShift Kubernetes et de GKE (Google Kubernetes Engine). Prise en charge de la mise à l’échelle automatique. Si le cluster Kubernetes managé par l’utilisateur permet la mise à l’échelle automatique, il fait automatiquement l’objet d’un scale-out ou d’un scale-in en fonction du volume d’exécutions actives et de déploiements actifs. Amélioration des performances du lanceur de travaux, ce qui permet de réduire de manière considérable le temps d’exécution des travaux. |