Esta página foi traduzida pela API Cloud Translation.

Configurar o suporte a várias redes para pods

Autopilot Standard

Nesta página, mostramos como ativar várias interfaces em nós e pods em um cluster do Google Kubernetes Engine (GKE) usando o suporte a várias redes para pods.

Antes de ler esta página, confira se você conhece os conceitos gerais de rede, a terminologia e os conceitos específicos desse recurso e os requisitos e limitações para compatibilidade com várias redes nos pods.

Para mais informações, consulte Sobre o suporte a várias redes para pods.

Requisitos e limitações

O suporte a várias redes para pods tem os seguintes requisitos e limitações:

Requisitos

GKE Standard versão 1.28 ou mais recente.
GKE Autopilot versão 1.29.5-gke.1091000 e mais recente ou versão 1.30.1-gke.1280000 e mais recente.
O suporte a várias redes para pods usa as mesmas especificações de VM que o multi-NIC para o Compute Engine.
O suporte a várias redes para pods exige o GKE Dataplane V2.
O suporte a várias redes para pods está disponível apenas para nós do Container-Optimized OS que executam a versão m101 ou posterior.

Limitações gerais

O suporte a várias redes para pods não funciona para clusters ativados para rede de pilha dupla.
A VPC compartilhada é compatível apenas com a versão 1.28 ou mais recente do GKE.
O CIDR de vários pods é compatível apenas com a versão 1.29 ou mais recente do GKE e apenas para a rede de pods padrão.
As redes de pod em um único cluster do GKE não podem ter intervalos CIDR sobrepostos.
Ao ativar o suporte a várias redes para pods, não é possível adicionar ou remover interfaces de redes de nós ou redes de pods depois de criar um pool de nós. Para alterar essas configurações, recrie o pool de nós.
Por padrão, o acesso à Internet não está disponível em interfaces adicionais de redes de pod dentro do pod. No entanto, é possível ativá-lo manualmente usando o Cloud NAT.
Não é possível alterar o gateway padrão dentro de um pod com várias interfaces por meio da API. O gateway padrão precisa estar conectado à rede do pod padrão.
A rede de pod padrão precisa sempre ser incluída em pods, mesmo que você crie redes ou interfaces de pods adicionais.
Não é possível configurar o recurso de várias redes quando o Managed Hubble estiver configurado.
Para usar a VPC compartilhada, verifique se o cluster do GKE está executando a versão 1.28.4 ou mais recente.
Para implantações de VPC compartilhada, todas as interfaces de rede (NICs) anexadas aos nós precisam pertencer ao mesmo projeto que o projeto host.
O nome dos objetos de rede digitados pelo dispositivo não pode exceder 41 caracteres. O caminho completo de cada soquete de domínio UNIX é composto, incluindo o nome de rede correspondente. O Linux tem uma limitação de comprimentos de caminho de soquete (menos de 107 bytes). Depois de considerar o diretório, o prefixo do nome do arquivo e a extensão .sock, o nome da rede é limitado a no máximo 41 caracteres.

Limitações do kit de desenvolvimento de plano de dados e dispositivos (DPDK)

Uma NIC de VM transmitida para um pod como uma NIC do tipo Device não está disponível para outros pods no mesmo nó.
Os pods que usam o modo DPDK precisam ser executados no modo privilegiado para acessar dispositivos VFIO.
O modo Autopilot não é compatível com o DPDK.
No modo DPDK, um dispositivo é tratado como um recurso de nó e só é anexado ao primeiro contêiner (não init) no pod. Se você quiser dividir vários dispositivos DPDK entre contêineres no mesmo pod, execute esses contêineres em pods separados.

Limitações de escalonamento

O GKE fornece uma arquitetura de rede flexível que permite escalonar o cluster. É possível adicionar outras redes de nós e pods ao cluster. É possível escalonar o cluster da seguinte maneira:

É possível adicionar até sete redes de nó extras a cada pool de nós do GKE. Esse é o mesmo limite de escala para VMs do Compute Engine.
Cada pod precisa ter menos de sete redes adicionais anexadas.
É possível configurar até 35 redes de pod nas oito redes de nós em um único pool de nós. É possível dividi-la em diferentes combinações, como:
- 7 redes de nós com 5 redes de pod cada
- 5 redes de nós com 7 redes de pod cada
- 1 rede de nó com 30 redes de pod. O limite para intervalos secundários por sub-rede é 30.
É possível configurar até 50 redes de pod por cluster.
É possível configurar até 32 pods de várias redes por nó.
É possível ter até 5.000 nós com várias interfaces.
É possível ter até 100.000 interfaces adicionais em todos os pods.

Preços

Os seguintes recursos do Otimizador de funções de rede (NFO) são compatíveis apenas com clusters que estão em projetos ativados com o GKE Enterprise:

Para entender as cobranças que se aplicam à ativação da edição Enterprise do Google Kubernetes Engine (GKE), consulte Preços do GKE Enterprise.

Implantar pods de várias redes

Para implantar pods de várias redes, faça o seguinte:

Prepare uma VPC adicional, uma sub-rede (rede de nó) e intervalos secundários (rede de pods).
Crie um cluster do GKE em várias redes usando o comando da CLI do Google Cloud.
Crie um novo pool de nós do GKE conectado à rede de nós e à rede de pods adicionais usando o comando da CLI do Google Cloud.
Crie a rede do pod e faça referência aos intervalos secundários, de VPC e sub-rede corretos em objetos de várias redes usando a API Kubernetes.
Na configuração da carga de trabalho, faça referência ao objeto Network preparado do Kubernetes usando a API Kubernetes.

Antes de começar

Antes de começar, veja se você realizou as seguintes tarefas:

Ative a API Google Kubernetes Engine.

Ativar a API Google Kubernetes Engine

