Exposition d'applications avec des routes dans Red Hat OpenShift 4

Flux de circulation dans un cluster classique à zone unique

Le diagramme suivant montre comment un routeur dirige le trafic réseau entre Internet et une application dans un cluster classique à zone unique :

1. Une demande envoyée à votre application utilise le nom d'hôte de la route que vous avez définie pour votre application.

2. Un service DNS résout le sous-domaine avec l'adresse IP publique portable du service de routeur.

3. Le routeur reçoit la demande et la transmet à l'adresse IP privée du pod d'application sur le réseau privé. L'adresse IP source du package de demande est remplacée par l'adresse IP publique du noeud worker sur lequel s'exécute le pod du routeur. Si plusieurs instances d'application sont déployées dans le cluster, le routeur achemine les demandes entre les pods d'application.

4. Lorsque l'application renvoie un paquet de réponses, elle utilise l'adresse IP du noeud worker où se trouve le routeur qui a transmis la demande du client. Le routeur envoie ensuite le paquet de réponses au client via le service d'équilibreur de charge.

Flux de circulation dans un cluster classique multizone

Le diagramme suivant montre comment un routeur dirige le trafic réseau entre Internet et une application dans un cluster classique à zones multiples :

1. Une demande envoyée à votre application utilise le nom d'hôte de la route que vous avez définie pour votre application.

2. Un service DNS résout le sous-domaine de route avec l'adresse IP publique portable d'un service de routeur qui a été signalé comme sain par l'équilibreur de charge multizone (MZLB). Le MZLB vérifie en continu les adresses IP publiques portables des services qui exposent le routeur dans chaque zone de votre cluster. Les demandes sont traitées par les services de routeur dans les différentes zones de façon circulaire.

3. En fonction de l'adresse IP résolue du service de routeur, le routeur reçoit la demande.

4. Le routeur transmet la demande à l'adresse IP privée du pod d'application via le réseau privé. L'adresse IP source du package de demande est remplacée par l'adresse IP publique du noeud worker sur lequel s'exécute le pod du routeur. Chaque routeur envoie les demandes vers les instances d'application au sein de sa propre zone et vers les instances d'application situées dans d'autres zones. De plus, si plusieurs instances d'application sont déployées dans une zone, le routeur alterne les demandes entre les pods d'application.

5. Lorsque l'application renvoie un paquet de réponses, elle utilise l'adresse IP du noeud worker où se trouve le routeur qui a transmis la demande du client. Le routeur envoie ensuite le paquet de réponses au client via le service d'équilibreur de charge.

Flux de circulation dans un cluster de VPC multizone 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 contrôleur Ingress affecte des routes accessibles au public pour vos applications et écoute les demandes adressées à vos applications sur l'interface réseau de l'hôte public.

Le diagramme suivant montre comment un contrôleur Ingress dirige le trafic réseau depuis Internet vers une application dans un cluster multizone, VPC.

1. Une demande envoyée à votre application utilise le nom d'hôte de la route que vous avez définie pour votre application.

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

3. L'équilibreur de charge VPC résout le nom d'hôte VPC en une adresse IP externe disponible d'un service de 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 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 transmet la demande à l'adresse IP privée de l'application pod sur le réseau privé. L'adresse IP source du paquet de requête est remplacée par l'adresse IP du noeud worker sur lequel le contrôleur Ingress du contrôleur s'exécute. Chaque contrôleur Ingress envoie des demandes aux instances d'application dans sa propre zone et aux instances d'application dans d'autres zones. De plus, si plusieurs instances d'application sont déployées dans une même zone, le contrôleur Ingress alterne les demandes entre les pods d'application.

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.

Flux de circulation dans un cluster de VPC multizone 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. Le contrôleur Ingress affecte des routes privées pour vos applications et écoute l'interface du réseau hôte privé. Seuls les clients connectés à votre réseau VPC privé peuvent accéder aux applications qui sont exposées par une route privée.

Le diagramme suivant montre comment un contrôleur Ingress dirige le trafic réseau des réseaux privés vers une application dans un cluster multizone, VPC.

1. Un client connecté à votre réseau VPC privé envoie une demande à votre application à l'aide de la route privée de l'application. 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 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 transmet la demande à l'adresse IP privée de l'application pod sur le réseau privé. L'adresse IP source du paquet de requête est remplacée par l'adresse IP du noeud worker sur lequel le contrôleur Ingress du contrôleur s'exécute. Chaque contrôleur Ingress envoie des demandes aux instances d'application dans sa propre zone et aux instances d'application dans d'autres zones. De plus, si plusieurs instances d'application sont déployées dans une même zone, le contrôleur Ingress alterne les demandes entre les pods d'application.

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 et via le VPN IBM Cloud VPC, Transit Gatewayou Direct Link vers le client.

