Como criar um cluster nativo de VPC

Nesta página, você aprende a configurar clusters nativos de VPC no Google Kubernetes Engine.

Visão geral

No GKE, os clusters podem ser diferenciados de acordo com a maneira como direcionam o tráfego de um pod para outro. O cluster que usa intervalos de IP de alias é chamado de cluster nativo de VPC. Um cluster que usa o Google Cloud Routes é chamado de cluster baseado em rotas .

Benefícios de clusters nativos de VPC

Os clusters nativos de VPC têm vários benefícios:

  • Os endereços de IP do pod são nativamente acessíveis dentro da rede VPC do cluster e outras redes VPC conectadas a ele por peering de rede VPC.
  • Os IPs de pod são reservados na rede VPC antes de os pods serem criados em seu cluster. Isso evita conflito com outros recursos na rede VPC e permite planejar melhor as alocações dos endereços de IP.
  • Os intervalos de IP do pod não dependem de rotas estáticas personalizadas. Eles não consomem a cota de rotas estáticas personalizadas geradas pelo sistema. Em vez disso, as rotas de sub-rede, geradas automaticamente, manipulam o roteamento para os clusters nativos de VPC.
  • É possível criar regras de firewall que se aplicam apenas aos intervalos de IP do pod em vez de qualquer endereço de IP nos nós do cluster.
  • Os nós em um cluster nativo de VPC têm o anti-spoofing ativado. A rede VPC realiza verificações anti-spoofing que impedem que os nós enviem pacotes com endereços de IP de origem arbitrários. (O recurso anti-spoofing está desativado para clusters com base em rotas.)
  • Os intervalos de IP do pod e os intervalos de IP secundários da sub-rede, em geral, podem ser compartilhados com redes locais conectadas com o Cloud VPN ou com Cloud Interconnect usando roteadores Cloud.
  • Os intervalos de IP do alias permitem que os pods acessem os serviços hospedados de forma direta, sem usar um gateway NAT.

Restriçõ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 (IP do cluster) só estão disponíveis no cluster. Se você precisar acessar um Serviço Kubernetes a partir de instâncias de VM fora do cluster, mas dentro da rede e região de VPC do cluster, crie um balanceador de carga TCP/UDP interno.

Intervalos de IP para clusters nativos de VPC

Ao criar um cluster nativo de VPC, você especifica uma sub-rede em uma rede VPC. O cluster usa três intervalos de IP de sub-rede exclusivos:

  • Ele usa o intervalo de IP primário da sub-rede para todos os endereços de IP dos nós.
  • Ele usa um intervalo de IP secundário para todos os endereços de IP do pod.
  • Ele usa outro intervalo de IP secundário para todos os endereços de Serviço (IP do cluster).

A tabela a seguir mostra um resumo dos intervalos de endereços IP para nós, pods e Serviços:

Intervalo Explicação Exemplo
Nós

Endereços IP de nós são atribuídos a partir do intervalo de endereços de IP primário da sub-rede associada ao seu cluster.

Os endereços de IP dos nós e o tamanho do intervalo de IPs secundários da sub-rede para pods limitam o número de nós que um cluster pode suportar. Consulte intervalos de limite de nós para ver mais informações.

Se você planeja criar um cluster de 900 nós, o intervalo de endereços de IP primário da sub-rede do cluster precisa ser de pelo menos /22 (2(32-22) = 210 = 1.024 endereços). Desses 1.024 endereços, 1.020 são utilizáveis porque quatro endereços IP estão reservados em todos os intervalos de endereços de IP primários.

Consulte Intervalo de endereços de IP primários de sub-rede e Intervalo secundário de endereços de IP de sub-redes para pods para ver mais informações.

Pods

Os endereços de IP do pod são obtidos do intervalo de endereços de IP secundários da sub-rede do cluster para pods. A menos que você defina um número máximo de pods por nó, o GKE aloca um /24 intervalo de IP de alias com (256 endereços) para cada nó dos pods executados nele. Em cada nó, esses 256 endereços de IP de alias são usados para dar suporte a até 110 pods.

Para um cluster de 900 nós dando suporte a até 110 pods por nó, você precisa de 900 × 256 = 230.400 endereços de IP para pods. (Cada nó recebe um intervalo de IP do alias com tamanho da máscara de rede de /24.) Esse cluster requer uma sub-rede com intervalo de IP secundário para pods com uma máscara de sub-rede não maior que /14. Esse intervalo de IP secundário fornece 2(32-14) = 2 18 = 262.144 endereços de IP para pods.

