Versão 1.4. Esta versão não é mais compatível, conforme descrito na Política de suporte da versão do Anthos. Para ver os patches e as atualizações mais recentes sobre vulnerabilidades de segurança, exposições e problemas que afetam os clusters do Anthos no VMware (GKE On-Prem), faça o upgrade para uma versão compatível. Você pode encontrar a versão mais recente neste link.

Versões disponíveis

Solução de problemas

Nas seções a seguir, descrevemos os problemas que podem ser encontrados ao usar o GKE On-Prem e como resolvê-los.

Antes de começar

Verifique as seções a seguir antes de começar a resolver um problema.

Como diagnosticar problemas de cluster usando `gkectl`

Use os comandos gkectl diagnose para identificar problemas de cluster e compartilhar informações do cluster com o Google. Consulte Como diagnosticar problemas de cluster.

Como executar comandos `gkectl` de maneira detalhada

-v5

Como registrar erros `gkectl` em `stderr`

--alsologtostderr

Como localizar registros `gkectl` na estação de trabalho do administrador

Mesmo que você não transmita as sinalizações de depuração, é possível visualizar os registros gkectl no seguinte diretório da estação de trabalho do administrador:

/home/ubuntu/.config/gke-on-prem/logs

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, tente depurar isso inspecionando os registros dos controladores da API Cluster no cluster de administrador:

Encontre o nome do pod de controladores da API Cluster no namespace kube-system, em que [ADMIN_CLUSTER_KUBECONFIG] é o caminho para o arquivo kubeconfig do cluster de administrador:
```
kubectl --kubeconfig [ADMIN_CLUSTER_KUBECONFIG] -n kube-system get pods | grep clusterapi-controllers
```
Abra os registros do pod, em que [POD_NAME] é o nome do pod. Opcionalmente, use grep ou uma ferramenta semelhante para pesquisar erros:
```
kubectl --kubeconfig [ADMIN_CLUSTER_KUBECONFIG] -n kube-system logs [POD_NAME] vsphere-controller-manager
```

Instalação

Como depurar problemas de F5 BIG-IP com o kubeconfig do nó do plano de controle do cluster de administrador

Após uma instalação, o GKE On-Prem gera um arquivo kubeconfig no diretório inicial da estação de trabalho do administrador denominado internal-cluster-kubeconfig-debug. Esse arquivo kubeconfig é idêntico ao kubeconfig do cluster de administrador, com a diferença de que ele aponta diretamente para o nó do plano de controle do cluster de administrador, em que o plano de controle de administrador é executado. É possível usar o arquivo internal-cluster-kubeconfig-debug para depurar problemas de F5 BIG-IP.

Falha na validação de `gkectl check-config`: não é possível encontrar partições de F5 BIG-IP

Sintomas: A validação falha porque não são encontradas partições de F5 BIG-IP, embora elas existam.
Causas possíveis: Um problema com a API F5 BIG-IP pode causar falha na validação.
Resolução: Tente executar gkectl check-config novamente.

Falha em `gkectl prepare --validate-attestations`: não foi possível validar o atestado de versão

Sintomas

Executar gkectl prepare com a sinalização --validate-attestations opcional retorna o seguinte erro:

could not validate build attestation for gcr.io/gke-on-prem-release/.../...: VIOLATES_POLICY

Causas possíveis

Um atestado pode não existir para as imagens afetadas.

Resolução

Tente fazer o download e implantar o OVA da estação de trabalho de administrador novamente, conforme instruído em Como criar uma estação de trabalho de administrador. Se o problema persistir, entre em contato com o Google para receber ajuda.

Como depurar usando os registros do cluster de inicialização

Durante a instalação, o GKE On-Prem cria um cluster temporário de inicialização. Após uma instalação bem-sucedida, o GKE On-Prem exclui o cluster de inicialização, deixando você com o cluster de administrador e de usuário. Geralmente, não há motivo para interagir com esse cluster.