Se você quiser usar a CLI do Google Cloud para essa tarefa, instale e, em seguida, inicialize a CLI gcloud. Se você instalou a gcloud CLI anteriormente, instale a versão mais recente executando gcloud components update.
Observação: para instalações atuais da gcloud CLI, defina as propriedades compute/region e compute/zone. Definindo os locais padrão, você evita erros como este na CLI gcloud: One of [--zone, --region] must be supplied: Please specify location.

Analise os requisitos e as limitações.

Preparar uma VPC adicional

O Google Cloud cria uma rede de pods padrão durante a criação do cluster associado ao pool de nós do GKE usado durante a criação inicial do cluster do GKE. A rede de pods padrão está disponível em todos os nós e pods do cluster. Para facilitar os recursos de várias redes no pool de nós, você precisa preparar VPCs atuais ou novas que ofereçam suporte a redes dos tipos Layer 3 e Device.

Para preparar outra VPC, considere os seguintes requisitos:

Rede dos tipos Layer 3 e Netdevice:
- Crie um intervalo secundário se você estiver usando redes do tipo Layer 3.
- Verifique se o tamanho do CIDR para o intervalo secundário é grande o suficiente para atender ao número de nós no pool de nós e o número de pods por nó que você quer ter.
- Semelhante à rede de pods padrão, as outras redes de pods usam superprovisionamento de endereço IP. O intervalo de IP secundário precisa ter o dobro de endereços IP por nó que o número de pods por nó.
Requisitos de rede do tipo Device: crie uma sub-rede normal em uma VPC. Você não precisa de uma sub-rede secundária.

Para ativar os recursos de várias redes no pool de nós, prepare as VPCs com as quais você quer estabelecer conexões adicionais. É possível usar uma VPC atual ou Criar uma nova VPC especificamente para o pool de nós.

Crie uma rede VPC que ofereça suporte a um dispositivo do tipo `Layer 3`

Para criar uma rede VPC compatível com um dispositivo do tipo Layer 3, faça o seguinte:

Verifique se o tamanho do CIDR para o intervalo secundário é grande o suficiente para atender ao número de nós no pool de nós e o número de pods por nó que você quer ter.
Semelhante à rede de pods padrão, as outras redes de pods usam superprovisionamento de endereço IP. O intervalo de endereço IP secundário precisa ter o dobro de endereços IP por nó que o número de pods por nó.

gcloud

gcloud compute networks subnets create SUBNET_NAME \
    --project=PROJECT_ID \
    --range=SUBNET_RANGE \
    --network=NETWORK_NAME \
    --region=REGION \
    --secondary-range=SECONDARY_RANGE_NAME=<SECONDARY_RANGE_RANGE>

Substitua:

SUBNET_NAME: o nome da sub-rede.
PROJECT_ID: o ID do projeto que contém a rede VPC em que a sub-rede é criada.
SUBNET_RANGE: o intervalo de endereços IPv4 principal da nova sub-rede, em notação CIDR.
NETWORK_NAME: o nome da rede VPC que contém a nova sub-rede.
REGION: a região do Google Cloud em que a nova sub-rede foi criada.
SECONDARY_RANGE_NAME: o nome do intervalo secundário.
SECONDARY_IP_RANGE é o intervalo de endereços IPv4 secundário na notação CIDR.

Console

No Console do Google Cloud, acesse a página Redes VPC.
Clique em Criar rede VPC.
No campo Nome, digite o nome da rede. Por exemplo, l3-vpc.
No menu suspenso Unidade máxima de transmissão (MTU, na sigla em inglês), escolha o valor de MTU apropriado.

Observação: antes de definir a MTU com um valor maior que 1460, analise a unidade de transmissão máxima.
Na seção Modo de criação de sub-rede, escolha Personalizado.
Clique em ADICIONAR SUB-REDE.
Na seção Nova sub-rede, especifique os parâmetros de configuração a seguir para uma sub-rede:
1. Forneça um Nome. Por exemplo, l3-subnet.
2. Selecione uma Região.
3. Digite um Intervalo de endereço IP. Esse é o intervalo IPv4 principal da sub-rede.
  
  Se você selecionar um intervalo que não seja um endereço RFC 1918, confirme se não há incompatibilidade entre o intervalo e uma configuração existente. Para mais informações, consulte Intervalos de sub-rede IPv4.
4. Para definir um intervalo secundário da sub-rede, clique em Criar um intervalo secundário de endereço IP.
  
  Se você selecionar um intervalo que não seja um endereço RFC 1918, confirme se não há incompatibilidade entre o intervalo e uma configuração existente. Para mais informações, consulte Intervalos de sub-rede IPv4.
5. Acesso privado do Google: é possível ativar o Acesso privado do Google para a sub-rede ao criá-la ou depois, editando-a.
6. Registros de fluxo: é possível ativar registros de fluxo de VPC para a sub-rede ao criá-la ou depois, editando-a.
7. Clique em Concluído.
Observação: para adicionar mais sub-redes, clique em Adicionar sub-rede. Depois de criar a rede, também é possível adicionar mais sub-redes à ela.
Na seção Regras de firewall, em Regras de firewall IPv4, selecione zero ou mais regras de firewall predefinidas.

As regras abordam casos de uso comuns para o processo de conexão a instâncias. É possível criar suas próprias regras de firewall, depois de criar a rede. Cada nome de regra predefinido começa com o nome da rede VPC que você está criando.
Em Regras de firewall IPv4, para editar a regra de firewall de entrada predefinida chamada allow-custom, clique em EDITAR.

É possível editar sub-redes, adicionar outros intervalos IPv4 e especificar protocolos e portas.

A regra de firewall allow-custom não será atualizada automaticamente se você adicionar outras sub-redes posteriormente. Se você precisar de regras de firewall para as novas sub-redes, atualize a configuração do firewall para adicioná-las.
Na seção Modo de roteamento dinâmico, para a rede VPC. Para saber mais informações, consulte modo de roteamento dinâmico. É possível alterar o modo de roteamento dinâmico mais tarde.
Clique em Criar.

