Análisis panorámico de los enlaces de datos de la red de contenedores de Alibaba Cloud (7): Terway DataPath V2 (Terway≥1.8.0)

El equipo de la comunidad de código abierto de China realizó su primera transmisión en vivo, contando la historia detrás de la comunidad de código abierto de China en nombre de compartir".

Autor: Yu Kai

Prefacio

En los últimos años, la tendencia de la infraestructura empresarial nativa de la nube se ha vuelto cada vez más fuerte, desde la IaaS inicial hasta los microservicios actuales, las demandas de los clientes de refinamiento granular y observabilidad se han vuelto más fuertes. Para satisfacer el mayor rendimiento y la mayor densidad de los clientes, las redes de contenedores se han estado desarrollando y evolucionando a gran velocidad, lo que inevitablemente trae umbrales y desafíos extremadamente altos para la observabilidad de las redes nativas de la nube por parte de los clientes. Para mejorar la observabilidad de las redes nativas de la nube y facilitar que los clientes y estudiantes de primera línea aumenten la legibilidad de los enlaces comerciales, ACK Industrial Research y AES establecieron conjuntamente una serie de observabilidad del plano de datos de la red nativa de la nube para ayudar a los clientes y estudiantes. en las líneas delantera y trasera comprenden el sistema de arquitectura de red nativa de la nube, simplifican el umbral de observabilidad de la red nativa de la nube, optimizan la experiencia de operación y mantenimiento del cliente y los estudiantes de posventa en el manejo de problemas difíciles y mejoran la estabilidad de los enlaces de la red nativa de la nube.

Desde una vista panorámica de la red de contenedores, toda la red de contenedores se puede dividir en tres partes: segmento de red Pod, segmento de red de servicios y segmento de red de nodos. Estas tres redes necesitan lograr interconexión y control de acceso, entonces, ¿cuáles son los principios técnicos para su implementación? ¿Cuál es el enlace completo y cuáles son las limitaciones? ¿Cuál es la diferencia entre franela y Terway? ¿Cuál es el rendimiento de la red en diferentes modos? Estos requieren que los clientes tomen decisiones basadas en sus propios escenarios comerciales antes de construir los contenedores. Una vez completada la construcción, la arquitectura relevante no se puede cambiar, por lo que los clientes deben comprender completamente las características de cada arquitectura. Por ejemplo, la siguiente figura es un diagrama simplificado. La red Pod debe lograr la interoperabilidad y el control de la red entre Pods en el mismo ECS, y también realizar el acceso entre Pods en diferentes ECS. El backend de los Pods que acceden a SVC puede estar en el mismo ECS o. otros ECS En estos modos diferentes, el modo de reenvío del enlace de datos es diferente y los resultados de rendimiento del lado comercial también son diferentes.

Este artículo es la séptima parte de [Análisis panorámico de enlaces de datos de redes de contenedores]. Presenta principalmente los enlaces de reenvío de los enlaces del plano de datos en el modo Kubernetes Terway DataPath V2. Primero, al comprender los enlaces de reenvío del plano de datos en diferentes escenarios, podemos identificarlos. Por otro lado, el rendimiento de la superficie de datos del enlace de acceso en diferentes escenarios puede ayudar a los clientes a optimizar aún más la arquitectura empresarial, mediante una comprensión profunda del enlace de reenvío, cuando se encuentran con la fluctuación de la red de contenedores, la operación y el mantenimiento del cliente y Alibaba Cloud; los estudiantes pueden saber qué está sucediendo y observar manualmente qué puntos de enlace se implementan para identificar mejor la dirección y la causa del problema.

Serie 1: Análisis panorámico de los enlaces de datos de la red de contenedores de Alibaba Cloud (1) -Flennel

Serie 2: Análisis panorámico de los enlaces de datos de la red de contenedores de Alibaba Cloud (2) - Terway ENI

Serie tres: Análisis panorámico de los enlaces de datos de la red de contenedores en la nube de Alibaba (3) - Terway ENIIP

Serie 4: Análisis panorámico de los enlaces de datos de la red de contenedores de Alibaba Cloud (4) -Terway IPVLAN + EBPF

Serie 5: Análisis panorámico de los enlaces de datos de la red de contenedores de Alibaba Cloud (5) - Terway ENI-Trunking

