Redes en los Kubernetes de Azure Operator Nexus

Una instancia de Azure Operator Nexus, o simplemente Operator Nexus, comprende hardware informático y de red instalado en las instalaciones del cliente. Varias capas de dispositivos físicos y virtuales proporcionan conectividad de red y servicios de enrutamiento a las cargas de trabajo que se ejecutan en este hardware de proceso. En este documento se proporciona una descripción detallada de cada una de estas capas de red.

Topología

Aquí se describe la topología del hardware en una instancia de Operator Nexus.

Los clientes poseen y administran enrutadores perimetrales del proveedor (PE). Estos enrutadores representan el borde de la red troncal del cliente.

Operator Nexus administra los enrutadores perimetrales del cliente (CE). Estos enrutadores forman parte de la instancia de Operator Nexus y se incluyen en hardware casi perimetral lista de materiales (BOM). Hay dos enrutadores CE en cada instancia de Operator Nexus de varios bastidores. Cada enrutador CE tiene un vínculo superior a cada uno de los enrutadores PE. Los enrutadores CE son los únicos dispositivos Operator Nexus que están conectados físicamente a la red del cliente.

Cada bastidor de servidores informáticos en una instancia de Azure Operador Nexus de varios bastidores tiene dos conmutadores en la parte superior del bastidor (TOR). Cada TOR tiene un vínculo superior a cada uno de los enrutadores CE. Cada TOR está conectado a cada servidor informático básico en el bastidor y está configurado como un simple conmutador de capa 2.

Equipo sin sistema operativo

Las cargas de trabajo de inquilino que se ejecutan en esta infraestructura de proceso suelen ser funciones de red virtual o en contenedor. Las funciones de red virtual (VNF) se ejecutan como máquinas virtuales (VM) en el hardware del servidor de proceso. Las funciones de red en contenedores (CNF) se ejecutan dentro de contenedores. Estos contenedores se ejecutan en máquinas virtuales que se ejecutan en el hardware del servidor de proceso.

Las funciones de red que proporcionan servicios de plano de datos de usuario final requieren interfaces de red de alto rendimiento que ofrecen características avanzadas y altas tasas de E/S.

En las instancias de Operator Nexus de varios bastidores casi perimetrales, cada servidor de proceso sin sistema operativo es una máquina de socket dual con arquitectura de acceso a memoria no uniforme (NUMA).

Un servidor de proceso sin sistema operativo en una instancia de Azure Operator Nexus de varios bastidores casi perimetral contiene una tarjeta de interfaz de red de doble puerto (pNIC) para cada celda NUMA. Estos pNIC admiten virtualización de E/S de raíz única (SR-IOV) y otras características de alto rendimiento. Una celda NUMA es la memoria y la CPU alineadas con un pNIC.

Todas las interfaces de red asignadas a las cargas de trabajo de inquilino son dispositivos de paso a través del host y usan funciones virtuales (VFs) sr-IOV asignadas desde la pNIC alineada con la celda NUMA que hospeda los recursos de CPU y memoria de la máquina virtual de la carga de trabajo. Esta disposición garantiza un rendimiento óptimo de la pila de redes dentro de las máquinas virtuales y contenedores asignados a esas máquinas virtuales.

Los bastidores de computación se implementan con un par de conmutadores Top-of-Rack (TOR). Cada pNIC en cada servidor de proceso sin sistema operativo está conectado a ambos TOR. El grupo de agregación de vínculos de varios chasis (MLAG) proporciona alta disponibilidad y el protocolo de control de agregación de vínculos (LACP) proporciona un mayor rendimiento agregado para el vínculo.

Cada servidor de proceso sin sistema operativo tiene una interfaz de red de almacenamiento proporcionada por un vínculo que agrega dos funciones virtuales locales de host (VF) (en lugar de máquinas virtuales locales de máquina virtual) conectadas a ambas PNIC. Estas dos máquinas virtuales se agregan en un enlace de copia de seguridad activa para asegurarse de que se produce un error en una de las pNIC, la conectividad de almacenamiento de red sigue estando disponible.

Recursos de red lógica

Al interactuar con la API de nube de red de Operator Nexus y las API de estructura de red administrada, los usuarios crean y modifican un conjunto de recursos lógicos.

Los recursos lógicos en la API de Managed Network Fabric corresponden a las redes y la configuración de control de acceso en el hardware de red subyacente (los TOR y CE). En particular, los recursos de ManagedNetworkFabric.L2IsolationDomain y ManagedNetworkFabric.L3IsolationDomain contienen conmutadores y configuraciones de red de bajo nivel. Un ManagedNetworkFabric.L2IsolationDomain representa un identificador de red de área local virtual (VLAN). Un ManagedNetworkFabric.L3IsolationDomain representa una configuración de enrutamiento y reenvío virtual(VRF) en los enrutadores CE. Obtenga información sobre el concepto de un dominio de aislamiento.

