Mise en ligne publique d'applications avec Ingress

Exposez publiquement plusieurs applications dans votre cluster Red Hat® OpenShift® on IBM Cloud® en créant des ressources Ingress gérées par le contrôleur Ingress.

Prérequis

Avant d'utiliser Ingress, consultez les prérequis suivants.

La configuration d'Ingress nécessite les rôles IBM Cloud IAM suivants :
- Rôle d'accès à la plateforme d'administration pour le cluster dans IBM Cloud Kubernetes Service.
- Rôle d'accès « Manager » dans tous les espaces de noms d' IBM Cloud Kubernetes Service (projets Red Hat OpenShift ).
En cas d'échec d'une zone, vous pouvez voir des échecs intermittents dans les demandes adressées aux applications qui sont exposées par le contrôleur Ingress dans cette zone.
Pour assurer la haute disponibilité, au moins deux noeuds worker par zone sont recommandés.

Clusters VPC : autorisez les requêtes de trafic acheminées par Ingress vers les ports de vos nœuds de travail. Pour plus d'informations, voir Comprendre la mise en réseau sécurisée par défaut des clusters VPC et Créer et gérer des groupes de sécurité VPC.
Clusters VPC multizones : si vous avez créé un cluster via l'interface de ligne de commande (CLI) puis ajouté manuellement des zones à vos pools de travailleurs à l'aide de la commande ibmcloud oc zone add vpc-gen2 , vous devez mettre à jour l'équilibreur de charge VPC qui expose le contrôleur Ingress afin d'y inclure les sous-réseaux de toutes les zones de votre cluster.
Clusters classiques : Activez une fonction VRF (Virtual Router Function) pour votre compte d'infrastructure IBM Cloud. Pour activer la fonction VRF, voir Activation de VRF. Pour vérifier si la fonction VRF est déjà activée, utilisez la commande ibmcloud account show. Si vous ne pouvez pas ou ne souhaitez pas activer VRF, activez Réseau local virtuel. Lorsqu'une fonction VRF ou Spanning VLAN est activée, le contrôleur Ingress peut router des paquets vers différents sous-réseaux dans le compte.

Exposition publique d'applications au sein de clusters via un point de terminaison de service cloud public

Clusters classiques Cloud privé virtuel

Si votre cluster a été créé sur une infrastructure classique, ou s'il a été créé sur une infrastructure VPC et que vous avez activé le point de terminaison du service cloud public lors de sa création, vous pouvez utiliser le contrôleur Ingress public par défaut pour exposer les applications de votre cluster afin qu'elles puissent recevoir des requêtes provenant du réseau public.

Avant de commencer :

Consultez les prérequis d'Ingress.
Accédez à votre cluster Red Hat OpenShift.

Etape 1 : Déployez des applications et créez des services d'application

Commencez par déployer vos applications et créer des services Kubernetes pour les exposer.

Déployez votre application sur le cluster. Prenez soin d'ajouter un libellé à votre déploiement dans la section "metadata" de votre fichier de configuration, par exemple app: code. Ce libellé est nécessaire pour identifier tous les pods sur lesquels votre application s'exécute afin que les pods soient dans l'équilibrage de charge Ingress.
Pour chaque déploiement d'application que vous souhaitez exposer, créez un service Kubernetes ClusterIP. Votre application doit être exposée par un service Kubernetes pour être incluse dans l'équilibrage de charge Ingress.

oc expose deploy <app_deployment_name> --name my-app-svc --port <app_port> -n <namespace>

Étape 2 : Configurer la terminaison « TLS » avec les certificats TLS et les secrets Kubernetes

Votre certificat « TLS » doit être enregistré en tant que secret « Kubernetes » dans chaque espace de noms où se trouvent vos applications.

Pour utiliser le domaine Ingress géré par IBM, consultez la section « Configuration des secrets TLS pour le sous-domaine Ingress fourni par IBM ».
Pour utiliser un domaine que vous avez créé vous-même, par exemple un domaine enregistré auprès d'un fournisseur externe, consultez la section « Configuration des secrets d' TLS pour les sous-domaines personnalisés ».

Etape 3 : Créez la ressource Ingress

