Criar um cluster nativo de VPC

Nesta página, explicamos como configurar clusters nativos de VPC no Google Kubernetes Engine (GKE).

Para saber mais sobre benefícios e requisitos dos clusters nativos de VPC, consulte a visão geral dos clusters nativos de VPC.

Antes de começar

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.

Limitações

  • Não é possível converter um cluster nativo de VPC em um cluster baseado em rotas, assim como não é possível converter um cluster baseado em rotas em um cluster nativo de VPC.
  • Os clusters nativos de VPC exigem redes VPC. Redes legadas não são compatíveis.
  • Como acontece com qualquer cluster do GKE, os endereços do Serviço (em inglês) (ClusterIP) só estão disponíveis no cluster. Se você precisar acessar um Serviço do Kubernetes a partir de instâncias de VM fora do cluster, mas dentro da rede VPC e região do cluster, crie um balanceador de carga de rede de passagem interna.
  • Se você usar todos os endereços IP do pod em uma sub-rede, não será possível substituir o intervalo de endereços IP secundário da sub-rede sem colocar o cluster em um estado instável. No entanto, é possível criar outros intervalos de endereços IP de pod usando CIDR de vários pods descontínuos.

Como criar um cluster em uma sub-rede atual

As instruções a seguir demonstram como criar um cluster GKE nativo de VPC em uma sub-rede atual com o método de atribuição de intervalo secundário de sua escolha.

gcloud

  • Para usar um método de atribuição de intervalo secundário gerenciado pelo GKE:

    gcloud container clusters create CLUSTER_NAME \
    --location=COMPUTE_LOCATION \
    --enable-ip-alias \
    --subnetwork=SUBNET_NAME \
    --cluster-ipv4-cidr=POD_IP_RANGE \
    --services-ipv4-cidr=SERVICES_IP_RANGE

  • Para usar um método de atribuição de intervalo secundário gerenciado pelo usuário:

    gcloud container clusters create CLUSTER_NAME \
    --location=COMPUTE_LOCATION \
    --enable-ip-alias \
    --subnetwork=SUBNET_NAME \
    --cluster-secondary-range-name=SECONDARY_RANGE_PODS \
    --services-secondary-range-name=SECONDARY_RANGE_SERVICES

Substitua:

  • CLUSTER_NAME: o nome do cluster do GKE.
  • COMPUTE_LOCATION: a região do Compute Engine para o cluster.
  • SUBNET_NAME: o nome de uma sub-rede atual. O intervalo de endereços IP primário da sub-rede é usado para os nós. A sub-rede precisa estar na mesma região do cluster. Se omitido, o GKE tentará usar uma sub-rede na rede VPC default na região do cluster.
  • Se o método de atribuição do intervalo secundário for gerenciado pelo GKE:
    • POD_IP_RANGE: um intervalo de endereços IP na notação CIDR, como 10.0.0.0/14, ou o tamanho da máscara de sub-rede de um bloco CIDR, como /14. Isso é usado para criar o intervalo de endereços IP secundário da sub-rede para pods. Se você omitir a opção --cluster-ipv4-cidr, o GKE escolherá um intervalo de /14 (218 endereços automaticamente). O intervalo escolhido automaticamente é selecionado aleatoriamente de 10.0.0.0/8 (um intervalo de 224 endereços) e não incluirá intervalos de endereços IP alocados para VMs, rotas existentes ou intervalos alocados a outros clusters. O intervalo escolhido automaticamente pode entrar em conflito com endereços IP reservados, rotas dinâmicas ou rotas em VPCs que fazem peering com esse cluster. Se você usar qualquer um deles, especifique --cluster-ipv4-cidr para evitar conflitos.
    • SERVICES_IP_RANGE é um intervalo de endereços IP na notação CIDR (por exemplo, 10.4.0.0/19) ou o tamanho da máscara de sub-rede de um bloco CIDR (por exemplo, /19). Isso é usado para criar o intervalo de endereços IP secundário da sub-rede para Services.
  • Se o método de atribuição do intervalo secundário for gerenciado pelo usuário:
    • SECONDARY_RANGE_PODS: o nome de um intervalo atual de endereços IP secundários no SUBNET_NAME especificado. O GKE usa todo o intervalo de endereços IP secundários da sub-rede para os pods do cluster.
    • SECONDARY_RANGE_SERVICES: o nome de um intervalo atual de endereços IP secundários no especificado.

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. No painel de navegação, em Cluster, clique em Rede.

  4. Na lista suspensa Rede, selecione uma VPC.

  5. Na lista suspensa Sub-rede de nós, selecione uma sub-rede para o cluster.

  6. Verifique se a caixa de seleção Ativar roteamento de tráfego nativo de VPC (usa IP do alias) está marcada.

  7. Marque a caixa de seleção Criar intervalos secundários automaticamente se você quiser que o método de atribuição do intervalo secundário seja gerenciado pelo GKE. Desmarque essa caixa de seleção se você já tiver criado intervalos secundários para a sub-rede escolhida e quiser que o método de atribuição de intervalo secundário seja gerenciado pelo usuário.

  8. No campo Intervalo de endereços do pod, especifique um intervalo de pods, como 10.0.0.0/14.

  9. No campo Intervalo de endereços de serviço, especifique um intervalo de serviços, como 10.4.0.0/19.

  10. Configure seu cluster.

  11. Clique em Criar.

