Résoudre les problèmes liés à l’extension Azure Machine Learning

Dans cet article, vous allez apprendre à résoudre les problèmes courants que vous pouvez rencontrer avec le déploiement d’extension Azure Machine Learning dans azure Kubernetes Service (AKS) ou Kubernetes avec Arc.

Comment l’extension Azure Machine Learning est-elle installée

L’extension Azure Machine Learning est publiée sous la forme d’un chart Helm et installée par Helm V3. Tous les composants de l’extension Azure Machine Learning sont installés dans l’espace de noms azureml. Vous pouvez utiliser les commandes suivantes pour vérifier l’état de l’extension.

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

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

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

Résoudre l’erreur de déploiement de l’extension Azure Machine Learning

Erreur : impossible de réutiliser un nom en cours d’utilisation

Cette erreur signifie que le nom d’extension que vous avez spécifié existe déjà. Si le nom est utilisé par l’extension Azure Machine Learning, vous devez attendre environ une heure avant de réessayer. Si le nom est utilisé par d’autres charts Helm, vous devez utiliser un autre nom. Exécutez helm list -Aa pour lister tous les charts Helm de votre cluster.

Erreur : une opération précédente pour le chart Helm est toujours en cours

Une fois l’opération inconnue terminée, vous devez attendre environ une heure avant de réessayer.

Erreur : impossible de créer du contenu dans l’espace de noms azureml, car il est en cours d’arrêt

Cette erreur se produit quand une opération de désinstallation n’est pas terminée et qu’une autre opération d’installation est déclenchée. Vous pouvez exécuter la commande az k8s-extension show pour vérifier l’état de provisionnement de l’extension et vous assurer que l’extension a été désinstallée avant d’effectuer d’autres actions.

Erreur : le téléchargement a échoué car le chemin du chart est introuvable

Cette erreur se produit quand vous spécifiez une version d’extension incorrecte. Vous devez vous assurer que la version spécifiée existe. Si vous souhaitez utiliser la dernière version, vous n’avez pas besoin de spécifier --version.

Erreur : impossible d’importer dans la version actuelle : métadonnées de propriété non valides

Cette erreur signifie qu’il existe un conflit entre les ressources de cluster existantes et l’extension Azure Machine Learning. Un message d’erreur complet peut ressembler au texte suivant :

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

Pour limiter les effets de ce problème, effectuez les étapes suivantes.

Vérifiez qui possède les ressources problématiques et si la ressource peut être supprimée ou modifiée.
Si la ressource est utilisée uniquement par l’extension Azure Machine Learning et peut être supprimée, vous pouvez ajouter manuellement des étiquettes pour atténuer le problème. En prenons pour exemple le message d’erreur précédent, vous pouvez exécuter des commandes comme suit :
```
kubectl label crd jobs.batch.volcano.sh "app.kubernetes.io/managed-by=Helm" 
kubectl annotate crd jobs.batch.volcano.sh "meta.helm.sh/release-namespace=azureml" "meta.helm.sh/release-name=<extension-name>"
```
En définissant les étiquettes et les annotations sur la ressource, helm gère la ressource détenue par l’extension Azure Machine Learning.
Quand la ressource est également utilisée par d’autres composants de votre cluster et ne peut pas être modifiée. Reportez-vous à Déployer l’extension Azure Machine Learning pour voir s’il existe un paramètre de configuration pour désactiver la ressource en conflit.

Contrôle d’intégrité de l’extension

Lorsque l’installation a échoué et qu’aucun des messages d’erreur précédents n’a été rencontré, vous pouvez utiliser l’outil de vérification d’intégrité intégré pour effectuer une analyse complète de l’extension. L’extension Azure Machine Learning contient une HealthCheck tâche pour vérifier la préparation de votre cluster lorsque vous essayez d’installer, de mettre à jour ou de supprimer l’extension. Le travail de contrôle d’intégrité génère un rapport, qui est enregistré dans un mappage de configuration nommé arcml-healthcheck dans l’espace de noms azureml. Les codes d’erreur et les solutions possibles pour le rapport sont listés dans Code d’erreur du contrôle d’intégrité.

