Resolver problemas de criação ou upgrade de clusters

Nesta página, mostramos como investigar problemas na criação e no upgrade de clusters no Google Distributed Cloud.

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 Google Distributed Cloud.

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ê tiver problemas durante a instalação, use o registros do cluster de inicialização para ajudar a depurar o problema.

Se você transmitir --cleanup-external-cluster=false para gkectl create cluster, o cluster de inicialização não é excluído, e é possível usar o comando cluster 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-system

Veja os registros de um pod:

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

Substitua POD_NAME pelo nome do pod que você quer visualizar.

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
```
Esse comando abre um terminal dentro do contêiner gkectl-control-plane executado no cluster de inicialização.

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

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 Google Distributed Cloud tira um snapshot externo do cluster de inicialização. Esse snapshot do cluster de inicialização é semelhante ao criado executando o comando gkectl diagnose snapshot comando 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 a criação do cluster de administrador e processo de upgrade. Você pode fornecer este resumo. para o Cloud Customer Care, 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

A VM não inicia depois que o plano de controle do administrador é iniciado

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

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.

Problemas de upgrade de cluster

As seções a seguir dão dicas sobre como resolver problemas encontrar durante um upgrade de cluster.

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. Antes de começar a reversão, será necessário verificar se o versão anterior está disponível para reversão.

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 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 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 implementar 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 a de gkeOnPremVersion para 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_KUBECONFIG

Verifique se a reversão foi bem-sucedida:

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

A saída a seguir mostra que pool-1 foi revertido para 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 um novo patch versão. Isso pode ser útil se você reverteu para uma versão anterior e quer para atualizar 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:
1. Defina o valor de gkeOnPremVersion como uma nova versão de patch. Este exemplo usa 1.14.1-gke.x.
2. 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.
  
  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 prepare e gkectl upgrade cluster, conforme descrito em Como fazer upgrade do Google Distributed Cloud.

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

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

O 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 Google Distributed Cloud executa automaticamente o 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 Google Distributed Cloud usa o Kubernetes drain comando 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.

Na versão 1.13 do Google Distributed Cloud, é possível verificar falhas na 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

O 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 sobre o status dos objetos da 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 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.

Remova as mudanças incompatíveis 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 silenciosamente ignoradas durante o upgrade, o que significa que essas alterações não precisam durante e após o upgrade.

Ao fazer upgrade dos clusters de usuário para a versão 1.28 ou mais recente, validamos todas as mudanças feita no arquivo de configuração e retornar um erro de alterações não suportadas, em vez de apenas ignorá-los. 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 vão entrar em vigor após o upgrade.

Por exemplo, se você tentar desativar o reparo automático de nós fizer upgrade de um cluster de usuário para a versão 1.28, o upgrade falhará com o seguinte erro mensagem:

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, você reverteria as mudanças feitas no AutoRepair config e, em seguida, execute gkectl upgrade novamente.
Outra opção é gerar arquivos de configuração que correspondam estado do cluster executando gkectl get-config. atualize os campos gkeOnPremVersion do cluster e dos pools de nós o arquivo de configuração e execute o gkectl upgrade novamente.

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 as permissões e o acesso das suas contas de usuário do vCenter e coletar registros do vSphere.

Recriar o arquivo kubeconfig do cluster de usuário ausente

Talvez você queira recriar um arquivo kubeconfig de cluster de usuário no comando a seguir: 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 kubeconfig.
Se o arquivo kubeconfig do cluster kubeconfig 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 kubeconfig para o cluster de usuário.
ADMIN_CLUSTER_KUBECONFIG é o caminho do arquivo kubeconfig para o cluster de administrador.

A seguir

Se precisar de mais ajuda, entre em contato com o Cloud Customer Care.