Crie um cluster nativo de VPC

Esta página explica como configurar clusters nativos da VPC no Google Kubernetes Engine (GKE).

Para saber mais sobre as vantagens e os requisitos dos clusters nativos de VPC, consulte a vista geral dos clusters nativos de VPC.

Para clusters do GKE Autopilot, as redes nativas da VPC estão ativadas por predefinição e não podem ser substituídas.

Antes de começar

Antes de começar, certifique-se de que realizou as seguintes tarefas:

• Ative a API Google Kubernetes Engine.
Ative a API Google Kubernetes Engine
• Se quiser usar a CLI gcloud para esta tarefa, instale-a e, em seguida, inicialize-a. Se instalou anteriormente a CLI gcloud, execute gcloud components update para obter a versão mais recente.

Limitações

• Não pode converter um cluster nativo de VPC num cluster baseado em rotas, nem converter um cluster baseado em rotas num cluster nativo de VPC.

• Os clusters nativos de VPC requerem redes VPC. As redes antigas não são suportadas.

• Tal como acontece com qualquer cluster do GKE, os endereços Service (ClusterIP) só estão disponíveis a partir do cluster. Se precisar de aceder a um serviço Kubernetes a partir de instâncias de VM fora do cluster, mas na rede VPC e na região do cluster, crie um balanceador de carga de rede de encaminhamento interno.

• Se usar todos os endereços IP do pod numa sub-rede, não pode substituir o intervalo de endereços IP secundários da sub-rede sem colocar o cluster num estado instável. No entanto, pode criar intervalos de endereços IP de pods adicionais através do CIDR de vários pods não contíguos.

Crie um cluster

Esta secção mostra como concluir as seguintes tarefas no momento da criação do cluster:

• Crie um cluster e uma sub-rede em simultâneo.
• Crie um cluster numa sub-rede existente.
• Crie um cluster e selecione o intervalo de endereços IP do plano de controlo.
• Crie um cluster com rede de pilha dupla numa nova sub-rede (disponível na versão 1.25 ou posterior dos clusters do Autopilot e na versão 1.24 ou posterior dos clusters Standard).
• Crie um cluster de pilha dupla e uma sub-rede de pilha dupla em simultâneo (disponível na versão 1.25 ou posterior dos clusters do Autopilot e na versão 1.24 ou posterior dos clusters Standard).

Também pode criar um cluster e ativar a gestão automática de endereços IP no cluster (pré-visualização), o que significa que o GKE cria automaticamente sub-redes e gere endereços IP por si. Para mais informações, consulte o artigo Use a gestão automática de endereços IP.

Depois de criar o cluster, pode modificar o acesso ao plano de controlo do cluster. Para saber mais, consulte o artigo Personalize o isolamento de rede no GKE.

Crie um cluster e uma sub-rede em simultâneo

As instruções seguintes demonstram como criar um cluster do GKE e uma sub-rede nativos da VPC ao mesmo tempo. O método de atribuição de intervalo secundário é gerido pelo GKE quando executa estes dois passos com um comando.

Se usar a VPC partilhada, não pode criar o cluster e a sub-rede em simultâneo. Em alternativa, os administradores de rede no projeto anfitrião da VPC partilhada têm de criar primeiro a sub-rede. Em seguida, pode criar o cluster numa sub-rede existente com um método de atribuição de intervalo secundário gerido pelo utilizador.

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

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

Depois de criar o cluster, pode modificar o acesso ao plano de controlo do cluster. Para saber mais, consulte o artigo Personalize o isolamento de rede no GKE.

Crie um cluster numa sub-rede existente

As instruções seguintes demonstram como criar um cluster do GKE nativo da VPC numa sub-rede existente com o seu método de atribuição de intervalo secundário.

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

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

  },
  ...
}

Depois de criar o cluster, pode modificar o acesso ao plano de controlo do cluster. Para saber mais, consulte o artigo Personalize o isolamento de rede no GKE.

Crie um cluster e selecione o intervalo de endereços IP do plano de controlo

Por predefinição, os clusters na versão 1.29 ou posterior usam o intervalo de sub-rede principal para aprovisionar o endereço IP interno atribuído ao ponto final do plano de controlo. Pode substituir esta definição predefinida selecionando um intervalo de sub-redes diferente apenas durante a criação do cluster.

As secções seguintes mostram como criar um cluster e substituir o intervalo de sub-rede.

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

Projete metadados para intervalos de endereços IP secundários

