Como criar um cluster particular


Nesta página, você aprende a criar um cluster particular do Google Kubernetes Engine (GKE), que é um tipo de cluster nativo de VPC. Em um cluster particular, os nós têm apenas endereços IP internos, o que significa que os nós e os pods estão isolados da Internet por padrão.

Os endereços IP internos para nós vêm do intervalo de endereços IP primário da sub-rede escolhida para o cluster. Os endereços IP do pod e os endereços IP de serviço vêm de dois intervalos de endereços IP secundários da mesma sub-rede. Para mais informações, consulte Intervalos de IP para clusters nativos de VPC.

As versões 1.14.2 e posteriores do GKE são compatíveis com quaisquer intervalos de endereços IP internos, incluindo intervalos particulares (RFC 1918 e outros intervalos particulares) e intervalos particulares de endereços IP públicos. Consulte a documentação da VPC para ver uma lista de intervalos de endereços IP internos válidos.

Para saber mais sobre como os clusters particulares funcionam, consulte Clusters particulares.

Antes de começar

Familiarize-se com os requisitos, restrições e limitações antes de passar para a próxima etapa.

Antes de começar, verifique se você realizou as tarefas a seguir:

  • Ativar a API Google Kubernetes Engine.
  • Ativar a API Google Kubernetes Engine
  • Se você quiser usar a Google Cloud CLI para essa tarefa, instale e, em seguida, inicialize a CLI gcloud. Se você instalou a CLI gcloud anteriormente, instale a versão mais recente executando gcloud components update.

Como criar um cluster privado sem acesso de cliente ao endpoint público

Nesta seção, você criará os recursos a seguir:

  • Um cluster particular chamado private-cluster-0 que tem nós particulares e que não tem acesso de cliente ao endpoint público.
  • Uma rede chamada my-net-0.
  • Uma sub-rede chamada my-subnet-0.

Console

Criar uma rede e uma sub-rede

  1. Acesse a página Redes VPC no console do Google Cloud.

    Acessar redes VPC

  2. Clique em Criar rede VPC.

  3. Em Nome, insira my-net-0.

  4. Em Modo de criação da sub-rede, selecione Personalizado.

  5. Na caixa Nova sub-rede, para Nome, digite my-subnet-0.

  6. Na lista Região, selecione a região desejada.

  7. Em Intervalo de endereços IP, insira 10.2.204.0/22.

  8. Defina o Acesso privado do Google como Ativado.

  9. Clique em Concluído.

  10. Clique em Criar.

crie um cluster particular

  1. Acesse a página Google Kubernetes Engine no Console do Google Cloud.

    Acessar o Google Kubernetes Engine

  2. Clique em Criar e, na seção Standard ou Autopilot, clique em Configurar.

  3. Em Nome, especifique private-cluster-0.

  4. No painel de navegação, clique em Rede.

  5. Na lista Rede, selecione my-net-0.

  6. Na lista Sub-rede de nós, selecione my-subnet-0.

  7. Selecione o botão de opção Cluster particular.

  8. Desmarque a caixa de seleção Acesso ao plano de controle usando o endereço IP externo.

  9. Opcional para o Autopilot: defina o Intervalo de IP do plano de controle para 172.16.0.32/28.

  10. Clique em Criar.

gcloud

  • Para clusters do Autopilot, execute o seguinte comando:

    gcloud container clusters create-auto private-cluster-0 \
        --create-subnetwork name=my-subnet-0 \
        --enable-master-authorized-networks \
        --enable-private-nodes \
        --enable-private-endpoint
    
  • Para clusters padrão, execute o seguinte comando:

    gcloud container clusters create private-cluster-0 \
        --create-subnetwork name=my-subnet-0 \
        --enable-master-authorized-networks \
        --enable-ip-alias \
        --enable-private-nodes \
        --enable-private-endpoint \
        --master-ipv4-cidr 172.16.0.32/28
    

onde:

  • --create-subnetwork name=my-subnet-0 faz com que o GKE crie automaticamente uma sub-rede denominada my-subnet-0;
  • --enable-master-authorized-networks especifica que o acesso ao endpoint público é restrito aos intervalos de endereços IP que você autorizar;
  • --enable-ip-alias torna o cluster nativo da VPC (não necessário para o Autopilot).
  • --enable-private-nodes indica que os nós do cluster não têm endereços IP externos.
  • --enable-private-endpoint indica que o cluster é gerenciado usando o endereço IP interno do endpoint da API do plano de controle.
  • --master-ipv4-cidr 172.16.0.32/28 especifica um intervalo de endereços IP internos para o plano de controle (opcional para o Autopilot). Essa configuração é permanente para esse cluster e precisa ser exclusiva na VPC. O uso de endereços IP internos não RFC 1918 é compatível.

API

Para criar um cluster sem um plano de controle acessível publicamente, especifique o campo enablePrivateEndpoint: true no recurso privateClusterConfig.

Nesse momento, os únicos endereços IP que têm acesso ao plano de controle são estes:

  • O intervalo principal de my-subnet-0
  • O intervalo secundário usado para os pods.

Por exemplo, suponha que você tenha criado uma VM no intervalo principal de my-subnet-0. Então, nessa VM, seria possível configurar kubectl para usar o endereço IP interno do plano de controle.

Se você quiser acessar o plano de controle de fora do my-subnet-0, precisará autorizar pelo menos um intervalo de endereços a ter acesso ao endpoint particular.

Suponha que você tenha uma VM na rede padrão, na mesma região que seu cluster, mas não em my-subnet-0.

