Conectividade no Azure Operator Nexus Kubernetes

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

Topology

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

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

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

Cada estante de servidores de computação numa instância do Azure Operator Nexus com múltiplas estantes possui dois switches top-of-rack (TOR). Cada TOR tem um uplink para cada um dos roteadores CE. Cada TOR é conectado a cada servidor de computação bare metal no rack e é configurado como um switch de camada 2 simples.

Bare metal

As cargas de trabalho de locatário em execução nessa infraestrutura de computação geralmente são funções de rede virtuais ou conteinerizadas. As funções de rede virtual (VNFs) são executadas como máquinas virtuais (VMs) no hardware do servidor de computação. As 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 para o usuário final exigem interfaces de rede de alto desempenho que oferecem recursos avançados e altas taxas de E/S.

Em instâncias Nexus de operador multirack de borda próxima, cada servidor de computação bare metal é uma máquina de soquete duplo com arquitetura NUMA ( Non-Uniform Memory Access ).

Um servidor físico de computação em uma instância Azure Operator Nexus próximo ao edge com múltiplos racks contém uma NIC de porta dupla (pNIC) para cada célula NUMA. Essas pNICs suportam Virtualização de E/S de Raiz Única (SR-IOV) e outros recursos de alto desempenho. Uma célula NUMA é alinhada em memória e CPU com uma única pNIC.

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

Os racks de servidores são implantados juntamente com um par de switches conhecidos como Top-of-Rack (TOR). Cada pNIC em cada servidor de computação "bare metal" está ligado a ambos os TORs. O MLAG (Multi-chassis link aggregation group ) 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 computação bare metal tem uma interface de rede de armazenamento que é fornecida por uma ligação que agrega duas funções virtuais (VF) host-local (em oposição a VM-local VFs) conectadas a ambos os pNICs. Esses dois VFs estão agregados numa conexão de backup ativo para garantir que, se uma das pNICs falhar, a conectividade com o armazenamento de rede permaneça disponível.

Recursos lógicos de rede

Ao interagir com a API do Operator Nexus Network Cloud e as APIs do 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 à configuração de redes e controle de acesso no hardware de rede subjacente (os TORs e CEs). É importante notar que os recursos ManagedNetworkFabric.L2IsolationDomain e ManagedNetworkFabric.L3IsolationDomain contêm configuração de switch e de rede de baixo nível. A ManagedNetworkFabric.L2IsolationDomain representa um identificador de rede local virtual (VLAN). A ManagedNetworkFabric.L3IsolationDomain representa uma configuração virtual de roteamento e encaminhamento (VRF) nos roteadores CE. Leia sobre o conceito de um Domínio de Isolamento.

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

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

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

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

Observação

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

Sim, sim, eles estão! A razão para tal deve-se ao facto de o NetworkCloud.L3Network dever poder referir-se a um ManagedNetworkFabric.InternalNetwork específico. ManagedNetworkFabric.InternalNetworks são criados dentro de um ManagedNetworkFabric.L3IsolationDomain específico e recebem um ID VLAN. Portanto, para fazer referência a um identificador específico ManagedNetworkFabric.InternalNetwork, o NetworkCloud.L3Network deve conter um identificador L3IsolationDomain e um identificador VLAN.

Recursos de rede lógica na API Network Cloud, como recursos lógicos de referência na API Managed Network Fabric e, assim, fornecem uma conexão lógica entre a infraestrutura de computação física e a infraestrutura de rede física.

Ao criar uma máquina virtual Nexus, pode especificar zero ou mais redes L2, L3 e troncalizadas na máquina virtual Nexus NetworkAttachments. Ao criar um cluster Nexus Kubernetes, pode-se especificar zero ou mais redes L2, L3 e Trunked no campo do Nexus Kubernetes Cluster NetworkConfiguration.AttachedNetworkConfiguration. AgentPools são coleções de nós de trabalho Kubernetes semelhantes dentro de um cluster Nexus Kubernetes. Você pode configurar as redes L2, L3 e Trunked anexadas de cada Agent Pool no campo do AttachedNetworkConfiguration AgentPool.

Você pode compartilhar redes entre máquinas virtuais Nexus autônomas e clusters Nexus Kubernetes. Essa capacidade de composição permite que você junte CNFs e VNFs trabalhando em conjunto nas mesmas redes lógicas.

O diagrama mostra um exemplo de um cluster Nexus Kubernetes 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 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 Nexus autônomas estão configuradas para se conectar à mesma rede de serviços de nuvem. Finalmente, 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 Nexus e os Clusters Nexus Kubernetes sempre fazem referência a algo chamado "Cloud Services Network" (CSN). A 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 na CloudServicesNetwork é roteado através de um proxy, onde o tráfego de saída é controlado através do uso de uma lista de permissões. Os usuários podem ajustar essa lista de permissões usando a Network Cloud API.

A Rede CNI

Ao criar um cluster Nexus Kubernetes, fornece-se o identificador de recurso de um NetworkCloud.L3Network no campo NetworkConfiguration.CniNetworkId.

Esta "rede CNI", às vezes referida como "DefaultCNI Network", especifica a rede de camada 3 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 Network Cloud, Managed Network Fabric e Kubernetes. No diagrama, a NetworkCloud.L3Network é um recurso lógico na Network Cloud API que representa uma rede de camada 3. O NetworkCloud.KubernetesCluster recurso tem um campo networkConfiguration.cniNetworkId que contém uma referência ao NetworkCloud.L3Network recurso.

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

