Acerca do suporte de várias redes para pods

Esta página descreve o suporte de várias redes para pods, incluindo exemplos de utilização, conceitos relevantes, terminologia e vantagens.

Vista geral

Google Cloud Suporta várias interfaces de rede ao nível da instância de máquina virtual (VM). Pode ligar uma VM a até oito redes com várias interfaces de rede, incluindo a rede predefinida e mais sete redes.

A rede do Google Kubernetes Engine (GKE) estende as capacidades de várias redes aos pods que são executados nos nós. Com o suporte de várias redes para pods, pode ativar várias interfaces em nós e pods num cluster do GKE. O suporte de várias redes para pods remove a limitação de interface única para pools de nós, o que limitava os nós a uma única VPC para redes.

O Network Function Optimizer (NFO) é um serviço de rede disponível para o GKE que oferece suporte para várias redes, endereços IP persistentes e um plano de dados nativo do Kubernetes de alto desempenho. A NFO permite funções de rede em contentores no GKE. A rede múltipla é um dos pilares fundamentais da NFO.

Para usar o suporte de várias redes para os seus pods e nós, consulte o artigo Configure o suporte de 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 predefinições e recursos. O cluster do GKE é criado nesta VPC. Se eliminar a VPC pré-configurada, o cluster do GKE é criado na VPC principal.

Sub-rede: no Google Cloud, uma sub-rede é a forma de criar Classless Inter-Domain Routing (CIDR) com máscaras de rede numa 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.

Node-network: a node-network refere-se a uma combinação dedicada de um par de VPC e sub-rede. Nesta rede de nós, os nós pertencentes ao conjunto de nós têm endereços IP atribuídos a partir do intervalo de endereços IP principal.

Intervalo secundário: um intervalo secundário é um CIDR e uma máscara de rede pertencentes a uma sub-rede. Google Cloud O GKE usa isto como uma rede de pods de camada 3. Um Pod pode estabelecer ligação a várias redes de Pods.

Pod-network: um objeto de rede que funciona como um ponto de ligação para pods. A associação pode ser do tipo Layer 3 ou do tipo Device. Pode configurar redes do tipo Device em netdevice ou no modo Data Plane Development Kit (DPDK).

As redes Layer 3 correspondem a um intervalo secundário numa sub-rede. Device de rede corresponde a uma sub-rede numa VPC. O modelo de dados para a rede de pods na rede múltipla do GKE é o seguinte:

  • Para Layer 3 Network: VPC -> Subnet Name -> Secondary Range Name

  • Para Device Network: VPC -> Subnet Name

Default Pod-network: Google Cloud cria uma rede de pods predefinida durante a criação do cluster. A rede de pods predefinida usa a VPC principal como a rede de nós. A rede de pods predefinida está disponível em todos os nós do cluster e pods por predefinição.

Pods com várias interfaces: as várias interfaces nos Pods não podem estabelecer ligação à mesma rede de Pods.

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

cluster de várias redes

Para redes com tipo Device, que podem ser configuradas no modo netdevice ou DPDK, a vNIC da VM é gerida como um recurso e transmitida ao pod. Neste caso, os mapas de rede de pods correspondem diretamente à rede de nós. Os intervalos secundários não são necessários para redes com tipos Device.

Redes de pods e nós

Exemplos de utilização

O suporte de várias redes para agrupamentos resolve os seguintes exemplos de utilização:

  • Implemente funções de rede em contentores: se executar as funções de rede em contentores, que têm planos de gestão e dados separados. Várias redes para pods isola redes para diferentes planos de utilizadores, alto desempenho ou baixa latência de interfaces específicas ou multi-inquilino ao nível da rede. Isto é necessário para a conformidade, a QoS e a segurança.
  • Ligar a VPC na mesma organização e projeto: quer criar clusters do GKE numa VPC e precisa de estabelecer ligação a serviços noutra VPC. Pode usar a opção de nós com várias interfaces de rede para a conetividade direta. Isto pode dever-se a um modelo de hub e raios, no qual um serviço centralizado (registo, autenticação) opera numa VPC de hub, e os raios requerem conetividade privada para aceder ao mesmo. Pode usar o suporte de várias redes para pods para ligar os pods em execução no cluster do GKE diretamente à VPC do hub.
  • Executar aplicações DPDK com VFIO: quer executar aplicações DPDK que requerem acesso à NIC no nó através do controlador VFIO. Pode alcançar 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: executa as funções de rede em contentores que requerem acesso direto à placa de interface de rede (NIC) no nó. Por exemplo, aplicações de computação de alto desempenho (HPC) que querem ignorar o Kubernetes e o GKE Dataplane V2 para alcançar a latência mais baixa. Algumas aplicações também querem aceder às informações de topologia PCIe da NIC para a colocar juntamente com outros dispositivos, como a GPU.

Vantagens

O suporte de várias redes para os pods oferece as seguintes vantagens:

  • Isolamento do tráfego: o suporte de várias redes para pods permite-lhe isolar o tráfego num cluster do GKE. Pode criar pods com várias interfaces de rede para separar o tráfego com base na capacidade, como a gestão e o plano de dados, em pods que executam funções nativas da nuvem (CNFs) específicas.
  • Dual homing: o dual homing permite que um pod tenha várias interfaces e encaminhe o tráfego para diferentes VPCs, permitindo que o pod estabeleça ligações com uma VPC principal e uma secundária. Se uma VPC tiver problemas, a aplicação pode recorrer à VPC secundária.
  • Segmentação de rede: os pods podem ligar-se a redes internas ou externas com base nas necessidades da carga de trabalho. Consoante os requisitos específicos das suas cargas de trabalho, pode escolher que pods ou grupos de pods se ligam a cada rede. Por exemplo, pode usar uma rede interna para comunicação leste-oeste e uma rede externa para acesso à Internet. Isto permite-lhe personalizar a conetividade de rede das suas cargas de trabalho com base nas respetivas necessidades específicas.
  • Desempenho ideal com DPDK: o suporte de várias redes para pods no GKE permite que as aplicações DPDK sejam executadas em pods do GKE, o que oferece um desempenho de processamento de pacotes ideal.
  • NIC do anfitrião diretamente disponível no pod: o suporte de NIC no modo netdevice passa a NIC da VM diretamente para o pod, ignorando o Kubernetes e o GKE Dataplane V2. Isto permite alcançar a latência mais baixa para a colaboração entre dispositivos.
  • Desempenho: para melhorar o desempenho das suas aplicações, pode associá-las à rede mais adequada às necessidades das aplicações.

O que se segue?