Clusters nativos de VPC

Esta página oferece uma vista geral dos clusters nativos da VPC no Google Kubernetes Engine (GKE).

Esta página destina-se a arquitetos da nuvem e especialistas em redes que concebem e arquitetam a rede para a respetiva organização. Para saber mais acerca das funções comuns e das tarefas de exemplo que referimos no Trusted Cloud by S3NS conteúdo, consulte o artigo Funções e tarefas comuns de utilizadores do GKE.

Vista geral

No GKE, os clusters podem ser distinguidos de acordo com a forma como encaminham o tráfego de um pod para outro.

Um cluster que usa intervalos de endereços IP de alias é denominado cluster nativo da VPC. Um cluster que usa rotas estáticas personalizadas numa rede VPC é denominado cluster baseado em rotas.

Vantagens dos clusters nativos de VPC

Os clusters nativos de VPC têm várias vantagens:

• Os endereços IP dos pods são encaminháveis nativamente na rede VPC do cluster e noutras redes VPC ligadas a esta através do intercâmbio da rede VPC.

• Os endereços IP dos pods são reservados na rede VPC antes de os pods serem criados no seu cluster. Isto evita conflitos com outros recursos na rede VPC e permite-lhe planear melhor as atribuições de endereços IP.

• Os intervalos de endereços IP dos pods não dependem de rotas estáticas personalizadas. Não consomem a quota de rotas estáticas personalizadas e geradas pelo sistema. Em alternativa, as rotas de sub-rede geradas automaticamente processam o encaminhamento para clusters nativos da VPC.

• Pode criar regras de firewall que se aplicam apenas a intervalos de endereços IP de pods, em vez de a qualquer endereço IP nos nós do cluster.

• Os intervalos de endereços IP de pods e os intervalos de endereços IP secundários de sub-redes em geral são acessíveis a partir de redes no local ligadas ao Cloud VPN ou ao Cloud Interconnect através de routers na nuvem.

• Algumas funcionalidades, como os grupos de pontos finais da rede (NEGs), só funcionam com clusters nativos da VPC.

Modo de rede de cluster predefinido

O modo de rede nativo de VPC é o modo predefinido para todos os clusters nas versões 1.21.0-gke.1500 e posteriores do GKE. Para versões anteriores, o modo de rede do cluster predefinido depende da forma como cria o cluster.

A tabela seguinte lista o modo de rede de cluster predefinido para as versões de cluster do GKE e os métodos de criação de clusters.

Também pode criar um cluster baseado em rotas especificando a flag --no-enable-ip-alias quando cria o cluster.

Intervalos de endereços IP para clusters nativos de VPC

Quando cria um cluster nativo de VPC, especifica uma sub-rede numa rede de VPC. O cluster usa os seguintes intervalos de endereços IP de sub-rede:

Atribuição de endereços IPv4

Os clusters nativos da VPC atribuem endereços IPv4 para nós, pods e serviços usando intervalos distintos na sub-rede especificada, da seguinte forma.

• Endereços IP dos nós: o cluster usa o intervalo de endereços IPv4 principal da sub-rede para atribuir endereços IP a todos os nós.

• Endereços IP de pods: o cluster usa o intervalo de endereços IPv4 secundário na sub-rede para todos os endereços IPv4 de pods no cluster. Para maior flexibilidade, pode usar intervalos de endereços IPv4 secundários de sub-rede adicionais configurando o CIDR multidisjunto de vários pods.

• Endereços IP de serviço: o cluster usa um intervalo de endereços IP secundário separado para todos os endereços de serviço (IP do cluster). Para obter informações sobre como ativar vários clusters para partilharem o mesmo intervalo IPv4 de serviços, consulte o artigo Partilhar intervalos de endereços IP entre clusters do GKE.

Atribuição de endereços IPv6 (redes de pilha dupla)

• Endereços IPv6 de nós e pods: em clusters ativados para redes de pilha dupla, o endereço IPv6 do nó e todos os endereços IPv6 de pods têm origem no intervalo de endereços IPv6 /96 designado do nó. O endereço IP do nó é o primeiro /128 (endereço IPv6 único) dentro deste intervalo. Para mais informações, consulte o artigo sobre redes de pilha dupla.

A tabela seguinte apresenta um resumo dos intervalos de endereços IP para nós, pods e serviços:

Endereços IP internos

