Você está visualizando a documentação de uma versão anterior do GKE On-Prem. Veja a documentação mais recente.

Resolver problemas

As seções a seguir descrevem os problemas que se pode encontrar ao usar o GKE On-Prem e como resolvê-los.

Antes de começar

Verifique as seções a seguir antes de começar a resolver um problema.

Como diagnosticar problemas de cluster usando gkectl

Use os comandos gkectl diagnose para identificar problemas de cluster e compartilhar informações do cluster com o Google. Consulte Como diagnosticar problemas de cluster.

Como executar comandos gkectl de forma detalhada

-v5

Como registrar erros gkectl em stderr

--alsologtostderr

Como localizar registros gkectl na estação de trabalho do administrador

Mesmo que você não passe as sinalizações de depuração, é possível ver os registros gkectl no seguinte diretório da estação de trabalho do administrador:

/home/ubuntu/.config/syllogi/logs

Como localizar registros da API Cluster no cluster de administrador

Se uma VM não for iniciada após o início do plano de controle do administrador, tente depurar isso inspecionando os registros dos controladores da API Cluster no cluster de administrador:

  1. Encontre o nome do pod de controladores da API Cluster no namespace kube-system, em que [ADMIN_CLUSTER_KUBECONFIG] é o caminho para o arquivo kubeconfig do cluster de administrador:

    kubectl --kubeconfig [ADMIN_CLUSTER_KUBECONFIG] -n kube-system get pods | grep clusterapi-controllers
  2. Abra os registros do pod, em que [POD_NAME] é o nome do pod. Opcionalmente, use grep ou uma ferramenta semelhante para pesquisar erros:

    kubectl --kubeconfig [ADMIN_CLUSTER_KUBECONFIG] -n kube-system logs [POD_NAME] vsphere-controller-manager

Instalação

Como depurar problemas de F5 BIG-IP usando o kubeconfig do nó do mestre do cluster de administrador

Após uma instalação, o GKE On-Prem gera um arquivo kubeconfig no diretório inicial da estação de trabalho do administrador chamado internal-cluster-kubeconfig-debug. Esse arquivo kubeconfig é idêntico ao kubeconfig do cluster de administrador, exceto pelo fato de apontar diretamente para o nó mestre do cluster de administrador, em que o plano de controle do administrador é executado. É possível usar o arquivo internal-cluster-kubeconfig-debug para depurar problemas de F5 BIG-IP.

Falha na validação de gkectl check-config: não é possível encontrar partições de F5 BIG-IP

Sintomas

A validação falha porque não são encontradas partições F5 BIG-IP, mesmo que elas existam.

Causas possíveis

Um problema com a API F5 BIG-IP pode causar falha na validação.

Resolução

Tente executar gkectl check-config novamente.

Falha em gkectl prepare --validate-attestations: não foi possível validar o atestado de versão

Sintomas

Executar gkectl prepare com a sinalização --validate-attestations opcional retorna o seguinte erro:

could not validate build attestation for gcr.io/gke-on-prem-release/.../...: VIOLATES_POLICY
Causas possíveis

Um atestado pode não existir para as imagens afetadas.

Resolução

Tente fazer o download e implantar o OVA da estação de trabalho de administrador novamente, conforme instruído em Como criar uma estação de trabalho de administrador. Se o problema persistir, entre em contato com o Google para receber ajuda.

Como depurar usando os registros do cluster de inicialização

Durante a instalação, o GKE On-Prem cria um cluster temporário de inicialização. Após uma instalação bem-sucedida, o GKE On-Prem exclui o cluster de inicialização, deixando você com o cluster de administrador e de usuário. Geralmente, não há motivo para interagir com esse cluster.

Se algo der errado durante uma instalação e você tiver transmitido --cleanup-external-cluster=false para gkectl create cluster, pode ser útil depurar usando os registros do cluster de inicialização. Encontre o pod e receba os registros dele:

kubectl --kubeconfig /home/ubuntu/.kube/kind-config-gkectl get pods -n kube-system
kubectl --kubeconfig /home/ubuntu/.kube/kind-config-gkectl -n kube-system get logs [POD_NAME]

