HyperPod résolution des problèmes d'inférence - Amazon SageMaker AI
L'installation du module complémentaire d'inférence a échoué en raison de l'absence de pilotes CSIInférence : les définitions de ressources personnalisées sont manquantes lors du déploiement du modèleL'installation du module complémentaire d'inférence a échoué en raison de l'absence du gestionnaire de certificatsL'installation du module complémentaire d'inférence a échoué en raison de l'absence d'un contrôleur ALBL'installation du module complémentaire d'inférence a échoué en raison de l'absence d'un opérateur KEDAExpiration du délai de téléchargement des certificatsDéploiement du modèle bloqué en attenteRésolution des problèmes d'état d'échec du déploiement du modèleVérification de la progression du déploiement du modèleProblème d'autorisation VPC ENIProblème de relation de confiance entre IAMErreur du plugin GPU NVIDIA manquantL'opérateur d'inférence ne démarre pas

Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

HyperPod résolution des problèmes d'inférence

Ce guide de dépannage aborde les problèmes courants qui peuvent survenir lors du déploiement et de l'exploitation d'Amazon SageMaker HyperPod Inference. Ces problèmes concernent généralement la configuration du réseau VPC, les autorisations IAM, la gestion des ressources Kubernetes et les problèmes de connectivité des opérateurs qui peuvent empêcher le déploiement réussi du modèle ou entraîner l'échec ou le maintien des déploiements en attente.

Ce guide de dépannage utilise la terminologie suivante : les étapes de dépannage sont des procédures de diagnostic permettant d'identifier et d'étudier les problèmes, la résolution fournit les actions spécifiques pour résoudre les problèmes identifiés et la vérification confirme que la solution a fonctionné correctement.

Référence rapide : trouvez votre problème

Utilisez les catégories suivantes pour trouver rapidement la section de dépannage correspondant à votre problème :

L'installation du module complémentaire d'inférence a échoué en raison de l'absence de pilotes CSI

Problème : La création du module complémentaire d'opérateur d'inférence échoue car les dépendances du pilote CSI requises ne sont pas installées sur le cluster EKS.

Symptômes et diagnostic

Messages d'erreur :

Les erreurs suivantes apparaissent dans les journaux de création des modules complémentaires ou dans les journaux des opérateurs d'inférence :

S3 CSI driver not installed (missing CSIDriver s3.csi.aws.com). 
Please install the required CSI driver and see the troubleshooting guide for more information.

FSx CSI driver not installed (missing CSIDriver fsx.csi.aws.com). 
Please install the required CSI driver and see the troubleshooting guide for more information.

Étapes de diagnostic :

  1. Vérifiez si les pilotes CSI sont installés :

    # Check for S3 CSI driver
kubectl get csidriver s3.csi.aws.com
kubectl get pods -n kube-system | grep mountpoint

# Check for FSx CSI driver  
kubectl get csidriver fsx.csi.aws.com
kubectl get pods -n kube-system | grep fsx

  2. Vérifiez l'état du module complémentaire EKS :

    # List all add-ons
aws eks list-addons --cluster-name $EKS_CLUSTER_NAME --region $REGION

# Check specific CSI driver add-ons
aws eks describe-addon --cluster-name $EKS_CLUSTER_NAME --addon-name aws-mountpoint-s3-csi-driver --region $REGION 2>/dev/null || echo "S3 CSI driver not installed"
aws eks describe-addon --cluster-name $EKS_CLUSTER_NAME --addon-name aws-fsx-csi-driver --region $REGION 2>/dev/null || echo "FSx CSI driver not installed"

  3. Vérifiez l'état du module complémentaire de l'opérateur d'inférence :

    aws eks describe-addon \
    --cluster-name $EKS_CLUSTER_NAME \
    --addon-name amazon-sagemaker-hyperpod-inference \
    --region $REGION \
    --query "addon.{Status:status,Health:health,Issues:issues}" \
    --output json

Résolution

Étape 1 : Installation du pilote S3 CSI manquant

  1. Créez un rôle IAM pour le pilote S3 CSI (s'il n'est pas déjà créé) :

    # Set up service account role ARN (from installation steps)
export S3_CSI_ROLE_ARN=$(aws iam get-role --role-name $S3_CSI_ROLE_NAME --query 'Role.Arn' --output text 2>/dev/null || echo "Role not found")
echo "S3 CSI Role ARN: $S3_CSI_ROLE_ARN"

  2. Installez le module complémentaire du pilote S3 CSI :

    aws eks create-addon \
    --cluster-name $EKS_CLUSTER_NAME \
    --addon-name aws-mountpoint-s3-csi-driver \
    --addon-version v1.14.1-eksbuild.1 \
    --service-account-role-arn $S3_CSI_ROLE_ARN \
    --region $REGION

  3. Vérifiez l'installation du pilote S3 CSI :

    # Wait for add-on to be active
aws eks wait addon-active --cluster-name $EKS_CLUSTER_NAME --addon-name aws-mountpoint-s3-csi-driver --region $REGION

