Gerenciamento de endereços GKE: otimização de endereços IPv4

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:

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ó:

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

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

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

    Máscara de rede de bloco CIDR do nó.

    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:

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

  2. 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ó.

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

    Máscara de rede de bloco CIDR do pod.

    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:

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

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

Exemplo de configuração do serviço. Para uma versão em PDF legível na tela, clique na imagem.
Figura 1. Exemplo de configuração do serviço. Para uma versão em PDF legível na tela, clique na imagem.

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ço 172.16.0.0/12 ou 192.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:

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.

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

    NAT para todos os blocos de CIDR em um cluster de GKE. Para uma versão em PDF legível na tela, clique na imagem.
    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