Solução de problemas de clusters particulares no GKE

Nesta página, mostramos como resolver problemas com clusters particulares do Google Kubernetes Engine (GKE).

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

O cluster particular não está em execução

Excluir o peering de VPC entre o plano de controle do cluster e os nós, excluir as regras de firewall que permitem o tráfego de entrada do plano de controle do cluster para nós na porta 10250 ou excluir a rota padrão para o gateway de Internet padrão faz com que o cluster privado pare de funcionar. Se você excluir a rota padrão, precisará garantir que o tráfego para os serviços necessários do Google Cloud seja roteado. Para mais informações, consulte roteamento personalizado.

Tempo limite ao criar um cluster particular

Cada cluster particular requer uma rota de peering entre VPCs, mas apenas uma operação de peering pode acontecer por vez. Se você tentar criar vários clusters particulares ao mesmo tempo, a criação do cluster poderá expirar. Para evitar isso, crie novos clusters particulares em série para que as rotas de peering da VPC já existam para cada cluster particular subsequente. A tentativa de criar um único cluster privado também poderá expirar se houver operações em execução na VPC.

A conexão de peering de rede VPC em um cluster particular é excluída acidentalmente

Sintomas

Quando você exclui uma conexão de peering de rede VPC acidentalmente, o cluster entra em um estado de reparo e todos os nós mostram um status UNKNOWN. Não é possível realizar nenhuma operação no cluster porque a acessibilidade ao plano de controle está desconectada. Quando você inspeciona o plano de controle, os registros exibem um erro semelhante ao seguinte:

error checking if node NODE_NAME is shutdown: unimplemented
Causas possíveis

Você excluiu acidentalmente a conexão de peering de rede VPC.

Resolução

Siga estas etapas:

  • Crie um novo cluster de peering de rede VPC temporário. A criação do cluster causa a recriação do peering de rede VPC, e o cluster antigo é restaurado para a operação normal.

  • Exclua o cluster de peering de rede VPC criado temporariamente após o reestabelecimento da operação normal no cluster antigo.

Cluster se sobrepõe a um peering ativo

Sintomas

A tentativa de criar um cluster privado retorna um erro semelhante ao seguinte:

Google Compute Engine: An IP range in the peer network overlaps with an IP
range in an active peer of the local network.
Causas possíveis

Você escolheu um CIDR de plano de controle sobreposto.

Resolução

Exclua e recrie o cluster usando um CIDR de plano de controle diferente.

Não é possível acessar o plano de controle de um cluster privado

Aumente a probabilidade de alcance do plano de controle do cluster implementando qualquer configuração de acesso ao endpoint do cluster. Para mais informações, consulte acesso a endpoints de cluster.

Sintomas

Depois de criar um cluster particular, a tentativa de executar comandos kubectl no cluster retorna um erro semelhante a um dos seguintes:

Unable to connect to the server: dial tcp [IP_ADDRESS]: connect: connection
timed out.

Unable to connect to the server: dial tcp [IP_ADDRESS]: i/o timeout.
Causas possíveis

kubectl é incapaz de se comunicar com o plano de controle do cluster.

Resolução

Verifique se as credenciais do cluster foram geradas para o kubeconfig ou se o contexto correto está ativado. Para mais informações sobre como configurar as credenciais do cluster, consulte Gerar entrada kubeconfig.

Verifique se o acesso ao plano de controle usando o endereço IP externo é permitido. Desativar o acesso externo ao plano de controle do cluster isola o cluster da Internet. Essa configuração é imutável após a criação do cluster. Com essa configuração, somente intervalos CIDR da rede interna autorizada ou rede reservada têm acesso ao plano de controle.

  1. Verifique se o endereço IP de origem está autorizado a acessar o plano de controle:

      gcloud container clusters describe CLUSTER_NAME \
      --format="value(masterAuthorizedNetworksConfig)"\
      --location=COMPUTE_LOCATION

    Substitua:

    Se o endereço IP de origem não estiver autorizado, a saída poderá retornar um resultado vazio (somente chaves) ou intervalos CIDR que não incluam o endereço IP de origem

    cidrBlocks:
  cidrBlock: 10.XXX.X.XX/32
  displayName: jumphost
  cidrBlock: 35.XXX.XXX.XX/32
  displayName: cloud shell