Quando cria ou atualiza um cluster do GKE, o GKE adiciona automaticamente entradas de metadados ao nível do projeto, como google_compute_project_metadata, para acompanhar a utilização do intervalo de endereços IP secundários, incluindo em ambientes de VPC partilhada. Estes metadados validam se o GKE atribui corretamente endereços IP para pods e serviços, o que ajuda a evitar conflitos.

O GKE gere automaticamente estes metadados.

Os metadados têm o seguinte formato:

key:   gke-REGION-CLUSTER_NAME-GKE_UID-secondary-ranges
value: pods:SHARED_VPC_NETWORK:SHARED_VPC_SUBNETWORK:CLUSTER_PODS_SECONDARY_RANGE_NAME

where:

• REGION: a Trusted Cloud by S3NS região onde o cluster está localizado.

• CLUSTER_NAME: o nome do cluster do GKE.

• GKE_UID: um identificador exclusivo para o cluster do GKE.

• VPC_NETWORK: o nome da rede VPC usada pelo cluster.

• VPC_SUBNETWORK: o nome da sub-rede na rede VPC usada pelo cluster.

• CLUSTER_PODS_SECONDARY_RANGE_NAME: o nome do intervalo de endereços IP secundário usado para os pods do cluster.

Crie um cluster com rede de pilha dupla

Pode criar um cluster com rede de pilha dupla IPv4/IPv6 numa sub-rede de pilha dupla nova ou existente. A sub-rede de pilha dupla está disponível na versão 1.25 ou posterior dos clusters do Autopilot e na versão 1.24 ou posterior dos clusters Standard. A sub-rede de pilha dupla não é suportada com pools de nós do Windows Server.

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

• Saiba mais sobre as vantagens e os requisitos dos clusters do GKE com rede de pilha dupla.
• Consulte as restrições e as limitações das redes de pilha dupla.

Nesta secção, começa por criar uma sub-rede de pilha dupla e usa esta 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 o seguinte:

   • SUBNET_NAME: o nome da sub-rede que escolher.
   • ACCESS_TYPE: a capacidade de encaminhamento para a Internet pública. Use INTERNAL para endereços IPv6 internos ou EXTERNAL para endereços IPv6 externos. Se --ipv6-access-type não for especificado, o tipo de acesso predefinido é EXTERNAL.
   • NETWORK_NAME: o nome da rede que vai conter a nova sub-rede. Esta rede tem de cumprir as seguintes condições:
     • Tem de ser uma rede VPC no modo personalizado. Para mais informações, veja como mudar uma rede VPC do modo automático para o modo personalizado.
     • Se substituir ACCESS_TYPE por INTERNAL, a rede tem de usar endereços de unicast IPv6 locais exclusivos (ULA).
   • PRIMARY_RANGE: o intervalo de endereços IP IPv4 principal para a nova sub-rede, na notação CIDR. Para mais informações, consulte o artigo Intervalos de sub-redes.
   • COMPUTE_REGION: a região de computação do cluster.

2. Para criar um cluster com uma sub-rede de pilha dupla, use o comando gcloud CLI ou a consola Trusted Cloud :

Crie um cluster de pilha dupla e uma sub-rede em simultâneo

Pode criar uma sub-rede e um cluster de pilha dupla em simultâneo. O GKE cria uma sub-rede IPv6 e atribui um intervalo principal IPv6 externo à sub-rede.

Se usar a VPC partilhada, não pode criar o cluster e a sub-rede em simultâneo. Em alternativa, um administrador de rede no projeto anfitrião da VPC partilhada tem de criar primeiro 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 o seguinte:

  • CLUSTER_NAME: o nome do novo cluster do Autopilot.
  • COMPUTE_LOCATION: a localização do Compute Engine para o cluster.
  • NETWORK_NAME: o nome de uma rede de VPC que contém a sub-rede. Esta rede VPC tem de ser uma rede VPC de modo personalizado que use endereços de transmissão única IPv6 locais exclusivos (ULA). Para mais informações, veja como mudar 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 sua organização permitirem a pilha dupla e a rede estiver no modo personalizado, o GKE cria uma sub-rede de pilha dupla e atribui um intervalo principal IPv6 externo à sub-rede .
    • Se as políticas da sua organização não permitirem a pilha dupla ou se a rede estiver no modo automático, o GKE cria 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 \
      --network=NETWORK_NAME \
      --create-subnetwork name=SUBNET_NAME,range=PRIMARY_RANGE \
      --location=COMPUTE_LOCATION
  

  Substitua o seguinte:

  • CLUSTER_NAME: o nome do novo cluster que escolher.
  • ACCESS_TYPE: a capacidade de encaminhamento para a Internet pública. Use INTERNAL para endereços IPv6 internos ou EXTERNAL para endereços IPv6 externos. Se --ipv6-access-type não for especificado, o tipo de acesso predefinido é EXTERNAL.
  • NETWORK_NAME: o nome da rede que vai conter a nova sub-rede. Esta rede tem de cumprir as seguintes condições:
    • Tem de ser uma rede VPC no modo personalizado. Para mais informações, veja como mudar uma rede VPC do modo automático para o modo personalizado.
    • Se substituir ACCESS_TYPE por INTERNAL, a rede tem de usar endereços de unicast IPv6 locais únicos (ULA).
  • SUBNET_NAME: o nome da nova sub-rede que escolher.
  • PRIMARY_RANGE: o intervalo de endereços IPv4 principal para a nova sub-rede, na notação CIDR. Para mais informações, consulte o artigo Intervalos de sub-redes.
  • COMPUTE_LOCATION: a localização do Compute Engine para o cluster.

