Chapitre 11. Configuration de la stratégie de publication des points d'extrémité du contrôleur d'entrée
11.1. Stratégie de publication des points d'extrémité du contrôleur d'entrée
NodePortService endpoint publishing strategy
La stratégie de publication des points d'extrémité NodePortService publie le contrôleur d'ingestion à l'aide d'un service NodePort de Kubernetes.
Dans cette configuration, le déploiement du contrôleur d'entrée utilise un réseau de conteneurs. Un site NodePortService est créé pour publier le déploiement. Les ports de nœuds spécifiques sont alloués dynamiquement par OpenShift Container Platform ; toutefois, pour prendre en charge les allocations de ports statiques, les modifications apportées au champ node port du site NodePortService géré sont conservées.
Figure 11.1. Diagramme de NodePortService
Le graphique précédent illustre les concepts suivants relatifs à la stratégie de publication des points d'extrémité Ingress NodePort d'OpenShift Container Platform :
- Tous les nœuds disponibles dans la grappe ont leur propre adresse IP, accessible de l'extérieur. Le service fonctionnant dans la grappe est lié à l'unique NodePort de tous les nœuds.
-
Lorsque le client se connecte à un nœud en panne, par exemple en connectant l'adresse IP
10.0.128.4dans le graphique, le port du nœud connecte directement le client à un nœud disponible qui exécute le service. Dans ce scénario, aucun équilibrage de charge n'est nécessaire. Comme le montre l'image, l'adresse10.0.128.4est hors service et une autre adresse IP doit être utilisée à la place.
L'opérateur d'entrée ignore toute mise à jour des champs .spec.ports[].nodePort du service.
Par défaut, les ports sont attribués automatiquement et vous pouvez accéder aux attributions de ports pour les intégrations. Cependant, il est parfois nécessaire d'allouer des ports statiques pour s'intégrer à l'infrastructure existante, qui peut ne pas être facilement reconfigurée en réponse aux ports dynamiques. Pour réaliser des intégrations avec des ports de nœuds statiques, vous pouvez mettre à jour la ressource de service géré directement.
Pour plus d'informations, consultez la documentation sur les services Kubernetes à l'adresse NodePort.
HostNetwork endpoint publishing strategy
La stratégie de publication des points d'extrémité HostNetwork publie le contrôleur d'entrée sur les ports des nœuds où le contrôleur d'entrée est déployé.
Un contrôleur d'entrée doté de la stratégie de publication de points finaux HostNetwork ne peut avoir qu'une seule réplique de pod par nœud. Si vous voulez des répliques n, vous devez utiliser au moins des nœuds n où ces répliques peuvent être planifiées. Étant donné que chaque réplique de pod demande les ports 80 et 443 sur l'hôte du nœud où elle est planifiée, une réplique ne peut pas être planifiée sur un nœud si un autre pod sur le même nœud utilise ces ports.
11.1.1. Configuration de l'étendue de la publication du contrôleur d'entrée sur Interne
Lorsqu'un administrateur de cluster installe un nouveau cluster sans spécifier qu'il s'agit d'un cluster privé, le contrôleur d'entrée par défaut est créé avec un scope défini sur External. Les administrateurs de clusters peuvent modifier un contrôleur d'entrée à portée External en Internal.
Conditions préalables
-
Vous avez installé le CLI
oc.
Procédure
Pour modifier un contrôleur d'entrée à portée de
ExternalenInternal, entrez la commande suivante :$ oc -n openshift-ingress-operator patch ingresscontrollers/default --type=merge --patch='{"spec":{"endpointPublishingStrategy":{"type":"LoadBalancerService","loadBalancer":{"scope":"Internal"}}}}'Pour vérifier l'état du contrôleur d'entrée, entrez la commande suivante :
$ oc -n openshift-ingress-operator get ingresscontrollers/default -o yaml
La condition d'état
Progressingindique si vous devez prendre d'autres mesures. Par exemple, la condition d'état peut indiquer que vous devez supprimer le service en entrant la commande suivante :$ oc -n openshift-ingress delete services/router-default
Si vous supprimez le service, l'opérateur d'entrée le recrée en tant que
Internal.
11.1.2. Configuration de l'étendue de la publication du point d'extrémité du contrôleur d'entrée sur Externe
Lorsqu'un administrateur de cluster installe un nouveau cluster sans spécifier qu'il s'agit d'un cluster privé, le contrôleur d'entrée par défaut est créé avec une adresse scope définie sur External.
La portée du contrôleur d'entrée peut être configurée pour être Internal pendant l'installation ou après, et les administrateurs de clusters peuvent changer un contrôleur d'entrée Internal en External.
Sur certaines plateformes, il est nécessaire de supprimer et de recréer le service.
La modification de l'étendue peut perturber le trafic Ingress, potentiellement pendant plusieurs minutes. Cela s'applique aux plateformes où il est nécessaire de supprimer et de recréer le service, car la procédure peut amener OpenShift Container Platform à déprovisionner l'équilibreur de charge du service existant, à en provisionner un nouveau et à mettre à jour le DNS.
Conditions préalables
-
Vous avez installé le CLI
oc.
Procédure
Pour modifier un contrôleur d'entrée à portée de
InternalenExternal, entrez la commande suivante :$ oc -n openshift-ingress-operator patch ingresscontrollers/private --type=merge --patch='{"spec":{"endpointPublishingStrategy":{"type":"LoadBalancerService","loadBalancer":{"scope":"External"}}}}'Pour vérifier l'état du contrôleur d'entrée, entrez la commande suivante :
$ oc -n openshift-ingress-operator get ingresscontrollers/default -o yaml
La condition d'état
Progressingindique si vous devez prendre d'autres mesures. Par exemple, la condition d'état peut indiquer que vous devez supprimer le service en entrant la commande suivante :$ oc -n openshift-ingress delete services/router-default
Si vous supprimez le service, l'opérateur d'entrée le recrée en tant que
External.