Exemplo:

  • my-subnet-0: 10.0.0.0/22
  • intervalo secundário de pods: 10.52.0.0/14
  • endereço da VM: 10.128.0.3

Use o comando a seguir para autorizar a VM a acessar o plano de controle:

gcloud container clusters update private-cluster-0 \
    --enable-master-authorized-networks \
    --master-authorized-networks 10.128.0.3/32

Como criar um cluster privado com acesso limitado ao endpoint público

Ao criar um cluster privado usando essa configuração, é possível optar por usar uma sub-rede gerada automaticamente ou uma sub-rede personalizada.

Como usar uma sub-rede gerada automaticamente

Nesta seção, você cria um cluster particular chamado private-cluster-1 em que o GKE gerar automaticamente uma sub-rede para os nós do cluster. Ela já tem o recurso “Acesso privado do Google” ativado. Na sub-rede, o GKE cria automaticamente dois intervalos secundários: um para os pods e outro para os serviços.

É possível usar a Google Cloud CLI ou a API GKE.

gcloud

  • Para clusters do Autopilot, execute o seguinte comando:

    gcloud container clusters create-auto private-cluster-1 \
        --create-subnetwork name=my-subnet-1 \
        --enable-master-authorized-networks \
        --enable-private-nodes
    
  • Para clusters padrão, execute o seguinte comando:

    gcloud container clusters create private-cluster-1 \
        --create-subnetwork name=my-subnet-1 \
        --enable-master-authorized-networks \
        --enable-ip-alias \
        --enable-private-nodes \
        --master-ipv4-cidr 172.16.0.0/28
    

onde:

  • --create-subnetwork name=my-subnet-1 faz com que o GKE crie automaticamente uma sub-rede denominada my-subnet-1;
  • --enable-master-authorized-networks especifica que o acesso ao endpoint público é restrito aos intervalos de endereços IP que você autorizar;
  • --enable-ip-alias torna o cluster nativo da VPC (não necessário para o Autopilot).
  • --enable-private-nodes indica que os nós do cluster não têm endereços IP externos.
  • --master-ipv4-cidr 172.16.0.0/28 especifica um intervalo de endereços IP internos para o plano de controle (opcional para o Autopilot). Essa configuração é permanente para esse cluster e precisa ser exclusiva na VPC. O uso de endereços IP internos não RFC 1918 é compatível.

API

Especifique o campo privateClusterConfig no recurso da API Cluster:

{
  "name": "private-cluster-1",
  ...
  "ipAllocationPolicy": {
    "createSubnetwork": true,
  },
  ...
    "privateClusterConfig" {
      "enablePrivateNodes": boolean # Creates nodes with internal IP addresses only
      "enablePrivateEndpoint": boolean # false creates a cluster control plane with a publicly-reachable endpoint
      "masterIpv4CidrBlock": string # CIDR block for the cluster control plane
      "privateEndpoint": string # Output only
      "publicEndpoint": string # Output only
  }
}

Nesse momento, os únicos endereços IP que têm acesso ao plano de controle do cluster são estes:

  • O intervalo principal de my-subnet-1
  • O intervalo secundário usado para os pods

Imagine que você tem um grupo de máquinas fora da sua rede VPC, com endereços no intervalo 203.0.113.0/29. Digite o comando abaixo para autorizar que essas máquinas acessem o endpoint público:

gcloud container clusters update private-cluster-1 \
    --enable-master-authorized-networks \
    --master-authorized-networks 203.0.113.0/29

Agora, estes são os únicos endereços IP que têm acesso ao plano de controle:

  • O intervalo principal de my-subnet-1
  • O intervalo secundário usado para os pods.
  • Os intervalos autorizados, como 203.0.113.0/29

Como usar uma sub-rede personalizada

Nesta seção, você criará os recursos a seguir:

  • Um cluster particular chamado private-cluster-2.
  • Uma rede chamada my-net-2.
  • Uma sub-rede chamada my-subnet-2, com intervalo principal 192.168.0.0/20, para seus nós de cluster. Sua sub-rede tem os seguintes intervalos de endereços secundários:
    • my-pods para os endereços IP de pods.
    • my-services para os endereços IP do Serviço.

Console

Criar uma rede, sub-rede e intervalos secundários

  1. Acesse a página Redes VPC no console do Google Cloud.

    Acessar redes VPC

  2. Clique em Criar rede VPC.

  3. Em Nome, insira my-net-2.

  4. Em Modo de criação da sub-rede, selecione Personalizado.

  5. Na caixa Nova sub-rede, para Nome, digite my-subnet-2.

  6. Na lista Região, selecione a região desejada.

  7. Em Intervalo de endereços IP, insira 192.168.0.0/20.

  8. Clique em Criar um intervalo de IP secundário. Digite my-services em Nome do intervalo da sub-rede e 10.0.32.0/20 em Intervalo de IP secundário.

  9. Clique em Adicionar intervalo de IP. Digite my-pods em Nome do intervalo da sub-rede e 10.4.0.0/14 em Intervalo de IP secundário.

  10. Defina o Acesso privado do Google como Ativado.

  11. Clique em Concluído.

  12. Clique em Criar.

crie um cluster particular