Les ressources Ingress définissent les règles de routage utilisées par le contrôleur Ingress pour acheminer le trafic vers votre service d'application.

Définissez un fichier de configuration de ressource Ingress qui utilise le domaine fourni par IBM ou votre domaine personnalisé pour acheminer le trafic réseau entrant vers les services que vous avez créés auparavant.
```
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: myingressresource
spec:
  tls:
  - hosts:
    - <domain>
    secretName: <secret_name>
  rules:
  - host: <domain>
    http:
      paths:
      - path: /<app1_path>
        pathType: Prefix
        backend:
            service:
                name: test
                port:
                    number: 80
      - path: /<app2_path>
        backend:
            service:
                name: <app2_service>
                port:
                    number: 80
```
tls

Si vous souhaitez utiliser TLS, incluez cette section TLS dans votre ressource. Remplacez <domain> par votre sous-domaine. N'utilisez pas *pour votre hôte ou laissez la propriété hôte vide pour éviter les échecs lors de la création d'entrée. Remplacez <tls_secret_name> par le secret que vous avez créé précédemment qui contient votre certificat TLS et la clé pour un domaine personnalisé ou le secret TLS qui a été automatiquement généré pour un sous-domaine fourni par IBM.

host

Remplacez <domain> par le sous-domaine Ingress fournir par IBM ou votre domaine personnalisé. Si votre cluster dispose de plusieurs projets dans lesquels sont exposées les applications, une ressource Ingress est requise par projet. Vous pouvez utiliser le même sous-domaine dans chaque ressource ou des sous-domaines différents dans chaque ressource. Par exemple, si vous utilisez un domaine générique, vous pouvez ajouter un sous-domaine générique au début du domaine, tel que subdomain1.custom_domain.net ou subdomain1.mycluster-<hash>-0000.us-south.containers.appdomain.cloud. N'utilisez pas & ast; pour votre hôte ou laissez la propriété hôte vide pour éviter les échecs lors de la création d'Ingress.

path

Remplacez « <app_path> » par le chemin d'accès sur lequel votre application est à l'écoute. Le chemin est ajouté au domaine fourni par IBM ou à votre domaine personnalisé de manière à créer une route unique vers votre application. Lorsque vous indiquez cette route dans un navigateur Web, le trafic réseau est acheminé vers le contrôleur Ingress. Le contrôleur Ingress recherche le service associé et le contrôleur Ingress envoie le trafic réseau au service. Le service transfère ensuite le trafic aux pods sur lesquels s'exécute l'application. De nombreuses applications n'écoutez pas sur un chemin spécifique, mais utilisent le chemin racine et un port spécifique. Dans ce cas, définissez le chemin racine en tant que / et n'indiquez pas de chemin d'accès individuel pour votre application. Pour http://domain/, entrez / comme chemin. Pour http://domain/app1_path, entrez /app1_path comme chemin.

pathType

Méthode de correspondance de chemin d'URL. Les valeurs prises en charge sont ImplementationSpecific, Exact ou Prefix. Pour plus d'informations et des exemples sur chaque type de chemin d'accès, consultez la documentation de la communauté sur l' Kubernetes.

name

Remplacez <app1_service> et <app2_service>, et ainsi de suite, par le nom des services que vous avez créés pour exposer vos applications. Si vos applications sont exposées par des services dans différents projets du cluster, incluez uniquement les services d'application figurant dans le même projet. Vous devez créer une ressource Ingress pour chaque projet contenant des applications que vous souhaitez exposer.

port

Port sur lequel votre service est à l'écoute. Utilisez le même port que celui que vous avez défini lors de la création du service Kubernetes pour votre application.
Créez la ressource Ingress pour votre cluster. Veillez à ce que la ressource se déploie dans le même projet que les services d'application que vous avez spécifiés dans la ressource.
```
oc apply -f myingressresource.yaml -n <project>
```
Vérifiez que la création de la ressource Ingress a abouti. Si les messages des événements signalent une erreur dans la configuration de votre ressource, corrigez les valeurs dans votre fichier de ressources, puis réappliquez ce fichier à la ressource.
```
oc describe ingress myingressresource
```

Votre ressource Ingress est créée dans le même projet que vos services d'application et vos applications sont enregistrées auprès du contrôleur Ingress.