Terraform

É possível criar um cluster nativo de VPC por meio do Terraform usando um módulo Terraform.

Por exemplo, você pode adicionar o seguinte bloco à configuração do Terraform:

module "gke" {
  source  = "terraform-google-modules/kubernetes-engine/google"
  version = "~> 12.0"

  project_id        = "PROJECT_ID"
  name              = "CLUSTER_NAME"
  region            = "COMPUTE_LOCATION"
  network           = "NETWORK_NAME"
  subnetwork        = "SUBNET_NAME"
  ip_range_pods     = "SECONDARY_RANGE_PODS"
  ip_range_services = "SECONDARY_RANGE_SERVICES"
}

Substitua:

  • PROJECT_ID: o ID do projeto.
  • CLUSTER_NAME: o nome do cluster do GKE.
  • COMPUTE_LOCATION: a região do Compute Engine para o cluster. Para o Terraform, a região do Compute Engine.
  • NETWORK_NAME: o nome de uma rede existente
  • SUBNET_NAME: o nome de uma sub-rede atual. O intervalo de endereços IP primário da sub-rede é usado para os nós. A sub-rede precisa estar na mesma região do cluster.
  • SECONDARY_RANGE_PODS: o nome de um intervalo atual de endereços IP secundários no especificado.
  • SECONDARY_RANGE_SERVICES: o nome de um intervalo atual de endereços IP secundários no especificado.

API

Ao criar um cluster nativo de VPC, você define um objeto IPAllocationPolicy. É possível referir-se a intervalos atuais de endereços IP secundários de sub-redes ou especificar blocos CIDR. Refira-se a intervalos atuais de endereços IP secundários de sub-redes para criar um cluster com o método de atribuição de intervalo secundário que seja gerenciado pelo usuário. Forneça blocos CIDR se desejar que o método de atribuição de intervalos seja gerenciado pelo GKE.

{
  "name": CLUSTER_NAME,
  "description": DESCRIPTION,
  ...
  "ipAllocationPolicy": {
    "useIpAliases": true,
    "clusterIpv4CidrBlock"      : string,
    "servicesIpv4CidrBlock"     : string,
    "clusterSecondaryRangeName" : string,
    "servicesSecondaryRangeName": string,

  },
  ...
}

Esse comando inclui os seguintes valores:

  • "clusterIpv4CidrBlock": o intervalo CIDR para pods. Isso determina o tamanho do intervalo secundário para pods e pode estar na notação CIDR, como 10.0.0.0/14. Um espaço vazio com o tamanho determinado é escolhido no espaço disponível na VPC. Se deixado em branco, um intervalo válido será encontrado e criado com um tamanho padrão;
  • "servicesIpv4CidrBlock": o intervalo CIDR para serviços. Veja a descrição de "clusterIpv4CidrBlock";
  • "clusterSecondaryRangeName": o nome do intervalo secundário de pods. O intervalo secundário já precisa existir e pertencer à sub-rede associada ao cluster.
  • "serviceSecondaryRangeName": o nome do intervalo secundário para Serviços. O intervalo secundário já precisa existir e pertencer à sub-rede associada ao cluster.

Criar um cluster e selecionar o intervalo de IP do plano de controle

Por padrão, os clusters com o Private Service Connect usam o intervalo de sub-rede principal para provisionar o endereço IP interno atribuído ao endpoint do plano de controle. É possível substituir essa configuração padrão selecionando um intervalo de sub-rede diferente somente durante o momento de criação do cluster. As seções a seguir mostram como criar um cluster com o Private Service Connect e modificar o intervalo de sub-rede.

gcloud

Criar cluster com o Private Service Connect definido como público

gcloud container clusters create CLUSTER_NAME \
    --private-endpoint-subnetwork=SUBNET_NAME \
    --location=COMPUTE_LOCATION

Adicione a flag --enable-private-nodes para criar o cluster do Private Service Connect como particular.

Substitua:

  • CLUSTER_NAME: o nome do cluster do GKE.
  • SUBNET_NAME: o nome de uma sub-rede atual.
  • COMPUTE_LOCATION: a região do Compute Engine para o cluster.

O GKE cria um cluster com o Private Service Connect.

Crie um cluster definido como particular:

Na versão 1.29 e mais recentes do GKE, é possível criar um cluster com o Private Service Connect:

gcloud container clusters create CLUSTER_NAME --enable-ip-alias \
    --enable-private-nodes  \
    --private-endpoint-subnetwork=SUBNET_NAME \
    --region=COMPUTE_REGION

