Dépannage

Découvrez les étapes de dépannage qui pourraient vous être utiles si vous rencontrez des problèmes avec Migrate for Anthos 1.7.5.

Exécuter des commandes shell sur votre conteneur

Vous pouvez accéder à un conteneur via une commande shell bash ou via PowerShell à l'aide de la commande kubectl exec.

Remarque : Dans les exemples ci-dessous, pour PowerShell, remplacez /bin/bash par cmd.exe, powershell.exe ou pwsh.exe selon votre version.

Exécutez kubectl describe pods pour rechercher le nom du pod auquel vous souhaitez vous connecter dans votre cluster.
Dans l'exemple suivant, la commande répertorie le pod suitecrm-0.
```
kubectl describe pods | grep Name

Name:               suitecrm-0
```
Exécutez les commandes d'interface système à l'aide de l'une des méthodes suivantes :
- Exécutez kubectl exec pour ouvrir une interface système de commande bash dans laquelle vous pouvez exécuter des commandes.
```
kubectl exec -it pod-name -- /bin/bash
```
  L'exemple suivant permet d'ouvrir une interface système dans le pod suitecrm-0 :
```
kubectl exec -it suitecrm-0 -- /bin/bash
```
- Utilisez kubectl exec pour exécuter directement des commandes.
```
kubectl exec -it pod-name -- /bin/bash -c "command(s)"
```
  L'exemple suivant répertorie le répertoire racine du pod suitecrm-0 :
```
kubectl exec -it suitecrm-0 -- /bin/bash -c "ls /"
```

Pour en savoir plus, consultez la documentation de Kubernetes.

Déboguer les ressources Kubernetes

Vous trouverez de l'aide sur les pages suivantes :

Si vous rencontrez un problème avec Google Kubernetes Engine, consultez la page Dépannage correspondante.
Si vous rencontrez un problème lié à votre cluster, consultez la section liée au dépannage des clusters dans la documentation de Kubernetes.
Si vous rencontrez un problème avec votre application, ses pods ou son objet contrôleur, consultez la section concernant le dépannage des applications.

L'erreur RESOURCE_OPERATION_RATE_EXCEEDED apparaît dans l'état de migration ou dans les journaux

L'erreur RESOURCE_OPERATION_RATE_EXCEEDED se produit lorsque la plate-forme source d'une migration est Compute Engine et que vous dépassez la limite d'instantanés de disque lors de la migration d'une VM Compute Engine.

Dans le cadre de la migration, Migrate for Anthos crée un instantané des images de disque à partir d'une VM exécutée sur la plate-forme source. Vous ne pouvez créer un instantané de disque qu'une fois toutes les 10 minutes (soit six fois par heure) pour une VM Compute Engine. Cette erreur indique que vous avez dépassé cette limite.

Pour éviter d'atteindre cette limite, nous vous recommandons de créer le cluster dans la même zone que la VM Compute Engine. Lorsque le cluster se trouve dans la même zone que la VM, Migrate for Anthos peut cloner le disque au lieu de créer un instantané, ce qui s'avère plus efficace et permet de contourner la limite d'instantanés.

Consultez les pages suivantes :

Pour en savoir plus sur la création d'un cluster, consultez la page Configurer un cluster de traitement sur Google Cloud pour les charges de travail Windows.
Pour en savoir plus sur la limite, consultez la section Créer des instantanés fréquents de manière efficace.

Échec de l'installation d'un appareil répertorié dans /etc/fstab

Par défaut, le système analyse /etc/fstab et installe tous les appareils répertoriés sur les points d'installation requis. Si un appareil n'est pas reconnu ou n'est pas installé, le pod de la charge de travail reste indisponible.

Prenons l'exemple d'une VM source Linux dans Amazon EC2 qui possède un espace de disque éphémère dont la persistance n'est pas garantie. Ces disques ne sont pas transmis à la cible, ce qui entraîne l'échec de leur installation par le conteneur.

Dans ce cas, les messages suivants peuvent s'afficher :

Unable to locate resolve [X] fstab entries: …
Error: Failed mount -o defaults /dev/mapper/mpathe-part /rootfs/mnt/ephemeral

Pour contourner le problème, vous pouvez utiliser l'une des méthodes suivantes :

Modifiez /etc/fstab sur la VM Linux pour supprimer la commande d'installation de l'appareil.
Définissez la variable d'environnement HC_INIT_SKIP_MOUNT_FAILURES pour configurer le système afin qu'il ignore les échecs d'installation et poursuive l'opération.

Pour définir la variable d'environnement HC_INIT_SKIP_MOUNT_FAILURES :

Créez un ConfigMap dans l'espace de noms de la migration, v2k-system, sur le cluster de traitement de la migration. Par exemple, définissez le ConfigMap dans un fichier nommé jobs-config.yaml :
```
apiVersion: v1
kind: ConfigMap
metadata:
  name: jobs-config
  namespace: v2k-system
data:
  environment: |
    HC_INIT_SKIP_MOUNT_FAILURES = true
```
Appliquez le ConfigMap à ce cluster :
```
kubectl apply -f jobs-config.yaml
```
Pour afficher le ConfigMap, exécutez la commande suivante :
```
kubectl describe configmaps -n v2k-system
```
Modifiez le plan de migration pour ajouter le ConfigMap. Le plan de migration est le fichier YAML que vous avez généré lors de la création de la migration. Pour en savoir plus sur la modification du plan de migration, consultez la section Personnaliser un plan de migration.