Etape 4 : Accédez à votre application sur Internet

Dans un navigateur Web, entrez l'URL du service d'application auquel accéder.

https://<domain>/<app1_path>

Si vous exposez plusieurs applications, accédez à ces applications en modifiant le chemin ajouté à l'URL.

https://<domain>/<app2_path>

Si vous utilisez un domaine générique, accédez à ces applications en utilisant leurs propres sous-domaines.

http://<subdomain1>.<domain>/<app1_path>

http://<subdomain2>.<domain>/<app1_path>

Vous ne pouvez pas vous connecter à votre application via Ingress? Essayez de procéder au traitement des incidents liés à Ingress.

Exposition publique d'applications dans des clusters de VPC avec un noeud final de service cloud privé uniquement

Cloud privé virtuel

Si votre cluster est créé sur une infrastructure VPC et que vous n'avez activé que le point de terminaison du service cloud privé lors de sa création, votre cluster est, par défaut, créé avec uniquement un contrôleur Ingress privé. Pour exposer vos applications au public, vous devez créer d'abord créer un contrôleur Ingress public. Ensuite, vous devez enregistrer votre contrôleur Ingress auprès d'un sous-domaine et, le cas échéant, importer votre propre certificat TLS.

Etape 1 : Déployez des applications et créez des services d'application

Commencez par déployer vos applications et créer des services Kubernetes pour les exposer.

Déployez votre application sur le cluster. Prenez soin d'ajouter un libellé à votre déploiement dans la section "metadata" de votre fichier de configuration, par exemple app: code. Ce libellé est nécessaire pour identifier tous les pods sur lesquels votre application s'exécute afin que les pods soient dans l'équilibrage de charge Ingress.
Pour chaque déploiement d'application que vous souhaitez exposer, créez un service Kubernetes ClusterIP. Votre application doit être exposée par un service Kubernetes pour être incluse dans l'équilibrage de charge Ingress.

oc expose deploy <app_deployment_name> --name my-app-svc --port <app_port> -n <namespace>

Étape 2 : Configurer la terminaison « TLS » avec les certificats TLS et les secrets Kubernetes

Votre certificat « TLS » doit être enregistré en tant que secret « Kubernetes » dans chaque espace de noms où se trouvent vos applications.

TLS Secrets pour les domaines Ingress personnalisés

Pour utiliser un domaine que vous avez créé vous-même, par exemple un domaine enregistré auprès d'un fournisseur externe, consultez la section « Configuration des secrets d' TLS pour les sous-domaines personnalisés ».

TLS Secrets pour les domaines Ingress gérés par « IBM »

Suivez les étapes suivantes pour configurer les secrets d' TLS s pour le domaine Ingress géré par IBM.

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

Dans le sous-domaine que vous avez copié, remplacez la valeur 000<n> dans le sous-domaine par 000<n+1>. Par exemple, la valeur du sous-domaine mycluster-a1b2cdef345678g9hi012j3kl4567890-0002.us-south.containers.appdomain.cloud est remplacée par mycluster-a1b2cdef345678g9hi012j3kl4567890-0003.us-south.containers.appdomain.cloud. n+1 indique le sous-domaine consécutif suivant que vous créez dans ce cluster. Vous enregistrez ce sous-domaine au cours d'étapes ultérieures. Lorsque vous enregistrez le nom de domaine, un secret « TLS » est automatiquement généré pour ce nom de domaine. Le nom de secret suit un format tronqué du sous-domaine, par exemple, mycluster-a1b2cdef345678g9hi012j3kl4567890-0003.

Etape 3 : Créez et configurez un contrôleur Ingress public

Après avoir préparé votre domaine et votre certificat TLS, vous devez créer un contrôleur Ingress public et le configurer avec votre domaine.

Créez un fichier de configuration pour un contrôleur Ingress public.

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

Créez la ressource de contrôleur Ingress dans le projet openshift-ingress-operator de votre cluster. Lorsque vous créez l'élément de contrôleur Ingress, un contrôleur d'entrée public est automatiquement créé et déployé dans le projet openshift-ingress en fonction des paramètres de contrôleur Ingress. En outre, un service de contrôleur Ingress est créé pour exposer le contrôleur Ingress.
```
oc create -f public-ingress-controller.yaml -n openshift-ingress-operator
```

