Créez des clusters ACK Edge pour connecter les appareils de vos centres de données et vos périphériques edge à Container Service for Kubernetes (ACK), exploitez les fonctionnalités d'ACK et gérez vos ressources de calcul locales. Cette rubrique décrit les concepts clés et les architectures réseau utilisés dans le réseau d'un cluster ACK Edge, notamment la connexion cloud-edge, l'interface réseau de conteneur (CNI), les services et les Ingress. La maîtrise de ces termes vous aide à optimiser les modèles de déploiement des applications et les méthodes d'accès au réseau.
Modes de connexion réseau cloud-edge
Les clusters ACK Edge prennent en charge deux modes de connexion : le mode réseau public et le mode réseau privé.
Mode réseau public : les centres de données locaux et les périphériques edge se connectent via des passerelles NAT Internet ou des cartes réseau publiques, ce qui permet d'accéder aux plans de contrôle ACK et aux autres services Alibaba Cloud.
Mode réseau privé : les appareils de calcul des centres de données et les périphériques edge se connectent via des lignes dédiées, des passerelles VPN ou d'autres réseaux privés, permettant ainsi l'accès aux plans de contrôle ACK hébergés sur le cloud et aux autres services Alibaba Cloud. Le schéma ci-dessous utilise Express Connect d'Alibaba Cloud comme exemple.
Composants de communication O&M cloud-edge
Les clusters ACK Edge reposent sur une architecture de collaboration cloud-edge où le cloud central gère les centres de données edge et les périphériques edge. Comme les appareils de calcul sont souvent répartis dans plusieurs régions et domaines réseau, une communication directe entre le cloud central et la partie edge n'est pas possible.
Pour répondre aux exigences d'O&M et de surveillance du cloud central concernant les périphériques edge, deux solutions s'offrent à vous :
Communication par réseau privé : connectez le VPC du cloud central aux centres de données ou aux appareils situés à la périphérie via des réseaux privés afin d'établir la communication entre le cloud et la partie edge.
Tunneling via Internet : utilisez le composant de communication O&M cloud-edge Raven pour établir un tunnel inverse sur Internet. Ce tunnel inverse facilite les transferts de données d'O&M et de surveillance entre le cloud et la partie edge. Assurez-vous que les centres de données edge ou les périphériques peuvent accéder à Internet. Pour plus d'informations, consultez Le composant de communication O&M interdomaines Raven.
CNI
Kubernetes utilise des plug-ins CNI pour activer et standardiser la mise en réseau des conteneurs :
Les pods rejoignent le réseau de conteneurs lors de leur création et le quittent lors de leur suppression.
Chaque pod reçoit une adresse IP unique.
Les pods peuvent communiquer avec des endpoints situés à l'intérieur et à l'extérieur du cluster.
Les plug-ins CNI implémentent le réseau de conteneurs. Votre plug-in CNI détermine l'allocation des adresses IP des pods, l'utilisation du réseau superposé, le transfert du trafic intra-cluster et le contrôle d'accès des pods. Parmi les plug-ins CNI open source bien connus figurent Calico, Flannel et Cilium.
Les clusters ACK Edge prennent en charge les plug-ins réseau Flannel et Terway Edge, chacun offrant des fonctionnalités distinctes. Avant de créer un cluster, reportez-vous aux sections suivantes pour sélectionner le plug-in réseau approprié.
Une fois le cluster créé, vous ne pouvez pas basculer entre Terway Edge et Flannel.
Flannel (réseaux superposés pour les conteneurs)
Dans les clusters ACK Edge, Flannel fonctionne en mode Virtual Extensible Local Area Network (VXLAN) pour établir un réseau de conteneurs sur le réseau hôte de couche 3, permettant ainsi la communication entre les pods sur différents hôtes.
Le plug-in réseau Flannel garantit que le bloc CIDR des pods ne chevauche pas le bloc CIDR du VPC. Le bloc CIDR des pods est divisé uniformément et attribué aux nœuds du cluster. Chaque pod sur un nœud reçoit une adresse IP appartenant au bloc CIDR du nœud. Le plug-in réseau Flannel présente les caractéristiques suivantes :
Le bloc CIDR des pods ne chevauche pas le bloc CIDR du VPC.
L'hôte encapsule les paquets de conteneurs via VXLAN pour la transmission.
Aucune configuration supplémentaire des périphériques réseau externes n'est requise ; la solution est prête à l'emploi.
Pour plus d'informations sur le plug-in réseau Flannel, consultez Flannel.
Terway Edge (réseaux sous-jacents pour les conteneurs)
Terway Edge adopte une solution de réseau cloud-native au sein du pool de nœuds cloud. Il configure le réseau de conteneurs en utilisant des interfaces réseau élastiques (ENI). Les ENI sont des cartes réseau virtuelles qui attribuent des adresses IP au sein d'un VPC aux pods. Pour un pool de nœuds edge, vous devez spécifier un bloc CIDR pour les pods. Les conteneurs obtiendront des adresses IP à partir de ce bloc CIDR. Le plug-in réseau Terway Edge présente les caractéristiques suivantes :
Le bloc CIDR des pods cloud et des instances Elastic Compute Service (ECS) se situe dans la plage d'adresses IP du VPC et se trouve sur le même plan réseau.
Le bloc CIDR des pods edge ne chevauche pas le bloc CIDR de l'hôte.
La communication entre les pods s'effectue sans encapsulation, offrant une efficacité supérieure à celle du réseau superposé.
La configuration des périphériques réseau externes avec des routes est nécessaire pour la transmission des paquets de conteneurs.
Prise en charge de l'accès direct aux conteneurs du cluster depuis des hôtes externes, des conteneurs et des services cloud via l'adresse IP du pod.
Pour plus d'informations sur le plug-in réseau Terway Edge, consultez Plug-in réseau Terway Edge.
Présentation des services
Un service expose les applications en fournissant un point d'entrée vers un groupe de pods. ACK propose les types de services suivants pour gérer les requêtes provenant de différentes sources et clients :
Type | Description |
ClusterIP | Un service ClusterIP gère l'accès au sein du cluster. Si votre application nécessite une exposition interne au cluster, créez un service ClusterIP. Remarque Par défaut, ClusterIP est sélectionné lors de la création d'un service. |
NodePort | Un service NodePort expose une application à Internet. Utilisez l'adresse IP et le port d'un nœud du cluster pour exposer votre application. Ainsi, votre application est accessible via l'adresse IP et le port du nœud. |
LoadBalancer | Un service LoadBalancer expose une application à Internet. Un service LoadBalancer utilise une instance SLB pour exposer les applications. Par conséquent, les services LoadBalancer offrent une disponibilité et des performances supérieures à celles des services NodePort. Pour plus d'informations sur l'utilisation d'un service LoadBalancer pour exposer des applications, consultez Utiliser des services LoadBalancer pour exposer des applications. |
Headless Service | Un Headless Service est défini en définissant le champ |
ExternalName | Un service ExternalName mappe un nom de service interne à un nom de domaine externe. Cela permet aux pods internes au cluster d'accéder au domaine externe en utilisant le nom de service interne. |
Dans les clusters ACK Edge, les ressources de calcul sont souvent réparties sur différents domaines réseau. Les fonctionnalités suivantes sont proposées pour les scénarios distribués :
|
Fonctionnalité |
Description |
|
Topologie de service |
La topologie de service garantit que les requêtes des clients sont dirigées vers les pods backend situés dans le même domaine réseau ou sur le même nœud. Par conséquent, la communication entre les clients et les pods de service situés dans différents domaines réseau est restreinte. Pour plus d'informations, consultez Topologie de service pour les pools de nœuds. |
|
Isolation de port pour le service NodePort |
Pour isoler les ports des services NodePort sur plusieurs domaines réseau, configurez l'écoute NodePort en fonction des pools de nœuds. Pour plus d'informations, consultez Configurer l'écoute NodePort en fonction des pools de nœuds. |
Présentation des Ingress
Dans les clusters ACK Edge, les services prennent en charge l'équilibrage de charge de couche 4. Cependant, les Ingress gèrent l'accès externe aux services du cluster au niveau de la couche 7. Un Ingress sert de point d'accès qui expose plusieurs services du cluster. Vous pouvez utiliser les Ingress pour configurer différentes règles de transfert de couche 7. Par exemple, vous pouvez acheminer les requêtes vers différents services en fonction des noms de domaine ou des chemins. Pour plus d'informations, consultez Présentation des Ingress.
