Je ne sais pas comment l'équilibrage de charge fonctionne avec Ingress.
Si je comprends bien, ce qui se passe est en fait quelque chose comme ceci:
Je ne vois pas comment l'équilibrage de charge est effectué.
Qu'est-ce qui ne va pas dans le schéma ci-dessus que j'ai dessiné?
Pouvez-vous m'aider à le rectifier?
Remarques:
- La réponse suivante m'indique que le contrôleur Ingress lui-même est de type 'loadbalancer': Type de service Ingress < br>
- J'utilise le genre ClusterIP car je ne veux pas exposer l'équilibreur de charge au monde extérieur. L'article suivant ne prend pas en charge cette revendication, où l'équilibreur de charge serait fourni par le service:
3 Réponses :
Les services ClusterIP effectuent eux-mêmes un équilibrage de charge. La dénomination peut prêter à confusion car les services LoadBalancer ne sont pas les seuls services qui impliquent un équilibrage de charge - LoadBalancer signifie en fait quelque chose de plus comme «fournisseur de cloud s'il vous plaît créer un équilibreur de charge externe et pointez-le à ce service ». Les services kubernetes ClusterIP équilibrent la charge entre les pods de différents nœuds à l'aide du proxy kube . Si vous ne souhaitez pas que kubernetes effectue l'équilibrage de charge, vous devez le désactiver spécifiquement par création d'un service headless .
Il convient de noter dans ce contexte que si vous voulez un équilibrage de charge mais que le trafic externe reste dans le nœud sur lequel il a atterri, vous pouvez définir externalTrafficPolicy - kubernetes.io/docs/tasks/access-application-cluster/...
Il semble que le premier schéma que vous avez dessiné soit correct. Mais je pense que vous êtes confus dans la terminologie. En particulier dans la différence entre ingress et ingress-controller .
Ingress est un type de ressources dans k8s (comme Service , Deployment , ReplicaSet etc.). Nous utilisons l'entrée si nous voulons exposer certains services à un monde externe avec une liaison vers un chemin et un hôte (c'est-à-dire myapp.com/api -> my-api-service).
Le travail du contrôleur d'entrée est de gérer la création / mise à jour / suppression des ressources d'entrée et d'implémenter toutes les fonctionnalités nécessaires à l'entrée. Sous le capot, le contrôleur d'entrée est un simple déploiement exposé en tant que service LoadBalancer ou NodePort selon l'endroit où k8s est déployé. Et le contrôleur d'image transmet la demande reçue à l'un des pods de service qui correspond à l'hôte et au chemin dans certaines des ressources d'entrée déployées.
Je suis devenu curieux et j'ai pensé: pourquoi aurais-je besoin d'une entrée pour l'équilibrage de charge sur la couche 7 si la seule chose qu'elle fait est de transférer le trafic vers un service qui implémente l'équilibrage de charge sur la couche 4?
La plupart des implémentations de contrôleur Ingress que j'ai recherchées, parlez au serveur d'API Kubernetes pour garder une trace de tous les pods associés à un service. Au lieu de transférer le trafic vers le service, ils sautent l'intermédiaire et le transmettent directement aux pods. Puisqu'un contrôleur d'entrée fonctionne sur la couche 7, il permet un équilibrage de charge plus orienté application.
Est-il clair que le contrôleur d'entrée est lui-même un pod / s? heureux de discuter à ce sujet - chat.stackoverflow.com/rooms/186559/… < / a>