Exécutez la commande oc get et recherchez le nom d'hôte VPC dans la zone EXTERNAL IP du service router-public-ingress-controller. Dans les clusters de VPC, les adresses IP externes des services sont non statiques et sont au contraire conservées derrière un nom d'hôte affecté par VPC.

oc get svc router-public-ingress-controller -n openshift-ingress

Exemple de sortie

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

Enregistrez le nom d'hôte VPC du service auprès du domaine que vous avez précédemment choisi.
- Domaine personnalisé : collaborez avec votre fournisseur DNS pour ajouter le nom d'hôte VPC du service router-public-ingress-controller 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 router-public-ingress-controller. Lorsque vous exécutez la commande suivante, le sous-domaine que vous avez spécifié dans le fichier public-ingress-controller.yaml est automatiquement généré et est enregistré auprès du service router-public-ingress-controller. Un secret TLS pour le domaine est automatiquement généré dans le projet que vous indiquez comme étant celui où s'exécute votre application. Le nom de secret suit un format tronqué du sous-domaine, par exemple, mycluster-a1b2cdef345678g9hi012j3kl4567890-0003.
```
    ibmcloud oc nlb-dns create vpc-gen2 --cluster <cluster_name_or_ID> --lb-host <VPC_hostname> --secret-namespace <project>
    ```
```

Etape 4 : Créez la ressource Ingress

Les ressources Ingress définissent les règles de routage utilisées par le contrôleur Ingress pour acheminer le trafic vers votre service d'application.

Définissez un fichier de configuration de ressource Ingress qui utilise le domaine fourni par IBM ou votre domaine personnalisé pour acheminer le trafic réseau entrant vers les services que vous avez créés auparavant.
```
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: myingressresource
spec:
  tls:
  - hosts:
    - <subdomain>
    secretName: <custom_secret_name>
  rules:
  - host: <subdomain>
    http:
      paths:
      - path: /<app1_path>
        pathType: Prefix
        backend:
            service:
              name: <app1_service>
              port:
                number: 80
      - path: /<app2_path>
        backend:
            service:
              name: <app2_service>
              port:
                number: 80
