Solução de problemas de criação e upgrade do cluster

Version 1.16 

• Versão mais recente
• Versão 1.16
• Versões anteriores (sem suporte)

Nesta página, mostramos como investigar problemas com a criação, upgrade e redimensionamento de clusters no GKE no VMware.

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 arquivo logs/gkectl-$(date).log no diretório local em que você executa gkectl.

• Para gkeadm, o arquivo de registros padrão é logs/gkeadm-$(date).log no diretório local em que você executa gkeadm.

• 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.

1. Encontre o nome do pod de controladores da API Cluster:

   kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG --namespace kube-system \
       get pods | grep clusterapi-controllers
   

2. 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, 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.

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 os registros dele para depurar problemas de instalação.

1. 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
   

2. Veja os registros de um pod:

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

3. Para acessar os registros do cluster de inicialização diretamente, execute o seguinte comando durante a criação, a atualização e o upgrade do cluster:

   docker exec -it gkectl-control-plane bash
   

   O comando abre um terminal dentro do contêiner do plano de controle-gkectl que é executado no cluster de inicialização.

   Para inspecionar os registros do kubelet e do containerd, 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
   

Como 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.

Verifique se a versão anterior está disponível para reversão:

gkectl version --cluster-name USER_CLUSTER_NAME --kubeconfig ADMIN_CLUSTER_KUBECONFIG

A saída mostra a versão atual e a anterior para 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 pools de nós

É possível reverter um pool de nós de cada vez ou reverter vários em uma única etapa.

No arquivo de configuração do cluster de usuário, em um ou mais pools de nós, defina o valor de gkeOnPremVersion como a versão anterior: 1.13.1-gke.35 neste exemplo:

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_KUBECONFIG

Verifique se a reversão:

gkectl version --cluster-name USER_CLUSTER_NAME --kubeconfig ADMIN_CLUSTER_KUBECONFIG

Por exemplo, a saída a seguir mostra que pool-1 foi 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

Suponha que o problema tenha sido corrigido em uma nova versão de patch, por exemplo, 1.14.1. Agora é possível fazer upgrade de todos os pools de nós e do plano de controle para a nova versão de patch.

No arquivo de configuração do cluster de usuário, faça o seguinte:

• defina o valor de gkeOnPremVersion como a nova versão de patch: 1.14.1-gke.x neste exemplo.

• Para cada pool de nós, remova o campo gkeOnPremVersion ou defina-o como a string vazia. Quando nenhuma versão é especificada para um pool de nós, a versão do pool de nós padrão é a versão especificada do cluster.

Exemplo:

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 prepare e gkectl upgrade cluster, conforme descrito em Como fazer upgrade do GKE no VMware.

Verifique a nova versão do cluster e confira as versões que agora estão disponíveis para reversão:

gkectl version --cluster-name USER_CLUSTER_NAME --kubeconfig ADMIN_CLUSTER_KUBECONFIG

Exemplo de saída:

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

Depuração de problemas F5 BIG-IP usando o arquivo interno kubeconfig

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.

Falha no redimensionamento de um cluster de usuário

Se o redimensionamento de um cluster de usuário falhar:

1. 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
   

2. Descreva uma MachineDeployment para exibir os registros:

   kubectl --kubeconfig USER_CLUSTER_KUBECONFIG describe machinedeployment MACHINE_DEPLOYMENT_NAME

3. 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

O GKE no VMware cria uma nova máquina e atribui a ela um dos endereços IP recém-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, o GKE no VMware vão capturar 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, o GKE 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

O GKE no VMware, em segundo plano, usa 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.

No GKE on VMware versão 1.13, é possível verificar falhas por meio de eventos de pod do Kubernetes.

1. Encontre os nomes das máquinas:

   kubectl --kubeconfig USER_CLUSTER_KUBECONFIG get machines --all-namespaces
   

2. 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.16/diagnose#overview_diagnose_snapshot

Consulte Diagnosticar problemas de cluster 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 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 arquivo kubeconfig para o cluster de usuário.
• ADMIN_CLUSTER_KUBECONFIG: o caminho do arquivo kubeconfig do cluster de administrador.

Remova as mudanças sem suporte para desbloquear o upgrade

Ao fazer upgrade de clusters para a versão 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 posteriores, validamos todas as alterações feitas no arquivo de configuração e retornamos um erro para as alterações sem suporte, em vez de apenas ignorá-las. Por exemplo, se você tentar desativar a reparação automática 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, estas são as soluções alternativas:

• Reverta a tentativa de alteração e execute o upgrade novamente. Por exemplo, no cenário anterior, você reverteria as alterações feitas na configuração AutoRepair e depois executaria gkectl upgrade novamente.
• Como alternativa, gere arquivos de configuração que correspondam ao estado atual do cluster executando gkectl get-config, atualize os campos gkeOnPremVersion do cluster e dos pools de nós no arquivo de configuração e execute gkectl upgrade novamente.