Substitua:

  • CLUSTER_NAME: o nome do cluster do GKE.
  • SUBNET_NAME: o nome de uma sub-rede atual. Se você não fornecer um valor private-endpoint-subnetwork mas você usa a flag master-ipv4-cidr o GKE cria uma nova sub-rede que usa os valores definidos master-ipv4-cidr. O GKE usa a nova sub-rede para provisionar o endereço IP interno para o plano de controle.
  • COMPUTE_LOCATION: a região do Compute Engine para o cluster.

Console

Crie um cluster definido como público:

Para atribuir uma sub-rede ao plano de controle de um novo cluster, primeiro é preciso adicionar uma sub-rede. Depois, siga estas etapas:

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

    Acessar o Google Kubernetes Engine

  2. Clique em Criar.

  3. Na seção Padrão ou Autopilot, clique em Configurar.

  4. Em Nome, insira o nome do cluster.

  5. Para clusters padrão, no painel de navegação, em Cluster, clique em Rede.

  6. Na seção Acesso à rede IPv4, faça o seguinte:

    1. Para criar um cluster do GKE como público, selecione Cluster público.
    2. Para criar um cluster do GKE como particular, selecione Cluster particular.

    Em ambos os casos, é possível alterar o modo de isolamento de clusters ao editar a configuração do cluster.

  7. Na seção Opções de rede avançadas, marque a caixa de seleção Substituir a sub-rede de endpoint particular padrão do plano de controle.

  8. Na lista Sub-rede do endpoint particular, selecione a sub-rede criada.

  9. Clique em Concluído. Adicione outras redes autorizadas conforme necessário.

Criar um cluster e uma sub-rede simultaneamente

As instruções a seguir demonstram como criar um cluster e uma sub-rede do GKE nativo de VPC ao mesmo tempo. O método de atribuição de intervalo secundário é gerenciado pelo GKE quando você executa estas duas etapas com um comando.

gcloud

Para criar um cluster nativo e uma sub-rede VPC simultaneamente:

gcloud container clusters create CLUSTER_NAME \
    --location=COMPUTE_LOCATION \
    --enable-ip-alias \
    --create-subnetwork name=SUBNET_NAME,range=NODE_IP_RANGE \
    --cluster-ipv4-cidr=POD_IP_RANGE \
    --services-ipv4-cidr=SERVICES_IP_RANGE

Substitua:

  • CLUSTER_NAME: o nome do cluster do GKE.
  • COMPUTE_LOCATION: a região do Compute Engine para o cluster.
  • SUBNET_NAME: o nome da sub-rede a ser criada. A região da sub-rede é a mesma região do cluster (ou a região que contém o cluster zonal). Use uma string vazia (name="") se quiser que o GKE gere um nome para você;
  • NODE_IP_RANGE: um intervalo de endereços IP na notação CIDR, como 10.5.0.0/20, ou o tamanho da máscara de sub-rede de um bloco CIDR, como /20. Isso é usado para criar o intervalo de endereços IP primário da sub-rede para nós. Se omitido, o GKE escolhe um intervalo de IP disponível na VPC com um tamanho de /20;
  • POD_IP_RANGE: um intervalo de endereços IP na notação CIDR, como 10.0.0.0/14, ou o tamanho da máscara de sub-rede de um bloco CIDR, como /14. Isso é usado para criar o intervalo de endereços IP secundário da sub-rede para pods. Se omitido, o GKE usa um intervalo /14 escolhido aleatoriamente, contendo 218 endereços. O intervalo escolhido automaticamente é selecionado aleatoriamente a partir de 10.0.0.0/8 (um intervalo de 224 endereços) e não incluirá intervalos de endereços IP alocados para VMs, rotas atuais ou intervalos alocados a outros clusters. O intervalo escolhido automaticamente pode entrar em conflito com endereços IP reservados, rotas dinâmicas ou rotas em VPCs que fazem peering com esse cluster. Se você usar qualquer um deles, especifique --cluster-ipv4-cidr para evitar conflitos.
  • SERVICES_IP_RANGE: um intervalo de endereços IP na notação CIDR, como 10.4.0.0/19, ou o tamanho da máscara de sub-rede de um bloco CIDR, como /19. Isso é usado para criar o intervalo de endereços IP secundário da sub-rede para serviços. Se omitido, o GKE usa /20, o tamanho padrão do intervalo de endereços IP para serviços.

Console

Não é possível criar um cluster e uma sub-rede simultaneamente usando o Console do Google Cloud. Em vez disso, primeiro crie uma sub-rede e depois crie o cluster em uma sub-rede existente.

API

Para criar um cluster nativo de VPC, defina um objeto IPAllocationPolicy no recurso do cluster:

{
  "name": CLUSTER_NAME,
  "description": DESCRIPTION,
  ...
  "ipAllocationPolicy": {
    "useIpAliases": true,
    "createSubnetwork": true,
    "subnetworkName": SUBNET_NAME
  },
  ...
}

O campo createSubnetwork cria e provisiona automaticamente uma sub-rede para o cluster. O campo subnetworkName é opcional. Se for deixado em branco, um nome será automaticamente escolhido para a sub-rede.

Usar intervalos de endereços IP não RFC 1918