Crie um cluster particular que usa a sub-rede:

  1. Acesse a página Google Kubernetes Engine no console do Google Cloud.

    Acessar o Google Kubernetes Engine

  2. Clique em Criar e, na seção Standard ou Autopilot, clique em Configurar.

  3. Em Nome, insira private-cluster-2.

  4. No painel de navegação, clique em Rede.

  5. Selecione o botão de opção Cluster particular.

  6. Para criar um plano de controle que possa ser acessado por intervalos de IP externos autorizados, mantenha marcada a caixa de seleção Acessar ao plano de controle usando o endereço IP externo.

  7. Opcional para o Autopilot: defina o Intervalo de IP do plano de controle para 172.16.0.16/28.

  8. Na lista Rede, selecione my-net-2.

  9. Na lista Sub-rede de nós, selecione my-subnet-2.

  10. Desmarque a caixa de seleção Criar intervalos secundários automaticamente.

  11. Na lista Intervalo CIDR secundário do pod, selecione my-pods.

  12. Na lista Serviços do intervalo CIDR secundário, selecione my-services.

  13. Marque a caixa de seleção Ativar redes autorizadas do plano de controle.

  14. Clique em Criar.

gcloud

Criar uma rede

Primeiro, crie uma rede para o cluster. O comando a seguir cria uma rede, my-net-2:

gcloud compute networks create my-net-2 \
    --subnet-mode custom

Criar uma sub-rede e intervalos secundários

Em seguida, crie uma sub-rede, my-subnet-2, na rede my-net-2, com intervalos secundários my-pods para pods e my-services para Services:

gcloud compute networks subnets create my-subnet-2 \
    --network my-net-2 \
    --range 192.168.0.0/20 \
    --secondary-range my-pods=10.4.0.0/14,my-services=10.0.32.0/20 \
    --enable-private-ip-google-access

crie um cluster particular

Agora, crie um cluster particular, private-cluster-2, usando a rede, a sub-rede e os intervalos secundários criados.

  • Para clusters do Autopilot, execute o seguinte comando:

    gcloud container clusters create-auto private-cluster-2 \
        --enable-master-authorized-networks \
        --network my-net-2 \
        --subnetwork my-subnet-2 \
        --cluster-secondary-range-name my-pods \
        --services-secondary-range-name my-services \
        --enable-private-nodes
    
  • Para clusters padrão, execute o seguinte comando:

    gcloud container clusters create private-cluster-2 \
        --enable-master-authorized-networks \
        --network my-net-2 \
        --subnetwork my-subnet-2 \
        --cluster-secondary-range-name my-pods \
        --services-secondary-range-name my-services \
        --enable-private-nodes \
        --enable-ip-alias \
        --master-ipv4-cidr 172.16.0.16/28 \
        --no-enable-basic-auth \
        --no-issue-client-certificate
    

Nesse momento, os únicos endereços IP que têm acesso ao plano de controle são estes:

  • O intervalo principal de my-subnet-2
  • O intervalo secundário my-pods

Suponha que você tenha um grupo de máquinas fora de my-net-2 que tenham endereços no intervalo 203.0.113.0/29. Digite o comando abaixo para autorizar que essas máquinas acessem o endpoint público:

gcloud container clusters update private-cluster-2 \
    --enable-master-authorized-networks \
    --master-authorized-networks 203.0.113.0/29

Nesse momento, os únicos endereços IP que têm acesso ao plano de controle são estes:

  • O intervalo principal de my-subnet-2
  • O intervalo secundário my-pods
  • Os intervalos autorizados, como 203.0.113.0/29

Como usar o Cloud Shell para acessar um cluster particular

O cluster particular que você criou na seção Como usar uma sub-rede gerada automaticamente, private-cluster-1, tem um endpoint público e tem redes autorizadas ativadas. Se você quiser usar o Cloud Shell para acessar o cluster, adicione o endereço IP externo do Cloud Shell à lista de redes autorizadas do cluster.

Para isso, siga estas etapas:

  1. Na janela da linha de comando do Cloud Shell, use dig para encontrar o endereço IP externo do seu Cloud Shell:

    dig +short myip.opendns.com @resolver1.opendns.com
    
  2. Adicione o endereço externo do seu Cloud Shell à lista de redes autorizadas do cluster:

    gcloud container clusters update private-cluster-1 \
        --enable-master-authorized-networks \
        --master-authorized-networks EXISTING_AUTH_NETS,SHELL_IP/32
    

    Substitua:

    • EXISTING_AUTH_NETS: os endereços IP da sua lista atual de redes autorizadas. É possível encontrar suas redes autorizadas no console ou executando o seguinte comando:

      gcloud container clusters describe private-cluster-1 --format "flattened(masterAuthorizedNetworksConfig.cidrBlocks[])"
      
    • SHELL_IP: é o endereço IP externo do seu Cloud Shell.

  3. Receba as credenciais para poder usar a kubectl para acessar o cluster:

    gcloud container clusters get-credentials private-cluster-1 \
        --project=PROJECT_ID \
        --internal-ip
    

    Substitua PROJECT_ID pela ID do seu projeto.

  4. Use kubectl, no Cloud Shell, para acessar seu cluster particular:

    kubectl get nodes
    

    A saída será assim:

    NAME                                               STATUS   ROLES    AGE    VERSION
    gke-private-cluster-1-default-pool-7d914212-18jv   Ready    <none>   104m   v1.21.5-gke.1302
    gke-private-cluster-1-default-pool-7d914212-3d9p   Ready    <none>   104m   v1.21.5-gke.1302
    gke-private-cluster-1-default-pool-7d914212-wgqf   Ready    <none>   104m   v1.21.5-gke.1302
    

Como criar um cluster privado com acesso irrestrito ao endpoint público

Nesta seção, você cria um cluster privado em que qualquer endereço IP pode acessar o plano de controle.

