Choix d'un service d'exposition d'application

Securely expose your apps to external traffic by using Red Hat OpenShift Ingress controller or IBM Cloud® Kubernetes Service NodePort, or network load balancer.

Description des options d'exposition d'applications

Pour rendre vos applications accessibles au trafic externe en toute sécurité, vous pouvez choisir parmi les services suivants.

Contrôleur d'entrée Red Hat OpenShift

Exposez plusieurs applications au sein d'un cluster en configurant le routage à l'aide du contrôleur Ingress « Red Hat OpenShift ». Le contrôleur Ingress utilise le sous-domaine Ingress comme point d'entrée public ou privé unique et sécurisé pour acheminer les demandes entrantes. Vous pouvez utiliser un seul sous-domaine pour exposer plusieurs applications dans votre cluster sous forme de services. La solution de contrôleur Ingress utilise trois composants.

L'opérateur Ingress qui gère les contrôleurs d'entrée de votre cluster.
Le contrôleur Ingress est un service Kubernetes basé sur HAProxy qui gère tout le trafic entrant pour les applications de votre cluster en implémentant des règles de routage pour les applications. Ce contrôleur est géré par l'opérateur Ingress. Le contrôleur d'entrée est à l'écoute des demandes de service HTTP entrantes ou HTTPS, puis transmet les demandes aux pods pour cette application uniquement en fonction des règles définies dans la ressource entrante et implémentée par le contrôleur entrant.
La ressource de route définit les règles de routage et de chargement des demandes entrantes pour une application.

Une route expose un service en tant que nom d'hôte au format <service_name>-<project>.<cluster_name>-<random_hash>-0000.<region>.containers.appdomain.cloud. Un contrôleur entrant est déployé par défaut sur votre cluster, ce qui permet aux routes d'être utilisées par des clients externes. 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 non sécurisées ou sécurisées à l'aide du certificat TLS affecté par le contrôleur entrant pour votre nom d'hôte. Notez que le contrôleur entrant prend en charge uniquement les protocoles HTTP et HTTPS.

NodePort

Lorsque vous exposez des applications avec un service NodePort, une valeur de port de noeud (NodePort) comprise entre 30000 et 32767 et une adresse IP interne de cluster sont affectées au service. Pour accéder au service à partir de l'extérieur du cluster, vous utilisez l'adresse IP publique ou privée de tout noeud worker et NodePort au format <IP_address>:<nodeport>. Toutefois, les adresses IP publique et privée du noeud worker ne sont pas permanentes. Lorsqu'un noeud worker est supprimé ou recréé, une nouvelle adresse IP publique et une nouvelle adresse IP privée sont affectées au noeud worker. Les valeurs NodePort sont idéales pour tester un accès public ou privé ou pour fournir un accès sur une courte période.

LoadBalancer

Le type de service LoadBalancer est implémenté différemment selon le fournisseur d'infrastructure de votre cluster.

Clusters classiques : Equilibreur de charge de réseau (NLB). Chaque cluster standard est mis à disposition avec quatre adresses IP publiques portables et quatre adresses IP privées portables que vous pouvez utiliser pour créer un équilibreur de charge de réseau (NLB) TCP/UDP pour votre application. Vous pouvez personnaliser votre équilibreur de charge de réseau en exposant n'importe quel port dont votre application a besoin. Les adresses IP publiques et privées portables affectées au NLB sont permanentes et ne changent pas lorsqu'un noeud worker est recréé dans le cluster. Si vous créez des équilibreurs de charge de réseau publics, vous pouvez créer un sous-domaine pour votre application qui enregistre les adresses IP d'équilibreur de charge de réseau publiques avec une entrée DNS. Vous pouvez également activer des moniteurs de diagnostic d'intégrité sur les adresses IP d'équilibreur de charge de réseau (NLB) pour chaque sous-domaine.
Clusters de VPC : Equilibreur de charge pour VPC. Lorsque vous créez un service Kubernetes LoadBalancer pour une application dans votre cluster, un équilibreur de charge VPC est automatiquement créé dans votre VPC, en dehors de votre cluster. L'équilibreur de charge VPC comprend plusieurs zones et achemine des demandes pour votre application via les ports de noeud privés qui sont automatiquement ouverts sur vos noeuds worker. Par défaut, l'équilibreur de charge est également créé avec un nom d'hôte que vous pouvez utiliser pour accéder à votre application, mais vous pouvez également créer un sous-domaine pour votre application qui crée une entrée DNS.