Os clusters do GKE podem usar intervalos de endereços IP particulares fora dos intervalos RFC 1918 para nós, pods e serviços. Consulte intervalos válidos na documentação da rede VPC para ver uma lista de intervalos particulares não RFC 1918 que podem ser usados como endereços IP internos para intervalos de sub-rede.

Os intervalos de endereços IP particulares não RFC 1918 são compatíveis com clusters particulares e não particulares.

Os intervalos particulares não RFC 1918 são intervalos de sub-redes. É possível usá-los exclusivamente ou com os intervalos de sub-redes RFC 1918. Nós, pods e serviços continuam a usar os intervalos de sub-redes, conforme descrito em Intervalos de IPs para clusters nativos de VPC. Se você usa intervalos não RFC 1918, lembre-se do seguinte:

  • Os intervalos de sub-redes, mesmo aqueles que usam intervalos não RFC 1918, precisam ser atribuídos manualmente ou pelo GKE antes da criação dos nós do cluster. Não é possível alternar ou parar de usar intervalos de sub-redes não RFC 1918, a menos que você substitua o cluster.

  • Os balanceadores de carga de rede de passagem interna usam apenas endereços IP do intervalo de endereços IP principais da sub-rede. Para criar um balanceador de carga de rede de passagem interna com um endereço não RFC 1918, o intervalo de endereços IP principais da sub-rede precisa ser não RFC 1918.

Os destinos fora do cluster podem ter dificuldade para receber tráfego de intervalos particulares não RFC 1918. Por exemplo, os intervalos particulares RFC 1112 (classe E) são normalmente usados como endereços multicast. Se um destino fora do cluster não puder processar pacotes com origens que são endereços IP particulares fora do intervalo RFC 1918, será possível realizar as seguintes ações:

  • Usar um intervalo RFC 1918 para o intervalo de endereços IP primários da sub-rede. Desse modo, os nós no cluster usam endereços RFC 1918.
  • Garantir que seu cluster esteja executando o agente de mascaramento de IP e que os destinos não estejam na lista nonMasqueradeCIDRs. Dessa maneira, os pacotes enviados dos pods têm as fontes alteradas (SNAT) para os endereços dos nós, que são RFC 1918.

Ativar intervalos públicos de endereços IP de uso particular

Os clusters do GKE podem usar de maneira particular determinados intervalos de endereços IP públicos como intervalos de endereços IP de sub-rede internos. É possível usar qualquer endereço IP público de maneira particular, exceto determinados intervalos restritos, conforme descrito na documentação da rede VPC.

Seu cluster precisa ser um cluster nativo de VPC para usar intervalos de endereços IP públicos usados de maneira particular. Os clusters baseados em rotas não são compatíveis.

Os intervalos públicos usados de modo privado são intervalos de sub-redes. É possível usá-los exclusivamente ou em conjunto com outros intervalos de sub-redes que utilizam endereços privados. Nós, pods e serviços continuam a usar os intervalos de sub-redes, conforme descrito em Intervalos de IPs para clusters nativos de VPC. Considere as seguintes informações ao reutilizar endereços IP públicos de maneira particular:

  • Quando você usa um intervalo público de endereços IP como um intervalo de sub-rede, o cluster não pode mais se comunicar com sistemas na Internet que usam esse intervalo público. Ele se tornará um intervalo interno de endereços IP na rede VPC do cluster.

  • Os intervalos de sub-redes (mesmo os que utilizam de maneira particular os intervalos públicos de endereços IP) precisam ser atribuídos manualmente ou pelo GKE antes da criação dos nós do cluster. Não é possível alternar ou parar de usar endereços IP públicos de maneira particular, a menos que você substitua o cluster.

Por padrão, o GKE implementa o SNAT nos nós para destinos de IP públicos. Se você tiver configurado o CIDR do pod para usar endereços IP externos, as regras SNAT serão aplicadas ao tráfego entre pods. Para evitar isso, você tem duas opções:

Use uma rede de pilha dupla IPv4/IPv6 para criar um cluster de pilha dupla

É possível criar um cluster com rede de pilha dupla IPv4/IPv6 em uma sub-rede de pilha dupla nova ou atual.

Nesta seção, mostramos como concluir as seguintes tarefas:

  • Crie uma sub-rede de pilha dupla (disponível nos clusters do Autopilot versão 1.25 ou posterior e clusters padrão versão 1.24 ou posterior).
  • Atualize uma sub-rede para uma pilha de pilha dupla (disponível nos clusters do Autopilot versão 1.25 e posterior e clusters padrão versão 1.24 ou posterior).
  • Crie um cluster com rede de pilha dupla (disponível nos clusters do Autopilot versão 1.25 e posterior e clusters padrão versão 1.24 ou posterior). Os clusters do Autopilot do GKE usam um cluster de pilha dupla por padrão quando você usa uma sub-rede de pilha dupla. Após a criação do cluster, será possível atualizar o cluster do Autopilot para que seja somente IPv4.
  • Crie um cluster de pilha dupla e uma sub-rede de pilha dupla simultaneamente (disponível nos clusters do Autopilot versão 1.25 e posterior e clusters padrão versão 1.24 ou posterior).

