Solução de problemas de isolamento de rede no GKE

Nesta página, mostramos como resolver problemas com o isolamento de rede do Google Kubernetes Engine (GKE).

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

Cluster do GKE não em execução

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

Sintomas
Os clusters criados na versão 1.28 ou anterior com nós particulares exigem uma rota de peering entre VPCs. No entanto, apenas uma operação de peering pode acontecer por vez. Se você tentar criar vários clusters com as características anteriores ao mesmo tempo, a criação do cluster poderá expirar.
Resolução

Use uma das seguintes soluções:

  • Crie clusters na versão 1.28 ou anterior em série para que as rotas de peering da VPC já existam para cada cluster subsequente sem um endpoint externo. A tentativa de criar um único cluster também poderá expirar se houver operações em execução na VPC.

  • Crie clusters na versão 1.29 ou mais recente.

A conexão de peering de rede VPC é 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:

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

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

O endpoint do Private Service Connect e a regra de encaminhamento são excluídos acidentalmente

Sintomas

Quando você exclui acidentalmente um endpoint ou uma regra de encaminhamento do Private Service Connect, 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 o acesso ao plano de controle está desconectado. 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 o endpoint do Private Service Connect ou a regra de encaminhamento. Os dois recursos são chamados gke-[cluster-name]-[cluster-hash:8]-[uuid:8]-pe e permitem que o plano de controle e os nós se conectem de forma particular.

Resolução

Gire o endereço IP do plano de controle.

Cluster se sobrepõe a um peering ativo

Sintomas

A tentativa de criar um cluster sem um endpoint externo 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

Use uma das seguintes soluções:

  • Exclua e recrie o cluster usando um CIDR de plano de controle diferente.
  • Recrie o cluster na versão 1.29 e inclua a flag --enable-private-nodes.

Não é possível acessar o plano de controle de um cluster sem um endpoint externo

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 sem um endpoint externo, a tentativa de executar comandos kubectl no cluster retorna um erro semelhante a um destes:

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

Use uma das seguintes soluções:

  • Ative o acesso DNS para uma maneira simplificada de acessar seu cluster com segurança. Para mais informações, consulte Endpoint baseado em DNS.

  • 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. 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(controlPlaneEndpointsConfig.ipEndpointsConfig.authorizedNetworksConfig)"\
      --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 Acessar com o endereço IP interno do plano de controle de qualquer região.

    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 "controlPlaneEndpointsConfig.ipEndpointsConfig.globalAccess"

      Substitua:

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

        enabled: true

    2. Se null for retornado, ative o acesso usando o endereço IP interno do plano de controle de qualquer região.

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

As seguintes configurações podem causar esse erro:

  • 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:

  1. 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.
  2. 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 uma sub-rede

Sintomas

Ao tentar criar um cluster com uma sub-rede automática ou uma sub-rede personalizada, você pode encontrar um destes erros:

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

Error: Error waiting for creating GKE cluster: Invalid value for field
PrivateClusterConfig.MasterIpv4CidrBlock: x.x.x.x/28 conflicts with an
existing subnet in one of the peered VPCs.
Causas possíveis

O intervalo CIDR do plano de controle especificado se sobrepõe a outro intervalo de IPs no cluster. Esse erro de criação de sub-rede também pode ocorrer se você estiver tentando reutilizar os CIDRs master-ipv4-cidr usados em um cluster excluído recentemente.

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 com endereços IP particulares só precisam de uma configuração adicional para atender aos requisitos de acesso à Internet. No entanto, os nós poderão acessar os serviços e as APIs do Google Cloud , incluindo o Artifact Registry, se você tiver ativado o Acesso privado do Google e atendido aos requisitos de rede.

Resolução

Use uma das seguintes soluções:

  • Copie as imagens no cluster 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 configurado 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 padrão com pools de nós particulares, ele trava na etapa de verificação de integridade e informa um erro semelhante a um dos seguintes:

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

As seguintes configurações podem causar esse erro:

  • 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 com nós particulares, ele informa um erro semelhante a um destes:

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

Verifique se você concluiu a configuração necessária do Container Registry ou do Artifact Registry.

Nós particulares criados, mas não estão se juntando ao cluster