```
tls

Si vous souhaitez utiliser TLS, incluez cette section TLS dans votre ressource.

Remplacez <domain> par votre sous-domaine. N'utilisez pas & ast; pour votre hôte ou laissez la propriété hôte vide pour éviter les échecs lors de la création d'Ingress.

Remplacez <tls_secret_name> par le secret que vous avez créé précédemment qui contient votre certificat TLS et la clé pour un domaine personnalisé ou le secret TLS qui a été automatiquement généré pour un sous-domaine fourni par IBM.

host

Remplacez <domain> par votre sous-domaine. Si votre cluster dispose de plusieurs projets dans lesquels sont exposées les applications, une ressource Ingress est requise par projet. Vous pouvez utiliser le même sous-domaine dans chaque ressource ou des sous-domaines différents dans chaque ressource. Par exemple, si vous utilisez un domaine générique, vous pouvez ajouter un sous-domaine générique au début du domaine, par exemple, subdomain1.custom_domain.net. N'utilisez pas & ast; pour votre hôte ou laissez la propriété hôte vide pour éviter les échecs lors de la création d'Ingress.

path

Remplacez « <app_path> » par le chemin d'accès sur lequel votre application est à l'écoute. Le chemin est ajouté au domaine fourni par IBM ou à votre domaine personnalisé de manière à créer une route unique vers votre application. Lorsque vous indiquez cette route dans un navigateur Web, le trafic réseau est acheminé vers le contrôleur Ingress. Le contrôleur Ingress recherche le service associé et envoie du trafic réseau au service. Le service transfère ensuite le trafic aux pods sur lesquels s'exécute l'application. De nombreuses applications n'écoutez pas sur un chemin spécifique, mais utilisent le chemin racine et un port spécifique. Dans ce cas, définissez le chemin racine en tant que / et n'indiquez pas de chemin d'accès individuel pour votre application. Par exemple, pour utiliser http://domain/, saisissez / comme chemin d'accès. Pour http://domain/app1_path, entrez /app1_path comme chemin.

pathType

Méthode de correspondance de chemin d'URL. Les valeurs prises en charge sont ImplementationSpecific, Exact ou Prefix. Pour plus d'informations et des exemples sur chaque type de chemin d'accès, consultez la documentation de la communauté sur l' Kubernetes.

name

Remplacez <app1_service> et <app2_service>, et ainsi de suite, par le nom des services que vous avez créés pour exposer vos applications. Si vos applications sont exposées par des services dans différents projets du cluster, incluez uniquement les services d'application figurant dans le même projet. Vous devez créer une ressource Ingress pour chaque projet contenant des applications que vous souhaitez exposer.

port

Port sur lequel votre service est à l'écoute. Utilisez le même port que celui que vous avez défini lors de la création du service Kubernetes pour votre application.
Créez la ressource Ingress pour votre cluster. Veillez à ce que la ressource se déploie dans le même projet que les services d'application que vous avez spécifiés dans la ressource.
```
oc apply -f myingressresource.yaml -n <project>
```
Vérifiez que la création de la ressource Ingress a abouti. Si les messages des événements signalent une erreur dans la configuration de votre ressource, corrigez les valeurs dans votre fichier de ressources, puis réappliquez ce fichier à la ressource.
```
oc describe ingress myingressresource
```

Votre ressource Ingress est créée dans le même projet que vos services d'application et vos applications sont enregistrées auprès du contrôleur Ingress.

Etape 5 : Accédez à votre application sur Internet

Dans un navigateur Web, entrez l'URL du service d'application auquel accéder.

https://<domain>/<app1_path>

Si vous exposez plusieurs applications, accédez à ces applications en modifiant le chemin ajouté à l'URL.

https://<domain>/<app2_path>

Si vous utilisez un domaine générique, accédez à ces applications en utilisant leurs propres sous-domaines.

http://<subdomain1>.<domain>/<app1_path>

http://<subdomain2>.<domain>/<app1_path>

Vous ne pouvez pas vous connecter à votre application via Ingress? Essayez de procéder au traitement des incidents liés à Ingress.

Exposition publique d'applications résidant hors de votre cluster

Exposez des applications résidant hors de votre cluster au public en les incluant dans l'équilibrage de charge Ingress public. Les demandes publiques entrantes sur le domaine fourni par IBM ou sur votre domaine personnalisé sont transmises automatiquement à l'application externe.

Avant de commencer, assurez-vous que l'application externe que vous souhaitez intégrer à l'équilibrage de charge du cluster est accessible via une adresse IP publique.

Pour rendre publiques les applications qui se trouvent en dehors de votre cluster, procédez comme suit.

Définissez un fichier de configuration du service « Kubernetes » pour l'application exposée par le contrôleur Ingress. Ce service transmet les demandes entrantes à un noeud final externe que vous allez créer dans les étapes suivantes.
```
apiVersion: v1
kind: Service
metadata:
  name: myexternalservice
spec:
  ports:
   - protocol: TCP
     port: <app_port>
```
Créez le service dans votre cluster.
```
oc apply -f myexternalservice.yaml
```
Définissez le fichier de configuration d'un noeud final externe. Incluez toutes les adresses IP publiques et les ports pouvant être utilisés pour accéder à votre application externe. Notez que le nom du point de terminaison doit correspondre à celui du service que vous avez créé à l'étape précédente, par exemple myexternalservice.
```
kind: Endpoints
apiVersion: v1
metadata:
  name: myexternalservice
subsets:
  - addresses:
      - ip: <external_IP1>
      - ip: <external_IP2>
    ports:
      - port: <external_port>
```
name

Remplacez <myexternalendpoint> par le nom du service Kubernetes que vous avez créé précédemment.

ip

Remplacez <external_IP> par les adresses IP publiques pour vous connecter à votre application externe.

port

Remplacez <external_port> par le port auquel votre application externe écoute.
Créez le noeud final dans votre cluster.
```
oc apply -f myexternalendpoint.yaml
```
Passez à la deuxième étape de la rubrique Exposition publique d'applications dans des clusters de VPC avec un noeud final de service de cloud privé uniquement ou Exposition publique d'applications dans des clusters avec un noeud final de service de cloud public.