Serie 6: Análisis panorámico de los enlaces de datos de la red de contenedores de Alibaba Cloud (6) -ASM Istio

Diseño de arquitectura de patrón Terway DataPath V2

La interfaz de red elástica (ENI) admite la función de configurar múltiples IP auxiliares. A una única interfaz de red elástica (ENI) se le pueden asignar de 6 a 20 IP auxiliares según las especificaciones de la instancia. El modo multi-IP de ENI utiliza esta IP auxiliar para asignar. al contenedor, mejorando así en gran medida la eficiencia del tamaño y la densidad de la implementación de Pod. En términos de conectividad de red, Terway actualmente admite dos soluciones: enrutamiento de políticas de cinco pares e IPVLAN. Sin embargo, la comunidad abandonó el soporte de IPVLAN después de cilium v1.12 [ 1] para unificar la coherencia del plano de datos. ACK La evolución es consistente con la comunidad, lo que facilita la integración de capacidades nativas de la nube y reduce la diferenciación. A partir de la versión 1.8.0, Terway ya no admite la aceleración del túnel IPvlan, pero utiliza DataPath V2 para unificar el plano de datos.

El segmento de red CIDR utilizado por el Pod es el mismo segmento de red que el CIDR del nodo.

Hay una tarjeta de red eth0 dentro del Pod, y la IP de eth0 es la IP del Pod. La dirección MAC de esta tarjeta de red no coincide con la dirección MAC de ENI en la consola. tarjetas de red en ECS, lo que significa que la tarjeta de red ENI adjunta no está conectada directamente al espacio de nombres de red del Pod.

Solo hay una ruta predeterminada que apunta a eth0 en el Pod, lo que significa que cuando el Pod accede a cualquier segmento de dirección, eth0 es la entrada y salida unificadas.

Al mismo tiempo, hay varias tarjetas de red ethx en ECS, lo que significa que la tarjeta de red ENI adjunta no está montada directamente en el espacio de nombres de red del Pod.

Se puede obtener a través del Enrutamiento de OS Linux que todo el tráfico destinado a la IP del Pod será reenviado a la tarjeta virtual calixx correspondiente al Pod. Por lo tanto, el espacio de nombres de red de ECS OS y Pod ha establecido una configuración completa de enlaces entrantes y salientes.

Para la implementación de ENI multi-IP, esto es similar al principio del enlace de datos de red de contenedor ACK (Terway ENIIP) [ 2] . Terway Pod se implementa en cada nodo a través de Daemonset. Puede utilizar el comando de mapeo terway-cli para obtener la cantidad de ENI conectados en el nodo, la dirección MAC y la IP de cada ENI.

Para que Pod acceda a SVC, el contenedor utiliza varios métodos para reenviar la solicitud a la capa ECS donde se encuentra el Pod, y el módulo netfilter en ECS implementa la resolución de la IP de SVC. Sin embargo, dado que el enlace de datos debe cambiarse del espacio de nombres de red del Pod al espacio de nombres de red del sistema operativo ECS, pasando por la pila de protocolos del núcleo en el medio, inevitablemente se producirá una pérdida de rendimiento si existe un mecanismo para hacerlo. Para lograr una alta concurrencia y un alto rendimiento, puede que no sea posible no satisfacer plenamente las necesidades del cliente. En comparación con el modo IPVLAN, que implementa eBPF dentro del Pod para la traducción de direcciones SVC, el eBPF en el modo DataPath V2 escucha en la tarjeta de red calixxx de cada Pod para acelerar el acceso al Pod y al Pod, y transfiere la dirección de acceso del Pod al SVC IP Para la aceleración del enlace, la comparación de modelos puede consultar el uso del complemento de red Terway [ 3] .

Enrutamiento BPF

Después del kernel 5.10, Cilium agregó la función eBPF Host-Routing y dos nuevos métodos de redireccionamiento, bpf_redirect_peer y bpf_redirect_neigh.

bpf_redirect_peer

El paquete de datos se envía directamente a la interfaz eth0 en el par veth Pod sin pasar por la interfaz lxc del host, de modo que el paquete de datos ingresa a la cola de trabajos pendientes de la CPU menos veces y obtiene un mejor rendimiento de reenvío.
bpf_redirect_neigh

Se utiliza para completar las direcciones mac src y dst del tráfico de salida del pod. No es necesario que el tráfico pase por el procesamiento de la pila de protocolos de ruta del kernel.

