Exposition d'applications dans des clusters Satellite

Exposez en toute sécurité des applications qui s'exécutent dans votre cluster Satellite à des demandes de trafic provenant du réseau public, à partir de ressources connectées au réseau privé de vos hôtes ou à partir de ressources dans IBM Cloud.

Plusieurs options vous permettent d'exposer des applications dans des clusters Satellite :

  • MetalLB : Une implémentationLoadBalancer adaptée aux clusters Satellite sur site.
  • Routes Red Hat OpenShift : exposez rapidement des applications à des demandes à partir du réseau public ou d'un réseau privé avec un nom d'hôte. Le contrôleur Red Hat OpenShift Ingress fournit l'enregistrement DNS et les certificats facultatifs pour vos routes.
  • Équilibreur de charge tiers et routes Red Hat OpenShift : Exposer des applications avec un nom d'hôte et ajouter des vérifications de santé pour les adresses IP de l'hôte qui sont enregistrées dans les enregistrements DNS du contrôleur Ingress.
  • Ports de noeud : exposez des applications non HTTP, telles que des applications UDP ou TCP apps, avec un port de noeud compris entre 30000 et 32767.
  • Routes Red Hat OpenShift et noeuds finaux de liaison Satellite : exposez votre application avec une route privée et créez un noeud final de liaison de type location pour la route. Seule une ressource connectée au réseau privé IBM Cloud peut accéder à votre application.

Configuration de MetalLB

MetalLB est une implémentation d'équilibrage de charge pour les clusters Kubernetes bare metal, à l'aide de protocoles de routage standard. Pour plus d'informations, consultez les sections À MetalLB propos MetalLB et Opérateur dans la Red Hat OpenShift documentation.

Pour installer et configurer le " MetalLB,, suivez les instructions du " Installation de l'opérateur " MetalLB dans la documentation du " Red Hat OpenShift Avant de commencer, assurez-vous que vous disposez d'un sous-réseau dédié (IPAddressPool) pour l'IP externe des services LoadBalancer. Vérifiez que les adresses IP incluses dans le IPAddressPool ne sont pas réservées ou utilisées à d'autres fins, sinon la fonction d'équilibrage de charge risque d'échouer.

Exposition d'applications avec des routes Red Hat OpenShift

Exposent rapidement les services de votre cluster sur l'adresse IP externe du contrôleur Red Hat OpenShift Ingress en utilisant une route.

Une route Red Hat OpenShift expose un service en tant que nom d'hôte au format <service_name>-<project>.<cluster_name>-<random_hash>-0000.upi.containers.appdomain.cloud. Un contrôleur d'entrée Ingress est déployé par défaut sur votre cluster, ce qui permet aux clients externes d'utiliser des routes. Le contrôleur entrant utilise le sélecteur de service pour rechercher le service et les nœuds finaux qui le soutienne. Vous pouvez configurer le sélecteur de service pour diriger le trafic via une route vers plusieurs services. Vous pouvez également créer des routes sécurisées ou non sécurisées en utilisant le certificat TLS attribué par le contrôleur Ingress pour votre nom d'hôte. Notez que le contrôleur entrant prend en charge uniquement les protocoles HTTP et HTTPS.

Avant de commencer à utiliser les routes, passez en revue les remarques ci-après.

Connectivité réseau hôte
Si les hôtes de votre cluster disposent d'une connectivité réseau publique, votre cluster est créé avec un contrôleur Ingress public par défaut. Vous pouvez utiliser ce contrôleur Ingress pour créer des routes publiques pour votre application. Si les hôtes de votre cluster ne disposent que d'une connectivité réseau privée, votre cluster est créé par défaut avec un contrôleur Ingress privé. Vous pouvez utiliser ce contrôleur Ingress pour créer des routes privées pour votre application qui ne sont accessibles que depuis le réseau privé de vos hôtes. Pour configurer des routes publiques dans des clusters ayant une connectivité de réseau privé uniquement, le premier Configurer votre propre équilibreur de charge tiers qui dispose de la connectivité réseau public devant votre contrôleur Ingress privé avant d'effectuer les étapes suivantes.
Contrôles de santé
La gestion des enregistrements DNS est fournie par défaut pour le contrôleur Ingress de votre cluster. Par exemple, si vous supprimez un hôte qui a été affecté à votre cluster à partir de votre emplacement et remplacez-le par un autre hôte, IBM met à jour les adresses IP de l'hôte dans l'enregistrement DNS de votre contrôleur Ingress pour vous. Notez que si l'enregistrement DNS des routes est fourni pour vous, aucun service d'équilibrage de charge n'est déployé devant le contrôleur Ingress de votre cluster. Pour vérifier la santé des adresses IP des hôtes enregistrés dans les enregistrements DNS du contrôleur Ingress, vous pouvez Configurer votre propre équilibreur de charge tiers en face de votre contrôleur Ingress avant d'effectuer les étapes suivantes.