Para saber mais sobre os benefícios e os requisitos dos clusters do GKE com a visão geral da rede de pilha dupla, consulte a documentação do cluster nativo de VPC.

Criar uma sub-rede de pilha dupla.

Para criar uma sub-rede de pilha dupla, execute o seguinte comando:

gcloud compute networks subnets create SUBNET_NAME \
    --stack-type=ipv4-ipv6 \
    --ipv6-access-type=ACCESS_TYPE \
    --network=NETWORK_NAME \
    --range=PRIMARY_RANGE \
    --region=COMPUTE_REGION

Substitua:

Atualizar uma sub-rede atual para uma sub-rede de pilha dupla

Para atualizar uma sub-rede atual para uma sub-rede de pilha dupla, execute o seguinte comando. A atualização de uma sub-rede não afeta os clusters IPv4 atuais.

gcloud compute networks subnets update SUBNET_NAME \
    --stack-type=ipv4-ipv6 \
    --ipv6-access-type=ACCESS_TYPE \
    --region=COMPUTE_REGION

Substitua:

  • SUBNET_NAME: o nome da sub-rede.
  • ACCESS_TYPE: a capacidade de alternar para a Internet pública. Use INTERNAL para clusters privados e EXTERNAL para clusters públicos. Se --ipv6-access-type não for especificado, o tipo de acesso padrão será EXTERNAL.
  • COMPUTE_REGION: a região de computação do cluster.

Criar um cluster com rede de pilha dupla

Para criar um cluster com uma sub-rede de pilha dupla, é possível usar gcloud CLI ou o console do Google Cloud:

gcloud

  • Para clusters do Autopilot, execute o seguinte comando: 

      gcloud container clusters create-auto CLUSTER_NAME \
      --location=COMPUTE_LOCATION \
      --network=NETWORK_NAME \
      --subnetwork=SUBNET_NAME

    Substitua:

    • CLUSTER_NAME: o nome do novo cluster de Autopilot.
    • COMPUTE_LOCATION: a região do Compute Engine para o cluster.
    • NETWORK_NAME: o nome da rede VPC que contém a sub-rede. Esta rede VPC precisa ser uma rede de modo personalizado. Para mais informações, veja como migrar uma rede VPC do modo automático para o modo personalizado.

    • SUBNET_NAME: o nome da sub-rede de pilha dupla. Para saber mais, veja como criar uma sub-rede de pilha dupla.

      Os clusters do Autopilot do GKE usam um cluster de pilha dupla por padrão quando você usa uma sub-rede de pilha dupla. Após a criação do cluster, será possível atualizar o cluster do Autopilot para que seja somente IPv4.

Console

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

    Acessar o Google Kubernetes Engine

  2. Clique em Criar.

  3. Na seção Padrão ou Autopilot, clique em Configurar.

  4. Configure o cluster conforme necessário.

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

  6. Na lista Rede, selecione o nome da sua rede.

  7. Na lista Sub-rede de nós, selecione o nome da sua sub-rede de pilha dupla.

  8. Para clusters padrão, selecione o botão de opção IPv4 e IPv6 (pilha dupla). Essa opção só estará disponível se você selecionar uma sub-rede de pilha dupla.

    Os clusters do Autopilot usam como padrão um cluster de pilha dupla quando você usa uma sub-rede de pilha dupla.

  9. Clique em Criar.

Crie um cluster de pilha dupla e uma sub-rede simultaneamente

É possível criar uma sub-rede e um cluster de pilha dupla ao mesmo tempo. O GKE cria uma sub-rede IPv6 e atribui um intervalo primário de IPv6 externo à sub-rede.

  • Para clusters do Autopilot, execute o seguinte comando: 

    gcloud container clusters create-auto CLUSTER_NAME \
    --location=COMPUTE_LOCATION \
    --network=NETWORK_NAME \
    --create-subnetwork name=SUBNET_NAME

    Substitua:

  • Para clusters padrão, execute o seguinte comando: 

    gcloud container clusters create CLUSTER_NAME \
    --enable-ip-alias \
    --stack-type=ipv4-ipv6 \
    --ipv6-access-type=ACCESS_TYPE \
    --network=NETWORK_NAME \
    --create-subnetwork name=SUBNET_NAME,range=PRIMARY_RANGE \
    --location=COMPUTE_LOCATION

    Substitua:

    • CLUSTER_NAME: o nome do novo cluster escolhido.
    • ACCESS_TYPE: a capacidade de alternar para a Internet pública. Use INTERNAL para clusters privados e EXTERNAL para clusters públicos. Se --ipv6-access-type não for especificado, o tipo de acesso padrão será EXTERNAL.
    • NETWORK_NAME: o nome da rede que conterá a nova sub-rede. Essa rede precisa atender às seguintes condições:
    • SUBNET_NAME: o nome da nova sub-rede escolhida.
    • PRIMARY_RANGE: o intervalo de endereços IPv4 principal da nova sub-rede, em notação CIDR. Para mais informações, consulte Intervalos de sub-rede.
    • COMPUTE_LOCATION: a região do Compute Engine para o cluster.