# Verify CSI driver is available
kubectl get csidriver s3.csi.aws.com
kubectl get pods -n kube-system | grep mountpoint

Étape 2 : Installation du pilote FSx CSI manquant

  1. Créez un rôle IAM pour le pilote FSx CSI (s'il n'est pas déjà créé) :

    # Set up service account role ARN (from installation steps)
export FSX_CSI_ROLE_ARN=$(aws iam get-role --role-name $FSX_CSI_ROLE_NAME --query 'Role.Arn' --output text 2>/dev/null || echo "Role not found")
echo "FSx CSI Role ARN: $FSX_CSI_ROLE_ARN"

  2. Installez le module complémentaire du pilote FSx CSI :

    aws eks create-addon \
    --cluster-name $EKS_CLUSTER_NAME \
    --addon-name aws-fsx-csi-driver \
    --addon-version v1.6.0-eksbuild.1 \
    --service-account-role-arn $FSX_CSI_ROLE_ARN \
    --region $REGION

# Wait for add-on to be active
aws eks wait addon-active --cluster-name $EKS_CLUSTER_NAME --addon-name aws-fsx-csi-driver --region $REGION

# Verify FSx CSI driver is running
kubectl get pods -n kube-system | grep fsx

Vérifier toutes les dépendances

Après avoir installé les dépendances manquantes, vérifiez qu'elles fonctionnent correctement avant de réessayer l'installation de l'opérateur d'inférence :

# Check all required add-ons are active
aws eks describe-addon --cluster-name $EKS_CLUSTER_NAME --addon-name aws-mountpoint-s3-csi-driver --region $REGION
aws eks describe-addon --cluster-name $EKS_CLUSTER_NAME --addon-name aws-fsx-csi-driver --region $REGION
aws eks describe-addon --cluster-name $EKS_CLUSTER_NAME --addon-name metrics-server --region $REGION
aws eks describe-addon --cluster-name $EKS_CLUSTER_NAME --addon-name cert-manager --region $REGION

# Verify all pods are running
kubectl get pods -n kube-system | grep -E "(mountpoint|fsx|metrics-server)"
kubectl get pods -n cert-manager

Inférence : les définitions de ressources personnalisées sont manquantes lors du déploiement du modèle

Problème : les définitions de ressources personnalisées (CRDs) sont manquantes lorsque vous essayez de créer des déploiements de modèles. Ce problème se produit lorsque vous avez précédemment installé et supprimé le module complémentaire d'inférence sans nettoyer les déploiements de modèles dotés de finaliseurs.

Symptômes et diagnostic

Cause première :

Si vous supprimez le module complémentaire d'inférence sans supprimer au préalable tous les déploiements de modèles, les ressources personnalisées dotées de finaliseurs restent dans le cluster. Ces finaliseurs doivent être terminés avant que vous puissiez supprimer le. CRDs Le processus de suppression du module complémentaire n'attend pas la fin de la suppression du CRD, ce qui le CRDs maintient dans un état de terminaison et empêche de nouvelles installations.

Pour diagnostiquer ce problème

  1. Vérifiez s'ils CRDs existent.

    kubectl get crd | grep inference.sagemaker.aws.amazon.com

  2. Vérifiez les ressources personnalisées bloquées.

    # Check for JumpStartModel resources
kubectl get jumpstartmodels -A

# Check for InferenceEndpointConfig resources
kubectl get inferenceendpointconfigs -A

  3. Inspectez les finaliseurs sur les ressources bloquées.

    # Example for a specific JumpStartModel
kubectl get jumpstartmodels <model-name> -n <namespace> -o jsonpath='{.metadata.finalizers}'

# Example for a specific InferenceEndpointConfig
kubectl get inferenceendpointconfigs <config-name> -n <namespace> -o jsonpath='{.metadata.finalizers}'

Résolution

Supprimez manuellement les finaliseurs de tous les déploiements de modèles qui n'ont pas été supprimés lorsque vous avez supprimé le module complémentaire d'inférence. Procédez comme suit pour chaque ressource personnalisée bloquée.

Pour supprimer les finaliseurs des ressources JumpStartModel

  1. Répertoriez toutes les JumpStartModel ressources dans tous les espaces de noms.

    kubectl get jumpstartmodels -A

  2. Pour chaque JumpStartModel ressource, supprimez les finaliseurs en appliquant un correctif à la ressource pour définir metadata.finalizers sur un tableau vide.

    kubectl patch jumpstartmodels <model-name> -n <namespace> -p '{"metadata":{"finalizers":[]}}' --type=merge

    L'exemple suivant montre comment appliquer un correctif à une ressource nommée kv-l1-only.

    kubectl patch jumpstartmodels kv-l1-only -n default -p '{"metadata":{"finalizers":[]}}' --type=merge

  3. Vérifiez que l'instance du modèle est supprimée.

    kubectl get jumpstartmodels -A

    Lorsque toutes les ressources sont nettoyées, vous devriez voir le résultat suivant.

    Error from server (NotFound): Unable to list "inference.sagemaker.aws.amazon.com/v1, Resource=jumpstartmodels": the server could not find the requested resource (get jumpstartmodels.inference.sagemaker.aws.amazon.com)

  4. Vérifiez que le JumpStartModel CRD est retiré.

    kubectl get crd | grep jumpstartmodels.inference.sagemaker.aws.amazon.com

    Si le CRD est correctement supprimé, cette commande ne renvoie aucune sortie.