Crie uma rede VPC compatível com dispositivos do tipo `Netdevice` ou `DPDK`

gcloud

gcloud compute networks subnets create SUBNET_NAME \
    --project=PROJECT_ID \
    --range=SUBNET_RANGE \
    --network=NETWORK_NAME \
    --region=REGION \
    --secondary-range=SECONDARY_RANGE_NAME=<SECONDARY_RANGE_RANGE>

Substitua:

SUBNET_NAME: o nome da sub-rede.
PROJECT_ID: o ID do projeto que contém a rede VPC em que a sub-rede é criada.
SUBNET_RANGE: o intervalo de endereços IPv4 principal da nova sub-rede, em notação CIDR.
NETWORK_NAME: o nome da rede VPC que contém a nova sub-rede.
REGION: a região do Google Cloud em que a nova sub-rede foi criada.
SECONDARY_RANGE_NAME: o nome do intervalo secundário.
SECONDARY_IP_RANGE é o intervalo de endereços IPv4 secundário na notação CIDR.

Console

No Console do Google Cloud, acesse a página Redes VPC.
Clique em Criar rede VPC.
No campo Nome, digite o nome da rede. Por exemplo, netdevice-vpc ou dpdk-vpc.
No menu suspenso Unidade máxima de transmissão (MTU, na sigla em inglês), escolha o valor de MTU apropriado.

Observação: antes de definir a MTU com um valor maior que 1460, consulte a Unidade máxima de transmissão.
Na seção Modo de criação de sub-rede, escolha Personalizado.
Na seção Nova sub-rede, especifique os parâmetros de configuração a seguir para uma sub-rede:
1. Forneça um Nome. Por exemplo, netdevice-subnet ou dpdk-vpc.
2. Selecione uma Região.
3. Digite um Intervalo de endereço IP. Esse é o intervalo IPv4 principal da sub-rede.
  
  Se você selecionar um intervalo que não seja um endereço RFC 1918, confirme se não há incompatibilidade entre o intervalo e uma configuração existente. Para mais informações, consulte Intervalos de sub-rede IPv4.
4. Acesso privado do Google: escolha se você quer ativar o Acesso privado do Google para a sub-rede ao criá-la ou mais tarde, editando-a.
5. Registros de fluxo: é possível ativar registros de fluxo de VPC para a sub-rede ao criá-la ou depois, editando-a.
6. Clique em Concluído.
  
  Observação: para adicionar mais sub-redes, clique em Adicionar sub-rede. Depois de criar a rede, também é possível adicionar mais sub-redes à ela.
Na seção Regras de firewall, em Regras de firewall IPv4, selecione zero ou mais regras de firewall predefinidas.

As regras abordam casos de uso comuns para o processo de conexão a instâncias. É possível criar suas próprias regras de firewall, depois de criar a rede. Cada nome de regra predefinido começa com o nome da rede VPC que você está criando.
Em Regras de firewall IPv4, para editar a regra de firewall de entrada predefinida chamada allow-custom, clique em EDITAR.

É possível editar sub-redes, adicionar outros intervalos IPv4 e especificar protocolos e portas.

A regra de firewall allow-custom não será atualizada automaticamente se você adicionar outras sub-redes posteriormente. Se você precisar de regras de firewall para as novas sub-redes, atualize a configuração do firewall para adicioná-las.
Na seção Modo de roteamento dinâmico, para a rede VPC. Para saber mais informações, consulte modo de roteamento dinâmico. É possível alterar o modo de roteamento dinâmico mais tarde.
Clique em Criar.

Criar um cluster do GKE com recursos de várias redes

A ativação de várias redes para um cluster adiciona as CustomResourceDefinitions (CRDs) necessárias ao servidor de API para esse cluster. Ele também implanta um controlador de rede, que é responsável por reconciliar e gerenciar objetos de várias redes. Não é possível modificar a configuração do cluster depois que ele é criado.

Criar um cluster do GKE Autopilot com recursos de várias redes

Criar um cluster do GKE Autopilot com recursos de várias redes:

gcloud container clusters create-auto CLUSTER_NAME \
    --cluster-version=CLUSTER_VERSION \
    --enable-multi-networking

Substitua:

CLUSTER_NAME: o nome do cluster.
CLUSTER_VERSION: a versão do cluster.

a sinalização --enable-multi-networking ativa as definições de recursos personalizados (CRDs) de várias redes no servidor de API deste cluster e implanta um gerenciador de controlador de rede que contém a reconciliação e o gerenciamento do ciclo de vida para objetos de várias redes.

Criar um cluster do GKE Standard com recursos de várias redes

gcloud

Criar um cluster do GKE Standard com recursos de várias redes:

gcloud container clusters create CLUSTER_NAME \
    --cluster-version=CLUSTER_VERSION \
    --enable-dataplane-v2 \
    --enable-ip-alias \
    --enable-multi-networking

Substitua:

CLUSTER_NAME: o nome do cluster.
CLUSTER_VERSION: a versão do cluster.

Esse comando inclui as seguintes sinalizações:

--enable-multi-networking: ativa as definições de recursos personalizados (CRDs, na sigla em inglês) de várias redes no servidor de API deste cluster e implanta um gerenciador de controlador de rede que contém a reconciliação e o gerenciamento do ciclo de vida para objetos de várias redes.
--enable-dataplane-v2: ativa o GKE Dataplane V2. Essa sinalização é necessária para ativar várias redes.

Console

Acesse a página Google Kubernetes Engine no console do Google Cloud.