Atualizar o tipo de pilha em um cluster atual

É possível alterar o tipo de pilha de um cluster atual. Antes de alterar o tipo de pilha em um cluster atual, considere as seguintes limitações:

  • A alteração do tipo de pilha é compatível com novos clusters do GKE que executam a versão 1.25 ou posterior. Os clusters do GKE que receberam upgrade das versões 1.24 para as versões 1.25 ou 1.26 podem receber erros de validação ao ativar a rede de pilha dupla. Em caso de erros, entre em contato com a equipe de suporte do Google Cloud.

  • Alterar o tipo de pilha é uma operação disruptiva porque o GKE reinicia os componentes no plano de controle e nos nós.

  • O GKE respeita as janelas de manutenção configuradas ao recriar nós. Isso significa que o tipo de pilha do cluster não estará operacional no cluster até ocorrer a próxima janela de manutenção. Caso não queira esperar, atualize o pool de nós manualmente definindo a sinalização --cluster-version para a mesma versão do GKE que o plano de controle já está executando. Você precisará usar a gcloud CLI se utilizar essa solução alternativa. Para mais informações, consulte avisos sobre janelas de manutenção.

  • Alterar o tipo de pilha não altera automaticamente a família de IP dos serviços atuais. Aplicam-se as seguintes condições:

    • Se você muda uma única pilha para duas pilhas, os serviços existentes permanecem em uma única pilha.
    • Se você alterar uma pilha dupla para uma única pilha, os serviços com endereços IPv6 entrarão em estado de erro. Exclua o serviço e crie um com o ipFamilies correto. Para saber mais, consulte um exemplo de como configurar uma implantação.

Para atualizar um cluster nativo de VPC, use a CLI gcloud ou o console do Google Cloud:

gcloud

Execute este comando:

  gcloud container clusters update CLUSTER_NAME \
      --stack-type=STACK_TYPE \
      --location=COMPUTE_LOCATION

Substitua:

  • CLUSTER_NAME: o nome do cluster que você quer atualizar.
  • STACK_TYPE: o tipo de pilha. Substitua por um dos seguintes valores:
    • ipv4: para atualizar um cluster de pilha dupla para um cluster somente IPv4. O GKE usa o intervalo de endereços IPv4 principal da sub-rede do cluster.
    • ipv4-ipv6: para atualizar um cluster IPv4 atual para pilha dupla. Só é possível alterar um cluster para pilha dupla se a sub-rede subjacente for compatível com pilha dupla. Para saber mais, consulte Atualizar uma sub-rede atual para uma sub-rede de pilha dupla.
  • COMPUTE_LOCATION: a região do Compute Engine para o cluster.

Console

  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 Tipo de pilha, clique em Editar.

  4. Na caixa de diálogo Editar tipo de pilha, marque a caixa de seleção do tipo de pilha de cluster que você precisa.

  5. Clique em Salvar alterações.

Criar um serviço de pilha dupla IPv4/IPv6

É possível criar um serviço de pilha dupla IPv4/IPv6 do tipo ClusterIP ou NodePort. Os novos clusters do GKE que executam a versão 1.29 ou mais recente são compatíveis com serviços de pilha dupla do tipo LoadBalancer. Para saber mais, consulte Serviço LoadBalancer de pilha dupla de IPv4/IPv6.

Para cada um desses tipos de serviço, é possível definir os campos ipFamilies e ipFamilyPolicy como IPv4, IPv6 ou uma pilha dupla. Para saber mais, consulte Serviços de pilha dupla IPv4/IPv6.

Verificar o tipo de pilha, o pod e os intervalos de endereços IP do serviço

Depois de criar um cluster nativo de VPC, é possível verificar os intervalos de pod e Serviço.

gcloud

Para verificar o cluster, execute o seguinte comando:

gcloud container clusters describe CLUSTER_NAME

A saída tem um bloco ipAllocationPolicy. O campo stackType descreve o tipo de definição de rede. Para cada tipo, é possível ver as seguintes informações de rede:

  • Informações de rede IPv4:

    • clusterIpv4Cidr é o intervalo secundário de pods.
    • servicesIpv4Cidr é o intervalo secundário de serviços.

  • Informações de rede IPv6 (se um cluster tiver rede de pilha dupla):

    • ipv6AccessType: a capacidade de alternar para a Internet pública. INTERNAL para endereços IPv6 particulares e EXTERNAL para endereços IPv6 públicos.
    • subnetIpv6CidrBlock: o intervalo de endereços IPv6 secundário da nova sub-rede.
    • servicesIpv6CidrBlock: o intervalo de endereços atribuído aos serviços IPv6 no cluster de pilha dupla.

Console

Para verificar o cluster, siga estas etapas:

  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 que você quer inspecionar.

Os intervalos secundários são exibidos na seção Rede:

  • O intervalo de endereços do pod é o intervalo secundário dos pods.
  • O intervalo de endereços de serviço é o intervalo secundário dos serviços.

