Analyse panoramique des liaisons de données du réseau de conteneurs Alibaba Cloud (7) : Terway DataPath V2 (Terway≥1.8.0)

L'équipe de la communauté open source chinoise a réalisé sa première diffusion en direct, racontant l'histoire de la communauté open source chinoise au nom du partage.

Auteur : Yu Kai

Préface

Ces dernières années, la tendance vers une infrastructure d'entreprise cloud native est devenue de plus en plus forte. Depuis l'IaaS initial jusqu'aux microservices actuels, les exigences des clients en matière de raffinement granulaire et d'observabilité sont devenues plus fortes. Afin de répondre aux performances et à la densité plus élevées des clients, les réseaux de conteneurs se sont développés et évoluent à grande vitesse, ce qui entraîne inévitablement des seuils et des défis extrêmement élevés pour l'observabilité des réseaux cloud natifs par les clients. Afin d'améliorer l'observabilité des réseaux natifs du cloud et de permettre aux clients et aux étudiants de première ligne d'augmenter plus facilement la lisibilité des liens commerciaux, ACK Industrial Research et AES ont établi conjointement une série d'observabilité du plan de données du réseau natif du cloud pour aider les clients et les étudiants. en première ligne et en arrière-plan, comprendre le système d'architecture de réseau cloud natif, simplifier le seuil d'observabilité du réseau natif cloud, optimiser l'expérience des étudiants en exploitation et maintenance client et après-vente dans la gestion de problèmes difficiles et améliorer la stabilité des liens de le réseau cloud natif.

D'une vue d'ensemble du réseau de conteneurs, l'ensemble du réseau de conteneurs peut être divisé en trois parties : le segment de réseau de pods, le segment de réseau de services et le segment de réseau de nœuds. Ces trois réseaux doivent réaliser l’interconnexion et le contrôle d’accès, alors quels sont les principes techniques de mise en œuvre ? Quel est le lien complet et quelles sont les limites ? Quelle est la différence entre la flanelle et le Terway ? Quelles sont les performances du réseau dans différents modes ? Celles-ci obligent les clients à faire des choix en fonction de leurs propres scénarios commerciaux avant de construire des conteneurs. Une fois la construction terminée, l'architecture concernée ne peut pas être modifiée, les clients doivent donc bien comprendre les caractéristiques de chaque architecture. Par exemple, la figure suivante est un diagramme simplifié. Le réseau de pods doit assurer l'interopérabilité et le contrôle du réseau entre les pods du même ECS, ainsi que l'accès entre les pods de différents ECS. Le backend des pods accédant à SVC peut se trouver dans le même ECS ou. autres ECS, dans ces différents modes, le mode de transfert de liaison de données est différent et les résultats de performances du côté commercial sont également différents.

Cet article est la septième partie de [Analyse panoramique des liaisons de données du réseau de conteneurs]. Il présente principalement les liens de transfert des liens de plan de données en mode Kubernetes Terway DataPath V2. Premièrement, en comprenant les liens de transfert de plan de données dans différents scénarios, nous pouvons identifier. Les performances de la surface de données du lien d'accès dans différents scénarios peuvent aider les clients à optimiser davantage l'architecture commerciale, d'autre part, grâce à une compréhension approfondie du lien de transfert, en cas de gigue du réseau de conteneurs, d'exploitation et de maintenance du client et d'Alibaba Cloud ; les étudiants peuvent savoir ce qui se passe. Déployer et observer manuellement quels points de liaison sont déployés pour identifier davantage la direction et la cause du problème.

Série 1 : Analyse panoramique des liaisons de données du réseau de conteneurs Alibaba Cloud (1) - Flanelle

Série 2 : Analyse panoramique des liaisons de données du réseau de conteneurs Alibaba Cloud (2) - Terway ENI

Troisième série : Analyse panoramique des liaisons de données du réseau de conteneurs Alibaba Cloud (3) - Terway ENIIP

Série 4 : Analyse panoramique des liaisons de données du réseau de conteneurs Alibaba Cloud (4) - Terway IPVLAN+EBPF

Série 5 : Analyse panoramique des liaisons de données du réseau de conteneurs Alibaba Cloud (5) - Terway ENI-Trunking

Série 6 : Analyse panoramique des liaisons de données du réseau de conteneurs Alibaba Cloud (6) - ASM Istio