Pour supprimer les finaliseurs des ressources InferenceEndpointConfig

  1. Répertoriez toutes les InferenceEndpointConfig ressources dans tous les espaces de noms.

    kubectl get inferenceendpointconfigs -A

  2. Pour chaque InferenceEndpointConfig ressource, supprimez les finaliseurs.

    kubectl patch inferenceendpointconfigs <config-name> -n <namespace> -p '{"metadata":{"finalizers":[]}}' --type=merge

    L'exemple suivant montre comment appliquer un correctif à une ressource nommée my-inference-config.

    kubectl patch inferenceendpointconfigs my-inference-config -n default -p '{"metadata":{"finalizers":[]}}' --type=merge

  3. Vérifiez que l'instance de configuration est supprimée.

    kubectl get inferenceendpointconfigs -A

    Lorsque toutes les ressources sont nettoyées, vous devriez voir le résultat suivant.

    Error from server (NotFound): Unable to list "inference.sagemaker.aws.amazon.com/v1, Resource=inferenceendpointconfigs": the server could not find the requested resource (get inferenceendpointconfigs.inference.sagemaker.aws.amazon.com)

  4. Vérifiez que le InferenceEndpointConfig CRD est retiré.

    kubectl get crd | grep inferenceendpointconfigs.inference.sagemaker.aws.amazon.com

    Si le CRD est correctement supprimé, cette commande ne renvoie aucune sortie.

Pour réinstaller le module complémentaire d'inférence

Après avoir nettoyé toutes les ressources bloquées et vérifié qu' CRDs elles sont supprimées, réinstallez le module complémentaire d'inférence. Pour de plus amples informations, veuillez consulter Installation de l'opérateur d'inférence avec le module complémentaire EKS.

Vérification

  1. Vérifiez que le module complémentaire d'inférence est correctement installé.

    aws eks describe-addon \
    --cluster-name $EKS_CLUSTER_NAME \
    --addon-name amazon-sagemaker-hyperpod-inference \
    --region $REGION \
    --query "addon.{Status:status,Health:health}" \
    --output table

    Le statut doit être ACTIF et la santé doit être SAINE.

  2. Vérifiez qu' CRDs ils sont correctement installés.

    kubectl get crd | grep inference.sagemaker.aws.amazon.com

    Vous devriez voir les informations relatives à l'inférence CRDs répertoriées dans la sortie.

  3. Testez la création d'un nouveau modèle de déploiement pour confirmer que le problème est résolu.

    # Create a test deployment using your preferred method
kubectl apply -f <your-model-deployment.yaml>

Prévention

Pour éviter ce problème, effectuez les étapes suivantes avant de désinstaller le module complémentaire d'inférence.

  1. Supprimez tous les déploiements de modèles.

    # Delete all JumpStartModel resources
kubectl delete jumpstartmodels --all -A

# Delete all InferenceEndpointConfig resources
kubectl delete inferenceendpointconfigs --all -A

# Wait for all resources to be fully deleted
kubectl get jumpstartmodels -A
kubectl get inferenceendpointconfigs -A

  2. Vérifiez que toutes les ressources personnalisées sont supprimées.

  3. Après avoir confirmé que toutes les ressources sont nettoyées, supprimez le module complémentaire d'inférence.

L'installation du module complémentaire d'inférence a échoué en raison de l'absence du gestionnaire de certificats

Problème : La création du module complémentaire d'opérateur d'inférence échoue car le module complémentaire EKS de cert-manager n'est pas installé, ce qui entraîne l'absence de définitions de ressources personnalisées (). CRDs

Symptômes et diagnostic

Messages d'erreur :

Les erreurs suivantes apparaissent dans les journaux de création des modules complémentaires ou dans les journaux des opérateurs d'inférence :

Missing required CRD: certificaterequests.cert-manager.io. 
The cert-manager add-on is not installed. Please install cert-manager and see the troubleshooting guide for more information.

Étapes de diagnostic :

  1. Vérifiez si cert-manager est installé :

    # Check for cert-manager CRDs
kubectl get crd | grep cert-manager
kubectl get pods -n cert-manager

# Check EKS add-on status
aws eks describe-addon --cluster-name $EKS_CLUSTER_NAME --addon-name cert-manager --region $REGION 2>/dev/null || echo "Cert-manager not installed"

  2. Vérifiez l'état du module complémentaire de l'opérateur d'inférence :

    aws eks describe-addon \
    --cluster-name $EKS_CLUSTER_NAME \
    --addon-name amazon-sagemaker-hyperpod-inference \
    --region $REGION \
    --query "addon.{Status:status,Health:health,Issues:issues}" \
    --output json