Acessar o Google Kubernetes Engine
Clique em Criar.
Configure o cluster padrão. Para mais informações, consulte Criar um cluster de zona ou Criar um cluster regional. Ao criar o cluster, selecione a sub-rede de nó e de rede apropriada.
No painel de navegação, em Cluster, clique em Rede.
Marque a caixa de seleção Ativar o Dataplane V2.
Selecione Ativar várias redes.
Clique em Criar.

Criar um pool de nós do GKE Standard conectado a outras VPCs

Crie um pool de nós que inclua nós conectados à rede de nós (VPC e sub-rede) e à rede de pods (intervalo secundário) criados em Criar rede de pods.

Para criar o novo pool de nós e associá-lo às redes adicionais no cluster do GKE:

gcloud

gcloud container node-pools create POOL_NAME \
  --cluster=CLUSTER_NAME \
  --additional-node-network network=NETWORK_NAME,subnetwork=SUBNET_NAME \
  --additional-pod-network subnetwork=subnet-dp,pod-ipv4-range=POD_IP_RANGE,max-pods-per-node=NUMBER_OF_PODS \
  --additional-node-network network=highperformance,subnetwork=subnet-highperf

Substitua:

POOL_NAME pelo nome do novo pool de nós.
CLUSTER_NAME pelo nome do cluster atual ao qual você está adicionando o pool de nós.
NETWORK_NAME pelo nome da rede para anexar os nós do pool de nós.
SUBNET_NAME pelo nome da sub-rede dentro da rede a ser usada para os nós.
POD_IP_RANGE é o intervalo de endereços IP do pod na sub-rede.
NUMBER_OF_PODS número máximo de pods por nó.

Esse comando contém as seguintes sinalizações:

--additional-node-network: define os detalhes da interface de rede, da rede e da sub-rede adicionais. Isso é usado para especificar as redes de nós para conexão com os nós do pool de nós. Especifique esse parâmetro quando quiser se conectar a outra VPC. Se você não especificar esse parâmetro, a VPC padrão associada ao cluster será usada. Para redes do tipo Layer 3, especifique a sinalização additional-pod-network que define a rede do pod, que é exposta dentro do cluster do GKE como o objeto Network. Ao usar a sinalização --additional-node-network, você precisa fornecer uma rede e uma sub-rede como parâmetros obrigatórios. Certifique-se de separar os valores de rede e sub-rede com uma vírgula e evite usar espaços.
--additional-pod-network: especifica os detalhes do intervalo secundário a ser usado para a rede de pods. Esse parâmetro não é obrigatório se você usa uma rede do tipo Device. Esse argumento especifica os seguintes valores de chave: subnetwork, pod-ipv4-range e max-pods-per-node. Ao usar o --additional-pod-network, você precisa fornecer os valores pod-ipv4-range e max-pods-per-node, separados por vírgulas e sem espaços.
- subnetwork: vincula a rede do nó à rede do pod. A sub-rede é opcional. Se você não especificar isso, a rede de pods extra será associada à sub-rede padrão fornecida durante a criação do cluster.
- --max-pods-per-node: o max-pods-per-node precisa ser especificado e precisa ter uma potência de 2. O valor mínimo é 4. max-pods-per-node não pode ser maior que o valor max-pods-per-node no pool de nós.

Console

Acesse a página Google Kubernetes Engine no console do Google Cloud.

Acessar o Google Kubernetes Engine
No painel de navegação, clique em Clusters.
Na seção Clusters do Kubernetes, clique no cluster que você criou.
Na parte de cima da página, para criar o pool de nós, clique em Adicionar pool de nós.
Na seção Detalhes do pool de nós, preencha o seguinte:
1. Insira um Nome para o pool de nós.
2. Digite o Número de nós a serem criados no pool de nós.
No painel de navegação, em Pools de nós, clique em Nós.
1. Na lista suspensa Tipo de imagem, selecione a imagem de nó Container-Optimized OS com containerd (cos_containerd).
  
  Aviso: no GKE versão 1.24 e posterior, os tipos de imagem de nó baseados no Docker não são compatíveis. Na versão 1.23 do GKE, não é possível criar novos pools de nós com tipos de imagem de nó do Docker. É necessário migrar para um tipo de imagem de nó containerd. Para saber mais sobre essa mudança, consulte Sobre a descontinuação de imagens de nó do Docker.
Ao criar uma VM, você seleciona um tipo de máquina de uma família de máquina que determina os recursos disponíveis para ela. Por exemplo, um tipo de máquina como e2-standard-4 contém quatro vCPUs, portanto, aceita até quatro VPCs no total. Há várias famílias de máquina disponíveis, cada uma organizada em série e em tipos predefinidos ou personalizados em cada série. A cobrança varia de acordo com cada tipo de máquina. Para mais informações, consulte a Tabela de preços do tipo de máquina.
No painel de navegação, selecione Rede.
Na seção Rede de nós, especifique o número máximo de pods por nó. A seção Redes de nós mostra a rede VPC utilizada para criar o cluster. É necessário designar redes de nós extras correlacionadas com redes VPC e tipos de dispositivos estabelecidos anteriormente.
Criar associação de pool de nós:
1. Para dispositivos do tipo Layer 3:
  1. Na seção Redes de nós, clique em ADICIONAR UMA REDE DE NÓ.
  2. Na lista suspensa de rede, selecione a VPC compatível com o dispositivo do tipo Camada 3.
  3. Selecione a sub-rede criada para a VPC Layer 3.
  4. Na seção Intervalos de endereços IP do pod do alias, clique em Adicionar intervalo de endereços IP do pod.
  5. Selecione a Sub-rede secundária e indique o Número máximo de pods por nó.
  6. Selecione Concluído.
2. Para o dispositivo do tipo Netdevice e DPDK:
  1. Na seção Redes de nós, clique em ADICIONAR UMA REDE DE NÓ.
  2. Na lista suspensa de rede, selecione a VPC compatível com dispositivos dos tipos Netdevice ou DPDK.
  3. Selecione a sub-rede criada para a VPC Netdevice ou DPDK.
  4. Selecione Concluído.
