Nesta página, mostramos como investigar problemas com a criação, o upgrade e o redimensionamento dos clusters do Anthos no VMware (GKE no local).
Comportamento padrão de geração de registros para gkectl
e gkeadm
Para gkectl
e gkeadm
, basta usar as configurações de geração de registros padrão:
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
.O nível de detalhes
-v5
padrão abrange todas as entradas de registro necessárias para a equipe de suporte.O arquivo de registros inclui o comando executado e a mensagem de falha.
Recomendamos que você envie o arquivo de registros para a equipe de suporte quando precisar de ajuda.
Como especificar locais não padrão para arquivos 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, você poderá investigar o problema inspecionando os registros a partir do pod de controladores da API Cluster no cluster de administrador.
Encontre o nome do pod de controladores da API Cluster:
kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG --namespace kube-system \ get pods | grep clusterapi-controllers
Visualize registros pelo
vsphere-controller-manager
. Comece especificando o pod, mas nenhum contêiner:kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG --namespace kube-system \ logs POD_NAME
A saída diz que você precisa especificar um contêiner e fornece os nomes dos contêineres no pod. Exemplo:
... a container name must be specified ..., choose one of: [clusterapi-controller-manager vsphere-controller-manager rbac-proxy]
Escolha um contêiner e veja os registros dele:
kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG --namespace kube-system \ logs POD_NAME --container CONTAINER_NAME
Como usar govc
para resolver problemas com o vSphere
Use govc
para investigar problemas com o vSphere. Por exemplo, é possível
confirmar as permissões e o acesso das suas contas de usuário do vCenter e
coletar registros do vSphere.
Como depurar usando os registros do cluster de inicialização
Durante a instalação, os clusters do Anthos no VMware criam um cluster temporário de inicialização. Após uma instalação bem-sucedida, os clusters do Anthos no VMware excluem o cluster de inicialização, deixando você com o cluster de administrador e o cluster de usuário. Geralmente, não há motivos para você interagir com o cluster de inicialização.
Se você transmitir --cleanup-external-cliuster=false
para gkectl create cluster
,
o cluster de inicialização não será excluído e será possível usar os registros
dele para depurar problemas de instalação.
Encontre os nomes dos pods em execução no namespace
kube-system
:kubectl --kubeconfig /home/ubuntu/.kube/kind-config-gkectl get pods -n kube-system
Veja os registros de um pod:
kubectl --kubeconfig /home/ubuntu/.kube/kind-config-gkectl -n kube-system get logs POD_NAME
Depuração de problemas F5 BIG-IP usando o arquivo interno kubeconfig
Após uma instalação, os clusters do Anthos no VMware geram um arquivo kubeconfig
no diretório inicial da estação de trabalho de administrador
chamado internal-cluster-kubeconfig-debug
. Esse arquivo kubeconfig é idêntico ao arquivo kubeconfig
do cluster de administrador. A diferença é que ele aponta diretamente para o nó do plano de controle
do cluster de administrador, onde o servidor da API Kubernetes é executado. É possível usar o
arquivo internal-cluster-kubeconfig-debug
para depurar problemas de F5 BIG-IP.
Falha no redimensionamento de um cluster de usuário
Se o redimensionamento de um cluster de usuário falhar:
Encontre os nomes das MachineDeployments e das Máquinas:
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG get machinedeployments --all-namespaces kubectl --kubeconfig USER_CLUSTER_KUBECONFIG get machines --all-namespaces
Descreva uma MachineDeployment para exibir os registros:
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG describe machinedeployment MACHINE_DEPLOYMENT_NAME
Verifique se há erros em Máquinas recém-criadas:
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG describe machine MACHINE_NAME
Nenhum endereço pode ser alocado para o redimensionamento do cluster
Esse problema ocorre se não houver endereços IP suficientes disponíveis para redimensionar um cluster de usuário.
kubectl describe machine
exibe o seguinte erro:
Events: Type Reason Age From Message ---- ------ ---- ---- ------- Warning Failed 9s (x13 over 56s) machineipam-controller ipam: no addresses can be allocated
Para resolver esse problema, aloque mais endereços IP para o cluster. Em seguida, exclua a máquina afetada:
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG delete machine MACHINE_NAME
Os clusters do Anthos no VMware criam uma nova máquina e a atribuem a ela um dos novos endereços IP disponíveis.
Número suficiente de endereços IP alocados, mas a máquina não é registrada no cluster
Esse problema pode ocorrer se houver um conflito de endereço IP. Por exemplo, um endereço IP especificado para uma máquina está sendo usado para um balanceador de carga.
Para resolver esse problema, atualize o arquivo de bloco de IP do cluster para que os endereços da máquina não entrem em conflito com os endereços especificados no arquivo de configuração do cluster ou com seu arquivo de bloco de IP da Seesaw.
O snapshot é criado automaticamente quando há falha na criação ou no upgrade do cluster de administrador
Se você tentar criar ou atualizar um cluster de administrador e essa operação falhar, os clusters do Anthos no VMware capturarão um snapshot externo do cluster de inicialização, que é um cluster temporário usado para criar ou atualizar o cluster de administrador. Embora esse snapshot do cluster de inicialização seja semelhante ao snapshot capturado ao executar o comando gkectl diagnose snapshot
no cluster de administrador, ele é acionado automaticamente. Esse snapshot do cluster de inicialização contém informações de depuração importantes para o processo de criação e upgrade do cluster de administrador. É possível fornecer esse snapshot para o suporte do Google Cloud, se necessário.
O snapshot externo inclui registros de pod de onprem-admin-cluster-controller
que podem ser visualizados para depurar problemas de criação ou upgrade do cluster. Os registros são armazenados em um arquivo separado, por exemplo:
kubectl_logs_onprem-admin-cluster-controller-6767f6597-nws8g_--container_onprem-admin-cluster-controller_--kubeconfig_.home.ubuntu..kube.kind-config-gkectl_--namespace_kube-system
As verificações de integridade são executadas automaticamente quando ocorre uma falha no upgrade do cluster
Se você tentar fazer upgrade de um cluster de administrador ou de usuário e essa operação falhar, os clusters do Anthos no VMware executarão automaticamente o comando gkectl diagnose cluster
no cluster.
Para pular o diagnóstico automático, transmita a sinalização --skip-diagnose-cluster
para gkectl upgrade
.
O processo de upgrade trava
Nos clusters do Anthos no VMware, nos bastidores, usam o comando drain
do Kubernetes durante um upgrade. Esse procedimento drain
pode ser bloqueado por uma implantação com apenas uma réplica que tenha um PodDisruptionBudget (PDB) criado com minAvailable: 1
.
Com a versão 1.13 ou mais recente dos clusters do Anthos no VMware, é possível verificar falhas com os eventos do pod do Kubernetes.
Encontre os nomes das máquinas:
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG get machines --all-namespaces
Verifique se há erros usando o comando
kubectl describe machine
:kubectl --kubeconfig USER_CLUSTER_KUBECONFIG describe machine MACHINE_NAME
Este um exemplo de saída:
Events: Type Reason Age From Message ---- ------ ---- ---- ------- Warning PodEvictionTooLong 3m49s machine-controller Waiting too long(12m10.284294321s) for pod(default/test-deployment-669b85c4cc-z8pz7) eviction.
Para uma análise mais detalhada sobre o status dos objetos da máquina, execute gkectl diagnose cluster
:
... Checking machineset...SUCCESS Checking machine objects...FAILURE Reason: 1 machine objects error(s). Unhealthy Resources: Pod test-deployment-669b85c4cc-7zjpq: Pod cannot be evicted successfully. There is 1 related PDB. ... Checking all poddisruptionbudgets...FAILURE Reason: 1 pod disruption budget error(s). Unhealthy Resources: PodDisruptionBudget test-pdb: default/test-pdb might be configured incorrectly, the total replicas(3) should be larger than spec.MinAvailable(3). ... Some validation results were FAILURE or UNKNOWN. Check report above.
Para resolver esse problema, salve e remova o PDB do cluster antes de tentar o upgrade. Em seguida, você poderá adicionar o PDB novamente após a conclusão do upgrade.
Diagnosticar o status da máquina virtual
Se surgir um problema com a criação da máquina virtual, execute gkectl diagnose cluster
para receber um diagnóstico do status da máquina virtual.
Veja um exemplo de saída:
- Validation Category: Cluster Healthiness Checking cluster object...SUCCESS Checking machine deployment...SUCCESS Checking machineset...SUCCESS Checking machine objects...SUCCESS Checking machine VMs...FAILURE Reason: 1 machine VMs error(s). Unhealthy Resources: Machine [NODE_NAME]: The VM's UUID "420fbe5c-4c8b-705a-8a05-ec636406f60" does not match the machine object's providerID "420fbe5c-4c8b-705a-8a05-ec636406f60e". Debug Information: null ... Exit with error: Cluster is unhealthy! Run gkectl diagnose cluster automatically in gkectl diagnose snapshot Public page https://cloud.google.com/anthos/clusters/docs/on-prem/1.13/diagnose#overview_diagnose_snapshot
Consulte Diagnóstico para mais informações.
Recriar o arquivo kubeconfig do cluster de usuário ausente
É possível recriar um arquivo kubeconfig do cluster de usuário em algumas situações:
- Se você tentar criar um cluster de usuário, a operação de criação falhar e você quiser o arquivo kubeconfig do cluster de usuário.
- Se o arquivo kubeconfig do cluster de usuário estiver ausente, como após ter sido excluído.
Execute estes comandos para recriar o arquivo kubeconfig do cluster de usuário:
KUBECONFIG_SECRET_NAME=$(kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG get secrets -n USER_CLUSTER_NAME | grep admin-kubeconfig | cut -d' ' -f1) kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG get secrets -n USER_CLUSTER_NAME $KUBECONFIG_SECRET_NAME \ -o jsonpath='{.data.kubeconfig\.conf}' | base64 -d | sed -r "s/kube-apiserver.*local\./USER_CLUSTER_VIP/" > new_user_kubeconfig
Substitua:
- USER_CLUSTER_VIP: o valor de VIP principal do usuário.
- USER_CLUSTER_NAME: o nome do cluster de usuário.
- ADMIN_CLUSTER_KUBECONFIG é o caminho do arquivo kubeconfig para o cluster de administrador;