Résolution

Étape 1 : Installation du module complémentaire cert-manager

  1. Installez le module complémentaire EKS cert-manager :

    aws eks create-addon \
    --cluster-name $EKS_CLUSTER_NAME \
    --addon-name cert-manager \
    --addon-version v1.18.2-eksbuild.2 \
    --region $REGION

  2. Vérifiez l'installation du gestionnaire de certificats :

    # Wait for add-on to be active
aws eks wait addon-active --cluster-name $EKS_CLUSTER_NAME --addon-name cert-manager --region $REGION

# Verify cert-manager pods are running
kubectl get pods -n cert-manager

# Verify CRDs are installed
kubectl get crd | grep cert-manager | wc -l
# Expected: Should show multiple cert-manager CRDs

Étape 2 : Réessayer d'installer l'opérateur d'inférence

  1. Une fois le gestionnaire de certificats installé, réessayez d'installer l'opérateur d'inférence :

    # Delete the failed add-on if it exists
aws eks delete-addon \
    --cluster-name $EKS_CLUSTER_NAME \
    --addon-name amazon-sagemaker-hyperpod-inference \
    --region $REGION 2>/dev/null || echo "Add-on not found, proceeding with installation"

# Wait for deletion to complete
sleep 30

# Reinstall the inference operator add-on
aws eks create-addon \
    --cluster-name $EKS_CLUSTER_NAME \
    --addon-name amazon-sagemaker-hyperpod-inference \
    --addon-version v1.0.0-eksbuild.1 \
    --configuration-values file://addon-config.json \
    --region $REGION

  2. Surveillez l'installation :

    # Check installation status
aws eks describe-addon \
    --cluster-name $EKS_CLUSTER_NAME \
    --addon-name amazon-sagemaker-hyperpod-inference \
    --region $REGION \
    --query "addon.{Status:status,Health:health}" \
    --output table

# Verify inference operator pods are running
kubectl get pods -n hyperpod-inference-system

L'installation du module complémentaire d'inférence a échoué en raison de l'absence d'un contrôleur ALB

Problème : La création du module complémentaire d'opérateur d'inférence échoue car le AWS Load Balancer Controller n'est pas installé ou n'est pas correctement configuré pour le module complémentaire d'inférence.

Symptômes et diagnostic

Messages d'erreur :

Les erreurs suivantes apparaissent dans les journaux de création des modules complémentaires ou dans les journaux des opérateurs d'inférence :

ALB Controller not installed (missing aws-load-balancer-controller pods). 
Please install the Application Load Balancer Controller and see the troubleshooting guide for more information.

Étapes de diagnostic :

  1. Vérifiez si le contrôleur ALB est installé :

    # Check for ALB Controller pods
kubectl get pods -n kube-system | grep aws-load-balancer-controller
kubectl get pods -n hyperpod-inference-system | grep aws-load-balancer-controller

# Check ALB Controller service account
kubectl get serviceaccount aws-load-balancer-controller -n kube-system 2>/dev/null || echo "ALB Controller service account not found"
kubectl get serviceaccount aws-load-balancer-controller -n hyperpod-inference-system 2>/dev/null || echo "ALB Controller service account not found in inference namespace"

  2. Vérifiez la configuration du module complémentaire de l'opérateur d'inférence :

    aws eks describe-addon \
    --cluster-name $EKS_CLUSTER_NAME \
    --addon-name amazon-sagemaker-hyperpod-inference \
    --region $REGION \
    --query "addon.{Status:status,Health:health,ConfigurationValues:configurationValues}" \
    --output json

Résolution

Choisissez l'une des options suivantes en fonction de votre configuration :

Option 1 : laisser le module complémentaire d'inférence installer le contrôleur ALB (recommandé)

  • Assurez-vous que le rôle ALB est créé et correctement configuré dans la configuration de votre module complémentaire :

    # Verify ALB role exists
export ALB_ROLE_ARN=$(aws iam get-role --role-name alb-role --query 'Role.Arn' --output text 2>/dev/null || echo "Role not found")
echo "ALB Role ARN: $ALB_ROLE_ARN"

# Update your addon-config.json to enable ALB
cat > addon-config.json << EOF
{
  "executionRoleArn": "$EXECUTION_ROLE_ARN",
  "tlsCertificateS3Bucket": "$BUCKET_NAME",
  "hyperpodClusterArn": "$HYPERPOD_CLUSTER_ARN",
  "alb": {
    "enabled": true,
    "serviceAccount": {
      "create": true,
      "roleArn": "$ALB_ROLE_ARN"
    }
  },
  "keda": {
    "auth": {
      "aws": {
        "irsa": {
          "roleArn": "$KEDA_ROLE_ARN"
        }
      }
    }
  }
}
EOF