Consulte Intervalo de endereços de IP secundários da sub-rede para pods para ver mais informações.

Serviços

Endereços de serviço (IP de cluster) são obtidos do intervalo de endereços de IP secundário da sub-rede do cluster para Serviços. Certifique-se de que esse intervalo seja grande o suficiente para fornecer endereços para todos os Serviços do Kubernetes hospedados no seu cluster.

Para um cluster que executa até 3.000 Serviços, você precisa de 3.000 endereços de IP de cluster. Você precisa de um intervalo secundário de tamanho /20 ou maior. O intervalo A /20 de endereços de IP resulta em 2 (32-20) = 2 12 = 4.096 endereços de IP.

Consulte Intervalo secundário de endereços de IP da sub-rede para Serviços para ver mais informações.

Endereços IP internos

Os endereços IP que você usa para as sub-redes do cluster nativo de VPC precisam vir de um intervalo válido. Os intervalos válidos incluem endereços IP privados (RFC 1918), intervalos de endereços particulares não RFC 1918 e endereços IP públicos reutilizados de modo privado. Consulte Intervalos válidos e Intervalos restritos na documentação da nuvem privada virtual para mais informações sobre os intervalos de endereços que você pode usar para sub-redes.

Consulte a seção Ativar intervalos de endereços IP não RFC 1918 para instruções sobre como ativar o uso desses intervalos.

Consulte a seção Ativar o uso particular de intervalos de endereços IP públicos para instruções sobre o uso desses intervalos em clusters particulares.

Métodos de atribuição de intervalo secundário

É possível atribuir intervalos de IP do pod e intervalos de endereços do Service (ClusterIP) a um cluster nativo de VPC usando um destes métodos:

Gerenciado pelo GKE (padrão)

O GKE pode criar e gerenciar os intervalos secundários da sub-rede para você. Ao criar o cluster, você especifica um intervalo CIDR completo ou o tamanho de uma máscara de rede para os pods e Serviços. Por exemplo, é possível especificar 10.1.0.0/16 para pods e 10.2.0.0/20 para Serviços, ou também é possível especificar /16 para pods e /20 para Serviços.

Se você criar o cluster e a sub-rede simultaneamente, os intervalos de IP do Serviço e do pod serão gerenciados pelo GKE.

Gerenciado pelo usuário

É possível criar os intervalos de IP secundários da sub-rede e, em seguida, criar um cluster que use esses intervalos. Se você criar manualmente os intervalos secundários, gerencie-os manualmente.

Diferenças de clusters baseados em rotas

O esquema de alocação para endereços de Pod e Serviço (IP do cluster) é diferente do esquema usado por um cluster baseado em rotas. Em vez de especificar um único CIDR para pods e Serviços juntos, escolha ou crie dois intervalos de IP secundários na sub-rede do cluster: um para pods e outro para serviços.

Considerações sobre VPC compartilhada

Ao criar um cluster nativo VPC em um ambiente de VPC compartilhada, um proprietário, editor ou membro IAM com função de administrador de rede no projeto de host da VPC compartilhada precisa criar sub-redes e intervalos secundários de IP manualmente. Um administrador de projeto de serviços que cria um cluster precisa ter permissão de nível de sub-rede para a sub-rede desejada no projeto host da rede de VPC compartilhada.

Em um ambiente de VPC compartilhada, os intervalos de IP secundários não podem ser gerenciados pelo GKE. Um administrador de rede no projeto de host da VPC compartilhada precisa criar a sub-rede e intervalos de IP secundários antes de criar o cluster. Para ver um exemplo de como configurar um cluster nativo de VPC em uma rede VPC compartilhada, consulte Configurando clusters com VPC compartilhada.

Planejamento de intervalo de IP

Use as informações nas seções a seguir para calcular os tamanhos dos intervalos de IP primário e secundário da sub-rede usada pelo cluster.

Intervalo do endereço IP primário da sub-rede

Cada sub-rede precisa ter um intervalo de endereços de IP primário. É possível expandir o intervalo de endereços IP primário a qualquer momento, mesmo quando os recursos do Google Cloud usarem a sub-rede. entretanto, não é possível reduzir ou alterar o esquema de endereço de IP primário de uma sub-rede após a criação da sub-rede. Os dois primeiros e os últimos dois endereços IP de um intervalo de IP primário são reservados para o Google Cloud.

