Solução de problemas

Saiba mais sobre as etapas principais para solucionar problemas que podem ocorrer ao usar o Migrate for Anthos 1.7.5.

Como executar comandos do shell no seu contêiner

É possível acessar um contêiner por meio de um shell bash ou do PowerShell usando o comando kubectl exec (em inglês).

Observação: nos exemplos abaixo, para o PowerShell, substitua /bin/bash por cmd.exe, powershell.exe ou pwsh.exe, de acordo com a versão.

Use kubectl describe pods para encontrar o nome do pod no cluster a que você quer se conectar.
No exemplo a seguir, o comando lista o pod "suitecrm-0".
```
kubectl describe pods | grep Name

Name:               suitecrm-0
```
Use um dos métodos a seguir para executar comandos de shell:
- Use kubectl exec para abrir um shell de comando bash para executar comandos.
```
kubectl exec -it pod-name -- /bin/bash
```
  No exemplo a seguir, você recebe um shell para o pod "suitecrm-0":
```
kubectl exec -it suitecrm-0 -- /bin/bash
```
- Use kubectl exec para executar comandos diretamente.
```
kubectl exec -it pod-name -- /bin/bash -c "command(s)"
```
  No exemplo a seguir, você lista o diretório raiz do pod "suitecrm-0":
```
kubectl exec -it suitecrm-0 -- /bin/bash -c "ls /"
```

Para mais informações, consulte a Documentação do Kubernetes (em inglês).

Como depurar recursos do Kubernetes

Você encontra mais ajuda nestas páginas:

Se você tiver um problema com o Google Kubernetes Engine, consulte a página de solução de problemas do GKE.
Se você tiver um problema relacionado ao cluster, consulte Como solucionar problemas de clusters (em inglês) na documentação do Kubernetes.
Se você tiver um problema com o aplicativo, os pods ou o objeto controlador, consulte Solução de problemas de aplicativos (em inglês).

O erro RESOURCE_OPERATION_RATE_EXCEEDED aparece no status ou nos registros de migração

O erro RESOURCE_OPERATION_RATE_EXCEEDED ocorre quando a plataforma de origem de uma migração é o Compute Engine e você excede o limite de snapshots de disco durante a migração de uma VM do Compute Engine.

Como parte da migração, o Migrate for Anthos cria um snapshot das imagens de disco de uma VM em execução na plataforma de origem. É possível criar um snapshot de disco no máximo uma vez a cada 10 minutos ou 6 vezes por hora para uma VM do Compute Engine. Esse erro indica que você excedeu esse limite.

Para evitar atingi-lo, recomendamos que você crie o cluster de migração na mesma zona da VM do Compute Engine. Quando o cluster está na mesma zona da VM, o Migrate for Anthos pode clonar o disco em vez de criar um snapshot, que é um processo mais eficiente e ignora o limite de snapshots.

Veja estes tópicos:

Como configurar um cluster de processamento nas cargas de trabalho do Google Cloud para Windows para saber mais sobre como criar um cluster.
Como criar snapshots frequentes com eficiência para saber mais sobre o limite.

Um dispositivo listado em /etc/fstab falha ao ser montado

Por padrão, o sistema analisa /etc/fstab e monta todos os dispositivos listados nos pontos de montagem necessários. Se um dispositivo não for reconhecido ou não for montado, o pod de carga de trabalho não chegará ao estado pronto.

Por exemplo, considere uma VM de origem no Linux no Amazon EC2 que tenha um disco temporário em que a persistência não seja garantida. Esses discos não são transmitidos para o destino, fazendo com que o contêiner falhe ao montá-lo.

Se isso acontecer, será possível ver mensagens como estas:

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

Para contornar esse problema:

edite /etc/fstab na VM do Linux para remover o comando de montagem do dispositivo;
ou defina a variável de ambiente HC_INIT_SKIP_MOUNT_FAILURES para configurar o sistema para ignorar falhas de montagem e continuar.

Para definir a variável de ambiente HC_INIT_SKIP_MOUNT_FAILURES:

crie um configmap no namespace de migração, v2k-system, no cluster de processamento de migração. Por exemplo, defina o configmap em um arquivo chamado jobs-config.yaml:
```
apiVersion: v1
kind: ConfigMap
metadata:
  name: jobs-config
  namespace: v2k-system
data:
  environment: |
    HC_INIT_SKIP_MOUNT_FAILURES = true
```
Aplique o configmap ao cluster:
```
kubectl apply -f jobs-config.yaml
```
Para visualizar o mapa de configuração, use este comando:
```
kubectl describe configmaps -n v2k-system
```
Edite o plano de migração para adicionar o configmap. O plano de migração é o arquivo yaml gerado quando você criou a migração. Consulte Como personalizar um plano de migração para mais informações sobre como editar esse plano.

No plano de migração, edite a seção configs para adicionar o configmap:
```
configs:
  jobsConfig:
    name: jobs-config
```
Salve suas edições e execute a migração conforme descrito em Como executar uma migração.

Falha nos recursos do contêiner implantado devido ao AppArmor

O AppArmor permite que um administrador do sistema restrinja os recursos de um contêiner implantado usando perfis personalizados. Em alguns casos, pode ser necessário aplicar um perfil ao contêiner implantado para personalizar os recursos dele.

Para personalizar o perfil do AppArmor:

Crie o perfil no cluster em que você está implantando o contêiner migrado. Consulte a documentação do AppArmor para mais informações.
Edite o arquivo deployment_spec.yaml para adicionar a variável de ambiente HC_APPARMOR_PROFILE com o nome do perfil do 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
...
```
Consulte Como revisar arquivos de implantação gerados para mais informações sobre como editar deployment_spec.yaml.

O erro FailedAttachVolume aparece no status ou nos registros de migração (visualização)

Se você estiver executando uma migração usando clusters do Anthos no AWS para executar a migração, poderá ver o erro FailedAttachVolume no status de migração ou nos registros com o mensagem de:

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

Esse erro significa que sua VM da AWS usa um disco criptografado e você não configurou o acesso corretamente. Consulte Pré-requisitos para migrar VMs do Linux usando clusters de processamento da AWS para mais informações.

O erro Provisioning aparece no status ou nos registros de migração (visualização)

Se você estiver executando uma migração usando clusters do Anthos no AWS para executar a migração, poderá ver o erro ProvisioningFailed no status de migração ou nos registros com o mensagem de:

"ProvisioningFailed - "Could not create volume V_ID"

Este erro pode ocorrer quando você tenta exportar dados para um novo volume criptografado, mas o cluster não tem acesso à chave de criptografia e, portanto, não consegue criar o disco EBS. Consulte Pré-requisitos para migrar VMs do Linux usando clusters de processamento da AWS para mais informações.

Quero receber suporte personalizado

O suporte pago está disponível para os clientes que fazem a migração com o Migrate for Anthos. Entre em contato para que possamos ajudá-lo.

Como fornecer informações ao suporte do Google Cloud

O Sysreport oferece suporte ao Migrate for Anthos com informações sobre a configuração do cluster para agilizar o tempo de resolução do problema.

É possível acessar o script no Cloud Shell.

Abrir o Cloud Shell

Em seguida, execute o script collect_sysreport.sh.

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

Em que:

[NAMESPACE]: (opcional) o namespace em que o Migrate for Anthos foi implantado (o padrão é v2k-system).
[OUTPUT_DIRECTORY]: (opcional) o caminho para o diretório em que o Sysreport será salvo (o padrão é $HOME).
[MIGRATION]: (opcional) informações adicionais coletadas para uma migração.

O script cria anthos-migrate-logs.TIMESTAMP.tar.xz, que você fornece ao suporte do Google Cloud.

Por padrão, o script coleta o seguinte:

Registros dos nós e do controlador da CSI do Migrate for Anthos
Syslog dos hosts de nó da CSI do Migrate for Anthos
Registros do controlador do Migrate for Anthos.
Todas as entidades do Migrate for Anthos no cluster.
Se você especificar uma migração e ela usar o repositório de artefatos padrão, colete os artefatos de migração do bucket do Cloud Storage ou da S3.
A saída de:
- kubectl cluster-info
- kubectl get nodes; kubectl describe node
- kubectl version
- kubectl top node
Os registros da carga de trabalho
A saída 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