Se algo der errado durante uma instalação e você tiver transmitido --cleanup-external-cluster=false para gkectl create cluster, talvez seja útil realizar a depuração usando os registros do cluster de inicialização. Encontre o pod e receba os registros dele:

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

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

Plug-in de autenticação para Anthos

Falha ao executar `gkectl create-login-config`

Problema 1:

Sintomas

Ao executar gkectl create-login-config, você encontra o seguinte erro:

Error getting clientconfig using [user_cluster_kubeconfig]

Causas possíveis

Esse erro significa que o arquivo kubeconfig transmitido para gkectl create-login-config não serve para um cluster de usuário ou que o CRD ClientConfig não foi acionado durante a criação do cluster.

Resolução

Execute o seguinte comando para ver se o CRD ClientConfig está no cluster:

$ kubectl --kubeconfig
  [user_cluster_kubeconfig] get clientconfig default -n kube-public

Problema 2:

Sintomas

Ao executar gkectl create-login-config, você encontra o seguinte erro:

error merging with file [merge_file] because [merge_file] contains a
  cluster with the same name as the one read from [kubeconfig]. Please write to
  a new output file

Causas possíveis

Cada arquivo de configuração de login precisa conter nomes exclusivos de cluster. Se você vir esse erro, o arquivo em que estiver gravando os dados de configuração de login conterá um nome de cluster que já existe no arquivo de destino.

Resolução

Grave em um novo arquivo --output. Observe o seguinte:

Se --output não for fornecido, os dados de configuração de login serão gravados em um arquivo chamado kubectl-anthos-config.yaml no diretório atual por padrão.
Se --output já existir, o comando tentará mesclar a nova configuração de login com o --output.

Falha ao executar `gcloud anthos auth login`

Problema 1:

Sintomas: Falha ao executar login usando o plug-in de autenticação e o arquivo YAML gerado de configuração de login.
Causas possíveis: Pode haver um erro nos detalhes de configuração do OIDC.
Resolução: Verifique o registro do cliente OIDC com o administrador.

Problema 2:

Sintomas: Quando um proxy é configurado para tráfego HTTPS, a execução do comando gcloud anthos auth login falha com proxyconnect tcp na mensagem de erro. Um exemplo do tipo de mensagem que pode ser exibida é proxyconnect tcp: tls: first record does not look like a TLS handshake.
Causas possíveis: Pode haver um erro nas configurações da variável de ambiente https_proxy ou HTTPS_PROXY. Se houver um https:// especificado nas variáveis de ambiente, as bibliotecas de cliente HTTP do GoLang poderão falhar se o proxy estiver configurado para processar conexões HTTPS usando outros protocolos, como SOCK5.
Resolução: Modifique as variáveis de ambiente https_proxy e HTTPS_PROXY para omitir o prefixo https://. No Windows, modifique as variáveis de ambiente do sistema. Por exemplo, altere o valor da variável de ambiente https_proxy de https://webproxy.example.com:8000 para webproxy.example.com:8000.

Falha ao usar o kubeconfig gerado por `gcloud anthos auth login` para acessar o cluster

Sintomas

Erro "Não autorizado"

Se houver um erro "Não autorizado" ao usar o kubeconfig gerado por gcloud anthos auth login para acessar o cluster, isso significa que o apiserver não pode autorizar o usuário.

Causas possíveis

Os RBACs apropriados estão ausentes ou incorretos ou há um erro na configuração do OIDC para o cluster.

Resolução

Siga estas etapas para tentar resolver o problema:

Analise o id-token do kubeconfig.

No arquivo kubeconfig que foi gerado pelo comando de login, copie o id-token:
```
kind: Config
…
users:
- name: …
  user:
    auth-provider:
      config:
        id-token: [id-token]
        …
```
Siga as etapas para instalar o jwt-cli e executar:
```
$ jwt [id-token]
```
Verificar a configuração do OIDC

A seção oidc preenchida em config.yaml, que foi usado para criar o cluster, contém os campos group e username, que são usados para definir as sinalizações --oidc-group-claim e --oidc-username-claim no apiserver. Quando o analisador é apresentado com o token, ele procura essa reivindicação de grupo e de nome de usuário e verifica se o grupo ou usuário correspondente tem as permissões corretas.

