Comprendre les interfaces réseau virtuelles dans les clusters VPC

Cloud privé virtuel 4.20 et plus tard Nœuds de travail en métal nu uniquement

Les interfaces réseau virtuelles (VNI) offrent des options de connectivité réseau avancées pour les charges de travail exécutées sur les clusters VPC Red Hat OpenShift on IBM Cloud avec des nœuds de travail en métal nu.

Qu'est-ce qu'une interface réseau virtuelle?

Une interface de réseau virtuel (VNI) est une abstraction VPC IBM Cloud qui représente des connexions réseau individuelles. Les VNI intègrent les propriétés d'une connexion réseau, notamment :

  • Adresses IP (primaires et secondaires)
  • Adresses MAC
  • Association de sous-réseaux VPC
  • Appartenance à un groupe de sécurité

Les VNI ne sont disponibles que sur les clusters dotés de nœuds de travail en métal nu exécutant Red Hat CoreOS (RHCOS).

Architecture VNI dans les grappes OpenShift

VNI statiques

Lorsque vous créez un cluster Red Hat OpenShift on IBM Cloud basé sur du bare metal ou que vous ajoutez un nouveau pool de travailleurs bare metal sur IBM Cloud VPC, deux VNI sont automatiquement créées et attachées à chaque nœud de travail bare metal :

VNI primaire
Gère le trafic régulier des travailleurs, y compris le réseau des pods, les réseaux superposés définis par l'utilisateur (UDN) et la communication avec le maître de la grappe.
VNI secondaire (porteur)
Joue le rôle de support pour les pièces jointes dynamiques de VNI que vous gérez. Ce VNI vous permet d'attacher des interfaces réseau supplémentaires aux charges de travail s'exécutant sur le nœud de travail.

VNI dynamiques

Les VNI dynamiques sont créées et gérées à la demande après la création du cluster. Ces VNI peuvent être

  • Attaché à des nœuds de travail spécifiques
  • Configuré pour flotter entre les travailleurs d'une même zone
  • Utilisé pour la connectivité directe du réseau VPC

Principales fonctionnalités

Connectivité directe avec le VPC
Les VNI permettent aux charges de travail de se connecter directement aux réseaux VPC, en contournant la superposition des réseaux de pods. Il fournit des fonctions de réseau VPC natives telles que les groupes de sécurité, les listes de contrôle d'accès au réseau et le routage.
Intégration des groupes de sécurité
Les VNI peuvent être associés à des groupes de sécurité VPC, ce qui permet de contrôler finement l'accès au réseau au niveau de l'interface.
Mise en réseau spécifique à une zone
Les VNI sont rattachés à un sous-réseau et à une zone VPC spécifiques. Ils ne peuvent gérer que le trafic des charges de travail s'exécutant sur des travailleurs en grappe dans la même zone que celle où l'interface VNI est approvisionnée.
Préservation du réseau pendant la migration
Pour les charges de travail qui prennent en charge la migration en direct (comme les VM de virtualisation OpenShift ), les VNI peuvent implicitement flotter et suivre la charge de travail entre les instances de travail bare metal au sein de la même zone, en préservant les connexions réseau.

Cas d'utilisation

OpenShift Virtualization
Activer la connectivité réseau VPC directe pour les machines virtuelles, ce qui permet aux machines virtuelles d'avoir leurs propres adresses IP VPC. Voir Gestion des interfaces réseau virtuelles pour la virtualisation OpenShift.
Charges de travail multi-réseaux
Connectez les charges de travail à plusieurs sous-réseaux VPC simultanément, ce qui permet de créer des topologies de réseau complexes et de séparer le trafic.
Migration des applications patrimoniales
Fournir un réseau de type VM pour les applications conteneurisées qui nécessitent des adresses IP spécifiques ou un accès direct au réseau.
Virtualisation des fonctions de réseau
Déployer des fonctions réseau qui nécessitent un accès direct aux fonctions réseau du VPC.

Limites et considérations

Modifications statiques du VNI
Ne modifiez pas les VNI statiques qui sont automatiquement créés pour chaque nœud de travailleur. Bien que ces VNI soient visibles dans votre compte VPC, toute modification de leurs paramètres n'est pas prise en charge. Il s'agit notamment d'attacher des IP flottantes, de changer les groupes de sécurité ou de modifier toute autre propriété de VNI. La modification des VNI statiques peut entraîner des problèmes de connectivité entre les clusters.
Restrictions de modification de la VNI pour les pièces jointes flottantes
Vous ne pouvez pas modifier les propriétés des VNI pour les attachements dynamiques flottants (à l'échelle d'un cluster). Il s'agit notamment de modifier le nom du VNI, les adresses IP flottantes, les paramètres NAT de l'infrastructure et les attributions de groupes de sécurité. Pour mettre à jour ces paramètres, vous devez d'abord détacher la VNI, effectuer vos modifications, puis la rattacher au cluster. Cette limitation est temporaire.
Contraintes de zone
Les VNI ne peuvent pas flotter entre les zones. Dans les clusters multi-zones, les VNI ne peuvent gérer que le trafic des charges de travail de la même zone que celle dans laquelle la VNI est provisionnée.
Exigences en matière de métal nu
Les VNI ne sont prises en charge que sur les nœuds de travail en métal nu. Les nœuds de travail des instances de serveurs virtuels (VSI) ne prennent pas en charge les VNI.
Exigence du RHCOS
Les nœuds de travail doivent utiliser le système d'exploitation Red Hat CoreOS (RHCOS).
OVN- Kubernetes CNI
Les clusters doivent utiliser le plugin OVN- Kubernetes Container Network Interface (CNI).
Gestion des comptes croisés
Dans Red Hat OpenShift on IBM Cloud, les nœuds de travail sont provisionnés dans le compte de IBM, et non dans le vôtre. Cela signifie que la gestion du cycle de vie des VNI diffère de celle des instances VPC bare metal autonomes, et que vous avez une visibilité différente sur les pièces jointes des VNI.
Exigence de version
La prise en charge de VNI nécessite OpenShift 4.20 ou une version ultérieure.

