Nesta página, mostramos como investigar problemas com a criação e o upgrade de clusters no GKE no VMware.
Se precisar de mais ajuda, entre em contato com o Cloud Customer Care.Problemas de instalação
As seções a seguir podem ajudar a resolver problemas de instalação do GKE no VMware.
Usar o cluster de inicialização para depurar problemas
Durante a instalação, o GKE no VMware cria um cluster temporário de inicialização. Após uma instalação bem-sucedida, o GKE no VMware exclui o cluster de inicialização, deixando você com o cluster de administrador e de usuário. Geralmente, não há motivos para você interagir com o cluster de inicialização. No entanto, se você encontrar problemas durante a instalação, use os registros do cluster de inicialização para depurar o problema.
Se você transmitir --cleanup-external-cluster=false para gkectl create cluster, o cluster de inicialização não será excluído, e será possível usar o cluster
de inicialização para depurar problemas de instalação.
Examinar os registros do cluster de inicializaçã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-systemVeja os registros de um pod:
kubectl --kubeconfig /home/ubuntu/.kube/kind-config-gkectl -n kube-system get logs POD_NAMESubstitua
POD_NAMEpelo nome do pod que você quer visualizar.Para receber diretamente os registros do cluster de inicialização, execute o seguinte comando durante a criação, atualização e upgrade do cluster:
docker exec -it gkectl-control-plane bashEsse comando abre um terminal dentro do contêiner
gkectl-control-planeque é executado no cluster de inicialização.Para inspecionar os registros
kubeletecontainerd, use os seguintes comandos e procure erros ou avisos na saída:systemctl status -l kubelet journalctl --utc -u kubelet systemctl status -l containerd journalctl --utc -u containerd
Examinar o snapshot do cluster de inicialização
Se você tentar criar ou fazer upgrade de um cluster de administrador e essa operação falhar,
o GKE no VMware vai capturar um snapshot externo do cluster de inicialização.
Esse snapshot do cluster de inicialização é semelhante ao capturado
ao executar o comando gkectl diagnose snapshot
no cluster de administrador,
mas o processo é acionado automaticamente. O 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 Cloud Customer Care, se necessário.
O snapshot externo inclui registros de pods do
onprem-admin-cluster-controller que podem ser visualizados para depurar problemas de criação de cluster ou
upgrade. 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
A VM não inicia depois que o plano de controle do administrador é iniciado
Se uma VM não for iniciada após a inicialização do plano de controle do administrador, investige o problema inspecionando os registros 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-controllersVisualize registros pelo
vsphere-controller-manager. Comece especificando o pod, mas nenhum contêiner:kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG --namespace kube-system \ logs POD_NAMEA 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
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 no arquivo de bloco de IP do Seesaw.
Problemas de upgrade de cluster
As seções a seguir dão dicas sobre como resolver problemas que podem ser encontrados durante um upgrade de cluster.
Reverter um pool de nós após um upgrade
Se você fizer upgrade de um cluster de usuário e descobrir um problema com os nós do cluster, será possível reverter os pools de nós selecionados para a versão anterior.
A reversão de pools de nós selecionados é compatível com pools de nós do Ubuntu e COS, mas não pools de nós do Windows.
A versão de um pool de nós pode ser igual ou uma versão secundária mais antiga que a versão do plano de controle do cluster de usuário. Por exemplo, se o plano de controle estiver na versão 1.14, os pools de nós poderão estar na versão 1.14 ou 1.13.
Acessar as versões de pool de nós disponíveis
Suponha que você tenha atualizado os nós de trabalho do cluster de usuário e o plano de controle da versão 1.13.1-gke.35 para a versão 1.14.0, e tenha descoberto um problema com os nós de trabalho atualizados. Então, você decide reverter um ou mais pools de nós para a versão que estava executando anteriormente: 1.13.1-gke.35. Antes de iniciar a reversão, é necessário verificar se a versão anterior está disponível.
Para visualizar as versões disponíveis, execute o seguinte comando:
gkectl version --cluster-name USER_CLUSTER_NAME \
--kubeconfig ADMIN_CLUSTER_KUBECONFIG
A saída mostra a versão atual e a versão anterior de cada pool de nós. Exemplo:
user cluster version: 1.14.0-gke.x
node pools:
- pool-1:
- version: 1.14.0-gke.x
- previous version: 1.13.1-gke.35
- pool-2:
- version: 1.14.0-gke.x
- previous version: 1.13.1-gke.35
available node pool versions:
- 1.13.1-gke.35
- 1.14.0-gke.x
Reverter a versão do pool de nós
É possível reverter a versão de um pool de nós um pool de nós por vez ou vários pools de nós em uma única etapa.
Para reverter uma versão do pool de nós, siga estas etapas:
No arquivo de configuração do cluster de usuário, em um ou mais pools de nós, defina o valor de
gkeOnPremVersioncomo a versão anterior. O exemplo a seguir mostra como reverter para a versão 1.13.1-gke.35:nodePools: - name: pool-1 cpus: 4 memoryMB: 8192 replicas: 3 gkeOnPremVersion: 1.13.1-gke.35 ...Atualize o cluster para reverter os pools de nós:
gkectl update cluster --config USER_CLUSTER_CONFIG \ --kubeconfig ADMIN_CLUSTER_KUBECONFIGVerifique se a reversão foi bem-sucedida:
gkectl version --cluster-name USER_CLUSTER_NAME \ --kubeconfig ADMIN_CLUSTER_KUBECONFIGA saída a seguir mostra que
pool-1foi revertido para a versão 1.13.1-gke.35.user cluster version: 1.14.0-gke.x node pools: - pool-1: - version: 1.13.1-gke.35 - previous version: 1.14.0-gke.x - pool-2: - version: 1.14.0-gke.x - previous version: 1.13.1-gke.35 available node pool versions: - 1.13.1-gke.35 - 1.14.0-gke.x
Fazer upgrade para uma nova versão de patch
É possível fazer upgrade de todos os pools de nós e do plano de controle para uma nova versão de patch. Isso pode ser útil se você reverteu para uma versão anterior e quer fazer upgrade para uma versão que inclua uma correção.
Para fazer upgrade para uma nova versão, siga estas etapas:
Faça as seguintes alterações no arquivo de configuração do cluster de usuário:
Defina o valor de
gkeOnPremVersioncomo uma nova versão de patch. Neste exemplo, usamos 1.14.1-gke.x.Para cada pool de nós, remova o campo
gkeOnPremVersionou defina-o como a string vazia. Quando nenhuma versão é especificada para um pool de nós, o padrão é a versão especificada para o cluster.Essas mudanças vão ser semelhantes ao exemplo a seguir:
gkeOnPremVersion: 1.14.1-gke.x nodePools: - name: pool-1 cpus: 4 memoryMB: 8192 replicas: 3 gkeOnPremVersion: "" - name: pool-2 cpus: 8 memoryMB: 8192 replicas: 2 gkeOnPremVersion: ""
Execute
gkectl prepareegkectl upgrade cluster, conforme descrito em Como fazer upgrade do GKE no VMware.Verifique a nova versão do cluster e veja as versões que estão disponíveis para reversão:
gkectl version --cluster-name USER_CLUSTER_NAME \ --kubeconfig ADMIN_CLUSTER_KUBECONFIGO resultado será assim:
user cluster version: 1.14.1-gke.y node pools: - pool-1: - version: 1.14.1-gke.y - previous version: 1.13.1-gke.35 - pool-2: - version: 1.14.1-gke.y - previous version: 1.13.1-gke.35 available node pool versions: - 1.13.1-gke.35 - 1.14.0-gke.x - 1.14.1-gke.y ```
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,
o GKE no VMware executará 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
Em segundo plano, o GKE no VMware usa o comando drain do Kubernetes
durante um upgrade. Este procedimento drain pode ser bloqueado por uma implantação com
apenas uma réplica que tem um PodDisruptionBudget (PDB) criado para ele com
minAvailable: 1.
No GKE no VMware versão 1.13, é possível verificar falhas com eventos do pod do Kubernetes.
Encontre os nomes das máquinas:
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG get machines --all-namespacesVerifique se há erros usando o comando
kubectl describe machine:kubectl --kubeconfig USER_CLUSTER_KUBECONFIG describe machine MACHINE_NAMEO resultado será assim:
Events: Type Reason Age From Message ---- ------ ---- ---- ------- Warning PodEvictionTooLong 3m49s machine-controller Waiting too long(12m10.284294321s) for pod(default/test-deployment-669b85c4cc-z8pz7) eviction.Opcional: para uma análise mais detalhada do status dos objetos de máquina, execute
gkectl diagnose cluster.O resultado será assim:
... 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 o PDB e remova-o do cluster antes de tentar o upgrade. Em seguida, adicione o PDB novamente após a conclusão do upgrade.
Remova as mudanças incompatíveis para desbloquear o upgrade
Ao fazer upgrade de clusters para versões 1.16 ou anteriores, as alterações na maioria dos campos são ignoradas silenciosamente durante o upgrade, o que significa que essas alterações não entram em vigor durante e após o upgrade.
Ao fazer upgrade de clusters de usuário para versões 1.28 ou mais recentes, validamos todas as alterações feitas no arquivo de configuração e retornamos um erro para alterações não suportadas, em vez de simplesmente ignorá-las. Esse recurso é apenas para clusters de usuários. Ao fazer upgrade de clusters de administrador, as alterações na maioria dos campos são ignoradas silenciosamente e não entrarão em vigor após o upgrade.
Por exemplo, se você tentar desativar o reparo automático de nós ao fazer upgrade de um cluster de usuário para a versão 1.28, o upgrade falhará com a seguinte mensagem de erro:
failed to generate desired create config: failed to generate desired OnPremUserCluster from seed config: failed to apply validating webhook to OnPremUserCluster: the following changes on immutable fields are forbidden during upgrade: (diff: -before, +after):
v1alpha1.OnPremUserClusterSpec{
... // 20 identical fields
UsageMetering: nil,
CloudAuditLogging: &{ProjectID: "syllogi-partner-testing", ClusterLocation: "us-central1", ServiceAccountKey: &{KubernetesSecret: &{Name: "user-cluster-creds", KeyName: "cloud-audit-logging-service-account-key"}}},
- AutoRepair: &v1alpha1.AutoRepairConfig{Enabled: true},
+ AutoRepair: &v1alpha1.AutoRepairConfig{},
CARotation: &{Generated: &{CAVersion: 1}},
KSASigningKeyRotation: &{Generated: &{KSASigningKeyVersion: 1}},
... // 8 identical fields
}
Se você precisar ignorar esse erro, existem estas soluções alternativas:
- Reverta a tentativa de alteração e execute o upgrade novamente. Por exemplo, no
cenário anterior, reverta as alterações feitas na configuração
AutoRepaire executegkectl upgradenovamente. - Como alternativa, gere arquivos de configuração que correspondam ao estado
atual do cluster executando
gkectl get-config, atualize os camposgkeOnPremVersiondo cluster e dos pools de nós no arquivo de configuração e executegkectl upgradenovamente.
Depurar problemas F5 BIG-IP com o arquivo kubeconfig interno
Após uma instalação, o GKE 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.
Depurar problemas com o vSphere
Use
govc para
investigar problemas com o vSphere. Por exemplo, é possível confirmar permissões e
acesso para suas contas de usuário do vCenter e coletar registros do vSphere.
Recriar o arquivo kubeconfig do cluster de usuário ausente
É possível recriar um arquivo kubeconfig do cluster de usuário nas seguintes
situações:
- Se você tentar criar um cluster de usuário, e a operação de criação falhar e
você quiser ter o arquivo
kubeconfigdo cluster de usuário. - Se o arquivo
kubeconfigdo cluster de usuário estiver ausente, por exemplo, depois de ter sido excluído.
Execute o seguinte comando para recriar o arquivo kubeconfig do cluster de usuário:
kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG get secrets -n admin \
-o jsonpath='{.data.admin\.conf}' | base64 -d > USER_CLUSTER_KUBECONFIG
Substitua:
USER_CLUSTER_KUBECONFIG: o nome do novo arquivokubeconfigdo cluster de usuário.ADMIN_CLUSTER_KUBECONFIG: o caminho do arquivokubeconfigpara o cluster de administrador.
A seguir
- Se precisar de mais ajuda, entre em contato com o Cloud Customer Care.