Verifique se as reivindicações definidas para group e user na seção oidc de config.yaml estão presentes no id-token.
Verifique os RBACs que foram aplicados.

Verifique se há um RBAC com as permissões corretas para o usuário especificado pela reivindicação de nome de usuário ou para um dos grupos listados na reivindicação de grupo da etapa anterior. O nome do usuário ou grupo no RBAC precisa ter o prefixo usernameprefix ou groupprefix fornecido na seção oidc de config.yaml.

Se usernameprefix for deixado em branco e username for um valor diferente de email, o prefixo será padronizado como issuerurl#. Para desativar os prefixos de nome de usuário, usernameprefix deve ser definido como -.

Para mais informações sobre prefixos de usuários e grupos, consulte Como preencher a especificação oidc.

Observe que o servidor da API Kubernetes atualmente trata uma barra invertida como um caractere de escape. Portanto, se o nome do usuário ou do grupo contiver \\, o servidor da API o lerá como um único \ ao analisar o id_token. Portanto, o RBAC aplicado a esse usuário ou grupo deve conter somente uma única barra invertida. Caso contrário, você verá um erro Unauthorized.

Exemplo:

config.yaml:
```
oidc:
    issuerurl:
    …
    username: "unique_name"
    usernameprefix: "-"
    group: "group"
    groupprefix: "oidc:"
    ...
```
id_token:
```
{
  ...
  "email": "cluster-developer@example.com",
  "unique_name": "EXAMPLE\\cluster-developer",
  "group": [
    "Domain Users",
    "EXAMPLE\\developers"
],
  ...
}
```
Os seguintes RBACs concederiam a esse usuário permissões de administrador de cluster (observe a barra única no campo de nome em vez de uma barra dupla):

Group RBAC:
```
apiVersion:
kind:
metadata:
   name: example-binding
subjects:
-  kind: Group
   name: "oidc:EXAMPLE\developers"
   apiGroup: rbac.authorization.k8s.io
   roleRef:
     kind: ClusterRole
     name: pod-reader
     apiGroup: rbac.authorization.k8s.io
```
User RBAC:
```
apiVersion:
kind:
metadata:
   name: example-binding
subjects:
-  kind: User
               name: "EXAMPLE\cluster-developer"
               apiGroup: rbac.authorization.k8s.io
           roleRef:
           kind: ClusterRole
               name: pod-reader
               apiGroup: rbac.authorization.k8s.io
```
Verificar os registros do servidor da API

Se o plug-in OIDC configurado no kube apiserver não for iniciado corretamente, o servidor da API retornará um erro "Não autorizado" quando apresentado com o id-token. Para ver se houve algum problema com o plug-in OIDC no servidor da API, execute:
```
$ kubectl
      --kubeconfig=[admin_cluster_kubeconfig] logs statefulset/kube-apiserver -n
      [user_cluster_name]
```

Sintomas

Não é possível se conectar ao servidor: recebe {DISCOVERY_ENDPOINT}: x509: certificado assinado por autoridade desconhecida

Causas possíveis

O token de atualização no kubeconfig expirou.

Resolução

Execute o comando login novamente.

Veja a seguir erros comuns que podem ocorrer ao usar o Console do Cloud para tentar fazer login:

O login redireciona para a página com o erro "URL não encontrado"

Sintomas

O Console do Cloud não consegue alcançar o provedor de identidade do GKE On-Prem.

Causas possíveis

O Console do Cloud não consegue alcançar o provedor de identidade do GKE On-Prem.

Resolução

Siga estas etapas para tentar resolver o problema:

Defina useHTTPProxy como true

Se o IDP não estiver acessível pela Internet pública, você precisará ativar o proxy OIDC HTTP para fazer login por meio do Console do Cloud. Na seção oidc de config.yaml, usehttpproxy deve ser definido como true. Se você já tiver criado um cluster e quiser ativar o proxy, será possível editar o CRD ClientConfig diretamente. Execute $ kubectl edit clientconfig default -n kube-public e altere useHTTPProxy para true.
useHTTPProxy já está definido como true