Exécutez cette commande pour obtenir le rapport de contrôle d’intégrité :

kubectl describe configmap -n azureml arcml-healthcheck

La vérification d’intégrité est déclenchée chaque fois que vous installez, mettez à jour ou supprimez l’extension. La structure du rapport de contrôle d’intégrité présente plusieurs parties : pre-install, pre-rollback, pre-upgrade, et pre-delete.

Si l’installation de l’extension échoue, vous devez examiner pre-install et pre-delete.
Si la mise à jour de l’extension échoue, vous devez examiner pre-upgrade et pre-rollback.
Si la suppression de l’extension échoue, vous devez examiner pre-delete.

Quand vous demandez de l’aide, nous vous recommandons d’exécuter la commande suivante et de nous envoyer le fichier healthcheck.logs, car il peut nous faciliter la recherche du problème.

kubectl logs healthcheck -n azureml

Le pod d’opérateur d’extension dans l’espace de noms azure-arc/kube-system se bloque en raison de OOMKill

Ce problème se produit lorsque la taille du graphique Helm de l’extension est importante et qu’il existe plusieurs versions Helm sur le cluster. Pour vérifier l’historique Helm de l’extension Azure ML, utilisez les commandes suivantes :

# Check if there is a release of the Azure ML extension Helm chart installed on the cluster
# Note: The default namespace for the extension is usually 'azureml'. If you specified a different namespace during installation, replace 'azureml' with your namespace.
helm list -n azureml

# Get helm history 
# Note: <release-name> should be the name of your azure ml extension and can be retrieved from the output of the previous command
helm history -n <extension-namespace> azureml

Il existe une limite d’historique Helm de 10 révisions, mais cette limite s’applique uniquement aux révisions dans un état non temporaire. Si vous voyez plusieurs révisions dans un état de restauration en attente ou de mise à niveau en attente dans la sortie de l’historique Helm, exécutez le script ci-dessous pour nettoyer l’historique Helm sur le cluster :

#!/bin/bash

# Set release name and namespace
RELEASE_NAME=$1 # release-name is the name of the azure ml extension helm release 
NAMESPACE=$2 # namespace is the azure ml extension's namespace. Default value is azureml 

# Validate input
if [[ -z "$RELEASE_NAME" || -z "$NAMESPACE" ]]; then
    echo "Usage: $0 <release-name> <namespace>"
    exit 1
fi

echo "Fetching Helm history for release: $RELEASE_NAME in namespace: $NAMESPACE"

# Get stuck revisions (PENDING_ROLLBACK or PENDING_UPGRADE) using grep + awk for accurate parsing
STUCK_REVISIONS=$(helm history "$RELEASE_NAME" -n "$NAMESPACE" | grep 'pending-' | awk '{print $1}')

if [[ -z "$STUCK_REVISIONS" ]]; then
    echo "No stuck Helm revisions found. Nothing to delete."
    exit 0
fi

echo "Found stuck Helm revisions: $STUCK_REVISIONS"

# Loop through each stuck revision and delete the corresponding secret
for REVISION in $STUCK_REVISIONS; do
    SECRET_NAME="sh.helm.release.v1.${RELEASE_NAME}.v${REVISION}"
   
    echo "Deleting Helm history secret: $SECRET_NAME"
   
    kubectl delete secret -n "$NAMESPACE" "$SECRET_NAME" --ignore-not-found
done

echo "Cleanup complete. Verify with 'helm history $RELEASE_NAME -n $NAMESPACE'"

exit 0

Comment exécuter le script :

chmod +x delete_stuck_helm_secrets.sh

./delete_stuck_helm_secrets.sh <release-name> <extension-namespace>

Code d’erreur du contrôle d’intégrité

Ce tableau montre comment résoudre les codes d’erreur retournés par le rapport de contrôle d’intégrité.

