Criar um cluster nativo de VPC

Mantenha tudo organizado com as coleções Salve e categorize o conteúdo com base nas suas preferências.

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.

Procedimentos

Siga os procedimentos abaixo para criar um cluster nativo de VPC e verificar os intervalos de endereços IP do pod e do serviço.

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 \
        --region=COMPUTE_REGION \
        --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 \
        --region=COMPUTE_REGION \
        --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_REGION: a região de computação do cluster. Para criar um cluster de zona, substitua essa sinalização por --zone=COMPUTE_ZONE, em que COMPUTE_ZONE é uma zona do Compute.
  • 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 SUBNET_NAME especificado. O GKE usa todo o intervalo de endereços IP secundários da sub-rede para os serviços do cluster.

Console

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

    Acessar o Google Kubernetes Engine

  2. Clique em Criar.

  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.

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,

  },
  ...
}

Esta saída inclui os seguintes valores:

  • "clusterIpv4CidrBlock": o tamanho/local do intervalo CIDR para pods. Determina o tamanho do intervalo secundário de pods e pode ser IP/tamanho na notação CIDR, como 10.0.0.0/14, ou /size, como /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 tamanho/local do intervalo CIDR para Serviços. Veja a descrição de "clusterIpv4CidrBlock";
  • "clusterSecondaryRangeName": o nome do intervalo secundário de pods. É obrigatório que o intervalo secundário já exista e pertença à sub-rede associada ao cluster (como a sub-rede especificada com a sinalização --subnetwork).
  • "serviceSecondaryRangeName": o nome do intervalo secundário para Serviços. O intervalo secundário já precisa existir e pertencer à sub-rede associada ao cluster (como a sub-rede especificada pela sinalização --subnetwork).

Terraform

É possíve 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_REGION"
  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_REGION: a região de computação do cluster.
  • 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 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 SUBNET_NAME especificado. O GKE usa todo o intervalo de endereços IP secundários da sub-rede para os serviços do cluster.

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 \
    --region=COMPUTE_REGION \
    --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_REGION: a região de computação do cluster. Para criar um cluster de zona, substitua essa sinalização por --zone=COMPUTE_ZONE, em que COMPUTE_ZONE é uma zona do Compute.
  • 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 particulares 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 TCP/UDP internos usam apenas endereços IP do intervalo de endereços IP primários da sub-rede. Para criar um balanceador de carga TCP/UDP interno com um endereço não RFC 1918, o intervalo de endereços IP primários 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.

Intervalos públicos de uso particular são intervalos de sub-rede. É possível usá-los exclusivamente ou em conjunto com outros intervalos de sub-rede que usam endereços particulares. 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. Ao usar intervalos de endereços IP públicos de uso privado para o CIDR do pod, isso resultaria nas regras SNAT aplicadas ao tráfego entre pods. Para evitar isso, você tem duas opções:

Exemplo de cluster com intervalos públicos usados de maneira particular

No exemplo a seguir, usamos a CLI gcloud para criar um cluster que usa intervalos de endereços IP públicos reutilizados de maneira particular. Use a sinalização a seguir:

  • --enable-ip-alias: cria um cluster nativo de VPC, necessário quando você utiliza de maneira particular intervalos públicos de endereços IP.

O comando a seguir cria um cluster particular nativo de VPC com as seguintes propriedades:

  • Nós que usam o intervalo de endereços IP primários 10.0.0.0/24 da sub-rede;
  • Os pods utilizam de maneira particular o intervalo de endereços IP públicos 5.0.0.0/16 como intervalo secundário de endereços IP da sub-rede para pods.
  • Os serviços utilizam de maneira particular o intervalo público de endereços IP 5.1.0.0/16 como o intervalo secundário de endereços IP da sub-rede para serviços.
  • O intervalo de endereços IP interno do plano de controle é 172.16.0.16/28.