Conception de l'architecture de modèle Terway DataPath V2

L'interface réseau élastique (ENI) prend en charge la fonction de configuration de plusieurs IP auxiliaires. Une seule interface réseau élastique (ENI) peut se voir attribuer 6 à 20 IP auxiliaires selon les spécifications de l'instance. Le mode multi-IP ENI utilise cette IP auxiliaire pour allouer. au conteneur, améliorant ainsi considérablement l'efficacité de la taille et de la densité du déploiement du Pod. En termes de connectivité réseau, Terway prend actuellement en charge deux solutions : le routage de politique de paire veth et IPVLAN. Cependant, la communauté a abandonné le support IPVLAN après cilium v1.12 [ 1] . ACK L'évolution est cohérente avec la communauté, ce qui facilite l'intégration des capacités natives du cloud et réduit la différenciation. À partir de la version 1.8.0, Terway ne prend plus en charge l'accélération du tunnel IPvlan, mais utilise DataPath V2 pour unifier le plan de données.

Le segment de réseau CIDR utilisé par le pod est le même segment de réseau que le CIDR du nœud.

Il y a une carte réseau eth0 à l'intérieur du Pod, et l'adresse IP de eth0 est l'adresse IP du Pod. L'adresse MAC de cette carte réseau n'est pas cohérente avec l'adresse MAC d'ENI sur la console. En même temps, il existe plusieurs ethx. cartes réseau sur ECS, ce qui signifie que la carte réseau connectée ENI n'est pas directement chargée dans l'espace de noms réseau du Pod.

Il n'existe qu'une route par défaut pointant vers eth0 dans le pod, ce qui signifie que lorsque le pod accède à un segment d'adresse, eth0 est l'entrée et la sortie unifiées.

Dans le même temps, il existe plusieurs cartes réseau ethx sur ECS, ce qui signifie que la carte réseau connectée à ENI n'est pas directement montée sur l'espace de noms réseau du Pod.

Il peut être obtenu via le routage OS Linux que tout le trafic destiné à l'IP du Pod sera transmis à la carte virtuelle calixx correspondant au Pod. Par conséquent, l'espace de noms réseau du système d'exploitation ECS et du pod a établi une configuration complète des liens entrants et sortants.

Pour la mise en œuvre d'ENI multi-IP, ceci est similaire au principe de la liaison de données du réseau de conteneurs ACK (Terway ENIIP) [ 2] . Terway Pod est déployé sur chaque nœud via Daemonset. Vous pouvez utiliser la commande de mappage terway-cli pour obtenir le nombre d'ENI attachés sur le nœud, l'adresse MAC et l'IP sur chaque ENI.

Pour que le pod accède à SVC, le conteneur utilise diverses méthodes pour transmettre la demande à la couche ECS où se trouve le pod, et le module netfilter dans ECS implémente la résolution de l'adresse IP du SVC. Cependant, étant donné que la liaison de données doit être basculée de l'espace de noms réseau du Pod vers l'espace de noms réseau du système d'exploitation de l'ECS, en passant par la pile de protocoles du noyau au milieu, une perte de performances se produira inévitablement s'il existe un mécanisme pour le faire. poursuivre une concurrence élevée et des performances élevées, cela peut ne pas être possible ne pas répondre pleinement aux besoins des clients. Par rapport au mode IPVLAN, qui déploie eBPF à l'intérieur du Pod pour la traduction d'adresses SVC, l'eBPF en mode DataPath V2 écoute sur la carte réseau calixxx de chaque Pod pour accélérer l'accès au Pod et au Pod, et transférer l'adresse d'accès du Pod au SVC IP Pour l'accélération de liaison, la comparaison des modèles peut se référer à l'utilisation du plug-in réseau Terway [ 3] .

Routage BPF

Après le noyau 5.10, Cilium a ajouté la fonction eBPF Host-Routing et deux nouvelles méthodes de redirection, bpf_redirect_peer et bpf_redirect_neigh.

bpf_redirect_peer

Le paquet de données est envoyé directement à l'interface eth0 dans le pod de la paire veth sans passer par l'interface lxc de l'hôte, de sorte que le paquet de données entre moins une fois dans la file d'attente du backlog du processeur et obtient de meilleures performances de transfert.
bpf_redirect_neigh

Utilisé pour remplir les adresses mac src et dst du trafic de sortie du pod. Le trafic n'a pas besoin de passer par le traitement de la pile de protocole de route du noyau.