Ingress

Vous pouvez utiliser Ingress pour exposer votre application au trafic externe via le contrôleur Ingress Red Hat OpenShift. Le gestionnaire du contrôleur Red Hat OpenShift convertit les ressources entrantes en ressources d'acheminement et le contrôleur entrant Red Hat OpenShift traite ces routes.

Choix d'une solution d'équilibrage de charge

Maintenant que vous connaissez les options à votre disposition pour exposer des applications dans un cluster Red Hat OpenShift, choisissez la meilleure solution pour votre charge de travail.

Le tableau suivant compare les fonctions de chaque méthode d'exposition d'application :

Comparaison des réseaux externes pour les applications dans Red Hat OpenShift les clusters.
Caractéristiques	équilibreur de charge (classique - équilibreur de charge de réseau)	LoadBalancer (équilibreur de charge VPC)	Contrôleur Ingress
Adresse IP externe stable	Oui		Oui
Nom d'hôte externe	Oui	Oui	Oui
Arrêt SSL	Oui*	Oui*	Oui
Equilibrage de charge HTTP(S)			Oui
Règles de routage personnalisées			Oui
Plusieurs applications par route ou service			Oui
Déploiement multicloud hybride cohérent			Oui

* l'arrêt SSL est fourni par des commandes ibmcloud oc nlb-dns. Dans les clusters classiques, ces commandes sont prises en charge uniquement pour les équilibreurs de charge de réseau public.

Planification d'un équilibrage de charge externe public

Exposez au public une application de votre cluster sur Internet.

Dans les clusters classiques, vos noeuds worker sont connectés à un VLAN public. Le VLAN public détermine l'adresse IP publique qui est affectée à chaque noeud worker, ce qui offre à chaque noeud worker une interface réseau publique. Les services de mise en réseau public se connectent à cette interface de réseau public en fournissant à votre application une adresse IP publique et, le cas échéant, une URL publique.

Dans les clusters VPC, vos noeuds worker sont connectés uniquement aux sous-réseaux VPC privés. Toutefois, lorsque vous créez des services de réseau public, un équilibreur de charge VPC est automatiquement créé. L'équilibreur de charge VPC peut acheminer les demandes publiques vers votre application en fournissant une URL publique à votre application. Lorsqu'une application est exposée au public, quiconque disposant de l'URL publique peut envoyer une demande à votre application.

Lorsqu'une application est exposée au public, quiconque disposant de l'adresse IP de service public ou de l'URL que vous avez configurée pour votre application peut envoyer une demande à cette dernière. C'est pourquoi il est recommandé d'exposer le moins d'applications possible. Exposez une application au public uniquement lorsque vous êtes prêt à accepter du trafic provenant de clients Web ou d'utilisateurs externes.

L'interface réseau publique des noeuds worker est protégée par des paramètres de règles réseau Calico prédéfinis qui sont configurés sur tous les noeuds worker lors de la création du cluster. Par défaut, tout le trafic réseau sortant est autorisé pour tous les noeuds worker. Le trafic réseau entrant est bloqué à l'exception de quelques ports. Ces ports sont ouverts de sorte qu'IBM puisse surveiller le trafic réseau et installer automatiquement les mises à jour de sécurité pour le maître Kubernetes et que les connexions puissent être établies avec les services de mise en réseau public. Pour plus d'informations sur ces règles, y compris comment les modifier, voir Règles réseau.

Mise en réseau d'application publique pour les clusters classiques

Pour rendre une application accessible au public sur Internet dans un cluster classique, choisissez une méthode d'exposition d'application qui utilise des routes, des services NodePort, des équilibreurs de charge de réseau (NLB) ou qui configure Ingress. Le tableau ci-après décrit chaque méthode possible, et explique pour quelle raison l'utiliser et comment la configurer. Pour obtenir des informations de base sur les services de mise en réseau répertoriés, voir Description des types de service Kubernetes.