A tabela a seguir mostra o número máximo de nós que podem ser criados em todos os clusters que usam a sub-rede, considerando o tamanho do intervalo de endereços IP primário da sub-rede.

Intervalo de IP primário da sub-rede Máximo de nós
/29
Tamanho mínimo do intervalo de IP primário de uma sub-rede
4 nós
/28 12 nós
/27 28 nós
/26 60 nós
/25 124 nós
/24 252 nós
/23 508 nós
/22 1.020 nós
/21 2.044 nós
/20
Tamanho padrão do intervalo de IP primário de uma sub-rede em redes de modo automático
4.092 nós
/19 8.188 nós
/8
Tamanho máximo do intervalo de IP primário de uma sub-rede
16.777.212 nós

Fórmulas úteis

É possível 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. 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 aceitar no máximo N nós:

    S = 32 - ⌈log2(N + 4)⌉

    ⌈⌉ é a função teto (mínimo de número inteiro), o que significa arredondar para o próximo número inteiro. O intervalo válido para o tamanho da máscara de rede, S, é entre 8 e 29, inclusive.

Intervalo do endereço IP secundário da sub-rede para pods

Planeje cuidadosamente seu intervalo de IPs secundário para pods. Embora seja possível substituir o intervalo de endereços de IP secundários de uma sub-rede, isso não é compatível porque pode colocar o cluster em um estado instável.

A tabela a seguir mostra o número máximo de nós e pods que podem ser criados em todos os clusters que usam a sub-rede, considerando o tamanho do intervalo de endereços IP secundário usado pelos pods. Esta tabela considera um número máximo de pods por nó é 110 (o padrão e a maior densidade possível de pods).

Intervalo secundário de IP da sub-rede para pods Máximo de endereços de IP de pod Máximo de nós Máximo de pods
/24
é o menor intervalo de IP de pod possível quando o método de atribuição do intervalo secundário é gerenciado pelo usuário
256 endereços 1 nó 110 pods
/23
só é possível quando o método de atribuição do intervalo secundário é gerenciado pelo usuário
512 endereços 2 nós 220 pods
/22
só é possível quando o método de atribuição do intervalo secundário é gerenciado pelo usuário
1.024 endereços 4 nós 440 pods
/21
é o menor intervalo de IP do pod possível quando o método de atribuição do intervalo secundário é gerenciado pelo GKE
2.048 endereços 8 nós 880 pods
/20 4.096 endereços 16 nós 1.760 pods
/19 8.192 endereços 32 nós 3.520 pods
/18 16.384 endereços 64 nós 7.040 pods
/17 32.768 endereços 128 nós 14.080 pods
/16 65.536 endereços 256 nós 28.160 pods
/15 131.072 endereços 512 nós 56.320 pods
/14
é o tamanho padrão do intervalo de IP secundário da sub-rede para pods quando o método de atribuição de intervalo secundário é gerenciado pelo GKE
262.144 endereços 1.024 nós 112.640 pods
/13 524.288 endereços 2.048 nós 225.280 pods
/12 1.048.576 endereços 4.096 nós 450.560 pods
/11
O maior intervalo possível de endereços de pod
2.097.152 endereços 8.192 nós 901.120 pods

Se você alterou o número máximo de pods por nó, pode usar as seguintes fórmulas para calcular o número máximo de nós e pods compatíveis com o intervalo de IP secundário de uma sub-rede para pods:

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

    • Q é o número de pods por nó;
    • ⌈⌉ é a função teto (mínimo de número inteiro), o que significa arredondar para o próximo número inteiro.
  2. Calcule o número máximo de nós, N, que o intervalo de IP secundário da sub-rede para pods pode suportar:
    N = 2(M - S) em que:

    • M é o tamanho da máscara de rede do intervalo de IP do alias de cada nó para pods, calculado na primeira etapa;
    • S é o tamanho da máscara de sub-rede do intervalo de IP secundário da sub-rede.
  3. Calcule o número máximo de pods, P, que o intervalo de IP secundário da sub-rede para pods pode suportar:
    P = N × Q em que:

    • N é o número máximo de nós, calculado na etapa anterior;
    • Q é o número de pods por nó.