gcloud container clusters create CLUSTER_NAME \
  --enable-ip-alias \
  --enable-private-nodes \
  --disable-default-snat \
  --zone=COMPUTE_ZONE \
  --create-subnetwork name=cluster-subnet,range=10.0.0.0/24 \
  --cluster-ipv4-cidr=5.0.0.0/16 \
  --services-ipv4-cidr=5.1.0.0/16 \
  --master-ipv4-cidr=172.16.0.16/28

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. Neste guia, mostramos como realizar 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).
  • Atualizar o tipo de pilha em um cluster atual (disponível no Autopilot e nos clusters padrão versão 1.25 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:

  • SUBNET_NAME: o nome da sub-rede escolhida.
  • 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:
  • PRIMARY_RANGE: o intervalo de endereços IP IPv4 principal da nova sub-rede, em notação CIDR. Para mais informações, consulte Intervalos de sub-rede.
  • COMPUTE_REGION: a região de computação do cluster.

É possível usar essa sub-rede ao criar um cluster do Autopilot ou Standard.

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 \
          --region REGION \
          --cluster-version VERSION \
          --network VPC_NETWORK_NAME \
          --subnetwork SUBNET_NAME
    

    Substitua:

    • CLUSTER_NAME: o nome do novo cluster de Autopilot.
    • REGION: a região do cluster, como us-central1.
    • VERSION: a versão mais recente do GKE 1.25. Confira as notas da versão do GKE para saber como a versão mais recente foi lançada. Também é possível usar a opção --release-channel para selecionar um canal de lançamento.
    • 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.
  • Para clusters padrão, execute o seguinte comando:

    gcloud container clusters create CLUSTER_NAME \
        --enable-ip-alias \
        --enable-dataplane-v2 \
        --stack-type=ipv4-ipv6 \
        --cluster-version=VERSION \
        --network=NETWORK_NAME \
        --subnetwork=SUBNET_NAME \
        --region=COMPUTE_REGION
    

    Substitua:

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 \
        --region REGION \
        --cluster-version VERSION \
        --network VPC_NETWORK_NAME \
        --create-subnetwork name=SUBNET_NAME
    

    Substitua:

    • CLUSTER_NAME: o nome do novo cluster de Autopilot.
    • REGION: a região do cluster, como us-central1.
    • VERSION: a versão mais recente do GKE 1.25. Confira as notas da versão do GKE para saber como a versão mais recente foi lançada. Também é possível usar a opção --release-channel para selecionar um canal de lançamento.
    • NETWORK_NAME: o nome da rede VPC que contém a sub-rede. Ela precisa ser uma rede de modo personalizado que usa endereços Unicast local exclusivo IPv6 (ULA, na sigla em inglês). Para mais informações, veja como migrar uma rede VPC do modo automático para o modo personalizado.
    • SUBNET_NAME: o nome da nova sub-rede; O GKE pode criar a sub-rede com base nas suas políticas da organização:
      • Se as políticas da organização permitirem a pilha dupla e a rede estiver no modo personalizado, o GKE criará uma sub-rede de pilha dupla e atribuirá um intervalo IPv6 primário à sub-rede.
      • Se as políticas da organização não permitirem pilha dupla ou se a rede estiver no modo automático, o GKE criará uma sub-rede de pilha única (IPv4).
  • 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 \
        --cluster-version=VERSION \
        --network=NETWORK_NAME \
        --create-subnetwork name=SUBNET_NAME,range=PRIMARY_RANGE \
        --region=COMPUTE_REGION
    

    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.
    • VERSION: a versão mais recente do GKE 1.24. Confira as notas da versão do GKE para saber como a versão mais recente foi lançada. Também é possível usar a opção --release-channel para selecionar um canal de lançamento.
    • 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_REGION: a região de computação do 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:

  • É possível alterar o tipo de pilha no Autopilot e Standard, no GKE versão 1.25 ou posterior.
  • 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 gcloud CLI ou o console do Google Cloud:

gcloud

Execute este comando:

  gcloud container clusters update CLUSTER_NAME \
      --stack-type=STACK_TYPE
      --region=COMPUTE_REGION

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_REGION: a região de computação do 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.

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 IP suficiente para os pods

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

O espaço disponível no intervalo de endereços IP do pod não é grande o suficiente para os nós solicitados no cluster. Por exemplo, se o intervalo de endereços IP do pod de um cluster tiver uma máscara de rede com tamanho de /23 (512 endereços), e o máximo de pods por nó for 110, não será possível criar mais de dois nós. Cada nó recebe um intervalo de endereços IP do alias com uma máscara de rede com tamanho de /24.

Soluções

É possível adicionar intervalos de IP do pod ao cluster usando CIDR de vários pods distintos.

Crie um cluster substituto depois de analisar e planejar os intervalos de endereços IP primários e secundários com o tamanho adequado. Consulte Intervalos de IPs para clusters nativos de VPC e Planejamento de intervalo de IPs.

Crie um novo pool de nós com um número máximo de pods menor por nó. Se possível, migre as cargas de trabalho para esse pool de nós e, em seguida, exclua o pool de nós anterior. Reduzir o número máximo de pods por nó permite acomodar mais nós em um intervalo de endereços IP secundários fixo para pods. Consulte Intervalo de endereços IP secundários da sub-rede para pods e Intervalos de limitação de nós para detalhes sobre os cálculos envolvidos.

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. 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 substituirá as regras de mascaramento de IP padrão. 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.

Restriçõ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 de instâncias de VM fora do cluster, mas dentro da rede de VPC e região do cluster, crie um balanceador de carga TCP/UDP interno.
  • 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.

A seguir