Sobre o suporte a várias redes para pods

Este documento descreve o suporte a várias redes para pods, incluindo casos de uso, conceitos relevantes, terminologia e benefícios.

Visão geral

OGoogle Cloud aceita várias interfaces de rede no nível da instância de máquina virtual (VM). É possível conectar uma VM a até oito redes com várias interfaces de rede, incluindo a rede padrão e mais sete redes adicionais.

A rede do Google Kubernetes Engine (GKE) estende os recursos de várias redes para pods executados nos nós. Com o suporte a várias redes para pods, é possível ativar várias interfaces em nós e pods em um cluster do GKE. O suporte a várias redes para pods remove a limitação de interface única para pools de nós, o que limitou os nós a uma única VPC para rede.

Para usar o suporte a várias redes para seus pods e nós, consulte Configurar o suporte a várias redes para pods.

Terminologia e conceitos

Esta página usa os seguintes conceitos:

VPC principal: a VPC principal é uma VPC pré-configurada que inclui um conjunto de configurações e recursos padrão. O cluster do GKE é criado nessa VPC. Se você excluiu a VPC pré-configurada, especifique uma VPC existente ao criar um cluster do GKE.

Sub-rede: em Google Cloud, uma sub-rede é a maneira de criar roteamento entre domínios sem classe (CIDR) com máscaras de rede em uma VPC. Uma sub-rede tem um único intervalo de endereços IP principal que é atribuído aos nós e pode ter vários intervalos secundários que podem pertencer a pods e serviços.

Rede-nó: refere-se a uma combinação dedicada de um par de VPC e sub-rede. Nessa rede de nós, os nós pertencentes ao pool são endereços IP alocados do intervalo de endereços IP principal.

Intervalo secundário: um intervalo secundário Google Cloud é um CIDR e uma máscara de rede que pertencem a uma sub-rede. O GKE usa isso como uma rede de pod de camada 3. Um pod pode se conectar a várias redes de pods.

Pod-network: um objeto de rede que serve como ponto de conexão para os pods. A conexão pode ser do tipo Layer 3 ou do tipo Device. É possível configurar redes do tipo Device no modo netdevice ou no kit de desenvolvimento de plano de dados (DPDK, na sigla em inglês).

Layer 3 redes correspondem a um intervalo secundário em uma sub-rede. A rede Device corresponde a uma sub-rede em uma VPC. O modelo de dados para a rede de pods em várias redes do GKE é o seguinte:

  • Para a rede Layer 3: VPC -> Nome da sub-rede -> Nome do intervalo secundário

  • Para a rede Device: VPC -> Nome da sub-rede

Rede de pods padrão:o Google Cloud cria uma rede de pods padrão durante a criação do cluster. A rede de pods padrão usa a VPC principal como a rede do nó. Por padrão, a rede de pods padrão está disponível em todos os nós e pods do cluster.

Pods com várias interfaces: não é possível conectar várias interfaces aos mesmos pods à mesma rede.

O diagrama a seguir mostra uma arquitetura típica de cluster do GKE com redes Layer 3:

Arquitetura de cluster do GKE com redes de camada 3

Para redes do tipo Device, que podem ser configuradas no modo netdevice ou DPDK, a vNIC da VM é gerenciada como um recurso e transmitida para o pod. Nesse caso, a rede do pod é mapeada diretamente para a rede do nó. Intervalos secundários não são obrigatórios para redes do tipo Device.

Redes de pods e nós

Casos de uso

O suporte a várias redes para pods aborda os seguintes casos de uso:

  • Implantar funções de rede em contêiner: se você executar as funções de rede em contêineres, que têm planos de gerenciamento e dados separados. A multirrede para pods isola redes para diferentes planos do usuário, alto desempenho ou baixa latência de interfaces específicas ou multilocação no nível da rede. Isso é necessário para conformidade, QoS e segurança.
  • Conectar a VPC dentro da mesma organização e projeto:você quer criar clusters do GKE em uma VPC e precisa se conectar a serviços em outra VPC. É possível usar a opção de nodes multi-NIC para conectividade direta. Isso pode ocorrer devido a um modelo hub e spoke, em que um serviço centralizado (geração de registros, autenticação) opera em uma VPC de hub e os spokes exigem conectividade privada para acessá-lo. É possível usar o suporte de várias redes para pods para conectar os pods em execução no cluster do GKE diretamente à VPC hub.
  • Executar aplicativos DPDK com VFIO:você quer executar aplicativos DPDK que exigem acesso ao NIC no nó por meio do driver VFIO. É possível conseguir a taxa de pacotes ideal ignorando completamente o kernel, o Kubernetes e o GKE Dataplane V2.
  • Ative o acesso direto à vNIC ignorando o Kubernetes e o GKE Dataplane V2:execute as funções de rede em contêineres que exigem acesso direto à placa de rede (NIC) no nó. Por exemplo, aplicativos de computação de alto desempenho (HPC) que querem ignorar o Kubernetes e o GKE Dataplane V2 para conseguir a menor latência. Alguns aplicativos também querem acessar as informações de topologia de PCIe da placa de rede para se colocalizar com outros dispositivos, como GPU.
  • Exponha cargas de trabalho em redes secundárias usando balanceadores de carga: é possível usar balanceadores de carga de rede de passagem externa e interna para expor cargas de trabalho (como funções de rede em contêineres) diretamente em VPCs secundárias. Isso permite que você forneça acesso aos aplicativos em interfaces de rede específicas sem usar a rede padrão do cluster.

Vantagens

O suporte a várias redes para pods oferece os seguintes benefícios:

  • Isolamento de tráfego: o suporte a várias redes para pods permite isolar o tráfego em um cluster do GKE. É possível criar pods com várias interfaces de rede para separar o tráfego com base na capacidade, como gerenciamento e plano de dados, em pods que executam funções de rede conteinerizadas (CNFs, na sigla em inglês).
  • Mutação dupla: permite que um pod tenha várias interfaces e direcione o tráfego para VPCs diferentes, permitindo que o pod estabeleça conexões com uma VPC primária e uma secundária. Se uma VPC tiver problemas, o aplicativo poderá recorrer à VPC secundária.
  • Segmentação de rede: os pods podem se conectar a redes internas ou externas com base nas necessidades da carga de trabalho. Dependendo dos requisitos específicos das cargas de trabalho, escolha quais pods ou grupos de pods se conectam a cada rede. Por exemplo, você pode usar uma rede interna para a comunicação leste-oeste e uma rede externa para acesso à Internet. Isso permite que você personalize a conectividade de rede das cargas de trabalho com base nas necessidades específicas delas.
  • Desempenho ideal com DPDK: o suporte a várias redes para pods no GKE permite que aplicativos DPDK sejam executados em pods do GKE, o que oferece um desempenho ideal do processamento de pacotes.
  • NIC de host diretamente disponível no pod: o suporte de placa de rede (NIC) do modo netdevice com várias redes transmite a placa de rede (NIC) da VM diretamente para o pod, ignorando o Kubernetes e o GKE Dataplane V2. Isso pode atingir a menor latência para colaboração entre dispositivos.
  • Performance: para melhorar o desempenho dos aplicativos, conecte-os à rede que for mais adequada às necessidades deles.
  • Balanceamento de carga em várias redes: o suporte a várias redes para pods permite provisionar balanceadores de carga de rede de passagem externa e interna para serviços em redes secundárias. Google Cloud Isso permite expor seus aplicativos a clientes em VPCs específicas, mantendo um isolamento de rede estrito entre suas cargas de trabalho.

A seguir