Intervalo do endereço de IP secundário da sub-rede para Serviços

Planeje cuidadosamente seu intervalo de IP secundário para Serviços. Como esse também é um intervalo de IP secundário da sub-rede, só é possível substituí-lo quando nenhum recurso do Google Cloud o utiliza. Este intervalo não pode ser alterado, desde que um cluster o use para Serviços (endereços de IP do cluster).

Ao contrário dos intervalos de IP do nó e do pod, cada cluster precisa ter um intervalo de IP de sub-rede secundário exclusivo para serviços e não pode ser proveniente de um intervalo de IP primário ou secundário compartilhado.

A tabela a seguir mostra o número máximo de Serviços que podem ser criados em um único cluster usando a sub-rede, considerando o tamanho do intervalo de endereços de IP secundário da sub-rede para Serviços.

Intervalo de IP secundário para Serviços Número máximo de Serviços
/27
Menor intervalo de endereços de Serviço possível
32 Serviços
/26 64 Serviços
/25 128 Serviços
/24 256 Serviços
/23 512 Serviços
/22 1.024 Serviços
/21 2.048 Serviços
/20
É o tamanho padrão para o intervalo de IP secundário da sub-rede para serviços quando o método de atribuição de intervalo secundário é gerenciado pelo GKE
4.096 Serviços
/19 8.192 Serviços
/18 16.384 Serviços
/17 32.768 Serviços
/16
O maior intervalo de endereços de Serviço possível
65.536 Serviços

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 de IP primários da sub-rede do cluster e do intervalo de endereços do pod do cluster.

O Console do Cloud mostra mensagens de erro como as listadas abaixo para indicar que o intervalo dos endereços de IP primários da sub-rede ou o intervalo de endereços de IP do cluster do pod (o endereço de IP secundário da sub-rede para pods) foi esgotado:

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

Antes de começar

Antes de começar, verifique se você realizou as tarefas a seguir:

Defina as configurações padrão da gcloud usando um dos métodos a seguir:

  • Use gcloud init se quiser orientações para definir os padrões.
  • Use gcloud config para definir individualmente a região, a zona e o ID do projeto.

Como usar o gcloud init

Se você receber o erro One of [--zone, --region] must be supplied: Please specify location, conclua esta seção.

  1. Execute gcloud init e siga as instruções:

    gcloud init

    Se você estiver usando SSH em um servidor remoto, utilize a sinalização --console-only para impedir que o comando inicie um navegador:

    gcloud init --console-only
  2. Siga as instruções para autorizar a gcloud a usar sua conta do Google Cloud.
  3. Crie uma nova configuração ou selecione uma atual.
  4. Escolha um projeto do Google Cloud.
  5. Escolha uma zona padrão do Compute Engine.

Como usar o gcloud config

  • Defina o ID do projeto padrão:
    gcloud config set project project-id
  • Se você estiver trabalhando com clusters zonais, defina a zona do Compute padrão:
    gcloud config set compute/zone compute-zone
  • Se você estiver trabalhando com clusters regionais, defina a região do Compute padrão:
    gcloud config set compute/region compute-region
  • Atualize gcloud para a versão mais recente:
    gcloud components update

Procedimentos

Use os procedimentos a seguir para criar um cluster nativo de VPC e verificar os intervalos de IP do pod e do Serviço.

Como criar um cluster em uma sub-rede existente

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 degerenciado pelo GKE:

    gcloud container clusters create cluster-name \
      --region=region \
      --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 de gerenciados pelo usuário:

    gcloud container clusters create cluster-name \
      --region=region \
      --enable-ip-alias \
      --subnetwork=subnet-name \
      --cluster-secondary-range-name=secondary-range-pods \
      --services-secondary-range-name=secondary-range-services
    

Substitua os marcadores por valores válidos:

  • cluster-name é o nome do cluster do GKE;
  • region é a região em que o cluster foi criado. Para criar um cluster de zona, substitua essa sinalização por --zone=zone, em que zone é uma zona do Google Cloud.
  • subnet-name é o nome de uma sub-rede existente. O intervalo de IP primário da sub-rede é usado para os nós. A sub-rede precisa estar na mesma região utilizada pelo 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 (por exemplo, 10.0.0.0/14) ou o tamanho da máscara de sub-rede de um bloco CIDR (por exemplo, /14). Isso é usado para criar o intervalo de endereços IP secundário da sub-rede para pods.
    • 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 de endereços IP secundários existente no subnet-name especificado. O GKE usa todo o intervalo secundário de IP da sub-rede para os pods do cluster.
    • secondary-range-services é o nome de um intervalo de endereços IP secundários existente no subnet-name especificado. O GKE usa todo o intervalo secundário de IP da sub-rede para os Serviços do cluster.