Estação de trabalho de administrador

AccessDeniedException durante o download do OVA

Sintomas

A tentativa de fazer o download do OVA e da assinatura da estação de trabalho do administrador retorna o seguinte erro:

AccessDeniedException: 403 whitelisted-service-account@project.iam.gserviceaccount.com does not have storage.objects.list access to gke-on-prem-release
Causas possíveis

Sua conta de serviço na lista de permissões não está ativada.

Resolução

Verifique se você ativou sua conta de serviço na lista de permissões. Se o problema persistir, entre em contato com o Google para receber ajuda.

openssl não pode validar o OVA da estação de trabalho do administrador

Sintomas

Executar openssl dgst no arquivo OVA da estação de trabalho do administrador não retorna Verified OK

Causas possíveis

Há um problema no arquivo OVA que impede a validação bem-sucedida.

Resolução

Tente fazer o download e implantar o OVA da estação de trabalho do administrador novamente, conforme instruído em Fazer o download do OVA da estação de trabalho do administrador . Se o problema persistir, entre em contato com o Google para receber ajuda.

Conectar

Não é possível registrar um cluster de usuário

Se você tiver problemas com o registro de clusters de usuários, entre em contato com o Google para receber ajuda.

O cluster criado durante a versão Alfa foi desregistrado

Consulte Como registrar um cluster de usuários na documentação do Connect.

Também é possível excluir e recriar o cluster.

Storage

Falha ao anexar o volume

Sintomas

A saída de gkectl diagnose cluster é semelhante a esta:

Checking cluster object...PASS
Checking machine objects...PASS
Checking control plane pods...PASS
Checking gke-connect pods...PASS
Checking kube-system pods...PASS
Checking gke-system pods...PASS
Checking storage...FAIL
    PersistentVolume pvc-776459c3-d350-11e9-9db8-e297f465bc84: virtual disk "[datastore_nfs] kubevols/kubernetes-dynamic-pvc-776459c3-d350-11e9-9db8-e297f465bc84.vmdk" IS attached to machine "gsl-test-user-9b46dbf9b-9wdj7" but IS NOT listed in the Node.Status
1 storage errors

Um ou mais pods estão parados no estado ContainerCreating com um aviso como este:

Events:
  Type     Reason              Age               From                     Message
  ----     ------              ----              ----                     -------
  Warning  FailedAttachVolume  6s (x6 over 31s)  attachdetach-controller  AttachVolume.Attach failed for volume "pvc-776459c3-d350-11e9-9db8-e297f465bc84" : Failed to add disk 'scsi0:6'.

Causas possíveis

Se um disco virtual estiver anexado à máquina virtual errada, pode ser devido ao problema #322727 no Kubernetes 1.12.

Resolução

Se um disco virtual estiver anexado à máquina virtual errada, talvez seja necessário desanexá-lo manualmente:

  1. Drene o nó. Consulte Esvaziar um nó com segurança. Convém incluir as sinalizações --ignore-daemonsets e --delete-local-data no comando kubectl drain.
  2. Desligue a VM.
  3. Edite a configuração de hardware da VM no vCenter para remover o volume.
  4. Ligue a VM
  5. Desmarque o nó.

O volume é perdido

Sintomas

A saída de gkectl diagnose cluster é semelhante a esta:

Checking cluster object...PASS
Checking machine objects...PASS
Checking control plane pods...PASS
Checking gke-connect pods...PASS
Checking kube-system pods...PASS
Checking gke-system pods...PASS
Checking storage...FAIL
    PersistentVolume pvc-52161704-d350-11e9-9db8-e297f465bc84: virtual disk "[datastore_nfs] kubevols/kubernetes-dynamic-pvc-52161704-d350-11e9-9db8-e297f465bc84.vmdk" IS NOT found
1 storage errors

Um ou mais pods estão parados no estado ContainerCreating com um aviso como este:

Events:
  Type     Reason              Age                   From                                    Message
  ----     ------              ----                  ----                                    -------
  Warning  FailedAttachVolume  71s (x28 over 42m)    attachdetach-controller                 AttachVolume.Attach failed for volume "pvc-52161704-d350-11e9-9db8-e297f465bc84" : File []/vmfs/volumes/43416d29-03095e58/kubevols/
  kubernetes-dynamic-pvc-52161704-d350-11e9-9db8-e297f465bc84.vmdk was not found

Causas possíveis

Se você vir um erro "não encontrado" relacionado ao arquivo VMDK, é provável que o disco virtual tenha sido excluído permanentemente. Isso pode acontecer se um operador excluir manualmente um disco virtual ou a máquina virtual à qual ele está anexado. Para evitar isso, gerencie suas máquinas virtuais conforme descrito em Como redimensionar um cluster de usuários e Como fazer upgrade de clusters

Resolução

Se um disco virtual foi excluído permanentemente, talvez seja necessário limpar manualmente os recursos relacionados do Kubernetes:

  1. Exclua o opções de referência do PV executando kubectl delete pvc [PVC_NAME].
  2. Execute kubectl delete pod [POD_NAME]. para excluir o pod que referenciau o PVC
  3. Repita a etapa 2. (Sim, na verdade. Consulte o problema 74374 do Kubernetes.)

Upgrades

Sobre o tempo de inatividade durante os upgrades

Recurso Descrição
Cluster de administrador

Quando um cluster de administrador fica inativo, os planos de controle do cluster de usuários e as cargas de trabalho em clusters de usuários continuam em execução, a menos que tenham sido afetados por uma falha que causou a inatividade.

Plano de controle do cluster de usuários

Normalmente, você não deve esperar inatividade perceptível nos planos de controle de cluster do usuário. No entanto, conexões de longa duração com o servidor da API Kubernetes podem falhar e precisam ser restabelecidas. Nesses casos, o autor da chamada da API precisa tentar novamente até estabelecer uma conexão. No pior dos casos, pode haver até um minuto de inatividade durante um upgrade.

Nós de cluster de usuários

Se um upgrade exigir uma alteração nos nós do cluster de usuário, o GKE On-Prem recriará os nós de maneira contínua e reagendará os pods em execução nesses nós. É possível evitar o impacto nas suas cargas de trabalho configurando PodDisruptionBudgets e regras antiafinidade apropriados.

Como redimensionar clusters de usuário

Falha no redimensionamento de um cluster de usuário

Sintomas

Falha na operação de redimensionamento em um cluster de usuário.

Causas possíveis

Vários fatores podem causar falhas nas operações de redimensionamento.

Resolução

Se um redimensionamento falhar, siga estas etapas:

  1. Verifique o status de MachineDeployment do cluster para ver se há eventos ou mensagens de erro:

    kubectl describe machinedeployments [MACHINE_DEPLOYMENT_NAME]
  2. Verifique se há erros nas máquinas recém-criadas:

    kubectl describe machine [MACHINE_NAME]

Erro: "nenhum endereço pode ser alocado"

Sintomas

Depois de redimensionar um cluster de usuário, kubectl describe machine [MACHINE_NAME] exibe o seguinte erro:

Events:
   Type     Reason  Age                From                    Message
   ----     ------  ----               ----                    -------
   Warning  Failed  9s (x13 over 56s)  machineipam-controller  ipam: no addresses can be allocated
   
Causas possíveis

Não há endereços IP suficientes disponíveis para o cluster de usuário.

Resolução

Aloque mais endereços IP para o cluster. Em seguida, exclua a máquina afetada:

kubectl delete machine [MACHINE_NAME]

Se o cluster estiver configurado corretamente, uma máquina de substituição será criada com um endereço IP.

Número suficiente de endereços IP alocados, mas a máquina não é registrada no cluster

Sintomas

A rede tem endereços suficientes alocados, mas a máquina ainda não é registrada no cluster de usuário.

Causas possíveis

Pode haver um conflito de IP. O IP pode ser usado por outra máquina ou pelo balanceador de carga.

Resolução