Par conséquent, le modèle global Terway DataPath V2 peut être résumé comme suit :

Actuellement, les noyaux de version basse (inférieure à 4.2) ne prennent pas en charge l'accélération eBPF. Aliyun2 peut obtenir des capacités d'accélération partielle, et Aliyun3 peut obtenir des capacités d'accélération complètes.
Les nœuds doivent passer par la pile de protocoles de l'hôte pour accéder aux pods. L'accès des pods à SVC ne passe pas par la pile de protocoles de l'hôte.
En mode DataPath V2, si un pod accède à l'adresse IP SVC, l'adresse IP SVC est convertie par eBPF sur la carte réseau calixxx de la paire veth du pod en l'adresse IP d'un pod backend SVC, puis la liaison de données contourne la pile de protocole hôte. En d'autres termes, l'adresse IP SVC ne sera capturée que dans la veth paire du pod source, mais ni le pod de destination ni l'ECS où se trouve le pod de destination ne seront capturés.

Analyse des liaisons de données du réseau de conteneurs en mode Terway DataPath V2

En fonction des caractéristiques du réseau de conteneurs, les liaisons réseau en mode Terway datapathv2 peuvent être grossièrement divisées en deux grands scénarios SOP : fournir des services externes à l'aide de Pod IP et fournir des services externes à l'aide de SVC. Cela peut être subdivisé en 11 petits scénarios SOP différents. . Scénario SOP.

Après avoir passé au peigne fin et fusionné les liaisons de données de ces 15 scénarios, ces scénarios peuvent être résumés dans les 8 scénarios typiques suivants :

Accédez à l'adresse IP du pod et accédez au pod à partir du même nœud
Access Pod IP, accès mutuel entre Pods sur le même nœud (les Pods appartiennent au même ENI)
Access Pod IP, accès mutuel entre les Pods sur le même nœud (les Pods appartiennent à des ENI différentes)
Access Pod IP, accès mutuel entre Pods entre différents nœuds
IP du cluster SVC/IP externe accessible par les pods du cluster, le pod backend SVC et le pod client appartiennent aux mêmes ECS et ENI.
IP du cluster SVC/IP externe accessible par les pods du cluster, le pod backend SVC et le pod client appartiennent au même ECS mais à une ENI différente.
L'adresse IP du cluster SVC/l'adresse IP externe accessible par les pods du cluster, le pod backend SVC et le pod client appartiennent à des ECS différents.
Accéder à l'adresse IP externe SVC depuis l'extérieur du cluster

Scénario 1 : Accéder à l'IP du pod, accéder au pod à partir du même nœud (y compris l'accès au backend SVC ClusterIP du même nœud)

environnement

nginx2-7ff4679659-xkpmm existe sur le nœud xxx.10.0.1.219, avec l'adresse IP 10.0.0.2.

routage du noyau

nginx2-7ff4679659-xkpmm, adresse IP 10.0.0.2, le PID du conteneur dans l'hôte est 5630 et l'espace de noms du réseau de conteneurs a une route par défaut pointant vers le conteneur eth0.

La paire veth correspondante de conteneur eth0 dans ECS OS est cali10e985649a0 Dans ECS OS, il existe une route pointant vers l'IP du Pod et le prochain saut est calixxx. D'après l'article précédent, nous pouvons savoir que la carte réseau calixxx est une paire avec. veth1 dans chaque Pod.

Grâce à la commande suivante, nous pouvons obtenir nginx2-7ff4679659-xkpmm L'adresse IP 10.0.0.2 est attribuée à la carte réseau accessoire eth2 par terway.

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

résumé

eth0 d'ECS a capturé les données renvoyées par nginx2-7ff4679659-xkpmm, mais n'a pas capturé les données envoyées.

eth1 d'ECS a également capturé les données renvoyées par nginx2-7ff4679659-xkpmm, mais n'a pas capturé les données envoyées.

cali10e985649a0 peut capturer les paquets envoyés et reçus.

Le résumé suivant n'affichera plus les observations des paquets de données.

Schéma de transfert de liaison de données (Aliyun2&Aliyun3) :

L'intégralité du lien passe par la pile de protocoles réseau d'ECS et du Pod.
Le lien complet de la demande est : ECS OS -> calixxx -> ECS Pod eth0