Clique em Criar.

Observações:

Se várias redes de pods adicionais forem especificadas na mesma rede de nós, elas precisarão estar na mesma sub-rede.
Não é possível referenciar o mesmo intervalo secundário de uma sub-rede várias vezes.

Exemplo O exemplo a seguir cria um pool de nós chamado pool-multi-net que anexa duas outras redes aos nós: datapalane (rede do tipo Layer 3) e alto desempenho (tipo de dispositivo de rede). Este exemplo pressupõe que você já criou um cluster do GKE chamado cluster-1:

gcloud container node-pools create pool-multi-net \
  --project my-project \
  --cluster cluster-1 \
  --zone us-central1-c \
  --additional-node-network network=dataplane,subnetwork=subnet-dp \
  --additional-pod-network subnetwork=subnet-dp,pod-ipv4-range=sec-range-blue,max-pods-per-node=8 \
  --additional-node-network network=highperformance,subnetwork=subnet-highperf

Para especificar outras interfaces de rede de nós e pods, defina os parâmetros --additional-node-network e --additional-pod-network várias vezes, conforme mostrado no exemplo a seguir:

--additional-node-network network=dataplane,subnetwork=subnet-dp \
--additional-pod-network subnetwork=subnet-dp,pod-ipv4-range=sec-range-blue,max-pods-per-node=8 \
--additional-pod-network subnetwork=subnet-dp,pod-ipv4-range=sec-range-green,max-pods-per-node=8 \
--additional-node-network network=managementdataplane,subnetwork=subnet-mp \
--additional-pod-network subnetwork=subnet-mp,pod-ipv4-range=sec-range-red,max-pods-per-node=4

Para especificar outras redes de pods diretamente na interface da VPC principal do pool de nós, conforme mostrado no exemplo a seguir:

--additional-pod-network subnetwork=subnet-def,pod-ipv4-range=sec-range-multinet,max-pods-per-node=8

Criar rede do pod

Defina as redes de pods que os pods acessarão definindo objetos do Kubernetes e vinculando-os aos recursos correspondentes do Compute Engine, como VPCs, sub-redes e intervalos secundários.

Para criar uma rede de pods, defina os objetos de CRD de rede no cluster.

Configurar a rede VPC `Layer 3`

YAML

Para a VPC Layer 3, crie objetos Network e GKENetworkParamSet:

Salve o seguinte manifesto de amostra como blue-network.yaml:
```
apiVersion: networking.gke.io/v1
kind: Network
metadata:
  name: blue-network
spec:
  type: "L3"
  parametersRef:
    group: networking.gke.io
    kind: GKENetworkParamSet
    name: "l3-vpc"
```
O manifesto define um recurso Network chamado blue-network do tipo Layer 3. O objeto Network faz referência ao objeto GKENetworkParamSet chamado l3-vpc, que associa uma rede aos recursos do Compute Engine.
Aplique o manifesto ao cluster:
```
kubectl apply -f blue-network.yaml
```
Salve o seguinte manifesto como dataplane.yaml:
```
apiVersion: networking.gke.io/v1
kind: GKENetworkParamSet
metadata:
  name: "dataplane"
spec:
  vpc: "l3-vpc"
  vpcSubnet: "subnet-dp"
  podIPv4Ranges:
    rangeNames:
    - "sec-range-blue"
```
Esse manifesto define o objeto GKENetworkParamSet chamado dataplane, define o nome da VPC como l3-vpc, o nome da sub-rede como subnet-dp e um intervalo de endereços IPv4 secundário para pods chamados sec-range-blue.
Aplique o manifesto ao cluster:
```
kubectl apply -f dataplane.yaml
```

Console

Acesse a página Google Kubernetes Engine no console do Google Cloud.

Acessar o Google Kubernetes Engine
No painel de navegação, clique em Gerenciador de funções da rede.
Na parte superior da página, clique em Criar para criar a rede do pod.
Na seção Antes de começar, verifique os detalhes.
Clique em PRÓXIMO: LOCAL DA REDE DE POD.
Na seção Local da rede do pod, no menu suspenso Cluster, selecione o cluster do GKE que tenha várias redes e o GKE Dataplane V2 ativado.
Clique em PRÓXIMO: REFERÊNCIA DE REDE VPC.
Na seção Referência da rede VPC, no menu suspenso Referência da rede VPC, selecione a rede VPC usada para pods multinic Layer 3.
Clique em PRÓXIMO: TIPO DE REDE DE POD.
Na seção Tipo de rede do pod, selecione L3 e insira o nome da rede do pod.
Clique em PRÓXIMO: FAIXA SECUNDÁRIA DA REDE DE POD.
Na seção Intervalo secundário da rede do pod, insira o Intervalo secundário.
Clique em PRÓXIMO: ROTAS DA REDE DE POD.
Na seção Rotas de rede do pod, para definir Rotas personalizadas, selecione ADICIONAR ROTA.
Clique em CRIAR REDE DE POD.

Configurar rede DPDK

YAML

Para a VPC do DPDK, crie objetos Network e GKENetworkParamSet.

Salve o seguinte manifesto de amostra como dpdk-network.yaml:

apiVersion: networking.gke.io/v1
kind: Network
metadata:
  name: dpdk-network
spec:
  type: "Device"
  parametersRef:
    group: networking.gke.io
    kind: GKENetworkParamSet
    name: "dpdk"

Esse manifesto define um recurso Network chamado dpdk-network com um tipo de Device. O recurso Network se refere a um objeto GKENetworkParamSet chamado dpdk para a configuração.