Por lo tanto, el modelo general de Terway DataPath V2 se puede resumir como:

Actualmente, los kernels de versión baja (inferiores a 4.2) no admiten la aceleración eBPF. Aliyun2 puede obtener capacidades de aceleración parcial y Aliyun3 puede obtener capacidades de aceleración completa.
Los nodos deben pasar por la pila de protocolos del Host para acceder a los Pods. El acceso de Pod a Pod y el acceso de Pod a SVC no pasan por la pila de protocolos del Host.
En el modo DataPath V2, si un Pod accede a la IP de SVC, eBPF convierte la IP de SVC en la tarjeta de red calixxx del quinto par del Pod a la IP de un Pod backend de SVC y luego el enlace de datos omite la pila de protocolos del Host. En otras palabras, la IP del SVC solo se capturará en el quinto par del Pod de origen, pero no se capturarán ni el Pod de destino ni el ECS donde se encuentra el Pod de destino.

Análisis de enlace de datos de red de contenedores en modo Terway DataPath V2

Según las características de la red de contenedores, los enlaces de red en el modo Terway datapathv2 se pueden dividir aproximadamente en dos grandes escenarios SOP: proporcionar servicios externos utilizando Pod IP y proporcionar servicios externos utilizando SVC. Esto se puede subdividir en 11 pequeños escenarios SOP diferentes. Escenario de POE.

Después de combinar y fusionar los enlaces de datos de estos 15 escenarios, estos escenarios se pueden resumir en los siguientes 8 escenarios típicos:

Acceda a la IP del Pod y acceda al Pod desde el mismo nodo
Access Pod IP, acceso mutuo entre Pods en el mismo nodo (los Pods pertenecen al mismo ENI)
Acceda a Pod IP, acceso mutuo entre Pods en el mismo nodo (los Pods pertenecen a diferentes ENI)
Access Pod IP, acceso mutuo entre Pods entre diferentes nodos
IP del clúster SVC/IP externa a la que acceden los pods en el clúster, el pod backend de SVC y el pod cliente pertenecen al mismo ECS y ENI
IP del clúster SVC/IP externa a la que acceden los pods en el clúster, el pod backend de SVC y el pod cliente pertenecen al mismo ECS pero a ENI diferente
La IP del clúster SVC/IP externa a la que acceden los Pods en el clúster, el Pod backend de SVC y el Pod cliente pertenecen a ECS diferentes.
Acceda a la IP externa de SVC desde fuera del clúster

Escenario 1: Acceda a la IP del Pod, acceda al Pod desde el mismo nodo (incluido el acceso al nodo backend SVC ClusterIP del mismo nodo)

ambiente

nginx2-7ff4679659-xkpmm existe en el nodo xxx.10.0.1.219, con dirección IP 10.0.0.2.

enrutamiento del kernel

nginx2-7ff4679659-xkpmm, dirección IP 10.0.0.2, el PID del contenedor en el host es 5630 y el espacio de nombres de la red del contenedor tiene una ruta predeterminada que apunta al contenedor eth0.

El quinto par correspondiente de contenedor eth0 en ECS OS es cali10e985649a0. En ECS OS, hay una ruta que apunta a la IP del Pod y el siguiente salto es calixxx. Del artículo anterior, podemos saber que la tarjeta de red calixxx es un par. veth1 en cada Pod.

Mediante el siguiente comando, podemos obtener nginx2-7ff4679659-xkpmm. La dirección IP 10.0.0.2 se asigna a la tarjeta de red accesoria eth2 por vía.

kubectl --kubeconfig kubeconfig -n kube-system exec -it terway-eniip-v5v2p -c terway -- mapeo terway-cli

resumen

eth0 de ECS capturó los datos devueltos por nginx2-7ff4679659-xkpmm, pero no capturó los datos enviados.

eth1 de ECS también capturó los datos devueltos por nginx2-7ff4679659-xkpmm, pero no capturó los datos enviados.

cali10e985649a0 puede capturar paquetes enviados y recibidos.

El resumen posterior ya no mostrará observaciones de paquetes de datos.

Diagrama de reenvío de enlace de datos (Aliyun2 y Aliyun3):

Todo el enlace pasa a través de la pila de protocolos de red de ECS y Pod.
El enlace de solicitud completo es: ECS OS -> calixxx -> ECS Pod eth0