Rede no Kubernetes do Operador do Nexus do Azure

Uma instância do Operador do Nexus do Azure, ou simplesmente Nexus do Operador, é composta por hardware de computação e rede instalado nas instalações do cliente. Várias camadas de dispositivos físicos e virtuais fornecem serviços de conectividade de rede e roteamento para as cargas de trabalho em execução neste hardware de computação. Este documento fornece uma descrição detalhada de cada uma dessas camadas de rede.

Topologia

Aqui, descrevemos a topologia do hardware em uma instância do Operator Nexus.

Os clientes possuem e gerenciam roteadores de Borda de Provedor (PE). Esses roteadores representam a borda da rede de backbone do cliente.

O Nexus do Operador gerencia os roteadores CE (borda do cliente). Esses roteadores fazem parte da instância do Operator Nexus e estão incluídos na lista de materiais (BOM) de hardware de borda. Há dois roteadores CE em cada instância do Nexus do Operador de vários racks. Cada roteador CE tem um uplink para cada um dos roteadores PE. Os roteadores CE são os únicos dispositivos do Operador Nexus que estão fisicamente conectados à rede do cliente.

Cada rack de servidores de computação em uma instância multi-rack do Nexus do Operador do Azure tem duas opções TOR (top-of-rack). Cada TOR tem um uplink para cada um dos roteadores CE. Cada TOR é conectado a cada servidor de computador bare-metal no rack e é configurado como um comutador de camada 2 simples.

Computador bare-metal

As cargas de trabalho de locatário em execução nessa infraestrutura de computação normalmente são funções de rede virtual ou em contêineres. Funções de rede virtual (VNFs) são executadas como VMs (máquinas virtuais) no hardware do servidor de computação. Funções de rede conteinerizadas (CNFs) são executadas dentro de contêineres. Esses contêineres são executados em VMs que são executadas no hardware do servidor de computação.

As funções de rede que fornecem serviços de plano de dados do usuário final exigem interfaces de rede de alto desempenho que oferecem recursos avançados e altas taxas de E/S.

Em instâncias do Operador do Nexus multi-rack de borda próxima, cada servidor de computação bare-metal é um computador de soquete duplo com arquitetura Acesso à Memória Não Uniforme (NUMA).

Um servidor de computador bare-metal em uma instância do Operador do Nexus do Azure multi-rack de borda próxima contém um cartão de interface de rede de porta dupla (pNIC) para cada célula NUMA. Esses pNICs dão suporte à Virtualização de E/S de Raiz Única (SR-IOV) e a outros recursos de alto desempenho. Uma célula NUMA é a memória e a CPU alinhadas com um pNIC.

Todas as interfaces de rede atribuídas a cargas de trabalho de locatário são dispositivos de passagem de host e usam funções virtuais (VFs) SR-IOV alocadas do pNIC alinhado à célula NUMA que abriga os recursos de CPU e memória da VM de carga de trabalho. Essa disposição garante o desempenho ideal da pilha de rede dentro das VMs e contêineres atribuídos a esses VFs.

Os racks de computação são implantados com um par de comutadores Top-of-Rack (TOR). Cada pNIC em cada servidor de computação bare-metal está conectado a ambos os TORs. O grupo de agregação de link de vários chassis (MLAG) fornece alta disponibilidade e o protocolo de controle de agregação de link (LACP) fornece maior taxa de transferência agregada para o link.

Cada servidor de computador bare-metal tem uma interface de rede de armazenamento fornecida por um vínculo que agrega duas funções virtuais (VFsl) de host local (em vez de VFs locais de VM) conectadas a ambos os pNICs. Esses dois VFs são agregados em um vínculo de backup ativo para garantir que, se um dos pNICs falhar, a conectividade de armazenamento de rede permanecerá disponível.

Recursos de rede lógica

Ao interagir com as APIs Operator Nexus Network Cloud e Managed Network Fabric, os usuários criam e modificam um conjunto de recursos lógicos.