Aplique o manifesto ao cluster:
```
kubectl apply -f dpdk-network.yaml
```
Para o objeto GKENetworkParamSet, salve o seguinte manifesto como dpdk.yaml:
```
apiVersion: networking.gke.io/v1
kind: GKENetworkParamSet
metadata:
  name: "dpdk"
spec:
  vpc: "dpdk"
  vpcSubnet: "subnet-dpdk"
  deviceMode: "DPDK-VFIO"
```
Esse manifesto define o objeto GKENetworkParamSet chamado dpdk, define o nome da VPC como dpdk, o nome da sub-rede como subnet-dpdk e o nome de deviceMode como DPDK-VFIO.
Aplique o manifesto ao cluster:
```
kubectl apply -f dpdk-network.yaml
```

Console

Acesse a página Google Kubernetes Engine no console do Google Cloud.

Acessar o Google Kubernetes Engine
No painel de navegação, clique em Gerenciador de funções da rede.
Na parte superior da página, clique em Criar para criar a rede do pod.
Na seção Antes de começar, verifique os detalhes.
Clique em PRÓXIMO: LOCAL DA REDE DE POD.
Na seção Local da rede do pod, no menu suspenso Cluster, selecione o cluster do GKE que tenha várias redes e o GKE Dataplane V2 ativado.
Clique em PRÓXIMO: REFERÊNCIA DE REDE VPC.
Na seção Referência da rede VPC, no menu suspenso Referência da rede VPC, selecione a rede VPC usada para pods multinic dpdk.
Clique em PRÓXIMO: TIPO DE REDE DE POD.
Na seção Tipo de rede do pod, selecione DPDK-VFIO (dispositivo) e insira o Nome da rede do pod.
Clique em PRÓXIMO: FAIXA SECUNDÁRIA DA REDE DE POD. A seção do intervalo secundário da rede do pod não estará disponível
Clique em PRÓXIMO: ROTAS DA REDE DE POD. Na seção Rotas de rede do pod, selecione ADICIONAR ROTA para definir rotas personalizadas
Clique em CRIAR REDE DE POD.

Configurar rede netdevice

Para a VPC netdevice, crie objetos Network e GKENetworkParamSet.

YAML

Salve o seguinte manifesto de amostra como netdevice-network.yaml:

apiVersion: networking.gke.io/v1
kind: Network
metadata:
    name: netdevice-network
spec:
    type: "Device"
    parametersRef:
      group: networking.gke.io
      kind: GKENetworkParamSet
      name: "netdevice"

Esse manifesto define um recurso Network chamado netdevice-network com um tipo de Device. Ele faz referência ao objeto GKENetworkParamSet chamado netdevice.

Aplique o manifesto ao cluster:

kubectl apply -f netdevice-network.yaml

Salve o seguinte manifesto como netdevice.yaml:
```
apiVersion: networking.gke.io/v1
kind: GKENetworkParamSet
metadata:
  name: netdevice
spec:
  vpc: netdevice
  vpcSubnet: subnet-netdevice
  deviceMode: NetDevice
```
Esse manifesto define um recurso GKENetworkParamSet chamado netdevice, define o nome da VPC como netdevice, o nome da sub-rede como subnet-netdevice e especifica o modo do dispositivo como NetDevice.
Aplique o manifesto ao cluster:
```
kubectl apply -f netdevice.yaml
```

Console

Acesse a página Google Kubernetes Engine no console do Google Cloud.

Acessar o Google Kubernetes Engine
No painel de navegação, clique em Gerenciador de funções da rede.
Na parte superior da página, clique em Criar para criar a rede do pod.
Na seção Antes de começar, verifique os detalhes.
Clique em PRÓXIMO: LOCAL DA REDE DE POD.
Na seção Local da rede do pod, no menu suspenso Cluster, selecione o cluster do GKE que tenha várias redes e o GKE Dataplane V2 ativado.
Clique em PRÓXIMO: REFERÊNCIA DE REDE VPC.
Na seção Referência da rede VPC, no menu suspenso Referência da rede VPC, selecione a rede VPC usada para os pods multinic do netdevice.
Clique em PRÓXIMO: TIPO DE REDE DE POD.
Na seção Tipo de rede do pod, selecione NetDevice (Device) e insira o Nome da rede do pod.
Clique em PRÓXIMO: FAIXA SECUNDÁRIA DA REDE DE POD. A seção do intervalo secundário da rede do pod não estará disponível
Clique em PRÓXIMO: ROTAS DA REDE DE POD. Na seção Rotas de rede do pod, para definir rotas personalizadas, selecione ADICIONAR ROTA.
Clique em CRIAR REDE DE POD.

Como configurar rotas de rede

A configuração da rota de rede permite definir rotas personalizadas para uma rede específica, que são configuradas nos pods para direcionar o tráfego para a interface correspondente dentro do pod.

YAML

Salve o seguinte manifesto como red-network.yaml:

apiVersion: networking.gke.io/v1
kind: Network
metadata:
  name: red-network
spec:
  type: "L3"
  parametersRef:
    group: networking.gke.io
    kind: GKENetworkParamSet
    name: "management"
  routes:
  -   to: "10.0.2.0/28"

Esse manifesto define um recurso de rede chamado red-network com um tipo de Layer 3 e uma rota personalizada "10.0.2.0/28" por meio dessa interface de rede.

Aplique o manifesto ao cluster:
```
kubectl apply -f red-network.yaml
```

Console

Acesse a página Google Kubernetes Engine no console do Google Cloud.

Acessar o Google Kubernetes Engine
Clique em Criar.
No painel de navegação, clique em Gerenciador de funções da rede.
Na seção Clusters do Kubernetes, clique no cluster que você criou.
Na parte superior da página, clique em Criar para criar a rede do pod.
Na seção Rotas de rede do pod, defina Rotas personalizadas.
Clique em CRIAR REDE DE POD.

Consulte a `Network` preparada

Na configuração da carga de trabalho, faça referência ao objeto Network do Kubernetes preparado usando a API Kubernetes.

