IBM Cloud Docs
A propos d'Ingress

A propos d'Ingress

Ingress est un service qui permet d'équilibrer les charges de travail du trafic réseau dans votre cluster en transférant des demandes publiques ou privées à vos applications. Vous pouvez utiliser Ingress pour exposer plusieurs services d'application sur un réseau public ou privé en utilisant un seul domaine public ou privé.

Dans votre cluster, le contrôleur Red Hat OpenShift Le contrôleur Ingress est un équilibreur de charge de couche 7 qui met en œuvre un contrôleur Ingress HAProxy. Un service de couche 4 LoadBalancer expose le contrôleur Ingress de sorte que le contrôleur Ingress puisse recevoir des demandes externes qui entrent dans votre cluster. Le contrôleur Ingress transmet ensuite les demandes aux pods d'application de votre cluster en fonction des caractéristiques de protocole de la couche 7, telles que les en-têtes.

Quels sont les composants d'Ingress ?

Dans les clusters qui exécutent Red Hat OpenShift version 4, Ingress se compose de trois composants: un opérateur Ingress, un contrôleur Ingress et les ressources d'itinéraire.

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.

Clusters classiques : adresses IP du contrôleur d'entrée

Pour rechercher les adresses IP des services du contrôleur Ingress par défaut, exécutez oc get svc -n openshift-ingress et recherchez la zone IP EXTERNE. Si vous disposez d'un cluster à zones multiples, notez que le service de contrôleur d'entrée dans la première zone où vous avez des nœuds worker est toujours nommé router-default, et que les services de contrôleur d'entrée dans les zones que vous ajoutez ultérieurement à votre cluster ont des noms tels que router-dal12.

Clusters VPC : noms d'hôtes des contrôleurs d'entrée

Lorsque vous créez un cluster de VPC, un équilibreur de charge VPC public et un équilibreur de charge VPC privé multizone sont automatiquement créés en dehors de votre cluster dans votre VPC. L'équilibreur de charge public VPC crée un nom d'hôte pour enregistrer le contrôleur Ingress public, et l'équilibreur de charge VPC privé crée un nom d'hôte pour enregistrer le contrôleur Ingress privé. Dans les clusters VPC, un nom d'hôte est affecté aux contrôleurs Ingress car les adresses IP externes ne sont pas statiques et peuvent changer avec le temps. Notez que ce nom d'hôte du contrôleur d'entrée est différent du sous-domaine Ingress par défaut de votre cluster.

Le sous-domaine Ingress pour votre cluster est automatiquement lié au nom d'hôte de l'équilibreur de charge VPC pour votre contrôleur public Ingress. Notez que le sous-domaine Ingress pour votre cluster, qui ressemble à <cluster_name>.<hash>-0000.<region>.containers.appdomain.cloud, est différent du nom d'hôte attribué par l'équilibreur de charge VPC pour votre contrôleur d'entrée public, qui ressemble à 01ab23cd-<region>.lb.appdomain.cloud. Le sous-domaine Ingress est la route publique via laquelle les utilisateurs accèdent à votre application à partir d'Internet ; il peut être configuré pour utiliser la terminaison TLS. Le nom d'hôte attribué à votre contrôleur d'entrée public est ce que l'équilibreur de charge VPC utilise pour acheminer le trafic vers le service de contrôleur Ingress.

Vous pouvez trouver le nom d'hôte affecté à votre contrôleur Ingress public et le nom d'hôte affecté à votre contrôleur Ingress privé en exécutant oc get svc -n openshift-ingress et en recherchant la zone IP EXTERNE.

Dans le tableau de bord de votre infrastructure VPC, les rapports d'équilibreur de charge VPC ne sont en bonne santé que les deux nœuds worker qui exécutent les gousses de réplique du contrôleur Ingress, car ces nœuds worker sont configurés en tant que programmes d'écoute pour l'équilibreur de charge VPC. Même si seuls les noeuds worker du programme d'écoute sont déclarés comme sains, le pool de noeuds worker des programmes d'écoute est tenu à jour par Red Hat OpenShift on IBM Cloud de sorte que tous les noeuds worker de votre cluster puissent toujours recevoir des demandes de l'équilibreur de charge VPC.

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.

Comment une demande accède-t-elle à mon application dans un cluster classique ?

Cluster à zone unique

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

Exposer une application dans un cluster à zone unique en utilisant Ingress*
Exposer une application dans un cluster à zone unique en utilisant Ingress* Exposer une application dans un cluster à zone unique en utilisant
Exposer une application dans un cluster à zone unique en utilisant Ingress*

  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 :

Exposer une application dans un cluster multizone en utilisant
une application dans un cluster multizone en utilisant Ingress*Exposer une application dans un cluster multizone en utilisant

  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.

Comment une demande accède-t-elle à mon application dans un cluster de VPC ?

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 :

Exposer publiquement une application dans un cluster VPC multizone en utilisant Ingress*Exposer
publiquement une application dans un cluster VPC multizone en utilisant

  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 :

Exposer en privé une application dans un cluster VPC multizone en utilisant
en privé une application dans un cluster VPC multizone en utilisant

  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.

Comment puis-je personnaliser le routage ?

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>.

Les annotations IBM Cloud Kubernetes Service (ingress.bluemix.net/<annotation>) et les annotations NGINX (nginx.ingress.kubernetes.io/<annotation>) sont prises en charge par Pas pour le contrôleur Ingress ou Route dans Red Hat OpenShift version 4.

Pour commencer, voir Personnalisation d'Ingress.

Comment puis-je activer les certificats TLS ?

Pour équilibrer le chargement des connexions HTTPS entrantes vers votre sous-domaine, vous pouvez configurer le contrôleur Ingress pour déchiffrer le trafic réseau et transmettre la demande déchiffrée aux applications qui sont exposées dans votre cluster.

Lorsque vous configurez le contrôleur Ingress public, vous choisissez le domaine à travers lequel vos applications sont accessibles. Si vous utilisez le domaine fourni par IBM, tel que mycluster-<hash>-0000.us-south.containers.appdomain.cloud/myapp, vous pouvez utiliser le certificat TLS par défaut créé pour le sous-domaine Ingress. Si vous configurez un enregistrement CNAME pour mapper votre domaine personnalisé au domaine fourni par IBM, vous pouvez fournir votre propre certificat TLS pour votre domaine personnalisé.

Pour plus d'informations sur les certificats TLS, voir Gestion des secrets et des certificats TLS.