Los recursos lógicos en la API de Network Cloud corresponden a la infraestructura informática. Hay recursos para bastidores físicos y hardware sin sistema operativo. Del mismo modo, hay recursos para clústeres de Kubernetes y máquinas virtuales que se ejecutan en ese hardware y las redes lógicas que las conectan.

NetworkCloud.L2Network, NetworkCloud.L3Network y NetworkCloud.TrunkedNetwork representan redes de carga de trabajo, lo que significa que el tráfico en estas redes está pensado para cargas de trabajo de inquilino.

Un NetworkCloud.L2Network representa una red de nivel 2 y contiene poco más de un vínculo a un ManagedNetworkFabric.L2IsolationDomain. Este L2IsolationDomain contiene un identificador de VLAN y una configuración de unidad de transmisión máxima (MTU).

Un NetworkCloud.L3Network representa una red de nivel 3 y contiene un identificador de VLAN, información sobre la asignación de direcciones IP para los puntos de conexión de la red y un vínculo a un ManagedNetworkFabric.L3IsolationDomain.

Nota:

¿Por qué un recurso de NetworkCloud.L3Network contiene un identificador de VLAN? ¿Las VLAN no son un concepto de capa 2?

¡Sí, sí son! El motivo de esto se debe al hecho de que NetworkCloud.L3Network debe poder hacer referencia a un ManagedNetworkFabric.InternalNetworkespecífico. ManagedNetworkFabric.InternalNetwork se crean dentro de un ManagedNetworkFabric.L3IsolationDomain específico y se les asigna un identificador de VLAN. Por lo tanto, para hacer referencia a un ManagedNetworkFabric.InternalNetwork específico, el NetworkCloud.L3Network debe contener un identificador L3IsolationDomain y un identificador VLAN.

Los recursos de red lógica en la API de Network Cloud, como los recursos lógicos de referencia NetworkCloud.L3Network en la API de Managed Network Fabric, proporcionan una conexión lógica entre la infraestructura informática física y la infraestructura de red física.

Al crear una máquina virtual Nexus, puede especificar cero o más redes L2, L3 y troncales en el NetworkAttachments de la máquina virtual de Nexus. Al crear un clúster de Kubernetes Nexus, puede especificar cero o más redes L2, L3 y troncales en el campo NetworkConfiguration.AttachedNetworkConfiguration del clúster de Nexus Kubernetes. AgentPools son colecciones de nodos de trabajo de Kubernetes similares dentro de un clúster de Kubernetes Nexus. Puede configurar las redes troncales y L2, L3 y L2 conectadas de cada grupo de agentes en el campo AttachedNetworkConfiguration de AgentPool.

Puede compartir redes en máquinas virtuales Nexus independientes y clústeres de Nexus Kubernetes. Esta composición le permite unir CNF y VNF que trabajan en concierto en las mismas redes lógicas.

En el diagrama se muestra un ejemplo de un clúster de Nexus Kubernetes con dos grupos de agentes y una máquina virtual Nexus independiente conectada a diferentes redes de carga de trabajo. El grupo de agentes "AP1" no tiene ninguna configuración de red adicional y, por tanto, hereda la información de red de KubernetesCluster. Tenga en cuenta también que todos los nodos de Kubernetes y todas las máquinas virtuales Nexus independientes están configuradas para conectarse a la misma red de Cloud Services. Por último, el grupo de agentes "AP2" y la máquina virtual independiente están configuradas para conectarse a una "red L3 compartida".

La CloudServicesNetwork

Las máquinas virtuales de Nexus y los clústeres Nexus Kubernetes siempre hacen referencia a algo llamado "Red de servicios en la nube" (CSN). El CSN es una red especial que se usa para el tráfico entre cargas de trabajo locales y un conjunto de puntos de conexión externos o hospedados en Azure.

El tráfico de CloudServicesNetwork se enruta a través de un proxy, donde el tráfico de salida se controla mediante el uso de una lista de permitidos. Los usuarios pueden ajustar esta lista de permitidos utilizando la API de Network Cloud.

La Red CNI

Al crear un clúster de Kubernetes Nexus, proporcione el identificador de recurso de un NetworkCloud.L3Network en el campo NetworkConfiguration.CniNetworkId.

Esta "red CNI", a veces denominada "DefaultCNI Network", especifica la red de nivel 3 que proporciona direcciones IP para los nodos de Kubernetes en el clúster de Nexus Kubernetes.

