Opérateur Ingress

L'opérateur d'entrée(Red Hat OpenShift) met en œuvre des règles de routage qui sont appliquées à tout le trafic entrant pour les applications de votre cluster.

Les contrôleurs Ingress sont gérés par l'opérateur Ingress. Lors de la création du cluster, le contrôleur Ingress par défaut est enregistré avec le sous-domaine Ingress par défaut de votre cluster au format <cluster_name>.<globally_unique_account_HASH>-0000.<region>.containers.appdomain.cloud. Lorsque vous enregistrez votre application avec ce sous-domaine en créant une ressource Route, le contrôleur Ingress s'assure que les demandes adressées à votre application via ce sous-domaine sont correctement associées à vos nacelles d'application. Pour voir le contrôleur Ingress par défaut dans votre cluster, exécutez oc describe ingresscontroller/default -n openshift-ingress-operator.

Si vous souhaitez enregistrer votre application auprès d'un autre domaine, vous pouvez créer un contrôleur Ingress personnalisé qui implémente des règles de routage pour un domaine personnalisé à la place.

Contrôleur Ingress

Un contrôleur Ingress basé sur HAProxy Red Hat OpenShift Un contrôleur Ingress est créé pour chaque IngressController, et un service de contrôleur Ingress est créé dans chaque zone où vous avez des nœuds de travail.

L'opérateur Ingress configure le contrôleur Ingress avec le même domaine que celui spécifié dans IngressController. Le contrôleur d'entrée est à l'écoute des demandes de service HTTP, HTTPS ou TCP entrantes via ce domaine. Le composant de service d'équilibrage de charge du contrôleur Ingress transmet les demandes aux nacelles de cette application uniquement en fonction des règles définies dans la ressource Route et implémentée par le contrôleur Ingress.

Si vous disposez d'un cluster multizone, un contrôleur Ingress à haute disponibilité est déployé sur votre cluster et est configuré avec un équilibreur de charge VPC multizone. Deux noeuds worker sont requis par zone de sorte que les deux répliques du contrôleur Ingress puissent être déployées et mises à jour correctement.

Si vous créez manuellement un contrôleur Ingress, celui-ci n'est pas automatiquement enregistré avec le sous-domaine Ingress ou une application de votre cluster.

Ressource route

Pour exposer une application à l'aide de la route, vous devez créer un service Kubernetes pour votre application et enregistrer ce service auprès du contrôleur Ingress en définissant une ressource d'itinéraire. La ressource Ingress est une ressource Red Hat OpenShift qui définit les règles d'acheminement des demandes entrantes pour les applications.

La ressource Route indique également le chemin d'accès à vos services d'application. Les chemins d'accès à vos services d'application sont ajoutés au sous-domaine Ingress de votre cluster pour composer une URL d'application unique, telle que mycluster-a1b2cdef345678g9hi012j3kl4567890-0000.us-south.containers.appdomain.cloud/myapp1.

Une ressource Route est requise pour chaque projet où vous avez des applications que vous souhaitez exposer.

• Si les applications de votre cluster sont toutes dans le même projet, vous devez créer une ressource Route pour définir les règles de routage des applications que vous souhaitez exposer. Notez que si vous souhaitez utiliser différents domaines pour les applications figurant dans un même projet, vous pouvez créer une ressource par domaine.
• Si les applications de votre cluster se trouvent dans des projets différents, vous devez créer une ressource Route pour chaque projet afin de définir les règles de routage de l'application.

Pour plus d'informations, voir Planification réseau pour un ou plusieurs projets.

Si vous voulez personnaliser des règles de routage pour votre application, vous pouvez utiliser des annotations HAProxy propres au routeur qui gère le trafic pour votre application. Ces annotations prises en charge sont au format haproxy.router.openshift.io/<annotation> ou router.openshift.io/<annotation>. Notez que les annotations IBM Cloud Kubernetes Service (ingress.bluemix.net/<annotation>) et les annotations NGINX (nginx.ingress.kubernetes.io/<annotation>) ne sont pas prises en charge pour le contrôleur d'entrée ou la ressource d'itinéraire dans Red Hat OpenShift version 4.

Cluster à zone unique

