Soluciona problemas

Obtén más información sobre los pasos de solución de problemas que pueden resultarte útiles si tienes dificultades para usar Migrate for Anthos 1.7.5.

Ejecuta comandos de shell en tu contenedor

Puedes acceder a un contenedor a través de una shell bash o a través de PowerShell mediante el comando kubectl exec.

Nota: En los siguientes ejemplos, para PowerShell reemplaza /bin/bash por cmd.exe, powershell.exe o pwsh.exe según tu versión.

Usa kubectl describe pods para encontrar el nombre del Pod en tu clúster al que deseas conectarte.
En el siguiente ejemplo, el comando muestra el pod suitecrm-0.
```
kubectl describe pods | grep Name

Name:               suitecrm-0
```
Ejecuta comandos de shell mediante uno de los siguientes métodos:
- Usa kubectl exec para abrir una shell de comandos de Bash en la que puedes ejecutar comandos.
```
kubectl exec -it pod-name -- /bin/bash
```
  En el siguiente ejemplo, se obtiene una shell para el pod de suitecrm-0:
```
kubectl exec -it suitecrm-0 -- /bin/bash
```
- Usa kubectl exec para ejecutar comandos directamente.
```
kubectl exec -it pod-name -- /bin/bash -c "command(s)"
```
  En el siguiente ejemplo, se muestra el directorio raíz del pod de suitecrm-0:
```
kubectl exec -it suitecrm-0 -- /bin/bash -c "ls /"
```

Para obtener más información, consulta la documentación de Kubernetes.

Depura los recursos de Kubernetes

Hay más ayuda disponible en las siguientes páginas:

Si tienes un problema con Google Kubernetes Engine, consulta la página Solución de problemas de GKE.
Si tienes un problema con el clúster, consulta Soluciona problemas de clústeres en la documentación de Kubernetes.
Si tienes un problema con la aplicación, sus pods o su objeto de controlador, consulta Soluciona problemas de aplicaciones.

El error RESOURCE_OPERATION_RATE_EXCEEDED aparece en los registros o el estado de migración

El error RESOURCE_OPERATION_RATE_EXCEEDED se produce cuando la plataforma de origen de una migración es Compute Engine y superas el límite de instantáneas de disco cuando se migra una VM de Compute Engine.

Como parte de la migración, Migrate for Anthos crea una instantánea de las imágenes de disco desde una VM que se ejecuta en la plataforma de origen. Solo puedes crear una instantánea de disco una vez cada 10 minutos, o 6 veces por hora, para una VM de Compute Engine. Este error indica que superaste ese límite.

Para evitar alcanzar este límite, te recomendamos que crees el clúster de migración en la misma zona que la VM de Compute Engine. Cuando el clúster está en la misma zona que la VM, Migrate for Anthos puede clonar el disco, en lugar de crear una instantánea, que es un proceso más eficiente y omite el límite de instantáneas.

Consulta los siguientes vínculos:

Para obtener más información sobre cómo crear un clúster, consulta Configura un clúster de procesamiento en Google Cloud para cargas de trabajo de Windows.
Crea instantáneas frecuentes de manera eficiente para obtener más información sobre el límite.

No se pudo activar un dispositivo indicado en /etc/fstab

De forma predeterminada, el sistema analiza /etc/fstab y activa todos los dispositivos enumerados en los puntos de activación requeridos. Si no se reconoce o no se activa un dispositivo, el pod de carga de trabajo no se alcanzará el estado Listo.

Por ejemplo, considera una VM de Linux de origen en Amazon EC2 que tiene un disco efímero donde no se garantiza la persistencia. Estos discos no se transmiten al destino, lo que provocará que el contenedor falle cuando se active.

Si esto ocurre, es posible que veas mensajes como los siguientes:

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

Puedes evitar esto si utilizas uno de los siguientes métodos:

Edita /etc/fstab en la VM de Linux para quitar el comando de activación del dispositivo.
Configura la variable de entorno HC_INIT_SKIP_MOUNT_FAILURES a fin de configurar el sistema para omitir las fallas de activación y continuar.

Para configurar la variable de entorno HC_INIT_SKIP_MOUNT_FAILURES, haz lo siguiente:

Crea un configmap en el espacio de nombres de migración, v2k-system, en el clúster de procesamiento de migración. Por ejemplo, define el configmap en un archivo llamado jobs-config.yaml:
```
apiVersion: v1
kind: ConfigMap
metadata:
  name: jobs-config
  namespace: v2k-system
data:
  environment: |
    HC_INIT_SKIP_MOUNT_FAILURES = true
```
Aplica el ConfigMap al clúster:
```
kubectl apply -f jobs-config.yaml
```
Para ver el configmap, usa el siguiente comando:
```
kubectl describe configmaps -n v2k-system
```
Edita el plan de migración para agregar el ConfigMap. El plan de migración es el archivo yaml que generaste cuando creaste la migración. Consulta Personaliza un plan de migración para obtener más información sobre cómo editar el plan de migración.

En el plan de migración, edita la sección configs para agregar el configmap:
```
configs:
  jobsConfig:
    name: jobs-config
```
Guarda tus ediciones y ejecuta la migración como se describe en Ejecuta una migración.

Falla en las capacidades del contenedor implementado debido a AppArmor

AppArmor permite que un administrador del sistema restrinja las capacidades de un contenedor implementado con el uso de perfiles personalizados. En algunos casos, es posible que debas aplicar un perfil a tu contenedor implementado para personalizar las capacidades.

Para personalizar el perfil de AppArmor, haz lo siguiente:

Crea el perfil en el clúster en el que vas a implementar el contenedor migrado. Consulta la documentación de AppArmor para obtener más información.
Edita el archivo deployment_spec.yaml para agregar la variable de entorno HC_APPARMOR_PROFILE con el nombre del perfil de 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
...
```
Consulta Revisa los archivos de implementación generados para obtener más información sobre cómo editar deployment_spec.yaml.

El error FailedAttachVolume aparece en los registros o el estado de migración (vista previa).

Si realizas una migración con clústeres de Anthos en AWS para realizar la migración, es posible que veas el error FailedAttachVolume en el estado de la migración o en los registros con el mensaje adjunto de lo siguiente:

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

Este error significa que tu VM de AWS usa un disco encriptado y no configuraste el acceso de forma correcta. Consulta Requisitos previos para migrar VM de Linux con clústeres de procesamiento de AWS para obtener más información.

El error de ProvisioningFailed aparece en los registros o estado de migración (vista previa).

Si realizas una migración con clústeres de Anthos en AWS para realizar la migración, es posible que veas el error ProvisioningFailed en el estado de la migración o en los registros con el mensaje adjunto de lo siguiente:

"ProvisioningFailed - "Could not create volume V_ID"

Este error puede ocurrir cuando intentas exportar datos a un volumen encriptado nuevo, pero el clúster no tiene acceso a la clave de encriptación y, por lo tanto, no crea el disco EBS. Consulta Requisitos previos para migrar VM de Linux con clústeres de procesamiento de AWS para obtener más información.

Deseo recibir asistencia personalizada

La asistencia paga está disponible para los clientes que migran con Migrate para Anthos. Comunícate para que podamos ayudarte.

Proporciona información al equipo de asistencia de Google Cloud

Sysreport proporciona compatibilidad con Migrate para Anthos con información sobre la configuración de tu clúster para agilizar la resolución de problemas.

Puedes acceder a la secuencia de comandos desde Cloud Shell.

Abrir Cloud Shell

A continuación, ejecuta la secuencia de comandos collect_sysreport.sh.

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

Aquí:

[NAMESPACE]: el espacio de nombres en el que se implementó Migrate for Anthos (la configuración predeterminada es v2k-system) (opcional).
[OUTPUT_DIRECTORY]: ruta de acceso al directorio en el que se guardará Sysreport (la configuración predeterminada es $HOME) (opcional).
[MIGRATION]: información adicional recopilada para una migración (opcional).

La secuencia de comandos crea anthos-migrate-logs.TIMESTAMP.tar.xz, que proporcionas al equipo de asistencia de Google Cloud.

De forma predeterminada, la secuencia de comandos recopila lo siguiente:

Registros desde el controlador Migrate para Anthos CSI y los nodos CSI
Syslog desde los hosts del nodo CSI de Migrate for Anthos
Registros del controlador de Migrate for Anthos.
Todas las entidades de Migrate for Anthos del clúster.
Si especificas una migración y la migración usa el repositorio de artefactos predeterminado, recopila los artefactos de migración desde Cloud Storage o S3.
El resultado de:
- kubectl cluster-info
- kubectl get nodes; kubectl describe node
- kubectl version
- kubectl top node
Los registros de la carga de trabajo.
El resultado de:
- 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