Console

  1. Acesse a página Google Kubernetes Engine no console do Google Cloud.

    Acessar o Google Kubernetes Engine

  2. Clique em Criar e, na seção Standard ou Autopilot, clique em Configurar.

  3. Em Nome, insira private-cluster-3.

  4. No painel de navegação, clique em Rede.

  5. Selecione a opção Cluster privado.

  6. Mantenha a caixa de seleção Acessar plano de controle usando o endereço IP externo marcada.

  7. Opcional para o Autopilot: defina o Intervalo de IP do plano de controle para 172.16.0.32/28.

  8. Deixe Rede e sub-rede do nó definidas como default. Dessa forma, o GKE gera uma sub-rede para o cluster.

  9. Desmarque a caixa de seleção Ativar redes autorizadas do plano de controle.

  10. Clique em Criar.

gcloud

  • Para clusters do Autopilot, execute o seguinte comando:

    gcloud container clusters create-auto private-cluster-3 \
        --create-subnetwork name=my-subnet-3 \
        --no-enable-master-authorized-networks \
        --enable-private-nodes
    
  • Para clusters padrão, execute o seguinte comando:

    gcloud container clusters create private-cluster-3 \
        --create-subnetwork name=my-subnet-3 \
        --no-enable-master-authorized-networks \
        --enable-ip-alias \
        --enable-private-nodes \
        --master-ipv4-cidr 172.16.0.32/28
    

onde:

  • --create-subnetwork name=my-subnet-3 faz com que o GKE crie automaticamente uma sub-rede denominada my-subnet-3;
  • --no-enable-master-authorized-networks desativa redes autorizadas para o cluster;
  • --enable-ip-alias torna o cluster nativo da VPC (não necessário para o Autopilot).
  • --enable-private-nodes indica que os nós do cluster não têm endereços IP externos.
  • --master-ipv4-cidr 172.16.0.32/28 especifica um intervalo de endereços IP internos para o plano de controle (opcional para o Autopilot). Essa configuração é permanente para esse cluster e precisa ser exclusiva na VPC. O uso de endereços IP internos não RFC 1918 é compatível.

Outras configurações de cluster particular

Além das configurações anteriores, é possível executar clusters privados com as seguintes configurações.

Como conceder aos nós privados acesso à Internet de saída

Para fornecer acesso de Internet de saída aos seus nós particulares, como para extrair imagens de um registro externo, use o Cloud NAT para criar e configurar um Cloud Router. O Cloud NAT permite que clusters particulares estabeleçam conexões de saída pela Internet para enviar e receber pacotes.

O Cloud Router permite que todos os nós da região usem o Cloud NAT para todos os intervalos de IP de alias e principais. Ele também aloca automaticamente os endereços IP externos para o gateway NAT.

Para instruções sobre como criar e configurar um Cloud Router, consulte Criar uma configuração do Cloud NAT usando o Cloud Router na documentação do Cloud NAT.

Como criar um cluster privado em uma rede VPC compartilhada

Para saber como criar um cluster particular em uma rede VPC compartilhada, consulte Como criar um cluster particular em uma VPC compartilhada.

Como implantar um aplicativo de contêiner do Windows Server em um cluster privado

Para saber como implantar um aplicativo de contêiner do Windows Server em um cluster particular, consulte a documentação do pool de nós do Windows.

Como acessar o endpoint privado do plano de controle globalmente

O endpoint particular do plano de controle é implementado por um balanceador de carga de rede interno na rede VPC do plano de controle. Clientes internos ou conectados por meio de túneis do Cloud VPN e anexos da VLAN do Cloud Interconnect podem acessar balanceadores de carga de rede internos.

Por padrão, esses clientes precisam estar localizados na mesma região do balanceador de carga.

Quando você ativa o acesso global do plano de controle, o balanceador de carga de rede interno é acessível globalmente: as VMs cliente e sistemas locais podem se conectar ao endpoint particular do plano de controle, sujeito à configuração de redes autorizadas, em qualquer região.

Para mais informações sobre os balanceadores de carga de rede internos e o acesso global, consulte Balanceadores de carga internos e redes conectadas.

Como ativar o acesso global do endpoint particular do plano de controle

Por padrão, o acesso global não é ativado para o endpoint privado do plano de controle quando você cria um cluster privado. Para ativar o acesso global ao plano de controle, use as seguintes ferramentas com base no modo de cluster:

  • Para clusters padrão, use Google Cloud CLI ou o Console do Google Cloud.
  • Para clusters do Autopilot, use o recurso Terraform google_container_cluster.

Console

Para criar um novo cluster privado com acesso global do plano de controle ativado, execute as etapas a seguir:

  1. Acesse a página Google Kubernetes Engine no console do Google Cloud.

    Acessar o Google Kubernetes Engine

  2. Clique em Criar e, na seção Standard ou Autopilot, clique em Configurar.

  3. Digite um Nome.

  4. No painel de navegação, clique em Rede.

  5. Selecione Cluster particular.

  6. Marque a caixa de seleção Ativar acesso global do plano de controle.

  7. Configure outros campos como quiser.

  8. Clique em Criar.

Para ativar o acesso global do plano de controle a um cluster particular atual, execute as seguintes etapas:

  1. Acesse a página Google Kubernetes Engine no console do Google Cloud.

    Acessar o Google Kubernetes Engine

  2. Ao lado do cluster que você quer editar, clique em Ações e, depois, em Editar.

  3. Na seção Rede, ao lado de Acesso global ao plano de controle, clique em Editar.

  4. Na caixa de diálogo Editar o acesso global ao plano de controle, marque a caixa de seleção Ativar o acesso global ao plano de controle.

  5. Clique em Salvar alterações.

gcloud