Dans le plan de migration, modifiez la section configs pour ajouter le ConfigMap :
```
configs:
  jobsConfig:
    name: jobs-config
```
Enregistrez vos modifications, puis exécutez la migration comme décrit dans la section Exécuter une migration.

Anomalie avec les fonctionnalités du conteneur déployé en raison d'AppArmor

AppArmor permet à un administrateur système de limiter les fonctionnalités d'un conteneur déployé à l'aide de profils personnalisés. Dans certains cas, vous devrez peut-être appliquer un profil au conteneur déployé pour personnaliser ses fonctionnalités.

Pour personnaliser le profil AppArmor, procédez comme suit :

Créez le profil sur le cluster où vous déployez le conteneur migré. Pour en savoir plus, consultez la documentation concernant AppArmor.

Modifiez le fichier deployment_spec.yaml pour ajouter la variable d'environnement HC_APPARMOR_PROFILE avec le nom du profil AppArmor :

spec:
  containers:
  - image: gcr.io/my-project/my-container:v1.0.0
    name: my-container
    env:
    - name: HC_APPARMOR_PROFILE
      value: "apparmor-profile-name"
    securityContext:
      privileged: true
...

Pour en savoir plus sur la modification de deployment_spec.yaml, consultez la section Examiner les fichiers de déploiement générés.

Erreur FailedAttachVolume s'affiche dans l'état de migration ou les journaux (aperçu)

Si vous effectuez une migration à l'aide de clusters Anthos sur AWS, l'erreur FailedAttachVolume peut s'afficher dans l'état de migration ou les journaux, accompagnée du message suivant :

"The encrypted volume was unable to access the KMS master key"

Cette erreur signifie que votre VM AWS utilise un disque chiffré et que vous n'avez pas configuré l'accès correctement. Pour en savoir plus, consultez la section Conditions préalables à la migration de VM Linux à l'aide de clusters de traitement AWS.

Une erreur ProvisioningFailed s'affiche dans l'état de migration ou les journaux (aperçu)

Si vous effectuez une migration à l'aide de clusters Anthos sur AWS, l'erreur ProvisioningFailed peut s'afficher dans l'état de migration ou les journaux, accompagnée du message suivant :

"ProvisioningFailed - "Could not create volume V_ID"

Cette erreur peut se produire lorsque vous essayez d'exporter des données dans un nouveau volume chiffré, mais que le cluster n'a pas accès à la clé de chiffrement et n'a pas, par conséquent, créé le disque EBS. Pour en savoir plus, consultez la section Conditions préalables à la migration de VM Linux à l'aide de clusters de traitement AWS.

Je souhaite bénéficier d'une assistance personnalisée

L'assistance payante est disponible pour les clients effectuant des migrations avec Migrate for Anthos. Contactez-nous pour que nous puissions vous aider.

Fournir des informations à l'assistance Google Cloud

Le script Sysreport fournit une assistance pour Migrate for Anthos, ainsi que des informations sur la configuration de votre cluster pour accélérer la résolution des problèmes.

Vous pouvez accéder au script à partir de Cloud Shell.

Ouvrir Cloud Shell

Exécutez ensuite le script collect_sysreport.sh.

/google/migrate/anthos/collect_sysreport.sh [-n NAMESPACE] [-o OUTPUT_DIRECTORY] [-m MIGRATION]

Où :

[NAMESPACE] (facultatif) : espace de noms dans lequel Migrate for Anthos a été déployé (la valeur par défaut est v2k-system).
[OUTPUT_DIRECTORY] (facultatif) : chemin d'accès au répertoire dans lequel le rapport Sysreport sera enregistré (la valeur par défaut est $HOME).
[MIGRATION] (facultatif) : informations supplémentaires collectées pour une migration.

Le script crée anthos-migrate-logs.TIMESTAMP.tar.xz, que vous fournissez à l'assistance Google Cloud.

Par défaut, le script collecte les éléments suivants :

Les journaux provenant du contrôleur Migrate for Anthos CSI et des nœuds CSI
Le fichier syslog des hôtes du nœud Migrate for Anthos CSI
Journaux du contrôleur Migrate for Anthos.
Toutes les entités Migrate for Anthos du cluster.
Si vous spécifiez une migration, et que celle-ci utilise le dépôt d'artefacts par défaut, collectez les artefacts de la migration à partir de Cloud Storage ou du bucket S3.
Le résultat des commandes ci-dessous :
- kubectl cluster-info
- kubectl get nodes; kubectl describe node
- kubectl version
- kubectl top node
Les journaux de la charge de travail
Le résultat des commandes ci-dessous :
- ps aux
- netstat -tlnp
- iptables -t nat -L
- fstab
- kubectl get pod
- kubectl describe pod
- kubectl top pod --all-namespaces --containers
- kubectl cluster-info dump
- kubectl api-resources -o wide
- kubectl top pod --all-namespaces --containers
- kubectl api-resources -o wide
- kubectl get componentstatuses --all-namespaces
- kubectl get endpoints --all-namespaces
- kubectl get events --all-namespaces
- kubectl describe limits --all-namespaces
- kubectl get namespaces
- kubectl describe pvc --all-namespaces
- kubectl describe pv --all-namespaces
- kubectl describe quota --all-namespaces
- kubectl describe sa --all-namespaces
- kubectl describe services --all-namespaces
- kubectl describe services --all-namespaces
- kubectl get ingresses --all-namespaces
- kubectl describe networkpolicies --all-namespaces
- kubectl get podsecuritypolicies --all-namespaces
- kubectl get clusterrolebindings --all-namespaces
- kubectl describe storageclasses --all-namespaces
- kubectl describe volumeattachments --all-namespaces