Se o proxy HTTP estiver ativado e você ainda estiver vendo esse erro, pode ter ocorrido um problema na inicialização do proxy. Para acessar os registros do proxy, execute $ kubectl logs deployment/clientconfig-operator -n kube-system. Mesmo que seu IDP tenha uma CA conhecida, para que o proxy http seja iniciado, o campo capath na seção oidc de config.yaml precisa ser fornecido.
Prompts de IDP para consentimento

Se o servidor de autorização solicitar consentimento e você não tiver incluído o extraparam prompt=consent, talvez esse erro apareça. Execute $ kubectl edit clientconfig default -n kube-public, adicione prompt=consent a extraparams e tente fazer login novamente.
Os RBACs estão configurados incorretamente

Se você ainda não tiver feito isso, tente fazer a autenticação usando o Plug-in de autenticação para Anthos. Se você também estiver vendo um erro de autorização ao fazer login com o plug-in, siga as etapas de solução de problemas para resolver o problema com o plug-in e tente fazer login novamente pelo Console do Cloud.
Tente sair e fazer login novamente

Em alguns casos, se algumas configurações forem alteradas no serviço de armazenamento, talvez seja necessário sair explicitamente. Acesse a página de detalhes do cluster, clique em Sair e tente fazer login novamente.

Estação de trabalho do administrador

`AccessDeniedException` durante o download do OVA

Sintomas

A tentativa de fazer o download do OVA e da assinatura da estação de trabalho de administrador retorna o seguinte erro:

AccessDeniedException: 403 whitelisted-service-account@project.iam.gserviceaccount.com does not have storage.objects.list access to gke-on-prem-release

Causas possíveis

Sua conta de serviço permitida não está ativada.

Resolução

Verifique se você ativou sua conta de serviço permitida. Se o problema persistir, entre em contato com o Google para receber ajuda.

`openssl` não pode validar o OVA da estação de trabalho de administrador

Sintomas: Executar openssl dgst no arquivo OVA da estação de trabalho de administrador não retorna Verified OK
Causas possíveis: Há um problema no arquivo OVA que impede a validação bem-sucedida.
Resolução: Tente fazer o download e implantar o OVA da estação de trabalho de administrador novamente, conforme descrito em Fazer o download do OVA da estação de trabalho de administrador . Se o problema persistir, entre em contato com o Google para receber ajuda.

Conectar

Não é possível registrar um cluster de usuário

Se você encontrar problemas com o registro de clusters de usuário, entre em contato com o Google para receber ajuda.

O registro do cluster criado durante a versão Alfa foi cancelado

Consulte Como registrar um cluster de usuário na documentação do Connect.

Também é possível excluir e recriar o cluster.

Armazenamento

Falha ao anexar o volume

Sintomas

A saída de gkectl diagnose cluster é semelhante a esta:

Checking cluster object...PASS
Checking machine objects...PASS
Checking control plane pods...PASS
Checking gke-connect pods...PASS
Checking kube-system pods...PASS
Checking gke-system pods...PASS
Checking storage...FAIL
    PersistentVolume pvc-776459c3-d350-11e9-9db8-e297f465bc84: virtual disk "[datastore_nfs] kubevols/kubernetes-dynamic-pvc-776459c3-d350-11e9-9db8-e297f465bc84.vmdk" IS attached to machine "gsl-test-user-9b46dbf9b-9wdj7" but IS NOT listed in the Node.Status
1 storage errors

Um ou mais pods estão parados no estado ContainerCreating com um aviso como este:

Events:
  Type     Reason              Age               From                     Message
  ----     ------              ----              ----                     -------
  Warning  FailedAttachVolume  6s (x6 over 31s)  attachdetach-controller  AttachVolume.Attach failed for volume "pvc-776459c3-d350-11e9-9db8-e297f465bc84" : Failed to add disk 'scsi0:6'.