Para clusters que usam apenas nós com endereços IP privados, muitas vezes, ao usar roteamento personalizado e dispositivos de rede de terceiros na VPC, 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 do GKE não conseguem acessar a Internet

Os pods em execução em nós com endereços IP particulares 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.

O acesso IP direto não pode ser desativado para clusters públicos.

Sintomas

Depois de desativar o endpoint do endereço IP, uma mensagem de erro semelhante a esta é exibida:

Direct IP access can't be disabled for public clusters
Causas possíveis

O cluster usa uma rede legada.

Resolução

Migre seus clusters para o Private Service Connect. Para mais informações sobre o status da migração, entre em contato com o suporte .

O acesso IP direto não pode ser desativado para clusters no meio da migração do PSC.

Sintomas

Depois de desativar o endpoint do endereço IP, uma mensagem de erro semelhante a esta é exibida:

Direct IP access can't be disabled for public clusters
Causas possíveis

O cluster usa uma rede legada.

Resolução

Use uma das seguintes soluções:

  • Recriar manualmente todos os pools de nós em uma versão diferente.
  • Aguarde até que o GKE atualize automaticamente os pools de nós durante um evento de manutenção.

O endpoint interno do plano de controle não pode ser ativado

Sintomas

Ao tentar ativar o endpoint interno do plano de controle do cluster, você recebe mensagens de erro semelhantes a esta:

private_endpoint_enforcement_enabled can't be enabled when envoy is disabled

private_endpoint_enforcement_enabled is unsupported. Please upgrade to the minimum support version
Causas possíveis

Seu cluster precisa fazer a rotação de endereços IP ou uma atualização de versão.

Resolução

Use uma das seguintes soluções:

A criação de cluster falha quando as políticas da organização são definidas

Sintomas

Ao tentar criar um cluster, você recebe uma mensagem de erro semelhante a esta:

compute.disablePrivateServiceConnectCreationForConsumers violated for projects
Causas possíveis

O endpoint ou back-end do cluster está bloqueado por uma política da organização do consumidor.

Resolução

Para permitir que as instâncias criem endpoints com a restrição compute.restrictPrivateServiceConnectProducer, siga as etapas em Políticas da organização do lado do consumidor.

O endpoint do Private Service Connect pode vazar durante a exclusão do cluster

Sintomas

Depois de criar um cluster, você pode notar um dos seguintes sintomas:

  • Não é possível conferir um endpoint conectado no Private Service Connect no seu Cluster baseado no Private Service Connect.

  • Não é possível excluir a sub-rede ou a rede VPC alocada para o endpoint interno em um cluster que usa o Private Service Connect. Uma mensagem de erro semelhante à seguinte aparece:

    projects/<PROJECT_ID>/regions/<REGION>/subnetworks/<SUBNET_NAME> is already being used by projects/<PROJECT_ID>/regions/<REGION>/addresses/gk3-<ID>
Causas possíveis

Nos clusters do GKE que usam o Private Service Connect, o GKE implanta um endpoint do Private Service Connect usando uma regra de encaminhamento que aloca um endereço IP interno para acessar o plano de controle do cluster na rede de um plano de controle. Para proteger a comunicação entre os controles e os nós usando o Private Service Connect, o GKE mantém o endpoint invisível e não é possível encontrá-lo no console doGoogle Cloud ou na CLI gcloud.

Resolução

Para evitar o vazamento do endpoint do Private Service Connect antes da exclusão do cluster, siga estas etapas:

  1. Atribua o Kubernetes Engine Service Agent role à conta de serviço do GKE.
  2. Verifique se as permissões compute.forwardingRules.* e compute.addresses.* não estão negadas explicitamente da conta de serviço do GKE.

Se o endpoint do Private Service Connect vazar, entre em contato com o suporte .

Não foi possível analisar a rede autorizada do cluster

Sintomas

Não é possível criar um cluster na versão 1.29 ou mais recente. Uma mensagem de erro semelhante à seguinte aparece:

Unable to parse cluster.master_ipv4_cidr "" into a valid IP address and mask
Causas possíveis

