Nesta página, mostramos como resolver problemas relacionados à instalação ou ao upgrade de clusters do 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 com a instalação do Google Distributed Cloud.
Mensagens de erro temporárias
O processo de instalação do Google Distributed Cloud é um loop de reconciliação contínuo. Como resultado, podem aparecer mensagens de erro transitórias no registro durante a instalação.
Desde que a instalação seja concluída com êxito, esses erros podem ser ignorados com segurança. Veja abaixo uma lista de mensagens de erros transitórias e comuns:
Internal error occurred: failed calling webhook "webhook.cert-manager.io": Post
https://cert-manager-webhook.cert-manager.svc:443/mutate?timeout=10s:
dial tcp IP_ADDRESS:443: connect: connection refused
Internal error occurred: failed calling webhook "vcluster.kb.io": Post
https://webhook-service.kube-system.svc:443/validate-baremetal-cluster-gke-io-v1-cluster?timeout=30s:
dial tcp IP_ADDRESS:443: connect: connection refused
Failed to register cluster with GKE Hub; gcloud output: error running command
'gcloud container fleet memberships register CLUSTER_NAME --verbosity=error --quiet':
error: exit status 1, stderr: 'ERROR: (gcloud.container.hub.memberships.register)
Failed to check if the user is a cluster-admin: Unable to connect to the server: EOF
Get
https://127.0.0.1:34483/apis/infrastructure.baremetal.cluster.gke.io/v1/namespaces/cluster-
cluster1/baremetalmachines: dial tcp 127.0.0.1:34483: connect: connection refused"
Create Kind Cluster "msg"="apply run failed" "error"="unable to recognize \"/tmp/kout088683152\": no matches for kind \"NetworkLogging\" in version \"networking.gke.io/v1alpha1\""
Create Kind Cluster "msg"="apply run failed" "error"="unable to recognize \"/tmp/kout869681888\": no matches for kind \"Provider\" in version \"clusterctl.cluster.x-k8s.io/v1alpha3\""
Se a chave da conta de serviço do Google Cloud tiver expirado, você verá as seguintes
mensagens de erro de bmctl
:
Error validating cluster config: 3 errors occurred:
* GKEConnect check failed: Get https://gkehub.googleapis.com/v1beta1/projects/project/locations/global/memberships/admin: oauth2: cannot fetch token: 400 Bad Request
Response: {"error":"invalid_grant","error_description":"Invalid JWT Signature."}
* ClusterOperations check failed: Post https://cloudresourcemanager.googleapis.com/v1/projects/project:testIamPermissions?alt=json&prettyPrint=false: oauth2: cannot fetch token: 400 Bad Request
Response: {"error":"invalid_grant","error_description":"Invalid JWT Signature."}
* GCR pull permission for bucket: artifacts.anthos-baremetal-release.appspot.com failed: Get https://storage.googleapis.com/storage/v1/b/artifacts.anthos-baremetal-release.appspot.com/iam/testPermissions?alt=json&permissions=storage.objects.get&permissions=storage.objects.list&prettyPrint=false: oauth2: cannot fetch token: 400 Bad Request
Response: {"error":"invalid_grant","error_description":"Invalid JWT Signature."}
É necessário gerar uma nova chave da conta de serviço.
Usar o cluster de inicialização para depurar problemas
Quando o Google Distributed Cloud cria clusters autogerenciados (de administrador, híbridos ou independentes), ele implanta um cluster (tipo) do Kubernetes no Docker para hospedar temporariamente os controladores do Kubernetes necessários para criar clusters. Esse cluster transitório é chamado de cluster de inicialização. Os clusters de usuário são criados e atualizados pelo cluster de administrador ou híbrido de gerenciamento sem o uso de um cluster de inicialização.
Se um cluster de tipo já existir na implantação quando você tentar instalar,
o Google Distributed Cloud excluirá o cluster de tipo atual. A exclusão só
ocorre depois que a instalação ou o upgrade são bem-sucedidos.
Para preservar o cluster de tipo atual mesmo após o sucesso, use a
sinalização --keep-bootstrap-cluster
de bmctl
.
O Google Distributed Cloud cria um arquivo de configuração para o cluster de inicialização
em WORKSPACE_DIR/.kindkubeconfig
. Só é possível se conectar ao
cluster de inicialização durante a criação e o upgrade dele.
O cluster de inicialização precisa acessar um repositório do Docker para extrair imagens. O
registro é o padrão para o Container Registry, a menos que você
esteja usando um registro particular. Durante a criação do cluster, bmctl
cria os seguintes arquivos:
bmctl-workspace/config.json
: contém as credenciais da conta de serviço do Google Cloud para o acesso ao registro. As credenciais são recebidas do campogcrKeyPath
no arquivo de configuração do cluster.bmctl-workspace/config.toml
: contém a configuração do containerd no cluster de tipo.
Examinar os registros do cluster de inicialização
Para depurar o cluster de inicialização, siga estas etapas:
- Conecte-se ao cluster de inicialização durante a criação e o upgrade do cluster.
- Receba os registros do cluster de inicialização.
É possível encontrar os registros na máquina que você usa para executar bmctl
nas seguintes
pastas:
bmctl-workspace/CLUSTER_NAME/log/create-cluster-TIMESTAMP/bootstrap-cluster/
bmctl-workspace/CLUSTER_NAME/log/upgrade-cluster-TIMESTAMP/bootstrap-cluster/
Substitua CLUSTER_NAME
e TIMESTAMP
pelo
nome do cluster e o horário do sistema correspondente.
Para acessar os registros do cluster de inicialização diretamente, execute o seguinte comando durante a criação e o upgrade do cluster:
docker exec -it bmctl-control-plane bash
O comando abre um terminal dentro do contêiner do plano de controle bmctl que é 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:
journalctl -u kubelet
journalctl -u containerd
Problemas de upgrade de cluster
Ao fazer upgrade dos clusters do Google Distributed Cloud, é possível monitorar o progresso e verificar o status dos seus clusters e nós.
- Se você tiver problemas durante um upgrade, tente determinar em que estágio a falha ocorre. Para saber mais sobre o que acontece com um cluster durante o processo de upgrade, consulte Ciclo de vida e etapas dos upgrades de cluster.
- Para saber mais sobre o impacto de um problema durante os upgrades de cluster, consulte Noções básicas sobre o impacto de falhas no Google Distributed Cloud.
As orientações a seguir podem ajudar a determinar se o upgrade continua normalmente ou se há um problema.
Monitorar o progresso do upgrade
Use o comando kubectl describe cluster
para ver o status de um cluster
durante o processo de upgrade:
kubectl describe cluster CLUSTER_NAME \
--namespace CLUSTER_NAMESPACE \
--kubeconfig ADMIN_KUBECONFIG
Substitua os seguintes valores:
CLUSTER_NAME
: o nome do cluster.CLUSTER_NAMESPACE
: o namespace do cluster.ADMIN_KUBECONFIG
: o arquivo kubeconfig do administrador.- Por padrão, os clusters de administrador, híbrido e autônomo usam um upgrade no local.
Se você usar a sinalização
--use-bootstrap=true
com o comandobmctl upgrade
, a operação de upgrade usará um cluster de inicialização. Para monitorar o progresso do upgrade quando um cluster de inicialização for usado, especifique o caminho para o arquivo kubeconfig do cluster de inicialização,.kindkubeconfig
. Esse arquivo está localizado no diretório do espaço de trabalho.
- Por padrão, os clusters de administrador, híbrido e autônomo usam um upgrade no local.
Se você usar a sinalização
Observe a seção Status
da saída, que mostra uma agregação do status de upgrade do cluster. Se o cluster relatar um erro, use as seções
a seguir para solucionar o problema.
Verificar se os nós estão prontos
Use o comando kubectl get nodes
para ver o status dos nós em um cluster
durante o processo de upgrade:
kubectl get nodes --kubeconfig KUBECONFIG
Para verificar se um nó concluiu o processo de upgrade, observe as colunas
VERSION
e AGE
na resposta do comando. O VERSION
é a
versão do Kubernetes do cluster. Para saber qual é a versão do Kubernetes de uma determinada
versão do Google Distributed Cloud, consulte Histórico de versões.
Se o nó mostrar NOT READY
, tente o conectar e verificar o status do
kubelet:
systemctl status kubelet
Você também pode analisar os registros do kubelet:
journalctl -u kubelet
Analise a saída do status do kubelet e os registros das mensagens que indicam por que o nó tem um problema.
Verificar qual nó está sendo atualizado
Para verificar qual nó do cluster está em processo de upgrade, use o
comando kubectl get baremetalmachines
:
kubectl get baremetalmachines --namespace CLUSTER_NAMESPACE \
--kubeconfig ADMIN_KUBECONFIG
Substitua os seguintes valores:
CLUSTER_NAMESPACE
: o namespace do cluster.ADMIN_KUBECONFIG
: o arquivo kubeconfig do administrador.- Se um cluster de inicialização for usado para um upgrade híbrido, de administrador ou separado, especifique o arquivo kubeconfig do cluster de inicialização
(
bmctl-workspace/.kindkubeconfig
).
- Se um cluster de inicialização for usado para um upgrade híbrido, de administrador ou separado, especifique o arquivo kubeconfig do cluster de inicialização
(
O exemplo de saída a seguir mostra que o nó que está sendo atualizado tem um ABM VERSION
diferente de DESIRED ABM VERSION
:
NAME CLUSTER READY INSTANCEID MACHINE ABM VERSION DESIRED ABM VERSION
10.200.0.2 cluster1 true baremetal://10.200.0.2 10.200.0.2 1.13.0 1.14.0
10.200.0.3 cluster1 true baremetal://10.200.0.3 10.200.0.3 1.13.0 1.13.0
Verificar quais nós estão no processo de drenagem
Durante o processo de upgrade, os nós são esvaziados dos pods, e a programação fica
desativada até que o upgrade do nó seja concluído. Para ver quais nós estão sendo drenados, use o comando kubectl get nodes
:
kubectl get nodes --kubeconfig USER_CLUSTER_KUBECONFIG | grep "SchedulingDisabled"
Substitua USER_CLUSTER_KUBECONFIG
pelo caminho para o
arquivo Kubeconfig do cluster de usuário.
A coluna STATUS
é filtrada usando grep
para mostrar apenas os nós que informam
SchedulingDisabled
. Esse status indica que os nós estão sendo drenados.
Também é possível verificar o status do nó do cluster de administrador:
kubectl get baremetalmachines -n CLUSTER_NAMESPACE \
--kubeconfig ADMIN_KUBECONFIG
Substitua os seguintes valores:
CLUSTER_NAMESPACE
: o namespace do cluster.ADMIN_KUBECONFIG
: o arquivo kubeconfig do administrador.- Se um cluster de inicialização for usado para um upgrade híbrido, de administrador ou separado, especifique o arquivo kubeconfig do cluster de inicialização
(
bmctl-workspace/.kindkubeconfig
).
- Se um cluster de inicialização for usado para um upgrade híbrido, de administrador ou separado, especifique o arquivo kubeconfig do cluster de inicialização
(
O nó que está sendo drenado mostra o status na coluna MAINTENANCE
.
Verifique por que um nó está no status de drenagem há muito tempo
Use um dos métodos na seção anterior para identificar o nó que está sendo drenado usando o comando kubectl get nodes
. Use o comando kubectl get
pods
e filtre o nome desse nó para ver mais detalhes:
kubectl get pods --all-namespaces -o wide --field-selector spec.nodeName=NODE_NAME
Substitua NODE_NAME
pelo nome do
nó que está sendo drenado. A saída retorna uma lista de pods que estão travados ou
são drenados com lentidão. O upgrade continua, mesmo com pods travados, quando o processo de drenagem em um nó leva mais de 20 minutos.
A partir da versão 1.29, o processo de drenagem de
nó usa a API Eviction, que respeita PodDisruptionBudgets
(PDBs).
As seguintes configurações de PDB podem causar problemas de drenagem de nós:
Pods gerenciados por vários PDBs
Configurações estáticas do PDB, como as seguintes:
maxUnavailable
==0
minUnavailable
>= total de réplicas
A contagem total de réplicas é difícil de determinar no recurso PDB, porque está definida em um recurso de nível superior, como
Deployment
,ReplicaSet
ouStatefulSet
. Os PDBs fazem a correspondência com pods com base no seletor somente na configuração. Uma boa abordagem para diagnosticar se uma configuração estática do PDB está causando um problema é verificar sepdb.Status.ExpectPods
<=pdb.Status.DesiredHealthy
primeiro e verificar se uma das configurações estáticas mencionadas permite que isso aconteça.
Violações no ambiente de execução, como o valor DisruptionsAllowed
calculado para um recurso
PDB como 0
, também podem bloquear a drenagem de nós. Se você tiver
objetos PodDisruptionBudget
configurados
que não permitam outras interrupções, talvez os upgrades de nó não consigam
fazer upgrade para a versão do plano de controle após várias tentativas. Para evitar essa
falha, recomendamos que você escalonar verticalmente Deployment
ou
HorizontalPodAutoscaler
para permitir que o nó seja drenado, respeitando a
configuração PodDisruptionBudget
.
Para conferir todos os objetos PodDisruptionBudget
que não permitem interrupções, use
o seguinte comando:
kubectl get poddisruptionbudget --all-namespaces \
-o jsonpath='{range .items[?(@.status.disruptionsAllowed==0)]}{.metadata.name}/{.metadata.namespace}{"\n"}{end}'
Verificar por que os pods não estão íntegros
Os upgrades poderão falhar se um pod contiver endereços IP do plano de controle upgrade-first-node
ou upgrade-node
. Esse comportamento geralmente ocorre porque os pods estáticos não estão íntegros.
Verifique os pods estáticos com o comando
crictl ps -a
e procure os pods do Kubernetes ouetcd
com falha. Se você tiver pods com falha, revise os registros dos pods para ver por que eles estão falhando.Veja algumas possibilidades de comportamento de loop de falhas:
- As permissões ou o proprietário de arquivos montados em pods estáticos não estão corretos.
- A conectividade com o endereço IP virtual não funciona.
- Problemas com
etcd
Se o comando
crictl ps
não funcionar ou não retornar nada, verifique o status dekubelet
econtainerd
. Use os comandossystemctl status SERVICE
ejournalctl -u SERVICE
para analisar os registros.
A seguir
- Se precisar de mais ajuda, entre em contato com o Cloud Customer Care.