enabled: true

  2. Adicione redes autorizadas para acessar o plano de controle.

Se você executar o comando kubectl em um ambiente local ou em uma região diferente do local do cluster, verifique se o acesso global ao endpoint particular do plano de controle está ativado. Para mais informações, consulte Como acessar o endpoint particular do plano de controle globalmente.

  1. Descreva o cluster para conferir a resposta da configuração de controle de acesso:

    gcloud container clusters describe CLUSTER_NAME \
    --location=COMPUTE_LOCATION \
    --flatten "privateClusterConfig.masterGlobalAccessConfig"

    Substitua:

    A saída bem-sucedida é semelhante a esta:

      enabled: true

  2. Se null for retornado, ative o acesso global ao plano de controle.

Não é possível criar o cluster devido à sobreposição do bloco CIDR IPv4

Sintomas

gcloud container clusters create retorna um erro semelhante ao seguinte:

The given master_ipv4_cidr 10.128.0.0/28 overlaps with an existing network
10.128.0.0/20.
Causas possíveis

Você especificou um bloco CIDR do plano de controle que se sobrepõe a uma sub-rede na VPC.

Resolução

Especifique um bloco para --master-ipv4-cidr CIDR para que não se sobreponha a uma sub-rede atual.

Não é possível criar o cluster porque o intervalo de serviços já está em uso por outro cluster

Sintomas

A tentativa de criar um cluster privado retorna um erro semelhante ao seguinte:

Services range [ALIAS_IP_RANGE] in network [VPC_NETWORK], subnetwork
[SUBNET_NAME] is already used by another cluster.
Causas possíveis

Uma das seguintes:

  • Você escolheu um intervalo de serviços que ainda está em uso por outro cluster, ou o cluster não foi excluído.
  • Havia um cluster usando esse intervalo de serviços que foi excluído, mas os metadados de intervalos secundários não foram limpos corretamente. Os intervalos secundários de um cluster do GKE estão salvos nos metadados do Compute Engine e precisam ser removidos após a exclusão do cluster. Mesmo quando os clusters são excluídos, talvez os metadados não sejam removidos.
Resolução

Siga estas etapas:

  • Verifique se o intervalo de serviços está em uso por um cluster atual. É possível usar o comando gcloud container clusters list com a sinalização filter para pesquisar o cluster. Se houver um cluster existente usando os intervalos de serviços, você precisará excluir esse cluster ou criar um novo intervalo de serviços.
  • Se o intervalo de serviços não estiver em uso por um cluster existente, remova manualmente a entrada de metadados que corresponde ao intervalo de serviços que você quer usar.

Não é possível criar sub-rede

Sintomas

Quando você tenta criar um cluster particular com uma sub-rede automática ou tenta criar uma sub-rede personalizada, pode encontrar o seguinte erro:

An IP range in the peer network overlaps
with an IP range in one of the active peers of the local network.
Causas possíveis

O intervalo CIDR do plano de controle especificado se sobrepõe a outro intervalo de IPs no cluster. Isso também pode ocorrer se você excluiu recentemente um cluster particular e está tentando criar um novo cluster particular usando o mesmo painel de controle CIDR.

Resolução

Tente usar um intervalo CIDR diferente.

Não é possível extrair a imagem do Hub Docker público

Sintomas

Um pod em execução no cluster exibe um aviso em kubectl describe:

Failed to pull image: rpc error: code = Unknown desc = Error response
from daemon: Get https://registry-1.docker.io/v2/: net/http: request canceled
while waiting for connection (Client.Timeout exceeded while awaiting
headers)
Causas possíveis

Os nós em um cluster particular não têm endereços IP externos. Portanto, eles não atendem aos requisitos de acesso à Internet. No entanto, os nós poderão acessar serviços e APIs do Google, incluindo o Artifact Registry, se você tiver ativado o Acesso privado do Google e atender aos requisitos de rede.

Resolução