Os recursos lógicos na API do Managed Network Fabric correspondem às redes e à configuração de controle de acesso no hardware de rede subjacente (os TORs e CEs). Notavelmente, os recursos ManagedNetworkFabric.L2IsolationDomain e ManagedNetworkFabric.L3IsolationDomain contêm comutador de baixo nível e configuração de rede. Um ManagedNetworkFabric.L2IsolationDomain representa um identificador de rede local virtual (VLAN). Um ManagedNetworkFabric.L3IsolationDomain representa uma configuração de roteamento e encaminhamento virtual (VRF) nos roteadores CE. Leia sobre o conceito de um Domínio de Isolamento.

Os recursos lógicos na API de Nuvem de Rede correspondem à infraestrutura de computação. Há recursos para racks físicos e hardware bare-metal. Da mesma forma, há recursos para clusters do Kubernetes e máquinas virtuais que são executados nesse hardware e nas redes lógicas que os conectam.

NetworkCloud.L2Network, NetworkCloud.L3Network e NetworkCloud.TrunkedNetwork representam redes de carga de trabalho, o que significa que o tráfego nessas redes destina-se a cargas de trabalho de locatário.

Um NetworkCloud.L2Network representa uma rede de camada 2 e contém pouco mais do que um link para um ManagedNetworkFabric.L2IsolationDomain. Esse L2IsolationDomain contém um identificador de VLAN e uma configuração de unidade de transmissão máxima (MTU).

Um NetworkCloud.L3Network representa uma rede de camada 3 e contém um identificador de VLAN, informações sobre a atribuição de endereço IP para pontos de extremidade na rede e um link para um ManagedNetworkFabric.L3IsolationDomain.

Observação

Por que um recurso NetworkCloud.L3Network contém um identificador de VLAN? As VLANs não são um conceito de camada 2?

Sim, sim, elas são! O motivo disso se deve ao fato de que NetworkCloud.L3Network deve ser capaz de se referir a um determinado ManagedNetworkFabric.InternalNetwork. ManagedNetworkFabric.InternalNetworks são criados dentro de um ManagedNetworkFabric.L3IsolationDomain específico e recebem um identificador VLAN. Portanto, para fazer referência a um ManagedNetworkFabric.InternalNetwork específico, o NetworkCloud.L3Network deve conter um identificador L3IsolationDomain e um identificador de VLAN.

Recursos lógicos de rede na API de Nuvem de Rede, como os recursos lógicos de NetworkCloud.L3Networkreferência na API do Managed Network Fabric, que, ao fazê-lo, fornecem uma conexão lógica entre a infraestrutura física de computação e a infraestrutura física de rede.

Ao criar uma Máquina Virtual Nexus, você pode especificar zero ou mais Redes L2, L3 e Tronco no NetworkAttachments da Máquina Virtual Nexus. Ao criar um cluster Kubernetes do Nexus, você pode especificar zero ou mais redes L2, L3 e redes em tronco no campo NetworkConfiguration.AttachedNetworkConfiguration do cluster Kubernetes do Nexus. AgentPools são coleções de nós de trabalho do Kubernetes semelhantes em um Cluster do Kubernetes do Nexus. Você pode configurar as Redes L2, L3 e Trunked anexadas de cada Pool de Agentes no campo do AttachedNetworkConfiguration do AgentPool.

Você pode compartilhar redes entre Máquinas Virtuais Autônomas do Nexus e Clusters do Nexus Kubernetes. Essa composição permite que você una CNFs e VNFs que trabalham em conjunto nas mesmas redes lógicas.

O diagrama mostra um exemplo de um Cluster do Kubernetes do Nexus com dois pools de agentes e uma Máquina Virtual Nexus autônoma conectada a diferentes redes de carga de trabalho. O Pool de Agentes "AP1" não tem nenhuma configuração de rede extra e, portanto, herda as informações de rede do KubernetesCluster. Observe também que todos os nós do Kubernetes e todas as máquinas virtuais autônomas do Nexus estão configuradas para se conectar à mesma rede de serviços em nuvem. Por fim, o Pool de Agentes "AP2" e a VM autônoma são configurados para se conectar a uma "Rede L3 Compartilhada".