Vous ne pouvez pas utiliser plusieurs méthodes d'exposition pour une application.

Présentation des méthodes d'exposition d'application publique
Nom	Méthode d'équilibrage de charge	Cas d'utilisation	Implémentation
Route	Equilibrage de charge HTTP(S) qui expose l'application avec un sous-domaine et utilise des règles de routage personnalisées.	Implémenter des règles de routage personnalisées et l'arrêt SSL pour plusieurs applications. Choisissez cette méthode pour rester native Red Hat OpenShift ; par exemple, vous pouvez utiliser la console Web Red Hat OpenShift pour créer et gérer des routes. Créez un service « `ClusterIP` » pour attribuer une adresse IP interne à votre application. Établissez un itinéraire Red Hat OpenShift. Personnalisez les règles de routage avec des configurations facultatives.
NodePort	Port sur un noeud worker qui expose l'application sur l'adresse IP publique du noeud worker.	Tester l'accès public à une application ou fournir un accès pendant une courte période.	Créez un service NodePort public.
NLB v1.0 (+ sous-domaine)	Equilibrage de charge de base qui expose l'application avec une adresse IP ou un sous-domaine.	Exposer rapidement une application au public avec une adresse IP ou un sous-domaine qui prend en charge l'arrêt SSL.	Créez un équilibreur de charge de réseau public (NLB) 1.0 dans un cluster à zone unique ou multizone. Le cas échéant, enregistrez un sous-domaine et des diagnostics d'intégrité.
NLB v2.0 (+ sous-domaine)	Equilibrage de charge DSR qui expose l'application avec une adresse IP ou un sous-domaine.	Exposez une application qui peut recevoir des niveaux élevés de trafic vers le public avec une adresse IP ou un sous-domaine prenant en charge l'arrêt SSL. Achevez les prérequis. Créez un NLB 2.0 public dans un cluster Unique ou à zones multiples . Le cas échéant, enregistrez un sous-domaine et des diagnostics d'intégrité.
Contrôleur Ingress	Equilibrage de charge HTTP(S) qui expose l'application avec un sous-domaine et utilise des règles de routage personnalisées.	Implémenter des règles de routage personnalisées et l'arrêt SSL pour plusieurs applications.	Créez une ressource entrante . Pour le contrôleur public par défaut entrant.

Mise en réseau d'application publique pour les clusters de VPC

Pour rendre une application accessible au public sur Internet dans un cluster VPC, choisissez une méthode d'exposition d'application qui utilise des routes, des équilibreurs de charge VPC ou qui configure Ingress. Le tableau ci-après décrit chaque méthode possible, et explique pour quelle raison l'utiliser et comment la configurer. Pour obtenir des informations de base sur les services de mise en réseau répertoriés, voir Description des types de service Kubernetes.

Vous ne pouvez pas utiliser plusieurs méthodes d'exposition pour une application.

Présentation des méthodes d'exposition d'application publique
Nom	Méthode d'équilibrage de charge	Cas d'utilisation	Implémentation
Route	Equilibrage de charge HTTP(S) qui expose l'application avec un sous-domaine et utilise des règles de routage personnalisées.	Implémenter des règles de routage personnalisées et l'arrêt SSL pour plusieurs applications. Choisissez cette méthode pour rester dans un environnement Red Hat OpenShift natif ; par exemple, vous pouvez utiliser la console Web Red Hat OpenShift pour créer et gérer des routes.	Créez une route à l'aide du contrôleur public par défaut Ingress dans les clusters avec un noeud final de service de cloud public, ou créez une route à l'aide d'un contrôleur d'entrée public personnalisé dans les clusters avec un noeud final de service de cloud privé uniquement.
Équilibreur de charge de VPC	Equilibrage de charge de base qui expose l'application avec un nom d'hôte.	Exposer rapidement une application au public avec un nom d'hôte affecté par un équilibreur de charge VPC.	Créez un service `LoadBalancer` public dans votre cluster. Un équilibreur de charge VPC multizone est automatiquement créé dans votre VPC qui affecte un nom d'hôte à votre service `LoadBalancer` pour votre application.
Ingress	Equilibrage de charge HTTP(S) qui expose l'application avec un sous-domaine et utilise des règles de routage personnalisées.	Implémenter des règles de routage personnalisées et l'arrêt SSL pour plusieurs applications.	Créez une ressource Ingress pour le contrôleur Ingress public par défaut dans des clusters avec un noeud final de service cloud public ou créez une ressource Ingress pour un contrôleur Ingress public personnalisé dans des clusters avec un noeud final de service cloud privé uniquement.