El diagrama muestra las relaciones entre algunos de los recursos lógicos de Network Cloud, Managed Network Fabric y Kubernetes. En el diagrama, un NetworkCloud.L3Network es un recurso lógico en la API de nube de red que representa una red de nivel 3. El recurso NetworkCloud.KubernetesCluster tiene un campo networkConfiguration.cniNetworkId que contiene una referencia al recurso NetworkCloud.L3Network.

El recurso NetworkCloud.L3Network está asociado a un único recurso de ManagedNetworkFabric.InternalNetwork a través de sus campos de l3IsolationDomainId y vlanId. El recurso ManagedNetworkFabric.L3IsolationDomain contiene uno o varios recursos de ManagedNetworkFabric.InternalNetwork, con clave vlanId. Cuando el usuario crea el recurso de NetworkCloud.KubernetesCluster, se crean uno o varios NetworkCloud.AgentPool recursos.

Cada uno de estos recursos de NetworkCloud.AgentPool consta de una o varias máquinas virtuales. Un recurso Node de Kubernetes representa cada una de esas máquinas virtuales. Estos recursos de Kubernetes Node deben obtener una dirección IP y los complementos de container Networking Interface (CNI) en las máquinas virtuales obtienen una dirección IP del grupo de direcciones IP asociadas al NetworkCloud.L3Network. El recurso NetworkCloud.KubernetesCluster hace referencia al NetworkCloud.L3Network a través de su campo cniNetworkId. Las reglas de enrutamiento y acceso para esas direcciones IP de nivel de nodo se encuentran en el ManagedNetworkFabric.L3IsolationDomain. El NetworkCloud.L3Network hace referencia al ManagedNetworkFabric.L3IsolationDomain a través de su campo de l3IsoldationDomainId.

Redes de Operator Nexus Kubernetes

Hay tres capas lógicas de redes en Kubernetes:

• Capa de red de nodos
• Capa de red de pods
• Capa de red de servicio

La Capa de red de nodos proporciona conectividad entre el plano de control de Kubernetes y el agente del nodo trabajador de Kubelet.

La Capa de red Pod proporciona conectividad entre contenedores (Pods) que se ejecutan dentro del clúster Nexus Kubernetes y conectividad entre un Pod y una o más redes definidas por inquilinos.

La Capa de red de servicio proporciona equilibrio de carga y funcionalidad de ingreso para conjuntos de Pods relacionados.

Redes de nodos

Los clústeres de Operator Nexus Kubernetes hospedan una o varias funciones de red en contenedor (CNF) que se ejecutan en máquinas virtuales (VM). Un nodo de Kubernetes representa una sola máquina virtual. Los nodos de Kubernetes pueden ser nodos de Plano de control o nodos de Trabajo. Los nodos del plano de control contienen componentes de administración para el clúster de Kubernetes. Los nodos de trabajo hospedan cargas de trabajo de inquilino.

Los grupos de nodos de trabajo de Kubernetes se denominan grupos de agentes. Los grupos de agentes son una construcción Operator Nexus, no una construcción de Kubernetes.

Cada servidor de proceso sin sistema operativo de una instancia de Operator Nexus tiene un switchdev que se define en una sola celda NUMA en el servidor sin sistema operativo. El switchdev alberga un conjunto de puertos de representador de VF SR-IOV que proporcionan conectividad a un conjunto de dispositivos puente que se usan para hospedar tablas de enrutamiento para diferentes redes.

Además de la interfaz defaultcni, Operator Nexus establece una interfaz de red cloudservices en cada nodo. La interfaz de red cloudservices es responsable del enrutamiento del tráfico destinado a puntos de conexión externos (al entorno local del cliente). La interfaz de red cloudservices corresponde al recurso de API de NetworkCloud.CloudServicesNetwork que define el usuario antes de crear un clúster de Nexus Kubernetes. La dirección IP asignada a la interfaz de red cloudservices es un dirección local de vínculo, lo que garantiza que el tráfico de red externo siempre atraviesa esta interfaz específica.

Además de las interfaces de red defaultcni y cloudservices. Operator Nexus crea una o varias interfaces de red en cada nodo de Kubernetes que corresponda a NetworkCloud.L2Network, NetworkCloud.L3Network y NetworkCloud.TrunkedNetwork asociaciones con el clúster de Kubernetes Nexus o AgentPool.

Solo las máquinas virtuales del grupo de agentes tienen estas interfaces de red adicionales. Las máquinas virtuales del plano de control solo tienen las interfaces de red defaultcni y cloudservices.

Administración de direcciones IP de nodo (IPAM)

Los nodos de un grupo de agentes reciben una dirección IP de un grupo de direcciones IP asociadas al recurso NetworkCloud.L3Network al que se hace referencia en el campo networkConfiguration.cniNetworkId del recurso de NetworkCloud.KubernetesCluster. Esta red defaultcni es la puerta de enlace predeterminada para todos los Pods que se ejecutan en ese Nodo y sirve como red predeterminada para la comunicación de Pod a Pod de este a oeste dentro del clúster Nexus Kubernetes.