Code d'erreur	Message d’erreur	Descriptif
E40001	LOAD_BALANCER_NOT_SUPPORT	L’équilibreur de charge n’est pas pris en charge dans votre cluster. Vous devez configurer l’équilibreur de charge dans votre cluster ou envisager de définir `inferenceRouterServiceType` sur `nodePort` ou `clusterIP`.
E40002	INSUFFICIENT_NODE	Vous avez activé `inferenceRouterHA`, ce qui nécessite au moins trois nœuds dans votre cluster. Désactivez la haute disponibilité si vous avez moins de trois nœuds.
E40003	INTERNAL_LOAD_BALANCER_NOT_SUPPORT	Actuellement, seul AKS prend en charge l’équilibreur de charge interne, et nous prenons uniquement en charge le type `azure`. Ne définissez pas `internalLoadBalancerProvider` si vous n’avez pas de cluster AKS.
E40007	Paramètre SSL non valide	Le certificat ou la clé SSL n’est pas valide. Le CNAME doit être compatible avec le certificat.
E45002	CONFLIT_PROMÉTHÉE	L’opérateur Prometheus installé est en conflit avec votre opérateur Prometheus existant. Pour plus d’informations, consultez Opérateur Prometheus.
E45003	BAD_NETWORK_CONNECTIVITY	Vous devez répondre à la configuration réseau nécessaire.
E45004	AZUREML_FE_ROLE_CONFLICT	L’extension Azure Machine Learning n’est pas prise en charge dans aks hérité. Pour installer l’extension Azure Machine Learning, vous devez supprimer les composants azureml-fe hérités.
E45005	AZUREML_FE_DEPLOYMENT_CONFLICT (Conflit de déploiement AzureML_FE)	L’extension Azure Machine Learning n’est pas prise en charge dans aks hérité. Pour installer l’extension Azure Machine Learning, vous devez exécuter la commande sous ce formulaire pour supprimer les composants azureml-fe hérités, plus de détails que vous pouvez consulter ici.

Commandes pour supprimer les composants azureml-fe hérités dans le cluster AKS :

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

Intégration des composants open source

L’extension Azure Machine Learning utilise certains composants open source, notamment l’opérateur Prometheus, le planificateur Volcano et l’exportateur DCGM. Si certains d’entre eux sont déjà installés sur le cluster Kubernetes, vous pouvez lire les sections suivantes pour intégrer vos composants existants à l’extension Azure Machine Learning.

Opérateur Prometheus

L’opérateur Prometheus est une infrastructure open source qui aide à créer un système de supervision des métriques dans Kubernetes. L’extension Azure Machine Learning utilise également l’opérateur Prometheus pour faciliter la supervision de l’utilisation des ressources des travaux.

Si l’opérateur Prometheus est installé dans le cluster par un autre service, vous pouvez spécifier installPromOp=false pour désactiver l’opérateur Prometheus dans l’extension Azure Machine Learning afin d’éviter un conflit entre deux opérateurs Prometheus. Dans ce cas, l’opérateur Prometheus existant gère toutes les instances Prometheus. Pour vous assurer que Prometheus fonctionne correctement, vous devez être attentif aux éléments suivants quand vous désactivez l’opérateur Prometheus dans l’extension Azure Machine Learning.

Vérifiez si Prometheus dans l’espace de noms azureml est géré par l’opérateur Prometheus. Dans certains scénarios, l’opérateur Prometheus est défini pour superviser uniquement certains espaces de noms spécifiques. Si tel est le cas, vérifiez que l’espace de noms azureml se trouve dans la liste d’autorisation. Pour plus d’informations, consultez les indicateurs de commande.
Vérifiez si kubelet-service est activé dans l’opérateur Prometheus. Kubelet-service contient tous les points de terminaison de kubelet. Pour plus d’informations, consultez les indicateurs de commande. Vous devez également vous assurer que kubelet-service a une étiquette k8s-app=kubelet.

Créez ServiceMonitor pour kubelet-service. Exécutez la commande suivante en remplaçant les variables :