Planification d'un équilibrage de charge externe privé

Exposez en privé une application de votre cluster sur le réseau privé uniquement.

Lorsque vous déployez une application dans un cluster Kubernetes dans IBM Cloud Kubernetes Service, vous souhaitez peut-être rendre l'application accessible uniquement aux utilisateurs et services qui se trouvent sur le même réseau privé que votre cluster. L'équilibrage de charge privé est idéal pour rendre votre application disponible pour des demandes depuis l'extérieur du cluster sans exposer l'application au public général. Vous pouvez également utiliser l'équilibrage de charge privé pour tester des accès, demander du routage et d'autres configurations pour votre application avant de l'exposer ultérieurement au public avec des services réseau public.

A titre d'exemple, admettons que vous ayez créé un équilibreur de charge de réseau privé pour votre application. Cet équilibreur de charge de réseau privé est accessible à :

Tout pod figurant dans le même cluster.
Tout pod figurant dans n'importe quel cluster dans le même compte IBM Cloud.
Si vous n'êtes pas dans le compte IBM Cloud mais toujours derrière le pare-feu de l'entreprise, tout système via une connexion VPN au sous-réseau sur lequel figure l'adresse IP de l'équilibreur de charge.
Si vous n'êtes pas dans le compte IBM Cloud, tout système via une connexion VPN au sous-réseau sur lequel figure l'adresse IP de l'équilibreur de charge.
Dans les clusters classiques, si la fonction VRF ou Spanning VLAN est activée, tout système connecté à l'un des VLAN privés dans le même compte IBM Cloud.
Dans les clusters de VPC :
- Si le trafic est autorisé entre les sous-réseaux VPC, n'importe quel système dans le même VPC.
- Si le trafic est autorisé entre les VPC, n'importe quel système ayant accès au VPC dans lequel se trouve le cluster.

Mise en réseau d'application privée pour les clusters classiques

Lorsque vos noeuds worker sont connectés à la fois à un VLAN public et à un VLAN privé, vous pouvez rendre votre application accessible uniquement à partir d'un réseau privé en créant des routes privées, des services NodePort, des NLB ou en configurant Ingress. Ensuite, vous pouvez créer des règles Calico pour bloquer le trafic public vers ces services.

Etant donné que les règles réseau Calico par défaut autorisent le trafic public entrant dans ces services, vous pouvez créer des règles Calico pour bloquer tout le trafic public vers ces services. Par exemple, un service NodePort ouvre un port sur un noeud worker via à la fois l'adresse IP privée et l'adresse IP publique du noeud worker. Un service d'équilibreur de charge de réseau avec une adresse IP privée portable ouvre un service NodePort public sur tous les noeuds worker. Vous devez créer une règle réseau pré-DNAT Calico pour bloquer les ports de noeud publics.

Découvrez les méthodes de mise en réseau d'application privée suivantes :