Solução de problemas

Nesta seção, há orientações para resolver problemas relacionados a clusters nativos de VPC. Também é possível ver os insights de uso do endereço IP do GKE.

O recurso de rede padrão não está pronto

Sintomas

Você verá uma mensagem de erro semelhante a esta:

projects/[PROJECT_NAME]/regions/XXX/subnetworks/default
Causas possíveis

Há operações paralelas na mesma sub-rede. Por exemplo, outro cluster nativo de VPC está sendo criado ou um intervalo secundário está sendo adicionado ou excluído na sub-rede.

Resolução

Repita o comando.

Valor inválido para IPCidrRange.

Sintomas

Você verá uma mensagem de erro semelhante a esta:

resource.secondaryIpRanges[1].ipCidrRange': 'XXX'. Invalid IPCidrRange: XXX conflicts with existing subnetwork 'default' in region 'XXX'
Causas possíveis

Outro cluster nativo de VPC está sendo criado simultaneamente, e está tentando alocar os mesmos intervalos na mesma rede VPC.

O mesmo intervalo secundário está sendo adicionado à sub-rede na mesma rede VPC.

Resolução

Se esse erro reaparecer na criação do cluster, quando nenhum intervalo secundário foi especificado, tente executar novamente o comando de criação do cluster.

Não há espaço de endereços IP suficiente para o pod

Sintomas

O cluster está preso em um estado de provisionamento por um longo período de tempo

A criação de cluster retorna um erro do grupo de instâncias gerenciadas (MIG, na sigla em inglês)

Quando você adiciona um ou mais nós a um cluster, o seguinte erro é exibido:

[IP_SPACE_EXHAUSTED] Instance 'INSTANCE_NAME' creation failed: IP space of 'projects/PROJECT_ID/regions/REGION/subnetworks/SUBNET_NAME-SECONDARY_RANGE_NAME' is exhausted.
Causas possíveis

Esgotamento de endereços IP para nós: o intervalo de endereços IP principal da sub-rede atribuída ao cluster fica sem endereços IP disponíveis. Isso geralmente acontece ao escalonar pools de nós ou criar clusters grandes.

Esgotamento de endereços IP para pods: o intervalo CIDR do pod atribuído ao cluster está cheio. Isso ocorre quando o número de pods excede a capacidade do CIDR, especialmente com alta densidade de pods por nó ou implantações grandes.

Convenções específicas de nomenclatura de sub-rede: a forma como uma sub-rede é nomeada em uma mensagem de erro pode ajudar a descobrir se o problema está no intervalo de endereços IP para nós (em que os próprios nós recebem o intervalo de endereços IP) ou no intervalo de endereços IP para pods (em que os contêineres dentro dos pods recebem os endereços IP).

Esgotamento do intervalo secundário (Autopilot): nos clusters do Autopilot, os intervalos secundários atribuídos aos endereços IP para pods são esgotados devido ao escalonamento ou à alta densidade de pods.

Solução

Colete as seguintes informações sobre o cluster: nome, versão do plano de controle, modo de operação, nome da VPC associada, nome da sub-rede e CIDR. Além disso, observe todos os intervalos IPv4 padrão e adicionais para pods de cluster (incluindo nomes e CIDRs), se o roteamento de tráfego nativo da VPC está ativado e a configuração de pods máximos por nó nos níveis do cluster e do pool de nós (se aplicável). Observe os pools de nós afetados e os intervalos de endereços IPv4 específicos para pods e as configurações de pods máximos por nó, se forem diferentes das configurações de todo o cluster. Além disso, registre as configurações padrão e personalizadas (se houver) para os pods máximos por nó na configuração do pool de nós.

Confirmar problema de esgotamento de endereços IP

  • Network Intelligence Center: verifique se há altas taxas de alocação de endereços IP nos intervalos de endereços IP para pods no Network Intelligence Center do cluster do GKE.

    Se você observar uma alta taxa de alocação de endereços IP nos intervalos de pods no Network Intelligence Center, isso significa que o intervalo de endereços IP para pods está esgotado.

    Se os intervalos de endereços IP para pods mostrarem taxas de alocação normais, mas você ainda estiver enfrentando esgotamento de endereços IP, é provável que o intervalo de endereços IP para nós esteja esgotado.

  • Registros de auditoria: examine o campo resourceName nas entradas IP_SPACE_EXHAUSTED, comparando-o com os nomes de sub-redes ou nomes de intervalos de endereços IP secundários para pods.

  • Verifique se o intervalo de endereços IP esgotado é um intervalo de endereços IP para nós ou um intervalo de endereços IP para pods.

    Para verificar se o intervalo de endereços IP esgotado é um intervalo de endereços IP para nós ou intervalo de endereços IP para pods, verifique se o valor resourceName na parte ipSpaceExhausted de uma entrada de registro IP_SPACE_EXHAUSTED está relacionada ao nome da sub-rede ou ao nome do intervalo de endereços IPv4 secundário para pods usados no cluster do GKE afetado.

    Quando o valor de resourceName está no formato "[Subnet_name]", o intervalo de endereços IP para nós está esgotado. Quando o valor de resourceName está no formato "[Subnet_name]-[Name_of_Secondary_IPv4_range_for_pods]-[HASH_8BYTES]", o intervalo de endereços IP para pods está esgotado.