Option 2 : utiliser l'installation existante du contrôleur ALB

  • Si ALB Controller est déjà installé, configurez le module complémentaire pour utiliser l'installation existante :

    # Update your addon-config.json to disable ALB installation
cat > addon-config.json << EOF
{
  "executionRoleArn": "$EXECUTION_ROLE_ARN",
  "tlsCertificateS3Bucket": "$BUCKET_NAME",
  "hyperpodClusterArn": "$HYPERPOD_CLUSTER_ARN",
  "alb": {
    "enabled": false
  },
  "keda": {
    "auth": {
      "aws": {
        "irsa": {
          "roleArn": "$KEDA_ROLE_ARN"
        }
      }
    }
  }
}
EOF

Étape 3 : Réessayer d'installer l'opérateur d'inférence

  1. Réinstallez le module complémentaire d'opérateur d'inférence avec la configuration mise à jour :

    # Delete the failed add-on if it exists
aws eks delete-addon \
    --cluster-name $EKS_CLUSTER_NAME \
    --addon-name amazon-sagemaker-hyperpod-inference \
    --region $REGION 2>/dev/null || echo "Add-on not found, proceeding with installation"

# Wait for deletion to complete
sleep 30

# Reinstall with updated configuration
aws eks create-addon \
    --cluster-name $EKS_CLUSTER_NAME \
    --addon-name amazon-sagemaker-hyperpod-inference \
    --addon-version v1.0.0-eksbuild.1 \
    --configuration-values file://addon-config.json \
    --region $REGION

  2. Vérifiez que le contrôleur ALB fonctionne :

    # Check ALB Controller pods
kubectl get pods -n hyperpod-inference-system | grep aws-load-balancer-controller
kubectl get pods -n kube-system | grep aws-load-balancer-controller

# Check service account annotations
kubectl describe serviceaccount aws-load-balancer-controller -n hyperpod-inference-system 2>/dev/null
kubectl describe serviceaccount aws-load-balancer-controller -n kube-system 2>/dev/null

L'installation du module complémentaire d'inférence a échoué en raison de l'absence d'un opérateur KEDA

Problème : La création du module complémentaire d'opérateur d'inférence échoue car l'opérateur KEDA (Kubernetes Event Driven Autoscaler) n'est pas installé ou n'est pas correctement configuré pour le module complémentaire d'inférence.

Symptômes et diagnostic

Messages d'erreur :

Les erreurs suivantes apparaissent dans les journaux de création des modules complémentaires ou dans les journaux des opérateurs d'inférence :

KEDA operator not installed (missing keda-operator pods). 
KEDA can be installed separately in any namespace or via the Inference addon.

Étapes de diagnostic :

  1. Vérifiez si l'opérateur KEDA est installé :

    # Check for KEDA operator pods in common namespaces
kubectl get pods -n keda-system | grep keda-operator 2>/dev/null || echo "KEDA not found in keda-system namespace"
kubectl get pods -n kube-system | grep keda-operator 2>/dev/null || echo "KEDA not found in kube-system namespace"
kubectl get pods -n hyperpod-inference-system | grep keda-operator 2>/dev/null || echo "KEDA not found in inference namespace"

# Check for KEDA CRDs
kubectl get crd | grep keda 2>/dev/null || echo "KEDA CRDs not found"

# Check KEDA service account
kubectl get serviceaccount keda-operator -A 2>/dev/null || echo "KEDA service account not found"

  2. Vérifiez la configuration du module complémentaire de l'opérateur d'inférence :

    aws eks describe-addon \
    --cluster-name $EKS_CLUSTER_NAME \
    --addon-name amazon-sagemaker-hyperpod-inference \
    --region $REGION \
    --query "addon.{Status:status,Health:health,ConfigurationValues:configurationValues}" \
    --output json

Résolution

Choisissez l'une des options suivantes en fonction de votre configuration :

Option 1 : laisser le module complémentaire d'inférence installer KEDA (recommandé)

  • Assurez-vous que le rôle KEDA est créé et correctement configuré dans la configuration de votre module complémentaire :

    # Verify KEDA role exists
export KEDA_ROLE_ARN=$(aws iam get-role --role-name keda-operator-role --query 'Role.Arn' --output text 2>/dev/null || echo "Role not found")
echo "KEDA Role ARN: $KEDA_ROLE_ARN"

# Update your addon-config.json to enable KEDA
cat > addon-config.json << EOF
{
  "executionRoleArn": "$EXECUTION_ROLE_ARN",
  "tlsCertificateS3Bucket": "$BUCKET_NAME",
  "hyperpodClusterArn": "$HYPERPOD_CLUSTER_ARN",
  "alb": {
    "serviceAccount": {
      "create": true,
      "roleArn": "$ALB_ROLE_ARN"
    }
  },
  "keda": {
    "enabled": true,
    "auth": {
      "aws": {
        "irsa": {
          "roleArn": "$KEDA_ROLE_ARN"
        }
      }
    }
  }
}
EOF