A Rede de Serviços em Nuvem

As Máquinas Virtuais do Nexus e os Clusters do Kubernetes do Nexus sempre fazem referência a algo chamado Rede de Serviços de Nuvem (CSN) O CSN é uma rede especial usada para o tráfego entre cargas de trabalho locais e um conjunto de pontos de extremidade externos ou hospedados no Azure.

O tráfego no CloudServicesNetwork é roteado por meio de um proxy, em que o tráfego de saída é controlado por meio do uso de uma lista de permissões. Os usuários podem ajustar essa lista de permissões usando a API de Nuvem de Rede.

A Rede CNI

Ao criar um Cluster Kubernetes do Nexus, você fornece o identificador de recurso de um NetworkCloud.L3Network no campo NetworkConfiguration.CniNetworkId.

Essa "rede CNI", às vezes conhecida como "Rede DefaultCNI", especifica a rede de camada três que fornece endereços IP para nós do Kubernetes no cluster Nexus Kubernetes.

O diagrama mostra as relações entre alguns dos recursos lógicos de Nuvem de Rede, Malha de Rede Gerenciada e Kubernetes. No diagrama, um NetworkCloud.L3Network é um recurso lógico na API de Nuvem de Rede que representa uma rede de camada 3. O recurso NetworkCloud.KubernetesCluster tem um campo networkConfiguration.cniNetworkId que contém uma referência ao recursoNetworkCloud.L3Network.

O NetworkCloud.L3Network recurso está associado a um único recurso ManagedNetworkFabric.InternalNetwork por meio de seus campos l3IsolationDomainId e vlanId. O recurso ManagedNetworkFabric.L3IsolationDomain contém um ou mais recursos ManagedNetworkFabric.InternalNetwork, identificados por vlanId. Quando o usuário cria o recurso NetworkCloud.KubernetesCluster, um ou mais recursos NetworkCloud.AgentPool são criados.

Cada um desses recursos NetworkCloud.AgentPool é composto por uma ou mais máquinas virtuais. Um recurso Node do Kubernetes representa cada uma dessas máquinas virtuais. Esses recursos Node do Kubernetes devem obter um endereço IP e os plug-ins da CNI (Interface de Rede de Contêiner) nas máquinas virtuais obtêm um endereço IP do pool de endereços IP associados ao NetworkCloud.L3Network. O recurso NetworkCloud.KubernetesCluster faz referência ao NetworkCloud.L3Network por meio do campo cniNetworkId. As regras de roteamento e acesso para esses endereços IP no nível do nó estão contidas no ManagedNetworkFabric.L3IsolationDomain. O NetworkCloud.L3Network refere-se ao campo ManagedNetworkFabric.L3IsolationDomain por meio do campo l3IsoldationDomainId.

Rede de Kubernetes do Operador Nexus

Há três camadas lógicas de rede no Kubernetes:

• Camada de rede do nó
• Camada de rede de pod
• Camada de interconexão de serviços

A Camada de rede do Nó fornece conectividade entre o plano de controle do Kubernetes e o agente de nó de trabalho do kubelet.

A Camada de rede pod fornece conectividade entre contêineres (Pods) em execução dentro do Cluster do Kubernetes do Nexus e conectividade entre um Pod e uma ou mais redes definidas pelo locatário.

A Camada de rede de serviço fornece funcionalidade de balanceamento de carga e entrada para conjuntos de Pods relacionados.

Rede de nós

Os clusters Kubernetes do Operador Nexus abrigam uma ou mais funções de rede containerizadas (CNFs) que são executadas em uma máquina virtual (VM). Um Nó do Kubernetes representa uma única VM. Os Nós do Kubernetes podem ser Nós do Painel de Controle ou Nós de Trabalho. Os nós do plano de controle contêm componentes de gerenciamento para o Cluster do Kubernetes. Cargas de trabalho de locatário da casa dos Nós de Trabalho.

