Kubernetes a beaucoup de pièces mobiles. Ceci est à attendre de tout modèle destiné à l'informatique distribuée. Pour découvrir ce que Kubernetes Ingress nous aide à accomplir, récapitulons d'abord quelques détails pertinents sur un cluster Kubernetes typique :

Une application déployée sur un cluster Kubernetes s'exécute en tant que pods de collecte.
Les pods sont essentiellement des conteneurs qui sont planifiés sur plusieurs nœuds.
Les nœuds peuvent être des serveurs physiques ou des VM proposés par votre hébergeur. Évidemment, vous pouvez également Kubernetes sur un serveur sur site, si vous le souhaitez.
Chaque Pod a une adresse IP unique.
Votre application est divisée en plusieurs sous-composants, souvent appelés microservices.
Pour chaque microservice de votre application, a un Service correspondant dans Kubernetes.
Dans le contexte de Kubernetes, un Un service expose une collection de pods au reste du cluster en tant qu'abstraction unique. Une seule IP virtuelle.
Cela permet à un service de votre application de communiquer avec un autre service. C'est une abstraction qui vous permet d'adresser une collection de pods, plutôt que de spécifier l'adresse IP d'un pod, chaque fois que vous voulez lui parler.
Un service Kubernetes agit également comme un équilibreur de charge pour tous les pods qu'il représente. Le trafic est réparti uniformément sur tous les nœuds.

Jusqu'ici tout va bien. Chaque service peut parler à un autre service. Cette communication est possible sur l'ensemble du cluster Kubernetes

Services d'exposition

"Si un arbre tombe dans une forêt et que personne n'est là pour l'entendre, fait-il un son?"

Sur une note similaire, si votre application ne sert pas à quelque chose en dehors du cluster Kubernetes, est-ce vraiment important que votre cluster soit bien construit ou non? Probablement pas.

Pour vous donner un exemple concret, disons que nous avons une application web classique composée d'un frontend écrit en Nodejs et d'un backend écrit en Python qui utilise la base de données MySQL. Vous déployez deux services correspondants sur votre cluster Kubernetes.

Vous créez un Dockerfile spécifiant comment empaqueter le logiciel frontal dans un conteneur, et de même vous empaquetez votre backend. Ensuite, dans votre cluster Kubernetes, vous déploierez deux services exécutant chacun un ensemble de pods derrière lui. Le service Web peut parler au cluster de base de données et vice versa.

Cependant, Kubernetes n'expose aucun de ces services (qui sont des points de terminaison HTTP essentiels) au reste du monde. Comme indiqué dans la doc officielle :

"Les services sont supposés avoir des adresses IP virtuelles uniquement routables au sein du réseau de cluster"

Ceci est parfaitement raisonnable du point de vue de la sécurité, vos services peuvent communiquer entre eux, mais le cluster ne permettra pas aux entités extérieures de communiquer directement avec les services. Par exemple, seule votre interface Web peut communiquer avec le service de base de données, et personne d'autre ne peut même envoyer des demandes au service de base de données.

Le problème se pose lorsque l'on regarde le cas d'utilisation d'un service frontend. Il doit être exposé au reste du public afin que les utilisateurs finaux puissent utiliser votre application. Nous exposons ces services à l'aide de Kubernetes Ingress.

Entrée Kubernetes

Ingress expose les routes HTTP et HTTPS de l'extérieur du cluster aux services au sein du cluster. Vous pouvez contrôler les règles de routage en définissant la ressource Kubernetes Ingress. Mais ça fait bien plus que ça. L'exposition d'un seul service peut être réalisée à l'aide de diverses autres alternatives telles que NodePort ou Load Balancers, mais ces installations ne disposent pas de fonctionnalités suffisamment sophistiquées pour une application Web moderne.

Des fonctionnalités telles que l'exposition de plusieurs applications sur une seule adresse IP, la définition d'itinéraires, etc.

Comprenons donc ces caractéristiques pour le reste de l'article :

Entrée de service unique

Il s'agit de la version la plus simple de l'exposition d'un seul service comme une interface Web avec une adresse IP (ou un nom de domaine) et des ports HTTP et HTTPS par défaut (i.e, 80 et 443).

Sortie simple

Il s'agit d'une configuration d'entrée qui vous permet d'autoriser le trafic entrant vers une seule adresse IP et de l'acheminer vers plusieurs services.

Cela consiste en:

Une ressource d'entrée se compose d'un nom d'hôte foo.bar.com
Une liste de chemins où le trafic va être acheminé comme foo.bar.com/admin foo.bar.com/home foo.bar.com/sso

Un seul sortance est le cas où une seule adresse IP est utilisée pour plusieurs services. Les services peuvent être à différents chemins dans l'URI comme foo.bar.com/admin peut être un service pour les administrateurs et foo.bar.com/home peut être le service qui génère la page d'accueil de chaque utilisateur.

Le port d'entrée sera toujours 80 ou 443, mais le port sur lequel les services s'exécutent (à l'intérieur du cluster) peut différer un peu.

Ce type d'entrée nous aide à minimiser le nombre d'équilibreurs de charge dans le cluster, car il agit essentiellement comme un.

Hébergement virtuel basé sur le nom

Les adresses IP publiques sont finies. Ils sont aussi assez chers. L'idée de l'hébergement virtuel basé sur le nom est plus ancienne que Kubernetes. L'essentiel est que vous pointez les enregistrements DNS pour différents sites Web comme ww1.Exemple.com et seconde guerre mondiale.Exemple.com à la même adresse IP. Le serveur exécuté à cette adresse IP verra la demande entrante, et si le nom d'hôte mentionné dans la demande est pour ww1.Exemple.com alors il sert ce site Web pour vous, et si ww2.Exemple.com est demandé, alors qui est servi.

Dans le contexte de Kubernetes, nous pouvons exécuter deux services s'exécutant sur, disons, le port 80 et les exposer tous les deux sur une seule adresse IP en utilisant également une entrée du port 80. Au point d'entrée le trafic de ww1.Exemple.com sera séparé du trafic pour la seconde guerre mondiale.Exemple.com. D'où le terme hébergement virtuel basé sur le nom.

Conclusion

L'entrée dans Kubernetes est assez sophistiquée pour être couverte en un seul message. Il existe une variété de cas d'utilisation pour cela, et une variété de contrôleurs d'entrée qui ajouteront la fonctionnalité d'entrée à votre cluster. Je recommanderais de commencer par Nginx Ingress Controller.

Pour plus de détails et de spécifications, vous pouvez également suivre la documentation officielle.