Seu projeto do Google Cloud usa webhooks privados baseados em IP. Portanto, não é possível criar um cluster com o Private Service Connect. Em vez disso, o cluster usa o peering de rede VPC, que analisa a flag master-ipv4-cidr.

Resolução

Use uma das seguintes soluções:

  • Continue a criar o cluster de peering de rede VPC e inclua o master-ipv4-cidr para definir CIDRs válidos. Essa solução tem as seguintes limitações:

    • A flag master-ipv4-cidr foi descontinuada no console Google Cloud . Para atualizar essa flag, só é possível usar a Google Cloud CLI ou o Terraform.
    • O VPC Network Peering foi descontinuado na versão 1.29 ou mais recente do GKE.

  • Migre seus webhooks baseados em IP particular seguindo as etapas em Limitações do Private Service Connect. Em seguida, entre em contato com o suporte para ativar o uso de clusters com o Private Service Connect.

Não é possível definir o intervalo de endereços IP interno em clusters com nós públicos

Sintomas

Não é possível definir um intervalo de endereços IP interno usando a flag --master-ipv4-cidr. Uma mensagem de erro semelhante a esta aparece:

ERROR: (gcloud.container.clusters.create) Cannot specify --master-ipv4-cidr
  without --enable-private-nodes
Causas possíveis

Você está definindo um intervalo de endereços IP interno para o plano de controle com a flag master-ipv4-cidr em um cluster sem a flag enable-private-nodes ativada. Para criar um cluster com master-ipv4-cidr definido, você precisa configurar o cluster para provisionar nós com endereços IP internos (nós particulares) usando a flag enable-private-nodes.

Resolução

Use uma das seguintes soluções:

  • Crie um cluster com o seguinte comando:

    gcloud container clusters create-auto CLUSTER_NAME \
    --enable-private-nodes \
    --master-ipv4-cidr CP_IP_RANGE

    Substitua:

    • CLUSTER_NAME: o nome do cluster.
    • CLUSTER_NAME: o intervalo de endereços IP interno do plano de controle.

  • Atualize o cluster para provisionar nós com apenas endereços IP. Para saber mais, consulte Configurar seu cluster.

Não é possível programar cargas de trabalho públicas em clusters do Autopilot

Sintomas
Em clusters do Autopilot, se o cluster usa apenas nós particulares, não é possível programar cargas de trabalho em pods públicos usando o nodeSelector cloud.google.com/private-node=false.
Causas possíveis
A configuração da flag private-node definida como false no nodeSelector do pod só está disponível em clusters da versão 1.30.3 ou mais recente.
Resolução
Faça upgrade do cluster para a versão 1.30 ou mais recente.

O acesso ao endpoint baseado em DNS está desativado

Sintomas

A tentativa de executar comandos kubectl no cluster retorna um erro semelhante ao seguinte:

couldn't get current server API group list:
control_plane_endpoints_config.dns_endpoint_config.allow_external_traffic is
disabled
Causas possíveis

O acesso baseado em DNS foi desativado no cluster.

Resolução

Ative o acesso ao plano de controle usando o endpoint baseado em DNS do plano de controle. Para saber mais, consulte Modificar o acesso ao plano de controle.

Os nós não conseguem alocar o endereço IP durante o escalonamento

Sintomas

A tentativa de expandir o intervalo de endereços IP principal da sub-rede para a lista de redes autorizadas retorna um erro semelhante ao seguinte:

 authorized networks fields cannot be mutated if direct IP access is disabled
Causas possíveis

Você desativou o endpoint baseado em IP do cluster.

Resolução

Desative e ative o endpoint baseado em IP do cluster usando a flag enable-ip-access.

Muitos blocos CIDR

gcloud retorna o seguinte erro ao tentar criar ou atualizar um cluster com mais de 50 blocos do CIDR:

ERROR: (gcloud.container.clusters.update) argument --master-authorized-networks: too many args

Para resolver esse problema, tente o seguinte:

Não foi possível estabelecer uma conexão com o servidor

Comandos kubectl expiram devido a blocos CIDR configurados incorretamente:

Unable to connect to the server: dial tcp MASTER_IP: getsockopt: connection timed out

Ao criar ou atualizar um cluster, assegure-se de especificar os blocos CIDR corretos.