Grupos de nós de trabalho do Kubernetes são chamados de Pools de Agentes. Os Pools de agentes são uma construção do Nexus do Operador, não uma construção do Kubernetes.

Cada servidor de computação bare-metal em uma instância do Operator Nexus tem um switchdev que é afiado para uma única célula NUMA no servidor bare-metal. O switchdev abriga um conjunto de portas de representador de VF SR-IOV que fornecem conectividade a um conjunto de dispositivos de ponte que são usados para abrigar tabelas de roteamento para redes diferentes.

Além da interface defaultcni, o Nexus do Operador estabelece uma interface de rede cloudservices em cada Nó. A interface de rede cloudservices é responsável por rotear o tráfego destinado a pontos de extremidade externos (fora das instalações do cliente). A interface de rede cloudservices corresponde ao recurso de API NetworkCloud.CloudServicesNetwork que o usuário define antes de criar um cluster Nexus Kubernetes. O endereço IP atribuído à interface de rede cloudservices é um endereço local de link, garantindo que o tráfego de rede externo sempre percorra essa interface específica.

Além das interfaces de rede defaultcni e cloudservices, o Operador Nexus cria uma ou mais interfaces de rede em cada Nó do Kubernetes que correspondem a associações NetworkCloud.L2Network, NetworkCloud.L3Network e NetworkCloud.TrunkedNetwork com o Cluster do Kubernetes ou AgentPool do Nexus.

Somente as VMs do Pool de Agentes têm essas interfaces de rede extras. As VMs do Painel de Controle têm apenas as interfaces de rede defaultcni e cloudservices.

Gerenciamento de Endereço de IP (IPAM)

Nodos em um Pool de Agentes recebem um endereço IP de uma lista de endereços IP associados ao recurso NetworkCloud.L3Network mencionado no campo NetworkCloud.KubernetesCluster do recurso networkConfiguration.cniNetworkId. Essa rede defaultcni é o gateway padrão para todos os Pods que são executados nesse nó e servem como a rede padrão para a comunicação de Pod para Pod leste-oeste no Cluster do Kubernetes do Nexus.

Rede de pods

Os Pods do Kubernetes são coleções de uma ou mais imagens de contêiner que são executadas em um namespace do Linux. Esse namespace do Linux isola os processos e recursos do contêiner de outros contêineres e processos no host. Qiuato aos Clusters do Kubernetes do Nexus, esse "host" é uma VM representada como um nó de trabalho do Kubernetes.

Antes de criar um Cluster Kubernetes do Operator Nexus, os usuários primeiro criam um grupo de recursos que representam as redes virtuais das quais as cargas de trabalho dos clientes recebem endereços. Essas redes virtuais são então referenciadas nos campos cniNetworkId, cloudServicesNetworkId, agentPoolL2Networks, agentPoolL3Networks e agentPoolTrunkedNetworks ao criar o Cluster Kubernetes do Operador Nexus.

Os pods podem ser executados em qualquer servidor de computação em qualquer rack em uma instância do Operator Nexus. Por padrão, todos os Pods em um Cluster do Kubernetes do Nexus podem se comunicar entre si pelo que é conhecido como a rede de pods. Vários plug-ins da Interface de Rede de Contêiner (CNI) instalados em cada nó de trabalho do Nexus Kubernetes gerenciam a rede pod.

Redes extras

Ao criar um Pod em um Cluster do Kubernetes do Nexus, você declara todas as redes extras às quais o Pod deve ser anexado especificando uma anotação k8s.v1.cni.cnf.io/networks. O valor da anotação é uma lista delimitada por vírgulas de nomes de rede. Esses nomes de rede correspondem aos nomes de todas as Redes Trunked, L3 ou L2 associadas ao Cluster do Kubernetes do Nexus ou ao Pool de Agentes.