Adicione a sinalização --enable-master-global-access para criar um cluster particular com acesso global ao endpoint particular do plano de controle ativado:

gcloud container clusters create CLUSTER_NAME \
    --enable-private-nodes \
    --enable-master-global-access

Também é possível ativar o acesso global ao endpoint particular do plano de controle para um cluster particular atual:

gcloud container clusters update CLUSTER_NAME \
    --enable-master-global-access

Como verificar o acesso global do endpoint particular do plano de controle

Verifique se o acesso global ao endpoint privado do plano de controle está ativado executando o comando a seguir e observando a saída.

gcloud container clusters describe CLUSTER_NAME

A saída inclui uma seção privateClusterConfig em que vê o status de masterGlobalAccessConfig.

privateClusterConfig:
  enablePrivateNodes: true
  masterIpv4CidrBlock: 172.16.1.0/28
  peeringName: gke-1921aee31283146cdde5-9bae-9cf1-peer
  privateEndpoint: 172.16.1.2
  publicEndpoint: 34.68.128.12
  masterGlobalAccessConfig:
    enabled: true

Como acessar o endpoint particular do plano de controle em outras redes

Quando você cria um cluster particular do GKE e desativa o endpoint público do plano de controle, é necessário administrá-lo com ferramentas como kubectl usando o endpoint particular do plano de controle. É possível acessar o endpoint particular do plano de controle do cluster de outra rede, incluindo o seguinte:

  • uma rede local conectada à rede VPC do cluster usando túneis do Cloud VPN ou anexos da VLAN do Cloud Interconnect;
  • Outra rede VPC conectada à rede VPC do cluster usando túneis do Cloud VPN

O diagrama a seguir mostra um caminho de roteamento entre uma rede no local e os nós do plano de controle do GKE:

Diagrama mostrando o roteamento entre a VPC local e o plano de controle do cluster

Para permitir que sistemas em outra rede se conectem ao endpoint particular do plano de controle de um cluster, atenda aos seguintes requisitos:

  1. Identifique e registre informações de rede relevantes para o cluster e o endpoint particular do plano de controle.

    gcloud container clusters describe CLUSTER_NAME \
       --location=COMPUTE_LOCATION \
       --format="yaml(network, privateClusterConfig)"
    

    Substitua:

    Na saída do comando, identifique e registre as seguintes informações para usar nas próximas etapas:

    • network: o nome ou URI da rede VPC do cluster.
    • privateEndpoint: o endereço IPv4 do endpoint particular do plano de controle ou o intervalo CIDR IPv4 delimitado (masterIpv4CidrBlock).
    • peeringName: o nome da conexão de peering de rede VPC usada para conectar a rede VPC do cluster à rede VPC do plano de controle.

    A saída será assim:

    network: cluster-network
    privateClusterConfig:
      enablePrivateNodes: true
      masterGlobalAccessConfig:
        enabled: true
      masterIpv4CidrBlock: 172.16.1.0/28
      peeringName: gke-1921aee31283146cdde5-9bae-9cf1-peer
      privateEndpoint: 172.16.1.2
      publicEndpoint: 34.68.128.12
    
  2. Considere ativar o acesso global do endpoint particular do plano de controle para permitir que os pacotes entrem em qualquer região na rede VPC do cluster. Ativar o acesso global do endpoint particular do plano de controle permite que você se conecte ao endpoint particular usando túneis do Cloud VPN ou anexos da VLAN do Cloud Interconnect localizados em qualquer região, não apenas na região do cluster.

  3. Crie uma rota para o endereço IP privateEndpoint ou o intervalo de endereços IP masterIpv4CidrBlock da outra rede. Como o endereço IP particular do plano de controle sempre se encaixa no masterIpv4CidrBlock intervalo de endereços IPv4, criando uma rota para o privateEndpoint o endereço IP ou o intervalo incluído fornece um caminho para pacotes da outra rede para o endpoint particular do plano de controle se:

    • A outra rede se conecta à rede VPC do cluster usando anexos da VLAN do Cloud Interconnect ou túneis do Cloud VPN que usam rotas dinâmicas (BGP): use uma divulgação de rota personalizada do Cloud Router. Para mais informações, consulte Como divulgar intervalos de IP personalizados na documentação do Cloud Router.

    • A outra rede se conecta à rede VPC do cluster usando túneis da VPN clássica que não usam rotas dinâmicas: é preciso configurar uma rota estática na outra rede do Google Analytics.

  4. Configure a rede VPC do cluster para exportar as rotas personalizadas na relação de peering com a rede VPC do plano de controle. O Google Cloud sempre configura a rede VPC do plano de controle para importar rotas personalizadas da rede VPC do cluster. Essa etapa fornece um caminho para os pacotes do endpoint particular do plano de controle de volta para a outra rede.

    Para ativar a exportação de rota personalizada a partir da rede VPC do cluster, use o seguinte comando:

    gcloud compute networks peerings update PEERING_NAME \
        --network=CLUSTER_VPC_NETWORK \
        --export-custom-routes
    

    Substitua:

    • PEERING_NAME: o nome do peering que conecta a rede VPC do cluster à rede VPC do plano de controle.
    • CLUSTER_VPC_NETWORK: o nome ou URI da rede VPC do cluster;

    Para mais detalhes sobre como atualizar a troca de rotas para conexões de peering de rede VPC existentes, consulte Atualizar a conexão de peering.

    As rotas personalizadas na rede VPC do cluster incluem rotas com destinos que são intervalos de endereços IP em outras redes, por exemplo, uma rede local. Para garantir que essas rotas se tornem efetivas como peering de rotas na rede VPC do plano de controle, consulte Destinos compatíveis com a outra rede.

