Este documento faz parte de uma série destinada a arquitetos de rede. A série discute as opções de gerenciamento de endereços do Google Kubernetes Engine (GKE) disponíveis para organizações restritas a endereços IPv4.
A série consiste nas partes a seguir:
- Introdução e visão geral
- Otimização de endereços IPv4 (este documento)
- Conversão de endereços de rede (NAT, na sigla em inglês) para um bloco de CIDR de Pod de GKE
- Como configurar NAT para um bloco de CIDR de Pod de GKE
- NAT para todos os blocos de CIDR do GKE
- Como configurar NAT para todos os blocos de CIDR do GKE
- Como configurar ULOGD2 e Cloud SQL para geração de registros NAT
- Como configurar IPs públicos de uso privado para o GKE
Neste documento, descrevemos um processo para identificar os requisitos do bloco CIDR do GKE. Em seguida, apresentamos um modelo de decisão que ajuda a identificar qual solução é recomendada para cada cenário em particular. Por fim, abordamos as várias soluções, com uma breve descrição delas, e listamos as vantagens e desvantagens.
Como identificar requisitos do bloco CIDR do GKE
Nesta seção, você determina os tamanhos dos blocos CIDR para seu cluster. É muito importante que você faça isso corretamente, porque não será possível alterar ou ampliar um bloco CIDR depois de ter criado o cluster.
Como determinar o tamanho do bloco CIDR do nó
Siga estas etapas para determinar o tamanho do bloco CIDR do nó:
Determine o número máximo de nós necessários no cluster durante todo o ciclo de vida dele.
Se for possível determinar esse número, que depende do aplicativo do cliente, do design e de previsões de crescimento, use-o como o número obrigatório de nós. Se não for possível determinar o número máximo de nós necessários, use o limite de cota de 5.000 nós como o máximo.
Determine os bits de host necessários para serem considerados no número obrigatório de nós.
Quando você sabe a contagem obrigatória de nós, é possível usar a tabela 1 para calcular os bits de host necessários para gerar uma máscara de rede. Encontre o número obrigatório de nós na coluna Nós obrigatórios. Para a próxima etapa, use o número correspondente na coluna Bits de host para nós.
Nós obrigatórios Bits de host para nós 1-4 3 5-12 4 13–28 5 29–60 6 61–124 7 125–252 8 253–508 9 509–1020 10 1021–2044 11 2045–4092 12 4093–8188 13 Tabela 1. Bits necessários para endereços de nós.
Gere uma máscara de rede de bloco CIDR usando o número da coluna Bits de host para nós determinada na etapa anterior:
32 – bits de host para nós = Máscara de rede de bloco CIDR do nó
A figura a seguir mostra esta equação graficamente.
Por exemplo, para um cluster de 5.000 nós, a tabela 1 mostra que 13 bits de host para nós são obrigatórios na máscara de rede do nó. Para calcular toda a máscara de rede, substitua o número de bits de host para nós na equação, 32 – 13 = 19. O resultado é uma máscara de rede de
/19
.
Como determinar o tamanho do bloco de CIDR de pod
Siga estas etapas para determinar o tamanho do bloco CIDR do pod:
Determine o número máximo de pods por nó necessários no cluster durante todo o ciclo de vida dele.
Se for possível determinar esse número, que depende do aplicativo, use-o como o número obrigatório de pods por nó. Se não for possível determinar o número máximo necessário, use o limite de cota de 110 pods por nó como o máximo.
Determine os bits de host necessários para o número obrigatório de nós.
Quando você sabe a contagem de pods obrigatórios por nó, é possível usar a tabela 2 a fim de calcular os bits de host necessários para gerar uma máscara de rede. Encontre o número de pods necessários por nó na coluna Contagem de pods por nó. Use o número correspondente na coluna Bits de host por pods para a próxima etapa.
Contagem de pods por nó Bits de host por pods 1–8 4 9–16 5 17–32 6 33–64 7 65–110 8 Tabela 2. Bits necessários para pods por nó.
Gere uma máscara de rede de bloco CIDR, usando o número de bits de host para nós que você determinou na etapa dois da seção Como determinar o tamanho do bloco CIDR do nó e o número de bits de host por pods que você determinou na etapa anterior:
32 - (bits de host para nós + bits de host por pods) = Máscara de rede de bloco CIDR do pod
A figura a seguir mostra esta equação graficamente.
Por exemplo, se você precisar de 110 pods por nó, precisará de 8 bits de host para os pods por nó. Em seguida, pegue os bits de host para os nós (13) e substitua esses números na equação, 32 - (13 + 8) = 11. O resultado é uma máscara de rede de
/11
.
Como determinar o tamanho do bloco CIDR do IP do cluster
Siga estas etapas para determinar o tamanho do bloco CIDR do endereço IP do cluster:
Determine o número máximo de endereços IP do cluster que você precisa no cluster durante todo o ciclo de vida dele.
Se for possível determinar esse número, que depende do aplicativo, use-o como o número obrigatório de endereços IP do cluster. Se não for possível determinar o número máximo necessário, use a máscara de rede
/20
padrão. Se você usar a máscara de rede padrão, poderá pular a etapa seguinte.Determine a máscara de rede de bloco CIDR do endereço IP do cluster.
Quando souber o número máximo de endereços IP do cluster necessários, será possível usar a tabela 3 para encontrar a máscara de rede.
Número de endereços IP do cluster Máscara de rede 1–32 /27
33–64 /26
65–128 /25
129–256 /24
257–512 /23
513–1.024 /22
1.025–2.048 /21
2.049–4.096 /20
4.097–8.192 /19
8.193–16.384 /18
16.385–32.768 /17
32.769–65.536 /16
Tabela 3. Máscara de rede do bloco de CIDR dos serviços.
Noções básicas sobre a demanda de endereços
Ao analisar os requisitos de bloco CIDR derivados das etapas anteriores, observe que o bloco CIDR do pod coloca a maior demanda para o espaço do endereço IP. Na maioria das vezes, o CIDR do nó coloca a segunda maior demanda, seguida pelo bloco CIDR de serviços.
Agora que você calculou os requisitos de endereço IP do cluster, é necessário analisar o espaço do endereço IP RFC 1918 disponível e selecionar um caminho a ser seguido.
Como selecionar a melhor solução
A figura 1 mostra uma árvore de decisão que pode ser usada para determinar a melhor solução de acordo com seus requisitos de bloco CIDR. Na seção Como analisar as soluções, resumimos cada solução.
Como analisar as soluções
Nesta seção, descrevemos cada solução e quando usá-la e resumimos todas as vantagens, desvantagens e outros problemas.
Como atribuir espaço de endereço disponível
Quando usar:
- Depois de revisar o espaço de endereço IP disponível e analisar a figura 1,
você determinou que há espaço de endereço RFC 1918 disponível suficiente para
alocar aos blocos CIDR do cluster. Por exemplo, o endereço
10.0.0.0/8
pode estar esgotado, mas há espaço suficiente de endereço172.16.0.0/12
ou192.168.0.0/16
para atender aos requisitos de bloco CIDR.
Descrição:
- Nenhuma outra etapa de configuração especial é necessária para esta solução. Aloque o espaço de endereço e continue com a instalação.
Vantagens:
- A mais fácil de todas as soluções.
- Não requer configuração especial.
Desvantagens:
- Exclui o espaço de endereços IP disponível.
Outros problemas:
- Para garantir que você está otimizando as alocações de endereço IP, use o recurso CIDR do pod flexível.
Como converter o bloco CIDR do pod do GKE
Quando usar:
- Depois de revisar o espaço de endereço IP disponível e analisar a figura 1, você determinou que há espaço de endereço RFC 1918 disponível suficiente para alocar ao bloco do nó, mas não há espaço suficiente para o bloco CIDR do pod. Portanto, é preciso converter os blocos CIDR do pod, e possivelmente do serviço.
Descrição:
Para converter os blocos CIDR do pod em um cluster do GKE, implemente o recurso
ip-masquerade-agent
, como mostrado na figura 2. Esse recurso oculta os endereços IP do pod atrás dos endereços IP do nó. Com esse design, também é possível reutilizar blocos CIDR para o bloco CIDR de serviço.Figura 2. NAT para um bloco CIDR do pod em um cluster do GKE. Para uma versão em PDF legível na tela, clique na imagem. Essa arquitetura tem vários componentes:
- Nova terminologia para descrever as características do bloco CIDR em relação ao NAT.
- O recurso
ip-masquerade-agent
. - Reutilização de blocos CIDR RFC 1918.
- Filtragem na conexão local.
Vantagens:
- Alivia roadblocks de alocação de endereços IPv4 para o CIDR de pod.
- Escalona para o maior bloco de CIDR de pod compatível.
- Isola os blocos de CIDR RFC 1918 reutilizados da tabela de roteamento global.
- Faz com que as malhas do Istio de vários clusters ainda sejam possíveis.
- Torna as configurações do grupo de endpoints da rede ainda possíveis.
Desvantagens:
- O NAT introduz novos problemas, como o tethering de endereços e a geração de registros, que você precisa solucionar.
- Nem todos os recursos na VPC podem se comunicar com os recursos locais que receberam o mesmo intervalo CIDR que o pod. Esse problema também existirá para recursos locais que compartilham o bloco CIDR de serviço, se o intervalo de serviço for reutilizado. O problema é que os blocos CIDR reutilizados aparecem como rotas locais para a VPC e, portanto, nunca são roteados para fora dela.
Outros problemas:
- Tenha cuidado ao selecionar os blocos CIDR RFC 1918 que serão reutilizados para os blocos CIDR do GKE.
- Não anuncie os blocos CIDR RFC 1918 reutilizados na rede local.
- Como os blocos CIDR reutilizados estão na tabela de roteamento da VPC, tome cuidado ao usar o peering de VPC ou conexões VPN.
Como converter todos os blocos CIDR do GKE
Quando usar:
- Depois de revisar o espaço de endereço IP disponível e analisar a figura 1, você determinou que não há espaço de endereço RFC 1918 suficiente disponível para alocação aos blocos CIDR do pod ou do nó do cluster. Portanto, é preciso converter todos os blocos CIDR.
Descrição:
Para converter todos os blocos CIDR em um cluster do GKE, implemente a arquitetura mostrada na figura 3.
Figura 3. NAT para todos os blocos CIDR em um cluster do GKE. Para uma versão em PDF legível na tela, clique na imagem. Essa arquitetura tem vários componentes:
- Nova terminologia para descrever as características do bloco CIDR em relação ao NAT.
- Reutilização de blocos CIDR RFC 1918.
- Uma VPC host que tem uma rede compartilhada.
- Uma VPC de serviço que chamou a VPC isolada que contém o cluster do GKE.
- Uma instância do Compute Engine chamou o gateway da VPC isolada que executa o NAT e tem uma interface de rede em ambas as VPCs isolada e host.
- O conceito de um bloco CIDR do balanceador de carga interno.
- Rotas estáticas nas duas VPCs que direcionam o tráfego adequadamente.
- Filtragem na conexão local.
Vantagens:
- Alivia roadblocks de alocação de endereços IPv4.
- Escalona para o maior cluster compatível.
- Permite a replicação de cookie-cutter para vários clusters.
- Oferece o melhor isolamento dos blocos CIDR RFC 1918 reutilizados da tabela de roteamento global.
- Torna as configurações de grupo de endpoints de rede ainda possíveis.
Desvantagens:
- Apresenta mais complexidade do que as soluções anteriores.
- O NAT introduz novos problemas, como o tethering de endereços e a geração de registros, que você precisa solucionar.
- Malhas de multicluster Istio não são possíveis em algumas implantações.
Outros problemas:
- Cuidado ao selecionar os blocos CIDR RFC 1918 que serão reutilizados para os blocos CIDR do GKE.
- Não anuncie os blocos CIDR RFC 1918 reutilizados na rede local.
A seguir
- Para entender melhor a tecnologia subjacente neste documento, leia as seguintes referências normativas:
- Explore arquiteturas de referência, diagramas, tutoriais e práticas recomendadas sobre o Google Cloud. Confira o Centro de arquitetura do Cloud.