Prérequis

Avant d'utiliser les VNI dans votre cluster, assurez-vous que vous avez :

  • Un cluster Red Hat OpenShift on IBM Cloud à la version 4.20 ou ultérieure
  • Nœuds de travail en métal nu dans votre cluster
  • Red Hat CoreOS (RHCOS) sur les nœuds de travail
  • OVN- Kubernetes CNI configuré
  • Infrastructure VPC avec les sous-réseaux appropriés
  • Le rôle d'accès à la plate-forme de l'opérateur pour Kubernetes Service dans IBM Cloud IAM
  • Le rôle d'accès à la plate-forme Editor ou Administrator pour les services d'infrastructure VPC dans IBM Cloud IAM

Gestion des VNI

Vous pouvez gérer les VNI à partir de la console IBM Cloud ou en utilisant le CLI.

Attacher un VNI à partir de la console

  1. Dans la console Red Hat OpenShift on IBM Cloud clusters, sélectionnez votre cluster.

  2. Dans le menu de navigation, cliquez sur Mise en réseau > Pièces jointes VNI.

  3. Cliquez sur Attach VNIs.

  4. Dans le panneau Attacher des VNI, configurez les paramètres suivants :

    • Sous-réseau: Sélectionnez le sous-réseau dans lequel se trouve votre VNI.
    • Nœud de travail: Sélectionnez un nœud de travail spécifique ou Tous les nœuds de travail pour un attachement VNI flottant.
    • VNI: Sélectionnez le VNI à joindre.
    • VLAN ID: Saisissez l'ID VLAN (plage : 1-500) correspondant à la configuration de votre réseau.
    • Suppression automatique: Facultatif. Cochez cette case pour supprimer automatiquement l'interface utilisateur virtuel lorsqu'elle est retirée du cluster.

  5. Cliquez sur Associer.

Attacher une VNI à partir de la CLI

Pour attacher une interface utilisateur virtuelle à un nœud de travail nu spécifique, utilisez la commande vni attach baremetal. Vous devez spécifier un ID VLAN (plage : 1-500) qui correspond à la configuration de votre réseau.

ibmcloud ks vni attach baremetal --worker WORKER_ID --vni VNI_ID --vlan VLAN_ID [--auto-delete]

Pour attacher un VNI flottant qui peut suivre les charges de travail entre les travailleurs de la même zone, indiquez l'ID du cluster au lieu de l'ID du travailleur :

ibmcloud ks vni attach baremetal --cluster-id CLUSTER_ID --vni VNI_ID --vlan VLAN_ID [--auto-delete]

L'option --auto-delete supprime automatiquement l'interface VNI lorsqu'elle est retirée de la grappe.

Visualisation des pièces jointes VNI à partir de la console

  1. Dans la console Red Hat OpenShift on IBM Cloud clusters, sélectionnez votre cluster.

  2. Dans le menu de navigation, cliquez sur Mise en réseau > Pièces jointes VNI.

  3. Affichez la liste des VNI attachés avec des détails tels que le nom du VNI, le nœud de travailleur, le sous-réseau, l'ID VLAN et l'IP primaire.

Visualisation des pièces jointes VNI à partir de l'interface CLI

Pour dresser la liste de tous les VNI attachés à un cluster :

ibmcloud ks vni ls --cluster-id CLUSTER_ID

Pour dresser la liste des VNI attachées à un nœud de travail spécifique :

ibmcloud ks vni ls --worker WORKER_ID

Détacher un VNI de la console

  1. Dans la console Red Hat OpenShift on IBM Cloud clusters, sélectionnez votre cluster.

  2. Dans le menu de navigation, cliquez sur Mise en réseau > Pièces jointes VNI.

  3. Recherchez la VNI que vous souhaitez détacher et cliquez sur l'icône du menu d'actions (⋯).

  4. Sélectionnez Détacher et confirmez l'action.

Détachement d'un VNI à partir de la CLI

Pour détacher un VNI d'un nœud de travail, spécifiez à la fois l'ID du VNI et l'ID du travailleur :

ibmcloud ks vni detach --worker WORKER_ID --vni VNI_ID

Pour les VNI flottants, il faut d'abord répertorier les VNI pour trouver l'ID du travailleur actuel, puis se détacher en utilisant cet ID de travailleur.

Pour des exemples plus détaillés et des cas d'utilisation, voir Gestion des interfaces réseau virtuelles pour la virtualisation OpenShift.

Etapes suivantes