Caractéristiques des modèles de déploiement de réseau pour une configuration de VLAN public et privé
Nom	Méthode d'équilibrage de charge	Cas d'utilisation	Implémentation
Route	Equilibrage de charge HTTP(S) qui expose l'application avec un sous-domaine et utilise des règles de routage personnalisées.	Implémenter des règles de routage personnalisées et l'arrêt SSL pour plusieurs applications. Choisissez cette méthode pour rester dans un environnement Red Hat OpenShift natif ; par exemple, vous pouvez utiliser la console Web Red Hat OpenShift pour créer et gérer des routes.	Créez un service `ClusterIP` pour attribuer une adresse IP interne à votre application. Créer un contrôleur Ingress exposé par un équilibreur de charge privé. Établissez un itinéraire Red Hat OpenShift. Personnaliser les règles de routage à l'aide de configurations optionnelles.
NodePort	Port sur un noeud worker qui expose l'application sur l'adresse IP privée du noeud worker.	Tester l'accès privé sur une application ou fournir un accès pendant une courte période.	Créer un service NodePort. Un service NodePort ouvre un port sur un noeud worker via à la fois l'adresse IP privée et l'adresse IP publique du noeud worker. Vous devez utiliser une règle réseau pré-DNAT Calico pour bloquer le trafic vers les ports de noeud publics.
NLB 1.0	Equilibrage de charge de base qui expose l'application avec une adresse IP privée.	Exposer rapidement une application à un réseau privé avec une adresse IP privée.	Créer un service NLB privé. Un NLB doté d'une adresse IP privée portable dispose toujours d'un port de nœud public ouvert sur chaque nœud de travail. Créez une règle réseau pré-DNAT Calico pour bloquer le trafic vers les ports de noeud publics.
NLB v2.0	Equilibrage de charge DSR qui expose l'application avec une adresse IP privée.	Exposer une application qui peut recevoir des niveaux élevés de trafic sur un réseau privé avec une adresse IP.	Remplir les conditions préalables. Créer un site privé NLB 2.0 dans un cluster simple ou multizone. Un NLB doté d'une adresse IP privée portable dispose toujours d'un port de nœud public ouvert sur chaque nœud de travail. Créez une règle réseau pré-DNAT Calico pour bloquer le trafic vers les ports de noeud publics.
Ingress	Equilibrage de charge HTTP(S) qui expose l'application avec un sous-domaine et utilise des règles de routage personnalisées.	Implémenter des règles de routage personnalisées et l'arrêt SSL pour plusieurs applications.	Voir Exposition publique d'applications avec Ingress

Mise en réseau d'application privée pour les clusters de VPC

Pour rendre une application disponible sur un réseau privé uniquement dans un cluster VPC, choisissez un modèle de déploiement d'équilibrage de charge en fonction de la configuration du noeud final de service de votre cluster : noeud final de service de cloud public et privé, ou noeud final de service de cloud privé uniquement. Pour chaque configuration de noeud final de service, le tableau ci-après décrit chaque méthode d'exposition possible, et explique pour quelle raison l'utiliser et comment le configurer.

Modèles de déploiement de réseau privé pour un cluster de VPC
Nom	Méthode d'équilibrage de charge	Cas d'utilisation	Implémentation
Route	Equilibrage de charge HTTP(S) qui expose l'application avec un sous-domaine et utilise des règles de routage personnalisées.	Implémenter des règles de routage personnalisées et l'arrêt SSL pour plusieurs applications. Choisissez cette méthode pour rester dans un environnement Red Hat OpenShift natif ; par exemple, vous pouvez utiliser la console Web Red Hat OpenShift pour créer et gérer des routes.	Créez un contrôleur entrant à l'aide du contrôleur entrant privé par défaut dans les clusters avec un noeud final de service de cloud privé uniquement ou créez une route à l'aide d'un contrôleur d'entrée privé personnalisé dans les clusters avec un noeud final de service de cloud public.
NodePort	Port sur un noeud worker qui expose l'application sur l'adresse IP privée du noeud worker.	Tester l'accès privé sur une application ou fournir un accès pendant une courte période.	Créez un service NodePort privé.
Équilibreur de charge de VPC	Equilibrage de charge de base qui expose l'application avec un nom d'hôte privé	Exposer rapidement une application sur un réseau privé avec un nom d'hôte privé affecté par un équilibreur de charge PVC.	Créez un service `LoadBalancer` privé dans votre cluster. Un équilibreur de charge VPC multizone est automatiquement créé dans votre VPC qui affecte un nom d'hôte à votre service `LoadBalancer` pour votre application.
Ingress	Equilibrage de charge HTTP(S) qui expose l'application avec un sous-domaine et utilise des règles de routage personnalisées.	Implémenter des règles de routage personnalisées et l'arrêt SSL pour plusieurs applications.	Créez une ressource Ingress pour le contrôleur Ingress privé par défaut dans des clusters avec un noeud final de service cloud privé uniquement ou créez une ressource Ingress pour un contrôleur Ingress privé personnalisé dans des clusters avec un noeud final de service cloud public.