Destinos compatíveis da outra rede

Os intervalos de endereços que a outra rede envia para os Cloud Routers na rede VPC do cluster precisam aderir às seguintes condições:

  • Embora a VPC do cluster possa aceitar uma rota padrão (0.0.0.0/0), a rede VPC do plano de controle sempre rejeita rotas padrão porque já tem uma rota padrão local. Se a outra rede enviar uma rota padrão para sua rede VPC, a outra rede também precisará enviar os destinos específicos dos sistemas que precisam se conectar ao endpoint particular do plano de controle. Para mais detalhes, consulte Ordem de roteamento.

  • Se a rede VPC do plano de controle aceitar rotas que substituem efetivamente uma rota padrão, essas rotas quebrarão a conectividade com as APIs e os serviços do Google Cloud, interrompendo o plano de controle do cluster. Como exemplo representativo, a outra rede não pode divulgar rotas com destinos 0.0.0.0/1 e 128.0.0.0/1. Consulte o ponto anterior para obter uma alternativa.

Monitore os limites do Cloud Router, especialmente o número máximo de destinos exclusivos para rotas aprendidas.

Verificar se os nós não têm endereços IP externos

Depois de criar um cluster particular, verifique se os nós dele não têm endereços IP externos.

Console

  1. Acesse a página Google Kubernetes Engine no console do Google Cloud.

    Acessar o Google Kubernetes Engine

  2. Na lista de clusters, clique no nome do cluster.

  3. Para clusters do Autopilot, na seção Noções básicas sobre clusters, verifique o campo Endpoint externo. O valor é Desativado.