Resolva o esgotamento de endereços IP para pods:

  • Redimensione o CIDR de pods existentes: aumente o tamanho do intervalo de endereços IP para pods existentes. É possível adicionar intervalos de IP do pod ao cluster usando CIDR de vários pods distintos.
  • Crie outras sub-redes: adicione ao cluster sub-redes com CIDRs de pods dedicados.

Reduza os pods por nó para liberar endereços IP:

Resolva o esgotamento de endereços IP para nós:

  • Revise o planejamento de endereços IP: verifique se o intervalo de endereços IP do nó está alinhado aos seus requisitos de escalonamento.
  • Crie um novo cluster (se necessário): se o intervalo de endereços IP para nós for muito restrito, crie um cluster de substituição com o dimensionamento adequado do intervalo de endereços IP. Consulte Intervalos de IPs para clusters nativos de VPC e Planejamento de intervalo de IPs.

Confirmar se o SNAT padrão está desativado

Use o seguinte comando para verificar o status do SNAT padrão:

gcloud container clusters describe CLUSTER_NAME

Substitua CLUSTER_NAME pelo nome do cluster.

A saída será assim:

networkConfig:
  disableDefaultSnat: true
  network: ...

Não é possível usar --disable-default-snat sem --enable-ip-alias

Essa mensagem de erro e must disable default sNAT (--disable-default-snat) before using public IP address privately in the cluster significam que você precisa definir explicitamente a sinalização --disable-default-snat ao criar o cluster, já que está usando endereços IP públicos no cluster particular.

Se você vir mensagens de erro como cannot disable default sNAT ... , isso significa que o SNAT padrão não pode ser desativado no cluster. Para resolver esse problema, revise a configuração do cluster.

Como depurar o Cloud NAT com o SNAT padrão desativado

Se você tiver um cluster particular criado com a sinalização --disable-default-snat, tiver configurado o Cloud NAT para acesso à Internet e não estiver vendo o tráfego vinculado à Internet dos seus pods, verifique se o intervalo de pods está incluído na configuração do Cloud NAT.

Se houver um problema com a comunicação entre pods, examine as regras de iptables nos nós para verificar se os intervalos de pods não estão mascarados por regras de iptables.

Para mais informações, consulte a documentação de mascaramento de IP do GKE.

Se você não tiver configurado um agente de mascaramento de IP para o cluster, o GKE garantirá automaticamente que a comunicação entre pods não seja mascarada. No entanto, se um agente de mascaramento de IP estiver configurado, ele modificará as regras padrão de mascaramento de IP. Verifique se as regras extras estão configuradas no agente de mascaramento de IP para ignorar o mascaramento dos intervalos de pod.

A comunicação de rede do cluster de pilha dupla não está funcionando conforme o esperado

Causas possíveis
As regras de firewall criadas pelo cluster do GKE não incluem os endereços IPv6 alocados.
Resolução
Para validar a regra de firewall, siga estas etapas:

  1. Verifique o conteúdo da regra de firewall:

    gcloud compute firewall-rules describe FIREWALL_RULE_NAME

    Substitua FIREWALL_RULE_NAME pelo nome da regra de firewall.

    Cada cluster de pilha dupla cria uma regra de firewall que permite que nós e pods se comuniquem uns com os outros. O conteúdo da regra de firewall é semelhante ao seguinte:

    allowed:
- IPProtocol: esp
- IPProtocol: ah
- IPProtocol: sctp
- IPProtocol: tcp
- IPProtocol: udp
- IPProtocol: '58'
creationTimestamp: '2021-08-16T22:20:14.747-07:00'
description: ''
direction: INGRESS
disabled: false
enableLogging: false
id: '7326842601032055265'
kind: compute#firewall
logConfig:
  enable: false
name: gke-ipv6-4-3d8e9c78-ipv6-all
network: https://www.googleapis.com/compute/alpha/projects/my-project/global/networks/alphanet
priority: 1000
selfLink: https://www.googleapis.com/compute/alpha/projects/my-project/global/firewalls/gke-ipv6-4-3d8e9c78-ipv6-all
selfLinkWithId: https://www.googleapis.com/compute/alpha/projects/my-project/global/firewalls/7326842601032055265
sourceRanges:
- 2600:1900:4120:fabf::/64
targetTags:
- gke-ipv6-4-3d8e9c78-node

    O valor de sourceRanges precisa ser igual ao de subnetIpv6CidrBlock. O valor targetTags precisa ser igual às tags nos nós do GKE. Para corrigir esse problema, atualize a regra de firewall com as informações do bloco ipAllocationPolicy do cluster.

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

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 em que o endpoint do Private Service Connect está alocado. 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 vê-lo no console do Google Cloud ou na gcloud CLI.

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.

A seguir