Atualize o tipo de stack

Pode alterar o tipo de pilha de um cluster existente ou atualizar uma sub-rede existente para uma sub-rede de pilha dupla.

Atualize o tipo de pilha num cluster existente

Antes de alterar o tipo de pilha num cluster existente, considere as seguintes limitações:

• A alteração do tipo de pilha é suportada em novos clusters do GKE com a versão 1.25 ou posterior. Os clusters do GKE que foram atualizados das versões 1.24 para as versões 1.25 ou 1.26 podem receber erros de validação quando ativam a rede de pilha dupla.

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

• O GKE respeita os períodos de manutenção configurados quando recria nós. Isto significa que o tipo de pilha do cluster não vai estar operacional no cluster até ocorrer o próximo período de manutenção. Se preferir não esperar, pode atualizar manualmente o conjunto de nós definindo a flag --cluster-version para a mesma versão do GKE que o plano de controlo já está a executar. Tem de usar a CLI gcloud se usar esta solução alternativa. Para mais informações, consulte as restrições para janelas de manutenção.

• A alteração do tipo de pilha não altera automaticamente a família de IPs dos serviços existentes. Aplicam-se as seguintes condições:

  • Se alterar uma única pilha para pilha dupla, os serviços existentes permanecem com uma única pilha.
  • Se alterar uma pilha dupla para uma pilha única, os serviços existentes com endereços IPv6 entram num estado de erro. Elimine o serviço e crie um com o ipFamilies correto. Para saber mais, consulte um exemplo de como configurar uma implementação.

Para atualizar um cluster nativo de VPC existente, pode usar a CLI gcloud ou a Trusted Cloud consola:

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

Atualize uma sub-rede existente para uma sub-rede de pilha dupla (disponível na versão 1.25 ou posterior dos clusters do Autopilot e na versão 1.24 ou posterior dos clusters Standard).

Atualize uma sub-rede existente para uma sub-rede de pilha dupla

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

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

Substitua o seguinte:

• SUBNET_NAME: o nome da sub-rede.
• ACCESS_TYPE: a capacidade de encaminhamento para a Internet pública. Use INTERNAL para endereços IPv6 internos ou EXTERNAL para endereços IPv6 externos. Se --ipv6-access-type não for especificado, o tipo de acesso predefinido é EXTERNAL.
• COMPUTE_REGION: a região de computação do cluster.

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

Depois de criar um cluster nativo da VPC, pode validar os respetivos intervalos de pods e serviços.

gcloud container clusters describe CLUSTER_NAME

Elimine o cluster

Para eliminar o cluster, siga os passos descritos no artigo Eliminar um cluster.

O GKE tenta limpar a sub-rede criada quando o cluster é eliminado. No entanto, se a sub-rede estiver a ser usada por outros recursos, o GKE não elimina a sub-rede, e tem de gerir o ciclo de vida da sub-rede.

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

As secções seguintes mostram como usar intervalos de endereços IP privados não RFC 1918 e como ativar intervalos de endereços IP públicos usados de forma privada.

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

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

Esta funcionalidade não é suportada com pools de nós do Windows Server.

Os intervalos privados não RFC 1918 são intervalos de sub-redes. Pode usá-los exclusivamente ou em conjunto com intervalos de sub-redes RFC 1918. Os nós, os pods e os serviços continuam a usar intervalos de sub-redes, conforme descrito em Intervalos de IP para clusters nativos da VPC. Se usar intervalos não RFC 1918, tenha em atenção o seguinte:

• Os intervalos de sub-redes, mesmo os que usam intervalos não RFC 1918, têm de ser atribuídos manualmente ou pelo GKE antes de os nós do cluster serem criados. Não pode mudar para nem deixar de usar intervalos de sub-redes não RFC 1918 para endereços IP de nós ou de serviços num cluster existente, a menos que substitua o cluster. No entanto, pode adicionar intervalos CIDR de pods adicionais, incluindo intervalos não RFC 1918, a um cluster nativo da VPC existente. Para mais informações sobre como adicionar intervalos CIDR de pods adicionais, consulte o artigo Expanda os intervalos de endereços IP de um cluster do GKE.

• Os balanceadores de carga de rede de encaminhamento interno usam apenas endereços IP do intervalo de endereços IP principal da sub-rede. Para criar um Network Load Balancer de encaminhamento interno com um endereço não RFC 1918, o intervalo de endereços IP primário da sua sub-rede tem de ser não RFC 1918.

Os destinos fora do seu cluster podem ter dificuldades em receber tráfego de intervalos privados não RFC 1918. Por exemplo, os intervalos privados RFC 1112 (classe E) são normalmente usados como endereços de multicast. Se um destino fora do seu cluster não conseguir processar pacotes cujas origens sejam endereços IP privados fora do intervalo RFC 1918, pode fazer o seguinte:

• Use um intervalo RFC 1918 para o intervalo de endereços IP principal da sub-rede. Desta forma, os nós no cluster usam endereços RFC 1918.

• Certifique-se de que o cluster está a executar o agente de ocultação de IP e que os destinos não estão na lista nonMasqueradeCIDRs. Desta forma, os pacotes enviados a partir de pods têm as respetivas origens alteradas (SNAT) para endereços de nós, que são RFC 1918.

Ative os intervalos de endereços IP externos usados de forma privada

Os clusters do GKE podem usar de forma privada determinados intervalos de endereços IP externos como intervalos de endereços IP internos de sub-rede. Pode usar de forma privada qualquer endereço IP externo, exceto determinados intervalos restritos, conforme descrito na documentação da rede VPC. Esta funcionalidade não é suportada com pools de nós do Windows Server.

O seu cluster tem de ser um cluster nativo da VPC para usar intervalos de endereços IP externos usados de forma privada. Os clusters baseados em rotas não são suportados.

Os intervalos externos usados de forma privada são intervalos de sub-rede. Pode usá-las exclusivamente ou em conjunto com outros intervalos de sub-redes que usam endereços privados. Os nós, os pods e os serviços continuam a usar intervalos de sub-redes, conforme descrito em Intervalos de IP para clusters nativos da VPC. Tenha em atenção o seguinte quando reutilizar endereços IP externos de forma privada:

• Quando usa um intervalo de endereços IP externos como um intervalo de sub-rede, o cluster deixa de poder comunicar com sistemas na Internet que usam esse intervalo externo. O intervalo torna-se um intervalo de endereços IP internos na rede VPC do cluster.

• Os intervalos de sub-redes, mesmo os que usam de forma privada intervalos de endereços IP externos, têm de ser atribuídos manualmente ou pelo GKE antes de os nós do cluster serem criados. Não pode mudar para nem deixar de usar intervalos de sub-redes não RFC 1918 para endereços IP de nós ou serviços num cluster existente, a menos que substitua o cluster. No entanto, pode adicionar intervalos de CIDR de pods adicionais, incluindo intervalos não RFC 1918, a um cluster nativo da VPC existente. Para mais informações sobre como adicionar intervalos CIDR de pods adicionais, consulte o artigo Expanda os intervalos de endereços IP de um cluster do GKE.

Por predefinição, o GKE implementa o SNAT nos nós para destinos de IP externos. Se configurou o CIDR do pod para usar endereços IP externos, as regras de SNAT aplicam-se ao tráfego de pod para pod. Para evitar esta situação, tem 2 opções:

• Crie o cluster com a flag --disable-default-snat. Para mais detalhes acerca desta flag, consulte o artigo Ocultação de IP no GKE.
• Configure o configMap ip-masq-agent incluindo na lista nonMasqueradeCIDRs, pelo menos, o CIDR do pod, o CIDR do serviço e a sub-rede dos nós.

Para clusters padrão, se a versão do cluster for 1.14 ou posterior, ambas as opções funcionam. Se a versão do cluster for anterior à 1.14, só pode usar a segunda opção (configurar ip-masq-agent).

O que se segue?

• Leia a vista geral da rede do GKE.
• Saiba mais sobre o balanceamento de carga interno.
• Saiba mais sobre a configuração de redes autorizadas.
• Saiba como criar políticas de rede de clusters.