Chapitre 15. Configuration du basculement IP
Cette rubrique décrit la configuration du basculement IP pour les pods et les services sur votre cluster OpenShift Container Platform.
Le basculement IP gère un pool d'adresses IP virtuelles (VIP) sur un ensemble de nœuds. Chaque adresse VIP de l'ensemble est desservie par un nœud sélectionné dans l'ensemble. Tant qu'un seul nœud est disponible, les VIP sont desservis. Il n'existe aucun moyen de répartir explicitement les adresses VIP entre les nœuds, de sorte qu'il peut y avoir des nœuds sans adresses VIP et d'autres nœuds avec de nombreuses adresses VIP. S'il n'y a qu'un seul nœud, tous les VIP s'y trouvent.
Les VIP doivent être routables depuis l'extérieur du cluster.
Le basculement IP surveille un port sur chaque VIP afin de déterminer si le port est accessible sur le nœud. Si le port n'est pas accessible, le VIP n'est pas affecté au nœud. Si le port est défini sur 0, cette vérification est supprimée. Le script de contrôle effectue les tests nécessaires.
Le basculement IP utilise Keepalived pour héberger un ensemble d'adresses VIP accessibles de l'extérieur sur un ensemble d'hôtes. Chaque VIP n'est desservi que par un seul hôte à la fois. Keepalived utilise le protocole VRRP (Virtual Router Redundancy Protocol) pour déterminer quel hôte, parmi l'ensemble des hôtes, dessert quel VIP. Si un hôte devient indisponible, ou si le service que Keepalived surveille ne répond pas, le VIP est basculé sur un autre hôte de l'ensemble. Cela signifie qu'un VIP est toujours servi tant qu'un hôte est disponible.
Lorsqu'un nœud exécutant Keepalived passe le script de contrôle, le VIP sur ce nœud peut entrer dans l'état master en fonction de sa priorité et de la priorité du maître actuel et selon la stratégie de préemption.
Un administrateur de cluster peut fournir un script via la variable OPENSHIFT_HA_NOTIFY_SCRIPT, et ce script est appelé chaque fois que l'état du VIP sur le nœud change. Keepalived utilise l'état master lorsqu'il gère le VIP, l'état backup lorsqu'un autre noeud gère le VIP, ou l'état fault lorsque le script de vérification échoue. Le script de notification est appelé avec le nouvel état à chaque fois que l'état change.
Vous pouvez créer une configuration de déploiement de basculement IP sur OpenShift Container Platform. La configuration de déploiement de basculement IP spécifie l'ensemble des adresses VIP et l'ensemble des nœuds sur lesquels ils sont gérés. Un cluster peut avoir plusieurs configurations de déploiement de basculement IP, chacune gérant son propre ensemble d'adresses VIP uniques. Chaque nœud de la configuration de basculement IP exécute un pod de basculement IP, et ce pod exécute Keepalived.
Lorsque l'on utilise des VIP pour accéder à un pod avec un réseau hôte, le pod d'application s'exécute sur tous les nœuds qui exécutent les pods de basculement IP. Cela permet à n'importe quel nœud de basculement IP de devenir le maître et de desservir les VIP en cas de besoin. Si les modules d'application ne sont pas exécutés sur tous les nœuds avec basculement IP, certains nœuds de basculement IP ne desservent jamais les VIP ou certains modules d'application ne reçoivent jamais de trafic. Utilisez le même sélecteur et le même nombre de réplications, à la fois pour le basculement IP et pour les modules d'application, afin d'éviter cette incohérence.
Lorsque l'on utilise des VIP pour accéder à un service, n'importe quel nœud peut faire partie de l'ensemble de nœuds de basculement IP, puisque le service est accessible sur tous les nœuds, quel que soit l'endroit où s'exécute le module d'application. N'importe lequel des nœuds de basculement IP peut devenir maître à tout moment. Le service peut soit utiliser des IP externes et un port de service, soit utiliser une adresse NodePort.
Lors de l'utilisation d'IP externes dans la définition du service, les VIP sont définis sur les IP externes et le port de surveillance du basculement d'IP est défini sur le port du service. Lors de l'utilisation d'un port de nœud, le port est ouvert sur chaque nœud du cluster et le service équilibre le trafic à partir du nœud qui dessert actuellement le VIP. Dans ce cas, le port de surveillance du basculement IP est défini sur NodePort dans la définition du service.
La mise en place d'un site NodePort est une opération privilégiée.
Même si un service VIP est hautement disponible, les performances peuvent encore être affectées. Keepalived s'assure que chaque VIP est desservi par un nœud de la configuration, et plusieurs VIP peuvent se retrouver sur le même nœud même si d'autres nœuds n'en ont pas. Les stratégies qui équilibrent la charge de manière externe sur un ensemble de VIP peuvent être contrecarrées lorsque le basculement IP place plusieurs VIP sur le même nœud.
Lorsque vous utilisez ingressIP, vous pouvez configurer le basculement IP pour avoir la même plage VIP que la plage ingressIP. Vous pouvez également désactiver le port de surveillance. Dans ce cas, tous les VIP apparaissent sur le même nœud du cluster. Tout utilisateur peut configurer un service avec ingressIP et le rendre hautement disponible.
Il y a un maximum de 254 VIP dans le cluster.
15.1. Variables d'environnement pour le basculement IP
Le tableau suivant contient les variables utilisées pour configurer le basculement IP.
| Nom de la variable | Défaut | Description |
|---|---|---|
|
|
|
Le module de basculement IP tente d'ouvrir une connexion TCP à ce port sur chaque IP virtuelle (VIP). Si la connexion est établie, le service est considéré comme étant en cours d'exécution. Si ce port est défini sur |
|
|
Nom de l'interface que le basculement IP utilise pour envoyer le trafic VRRP (Virtual Router Redundancy Protocol). La valeur par défaut est | |
|
|
|
Le nombre de répliques à créer. Il doit correspondre à la valeur |
|
|
La liste des plages d'adresses IP à répliquer. Elle doit être fournie. Par exemple, | |
|
|
|
La valeur de décalage utilisée pour définir les ID des routeurs virtuels. L'utilisation de différentes valeurs de décalage permet à plusieurs configurations de basculement IP d'exister au sein d'un même cluster. Le décalage par défaut est |
|
|
Le nombre de groupes à créer pour VRRP. S'il n'est pas défini, un groupe est créé pour chaque plage IP virtuelle spécifiée avec la variable | |
|
| ENTRÉE |
Le nom de la chaîne iptables, pour ajouter automatiquement une règle |
|
| Le nom du chemin complet dans le système de fichiers pod d'un script qui est périodiquement exécuté pour vérifier que l'application fonctionne. | |
|
|
| Période, en secondes, pendant laquelle le script de contrôle est exécuté. |
|
| Le nom du chemin complet dans le système de fichiers pod d'un script qui est exécuté chaque fois que l'état change. | |
|
|
|
La stratégie de gestion d'un nouvel hôte de priorité supérieure. La stratégie |
