Versão 1.7. Essa versão é compatível com a política de suporte da versão do Anthos, que oferece os patches e atualizações mais recentes para vulnerabilidades de segurança, exposições e problemas que afetam os clusters do Anthos no VMware (GKE On-Prem). Consulte as notas da versão para saber mais detalhes. Esta não é a versão mais recente.

Versões disponíveis

Solução de problemas na criação e no upgrade de clusters

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

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

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 aos clusters em execução sobre o novo certificado:

Recupere e descompacte o novo certificado do vCenter:
```
curl -k -o certs.zip https://VCENTER_IP_ADDRESS/certs/download.zip
unzip certs.zip
```
A sinalização -k permite certificados desconhecidos. Isso evita problemas de certificado que você possa ter com o vCenter.
Salve o certificado do Linux em um arquivo chamado vcenter-ca.pem:
```
cat certs/lin/*.0 > vcenter-ca.pem
```
No arquivo de configuração do cluster de administração, defina vCenter.caCertPath como o caminho do novo arquivo vcenter-ca.pem.
Use SSH para se conectar ao nó do plano de controle do cluster de administração.

No nó, substitua o conteúdo de /etc/vsphere/certificate/ca.crt pelo conteúdo de vcenter.pem.

Saia da conexão SSH.

Exclua os ConfigMaps do vcenter-ca-certificate. Existe um no namespace kube-system e outro em cada namespace de cluster de usuário. Exemplo:

kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG delete configmap vsphere-ca-certificate \
    --namespace kube-system
...
kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG delete configmap vsphere-ca-certificate \
    --namespace user-cluster1

Crie novos ConfigMaps com o novo certificado. Exemplo:

kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG create configmap \
    --namespace kube-system --dry-run vsphere-ca-certificate --from-file=ca.crt=vcenter.pem \
    --output yaml  | kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG apply -f -
...
kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG create configmap \
    --namespace user-cluster1 --dry-run vsphere-ca-certificate --from-file=ca.crt=vcenter.pem \
    --output yaml  | kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG apply -f -

Reiniciar o contêiner que contém os pods estáticos no plano de controle do administrador:
- Conecte-se via SSH à VM mestre do administrador.
- Execute docker restart.
Agora atualize os dados do certificado de CA na chave secreta "create-config" do administrador.
- Receba o secret e decodifique o valor data.cfg da saída:
```
kubectl get secret create-config -n kube-system -o jsonpath={.data.cfg} | base64 -d > admin-create-config.yaml
```
  `
- Compare o valor em admincluster.spec.cluster.vsphere.cacertdata com o novo certificado de CA do vCenter.
- Se os dois valores forem diferentes, você precisará editar o secret "admin-config" para adicionar o novo certificado de CA. No arquivo admin-create-config.yaml, copie o resultado da decodificação de base-64 e substitua o valor de admincluster.spec.cluster.vsphere.cacertdata pelo novo certificado CA do vCenter.
- Codifique o valor da etapa anterior: cat admin-create-config.yaml | base64 -w0 > admin-create-config.b64
- Edite o secret create-config e substitua o valor data.cfg pelo valor codificado:
```
kubectl --kubeconfig ADMIN_KUBECONFIG edit secrets -n kube-system create-config
```
Agora atualize os dados do certificado de CA nos secrets de criação e configuração dos clusters de usuário.

Edite o secret create-config e substitua o valor data.cfg pelo valor codificado em base64 que você criou na etapa anterior. Exemplo:
```
kubectl --kubeconfig ADMIN_KUBECONFIG edit secrets -n user-cluster-1 create-config
```

Exclua os pods a seguir nos clusters de usuários.

clusterapi-controllers
kube-controller-manager
kube-apiserver
vsphere-csi-controller
vsphere-metrics-exporter

Para ver os nomes dos pods, execute:

kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG get pods --all-namespaces | grep clusterapi
kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG get pods --all-namespaces | grep kube-controller-manager
kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG get pods --all-namespaces | grep kube-apiserver
kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG get pods --all-namespaces | grep vsphere-csi-controller
kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG get pods --all-namespaces | grep vsphere-metrics-exporter

Exclua os pods encontrados na etapa anterior:

kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG --namespace NAMESPACE \
    delete pod POD_NAME

Quando os pods forem reiniciados, eles usarão o novo certificado.

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

Nesse caso, salve o PDB e remova-o do cluster antes de tentar o upgrade. Em seguida, você poderá adicionar o PDB novamente após a conclusão do upgrade.