Option 2 : Utiliser l'installation KEDA existante

  • Si KEDA est déjà installé, configurez le module complémentaire pour utiliser l'installation existante :

    # Update your addon-config.json to disable KEDA installation
cat > addon-config.json << EOF
{
  "executionRoleArn": "$EXECUTION_ROLE_ARN",
  "tlsCertificateS3Bucket": "$BUCKET_NAME",
  "hyperpodClusterArn": "$HYPERPOD_CLUSTER_ARN",
  "alb": {
    "serviceAccount": {
      "create": true,
      "roleArn": "$ALB_ROLE_ARN"
    }
  },
  "keda": {
    "enabled": false
  }
}
EOF

Étape 3 : Réessayer d'installer l'opérateur d'inférence

  1. Réinstallez le module complémentaire d'opérateur d'inférence avec la configuration mise à jour :

    # Delete the failed add-on if it exists
aws eks delete-addon \
    --cluster-name $EKS_CLUSTER_NAME \
    --addon-name amazon-sagemaker-hyperpod-inference \
    --region $REGION 2>/dev/null || echo "Add-on not found, proceeding with installation"

# Wait for deletion to complete
sleep 30

# Reinstall with updated configuration
aws eks create-addon \
    --cluster-name $EKS_CLUSTER_NAME \
    --addon-name amazon-sagemaker-hyperpod-inference \
    --addon-version v1.0.0-eksbuild.1 \
    --configuration-values file://addon-config.json \
    --region $REGION

  2. Vérifiez que KEDA fonctionne :

    # Check KEDA pods
kubectl get pods -n hyperpod-inference-system | grep keda
kubectl get pods -n kube-system | grep keda
kubectl get pods -n keda-system | grep keda 2>/dev/null

# Check KEDA CRDs
kubectl get crd | grep scaledobjects
kubectl get crd | grep scaledjobs

# Check KEDA service account annotations
kubectl describe serviceaccount keda-operator -n hyperpod-inference-system 2>/dev/null
kubectl describe serviceaccount keda-operator -n kube-system 2>/dev/null
kubectl describe serviceaccount keda-operator -n keda-system 2>/dev/null

Expiration du délai de téléchargement des certificats

Lors du déploiement d'un point de terminaison SageMaker AI, le processus de création échoue en raison de l'impossibilité de télécharger le certificat de l'autorité de certification (CA) dans un environnement VPC. Pour connaître les étapes de configuration détaillées, reportez-vous au guide de l'administrateur.

Message d’erreur:

L'erreur suivante apparaît dans les CloudWatch journaux des terminaux SageMaker AI : 

Error downloading CA certificate: Connect timeout on endpoint URL: "https://****.s3.<REGION>.amazonaws.com/****/***.pem"

Cause première :

  • Ce problème se produit lorsque l'opérateur d'inférence ne peut pas accéder au certificat auto-signé dans Amazon S3 au sein de votre VPC

  • Une configuration correcte du point de terminaison Amazon S3 VPC est essentielle pour l'accès aux certificats

Résolution :

  1. Si vous ne disposez pas d'un point de terminaison VPC Amazon S3 :

    • Créez un point de terminaison Amazon S3 VPC en suivant la configuration décrite dans la section 5.3 du guide d'administration.

  2. Si vous possédez déjà un point de terminaison VPC Amazon S3 :

    • Assurez-vous que la table de routage du sous-réseau est configurée pour pointer vers le point de terminaison VPC (si vous utilisez un point de terminaison de passerelle) ou que le DNS privé est activé pour le point de terminaison de l'interface.

    • Le point de terminaison Amazon S3 VPC doit être similaire à la configuration mentionnée dans la section 5.3 Étape de création du point de terminaison

Déploiement du modèle bloqué en attente

Lors du déploiement d'un modèle, le déploiement reste dans l'état « En attente » pendant une période prolongée. Cela indique que l'opérateur d'inférence n'est pas en mesure de lancer le déploiement du modèle dans votre HyperPod cluster.

Composants concernés :

Lors d'un déploiement normal, l'opérateur d'inférence doit :

  • Déployer le modèle Pod

  • Création d'un équilibreur de charge

  • Créer un point de terminaison SageMaker AI

Étapes de résolution des problèmes :

  1. Vérifiez l'état du module de l'opérateur d'inférence :

    kubectl get pods -n hyperpod-inference-system

    Exemple de sortie attendue :

    NAME                                                           READY   STATUS    RESTARTS   AGE
hyperpod-inference-operator-controller-manager-65c49967f5-894fg   1/1     Running   0         6d13h

  2. Consultez les journaux des opérateurs d'inférence et examinez les journaux des opérateurs pour détecter les messages d'erreur :

    kubectl logs hyperpod-inference-operator-controller-manager-5b5cdd7757-txq8f -n hyperpod-inference-operator-system

Ce qu'il faut rechercher :

  • Messages d'erreur dans les journaux de l'opérateur

  • État du module de commande

  • Tout avertissement ou échec lié au déploiement

Note