Os endereços IP que usa para as sub-redes do cluster nativo da VPC têm de ser provenientes de um intervalo de sub-redes válido. Os intervalos válidos incluem endereços IP privados (RFC 1918 e outros) e endereços IP públicos usados de forma privada. Consulte os Intervalos válidos e os Intervalos restritos na documentação da VPC para mais informações sobre intervalos de sub-redes válidos.

Consulte o artigo Usar intervalos de endereços IP privados não RFC 1918 para obter instruções sobre como ativar a utilização destes intervalos.

Consulte o artigo Ative intervalos de endereços IP públicos usados de forma privada para obter instruções sobre a utilização destes intervalos.

Métodos de atribuição de intervalos secundários

Pode atribuir intervalos de endereços IP de pods e intervalos de endereços de serviços (ClusterIP) a um cluster nativo da VPC. Estes intervalos de endereços IP podem ser geridos pelo GKE ou pelo utilizador.

Tem de compreender os seguintes termos principais para compreender os métodos de atribuição de intervalo secundário.

Atribuição: a atribuição de intervalos de endereços IP refere-se ao processo de atribuição de um intervalo de sub-rede específico a um cluster nativo da VPC. Isto estabelece um conjunto de endereços IP que os componentes podem usar no cluster, como pods e serviços.

Gestão: a gestão do intervalo de endereços IP refere-se às operações CRUD (criação, atualização, eliminação e leitura) contínuas ao nível do cluster, do conjunto de nós ou do pod, relacionadas com os intervalos de sub-redes atribuídos e a atribuição de recursos no seu cluster nativo da VPC.

Intervalos secundários geridos pelo GKE (predefinição)

Para clusters do GKE Autopilot com a versão 1.27 e posteriores e clusters do GKE Standard com as versões 1.29 e posteriores, o GKE atribui endereços IP para serviços a partir de um intervalo gerido pelo GKE por predefinição: 34.118.224.0/20. Isto elimina a necessidade de especificar o seu próprio intervalo de endereços IP para os serviços. Aplicam-se as seguintes considerações:

• Opcionalmente, pode especificar intervalos personalizados para serviços através da flag --services-ipv4-cidr.
• Se especificar apenas um tamanho usando a flag --services-ipv4-cidr (por exemplo, /22), o GKE continua a usar o intervalo gerido pelo GKE para obter o subintervalo de endereços.
• O GKE não cria um intervalo de endereços IP secundário separado para os serviços quando é usado o intervalo gerido pelo GKE.

Gerido pelo utilizador

Para ter controlo total sobre a atribuição de endereços IP, pode gerir manualmente as sub-redes do cluster nativo da VPC.

Pode criar os intervalos de endereços IP secundários da sub-rede e, em seguida, criar um cluster que use esses intervalos. Durante a criação do cluster, especifique o nome do intervalo da sub-rede para pods e serviços. Se criar manualmente os intervalos secundários, tem de os gerir.

O intervalo de endereços IP mais pequeno que pode criar sem usar o CIDR de vários pods descontínuos é /28, mas esse intervalo só lhe permitiria criar 1 nó com um máximo de 8 pods. Deve usar um intervalo suficientemente grande para o número máximo de nós de que precisa.

O intervalo utilizável mínimo também depende do número máximo de pods por nó.

Consulte a tabela em Otimizar a atribuição de endereços IP para o intervalo CIDR mínimo utilizável para diferentes valores de agrupamentos máximos por nó.

Se esgotar o intervalo de endereços IP para pods, tem de fazer uma das seguintes ações:

• Crie um novo cluster com um intervalo de endereços de pods maior.
• Recrie os node pools depois de diminuir o --max-pods-per-node para os node pools.
• Expanda o intervalo de endereços IP do pod secundário através do CIDR de vários pods descontínuos.

Diferenças com clusters baseados em rotas

O esquema de atribuição de endereços de pods e serviços (ClusterIP) é diferente do esquema usado por um cluster baseado em rotas. Em vez de especificar um único CIDR para os pods e os serviços em conjunto, tem de escolher ou criar dois intervalos de endereços IP secundários na sub-rede do cluster: um para os pods e outro para os serviços.

Considerações sobre a VPC partilhada

Quando cria um cluster nativo da VPC num ambiente de VPC partilhada, um proprietário, um editor ou um principal de gestão de identidades e acessos (IAM) do projeto com a função de administrador de rede no projeto anfitrião da VPC partilhada tem de criar manualmente a sub-rede e os intervalos de endereços IP secundários do cluster. Um administrador do projeto de serviço que cria um cluster tem de ter, pelo menos, autorizações ao nível da sub-rede para a sub-rede no projeto anfitrião da rede de VPC partilhada.

