Red Hat OpenShift sur RHV est conçu pour séparer logiquement le trafic réseau à différents fins à l'aide de réseaux locaux virtuels (VLAN). Cette configuration peut être adaptée aux besoins du client ou pour assurer une isolation supplémentaire pour des services réseau spécifiques. Le tableau suivant répertorie les VLAN nécessaires à la mise en œuvre de la solution lors de sa validation chez NetApp.

L'infrastructure suivante doit être en place avant le déploiement de la plateforme de conteneurs OpenShift :

L'architecture vérifiée décrite dans ce document présente le déploiement matériel minimum adapté aux opérations haute disponibilité en déployant deux nœuds d'hyperviseur RHV-H, et en assurant une configuration avec tolérance aux pannes dans laquelle les deux hôtes peuvent gérer le moteur hébergé et les VM déployés peuvent migrer entre les deux hyperviseurs.

Red Hat OpenShift se déployant initialement avec trois nœuds maîtres, il est garanti dans une configuration à deux nœuds qui occupera au moins deux maîtres, ce qui peut entraîner une interruption possible pour OpenShift si ce nœud spécifique devient indisponible. C'est donc une meilleure pratique de Red Hat qu'au moins trois nœuds d'hyperviseur RHV-H peuvent être déployés dans le cadre de la solution de façon à ce que les maîtres OpenShift puissent être distribués uniformément et que la solution bénéficie d'un degré de tolérance aux pannes supplémentaire.

Vous pouvez distribuer les maîtres OpenShift sur plusieurs nœuds d'hyperviseur en activant l'affinité VM/hôte.

L'affinité est un moyen de définir des règles pour un ensemble de VM et/ou d'hôtes qui déterminent si les VM s'exécutent sur le même hôte ou sur des hôtes du groupe ou sur des hôtes différents. Elle est appliquée aux VM par la création de groupes d'affinités comprenant des VM et/ou des hôtes avec un ensemble de paramètres et de conditions identiques. Selon que les VM d'un groupe d'affinité s'exécutent sur le même hôte ou sur les hôtes du groupe ou séparément sur des hôtes différents, les paramètres du groupe d'affinités peuvent définir une affinité positive ou négative.

Les conditions définies pour les paramètres peuvent être soit application stricte, soit application souple. Une mise en œuvre stricte permet de garantir que les VM d'un groupe d'affinité suivent toujours l'affinité positive ou négative strictement sans égard aux conditions externes. La mise en œuvre logicielle garantit qu'une préférence plus élevée est définie pour les VM d'un groupe d'affinité afin de suivre l'affinité positive ou négative lorsque cela est possible. Dans la configuration à deux ou trois hyperviseurs décrite dans ce document, soft affinité est le paramètre recommandé. Dans les clusters de plus grande taille, l'affinité matérielle peut distribuer correctement les nœuds OpenShift.

Pour configurer des groupes d'affinités, reportez-vous à la section "Red Hat 6.11. Documentation des groupes d'affinités".

IPI facilite le déploiement des clusters OpenShift via l'assistant interactif présenté plus haut dans ce document. Cependant, il est possible qu'il y ait des valeurs par défaut qui devront être modifiées dans le cadre du déploiement du cluster.

Dans ces instances, vous pouvez exécuter et tâches l'assistant sans déployer immédiatement un cluster. Au contraire, un fichier de configuration est créé à partir duquel le cluster peut être déployé ultérieurement. Cette fonction s'avère très utile pour modifier les valeurs par défaut des IPI ou pour déployer plusieurs clusters identiques dans votre environnement pour d'autres utilisations telles que la colocation. Pour plus d'informations sur la création d'une configuration d'installation personnalisée pour OpenShift, consultez "Red Hat OpenShift installation d'un cluster sur RHV avec personnalisation".