Un déploiement sain doit dépasser l'état « En attente » dans un délai raisonnable. Si les problèmes persistent, consultez les journaux des opérateurs d'inférence pour détecter les messages d'erreur spécifiques afin d'en déterminer la cause première.

Résolution des problèmes d'état d'échec du déploiement du modèle

Lorsqu'un déploiement de modèle passe à l'état « Échec », l'échec peut se produire dans l'un des trois composants suivants :

  • Déploiement du Model Pod

  • Création d'un équilibreur de charge

  • SageMaker Création de points de terminaison AI

Étapes de résolution des problèmes :

  1. Vérifiez le statut de l'opérateur d'inférence :

    kubectl get pods -n hyperpod-inference-system

    Sortie attendue :

    NAME                                                           READY   STATUS    RESTARTS   AGE
hyperpod-inference-operator-controller-manager-65c49967f5-894fg   1/1     Running   0         6d13h

  2. Consultez les journaux des opérateurs :

    kubectl logs hyperpod-inference-operator-controller-manager-5b5cdd7757-txq8f -n hyperpod-inference-operator-system

Ce qu'il faut rechercher :

Les journaux de l'opérateur indiqueront quel composant a échoué :

  • Défaillances de déploiement du Model Pod

  • Problèmes de création d'un équilibreur de charge

  • SageMaker Erreurs de point de terminaison AI

Vérification de la progression du déploiement du modèle

Pour suivre la progression du déploiement de votre modèle et identifier les problèmes potentiels, vous pouvez utiliser les commandes kubectl pour vérifier l'état des différents composants. Cela permet de déterminer si le déploiement progresse normalement ou s'il a rencontré des problèmes lors de la création du module de modélisation, de la configuration de l'équilibreur de charge ou des phases de configuration des terminaux SageMaker AI.

Méthode 1 : vérifier l'état du JumpStart modèle

kubectl describe jumpstartmodel.inference.sagemaker.aws.amazon.com/<model-name> -n <namespace>

Indicateurs de statut clés à surveiller :

  1. Statut du déploiement

    • Rechercher Status.State : Devrait montrer DeploymentComplete

    • Vérifiez Status.Deployment Status.Available Replicas

    • Surveiller Status.Conditions la progression du déploiement

  2. SageMaker État du point de terminaison AI

    • Vérifiez Status.Endpoints.Sagemaker.State : Devrait s'afficher CreationCompleted

    • Vérifiez Status.Endpoints.Sagemaker.Endpoint Arn

  3. État du certificat TLS

    • Afficher les Status.Tls Certificate détails

    • Vérifiez l'expiration du certificat dans Last Cert Expiry Time

Méthode 2 : vérifier la configuration du point de terminaison d'inférence

kubectl describe inferenceendpointconfig.inference.sagemaker.aws.amazon.com/<deployment_name> -n <namespace>

Le statut commun stipule :

  • DeploymentInProgress: Phase de déploiement initiale

  • DeploymentComplete: Déploiement réussi

  • Failed: échec du déploiement

Note

Surveillez la section Événements pour détecter tout avertissement ou erreur. Vérifiez que le nombre de répliques correspond à la configuration attendue. Vérifiez que toutes les conditions sont réunies Status: True pour un déploiement sain.

Problème d'autorisation VPC ENI

SageMaker La création d'un point de terminaison AI échoue en raison d'autorisations insuffisantes pour créer des interfaces réseau dans un VPC.

Message d’erreur:

Please ensure that the execution role for variant AllTraffic has sufficient permissions for creating an endpoint variant within a VPC

Cause première :

Le rôle d'exécution de l'opérateur d'inférence ne dispose pas de l'autorisation Amazon EC2 requise pour créer des interfaces réseau (ENI) dans un VPC.

Résolution :

Ajoutez l'autorisation IAM suivante au rôle d'exécution de l'opérateur d'inférence :

{
    "Effect": "Allow",
    "Action": [
        "ec2:CreateNetworkInterfacePermission",
        "ec2:DeleteNetworkInterfacePermission"
     ],
    "Resource": "*"
}

Vérification :