cat << EOF | kubectl apply -f -
apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
  name: prom-kubelet
  namespace: azureml
  labels:
    release: "<extension-name>"     # Please replace to your Azure Machine Learning extension name
spec:
  endpoints:
  - port: https-metrics
    scheme: https
    path: /metrics/cadvisor
    honorLabels: true
    tlsConfig:
      caFile: /var/run/secrets/kubernetes.io/serviceaccount/ca.crt
      insecureSkipVerify: true
    bearerTokenFile: /var/run/secrets/kubernetes.io/serviceaccount/token
    relabelings:
    - sourceLabels:
      - __metrics_path__
      targetLabel: metrics_path
  jobLabel: k8s-app
  namespaceSelector:
    matchNames:
    - "<namespace-of-your-kubelet-service>"  # Please change this to the same namespace of your kubelet-service
  selector:
    matchLabels:
      k8s-app: kubelet    # Please make sure your kubelet-service has a label named k8s-app and it's value is kubelet

EOF

Exportateur DCGM

Dcgm-exporter est l’outil officiel recommandé par NVIDIA pour collecter les métriques GPU. Il est intégré à l’extension Azure Machine Learning. Toutefois, par défaut, dcgm-exporter n’est pas activé et aucune métrique GPU n’est collectée. Vous pouvez définir l’indicateur installDcgmExporter sur true pour l’activer. Comme il s’agit de l’outil officiel de NVIDIA, vous pouvez déjà l’avoir installé dans votre cluster GPU. Si tel est le cas, vous pouvez définir installDcgmExporter sur false et suivre les étapes pour intégrer votre dcgm-exporter à l’extension Azure Machine Learning. Notez également que dcgm-exporter permet à l’utilisateur de configurer les métriques à exposer. Pour l’extension Azure Machine Learning, assurez-vous que les mesures DCGM_FI_DEV_GPU_UTIL, DCGM_FI_DEV_FB_FREE et DCGM_FI_DEV_FB_USED sont exposées.

Vérifiez que l’extension Aureml et dcgm-exporter sont correctement installés. Dcgm-exporter peut être installé par le chart helm dcgm-exporter ou le chart helm gpu-operator

Vérifiez s’il existe un service pour dcgm-exporter. S’il n’en existe pas ou si vous ne savez pas comment vérifier, exécutez la commande suivante pour en créer un.

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

Vérifiez si le service à l’étape précédente est correctement défini.

kubectl -n <namespace-of-your-dcgm-exporter> port-forward service/dcgm-exporter-service 9400:9400
# run this command in a separate terminal. You will get a lot of dcgm metrics with this command.
curl http://127.0.0.1:9400/metrics

Configurez ServiceMonitor pour exposer le service dcgm-exporter à l’extension Azure Machine Learning. Exécutez la commande suivante ; cela prend effet en quelques minutes.

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

Planificateur volcano

Si la suite volcano est déjà installée sur votre cluster, vous pouvez définir installVolcano=false afin que l’extension n’installe pas le planificateur volcano. Le planificateur volcano et le contrôleur volcano sont requis pour la soumission et la planification des travaux d’entraînement.

La configuration du planificateur Volcano utilisée par l’extension Azure Machine Learning est la suivante :

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

Vous devez utiliser ce même paramètre de configuration et désactiver le webhook job/validate dans l’admission du volcan si votre version de volcan est inférieure à 1.6, afin que les charges de travail d’entraînement Azure Machine Learning puissent s’exécuter correctement.

Intégration du planificateur volcano prenant en charge l’autoscaler de cluster

Comme indiqué dans ce thread, le plug-in gang ne fonctionne pas bien avec l’autoscaler de cluster (CA) et également avec l’autoscaler de nœud dans AKS.

Si vous utilisez le volcano fourni avec l’extension Azure Machine Learning via la définition de installVolcano=true, l’extension aura une configuration de planificateur par défaut, qui configure le plug-in gang pour empêcher l’interblocage de travaux. Par conséquent, l’autoscaler de cluster dans le cluster AKS n’est pas pris en charge avec le volcano installé par extension.

