Dans les clusters ACK Edge, Raven assure la communication entre domaines réseau distincts pour une exploitation et une maintenance (O&M) cloud-edge efficace. Cette rubrique décrit les concepts de Raven, son fonctionnement et ses capacités.
Raven prend en charge le mode proxy (couche 7, gère les conflits d'adresses IP) et le mode tunnel (couche 3, connectivité au niveau des conteneurs).
Contexte
Les clusters ACK Edge reposent sur une architecture cloud-edge : les composants du plan de contrôle s'exécutent dans le cloud, tandis que les charges de travail sont déployées dans des centres de données ou sur des dispositifs périphériques (edge). Les nœuds edge se connectent au point de terminaison public du plan de contrôle via Internet.
Les nœuds edge sont regroupés en pools de nœuds, chacun représentant un domaine réseau distinct. Les nœuds appartenant à des pools différents ne peuvent pas communiquer directement et peuvent présenter des plages d'adresses IP qui se chevauchent. Cette isolation est intentionnelle, mais elle empêche les composants côté cloud d'accéder aux charges de travail edge pour la surveillance et les opérations.
Fonctionnement
Raven fonctionne en deux phases : l'établissement de tunnels entre les nœuds de passerelle, puis le transfert du trafic interdomaines via ces tunnels.
Phase 1 : Initialisation
Chaque pool de nœuds élit un nœud qui sert de passerelle edge. Les nœuds isolés agissent comme leur propre passerelle.
Le DaemonSet raven-agent-ds s'exécute sur chaque nœud en mode réseau hôte. Sur les nœuds de passerelle, il établit des tunnels chiffrés vers la passerelle cloud.
Le composant du plan de contrôle ack-edge-yurt-manager répartit les nœuds en domaines réseau selon leur appartenance aux pools de nœuds et crée une ressource personnalisée
gatewaypour chaque domaine.
Phase 2 : Transfert des requêtes
Les requêtes interdomaines provenant des composants côté cloud sont acheminées via le nœud de passerelle cloud vers le nœud de passerelle edge approprié.
Le nœud de passerelle edge transfère les requêtes vers l'hôte cible, le conteneur ou le service situé dans son domaine réseau.
Choisir un mode de communication
Choisissez le mode en fonction de l'existence ou non de conflits d'adresses IP entre vos pools de nœuds.
| Mode | Type de trafic | Prend en charge les conflits d'IP | Cas d'utilisation |
|---|---|---|---|
| Mode proxy | Au niveau de l'hôte (couche 7) | Oui | Les pools de nœuds présentent des conflits d'IP, ou vous avez besoin des commandes kubectl logs/exec/attach/top |
| Mode tunnel | Au niveau des conteneurs (couche 3) | Non | Les pools de nœuds disposent d'une connectivité inter-nœuds et ne présentent aucun conflit d'IP |
Mode proxy
Le mode proxy crée un canal inverse chiffré entre le nœud de passerelle edge et le nœud de passerelle cloud. La passerelle cloud transfère les requêtes interdomaines vers la passerelle edge au niveau de la couche 7, en identifiant les cibles par NodeName+Port. Un nœud isolé agit comme sa propre passerelle et établit un tunnel directement vers la passerelle cloud.
Le mode proxy prend en charge :
La communication réseau hôte pour l'APIServer, MetricsServer et Prometheus
Les commandes
kubectl logs,kubectl exec,kubectl attachetkubectl topLes pools de nœuds dont les plages d'adresses IP entrent en conflit
En cas de conflit d'adresses IP, utilisez le mode proxy. Le mode tunnel ne peut pas acheminer le trafic au niveau de l'hôte lorsque les adresses IP se chevauchent entre les domaines réseau.
Mode tunnel
Le mode tunnel établit des tunnels IPsec-VPN entre le nœud de passerelle edge et le nœud de passerelle cloud. Au sein de chaque domaine réseau, Raven crée une superposition Virtual Extensible LAN (VXLAN) à l'aide de Flannel VXLAN, et tout le trafic interdomaines des conteneurs est acheminé via le tunnel VPN grâce à cette couche VXLAN.
Le mode tunnel prend en charge :
La communication entre conteneurs à travers les domaines réseau
La collecte des métriques des conteneurs edge par Prometheus
Le mode tunnel nécessite une connectivité directe entre les nœuds au sein de chaque pool de nœuds.
Des pertes de données peuvent survenir lors de la communication interdomaines via Internet. N'utilisez pas le mode tunnel pour transmettre des données critiques pour l'activité. Pour toute question ou suggestion, soumettez un ticket afin de contacter l'équipe technique ACK.
Architecture des composants
Raven se compose de deux composants :
| Composant | Type | Rôle |
|---|---|---|
| ack-edge-yurt-manager | Plan de contrôle | Répartit les nœuds en domaines réseau selon les pools de nœuds et crée des ressources personnalisées gateway |
| raven-agent-ds | Plan de données (DaemonSet) | S'exécute sur chaque nœud ; configure les routes ou les tunnels VPN entre les nœuds de passerelle |
Raven nécessite une ressource de cluster personnalisée gateway pour stocker les données relatives aux nœuds et à la configuration de chaque domaine réseau.
Prérequis
Avant de commencer, assurez-vous de disposer des éléments suivants :
Un cluster ACK Edge exécutant Kubernetes 1.26.3 ou une version ultérieure
Au moins une instance Elastic Compute Service (ECS) désignée comme nœud de passerelle cloud (lors de la création du cluster)
Si les hôtes edge atteignent le plan de contrôle via Internet : une instance Classic Load Balancer (CLB), une adresse IP élastique (EIP) et des listes de contrôle d'accès réseau (ACL) configurées
Étapes suivantes
Pour modifier le mode de communication, configurer les ACL réseau ou définir des passerelles personnalisées, consultez Utiliser le composant de communication O&M interrégion Raven.
Pour consulter les notes de version de raven-agent-ds, voir raven-agent-ds.