Num ambiente de VPC partilhada, os intervalos de endereços IP secundários não podem ser geridos pelo GKE. Um administrador de rede no projeto anfitrião da VPC partilhada tem de criar a sub-rede e os intervalos de endereços IP secundários antes de poder criar o cluster. Para ver um exemplo que mostra como configurar um cluster nativo de VPC numa rede de VPC partilhada, consulte o artigo Configurar clusters com a VPC partilhada.

Planeamento do intervalo de endereços IP

Use as informações nas secções seguintes para ajudar a calcular os tamanhos dos intervalos de endereços IP primários e secundários da sub-rede usada pelo cluster.

Intervalo de endereços IP principal da sub-rede

Considere as seguintes condições ao planear o intervalo de endereços IP do nó principal:

• Todas as sub-redes têm de ter um intervalo de endereços IP principal. Este é o intervalo de endereços IP que o GKE usa para atribuir endereços IP a balanceadores de carga internos e nós.

• Depois de criar uma sub-rede, pode expandir o respetivo intervalo de endereços IP principal, mas não o pode reduzir. Se expandir uma sub-rede usada por um cluster com redes autorizadas, tem de adicionar o intervalo de endereços IP expandido à lista de redes autorizadas do plano de controlo. Antes de expandir um intervalo, certifique-se de que revê as limitações e as recomendações em Expanda um intervalo IPv4 principal.

• Os dois primeiros e os dois últimos endereços IP de um intervalo de endereços IP principal são reservados pela Trusted Cloud.

• Os clusters com o Private Service Connect usam o intervalo de sub-rede principal para aprovisionar o endereço IP interno atribuído ao ponto final do plano de controlo. No entanto, pode substituir este aprovisionamento de endereços IP com a flag private-endpoint-subnetwork. Para saber mais, consulte o artigo Crie um cluster e selecione o intervalo de endereços IP do plano de controlo.

A tabela seguinte mostra o número máximo de nós que pode criar, tendo em conta o tamanho do intervalo de endereços IP principal da sub-rede e a configuração do cluster:

• Cenário 1: número máximo de nós num cluster que usa a sub-rede predefinida.
• Cenário 2: número máximo de nós num cluster do Private Service Connect que não usa a flag private-endpoint-subnetwork.

Expanda o intervalo de endereços IP principal

Se ficar sem endereços IP no intervalo de endereços IP principal, pode expandir o intervalo de endereços IP principal em qualquer altura, mesmo quando os Trusted Cloud recursos, como equilibradores de carga e grupos de pontos finais de rede, usam a sub-rede.

Antes de expandir o intervalo de endereços IP principal, considere o seguinte:

• Não pode haver intervalos de endereços IP sobrepostos na sub-rede.
• O GKE usa o intervalo de endereços IP principal para atribuir endereços IP para balanceadores de carga internos e nós.

Fórmulas úteis

Pode usar as seguintes fórmulas para:

• Calcule o número máximo de nós, N, que uma determinada máscara de rede pode suportar em clusters que usam a sub-rede predefinida. Use S para o tamanho da máscara de rede, cujo intervalo válido está entre 8 e 29, inclusive.

  N = 2^{(32 -S)} - 4

• Calcule o tamanho da máscara de rede, S, necessária para suportar um máximo de N nós:

  S = 32 - ⌈log₂(N + 4)⌉

  ⌈⌉ é a função de arredondamento para cima (menor número inteiro), o que significa arredondar para o número inteiro seguinte. O intervalo válido para o tamanho da máscara de rede, S, está entre 8 e 29, inclusive.

Nos clusters do Private Service Connect que não usam a flag private-endpoint-subnetwork, pode usar as fórmulas anteriores, mas reduzir o valor de N em 1.

Intervalo de endereços IP secundários da sub-rede para pods

Planeie cuidadosamente o intervalo de endereços IP secundários para os pods.

A tabela seguinte mostra o número máximo de nós e agrupamentos que pode criar em todos os clusters que usam a sub-rede, tendo em conta a dimensão do intervalo de endereços IP secundários da sub-rede usado pelos agrupamentos.

Esta tabela pressupõe que o número máximo de agrupamentos por nó é 110, que é a densidade de agrupamentos predefinida.