Le diagramme suivant montre comment Ingress dirige la communication entre Internet et une application dans un cluster à zone unique classique :

1. Un utilisateur envoie une demande à votre application en accédant à l'URL de votre application. Cette URL est le sous-domaine Ingress de votre cluster ajouté avec le chemin de ressource Ingress pour votre application exposée, telle que mycluster-<hash>-0000.us-south.containers.appdomain.cloud/myapp.

2. Un service système DNS résout le sous-domaine dans l'URL vers l'adresse IP publique portable de l'équilibreur de charge qui expose le contrôleur Ingress dans votre cluster.

3. En fonction de l'adresse IP résolue, le client envoie la demande au service de contrôleur Ingress.

4. Le contrôleur Ingress vérifie les règles de routage implémentée par le contrôleur Ingress pour une règle de routage pour le chemin myapp. Si une règle de correspondance est trouvée, la demande est mise en correspondance selon les règles que vous avez définies dans le contrôleur Ingress et la ressource Route vers la nacelle où l'application est déployée. L'adresse IP source du paquet est remplacée par l'adresse IP du noeud de travail où s'exécute le contrôleur Ingress. Si plusieurs instances d'application sont déployées dans le cluster, la charge du contrôleur Ingress équilibre les demandes entre les nacelles d'application.

5. Lorsque l'application renvoie un paquet de réponses, elle utilise l'adresse IP du noeud de travail où le contrôleur Ingress qui a transmis la demande existe. Le contrôleur d'entrée envoie ensuite le paquet de réponses au client.

Cluster à zones multiples

Le diagramme suivant montre comment Ingress dirige la communication entre Internet et une application dans un cluster à zones multiples classique :

1. Un utilisateur envoie une demande à votre application en accédant à l'URL de votre application. Cette URL est le sous-domaine Ingress de votre cluster ajouté avec le chemin de ressource Ingress pour votre application exposée, telle que mycluster-<hash>-0000.us-south.containers.appdomain.cloud/myapp.

2. Un service système DNS résout le sous-domaine de routage vers l'adresse IP publique flottante d'un service de contrôleur Ingress signalé comme étant en bonne santé par le MZLB. Le MZLB vérifie continuellement les adresses IP publiques portables des services qui exposent le contrôleur Ingress dans chaque zone de votre cluster. Les demandes sont traitées par les services du contrôleur Ingress dans diverses zones d'un cycle circulaire.

3. Le client envoie la demande à l'adresse IP du service qui expose le contrôleur Ingress.

4. Le contrôleur Ingress vérifie les règles de routage implémentée par le contrôleur Ingress pour le chemin myapp. Si une règle de correspondance est trouvée, la requête est copiée selon les règles que vous avez définies dans IngressController et la ressource Route vers la nacelle où l'application est déployée. L'adresse IP source du paquet est remplacée par l'adresse IP du noeud de travail où s'exécute le contrôleur Ingress. Si plusieurs instances d'application sont déployées dans le cluster, le service du contrôleur Ingress envoie les demandes entre les pods d'application dans toutes les zones.

5. Lorsque l'application renvoie un paquet de réponses, elle utilise l'adresse IP du noeud de travail où le service de contrôleur Ingress qui a transmis la demande existe. Le contrôleur d'entrée envoie ensuite le paquet de réponses au client.

Cluster de VPC avec un noeud final de service cloud public

Lorsque vous créez un cluster VPC multizone avec le noeud final de service de cloud public activé, un contrôleur Ingress public est créé par défaut. Le diagramme suivant montre comment Ingress dirige la communication entre Internet et une application dans un cluster de VPC multizone :

1. Un utilisateur envoie une demande à votre application en accédant à l'URL de votre application. Cette URL est le sous-domaine Ingress de votre cluster pour votre application exposée ajoutée au chemin de ressource Ingress, tel que mycluster-<hash>-0000.us-south.containers.appdomain.cloud/myapp.

2. Un service DNS résout le sous-domaine de routage vers le nom d'hôte de l'équilibreur de charge VPC affecté au contrôleur Ingress. Dans les clusters de VPC, les adresses IP externes sont flottantes et sont conservées derrière un nom d'hôte affecté par VPC.