Après avoir ajouté l'autorisation :

  1. Supprimer le point de terminaison défaillant (s'il existe)

  2. Réessayez de créer le point de terminaison

  3. Surveillez l'état du déploiement pour s'assurer qu'il est terminé avec succès

Note

Cette autorisation est essentielle pour les points de terminaison SageMaker AI exécutés en mode VPC. Assurez-vous que le rôle d'exécution dispose également de toutes les autres autorisations nécessaires liées au VPC.

Problème de relation de confiance entre IAM

HyperPod L'opérateur d'inférence ne démarre pas avec une AssumeRoleWithWebIdentity erreur STS, ce qui indique un problème de configuration de la relation de confiance IAM.

Message d’erreur:

failed to enable inference watcher for HyperPod cluster *****: operation error SageMaker: UpdateClusterInference, 
get identity: get credentials: failed to refresh cached credentials, failed to retrieve credentials, 
operation error STS: AssumeRoleWithWebIdentity, https response error StatusCode: 403, RequestID: ****, 
api error AccessDenied: Not authorized to perform sts:AssumeRoleWithWebIdentity

Résolution :

Mettez à jour la relation de confiance du rôle d'exécution IAM de l'opérateur d'inférence avec la configuration suivante.

Remplacez les espaces réservés suivants :

  • <ACCOUNT_ID>: votre identifiant AWS de compte

  • <REGION>: Votre AWS région

  • <OIDC_ID>: ID du fournisseur OIDC de votre cluster Amazon EKS

JSON
{
    "Version":"2012-10-17",		 	 	 
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
            "Federated": "arn:aws:iam::111122223333:oidc-provider/oidc.eks.us-east-2.amazonaws.com/id/<OIDC_ID>"
            },
            "Action": "sts:AssumeRoleWithWebIdentity",
            "Condition": {
                "StringLike": {
                    "oidc.eks.us-east-2.amazonaws.com/id/<OIDC_ID>:sub": "system:serviceaccount:<namespace>:<service-account-name>",
                    "oidc.eks.us-east-2.amazonaws.com/id/<OIDC_ID>:aud": "sts.amazonaws.com"
                }
            }
        },
        {
            "Effect": "Allow",
            "Principal": {
                "Service": [
                    "sagemaker.amazonaws.com"
                ]
            },
            "Action": "sts:AssumeRole"
        }
    ]
}

Vérification :

Après avoir mis à jour la relation de confiance :

  1. Vérifiez la configuration des rôles dans la console IAM

  2. Redémarrez l'opérateur d'inférence si nécessaire

  3. Surveillez les journaux des opérateurs pour un démarrage réussi

Erreur du plugin GPU NVIDIA manquant

Le déploiement du modèle échoue avec une erreur d'insuffisance du GPU malgré la disponibilité de nœuds GPU. Cela se produit lorsque le plug-in de périphérique NVIDIA n'est pas installé dans le HyperPod cluster.

Message d’erreur:

0/15 nodes are available: 10 node(s) didn't match Pod's node affinity/selector, 
5 Insufficient nvidia.com/gpu. preemption: 0/15 nodes are available: 
10 Preemption is not helpful for scheduling, 5 No preemption victims found for incoming pod.

Cause première :

  • Kubernetes ne peut pas détecter les ressources GPU sans le plug-in pour appareil NVIDIA

  • Cela entraîne des échecs de planification pour les charges de travail du GPU

Résolution :

Installez le plug-in GPU NVIDIA en exécutant :

kubectl create -f https://raw.githubusercontent.com/NVIDIA/k8s-device-plugin/refs/tags/v0.17.1/deployments/static/nvidia-device-plugin.yml

Étapes de vérification :

  1. Vérifiez l'état du déploiement du plugin :

    kubectl get pods -n kube-system | grep nvidia-device-plugin

  2. Vérifiez que les ressources du GPU sont désormais visibles :

    kubectl get nodes -o=custom-columns=NAME:.metadata.name,GPU:.status.allocatable.nvidia\\.com/gpu

  3. Réessayer le déploiement du modèle

Note

Assurez-vous que les pilotes NVIDIA sont installés sur les nœuds GPU. L'installation du plugin s'effectue une seule fois par cluster. L'installation peut nécessiter des privilèges d'administrateur du cluster.

L'opérateur d'inférence ne démarre pas

Le module de l'opérateur d'inférence n'a pas pu démarrer et est à l'origine du message d'erreur suivant. Cette erreur est due à la politique d'autorisation selon laquelle le rôle d'exécution de l'opérateur n'est pas autorisé à exécutersts:AssumeRoleWithWebIdentity. De ce fait, la partie opérateur exécutée sur le plan de commande n'est pas démarrée.

Message d’erreur:

Warning Unhealthy 5m46s (x22 over 49m) kubelet Startup probe failed: Get "http://10.1.100.59:8081/healthz": context deadline exceeded (Client.Timeout exceeded while awaiting headers)

Cause première :

  • La politique d'autorisation du rôle d'exécution de l'opérateur d'inférence n'est pas définie pour accéder au jeton d'autorisation pour les ressources.

Résolution :

Définissez la politique suivante concernant le rôle d'exécution de EXECUTION_ROLE_ARN pour l'opérateur d' HyperPod inférence :

HyperpodInferenceAccessPolicy-ml-cluster to include all resources
JSON
{
    "Version":"2012-10-17",		 	 	 
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "s3:ListBucket",
                "s3:PutObject",
                "s3:GetObject",
                "s3:DeleteObject"
            ],
            "Resource": "*"
        },
        {
            "Effect": "Allow",
            "Action": [
                "ecr:GetAuthorizationToken"
            ],
            "Resource": "*"
        }
    ]
}

Étapes de vérification :

  1. Modifiez la stratégie.

  2. Arrêtez le module de l'opérateur d' HyperPod inférence.

  3. Le pod sera redémarré sans aucune exception.