Causas possíveis

Se um disco virtual estiver anexado à máquina virtual errada, pode ser devido ao problema nº 32727 no Kubernetes 1.12.

Resolução

Se um disco virtual estiver anexado à máquina virtual errada, talvez seja necessário desanexá-lo manualmente:

Drene o nó. Consulte Drenar um nó com segurança. Convém incluir as sinalizações --ignore-daemonsets e --delete-local-data no comando kubectl drain.
Desligue a VM.
Edite a configuração de hardware da VM no vCenter para remover o volume.
Ligue a VM
Desfaça o nó.

O volume foi perdido

Sintomas

A saída de gkectl diagnose cluster é semelhante a esta:

Checking cluster object...PASS
Checking machine objects...PASS
Checking control plane pods...PASS
Checking gke-connect pods...PASS
Checking kube-system pods...PASS
Checking gke-system pods...PASS
Checking storage...FAIL
    PersistentVolume pvc-52161704-d350-11e9-9db8-e297f465bc84: virtual disk "[datastore_nfs] kubevols/kubernetes-dynamic-pvc-52161704-d350-11e9-9db8-e297f465bc84.vmdk" IS NOT found
1 storage errors

Um ou mais pods estão parados no estado ContainerCreating com um aviso como este:

Events:
  Type     Reason              Age                   From                                    Message
  ----     ------              ----                  ----                                    -------
  Warning  FailedAttachVolume  71s (x28 over 42m)    attachdetach-controller                 AttachVolume.Attach failed for volume "pvc-52161704-d350-11e9-9db8-e297f465bc84" : File []/vmfs/volumes/43416d29-03095e58/kubevols/
  kubernetes-dynamic-pvc-52161704-d350-11e9-9db8-e297f465bc84.vmdk was not found

Causas possíveis

Se você vir um erro "não encontrado" relacionado ao arquivo VMDK, é provável que o disco virtual tenha sido excluído permanentemente. Isso pode acontecer se um operador excluir manualmente um disco virtual ou a máquina virtual ao qual estiver anexado. Para evitar isso, gerencie suas máquinas virtuais conforme descrito em Como redimensionar um cluster de usuário e Como fazer upgrade de clusters

Resolução

Se um disco virtual foi excluído permanentemente, talvez seja necessário limpar manualmente os recursos relacionados do Kubernetes:

Execute kubectl delete pvc [PVC_NAME]. para excluir o PVC que faz referência ao PV
Execute kubectl delete pod [POD_NAME]. para excluir o pod que faz referência ao PVC
Repita a etapa 2. (Sim, na verdade. Consulte o problema 74374 do Kubernetes.)

Upgrades

Sobre a inatividade durante upgrades

Recurso	Descrição
Cluster de administrador	Quando um cluster de administrador fica inativo, os planos de controle do cluster de usuário e as cargas de trabalho em clusters de usuário continuam em execução, a menos que tenham sido afetados por uma falha que causou a inatividade.
Plano de controle do cluster de usuário	Normalmente, não há inatividade perceptível nos planos de controle do cluster de usuário. No entanto, conexões de longa duração com o servidor da API Kubernetes podem falhar e precisam ser restabelecidas. Nesses casos, o autor da chamada da API precisa tentar novamente até estabelecer uma conexão. No pior dos casos, pode haver até um minuto de inatividade durante um upgrade. Observação: se os nós do cluster de usuário não conseguirem alcançar o plano de controle do usuário durante o upgrade, novas cargas de trabalho não serão programadas para o cluster. As cargas de trabalho já existentes não são afetadas.
Nós do cluster de usuário	Se um upgrade exigir uma alteração nos nós do cluster de usuário, o GKE On-Prem recriará os nós de maneira contínua e reagendará os pods em execução nesses nós. É possível evitar o impacto nas suas cargas de trabalho configurando PodDisruptionBudgets e regras antiafinidade apropriados (links em inglês).

Como redimensionar clusters de usuário

Falha no redimensionamento de um cluster de usuário

Sintomas

