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.

Nos clusters do GKE Autopilot, as redes nativas da VPC são ativadas por padrão e não podem ser substituídas.

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.

Crie um cluster

Nesta seção, mostramos como concluir as seguintes tarefas no momento da criação do cluster:

  • Criar um cluster e uma sub-rede simultaneamente.
  • Como criar um cluster em uma sub-rede atual.
  • Criar um cluster e selecionar o intervalo de IP do plano de controle.
  • Crie um cluster com rede de pilha dupla em uma nova sub-rede (disponível nos clusters do Autopilot versão 1.25 ou posterior e clusters padrão versão 1.24 ou posterior).
  • 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).

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.

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. Ao criar uma sub-rede em um cluster particular usando o Private Service Connect, o parâmetro --master-ipv4-cidr é opcional. Para criar um cluster particular:

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

  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 com rede 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. A sub-rede de pilha dupla está disponível nos clusters do Autopilot versão 1.25 ou mais recente e nos clusters padrão versão 1.24 ou mais recente. A sub-rede de pilha dupla não é compatível com pools de nós do Windows Server.

Antes de configurar clusters de pilha dupla, recomendamos que você realize as seguintes ações:

Nesta seção, você vai criar uma sub-rede de pilha dupla e usar essa sub-rede para criar um cluster.

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

  2. Para criar um cluster com uma sub-rede de pilha dupla, use o 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.

      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.

Se estiver usando uma VPC compartilhada, não será possível criar o cluster e a sub-rede simultaneamente. Em vez disso, primeiro um administrador de rede no projeto de host da VPC compartilhada precisa criar a sub-rede de pilha dupla.

  • 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

É possível mudar o tipo de pilha de um cluster ou atualizar uma sub-rede para uma sub-rede de pilha dupla.

Atualizar o tipo de pilha em 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.

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

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.

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.

Configuração avançada para endereços IP internos

As seções a seguir mostram como usar intervalos de endereços IP particulares não RFC 1918 e como ativar intervalos de endereços IP públicos usados de maneira particular.

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.

Esse recurso não tem suporte para os pools de nós do Windows Server.

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 externos de endereços IP de uso particular

Os clusters do GKE podem usar de maneira particular determinados intervalos de endereços IP externos como intervalos de endereços IP de sub-rede internos. É possível usar qualquer endereço IP externo de maneira particular, exceto determinados intervalos restritos, conforme descrito na documentação da rede VPC. Esse recurso não é compatível com os pools de nós do Windows Server.

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

Os intervalos externos 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 externos 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 externo. 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 externos 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 externos 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 externos. 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:

Para clusters padrão, se a versão do cluster for 1.14 ou mais recente, ambas as opções vão funcionar. Se a versão do cluster for anterior à 1.14, só será possível usar a segunda opção (configuração de ip-masq-agent).

A seguir