Use uma das seguintes soluções:

  • Copie as imagens no seu cluster privado do Docker Hub para o Artifact Registry. Consulte Como migrar contêineres de um registro de terceiros para mais informações.

  • O GKE verifica mirror.gcr.io automaticamente em busca de cópias em cache de imagens do Docker Hub acessadas com frequência.

  • Se você precisar extrair imagens do Docker Hub ou de outro repositório público, use o Cloud NAT ou um proxy baseado em instância que seja o destino de uma rota 0.0.0.0/0 estática.

Solicitação de API que aciona o tempo limite do webhook de admissão

Sintomas

Uma solicitação de API que aciona um webhook de admissão configurada para usar um serviço com um targetPort diferente de 443 expira, fazendo com que a solicitação falhe:

Error from server (Timeout): request did not complete within requested timeout 30s
Causas possíveis

Por padrão, o firewall não permite conexões TCP com nós, exceto nas portas 443 (HTTPS) e 10250 (kubelet). Um webhook de admissão que tentará se comunicar com um pod em uma porta diferente da 443 falhará se não houver uma regra de firewall personalizada que permita o tráfego.

Resolução

Adicione uma regra de firewall para o caso de uso específico.

Não foi possível criar o cluster devido a uma falha na verificação de integridade

Sintomas

Depois de criar um cluster particular, ele trava na etapa de verificação de integridade e informa um erro semelhante a este:

All cluster resources were brought up, but only 0 of 2 have registered.

All cluster resources were brought up, but: 3 nodes out of 4 are unhealthy
Causas possíveis

Qualquer um dos seguintes:

  • Os nós de cluster não podem fazer o download dos binários necessários da API Cloud Storage (storage.googleapis.com).
  • Regras de firewall que restringem o tráfego de saída.
  • As permissões de IAM da VPC compartilhada estão incorretas.
  • O Acesso privado do Google requer que você configure o DNS para *.gcr.io.
Resolução

Use uma das seguintes soluções:

O Kubelet não conseguiu criar o sandbox de pod

Sintomas

Depois de criar um cluster particular, ele informa um erro semelhante a um dos seguintes:

Warning  FailedCreatePodSandBox  12s (x9 over 4m)      kubelet  Failed to create pod sandbox: rpc error: code = Unknown desc = Error response from daemon: Get https://registry.k8s.io/v2/: net/http: request canceled while waiting for connection (Client.Timeout exceeded while awaiting headers)

NetworkReady=false reason:NetworkPluginNotReady message:docker: network plugin is not ready: cni config uninitialized
Causas possíveis

O pod calico-node ou netd não pode alcançar *.gcr.io.

Resolução

Use uma das seguintes soluções:

Os nós de cluster particulares foram criados, mas não estão mesclando com o cluster

Muitas vezes, ao usar roteamento personalizado e dispositivos de rede de terceiros na VPC que o cluster particular usa, a rota padrão (0.0.0.0/0) é redirecionada para o dispositivo, e não para o gateway de Internet padrão. Além da conectividade do plano de controle, você precisa garantir que os seguintes destinos estejam acessíveis:

  • *.googleapis.com
  • *.gcr.io
  • gcr.io

Configure o Acesso privado do Google nos três domínios. Essa prática recomendada permite que os novos nós sejam inicializados e se mesclem com o cluster, mantendo o tráfego vinculado à Internet restrito.

Cargas de trabalho em clusters particulares do GKE não podem acessar a Internet

Os pods em clusters particulares do GKE não podem acessar a Internet. Por exemplo, depois de executar o comando apt update do pod exec shell, ele informa um erro semelhante a este:

0% [Connecting to deb.debian.org (199.232.98.132)] [Connecting to security.debian.org (151.101.130.132)]

Se o intervalo de endereços IP secundários da sub-rede usado para pods no cluster não estiver configurado no gateway do Cloud NAT, os pods não poderão se conectar à Internet porque não terão um endereço IP externo configurado para o gateway do Cloud NAT.

Configure o gateway NAT do Cloud para aplicar pelo menos os seguintes intervalos de endereços IP de sub-rede para a sub-rede usada pelo cluster:

  • Intervalo de endereços IP principais de sub-rede (usado pelos nós)
  • Intervalo de endereços IP secundários da sub-rede usado para pods no cluster
  • Intervalo de endereços IP secundários da sub-rede usado para serviços no cluster

Para saber mais, consulte como adicionar um intervalo de IP de sub-rede secundário usado para pods.