Console

  1. Acesse o menu do Google Kubernetes Engine no Console do Cloud.

    Acessar o menu do Google Kubernetes Engine

  2. Clique no botão Criar cluster.

  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 (exemplo: 10.0.0.0/14).

  9. No campo Intervalo de endereços de serviço, especifique um intervalo de serviços (exemplo: 10.4.0.0/19).

  10. Configure o cluster como quiser.

  11. Clique em Criar.

API

Ao criar um cluster nativo de VPC, você define um objeto IPAllocationPolicy. É possível se referir a intervalos de IP secundários de sub-redes existentes ou especificar blocos CIDR. Refira-se a intervalos de IP secundários da sub-rede existente para criar um cluster com 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,

  },
  ...
}

em que:

  • "clusterIpv4CidrBlock" é o tamanho/local do intervalo CIDR para pods. Determina o tamanho do intervalo secundário de pods e pode ser IP/tamanho em notação CIDR (como 10.0.0.0/14) ou /tamanho (como /14). Um espaço vazio com o tamanho especificado é escolhido do 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 tamanho/local do intervalo CIDR para Serviços. Veja a descrição de "clusterIpv4CidrBlock";
  • "clusterSecondaryRangeName" é o nome do intervalo secundário de pods. É obrigatório que o intervalo secundário já exista e pertença à sub-rede associada ao cluster (como a sub-rede especificada com a sinalização --subnetwork);
  • "serviceSecondaryRangeName" é o nome do intervalo secundário para Serviços. O intervalo secundário já precisa existir e pertencer à sub-rede associada ao cluster (como a sub-rede especificada pela sinalização --subnetwork).

Terraform

É fácil criar um cluster nativo de VPC por meio do Terraform usando um módulo Terraform.

Por exemplo, você pode adicionar este bloco à configuração do Terraform:

module "gke" {
  source  = "terraform-google-modules/kubernetes-engine/google"
  version = "~> 9.1"

  project_id        = "project-id"
  name              = "cluster-name"
  region            = "region"
  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 em que o cluster é criado.
  • cluster-name é o nome do cluster do GKE;
  • region é a região em que o cluster foi criado.
  • network-name é o nome de uma rede existente.
  • subnet-name é o nome de uma sub-rede existente. O intervalo de IP primário da sub-rede é usado para os nós. A sub-rede precisa estar na mesma região utilizada pelo cluster.
  • secondary-range-pods é o nome de um intervalo de endereços IP secundários existente no subnet-name especificado. O GKE usa todo o intervalo secundário de IP da sub-rede para os pods do cluster.
  • secondary-range-services é o nome de um intervalo de endereços IP secundários existente no subnet-name especificado. O GKE usa todo o intervalo secundário de IP da sub-rede para os Serviços do cluster.

Como 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 essas duas etapas com um comando.

gcloud

Para criar um cluster nativo e uma sub-rede VPC simultaneamente:

gcloud container clusters create cluster-name \
    --region=region \
    --enable-ip-alias \
    --create-subnetwork name=subnet-name,range=node-ip-range \
    --cluster-ipv4-cidr=pod-ip-range \
    --services-ipv4-cidr=services-ip-range

em que:

  • cluster-name é o nome do cluster do GKE;
  • region é a região em que o cluster foi criado. Para criar um cluster de zona, substitua essa sinalização por --zone=zone, em que zone é uma zona do GKE;
  • 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 (por exemplo, 10.5.0.0/20) ou o tamanho da máscara de sub-rede de um bloco CIDR (por exemplo, /20). Isso é usado para criar o intervalo de endereços IP principais 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 (por exemplo, 10.0.0.0/14) ou o tamanho da máscara de sub-rede de um bloco CIDR (por exemplo, /14). Isso é usado para criar o intervalo de endereços IP secundário da sub-rede para pods. Se omitido, o GKE usa /14, o tamanho padrão do intervalo de IP para pod;
  • 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 omitido, o GKE usa /20, o tamanho padrão do intervalo de IP para Serviços.

Console

Não é possível criar um cluster e uma sub-rede simultaneamente usando o Console do 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 ativar intervalos de endereços IP não RFC 1918

Intervalos de endereços IP não RFC 1918 podem ser usados em clusters do GKE criados com 1.14.2-gke.1 e versões posteriores. Esses endereços podem ser usados em clusters particulares e como endereços internos em clusters comuns.

Endereços não RFC 1918 podem ser usados no intervalo principal para nós e balanceadores de carga TCP/UDP internos; a sub-rede secundária, para pods, e a sub-rede secundária, para serviços.

Se os pods em execução no cluster precisarem entrar em contato com serviços fora do cluster, não compatíveis ou que não possam ser acessados com endereços não RFC 1918, é recomendável usar endereços RFC 1918 no intervalo principal para nós e configurar o Agente de mascaramento de IP possibilitando acessar esses serviços.

Para ativar o uso de IPs reservados não RFC 1918 em clusters públicos ou privados, crie um cluster com a versão 1.14.2-gke.1 ou posterior do GKE. Os IPs reservados não RFC 1918 só podem ser ativados ao criar um novo cluster. Eles não podem ser ativados em um cluster existente.

Como ativar o uso particular de endereços IP públicos

É possível aumentar o número de endereços IP disponíveis para atribuição a recursos de cluster usando determinados intervalos de endereços públicos como se fossem endereços IP privados. Por exemplo, o intervalo de classe E contém 228 endereços IP reservados que não podem ser usados na Internet pública. Reutilizar esses endereços em clusters particulares expande os endereços IP disponíveis. Para mais informações sobre os intervalos de IP que podem ser usados na rede VPC, consulte Intervalos válidos.

A reutilização privada de IPs públicos só é compatível com clusters particulares nativos de VPC.

Consulte as seções a seguir para instruções sobre como ativar o uso particular de endereços IP públicos em novos clusters.

Como criar um novo cluster

Para oferecer suporte ao uso particular de endereços IP públicos, um cluster precisa ser criado com as seguintes configurações:

  • --disable-default-snat: é necessário desativar o SNAT para que as respostas possam ser roteadas para o pod que originou o tráfego.

    Isso significa que as regras SNAT padrão não são aplicadas ao tráfego vinculado à Internet. Se os pods originarem tráfego vinculado à Internet, adicione o intervalo de sub-rede do pod ao Cloud NAT.

  • --enable-ip-alias: cria um cluster nativo de VPC, necessário para o uso particular de IPs públicos.

  • --enable-private-nodes: o uso particular de IPs públicos só é possível em clusters particulares.

Use este comando para criar um cluster:

gcloud beta container clusters create cluster-name \
  --enable-ip-alias --enable-private-nodes --zone=zone \
  --disable-default-snat  --cluster-ipv4-cidr=5.0.0.0/16 \
  --services-ipv4-cidr=5.1.0.0/16 --master-ipv4-cidr=master-CIDR

No momento, não é possível desativar as regras NAT de origem usando a interface do Console do Google Cloud.

Como desativar o SNAT padrão em um cluster existente

Use a opção --disable-default-snat para desativar as regras SNAT padrão em um cluster existente.

gcloud beta container clusters update cluster-name \
  --zone=zone --disable-default-snat

No momento, não é possível desativar as regras NAT de origem usando a interface do Console do Google Cloud.

Como ativar o SNAT padrão em um cluster existente

Use este comando para ativar as regras SNAT padrão em um cluster particular existente:

gcloud beta container clusters update cluster-name \
  --zone=zone --no-disable-default-snat

No momento, não é possível reativar as regras NAT de origem usando a interface do Console do Google Cloud.

Como verificar intervalos de pod e Service

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

Na saída do comando, observe o campo ipAllocationPolicy:

  • clusterIpv4Cidr é o intervalo secundário de pods.
  • servicesIpv4Cidr é o intervalo secundário de serviços.

Console

Para verificar o cluster, siga estas etapas:

  1. Acesse o menu do Google Kubernetes Engine no Console do Cloud.

    Acessar o menu do Google Kubernetes Engine

  2. Selecione o cluster pretendido.

Os intervalos secundários são exibidos na seção Cluster sob a guia Detalhes:

  • O intervalo de endereços do contêiner é o intervalo secundário dos pods
  • O intervalo de endereços de serviço é o intervalo secundário dos Serviços

Solução de problemas

Nesta seção há orientações para resolver problemas relacionados a clusters nativos de VPC.

O recurso "projects/[PROJECT_NAME]/regions/XXX/subnetworks/default" não está pronto

Causas possíveis
Há operações paralelas na mesma sub-rede. Por exemplo, outro cluster nativo de VPC está sendo criado ou um intervalo secundário está sendo adicionado ou excluído na sub-rede.
Resolução
Repetir o comando.

Valor inválido para o campo "resource.secondaryIpRanges [1].ipCidrRange": "XXX". IPCidrRange inválido: XXX está em conflito com a sub-rede "padrão" atual na região "XXX".

Causas possíveis

Outro cluster nativo de VPC está sendo criado simultaneamente, e está tentando alocar os mesmos intervalos na mesma rede VPC.

O mesmo intervalo secundário está sendo adicionado à sub-rede na mesma rede VPC.

Resolução

Se esse erro reaparecer na criação do cluster, quando nenhum intervalo secundário foi especificado, tente executar novamente o comando de criação do cluster.

Não há espaço de IP suficiente para os pods

Sintomas

O cluster está preso em um estado de provisionamento por um longo período de tempo

A criação de cluster retorna um erro do grupo de instâncias gerenciadas (MIG)

Novos nós não podem ser adicionados a um cluster existente

Causas possíveis

O espaço disponível no intervalo de IP do pod não é grande o suficiente para os nós solicitados no cluster. Por exemplo, se o intervalo de IP de um cluster tiver uma máscara de rede com tamanho de /23 (512 endereços) e pods máximos por nó de 110, você não poderá criar mais de dois nós. (Cada nó recebe um intervalo de IP do alias com uma máscara de rede com tamanho de /24.)

Soluções

Crie um cluster substituto depois de analisar e planejar os intervalos de IP primário e secundário de tamanho adequado. Consulte Intervalos de IP para clusters nativos de VPC e Planejamento de intervalo de IP.

Se não for possível substituir o cluster, você poderá solucionar o problema se criar um novo pool de nós com um número máximo de pods por nó. Se possível, transfira as cargas de trabalho para esse pool de nós e, em seguida, exclua o pool de nós anterior. Reduzir o número máximo de pods por nós permite suportar mais nós em um intervalo de IP secundário fixo para pods. Consulte Intervalo secundário de endereços IP da sub-rede para pods e Intervalos de limitação de nós para ver detalhes sobre os cálculos.

Confirmar se o sNAT padrão está desativado

Use o seguinte comando para verificar o status do sNAT padrão:

gcloud beta container clusters describe cluster-name

Substitua cluster-name pelo nome do cluster.

A saída incluirá um campo disableDefaultSnat como este:

networkConfig:
  disableDefaultSnat: true
  network: ...

Não é possível usar --disable-default-snat sem --enable-ip-alias

Essa mensagem de erro e must disable default sNAT (--disable-default-snat) before using public IP privately in the cluster significam que você precisa definir explicitamente a sinalização --disable-default-snat ao criar o cluster, já que está usando endereços IP públicos no cluster particular.

Se você vir mensagens de erro como cannot disable default sNAT ... , isso significa que o SNAT padrão não pode ser desativado no cluster. Revise a configuração do cluster.

Como depurar o Cloud NAT com o sNAT padrão desativado

Se você tiver um cluster particular criado com a sinalização --disable-default-snat, tiver configurado o Cloud NAT para acesso à Internet e não estiver vendo o tráfego vinculado à Internet dos seus pods, verifique se o intervalo de pods está incluído na configuração do Cloud NAT.

Se houver um problema com a comunicação entre pods, examine as regras de iptables nos nós para verificar se os intervalos de pods não estão mascarados por regras de iptables. Consulte o exemplo de saída de iptables do mascaramento de IP para saber como listar as regras iptables e quais são as regras padrão. Se você não tiver configurado um agente de mascaramento de IP para o cluster, o GKE garantirá automaticamente que a comunicação entre pods não seja mascarada. No entanto, se um agente de mascaramento de IP estiver configurado, ele substituirá as regras de mascaramento de IP padrão. Verifique se as regras adicionais estão configuradas no agente de mascaramento de IP para ignorar o mascaramento dos intervalos de pod.

A seguir