Falha na operação de redimensionamento em um cluster de usuário.

Causas possíveis

Vários fatores podem causar falhas nas operações de redimensionamento.

Resolução

Se um redimensionamento falhar, siga estas etapas:

Verifique o status de MachineDeployment do cluster para ver se há eventos ou mensagens de erro:
```
kubectl describe machinedeployments [MACHINE_DEPLOYMENT_NAME]
```
Verifique se há erros nas máquinas recém-criadas:
```
kubectl describe machine [MACHINE_NAME]
```

Erro: "nenhum endereço pode ser alocado"

Sintomas

Depois de redimensionar um cluster de usuário, kubectl describe machine [MACHINE_NAME] exibe o seguinte erro:

Events:
   Type     Reason  Age                From                    Message
   ----     ------  ----               ----                    -------
   Warning  Failed  9s (x13 over 56s)  machineipam-controller  ipam: no addresses can be allocated

Causas possíveis

Não há endereços IP suficientes disponíveis para o cluster de usuário.

Resolução

Aloque mais endereços IP para o cluster. Em seguida, exclua a máquina afetada:

kubectl delete machine [MACHINE_NAME]

Se o cluster estiver configurado corretamente, uma máquina de substituição será criada com um endereço IP.

Número suficiente de endereços IP alocados, mas a máquina não é registrada no cluster

Sintomas: A rede tem endereços suficientes alocados, mas ainda assim a máquina não é registrada no cluster de usuário.
Causas possíveis: Pode haver um conflito de IP. O IP pode ser usado por outra máquina ou pelo balanceador de carga.
Resolução: Verifique se o endereço IP da máquina afetada não foi usado. Se houver um conflito, você precisará resolvê-lo no seu ambiente.

vSphere

Depuração com `govc`

Se você encontrar problemas específicos ao vSphere, use o govc para solucionar problemas. Por exemplo, é possível confirmar facilmente as permissões e o acesso das suas contas de usuário do vCenter e coletar registros do vSphere.

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

Recupere o novo certificado do vCenter e salve-o em um arquivo:

true | openssl s_client -connect [VCENTER_IP_ADDRESS]:443 -showcerts 2>/dev/null | sed -ne '/-BEGIN/,/-END/p' > vcenter.pem

Agora, para cada cluster, exclua o ConfigMap que contém o certificado do vSphere e do vCenter de cada cluster e crie um novo ConfigMap com o novo certificado. Exemplo:

kubectl --kubeconfig kubeconfig delete configmap vsphere-ca-certificate -n kube-system

kubectl --kubeconfig kubeconfig delete configmap vsphere-ca-certificate -n user-cluster1

kubectl --kubeconfig kubeconfig create configmap -n user-cluster1 --dry-run vsphere-ca-certificate --from-file=ca.crt=vcenter.pem  -o yaml  | kubectl --kubeconfig kubeconfig apply -f -

kubectl --kubeconfig kubeconfig create configmap -n kube-system --dry-run vsphere-ca-certificate --from-file=ca.crt=vcenter.pem  -o yaml  | kubectl --kubeconfig kubeconfig apply -f -

Exclua o pod clusterapi-controllers de cada cluster. Quando o pod é reiniciado, ele começa a usar o novo certificado. Exemplo:

kubectl --kubeconfig kubeconfig -n kube-system get pods

kubectl --kubeconfig kubeconfig -n kube-system delete pod clusterapi-controllers-...

Diversos

Limite de sessão no provedor do vSphere do Terraform

O GKE On-Prem usa o provedor do vSphere do Terraform para abrir VMs no ambiente vSphere. O limite de sessões no provedor é de 1.000 sessões. A implementação atual não fecha as sessões ativas após o uso. Podem ocorrer erros 503 se você tiver muitas sessões em execução.

As sessões são fechadas automaticamente após 300 segundos.

Sintomas

Se você tiver muitas sessões em execução, talvez você encontre o seguinte erro:

Error connecting to CIS REST endpoint: Login failed: body:
  {"type":"com.vmware.vapi.std.errors.service_unavailable","value":
  {"messages":[{"args":["1000","1000"],"default_message":"Sessions count is
  limited to 1000. Existing sessions are 1000.",
  "id":"com.vmware.vapi.endpoint.failedToLoginMaxSessionCountReached"}]}},
  status: 503 Service Unavailable

Causas possíveis

Há muitas sessões de provedor do Terraform em execução no seu ambiente.

Resolução

No momento, isso está funcionando conforme o esperado. As sessões são fechadas automaticamente após 300 segundos. Para mais informações, consulte o problema nº 618 no GitHub.

Como usar um proxy para o Docker: `oauth2: cannot fetch token`

Sintomas

Ao usar um proxy, você encontra o seguinte erro:

oauth2: cannot fetch token: Post https://oauth2.googleapis.com/token: proxyconnect tcp: tls: oversized record received with length 20527

Causas possíveis

É possível que você tenha fornecido um proxy HTTPS em vez de HTTP.

Resolução

Na configuração do Docker, altere o endereço do proxy para http:// em vez de https://.

Como verificar se as licenças são válidas

Lembre-se de verificar se as licenças são válidas, especialmente se você estiver usando licenças de teste. Pode haver falhas inesperadas se as licenças F5, host ESXi ou vCenter tiverem expirado.

Solução de problemas

Antes de começar

Como diagnosticar problemas de cluster usando gkectl

Como executar comandos gkectl de maneira detalhada

Como registrar erros gkectl em stderr

Como localizar registros gkectl na estação de trabalho do administrador

Como localizar registros da API Cluster no cluster de administrador

Instalação

Como depurar problemas de F5 BIG-IP com o kubeconfig do nó do plano de controle do cluster de administrador

Falha na validação de gkectl check-config: não é possível encontrar partições de F5 BIG-IP

Falha em gkectl prepare --validate-attestations: não foi possível validar o atestado de versão

Como depurar usando os registros do cluster de inicialização

Plug-in de autenticação para Anthos

Falha ao executar gkectl create-login-config

Falha ao executar gcloud anthos auth login

Falha ao usar o kubeconfig gerado por gcloud anthos auth login para acessar o cluster

Login no Console do Google Cloud

O login redireciona para a página com o erro "URL não encontrado"

Estação de trabalho do administrador

AccessDeniedException durante o download do OVA

openssl não pode validar o OVA da estação de trabalho de administrador

Conectar

Não é possível registrar um cluster de usuário

O registro do cluster criado durante a versão Alfa foi cancelado

Armazenamento

Falha ao anexar o volume

Sintomas

Causas possíveis

Resolução

O volume foi perdido

Sintomas

Causas possíveis

Resolução

Upgrades

Sobre a inatividade durante upgrades

Como redimensionar clusters de usuário

Falha no redimensionamento de um cluster de usuário

Erro: "nenhum endereço pode ser alocado"

Número suficiente de endereços IP alocados, mas a máquina não é registrada no cluster

vSphere

Depuração com govc

Como alterar o certificado do vCenter

Diversos

Limite de sessão no provedor do vSphere do Terraform

Como usar um proxy para o Docker: oauth2: cannot fetch token

Como verificar se as licenças são válidas

Como diagnosticar problemas de cluster usando `gkectl`

Como executar comandos `gkectl` de maneira detalhada

Como registrar erros `gkectl` em `stderr`

Como localizar registros `gkectl` na estação de trabalho do administrador

Falha na validação de `gkectl check-config`: não é possível encontrar partições de F5 BIG-IP

Falha em `gkectl prepare --validate-attestations`: não foi possível validar o atestado de versão

Falha ao executar `gkectl create-login-config`

Falha ao executar `gcloud anthos auth login`

Falha ao usar o kubeconfig gerado por `gcloud anthos auth login` para acessar o cluster

`AccessDeniedException` durante o download do OVA

`openssl` não pode validar o OVA da estação de trabalho de administrador

Depuração com `govc`

Como usar um proxy para o Docker: `oauth2: cannot fetch token`