Les clusters ACK Edge proposent deux méthodes de déploiement des contrôleurs Ingress, chacune adaptée à une topologie réseau spécifique. Choisissez la méthode qui correspond à vos exigences de connectivité cloud-edge et de routage du trafic.
Concepts clés
Ingress est un objet API Kubernetes qui gère le routage HTTP et HTTPS de couche 7 depuis l'extérieur du cluster vers les services exécutés à l'intérieur. En définissant des règles de transfert sur une ressource Ingress, vous dirigez les requêtes externes vers les pods backend appropriés. Pour en savoir plus sur les principes d'Ingress, consultez la rubrique Gestion d'Ingress.
Les ressources Ingress gèrent uniquement les règles de routage HTTP et HTTPS. Vous devez configurer les fonctionnalités avancées, telles que les algorithmes d'équilibrage de charge et l'affinité de session, sur le contrôleur Ingress et non sur la ressource Ingress.
Le contrôleur Ingress surveille les ressources Ingress et transfère les requêtes HTTP/HTTPS entrantes vers les pods backend appropriés.
Structure d'un cluster ACK Edge
Un cluster ACK Edge étend les clusters ACK Pro pour connecter les nœuds edge au centre de données. Chaque cluster se compose de deux parties :
Cloud node pool : contient des ressources telles que des instances Elastic Compute Service (ECS) au sein du VPC du cluster.
Edge node pool : un ou plusieurs pools de nœuds edge connectés au centre de données.
Pour plus d'informations, consultez la rubrique Pools de nœuds.
Choisir une méthode de déploiement
| Méthode de déploiement | Types d'Ingress pris en charge | Exigence réseau | Topologie de service |
|---|---|---|---|
| Déploiement par pool de nœuds | NGINX Ingress uniquement | Ligne louée ou réseau public | Facultatif (ligne louée) / Obligatoire (réseau public) |
| Déploiement cloud | NGINX Ingress et ALB Ingress | Ligne louée requise | Non utilisée |
Déploiement par pool de nœuds : privilégiez cette méthode si vos nœuds edge se connectent via un réseau public, ou si vous souhaitez que chaque pool de nœuds gère son propre trafic localement sans transit par le cloud.
Déploiement cloud : optez pour cette méthode lorsque votre cloud node pool et vos edge node pools sont connectés via une ligne louée, et que vous n'avez pas besoin de maintenir le trafic local dans chaque edge node pool.
Déploiement par pool de nœuds
Avec le déploiement par pool de nœuds, un contrôleur Ingress s'exécute dans chaque pool de nœuds, y compris le cloud node pool et les edge node pools.
Le contrôleur Ingress du cloud node pool utilise un service LoadBalancer. Le point de terminaison correspond à l'adresse IP d'une instance Classic Load Balancer (CLB).
Le contrôleur Ingress de chaque edge node pool utilise un service NodePort. Le point de terminaison correspond à l'adresse IP de n'importe quel nœud de ce pool.
Topologie de service : configurez une topologie de service pour garantir le transfert des requêtes vers les pods backend du même pool de nœuds. Cette configuration est facultative avec une connexion par ligne louée, mais obligatoire avec une connexion par réseau public. Consultez la rubrique Configurer une topologie de service.
Pour installer le contrôleur, consultez la rubrique Installer le contrôleur NGINX Ingress.
Déploiement cloud
Avec le déploiement cloud, le contrôleur Ingress s'exécute uniquement dans le cloud node pool.
Le cloud node pool et les edge node pools doivent être connectés via une ligne louée pour permettre la communication intranet, incluant l'interconnexion des réseaux hôte et conteneur.
Le contrôleur Ingress expose un accès Internet via un service LoadBalancer, en utilisant l'adresse IP d'une instance Classic Load Balancer (CLB) comme point de terminaison.
Le trafic externe entre par le contrôleur Ingress du cloud node pool et est acheminé vers les pods backend avec équilibrage de charge. Cette méthode n'utilise pas la topologie de service.
Pour installer le contrôleur, consultez les rubriques suivantes :