Se alterou o número máximo de agrupamentos por nó, pode usar as seguintes fórmulas para calcular o número máximo de nós e agrupamentos que um intervalo de endereços IP secundários de uma sub-rede para agrupamentos pode suportar:

1. Calcule o tamanho da máscara de rede do intervalo de agrupamentos de cada nó, M.
   M = 31 - ⌈log2(Q)⌉ onde:

   • Q é o número de agrupamentos por nó
   • ⌈⌉ é a função de limite superior (menor número inteiro), o que significa arredondar para o número inteiro seguinte
   • Por exemplo, se Q for 110, então M = 24

2. Calcule o número máximo de nós, N, que o intervalo de endereços IP secundários da sub-rede para pods pode suportar:
   N = 2(M - S) onde:

   • M é o tamanho da máscara de rede do intervalo de endereços IP do alias de cada nó para pods, calculado no primeiro passo
   • S é o tamanho da máscara de sub-rede do intervalo de endereços IP secundários da sub-rede
   • Por exemplo, se M for 24 e S for 20, então N = 16

3. Calcule o número máximo de pods, P, que o intervalo de endereços IP secundários da sub-rede para pods pode suportar:
   P = N × Q onde:

   • N é o número máximo de nós, calculado no passo anterior
   • Q é o número de agrupamentos por nó
   • Por exemplo, se N for 16 e Q for 110, então P = 1760

Pode adicionar mais endereços IP para pods através do CIDR de vários pods não contíguos.

Intervalo de endereços IP secundários da sub-rede para serviços

Planeie cuidadosamente o intervalo de endereços IP secundários para serviços. Uma vez que também é um intervalo de endereços IP secundários da sub-rede, este intervalo não pode ser alterado depois de o cluster ser criado.

Se usar serviços de vários clusters, o objeto ServiceImport usa endereços IP do intervalo de endereços IP secundários para serviços.

Nos clusters do GKE Autopilot com a versão 1.27 e posteriores e nos clusters do GKE Standard com as versões 1.29 e posteriores, o GKE atribui endereços IP para serviços a partir de um intervalo gerido pelo GKE por predefinição: 34.118.224.0/20. Isto elimina a necessidade de especificar o seu próprio intervalo de endereços IP para os serviços. Aplicam-se as seguintes considerações:

• Opcionalmente, pode especificar intervalos personalizados para serviços através da flag --services-ipv4-cidr ou da flag --services-secondary-range-name.
• Se especificar apenas um tamanho de intervalo através da flag --services-ipv4-cidr (por exemplo, /22), o GKE continua a usar o intervalo gerido pelo GKE para obter o subintervalo de endereços.
• O GKE não cria um intervalo de endereços IP secundário separado para os serviços quando é usado o intervalo gerido pela Google. O intervalo gerido pelo GKE não usa a quota do intervalo de endereços IP secundários para a sua sub-rede.

A tabela seguinte mostra o número máximo de serviços que pode criar num único cluster usando a sub-rede, dado o tamanho do intervalo de endereços IP secundários da sub-rede para serviços.

Partilhar intervalos de endereços IP entre clusters do GKE

Pode partilhar o intervalo principal, o intervalo de endereços IP secundários para pods e o intervalo de endereços IP secundários para serviços entre clusters na mesma sub-rede. Este comportamento está disponível para clusters padrão e do Autopilot.

É aconselhável partilhar intervalos de endereços IP se tiver uma equipa centralizada que esteja a gerir a infraestrutura para clusters. Pode reduzir as despesas gerais criando três intervalos para pods, serviços e nós, e reutilizando-os ou partilhando-os, especialmente num modelo de VPC partilhada. Também pode facilitar a gestão de endereços IP por parte dos administradores de rede, uma vez que não precisam de criar sub-redes específicas para cada cluster.

Partilhar o intervalo de sub-rede personalizado para o plano de controlo

Por predefinição, o GKE usa o intervalo de sub-rede principal para aprovisionar o ponto final interno do plano de controlo. No entanto, em clusters com o Private Service Connect, pode configurar o GKE para aprovisionar o ponto final interno a partir de uma sub-rede diferente que criou. Pode partilhar esta sub-rede entre outros clusters ou em projetos se estiver a usar a VPC partilhada.

Partilhar o intervalo de endereços IP principal para nós

Se criar mais do que um cluster na sub-rede, o intervalo de endereços IP principal para os nós é partilhado por predefinição.

A partilha do endereço IP principal para nós tem as seguintes limitações:

• Se partilhar o intervalo de endereços IP principal para nós com dois ou mais clusters nativos da VPC, um cluster pode usar uma grande parte do intervalo de endereços IP partilhado, deixando os outros clusters sem endereços IP suficientes para expansão.

Partilhar o intervalo de endereços IP secundários para pods

Quando partilha o intervalo secundário para os Pods, cada Pod continua a receber um endereço IP único.

A partilha do intervalo de endereços IP secundários para os Pods tem as seguintes limitações:

• Se partilhar o intervalo de endereços IP secundários para agrupamentos com dois ou mais clusters nativos da VPC, um cluster pode usar uma grande parte do intervalo de endereços IP partilhado, deixando os outros clusters sem endereços IP suficientes para expansão.

• Entre os diferentes tipos de intervalos secundários, os intervalos de pods adicionais e os intervalos de pods adicionais não são partilháveis entre clusters.

• Para partilhar um intervalo de endereços IP secundário, transmita-o na linha de comandos com --cluster-secondary-range. Não pode usar um intervalo secundário partilhado quando cria clusters na IU.

Partilhar o intervalo de endereços IP secundários para serviços

Dois ou mais clusters podem usar simultaneamente o mesmo intervalo de endereços IPv4 secundários para serviços quando usa intervalos secundários geridos pelo utilizador.

Para configurar dois ou mais clusters para partilharem um intervalo de endereços IPv4 secundários de sub-rede comum para serviços, use o mesmo intervalo de endereços IPv4 secundários de sub-rede quando criar cada cluster. Não é necessária uma flag de configuração separada para partilhar um intervalo de endereços IPv4 comum para os serviços.

Quando partilham um intervalo de endereços IPv4 comum para serviços, cada cluster usa o intervalo de endereços IPv4 secundário de toda a sub-rede para serviços internamente. Os endereços IP dos serviços são programados no nó de cada cluster, mas não são atribuídos à interface de rede de nenhum nó. Os endereços IP de serviço não são encaminháveis na rede VPC do cluster. Os endereços IP de serviço só são utilizáveis por pods de cliente no mesmo cluster que o serviço.

Quando um pod envia um pacote para um endereço IP de serviço, a configuração do iptables ou eBPF no nó executa a tradução de endereços de rede (NAT) de destino, alterando o endereço IP de destino do pacote do endereço IP de serviço para um endereço IP de pod de serviço. O pacote é encaminhado com base no endereço IP do pod de destino.

A partilha do intervalo de endereços IP secundário para serviços oferece as seguintes vantagens:

• Reduza o número de intervalos de endereços IP secundários únicos para serviços criados numa sub-rede
• Use menos endereços IP

A partilha do intervalo de endereços IP secundários para serviços tem as seguintes limitações:

• A partilha do intervalo de endereços IP secundários para serviços não é suportada com o Cloud DNS ao nível da VPC para o GKE.

• Não pode partilhar intervalos que correspondam à seguinte regex:

  ^gke-.*-services-[abcdef0-9]{8}
  

• Para partilhar um intervalo de endereços IP secundário para serviços, transmita-o na linha de comandos. --cluster-secondary-range Não pode usar um intervalo secundário partilhado para serviços quando cria clusters na IU.

Intervalos de limitação de nós

O número máximo de pods e serviços para um determinado cluster do GKE é limitado pelo tamanho dos intervalos secundários do cluster. O número máximo de nós no cluster é limitado pelo tamanho do intervalo de endereços IP principal da sub-rede do cluster e pelo intervalo de endereços do pod do cluster.

A seguinte mensagem de erro indica que o intervalo de endereços IP principal da sub-rede ou o intervalo de endereços IP dos pods do cluster (o intervalo de endereços IP secundário da sub-rede para pods) foi esgotado:

Instance [node name] creation failed: IP space of [cluster subnet] is
exhausted

Pode adicionar mais endereços IP para nós ao expandir a sub-rede principal ou adicionar novos endereços IP para pods através do CIDR de vários pods descontinuados. Para mais informações, consulte o artigo Não existe espaço de endereço IP livre suficiente para os pods.

Redes de pilha dupla IPv4/IPv6

Com a rede de pilha dupla IPv4/IPv6, pode definir como o GKE atribui endereços IP (ipFamilies) aos seguintes objetos:

• Para pods e nós, o GKE atribui endereços IPv4 e IPv6.
• Para os serviços, o GKE atribui endereços de pilha única (apenas IPv4 ou apenas IPv6) ou de pilha dupla.