Para clusters padrão, faça o seguinte:

  1. Na página Clusters, clique na guia Nós.
  2. Em Pools de nós, clique no nome do pool.
  3. Na página Detalhes do pool de nós, em Grupos de instâncias, clique no nome do grupo. Por exemplo, gke-private-cluster-0-default-pool-5c5add1f-grp`.
  4. Na lista de instâncias, confirme se elas não têm endereços IP externos.

gcloud

Execute este comando:

kubectl get nodes --output wide

A coluna EXTERNAL-IP da resposta está vazia:

STATUS ... VERSION        EXTERNAL-IP  OS-IMAGE ...
Ready      v.8.7-gke.1                 Container-Optimized OS
Ready      v1.8.7-gke.1                Container-Optimized OS
Ready      v1.8.7-gke.1                Container-Optimized OS

Como visualizar a sub-rede do cluster e os intervalos de endereços secundários

Depois de criar um cluster particular, você pode exibir os intervalos de endereços de sub-rede e secundários que você ou o GKE provisionaram para o cluster.

Console

  1. Acesse a página Redes VPC no Console do Google Cloud.

    Acessar redes VPC

  2. Clique no nome da sub-rede. Por exemplo, gke-private-cluster-0-subnet-163e3c97.

  3. Em Intervalo de endereços IP, veja o intervalo de endereços principal da sub-rede. É o intervalo usado para nós.

  4. Em Intervalos de IP secundários, veja o intervalo de endereços IP para pods e o intervalo para serviços.

gcloud

Listar todas as sub-redes

Para listar as sub-redes na rede do cluster, execute o seguinte comando:

gcloud compute networks subnets list \
    --network NETWORK_NAME

Substitua NETWORK_NAME pela rede do cluster particular. Se você criou o cluster com uma sub-rede criada automaticamente, use default.

Na saída do comando, localize o nome da sub-rede do cluster.

Visualizar sub-rede do cluster

Receba informações sobre a sub-rede criada automaticamente:

gcloud compute networks subnets describe SUBNET_NAME

Substitua SUBNET_NAME pelo nome da subnet.

A resposta mostra o intervalo de endereços principal para nós (o primeiro campo ipCidrRange) e os intervalos secundários para pods e Serviços (em secondaryIpRanges):

...
ipCidrRange: 10.0.0.0/22
kind: compute#subnetwork
name: gke-private-cluster-1-subnet-163e3c97
...
privateIpGoogleAccess: true
...
secondaryIpRanges:
- ipCidrRange: 10.40.0.0/14
  rangeName: gke-private-cluster-1-pods-163e3c97
- ipCidrRange: 10.0.16.0/20
  rangeName: gke-private-cluster-1-services-163e3c97
...

Como ver os endpoints de um cluster particular

Para visualizar os endpoints de clusters privados, use a CLI gcloud ou o Console do Google Cloud.

Console

  1. Acesse a página Google Kubernetes Engine no console do Google Cloud.

    Acessar o Google Kubernetes Engine

  2. Na lista de clusters, clique no nome do cluster.

  3. Na guia Detalhes, em Princípios básicos do cluster, procure o campo Endpoint.

gcloud

Execute este comando:

gcloud container clusters describe CLUSTER_NAME

A saída mostra tanto o endpoint particular quanto o público:

...
privateClusterConfig:
enablePrivateEndpoint: true
enablePrivateNodes: true
masterIpv4CidrBlock: 172.16.0.32/28
privateEndpoint: 172.16.0.34
publicEndpoint: 35.239.154.67

Como extrair imagens de contêiner de um registro de imagem

Em um cluster particular, o ambiente de execução de contêiner pode extrair imagens do Artifact Registry; no entanto, não é possível extrair imagens de qualquer outro registro de imagem de contêiner na Internet. Isso ocorre porque os nós em um cluster particular não têm endereços IP externos. Portanto, por padrão, eles não podem se comunicar com serviços fora da rede do Google Cloud.

Os nós de um cluster particular poderão se comunicar com os serviços do Google Cloud, como o Artifact Registry, se estiverem em uma sub-rede com o Acesso privado do Google ativado.

Os comandos a seguir criam uma implantação que extrai uma imagem de amostra de um repositório do Artifact Registry:

kubectl run hello-deployment --image=us-docker.pkg.dev/google-samples/containers/gke/hello-app:1.0

Como adicionar regras de firewall para casos de uso específicos

Esta seção explica como adicionar uma regra de firewall a um cluster privado. Por padrão, as regras de firewall restringem o plano de controle do cluster a apenas iniciar conexões TCP com os nós 443 (HTTPS) e 10250 (kubelet). Para alguns recursos do Kubernetes, talvez seja necessário adicionar regras de firewall para permitir o acesso em outras portas.

Os recursos do Kubernetes que exigem regras de firewall adicionais incluem:

Adicionar uma regra de firewall permite o tráfego do plano de controle do cluster para todos os itens a seguir:

  • A porta especificada de cada nó (hostPort).
  • a porta especificada de cada pod em execução nesses nós
  • A porta especificada de cada Service em execução nesses nós

Para saber mais sobre as regras de firewall, consulte Regras de firewall na documentação do Cloud Load Balancing

Para adicionar uma regra de firewall a um cluster privado, você precisa registrar o bloco CIDR do plano de controle do cluster e o destino usado. Depois de registrá-la, é possível criar a regra.

Etapa 1: Ver o bloco CIDR do plano de controle

Você precisa do bloco CIDR do plano de controle do cluster para adicionar uma regra de firewall.

Console

  1. Acesse a página Google Kubernetes Engine no console do Google Cloud.

    Acessar o Google Kubernetes Engine

  2. Na lista de clusters, clique no nome do cluster.

Na guia Detalhes, em Rede, anote o valor do campo Intervalo de endereços do plano de controle.

gcloud

Execute este comando:

gcloud container clusters describe CLUSTER_NAME

Substitua CLUSTER_NAME pelo nome do cluster privado.

Na saída do comando, anote o valor no campo masterIpv4CidrBlock.

Etapa 2. Ver as regras de firewall atuais

É necessário especificar o destino (neste caso, os nós de destino) que as regras de firewall do cluster usam.

Console

  1. Acesse a página de políticas de firewall no console do Google Cloud.

    Acessar as políticas de firewall

  2. Em Filtrar tabela para regras de firewall da VPC, insira gke-CLUSTER_NAME.

Nos resultados, anote o valor no campo Destinos.

gcloud

Execute este comando:

gcloud compute firewall-rules list \
    --filter 'name~^gke-CLUSTER_NAME' \
    --format 'table(
        name,
        network,
        direction,
        sourceRanges.list():label=SRC_RANGES,
        allowed[].map().firewall_rule().list():label=ALLOW,
        targetTags.list():label=TARGET_TAGS
    )'

Na saída do comando, anote o valor no campo Destinos.

Etapa 3. Adicionar uma regra de firewall

Console

  1. Acesse a página de políticas de firewall no console do Google Cloud.

    Acessar as políticas de firewall

  2. Clique em Criar regra de firewall.

  3. Em Nome, insira o nome desejado para a regra de firewall.

  4. Na lista Rede, selecione a rede relevante.

  5. Em Direção de tráfego, clique em Entrada.

  6. Em Ação se houver correspondência, clique em Permitir.

  7. Na lista Destinos, selecione Tags de destino especificadas.

  8. Em Tags de destino, insira o valor de destino que você anotou anteriormente.

  9. Na lista Filtro de origem, selecione Intervalos IPv4.

  10. Em Intervalos de IPv4 de origem, insira o bloco CIDR do plano de controle do cluster.

  11. Em Protocolos e portas, clique em Protocolos e portas especificados e marque a caixa de seleção do protocolo relevante (tcp ou udp) e insira o número da porta no campo do protocolo.

  12. Clique em Criar.

gcloud

Execute este comando:

gcloud compute firewall-rules create FIREWALL_RULE_NAME \
    --action ALLOW \
    --direction INGRESS \
    --source-ranges CONTROL_PLANE_RANGE \
    --rules PROTOCOL:PORT \
    --target-tags TARGET

Substitua:

  • FIREWALL_RULE_NAME: o nome escolhido para a regra de firewall.
  • CONTROL_PLANE_RANGE: o intervalo de endereços IP do plano de controle de cluster (masterIpv4CidrBlock) coletado anteriormente.
  • PROTOCOL:PORT: é a porta desejada e o protocolo dela, tcp ou udp.
  • TARGET: é o valor de destino (Targets) coletado anteriormente.

Como proteger um cluster particular com o VPC Service Controls

Para proteger ainda mais os clusters privados do GKE, use o VPC Service Controls.

O VPC Service Controls protege ainda mais os clusters privados do GKE para reduzir o risco de exportação de dados. Ao usá-lo, é possível adicionar projetos a perímetros de serviço. Isso protege recursos e serviços contra solicitações que vêm de fora desses perímetros.

Para saber mais sobre perímetros de serviço, consulte Detalhes e configuração do perímetro de serviço.

Se você usar o Artifact Registry com seu cluster particular do GKE em um perímetro de serviço do VPC Service Controls, precisará configurar o roteamento para o IP virtual restrito para evitar a exfiltração de dados.

Reutilização de peering de VPC

Todos os clusters particulares criados após 15 de janeiro de 2020 reutilizam as conexões do peering da rede VPC.

Todos os clusters particulares criados antes de 15 de janeiro de 2020 usam uma conexão exclusiva de peering da rede VPC. Cada rede VPC faz peering com até 25 outras redes VPC, o que significa que para esses clusters há um limite de no máximo 25 clusters particulares por rede, supondo que os peerings não estejam sendo usados para outros fins.

Este recurso não é compatível com versões anteriores. Para ativar a reutilização do peering da rede VPC em clusters particulares mais antigos, é possível excluir um cluster e recriá-lo. O upgrade de um cluster não faz com que ele reutilize uma conexão de peering de rede VPC atual.

Cada local será compatível com até 75 clusters particulares se eles tiverem a reutilização de peering de rede VPC ativada. Zonas e regiões são tratadas como locais separados.

Por exemplo, é possível criar até 75 clusters particulares zonais em us-east1-a e outros 75 clusters particulares regionais em us-east1. Isso também se aplica se você estiver usando clusters particulares em uma rede VPC compartilhada. O número máximo de conexões com uma rede VPC é 25, o que significa que só é possível criar clusters particulares usando 25 locais únicos.

A reutilização do peering de rede VPC se aplica somente a clusters no mesmo local. Por exemplo, clusters regionais na mesma região ou clusters zonais na mesma zona. No máximo, é possível ter quatro peerings de rede VPC por região se criar clusters regionais e clusters por zona em todas as zonas dessa região.

Para verificar se o cluster particular reutiliza as conexões de peering de rede VPC, use a gcloud CLI ou o console do Google Cloud.

Console

Verifique a linha de Peering de VPC na página de detalhes do cluster. Se o cluster estiver usando novamente as conexões de peering de VPC, a resposta começará com gke-n. Por exemplo, gke-n34a117b968dee3b2221-93c6-40af-peer.

gcloud

gcloud container clusters describe CLUSTER_NAME \
    --format="value(privateClusterConfig.peeringName)"

Se o cluster estiver usando novamente as conexões de peering de VPC, a resposta começará com gke-n. Por exemplo, gke-n34a117b968dee3b2221-93c6-40af-peer.

Limpar

Depois de concluir as tarefas nesta página, siga estas etapas para remover os recursos e evitar cobranças indesejadas na conta:

Excluir os clusters

Console

  1. Acesse a página Google Kubernetes Engine no console do Google Cloud.

    Acessar o Google Kubernetes Engine

  2. Selecione cada cluster.

  3. Clique em Excluir.

gcloud

gcloud container clusters delete -q private-cluster-0 private-cluster-1 private-cluster-2 private-cluster-3

Excluir a rede

Console

  1. Acesse a página Redes VPC no Console do Google Cloud.

    Acessar redes VPC

  2. Na lista de redes, clique em my-net-0.

  3. Na página Detalhes da rede, clique em Excluir rede VPC.

  4. Na caixa de diálogo Excluir uma rede, clique em Excluir.

gcloud

gcloud compute networks delete my-net-0

Requisitos, restrições e limitações

Os clusters particulares têm os seguintes requisitos:

Clusters privados têm as seguintes restrições:

  • Não é possível converter um cluster não particular em um cluster particular.
  • Quando você usa 172.17.0.0/16 para seu intervalo de IP do plano de controle, não é possível usar esse intervalo para endereços IP de nós, pods ou serviços.
  • 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.
  • Quando a exportação de rota personalizada é ativada para a VPC, criar rotas que se sobrepõem aos intervalos de IP do Google Cloud pode interromper o cluster.
  • É possível adicionar até 50 redes autorizadas (blocos CIDR permitidos) em um projeto. Para mais informações, consulte Adicionar uma rede autorizada a um cluster.

Clusters privados têm as seguintes limitações:

  • O tamanho do bloco RFC 1918 do plano de controle do cluster precisa ser /28.
  • O GKE é capaz de detectar a sobreposição com o bloco de endereços do plano de controle do cluster, mas não consegue detectar a sobreposição em uma rede VPC compartilhada.
  • Todos os nós em um cluster particular são criados sem um IP público. Eles têm acesso limitado às APIs e aos serviços do Google Cloud. Para fornecer acesso à Internet de saída para seus nós particulares, use o Cloud NAT.
  • O acesso privado do Google é ativado automaticamente quando você cria um cluster particular, a menos que esteja usando a VPC compartilhada. Não desative o Acesso privado do Google a menos que esteja usando a NAT para acessar a Internet.
  • Todos os clusters particulares criados antes de 15 de janeiro de 2020 têm um limite de no máximo 25 clusters por rede, supondo que os peerings não estejam sendo usados para outros fins. Consulte reutilização de peering de VPC para mais informações.
  • 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.
  • Se você expandir o intervalo de IP principal de uma sub-rede para acomodar nós adicionais, será necessário adicionar o intervalo de endereços IP primário expandido da sub-rede à lista de redes autorizadas do cluster. Caso contrário, as regras de firewall de permissão de entrada relevantes para o plano de controle não são atualizadas, e os novos nós criados no espaço de endereços IP expandido não poderão ser registrados no plano de controle. Isso pode levar a uma interrupção em que novos nós são continuamente excluídos e substituídos. Essa interrupção pode ocorrer ao executar upgrades de pool de nós ou quando os nós são substituídos automaticamente devido a falhas de sondagem de ativação.
  • Não crie regras de firewall ou regras de políticas hierárquicas de firewall que tenham uma prioridade mais alta do que as regras de firewall criadas automaticamente.

Solução de problemas

Veja nas seções a seguir como resolver problemas comuns relacionados a clusters particulares.

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.

A seguir