Cada um desses NetworkCloud.AgentPool recursos compreende uma ou mais máquinas virtuais. Um recurso do Kubernetes Node representa cada uma dessas máquinas virtuais. Esses recursos do Kubernetes Node devem obter um endereço IP e os plug-ins CNI (Container Networking Interface) nas máquinas virtuais capturam um endereço IP do pool de endereços IP associados ao NetworkCloud.L3Network. O NetworkCloud.KubernetesCluster recurso faz referência ao NetworkCloud.L3Network através 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 à ManagedNetworkFabric.L3IsolationDomain através do seu campo l3IsoldationDomainId.

Operador de rede Nexus Kubernetes

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

• Camada de rede de nó
• Camada de rede de Pod
• Camada de rede de serviço

A camada de rede do Node fornece conectividade entre o plano de controle do Kubernetes e o agente do Node trabalhador do kubelet.

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

A camada de rede Service fornece balanceamento de carga e funcionalidade de entrada para conjuntos de Pods relacionados.

Rede de nós

Os clusters Nexus Kubernetes do operador abrigam uma ou mais funções de rede conteinerizadas (CNFs) que são executadas em máquinas virtuais (VM). Um nó Kubernetes representa uma única VM. Os nós do Kubernetes podem ser nós do plano de controle ou nós de trabalho . Os nós do plano de controle contêm componentes de gerenciamento para o cluster do Kubernetes. Os Worker Nodes abrigam cargas de trabalho dos inquilinos.

Os 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 é afinado a uma única célula NUMA no servidor bare metal. O switchdev aloja um conjunto de portas representadoras VF SR-IOV que fornecem conectividade a um conjunto de dispositivos ponte usados para abrigar tabelas de roteamento para diferentes redes.

Além da interface defaultcni, o Operator Nexus estabelece uma interface de rede cloudservices em cada nodo. A cloudservices interface de rede é responsável por rotear o tráfego destinado a pontos finais externos (para as instalações do cliente). A interface de rede cloudservices corresponde ao recurso de API que o utilizador define antes de criar um cluster Nexus Kubernetes. O endereço IP atribuído à interface de rede cloudservices é um endereço link-local, garantindo que o tráfego de rede externo sempre percorra esta interface específica.

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

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

Gestão de Endereço IP do Nó (IPAM)

Os nós em um Pool de Agentes recebem um endereço IP a partir de um conjunto de endereços IP associados ao recurso NetworkCloud.L3Network mencionado no campo NetworkCloud.KubernetesCluster do recurso networkConfiguration.cniNetworkId. Essa defaultcni rede é o gateway padrão para todos os Pods executados nesse nó e serve como a rede padrão para comunicação leste-oeste entre Pod dentro do cluster Nexus Kubernetes.

Rede de pods

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

Antes de criar um Cluster Kubernetes do Operator Nexus, os utilizadores devem inicialmente criar um conjunto de recursos que representam as redes virtuais de onde as cargas de trabalho dos tenants 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 Operator Nexus.

Os pods podem ser executados em qualquer servidor de computação em qualquer rack numa instância do Operator Nexus. Por padrão, todos os Pods em um cluster Nexus Kubernetes podem se comunicar uns com os outros através do que é conhecido como a rede pod. Vários plug-ins CNI ( Container Networking Interface ) instalados em cada nó de trabalho do Nexus Kubernetes gerenciam a rede do Pod.

Redes Extras

Ao criar um Pod em um cluster Nexus Kubernetes, você declara todas as redes extras às quais o Pod deve se conectar especificando uma k8s.v1.cni.cnf.io/networks anotação. O valor da anotação é uma lista delimitada por vírgulas de nomes de rede. Esses nomes de rede correspondem a nomes de quaisquer redes troncalizadas, L3 ou L2 associadas ao cluster ou pool de agentes do Nexus Kubernetes.

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

Para cada rede trunk listada nas redes associadas ao Pod, o Pod obtém uma única interface de rede. A carga de trabalho é responsável por enviar tráfego marcado bruto através desta interface ou construir interfaces marcadas sobre a interface de rede.

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

Gerenciamento de endereços IP do pod

Ao criar um cluster Nexus Kubernetes, você especifica os intervalos de endereços IP para a rede pod no podCidrs campo. Quando os Pods são lançados, o plugin CNI estabelece uma eth0@ifXX interface no Pod e atribui um endereço IP a partir de um intervalo de endereços IP nesse podCidrs campo.

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 à interface de rede do Pod.

Roteamento

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

A eth0 interface dentro de um Pod possui uma tabela de rotas simples que usa efetivamente a tabela de rotas da VM do nó de trabalho para qualquer um dos seguintes tipos de tráfego.

• Tráfego de pod para pod: O tráfego destinado a um IP nas gamas de endereços podCidrs flui para o switchdev na VM anfitriã e através da interface de nível de nó defaultcni, onde é encaminhado para o endereço IP da VM do pool de agentes adequado ao destino.
• Tráfego de rede L3 OSDevice: O tráfego destinado a um IP em uma rede L3 associada com o OSDevice tipo de plug-in flui para o switchdev na VM host e pela interface de nível de nó associada a essa rede L3.
• Todo o outro tráfego passa para o gateway predefinido no Pod, que encaminha para a interface no nível cloudservices 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 CNI BFD e BGP

Configuração padrão do BFD

Os parâmetros de BFD (Bidirectional Forwarding Detection) podem ser configurados para cada ligação BGP. Os temporizadores BFD são negociados entre os clusters Kubernetes do Operator Nexus e o roteador de mesmo nível. O valor de temporizador mais alto entre os dois roteadores é selecionado, que é o comportamento BFD padrão. Os clusters Nexus Kubernetes usam os seguintes valores:

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

Configurações BGP padrão

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

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