Afin de créer des routes pour vos applications :

  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. Configurez un domaine pour votre application.

    • Domaine fourni par IBM : Si vous n'avez pas besoin d'utiliser un domaine personnalisé, un nom d'hôte de route est généré pour vous au format <service_name>-<project>.<cluster_name>-<random_hash>-0000.upi.containers.appdomain.cloud. Passez à l'étape suivante.
    • Domaine personnalisé : collaborez avec votre fournisseur DNS pour créer un domaine personnalisé. Notez que si vous avez précédemment configuré un équilibreur de charge tiers devant votre contrôleur Ingress, travaillez avec votre fournisseur DNS pour créer un domaine personnalisé pour l'équilibreur de charge à la place.
  3. Récupère les adresses IP du service de contrôleur Ingress dans la colonne ADRESSE IP EXTERNE.

    oc get svc router-external-default -n openshift-ingress
    
  4. 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.

  5. Mettez en correspondance votre domaine personnalisé avec les adresses IP du contrôleur Ingress en ajoutant les adresses IP en tant qu'enregistrements A.

  6. Configurez une route basée sur le type de terminaison TLS requise par votre application. Si vous ne disposez pas d'un domaine personnalisé, n'utilisez pas l'option --hostname afin qu'un nom d'hôte de route soit généré automatiquement pour vous. 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`.
        {: tip}
    
    * 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 relative aux routes de périphérie « 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>]
        ```
    
  7. Vérifiez que la route pour votre application est créée.

    oc get routes
    
  8. Facultatif : Personnalisez 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 d'un équilibreur de charge tiers devant le contrôleur Red Hat OpenShift Ingress

Pour effectuer un contrôle de l'état des adresses IP des hôtes enregistrés dans les enregistrements DNS du contrôleur Ingress, vous pouvez configurer votre propre équilibreur de charge tiers en amont des adresses IP des hôtes affectés comme nœuds de travail à votre cluster.

Par exemple, si vous supprimez un hôte qui a été affecté à votre cluster à partir de votre emplacement et remplacez-le par un autre hôte, IBM met à jour les adresses IP de l'hôte dans l'enregistrement DNS de votre contrôleur Ingress pour vous. Mais si vous mettez un hôte hors tension, par exemple via la gestion de l'infrastructure de votre fournisseur de cloud computing, l'adresse IP de l'hôte n'est pas supprimée des enregistrements DNS de votre contrôleur Ingress et peut faire échouer un appel si l'enregistrement DNS est résolu à l'adresse IP de cet hôte. En installant un équilibreur de charge devant votre contrôleur Ingress, vous pouvez vous assurer que les adresses IP des hôtes sont régulièrement contrôlées, par exemple pour garantir la haute disponibilité des charges de travail de niveau production.

Après avoir créé un équilibreur de charge devant votre contrôleur Ingress, vous pouvez utiliser le contrôleur Ingress pour créer des routes pour votre application. Lorsqu'une demande est envoyée à la route pour votre application, la demande est d'abord reçue par votre équilibreur de charge avant d'être transmise à votre contrôleur Ingress, qui transmet ensuite la demande à votre application.

  1. Répertoriez les détails du contrôleur Ingress par défaut de votre cluster. Dans la colonne ADRESSE IP EXTERNE de la sortie, obtenez les adresses IP du noeud de travail qui sont enregistrées pour le contrôleur Ingress de votre cluster. Dans la colonne PORT (S) de la sortie, selon que vous souhaitez créer un équilibreur de charge public ou privé, obtenez le port de noeud que le service de contrôleur Ingress expose actuellement pour le trafic réseau public ou privé.

    oc get svc router-external-default -n openshift-ingress
    

    Dans l'exemple de sortie suivant, le port de noeud 30783 est exposé pour le trafic public (80) :

    NAME                      TYPE           CLUSTER-IP      EXTERNAL-IP                            PORT(S)                      AGE
    router-external-default   LoadBalancer   172.21.84.172   169.xx.xxx.xxx, 169.xx.xxx.xxx         80:30783/TCP,443:30413/TCP   24h
    
  2. A l'aide de ces adresses IP et du port de noeud, créez un équilibreur de charge de couche 4 connecté au réseau privé de vos hôtes. Par exemple, vous pouvez déployer un équilibreur de charge à partir du fournisseur de cloud de vos hôtes ou déployer un équilibreur de charge F5 sur votre réseau sur site. La création de routes publiques implique que l'équilibreur de charge dispose d'une connectivité au réseau public et qu'il soit capable de transférer du trafic TCP et UDP vers le port pour trafic public que vous avez identifié à l'étape précédente. La création de routes privées implique que l'équilibreur de charge soit capable de transférer du trafic TCP et UDP vers le port pour trafic privé que vous avez identifié à l'étape précédente.

  3. Récupérez le nom d'hôte de votre cluster. Ce sous-domaine au format <cluster_name>-<random_hash>-0000.upi.containers.appdomain.cloud est enregistré auprès du contrôleur Ingress de votre cluster.

    ibmcloud oc nlb-dns ls --cluster <cluster_name_or_ID>
    
  4. Ajoutez les adresses IP publiques de votre équilibreur de charge au sous-domaine de votre cluster. Répétez cette commande pour toutes les adresses IP publiques que vous souhaitez ajouter.

    ibmcloud oc nlb-dns add --ip <public_IP> --cluster <cluster_name_or_ID> --nlb-host <hostname>
    
  5. Retirez les adresses IP de noeud worker du sous-domaine de votre cluster. Répétez cette commande pour toutes les adresses IP que vous avez récupérées précédemment.

    ibmcloud oc nlb-dns rm classic --ip <private_IP> --cluster <cluster_name_or_ID> --nlb-host <hostname>
    
  6. Vérifiez que les adresses IP publiques de votre équilibreur de charge sont désormais enregistrées auprès du sous-domaine de votre cluster.

    ibmcloud oc nlb-dns ls --cluster <cluster_name_or_ID>
    
  7. Suivez les étapes décrites dans la rubrique Exposition d'applications avec des routes Red Hat OpenShift afin de créer des routes pour vos applications.

Si vous configurez un équilibreur de charge externe ou une adresse VIP pour qu'il s'enregistre auprès du sous-domaine plutôt que d'utiliser l'enregistrement par défaut, cet équilibreur de charge doit disposer d'un accès entrant vers les hôtes du cluster, et ces derniers doivent disposer d'un accès sortant vers l'équilibreur de charge.

Exposition d'applications avec des ports de noeud (NodePort)

Si vous ne pouvez pas utiliser le contrôleur Red Hat OpenShift Ingress pour exposer une application, par exemple si vous devez exposer une application TCP ou UDP, vous pouvez créer un Port du noeud pour votre application.

  1. Créez un port de noeud pour votre application. Un port de noeud compris entre 30000 et 32767 et une adresse IP de cluster interne sont affectés à votre application.

    oc expose deployment <deployment_name> --type=NodePort --name=<nodeport_svc_name>
    
  2. Récupérez le port de noeud qui a été affecté à votre application.

    oc describe svc <nodeport_svc_name>
    
  3. Récupérer le Nom d'hôte pour votre cluster au format <cluster_name>-<random_hash>-0000.upi.containers.appdomain.cloud.

    ibmcloud oc nlb-dns ls --cluster <cluster_name_or_ID>
    
  4. Accédez à votre application en utilisant le sous-domaine de votre cluster et le NodePort au format <cluster_name>-<random_hash>-0000.upi.containers.appdomain.cloud:<nodeport>. Notez que si vos hôtes disposent uniquement d'une connectivité au réseau privé, vous devez être connecté au réseau privé des hôtes, par exemple via un accès VPN.

  5. Facultatif : Si vous ne voulez pas accéder directement au NodePort, ou si vous devez exposer vos applications sur un port spécifique tel que 443, vous pouvez configurer votre propre tiers, équilibreur de charge de couche 4 qui est connecté au réseau privé de vos hôtes et transmet le trafic vers le NodePort. Par exemple, vous pouvez déployer un équilibreur de charge à partir du fournisseur de cloud de vos hôtes ou déployer un équilibreur de charge F5 sur votre réseau sur site. L'équilibreur de charge doit être capable de transférer le trafic provenant des adresses TCP et UDP vers les ports 30000 - 32767.

Exposition d'applications avec des routes et des noeuds finaux de liaison pour le trafic depuis IBM Cloud

Si vous souhaitez accéder à une application dans votre cluster Satellite à partir d'une ressource de IBM Cloud sur le réseau privé, vous pouvez utiliser votre contrôleur Ingress privé pour créer une route privée pour votre application. Vous pouvez ensuite créer un noeud final de liaison de type location pour la route, qui est accessible uniquement depuis le réseau privé IBM Cloud.

  1. Suivez les étapes décrites dans la rubrique Exposition d'applications avec des routes Red Hat OpenShift afin de créer une route privée pour votre application. Cette route n'est accessible qu'à partir du réseau privé de vos hôtes.

  2. Suivez les étapes décrites dans la rubrique relative à la création de noeuds finaux location pour se connecter à des ressources dans un emplacement afin de créer un noeud final de liaison Satellite pour la route privée de votre application.

  3. Facultatif : pour autoriser l'accès au noeud final uniquement à partir de la ressource spécifique dans IBM Cloud, ajoutez la ressource à la liste source de votre noeud final.