Na versão 1.24 ou posterior do GKE, pode ativar a rede de pilha dupla para novos clusters do GKE em redes VPC autónomas e partilhadas. Também pode aplicar políticas de rede com a rede de pilha dupla ativada.

Vantagens

As redes de pilha dupla oferecem as seguintes vantagens:

• Ativa a comunicação IPv6 ponto a ponto.
• Permite um melhor desempenho em comparação com a tradução de endereços de rede (NAT) ou o túnel de IP. Isto é conseguido porque não existe tradução de IPv6 para IPv4.

Disponibilidade

A rede de pilha dupla com o GKE tem as seguintes restrições:

• As redes de pilha dupla só estão disponíveis para clusters nativos da VPC com o GKE Dataplane V2 ativado.
• As redes de pilha dupla só são suportadas em sub-redes em VPCs de modo personalizado. Para mais informações, consulte os Trusted Cloud tipos de redes VPC.
• Os endereços IPv6 de pilha única para agrupamentos ou nós não são suportados.
• Os clusters de pilha dupla consomem memória adicional por nó para suportar IPv4 e IPv6 em comparação com clusters apenas IPv4. Considere esta caraterística quando configurar clusters de grande escala.
• Os clusters de pilha dupla não suportam o acesso privado à Google através de IPv6.
• As versões 1.26.0-gke.2200 e posteriores do GKE suportam IPv6 (registos AAAA) com o Cloud DNS para operações internas do cluster e consultas DNS externas.
• Os serviços de pilha dupla são suportados para os serviços ClusterIP, NodePort e LoadBalancer.
• O IPv6 não é suportado para nós do Windows.

Considere as restrições anteriores antes de criar um cluster com rede de pilha dupla. Para mais informações, saiba como criar um cluster nativo da VPC com rede de pilha dupla.

Atribuição de endereços IPv6 públicos e privados

A tabela seguinte apresenta um resumo dos endereços IPv6 públicos e privados com o comportamento e as configurações de rede de pilha dupla:

Para saber mais, veja como usar uma rede de pilha dupla para um cluster nativo da VPC.

Arquitetura

Um cluster com redes de pilha dupla IPv4/IPv6 tem os seguintes intervalos atribuídos:

• Um intervalo /64 para cada sub-rede como um intervalo principal.
• Um intervalo /96 por nó do intervalo principal a usar como intervalo de endereços IP do nó principal.

• Um intervalo /112 por nó do intervalo de endereços IP do nó principal a usar como um intervalo de endereços IP do pod para esse nó. Com a rede de pilha dupla, os pods recebem os respetivos endereços IPv6 do intervalo de endereços IP de pods geral (semelhante aos nós) e não do intervalo secundário para pods reservado a endereços IPv4.

  O intervalo de endereços IP do grupo geral é composto por intervalos não sobrepostos do intervalo de IP do nó principal. Como tal, este intervalo de IPs do pod é descontinuado.

• Um intervalo /112 para usar nos serviços. Este intervalo provém de um intervalo /64 do intervalo de endereços privados da Google que foi reservado para o intervalo de endereços IP de serviços secundários do GKE.

O diagrama seguinte mostra como o Trusted Cloud e o GKE atribuem endereços IPv6:

No diagrama, o intervalo principal da sub-rede da VPC é 2600:1900:0:1::/64 e o intervalo reservado para os serviços do GKE é 2600:2D00:0:4::0:0/64. Cada nó no cluster tem um intervalo /96 para o intervalo de endereços IP do nó principal e um intervalo /112 para o intervalo de endereços IP do pod. O cluster também tem um intervalo de endereços IP de serviços secundários /112.

Serviços

Pode criar um serviço de pilha dupla IPv4/IPv6 do tipo ClusterIP ou NodePort. Os novos clusters do GKE com a versão 1.29 ou posterior suportam serviços de pilha dupla do tipo LoadBalancer.

Pode expor uma implementação com um serviço do tipo ClusterIP, NodePort ou LoadBalancer. Para cada um destes tipos de serviço, pode definir os campos ipFamilies e ipFamilyPolicy como IPv4, IPv6 ou um serviço de duplo stack. Para mais informações, consulte um exemplo de como configurar uma implementação.

O que se segue?

• Saiba mais acerca do intercâmbio da rede da VPC.
• Saiba como criar um cluster nativo da VPC.
• Saiba mais sobre as estatísticas de utilização de endereços IP do GKE.