Dans ce cas, si vous préférez que l’autoscaler de cluster AKS puisse fonctionner normalement, vous pouvez configurer ce paramètre volcanoScheduler.schedulerConfigMap via l’extension de mise à jour et lui spécifier une configuration personnalisée du planificateur volcano sans gang, par exemple :

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

Pour utiliser cette configuration dans votre cluster AKS, vous devez suivre les étapes suivantes :

Créez un fichier ConfigMap avec la configuration précédente dans l'espace de noms azureml. Cet espace de noms est généralement créé lorsque vous installez l’extension Azure Machine Learning.
Définissez volcanoScheduler.schedulerConfigMap=<configmap name> dans la configuration de l’extension pour appliquer ce fichier configmap. Et vous devez ignorer la validation des ressources lors de l’installation de l’extension en configurant amloperator.skipResourceValidation=true. Par exemple :
```
az k8s-extension update --name <extension-name> --config volcanoScheduler.schedulerConfigMap=<configmap name> amloperator.skipResourceValidation=true --cluster-type managedClusters --cluster-name <your-AKS-cluster-name> --resource-group <your-RG-name>
```

Remarque

Étant donné que le plug-in gang est supprimé, il est possible que l’interblocage se produise lorsque volcano planifie le travail.

Pour éviter cette situation, vous pouvez utiliser le même type d’instance dans les travaux.

L’utilisation d’une configuration de planificateur autre que la configuration par défaut fournie par l’extension Azure Machine Learning peut ne pas être entièrement prise en charge. Procédez avec prudence.

Vous devez désactiver le webhook job/validate dans l’admission du volcan si votre version de volcan est inférieure à 1,6.

Contrôleur Nginx d’entrée

L’installation de l’extension Azure Machine Learning est fournie avec une classe de contrôleur nginx d’entrée comme k8s.io/ingress-nginx par défaut. Si vous avez déjà un contrôleur nginx d’entrée dans votre cluster, vous devez utiliser une autre classe de contrôleur pour éviter l’échec de l’installation.

Deux options s'offrent à vous :

Remplacez votre classe de contrôleur existante par autre chose que k8s.io/ingress-nginx.
Créez ou mettez à jour notre extension Azure Machine Learning avec une classe de contrôleur personnalisée différente de la vôtre en suivant les exemples suivants.

Par exemple, pour créer l’extension avec une classe de contrôleur personnalisé :

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

Pour mettre à jour l’extension avec une classe de contrôleur personnalisé :

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

Le contrôleur d’entrée Nginx installé avec l’extension Azure Machine Learning se bloque en raison d’erreurs de mémoire insuffisante (OOM)

Symptôme

Le contrôleur d’entrée nginx installé avec l’extension Azure Machine Learning se bloque en raison d’erreurs de mémoire insuffisante (OOM), même en l’absence de charge de travail. Les journaux du contrôleur n’affichent aucune information utile pour diagnostiquer le problème.

Cause possible

Ce problème peut se produire si le contrôleur d’entrée nginx s’exécute sur un nœud avec de nombreuses UC. Par défaut, le contrôleur d’entrée nginx génère des processus de travail en fonction du nombre de processeurs, qui peuvent consommer plus de ressources et provoquer des erreurs OOM sur les nœuds avec davantage de processeurs. Il s’agit d’un problème connu signalé sur GitHub

Résolution

Pour résoudre ce problème, vous pouvez :

Ajustez le nombre de processus de travail en installant l’extension avec le paramètre nginxIngress.controllerConfig.worker-processes=8.
Augmentez la limite de mémoire en utilisant le paramètre nginxIngress.resources.controller.limits.memory=<new limit>.

Veillez à ajuster ces deux paramètres en fonction des spécifications de votre nœud et des exigences de charge de travail spécifiques pour optimiser efficacement vos charges de travail.

Étapes suivantes

Commentaires

Cette page a-t-elle été utile ?

Last updated on 2025-05-07