Conectar o pod a redes específicas

Para conectar pods às redes especificadas, inclua os nomes dos objetos Network como anotações dentro da configuração do pod. Certifique-se de incluir o default Network e as redes adicionais selecionadas nas anotações para estabelecer as conexões.

Salve o seguinte manifesto de amostra como sample-l3-pod.yaml:

apiVersion: v1
kind: Pod
metadata:
  name: sample-l3-pod
  annotations:
    networking.gke.io/default-interface: 'eth0'
    networking.gke.io/interfaces: |
      [
        {"interfaceName":"eth0","network":"default"},
        {"interfaceName":"eth1","network":"blue-network"}
      ]
spec:
  containers:
  - name: sample-l3-pod
    image: busybox
    command: ["sleep", "10m"]
    ports:
    - containerPort: 80
  restartPolicy: Always

Esse manifesto cria um pod chamado sample-l3-pod com duas interfaces de rede, eth0 e eth1, associadas às redes default e blue-network, respectivamente.

Aplique o manifesto ao cluster:
```
kubectl apply -f sample-l3-pod.yaml
```

Conectar o pod com várias redes

Salve o seguinte manifesto de amostra como sample-l3-netdevice-pod.yaml:

apiVersion: v1
kind: Pod
metadata:
  name: sample-l3-netdevice-pod
  annotations:
    networking.gke.io/default-interface: 'eth0'
    networking.gke.io/interfaces: |
      [
        {"interfaceName":"eth0","network":"default"},
        {"interfaceName":"eth1","network":"blue-network"},
        {"interfaceName":"eth2","network":"netdevice-network"}
      ]
spec:
  containers:
  - name: sample-l3-netdevice-pod
    image: busybox
    command: ["sleep", "10m"]
    ports:
    - containerPort: 80
  restartPolicy: Always

Esse manifesto cria um pod chamado sample-l3-netdevice-pod com três interfaces de rede, eth0 e eth1 e eth2 associadas às redes default, blue-network e netdevice respectivamente.

Aplique o manifesto ao cluster:

kubectl apply -f sample-l3-netdevice-pod.yaml

É possível usar a mesma anotação em qualquer ReplicaSet (Implantação ou DaemonSet) na seção de anotação do modelo.

Exemplo de configuração de um pod com várias interfaces:

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
      valid_lft forever preferred_lft forever
2: eth0@if9: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1460 qdisc noqueue state UP group default
    link/ether 2a:92:4a:e5:da:35 brd ff:ff:ff:ff:ff:ff link-netnsid 0
    inet 10.60.45.4/24 brd 10.60.45.255 scope global eth0
      valid_lft forever preferred_lft forever
10: eth1@if11: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1460 qdisc noqueue state UP group default qlen 1000
    link/ether ba:f0:4d:eb:e8:02 brd ff:ff:ff:ff:ff:ff link-netnsid 0
    inet 172.16.1.2/32 scope global eth1
      valid_lft forever preferred_lft forever

Verificação

Crie clusters com --enable-multi-networking somente se --enable-dataplane-v2 estiver ativado.
Verifique se todos os pools de nós no cluster estão executando imagens do Container-Optimized OS no momento da criação do cluster e do pool de nós.
Verifique se os pools de nós serão criados com --additional-node-network ou --additional-pod-network somente se a rede estiver ativada no cluster.
Verifique se a mesma sub-rede não é especificada duas vezes como argumento --additional-node-network para um pool de nós.
Verifique se o mesmo intervalo secundário não está especificado como o argumento --additional-pod-network para um pool de nós.
Siga os limites de escala especificados para objetos de rede, considerando o número máximo de nós, pods e endereços IP permitidos.
Verifique se há apenas um objeto GKENetworkParamSet que se refira a uma sub-rede e um intervalo secundários específicos.
Verifique se cada objeto de rede se refere a um objeto GKENetworkParamSet diferente.
Verifique se o objeto de rede, se for criado com uma sub-rede específica com a rede Device, não está sendo usado no mesmo nó com outra rede com um intervalo secundário. Só é possível validar isso no tempo de execução.
Verifique se os vários intervalos secundários atribuídos aos pools de nós não têm endereços IP sobrepostos.

Resolver problemas de parâmetros de várias redes no GKE

Quando você cria um cluster e um pool de nós, o Google Cloud implementa determinadas verificações para garantir que apenas parâmetros válidos de várias redes sejam permitidos. Isso garante que a rede esteja configurada corretamente para o cluster.

Se você não conseguir criar cargas de trabalho de várias redes, verifique o status e os eventos do pod para mais informações:

kubectl describe pods samplepod

O resultado será assim:

Name:         samplepod
Namespace:    default
Status:       Running
IP:           192.168.6.130
IPs:
  IP:  192.168.6.130
...
Events:
  Type     Reason                  Age   From               Message
  ----     ------                  ----  ----               -------
  Normal   NotTriggerScaleUp  9s               cluster-autoscaler  pod didn't trigger scale-up:
  Warning  FailedScheduling   8s (x2 over 9s)  default-scheduler   0/1 nodes are available: 1 Insufficient networking.gke.io.networks/my-net.IP. preemption: 0/1 nodes are available: 1 No preemption victims found for incoming pod

Veja a seguir motivos gerais para a falha na criação de pods:

Falha ao programar pod porque os requisitos de recursos de várias redes não foram atendidos
Falha ao identificar redes especificadas

Resolver problemas na criação de redes do Kubernetes

Depois de criar uma rede, os nós que precisam ter acesso à rede configurada são anotados com uma anotação de status de rede.

Para observar as anotações, execute o seguinte comando:

kubectl describe node NODE_NAME

Substitua NODE_NAME pelo nome do nó.

O resultado será assim:

networking.gke.io/network-status: [{"name":"default"},{"name":"dp-network"}]

