Nas seções a seguir, descrevemos os problemas que podem ocorrer 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.
Comportamento de geração de registros padrão
Para gkectl
e gkeadm
, basta usar as configurações de
geração de registros padrão:
-
Por padrão, as entradas de registro são salvas da seguinte maneira:
-
Para
gkectl
, o arquivo de registros padrão é/home/ubuntu/.config/gke-on-prem/logs/gkectl-$(date).log
e está vinculado ao arquivologs/gkectl-$(date).log
no diretório local em que você executagkectl
. -
Para
gkeadm
, o arquivo de registros padrão élogs/gkeadm-$(date).log
no diretório local em que você executagkeadm
.
-
Para
- Todas as entradas de registro são salvas no arquivo de registros, mesmo que não sejam
impressas no terminal (quando
--alsologtostderr
éfalse
). - O nível de detalhamento
-v5
(padrão) abrange todas as entradas de registro exigidas pela equipe de suporte. - O arquivo de registros também contém o comando executado e a mensagem de erro.
Recomendamos que você envie o arquivo de registros para a equipe de suporte quando precisar de ajuda.
Como especificar um local não padrão para o arquivo de registros
Se quiser especificar um local não padrão para o arquivo de registros gkectl
, use
a sinalização --log_file
. O arquivo de registro que você especificar não
será vinculado ao diretório local.
Se quiser especificar um local não padrão para o arquivo de registros gkeadm
, use
a sinalização --log_file
.
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:
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
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 com o kubeconfig do nó do plano de controle 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 denominado internal-cluster-kubeconfig-debug
. Esse arquivo kubeconfig é idêntico ao kubeconfig do cluster de administrador, com a diferença de que ele aponta diretamente para o nó do plano de controle do cluster de administrador, em que o plano de controle de 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 de F5 BIG-IP, embora 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
,
talvez seja útil realizar a depuração usando os registros do cluster de inicialização. Encontre
o pod e acesse 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 do administrador
openssl
não pode validar o OVA da estação de trabalho de administrador
- Sintomas
Executar
openssl dgst
no arquivo OVA da estação de trabalho de administrador não retornaVerified 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 de administrador novamente, conforme descrito em Fazer o download do OVA da estação de trabalho de 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ê encontrar problemas com o registro de clusters de usuário, entre em contato com o Google para receber ajuda.
O registro do cluster criado durante a versão Alfa foi cancelado
Consulte Como registrar um cluster de usuário na documentação do Connect.
Também é possível excluir e recriar o cluster.
Armazenamento
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 nº 32727 no Kubernetes 1.12.
Resolução
Se um disco virtual estiver anexado à máquina virtual errada, talvez seja necessário desanexá-lo manualmente:
- Drene o nó.
Consulte Drenar um nó com segurança. Convém incluir as
sinalizações
--ignore-daemonsets
e--delete-local-data
no comandokubectl drain
. - Desligue a VM.
- Edite a configuração de hardware da VM no vCenter para remover o volume.
- Ligue a VM
- Desfaça o nó.
O volume foi 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 ao qual estiver anexado. Para evitar isso, gerencie suas máquinas virtuais conforme descrito em Como redimensionar um cluster de usuário 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:
- Execute
kubectl delete pvc [PVC_NAME].
para excluir o PVC que faz referência ao PV - Execute
kubectl delete pod [POD_NAME].
para excluir o pod que faz referência ao PVC - Repita a etapa 2. (Sim, na verdade. Consulte o problema 74374 do Kubernetes.)
Não é possível remover o volume do CSI do vSphere
Sintomas
Se você encontrar pods presos na fase ContainerCreating
com
avisos de FailedAttachVolume
, pode ser devido a uma falha na remoção em
um nó diferente.
Execute o seguinte comando para encontrar erros de remoção de CSI:
kubectl get volumeattachments -o=custom-columns=NAME:metadata.name,DETACH_ERROR:status.detachError.message
A saída será semelhante a esta:
NAME DETACH_ERROR csi-0e80d9be14dc09a49e1997cc17fc69dd8ce58254bd48d0d8e26a554d930a91e5 rpc error: code = Internal desc = QueryVolume failed for volumeID: "57549b5d-0ad3-48a9-aeca-42e64a773469". ServerFaultCode: NoPermission csi-164d56e3286e954befdf0f5a82d59031dbfd50709c927a0e6ccf21d1fa60192dcsi-8d9c3d0439f413fa9e176c63f5cc92bd67a33a1b76919d42c20347d52c57435c csi-e40d65005bc64c45735e91d7f7e54b2481a2bd41f5df7cc219a2c03608e8e7a8
Causas possíveis
O privilégio CNS > Searchable
não foi concedido ao usuário vSphere.
Resolução
Adicione o privilégio CNS > Searchable
à sua conta de usuário do vCenter. Essa operação
é repetida automaticamente até ser bem-sucedida.
Upgrades
Sobre a inatividade durante upgrades
Recurso | Descrição |
---|---|
Cluster de administrador | Quando um cluster de administrador fica inativo, os planos de controle do cluster de usuário e as cargas de trabalho em clusters de usuário continuam em execução, a menos que tenham sido afetados por uma falha que causou a inatividade. |
Plano de controle do cluster de usuário | Normalmente, não há inatividade perceptível nos planos de controle do cluster de 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 do cluster de usuário | 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:
Verifique o status de MachineDeployment do cluster para ver se há eventos ou mensagens de erro:
kubectl describe machinedeployments [MACHINE_DEPLOYMENT_NAME]
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 ainda assim a máquina 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á resolvê-lo 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 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:
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
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 -
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 no provedor do vSphere do Terraform
O GKE On-Prem usa o provedor do vSphere do Terraform para abrir VMs no ambiente vSphere. O limite de sessões no 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º 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 dehttps://
.
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.