Verifique se o endereço IP da máquina afetada não foi usado. Se houver um conflito, você precisará resolver o conflito no seu ambiente.

vSphere

Depuração com govc

Se você encontrar problemas específicos ao vSphere, use o govc para solucionar problemas. Por exemplo, é possível confirmar facilmente as permissões e o acesso das suas contas de usuário do vCenter e coletar registros do vSphere.

Como alterar o certificado do vCenter

Se você estiver executando um servidor vCenter no modo de configuração padrão ou modo de avaliação e tiver um certificado TLS gerado, esse certificado poderá mudar ao longo do tempo. Se o certificado tiver sido alterado, você precisará informar seus clusters em execução sobre o novo certificado:

  1. Recupere o novo certificado do vCenter e salve-o em um arquivo:

    true | openssl s_client -connect [VCENTER_IP_ADDRESS]:443 -showcerts 2>/dev/null | sed -ne '/-BEGIN/,/-END/p' > vcenter.pem
  2. Agora, para cada cluster, exclua o ConfigMap que contém o certificado do vSphere e do vCenter de cada cluster e crie um novo ConfigMap com o novo certificado. Exemplo:

    kubectl --kubeconfig kubeconfig delete configmap vsphere-ca-certificate -n kube-system
    kubectl --kubeconfig kubeconfig delete configmap vsphere-ca-certificate -n user-cluster1
    kubectl --kubeconfig kubeconfig create configmap -n user-cluster1 --dry-run vsphere-ca-certificate --from-file=ca.crt=vcenter.pem  -o yaml  | kubectl --kubeconfig kubeconfig apply -f -
    kubectl --kubeconfig kubeconfig create configmap -n kube-system --dry-run vsphere-ca-certificate --from-file=ca.crt=vcenter.pem  -o yaml  | kubectl --kubeconfig kubeconfig apply -f -
  3. Exclua o pod clusterapi-controllers de cada cluster. Quando o pod é reiniciado, ele começa a usar o novo certificado. Exemplo:

    kubectl --kubeconfig kubeconfig -n kube-system get pods
    kubectl --kubeconfig kubeconfig -n kube-system delete pod clusterapi-controllers-...

Diversos

Limite de sessão do provedor do Terraform vSphere

O GKE On-Prem usa o provedor do vSphere do Terraform para abrir VMs no ambiente vSphere. O limite de sessões do provedor é de 1.000 sessões. A implementação atual não fecha as sessões ativas após o uso. Podem ocorrer erros 503 se você tiver muitas sessões em execução.

As sessões são fechadas automaticamente após 300 segundos.

Sintomas

Se você tiver muitas sessões em execução, talvez você encontre o seguinte erro:

Error connecting to CIS REST endpoint: Login failed: body:
  {"type":"com.vmware.vapi.std.errors.service_unavailable","value":
  {"messages":[{"args":["1000","1000"],"default_message":"Sessions count is
  limited to 1000. Existing sessions are 1000.",
  "id":"com.vmware.vapi.endpoint.failedToLoginMaxSessionCountReached"}]}},
  status: 503 Service Unavailable
Causas possíveis

Há muitas sessões de provedor do Terraform em execução no seu ambiente.

Resolução

No momento, isso está funcionando conforme o esperado. As sessões são fechadas automaticamente após 300 segundos. Para mais informações, consulte o problema número 618 no GitHub.

Como usar um proxy para o Docker: oauth2: cannot fetch token

Sintomas

Ao usar um proxy, você encontra o seguinte erro:

oauth2: cannot fetch token: Post https://oauth2.googleapis.com/token: proxyconnect tcp: tls: oversized record received with length 20527
Causas possíveis

É possível que você tenha fornecido um proxy HTTPS em vez de HTTP.

Resolução

Na configuração do Docker, altere o endereço do proxy para http:// em vez de https://.

Como verificar se as licenças são válidas

Lembre-se de verificar se as licenças são válidas, especialmente se você estiver usando licenças de teste. Pode haver falhas inesperadas se as licenças F5, host ESXi ou vCenter tiverem expirado.