A saída lista cada rede disponível no nó. Se o status da rede esperado não for visto no nó, faça o seguinte:

Verificar se o nó pode acessar a rede

Se a rede não estiver aparecendo na anotação de status da rede do nó:

Verifique se o nó faz parte de um pool configurado para várias redes.
Verifique as interfaces do nó para ver se ele tem uma interface para a rede que você está configurando.
Se um nó não tiver status de rede e tiver apenas uma interface de rede, ainda será necessário criar um pool de nós com várias redes ativadas.
Se o nó contiver a interface da rede que você está configurando, mas não for visto na anotação de status da rede, verifique os recursos Network e GKENetworkParamSet (GNP).

Verifique os recursos `Network` e `GKENetworkParamSet`

O status dos recursos Network e GKENetworkParamSet (GNP) inclui um campo de condições para relatar erros de configuração. Recomendamos verificar o GNP primeiro, porque ele não depende de outro recurso para ser válido.

Para inspecionar o campo de condições, execute o seguinte comando:

kubectl get gkenetworkparamsets GNP_NAME -o yaml

Substitua GNP_NAME pelo nome do recurso GKENetworkParamSet.

Quando a condição Ready for igual a "true", a configuração será válida e a saída será semelhante a esta:

apiVersion: networking.gke.io/v1
kind: GKENetworkParamSet
...
spec:
  podIPv4Ranges:
    rangeNames:
    -   sec-range-blue
  vpc: dataplane
  vpcSubnet: subnet-dp
status:
  conditions:
  -   lastTransitionTime: "2023-06-26T17:38:04Z"
    message: ""
    reason: GNPReady
    status: "True"
    type: Ready
  networkName: dp-network
  podCIDRs:
    cidrBlocks:
    -   172.16.1.0/24

Quando a condição Ready é igual a falso, a saída exibe o motivo e é semelhante a esta:

apiVersion: networking.gke.io/v1
kind: GKENetworkParamSet
...
spec:
  podIPv4Ranges:
    rangeNames:
    -   sec-range-blue
  vpc: dataplane
  vpcSubnet: subnet-nonexist
status:
  conditions:
  -   lastTransitionTime: "2023-06-26T17:37:57Z"
    message: 'subnet: subnet-nonexist not found in VPC: dataplane'
    reason: SubnetNotFound
    status: "False"
    type: Ready
  networkName: ""

Se você encontrar uma mensagem semelhante, verifique se seu NPS foi configurado corretamente. Se já estiver, verifique se a configuração de rede do Google Cloud está correta. Depois de atualizar a configuração de rede do Google Cloud, talvez seja necessário recriar o recurso GNP para acionar manualmente uma ressincronização. Isso evita a pesquisa infinita da API do Google Cloud.

Quando o PIB estiver pronto, verifique o recurso Network.

kubectl get networks NETWORK_NAME -o yaml

Substitua NETWORK_NAME pelo nome do recurso Network.

A saída de uma configuração válida é semelhante a esta:

apiVersion: networking.gke.io/v1
kind: Network
...
spec:
  parametersRef:
    group: networking.gke.io
    kind: GKENetworkParamSet
    name: dp-gnp
  type: L3
status:
  conditions:
  -   lastTransitionTime: "2023-06-07T19:31:42Z"
    message: ""
    reason: GNPParamsReady
    status: "True"
    type: ParamsReady
  -   lastTransitionTime: "2023-06-07T19:31:51Z"
    message: ""
    reason: NetworkReady
    status: "True"
    type: Ready

reason: NetworkReady indica que o recurso de rede está configurado corretamente. reason: NetworkReady não implica que o recurso de rede está necessariamente disponível em um nó específico ou está sendo usado ativamente.
Se houver um erro de configuração ou erro, o campo reason na condição especificará o motivo exato do problema. Nesses casos, ajuste a configuração de acordo.
O GKE preencherá o campo ParamsReady se o campo parametersRef for definido como um recurso GKENetworkParamSet existente no cluster. Se você especificou um GKENetworkParamSet typeRef e a condição não estiver aparecendo, verifique se o nome, o tipo e o grupo correspondem ao recurso GNP existente no cluster.

Configurar o suporte a várias redes para pods

Requisitos e limitações

Requisitos

Limitações gerais

Limitações do kit de desenvolvimento de plano de dados e dispositivos (DPDK)

Limitações de escalonamento

Preços

Implantar pods de várias redes

Antes de começar

Preparar uma VPC adicional

Crie uma rede VPC que ofereça suporte a um dispositivo do tipo Layer 3

gcloud

Console

Crie uma rede VPC compatível com dispositivos do tipo Netdevice ou DPDK

gcloud

Console

Criar um cluster do GKE com recursos de várias redes

Criar um cluster do GKE Autopilot com recursos de várias redes

Criar um cluster do GKE Standard com recursos de várias redes

gcloud

Console

Criar um pool de nós do GKE Standard conectado a outras VPCs

gcloud

Console

Criar rede do pod

Configurar a rede VPC Layer 3

YAML

Console

Configurar rede DPDK

YAML

Console

Configurar rede netdevice

YAML

Console

Como configurar rotas de rede

YAML

Console

Consulte a Network preparada

Conectar o pod a redes específicas

Conectar o pod com várias redes

Verificação

Resolver problemas de parâmetros de várias redes no GKE

Resolver problemas na criação de redes do Kubernetes

Verificar se o nó pode acessar a rede

Verifique os recursos Network e GKENetworkParamSet

A seguir

Crie uma rede VPC que ofereça suporte a um dispositivo do tipo `Layer 3`

Crie uma rede VPC compatível com dispositivos do tipo `Netdevice` ou `DPDK`

Configurar a rede VPC `Layer 3`

Consulte a `Network` preparada

Verifique os recursos `Network` e `GKENetworkParamSet`