O Operador Nexus configura a VM do Pool de Agentes com arquivos NetworkAttachmentDefinition (NAD) que contêm a configuração de rede para uma rede extra única.

Para cada rede tronco listada nas redes associadas do Pod, o Pod obtém um único adaptador de rede. A carga de trabalho é responsável por enviar tráfego marcado bruto por essa interface ou construir interfaces marcadas na parte superior da interface de rede.

Para cada rede L2 listada nas redes associadas do Pod, o Pod obtém uma única interface de rede. A carga de trabalho é responsável por seu próprio endereçamento MAC estático.

Gerenciamento de Endereço IP do Pod

Ao criar um cluster do Nexus Kubernetes, especifique os intervalos de endereços IP para a rede de pods no campo podCidrs. Quando os Pods são iniciados, o plug-in CNI estabelece uma interface eth0@ifXX no Pod e atribui um endereço IP de um intervalo de endereços IP nesse campo podCidrs.

Para redes L3, se a rede tiver sido configurada para usar o NEXUS IPAM, a interface de rede do Pod associada à Rede L3 receberá um endereço IP do intervalo de endereços IP (CIDR) configurado para essa rede. Se a Rede L3 não estiver configurada para usar o NEXUS IPAM, a carga de trabalho será responsável por atribuir estaticamente um endereço IP ao adaptador de rede do Pod.

Roteamento

Em cada Pod, o tráfego da interface do eth0 atravessa um dispositivo de ethernet virtual (veth) que se conecta a um switchdev no host (a VM) que abriga o defaultcni, cloudservices e outras interfaces no nível do Nó.

A interface eth0 em um Pod tem uma tabela de rotas simples que usa efetivamente a tabela de rotas da VM do nó de trabalho para qualquer um dos tráfegos a seguir.

• Tráfego de pod a pod: o tráfego destinado a um IP nos intervalos de endereços do podCidrs flui para o switchdev na VM do host e sobre a interface defaultcni no Nível do Nó em que ele é roteado para o endereço de IP do pool de agentes de destino apropriado.
• Tráfego de rede L3 OSDevice: o tráfego destinado a um IP em uma rede L3 associada com o tipo de plug-in OSDevice flui para o switchdev na VM do host e pela interface no nível do nó associada à rede L3.
• Todo o outro tráfego passa para o gateway padrão no Pod, que roteia para a interface cloudservices no Nível do Nó. As regras de saída configuradas no CloudServicesNetwork associado ao cluster Nexus Kubernetes determinam como o tráfego deve ser roteado.

Interfaces de rede adicionais dentro de um Pod usarão a tabela de rotas do Pod para rotear o tráfego para redes L3 adicionais que usam os tipos de plugin SRIOV e DPDK.

Configuração de BFD e BGP da CNI

Configuração padrão do BFD

Os parâmetros de Detecção de Encaminhamento Bidirecional (BFD) podem ser configurados para cada emparelhamento BGP. Os temporizadores BFD são negociados entre os clusters do Kubernetes do Operador Nexus e o roteador par. O valor de temporizador mais alto entre os dois roteadores é selecionado, que é o comportamento BFD padrão. Os clusters do Kubernetes do Nexus usam os seguintes valores

• Intervalo: 300ms
• Multiplicador: 3
  Se o BFD não estiver habilitado no roteador par, uma sessão não será estabelecida.

Configurações de BGP padrão

OS temporizadores Border Gateway Protocol (BGP) são negociados entre os clusters do Kubernetes do Operador Nexus e o roteador par. O menor valor de temporizador de retenção entre os dois roteadores é selecionado, que é o comportamento padrão do BGP. Os clusters do Kubernetes do Nexus usam os seguintes valores

• tempo de espera: 240 segundos de espera
• Intervalo de keep-alive: 1/3 de tempo de espera (80s) Se uma sessão BFD também existir, o BGP aproveitará o BFD para detectar pares com falha.