Mise à disposition privée d'applications avec Ingress

Exposez en mode privé plusieurs applications au sein de 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 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 le VRF, activez le VLAN Spanning. 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 privée d'applications avec un noeud final de service de cloud public

Clusters classiques Cloud privé virtuel

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 un contrôleur Ingress privé. 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 noms de domaine personnalisés

Pour configurer les secrets « TLS » pour 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 « TLS » pour les sous-domaines personnalisés ». Ces étapes s'appliquent aussi bien aux clusters classiques qu'aux clusters VPC.

TLS secrets pour le domaine géré par IBM

Clusters classiques Pour utiliser le domaine Ingress géré par IBM dans un cluster classique, consultez la section «Configuration des secrets TLS pour le sous-domaine Ingress fourni par IBM ».
Clusters de VPC Pour utiliser le domaine Ingress géré par IBMdans un cluster de VPC, procédez comme suit.

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 privé

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

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

apiVersion: operator.openshift.io/v1
kind: IngressController
metadata:
  name: private-ingress-controller
  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: Internal
    type: LoadBalancerService

Créez la ressource de contrôleur Ingress dans le projet openshift-ingress-operator de votre cluster. Lorsque vous créez le IngressController, un contrôleur Ingress privé est automatiquement créé et déployé dans le projet openshift-ingress en fonction des paramètres IngressController que vous avez définis à l'étape précédente. De plus, un service de contrôleur Ingress est créé afin de rendre accessible le contrôleur Ingress via une adresse IP (clusters classiques) ou un nom d'hôte VPC (clusters VPC).
```
oc create -f private-ingress-controller.yaml -n openshift-ingress-operator
```

Exécutez la commande oc get et recherchez l'adresse IP ou le nom d'hôte VPC dans la zone EXTERNAL IP du service router-private-ingress-controller.

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

Exemple de sortie pour les clusters classiques.

NAME                                  TYPE           CLUSTER-IP       EXTERNAL-IP    PORT(S)                      AGE
router-private-ingress-controller     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-ingress-controller     LoadBalancer   172.21.57.132    1234abcd-us-south.lb.appdomain.cloud    80/TCP,443/TCP,1940/TCP      3m

Enregistrez l'adresse IP externe ou 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 l'adresse IP externe ou le nom d'hôte VPC du service router-private-ingress-controller respectivement en tant qu'enregistrement A (clusters classiques) ou enregistrement CNAME (clusters de VPC) 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-private-ingress-controller. Lorsque vous exécutez la commande suivante, le sous-domaine que vous avez spécifié dans le fichier private-ingress-controller.yaml est automatiquement généré et est enregistré auprès du service router-private-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>
        backend:
            service:
                name: <app1_service>
                port:
                    number: 80
      - path: /<app2_path>
        backend:
            serivce:
              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 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* pour votre hôte ou laissez la propriété hôte vide pour éviter les échecs lors de la création d'entrée.

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/, entrez / comme chemin. Pour http://domain/app1_path, entrez /app1_path comme chemin.

serviceName

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

servicePort

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 à partir de votre réseau privé

Clusters classiques : avant d'accéder à votre application, vérifiez que vous pouvez accéder à un service DNS. Pour utiliser le fournisseur DNS externe par défaut, vous devez configurer les nœuds périphériques avec un accès public et configurer une Virtual Router Appliance.
A l'intérieur de votre réseau privé, entrez l'URL du service d'application dans un navigateur Web.
```
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 privée d'applications dans des clusters de VPC avec un noeud final de service cloud privé uniquement

Si votre cluster a été 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, vous pouvez utiliser le contrôleur Ingress privé par défaut pour exposer les applications de votre cluster aux requêtes provenant du réseau privé.

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:
    - <custom_domain>
    secretName: <custom_secret_name>
  rules:
  - host: <domain>
    http:
      paths:
      - path: /<app1_path>
        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 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* pour votre hôte ou laissez la propriété hôte vide pour éviter les échecs lors de la création d'entrée.

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/, entrez / comme chemin. Pour http://domain/app1_path, entrez /app1_path comme chemin.

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.

Étape 4 : Accédez à votre application

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.