Redes de pods

Los pods de Kubernetes son colecciones de una o varias imágenes de contenedor que se ejecutan en un Espacio de nombres de Linux. Este espacio de nombres de Linux aísla los procesos y recursos del contenedor de otros contenedores y procesos en el host. En el caso de los clústeres de Nexus Kubernetes, este "host" es una máquina virtual que se representa como un nodo de trabajo de Kubernetes.

Antes de crear un clúster de Kubernetes Operator Nexus, los usuarios crean primero un conjunto de recursos que representan las redes virtuales desde las que se asignan direcciones a las cargas de trabajo de inquilino. A continuación, se hace referencia a estas redes virtuales en los campos cniNetworkId, cloudServicesNetworkId, agentPoolL2Networks, agentPoolL3Networks y agentPoolTrunkedNetworks al crear el clúster de Kubernetes de Operator Nexus.

Los pods se pueden ejecutar en cualquier servidor de proceso en cualquier bastidor de una instancia de Operator Nexus. De forma predeterminada, todos los pods de un clúster de Nexus Kubernetes pueden comunicarse entre sí a través de lo que se conoce como la red de pods. Varios complementos Container Networking Interface (CNI) que se instalan en cada nodo de trabajo de Nexus Kubernetes administran las redes de pods.

Redes adicionales

Al crear un pod en un clúster de Nexus Kubernetes, se declaran las redes adicionales a las que el pod debe asociarse mediante especificando una anotación de k8s.v1.cni.cnf.io/networks. El valor de la anotación es una lista delimitada por comas de nombres de red. Estos nombres de red corresponden a nombres de cualquier red troncal, L3 o L2 asociada al clúster de Kubernetes Nexus o al grupo de agentes.

Operator Nexus configura la máquina virtual del grupo de agentes con archivos NetworkAttachmentDefinition (NAD) que contienen la configuración de red para una única red adicional.

Para cada red troncal enumerada en las redes asociadas del pod, el pod obtiene una única interfaz de red. La carga de trabajo es responsable de enviar tráfico etiquetado sin procesar a través de esta interfaz o construir interfaces etiquetadas sobre la interfaz de red.

Para cada red L2 que aparece en las redes asociadas del pod, el pod obtiene una única interfaz de red. La carga de trabajo es responsable de su propio direccionamiento MAC estático.

Administración de direcciones IP del pod

Al crear un clúster de Nexus Kubernetes, especifique los intervalos de direcciones IP de la red de pods en el campo podCidrs. Cuando se inicia pods, el complemento CNI establece una interfaz eth0@ifXX en el pod y asigna una dirección IP desde un intervalo de direcciones IP en ese campo podCidrs.

En el caso de las redes L3, si la red se ha configurado para usar Nexus IPAM, la interfaz de red del pod asociada a la red L3 recibe una dirección IP del intervalo de direcciones IP (CIDR) configurado para esa red. Si la red L3 no está configurada para usar Nexus IPAM, la carga de trabajo es responsable de asignar estáticamente una dirección IP a la interfaz de red del pod.

Enrutamiento

Dentro de cada pod, el tráfico de la interfaz de eth0 atraviesa un dispositivo ethernet virtual (veth) que se conecta a una switchdev en el host (la máquina virtual) que hospeda el defaultcni, cloudservices y otras interfaces de nivel de nodo.

La interfaz eth0 dentro de un pod tiene una tabla de rutas sencilla que usa eficazmente la tabla de rutas de la máquina virtual del nodo de trabajo para cualquiera de los siguientes tráficos.

• Tráfico de pod a pod: el tráfico destinado a una dirección IP en los intervalos de direcciones de podCidrs fluye al switchdev en la máquina virtual host y a través de la interfaz de nivel de nodo defaultcni donde se enruta a la dirección IP del grupo de agentes de destino adecuada.
• Tráfico de red de OSDevice L3: el tráfico destinado a una dirección IP en una red L3 asociada con el tipo de complemento OSDevice fluye al switchdev en la máquina virtual host y a través de la interfaz de nivel de nodo asociada a esa red L3.
• El resto del tráfico pasa a la puerta de enlace predeterminada en el pod, que se enruta a la interfaz de cloudservices de nivel de nodo. Las reglas de salida configuradas en CloudServicesNetwork asociadas al clúster de Nexus Kubernetes determinan cómo se debe enrutar el tráfico.

Las interfaces de red adicionales dentro de un pod usarán la tabla de rutas del pod para enrutar el tráfico a redes L3 adicionales que usan los tipos de complementos SRIOV y DPDK.