Configuration de routes publiques dans des clusters classiques ou dans des clusters de VPC avec un noeud final de service cloud public

Si votre cluster est créé sur une infrastructure classique, ou s'il est créé sur une infrastructure VPC et que vous avez activé le point de terminaison du service cloud public lors de sa création, votre cluster est créé par défaut avec un contrôleur Ingress public. Vous pouvez utiliser ce contrôleur Ingress pour créer des routes publiques pour votre application.

1. Créez un service Kubernetes ClusterIP pour le déploiement de votre application. Le service fournit une adresse IP interne pour l'application sur laquelle le contrôleur Ingress peut envoyer du trafic.

   oc expose deploy <app_deployment_name> --name my-app-svc
   

2. Choisissez un domaine pour votre application. Notez que les URL de route doivent comporter 130 caractères maximum IBM- domaine fourni: si vous n'avez pas besoin d'utiliser un domaine personnalisé, un nom d'hôte de route est généré automatiquement pour vous au format <service_name>-<project>.<cluster_name>-<random_hash>-0000.<region>.containers.appdomain.cloud. Domaine personnalisé : pour spécifier un domaine personnalisé, utilisez votre fournisseur DNS ou IBM Cloud® Internet Services.

   1. Récupère l'adresse IP publique du service public de contrôleur Ingress dans chaque zone de la colonne ADRESSE IP EXTERNE. 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.

       oc get svc -n openshift-ingress
       ```
   1. Créez un domaine personnalisé avec votre fournisseur DNS.
           Si vous souhaitez utiliser le même sous-domaine pour plusieurs services dans votre cluster, vous pouvez enregistrer un sous-domaine générique, tel que `*.example.com`.
   {: tip}
   
   1. Mettez en correspondance votre domaine personnalisé avec l'adresse IP publique du contrôleur Ingress en ajoutant l'adresse IP en tant qu'enregistrement A.
   
   

3. Configurez une route basée sur le type de terminaison TLS requise par votre application. Si vous ne disposez pas d'un nom de domaine personnalisé, n'incluez pas l'option « --hostname ». Un nom d'hôte de route est généré pour vous au format <service_name>-<project>.<cluster_name>-<random_hash>-0000.<region>.containers.appdomain.cloud. Si vous avez enregistré un sous-domaine générique, spécifiez un sous-domaine unique dans chaque route que vous créez. Par exemple, vous pouvez spécifier --hostname svc1.example.com dans cette route, et --hostname svc2.example.com dans une autre route.

   • Simple :

       oc expose service <app_service_name> [--hostname <subdomain>]
       ```
   * Passe-système :
   ```sh {: pre}
       oc create route passthrough --service <app_service_name> [--hostname <subdomain>]
       ```
       Vous devez gérer des connexions HTTP/2 ? Après avoir créé la route, exécutez `oc edit route <app_service_name>` et remplacez la valeur `targetPort` de la route par `https`. Vous pouvez tester la route en exécutant `curl -I --http2 https://<route> --insecure`.
   * Remarque : si vous utilisez un domaine personnalisé, incluez les options `--hostname`, `--cert` et `--key`, ainsi que, si vous le souhaitez, l'option `--ca-cert`. Pour plus d'informations sur les exigences relatives aux certificats « TLS », consultez la [documentation sur les routes périphériques « Red Hat OpenShift](https://docs.redhat.com/en/documentation/openshift_container_platform/4.21/html/ingress_and_load_balancing/routes#nw-ingress-creating-an-edge-route-with-a-custom-certificate_secured-routes){: external} ».
   ```sh {: pre}
       oc create route edge --service <app_service_name> [--hostname <subdomain> --cert <tls.crt> --key <tls.key> --ca-cert <ca.crt>]
       ```
   * Ré-chiffrement : si vous utilisez un domaine personnalisé, incluez les options `--hostname`, `--cert` et `--key`, ainsi que, si vous le souhaitez, l'option `--ca-cert`. Pour plus d'informations sur les exigences relatives aux certificats « TLS », consultez la [documentation sur la route de rechiffrement « Red Hat OpenShift](https://docs.redhat.com/en/documentation/openshift_container_platform/4.21/html/ingress_and_load_balancing/routes#nw-ingress-creating-a-reencrypt-route-with-a-custom-certificate_secured-routes){: external} ».
   ```sh {: pre}
       oc create route reencrypt --service <app_service_name> --dest-ca-cert <destca.crt> [--hostname <subdomain> --cert <tls.crt> --key <tls.key> --ca-cert <ca.crt>]
       ```
   

4. Vérifiez que la route pour votre application est créée.

   oc get routes
   

5. Facultatif : Personnaliser les règles de routage par défaut à l'aide de configurations facultatives. Par exemple, vous pouvez utiliser des annotations « HAProxy » spécifiques à une route.

Configuration de routes publiques dans des clusters de VPC avec un noeud final de service cloud privé uniquement

Si votre cluster est créé sur une infrastructure VPC et que vous avez activé uniquement le noeud final de service de cloud privé lors de la création du cluster, votre cluster est créé avec un routeur privé par défaut. Pour exposer publiquement vos applications, vous devez d'abord créer une ressource publique IngressController et la configurer avec un sous-domaine. L'opérateur Ingress crée et configure automatiquement un nouveau contrôleur Ingress public basé sur l'IngressController, que vous pouvez utiliser pour créer des routes publiques pour vos applications.

Notez que même si vous créez une ressource IngressController dans les étapes suivantes, IngressController n'est requis que pour créer et configurer le contrôleur Ingress nécessaire pour vous. Une fois le contrôleur Ingress créé, vous utilisez le contrôleur Ingress directement pour créer des routes.

1. Préparez le domaine que vous souhaitez utiliser pour votre contrôleur Ingress.

   • Domaine personnalisé : pour enregistrer un domaine personnalisé, travaillez en collaboration avec votre fournisseur DNS (Domain Name Service) ou votre DNS IBM Cloud. Si vous souhaitez utiliser le même sous-domaine pour plusieurs services dans votre cluster, vous pouvez enregistrer un sous-domaine générique, tel que *.example.com. Si vous utilisez un domaine personnalisé, vous devez également spécifier le certificat de domaine dans votre spécification IngressController. Pour plus d'informations, voir Définition d'un certificat par défaut personnalisé
   • Domaine fourni par IBM :
     1. Répertoriez les sous-domaines qui existent dans votre cluster. Dans la colonne Sous-domaine de la sortie, copiez le sous-domaine dont la valeur 000<n> est la plus élevée.

        ibmcloud oc nlb-dns ls --cluster CLUSTER_NAME_OR_ID
        

        Dans cet exemple de sortie, le sous-domaine mycluster-a1b2cdef345678g9hi012j3kl4567890-0002.us-south.containers.appdomain.cloud a la valeur 000<n> la plus élevée de 0002.

        Subdomain                                                                               Load Balancer Hostname                        Health Monitor   SSL Cert Status           SSL Cert Secret Name
        mycluster-a1b2cdef345678g9hi012j3kl4567890-0000.us-south.containers.appdomain.cloud     ["1234abcd-us-south.lb.appdomain.cloud"]      None             created                   mycluster-a1b2cdef345678g9hi012j3kl4567890-0000
        mycluster-a1b2cdef345678g9hi012j3kl4567890-0001.us-south.containers.appdomain.cloud     ["5678efgh-us-south.lb.appdomain.cloud"]      None             created                   mycluster-a1b2cdef345678g9hi012j3kl4567890-0001
        mycluster-a1b2cdef345678g9hi012j3kl4567890-0002.us-south.containers.appdomain.cloud     ["9012ijkl-us-south.lb.appdomain.cloud"]      None             created                   mycluster-a1b2cdef345678g9hi012j3kl4567890-0002
        

     2. Dans le sous-domaine que vous avez copié, remplacez la valeur 000<n> dans le sous-domaine par 000<n+1>. Par exemple, le sous-domaine mycluster-a1b2cdef345678g9hi012j3kl4567890-0002.us-south.containers.appdomain.cloud est remplacé par mycluster-a1b2cdef345678g9hi012j3kl4567890-0003.us-south.containers.appdomain.cloud. Vous enregistrez ce sous-domaine au cours d'étapes ultérieures.

2. Créez un fichier YAML qui configure un contrôleur Ingress public avec le domaine choisi à l'étape 1.

   apiVersion: operator.openshift.io/v1
   kind: IngressController
   metadata:
     name: public
     namespace: openshift-ingress-operator
   spec:
     # defaultCertificate: If you are using a custom domain, specify the domain certificate
       # name: custom-certs-default
     replicas: 2
     domain: <domain>
     endpointPublishingStrategy:
       loadBalancer:
         scope: External
       type: LoadBalancerService
   

3. Créez la ressource IngressController dans l'espace de nom openshift-ingress-operator de votre cluster. Lorsque vous créez l'élément IngressController, un contrôleur d'entrée public est automatiquement créé et déployé dans l'espace de nom openshift-ingress en fonction des paramètres IngressController. En outre, un service de contrôleur Ingress est créé pour exposer le contrôleur Ingress.

   oc create -f public.yaml -n openshift-ingress-operator
   

4. Récupérez le nom d'hôte VPC contenu dans la zone EXTERNAL IP du service router-public. Dans les clusters de VPC, les adresses IP externes des services de routeur sont flottantes et sont conservées derrière un nom d'hôte affecté par VPC.

   oc get svc router-public -n openshift-ingress
   

   Exemple de sortie

   NAME                         TYPE           CLUSTER-IP       EXTERNAL-IP                             PORT(S)                      AGE
   router-public                LoadBalancer   172.21.57.132    1234abcd-us-south.lb.appdomain.cloud    80/TCP,443/TCP,1940/TCP      3m
   

5. Enregistrez le nom d'hôte VPC du service dans le domaine que vous avez choisi à l'étape 1. Cette étape garantit que les adresses IP de vos services de contrôleur d'entrée, qui sont conservées derrière le nom d'hôte VPC, sont enregistrées dans le domaine que vous avez choisi pour le contrôleur Ingress.

   • Domaine personnalisé : collaborez avec votre fournisseur DNS pour ajouter le nom d'hôte VPC du service en tant qu'enregistrement CNAME qui est mappé à votre domaine personnalisé.
   • Domaine fourni par IBM : créez une entrée DNS pour le nom d'hôte VPC du service. Lorsque vous exécutez la commande suivante, le sous-domaine que vous avez spécifié à l'étape 2 est automatiquement généré et est enregistré avec le service de contrôleur Ingress.

       ibmcloud oc nlb-dns create vpc-gen2 --cluster <cluster_name_or_ID> --lb-host <router_VPC_hostname>
       ```
   

6. Facultatif : Si vous souhaitez utiliser l'affûtage de contrôleur Ingress pour que des routes spécifiques soient gérées par un contrôleur Ingress spécifique, par exemple les routes privées ne doivent être admises qu'à un routeur privé, vous pouvez utiliser des libellés de route ou des libellés d'espace de nom pour spécifier la méthode d'affûtage. Pour ajouter le sélecteur lors de la création, incluez-le dans ingresscontroller yaml sous spec. Par exemple, pour permettre à un contrôleur Ingress de gérer uniquement les entrées / routes avec le libellé type=sharded, vous pouvez ajouter un routeSelector. Pour plus d'informations, voir Éclatement des données du contrôleur Ingress.

     routeSelector:
       matchLabels:
         type: sharded
   

   1. Pour ajouter des sélecteurs à un contrôleur Ingress existant, obtenez une liste de contrôleurs Ingress.

       oc get ingresscontroller -n openshift-ingress-operator
       ```
   1. Ajoutez les sélecteurs pour transgresser les contrôleurs dans lesquels vous souhaitez utiliser le partage.
   
   ```sh {: pre}
       oc patch  -n openshift-ingress-operator IngressController/<name>   --type='merge'   -p '{"spec":{"routeSelector":{"matchLabels":{"type":"sharded"}}}}'
       ```
   
   1. Notez qu'aucun sélecteur n'est ajouté à l'IngressController par défaut, de sorte que toutes les routes sont toujours admises au contrôleur Ingress par défaut sur le cluster. Vous pouvez utiliser la route appropriée ou un sélecteur de libellé d'espace de nom pour modifier ce comportement. Par exemple, pour ajuster le routeur par défaut pour ignorer ingress / routes avec le libellé `type=sharded`, exécutez la commande de correctif suivante.
   ```sh {: pre}
       oc patch -n openshift-ingress-operator IngressController/default --type='merge'   -p '{"spec":{"routeSelector":{"matchExpressions":[{"key":"type","operator":"NotIn","values":["sharded"]}]}}}'
       ```
       Plusieurs routes et Ingresses du cluster dépendent du contrôleur de la sortie publique par défaut. Assurez-vous que les modifications sont correctes avant de modifier le contrôleur Ingress par défaut. Pour plus d'informations, voir [Éclatement des données du contrôleur Ingress](https://docs.redhat.com/en/documentation/openshift_container_platform/4.21/html/networking_overview/index#nw-ingress-sharding_configuring-ingress){: external}.
       {: note}
   
   
   

7. Créez un service Kubernetes ClusterIP pour le déploiement de votre application. Le service fournit une adresse IP interne pour l'application sur laquelle le contrôleur Ingress peut envoyer du trafic.

   oc expose deploy <app_deployment_name> --name <app_service_name> -n <app_project>
   

8. Configurez une route basée sur le type de terminaison TLS requise par votre application. Si vous n'utilisez pas l'option « --hostname », le nom d'hôte de la route est généré automatiquement au format <app_service_name>-<app_project>.<router-subdomain>.

   • Simple :

       oc expose service <app_service_name> [--hostname <subdomain>]
       ```
   * Passe-système :
   ```sh {: pre}
       oc create route passthrough --service <app_service_name> [--hostname <subdomain>]
       ```
       Vous devez gérer des connexions HTTP/2 ? Après avoir créé la route, exécutez `oc edit route <app_service_name>` et remplacez la valeur `targetPort` de la route par `https`. Vous pouvez tester la route en exécutant `curl -I --http2 https://<route> --insecure`.
   * Remarque : si vous utilisez un domaine personnalisé, incluez les options `--hostname`, `--cert` et `--key`, ainsi que, si vous le souhaitez, l'option `--ca-cert`. Pour plus d'informations sur les exigences relatives aux certificats « TLS », consultez la [documentation sur les routes périphériques « Red Hat OpenShift](https://docs.redhat.com/en/documentation/openshift_container_platform/4.21/html/ingress_and_load_balancing/routes#nw-ingress-creating-an-edge-route-with-a-custom-certificate_secured-routes){: external} ».
   ```sh {: pre}
       oc create route edge --service <app_service_name> [--hostname <subdomain> --cert <tls.crt> --key <tls.key> --ca-cert <ca.crt>]
       ```
   * Ré-chiffrement : si vous utilisez un domaine personnalisé, incluez les options `--hostname`, `--cert` et `--key`, ainsi que, si vous le souhaitez, l'option `--ca-cert`. Pour plus d'informations sur les exigences relatives aux certificats « TLS », consultez la [documentation sur la route de rechiffrement « Red Hat OpenShift](https://docs.redhat.com/en/documentation/openshift_container_platform/4.21/html/ingress_and_load_balancing/routes#nw-ingress-creating-a-reencrypt-route-with-a-custom-certificate_secured-routes){: external} ».
   ```sh {: pre}
       oc create route reencrypt --service <app_service_name> --dest-ca-cert <destca.crt> [--hostname <subdomain> --cert <tls.crt> --key <tls.key> --ca-cert <ca.crt>]
       ```
   

9. Vérifiez que la route configurée pour votre application est créée.

   oc get routes
   

10. Facultatif: personnalisez les règles de routage du contrôleur Ingress public avec des configurations facultatives. Par exemple, vous pouvez utiliser des annotations « HAProxy » spécifiques à une route.

11. Pour créer des routes pour d'autres applications en utilisant le même sous-domaine, vous pouvez répéter les étapes 7 à 10 de sorte que le chemin soit généré par le même contrôleur d'entrée public. Si vous souhaitez créer des routes pour d'autres applications à l'aide d'un sous-domaine différent, répétez toutes les étapes de cette section pour créer un nouveau contrôleur d'entrée public avec un domaine différent.

Configuration de routes privées dans des clusters classiques ou dans des clusters de VPC avec un noeud final de service cloud public

Si votre cluster est créé sur une infrastructure classique, ou s'il est créé sur une infrastructure VPC et que vous avez activé le point de terminaison du service cloud public lors de sa création, votre cluster est créé par défaut avec uniquement un contrôleur Ingress public. Pour exposer vos applications en privé, vous devez d'abord créer une ressource IngressController privée et configurer le contrôleur avec un sous-domaine. L'opérateur Ingress crée et configure automatiquement un nouveau contrôleur Ingress privé, que vous pouvez utiliser pour créer des routes privées pour vos applications.

Notez que même si vous créez une ressource IngressController dans les étapes suivantes, la ressource IngressController n'est requise que pour créer et configurer le contrôleur Ingress nécessaire pour vous. Une fois le contrôleur Ingress créé, vous utilisez le routeur directement pour créer des routes.

1. Préparez le domaine que vous souhaitez utiliser pour votre contrôleur Ingress.

   • Domaine personnalisé, clusters classiques ou VPC : pour enregistrer un domaine personnalisé, travaillez en collaboration avec votre fournisseur DNS (Domain Name Service) ou votre DNS IBM Cloud. Si vous souhaitez utiliser le même sous-domaine pour plusieurs services dans votre cluster, vous pouvez enregistrer un sous-domaine générique, tel que *.example.com.
   • Domaine fourni par IBM, clusters de VPC uniquement :
     1. Répertoriez les sous-domaines qui existent dans votre cluster. Dans la colonne Sous-domaine de la sortie, copiez le sous-domaine dont la valeur 000<n> est la plus élevée.

        ibmcloud oc nlb-dns ls --cluster <cluster_name_or_id>
        

        Dans cet exemple de sortie, le sous-domaine mycluster-a1b2cdef345678g9hi012j3kl4567890-0002.us-south.containers.appdomain.cloud a la valeur 000<n> la plus élevée de 0002.

        Subdomain                                                                               Load Balancer Hostname                        Health Monitor   SSL Cert Status           SSL Cert Secret Name
        mycluster-a1b2cdef345678g9hi012j3kl4567890-0000.us-south.containers.appdomain.cloud     ["1234abcd-us-south.lb.appdomain.cloud"]      None             created                   mycluster-a1b2cdef345678g9hi012j3kl4567890-0000
        mycluster-a1b2cdef345678g9hi012j3kl4567890-0001.us-south.containers.appdomain.cloud     ["5678efgh-us-south.lb.appdomain.cloud"]      None             created                   mycluster-a1b2cdef345678g9hi012j3kl4567890-0001
        mycluster-a1b2cdef345678g9hi012j3kl4567890-0002.us-south.containers.appdomain.cloud     ["9012ijkl-us-south.lb.appdomain.cloud"]      None             created                   mycluster-a1b2cdef345678g9hi012j3kl4567890-0002
        

     2. Dans le sous-domaine que vous avez copié, remplacez la valeur 000<n> dans le sous-domaine par 000<n+1>. Par exemple, le sous-domaine mycluster-a1b2cdef345678g9hi012j3kl4567890-0002.us-south.containers.appdomain.cloud est remplacé par mycluster-a1b2cdef345678g9hi012j3kl4567890-0003.us-south.containers.appdomain.cloud. Vous enregistrez ce sous-domaine au cours d'étapes ultérieures.

2. Créez un fichier de configuration qui configure un contrôleur Ingress privé avec le domaine choisi à l'étape 1.

   apiVersion: operator.openshift.io/v1
   kind: IngressController
   metadata:
     name: private
     namespace: openshift-ingress-operator
   spec:
     replicas: 2
     domain: <domain>
     endpointPublishingStrategy:
       loadBalancer:
         scope: Internal
       type: LoadBalancerService
   

3. Créez la ressource IngressController dans l'espace de nom openshift-ingress-operator de votre cluster. Lorsque vous créez la ressource IngressController, un contrôleur Ingress privé est automatiquement créé et déployé dans l'espace de nom openshift-ingress en fonction des paramètres IngressController. En outre, un service de contrôleur Ingress est créé pour exposer le contrôleur Ingress avec une adresse IP (clusters classiques) ou un nom d'hôte VPC (clusters VPC).

   oc create -f private.yaml -n openshift-ingress-operator
   

4. Récupérez l'adresse IP ou le nom d'hôte VPC contenu dans la zone EXTERNAL IP du service router-private.

   oc get svc router-private -n openshift-ingress
   

   Exemple de sortie pour les clusters classiques :

   NAME                         TYPE           CLUSTER-IP       EXTERNAL-IP    PORT(S)                      AGE
   router-private               LoadBalancer   172.21.57.132    10.XX.XX.XX    80/TCP,443/TCP,1940/TCP      3m
   

   Exemple de sortie pour les clusters de VPC :

   NAME                         TYPE           CLUSTER-IP       EXTERNAL-IP                             PORT(S)                      AGE
   router-private               LoadBalancer   172.21.57.132    1234abcd-us-south.lb.appdomain.cloud    80/TCP,443/TCP,1940/TCP      3m
   

5. Enregistrez l'adresse IP externe ou le nom d'hôte VPC du service auprès du domaine que vous avez choisi à l'étape 1.

   • Domaine personnalisé, clusters classiques ou VPC : collaborez avec votre fournisseur DNS pour ajouter l'adresse IP externe ou le nom d'hôte VPC du service respectivement en tant qu'enregistrement A (clusters classiques) ou enregistrement CNAME (clusters de VPC) qui est mappé à votre domaine personnalisé.
   • Domaine fourni par IBM, clusters de VPC uniquement : créez une entrée DNS pour le nom d'hôte VPC du service. Lorsque vous exécutez la commande suivante, le sous-domaine que vous avez spécifié à l'étape 2 est automatiquement généré et est enregistré avec le service de contrôleur Ingress.

       ibmcloud oc nlb-dns create vpc-gen2 --cluster <cluster_name_or_ID> --lb-host <router_VPC_hostname>
       ```
   

6. Facultatif : Si vous souhaitez utiliser l'affûtage de contrôleur Ingress pour que des routes spécifiques soient gérées par un contrôleur Ingress spécifique, par exemple les routes privées ne doivent être admises qu'à un routeur privé, vous pouvez utiliser des libellés de route ou des libellés d'espace de nom pour spécifier la méthode d'affûtage. Pour ajouter le sélecteur lors de la création, incluez-le dans ingresscontroller yaml sous spec. Par exemple, pour permettre à un contrôleur Ingress de gérer uniquement les entrées / routes avec le libellé type=sharded, vous pouvez ajouter un routeSelector. Pour plus d'informations, voir Éclatement des données du contrôleur Ingress.

     routeSelector:
       matchLabels:
         type: sharded
   

   1. Pour ajouter des sélecteurs à un contrôleur Ingress existant, obtenez une liste de contrôleurs Ingress.

       oc get ingresscontroller -n openshift-ingress-operator
       ```
   1. Ajoutez les sélecteurs pour transgresser les contrôleurs dans lesquels vous souhaitez utiliser le partage.
   
   ```sh {: pre}
       oc patch  -n openshift-ingress-operator IngressController/<name>   --type='merge'   -p '{"spec":{"routeSelector":{"matchLabels":{"type":"sharded"}}}}'
       ```
   
   1. Notez qu'aucun sélecteur n'est ajouté à l'IngressController par défaut, de sorte que toutes les routes sont toujours admises au contrôleur Ingress par défaut sur le cluster. Vous pouvez utiliser la route appropriée ou un sélecteur de libellé d'espace de nom pour modifier ce comportement. Par exemple, pour ajuster le routeur par défaut pour ignorer ingress / routes avec le libellé `type=sharded`, exécutez la commande de correctif suivante.
   ```sh {: pre}
       oc patch -n openshift-ingress-operator IngressController/default --type='merge'   -p '{"spec":{"routeSelector":{"matchExpressions":[{"key":"type","operator":"NotIn","values":["sharded"]}]}}}'
       ```
   

7. Créez un service Kubernetes ClusterIP pour le déploiement de votre application. Le service fournit une adresse IP interne pour l'application sur laquelle le contrôleur Ingress peut envoyer du trafic.

   oc expose deploy <app_deployment_name> --name <app_service_name> -n <app_project>
   

8. Configurez une route basée sur le type de terminaison TLS requise par votre application. Indiquez le nom d'hôte configuré à l'étape 5.

   • Simple :

       oc expose service <app_service_name> --hostname <subdomain>
       ```
   * Passe-système :
   ```sh {: pre}
       oc create route passthrough --service <app_service_name> --hostname <subdomain>
       ```
       Vous devez gérer des connexions HTTP/2 ? Après avoir créé la route, exécutez `oc edit route <app_service_name>` et remplacez la valeur `targetPort` de la route par `https`. Vous pouvez tester la route en exécutant `curl -I --http2 https://<route> --insecure`.
   * Remarque : si vous utilisez un domaine personnalisé, incluez les options `--cert` et `--key`, ainsi que, si vous le souhaitez, l'option `--ca-cert`. Pour plus d'informations sur les exigences relatives aux certificats « TLS », consultez la [documentation sur les routes périphériques « Red Hat OpenShift](https://docs.redhat.com/en/documentation/openshift_container_platform/4.21/html/ingress_and_load_balancing/routes#nw-ingress-creating-an-edge-route-with-a-custom-certificate_secured-routes){: external} ».
   ```sh {: pre}
       oc create route edge --service <app_service_name> --hostname <subdomain> [--cert <tls.crt> --key <tls.key> --ca-cert <ca.crt>]
       ```
   * Ré-chiffrement : si vous utilisez un domaine personnalisé, incluez les options `--cert` et `--key`, ainsi que, si vous le souhaitez, l'option `--ca-cert`. Pour plus d'informations sur les exigences relatives aux certificats « TLS », consultez la [documentation sur la route de rechiffrement « Red Hat OpenShift](https://docs.redhat.com/en/documentation/openshift_container_platform/4.21/html/ingress_and_load_balancing/routes#nw-ingress-creating-a-reencrypt-route-with-a-custom-certificate_secured-routes){: external} ».
   ```sh {: pre}
       oc create route reencrypt --service <app_service_name> --dest-ca-cert <destca.crt> --hostname <subdomain> [--cert <tls.crt> --key <tls.key> --ca-cert <ca.crt>]
       ```
   

9. Vérifiez que la route configurée pour votre application est créée.

   oc get routes
   

10. Facultatif: personnalisez les règles de routage du contrôleur Ingress privé avec des configurations facultatives. Par exemple, vous pouvez utiliser des annotations « HAProxy » spécifiques à une route.

11. Pour créer des routes pour d'autres applications en utilisant le même sous-domaine, vous pouvez répéter les étapes 7 à 10 de sorte que le chemin soit généré par le même contrôleur Ingress privé. Si vous souhaitez créer des routes pour d'autres applications à l'aide d'un sous-domaine différent, répétez toutes les étapes de cette section pour créer un nouveau contrôleur Ingress privé.

Configuration de routes privées dans des clusters de VPC avec un noeud final de service cloud privé uniquement

Si votre cluster est créé sur l'infrastructure VPC et que vous avez activé le seul nœud final de service de cloud privé lors de la création du cluster, votre cluster est créé avec un contrôleur Ingress privé par défaut. Vous pouvez utiliser ce contrôleur Ingress pour créer des routes privées pour votre application.

1. Créez un service Kubernetes ClusterIP pour le déploiement de votre application. Le service fournit une adresse IP interne pour l'application sur laquelle le contrôleur Ingress peut envoyer du trafic.

   oc expose deploy <app_deployment_name> --name my-app-svc
   

2. Choisissez un domaine pour votre application.

   • Domaine fourni par IBM : Si vous n'avez pas besoin d'un domaine personnalisé, un sous-domaine de routage est généré pour vous au format <service_name>-<project>.<cluster_name>-<random_hash>-0000.<region>.containers.appdomain.cloud.
   • Domaine personnalisé : pour spécifier un domaine personnalisé, utilisez votre fournisseur DNS ou IBM Cloud® Internet Services.

     1. Récupère l'adresse IP externe du service de contrôleur Ingress privé dans chaque zone de la colonne ADRESSE IP EXTERNE. 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.

        oc get svc -n openshift-ingress
        

     2. Créez un domaine personnalisé avec votre fournisseur DNS. Si vous souhaitez utiliser le même sous-domaine pour plusieurs services dans votre cluster, vous pouvez enregistrer un sous-domaine générique, tel que *.example.com.

     3. Mettez en correspondance votre domaine personnalisé avec l'adresse IP privée des services du contrôleur Ingress en ajoutant les adresses IP en tant qu'enregistrements A.

3. Configurez une route en fonction de Type d'arrêt TLS requis par votre application. Si vous ne disposez pas d'un nom de domaine personnalisé, n'incluez pas l'option « --hostname ». Un sous-domaine de route est généré pour vous au format <service_name>-<project>.<cluster_name>-<random_hash>-0000.<region>.containers.appdomain.cloud. Si vous avez enregistré un sous-domaine générique, spécifiez un sous-domaine unique dans chaque route que vous créez. Par exemple, vous pouvez spécifier --hostname svc1.example.com dans cette route, et --hostname svc2.example.com dans une autre route.

   • Simple :

       oc expose service <app_service_name> [--hostname <subdomain>]
       ```
   * Passe-système :
   ```sh {: pre}
       oc create route passthrough --service <app_service_name> [--hostname <subdomain>]
       ```
       Vous devez gérer des connexions HTTP/2 ? Après avoir créé la route, exécutez `oc edit route <app_service_name>` et remplacez la valeur `targetPort` de la route par `https`. Vous pouvez tester la route en exécutant `curl -I --http2 https://<route> --insecure`.
   
   * Remarque : si vous utilisez un domaine personnalisé, incluez les options `--hostname`, `--cert` et `--key`, ainsi que, si vous le souhaitez, l'option `--ca-cert`. Pour plus d'informations sur les exigences relatives aux certificats « TLS », consultez la [documentation sur les routes périphériques « Red Hat OpenShift](https://docs.redhat.com/en/documentation/openshift_container_platform/4.21/html/ingress_and_load_balancing/routes#nw-ingress-creating-an-edge-route-with-a-custom-certificate_secured-routes){: external} ».
   ```sh {: pre}
       oc create route edge --service <app_service_name> [--hostname <subdomain> --cert <tls.crt> --key <tls.key> --ca-cert <ca.crt>]
       ```
   * Ré-chiffrement : si vous utilisez un domaine personnalisé, incluez les options `--hostname`, `--cert` et `--key`, ainsi que, si vous le souhaitez, l'option `--ca-cert`. Pour plus d'informations sur les exigences relatives aux certificats « TLS », consultez la [documentation sur la route de rechiffrement « Red Hat OpenShift](https://docs.redhat.com/en/documentation/openshift_container_platform/4.21/html/ingress_and_load_balancing/routes#nw-ingress-creating-a-reencrypt-route-with-a-custom-certificate_secured-routes){: external} ».
   ```sh {: pre}
       oc create route reencrypt --service <app_service_name> --dest-ca-cert <destca.crt> [--hostname <subdomain> --cert <tls.crt> --key <tls.key> --ca-cert <ca.crt>]
       ```
   

4. Vérifiez que la route pour votre application est créée.

   oc get routes
   

5. Facultatif : Personnaliser les règles de routage par défaut à l'aide de configurations facultatives. Par exemple, vous pouvez utiliser des annotations « HAProxy » spécifiques à une route.