3. L'équilibreur de charge VPC résout le nom d'hôte VPC en une adresse IP disponible dans une zone pour le contrôleur Ingress qui a été signalé comme étant en bonne santé. L'équilibreur de charge VPC vérifie en permanence les adresses IP externes du contrôleur Ingress dans chaque zone de votre cluster.

4. En fonction de l'adresse IP résolue, l'équilibreur de charge VPC envoie la demande à un contrôleur Ingress.

5. Le contrôleur Ingress vérifie les règles de routage implémentée par le contrôleur Ingress pour le chemin myapp. Si une règle de correspondance est trouvée, la requête est copiée selon les règles que vous avez définies dans IngressController et la ressource Route vers la nacelle où l'application est déployée. L'adresse IP source du paquet est remplacée par l'adresse IP du noeud de travail où s'exécute le contrôleur Ingress. Si plusieurs instances d'application sont déployées dans le cluster, la charge du contrôleur Ingress équilibre les demandes entre les pods d'application dans toutes les zones.

6. Lorsque l'application renvoie un paquet de réponses, elle utilise l'adresse IP du noeud de travail où le service de contrôleur Ingress qui a transmis la demande existe. L'équilibreur de charge VPC envoie ensuite le paquet de réponses au client.

Cluster de VPC avec un noeud final de service cloud privé uniquement

Lorsque vous créez un cluster VPC multizone avec le point de terminaison de service de cloud privé uniquement, un contrôleur Ingress privé est créé par défaut. Seuls les clients connectés à votre réseau VPC privé peuvent accéder aux applications qui sont exposées par un contrôleur Ingress privé. Le diagramme suivant montre comment Ingress dirige la communication entre des réseaux privés et une application dans un cluster de VPC multizone :

1. Un client connecté à votre réseau VPC privé envoie une demande à votre application à l'aide de l'URL de celle-ci. Cette URL est le sous-domaine Ingress de votre cluster pour votre application exposée ajoutée au chemin de ressource Ingress, tel que mycluster-<hash>-0000.us-south.containers.appdomain.cloud/myapp. Par exemple, vous pourriez utiliser le VPN VPC, IBM Cloud Transit Gateway ou IBM Cloud Direct Link pour autoriser les demandes depuis un réseau sur site, un autre cloud privé virtuel ou une infrastructure classique IBM Cloud vers des applications qui s'exécutent dans votre cluster.

2. Un service DNS résout le sous-domaine de routage vers le nom d'hôte de l'équilibreur de charge VPC affecté aux services du contrôleur Ingress. Dans les clusters VPC, les adresses IP privées de vos services de contrôleur d'entrée sont flottantes et sont conservées derrière un nom d'hôte attribué par VPC. Notez que bien que l'enregistrement DNS du sous-domaine de route soit enregistré dans le système DNS public, les serveurs de résolution DNS sont accessibles à partir du cloud privé virtuel.

3. L'équilibreur de charge VPC privé résout le nom d'hôte VPC en une adresse IP privée disponible d'un service de contrôleur Ingress qui a été signalé comme étant en bon état de santé. L'équilibreur de charge VPC vérifie en permanence les adresses IP des services qui exposent le contrôleur Ingress dans chaque zone de votre cluster.

4. En fonction de l'adresse IP résolue, l'équilibreur de charge VPC envoie la demande à un service de contrôleur Ingress.

5. Le contrôleur Ingress vérifie les règles de routage implémentée par le contrôleur Ingress pour le chemin myapp. Si une règle de correspondance est trouvée, la requête est copiée selon les règles que vous avez définies dans IngressController et la ressource Route vers la nacelle où l'application est déployée. L'adresse IP source du paquet est remplacée par l'adresse IP du noeud de travail où s'exécute le contrôleur Ingress. Si plusieurs instances d'application sont déployées dans le cluster, la charge du contrôleur Ingress équilibre les demandes entre les pods d'application dans toutes les zones.

6. Lorsque l'application renvoie un paquet de réponses, elle utilise l'adresse IP du noeud worker où le contrôleur Ingress qui a transmis la demande client existe. Le contrôleur d'entrée envoie ensuite le paquet de réponses via l'équilibreur de charge VPC au client.