Fonctions principales

VNI statiques par nœud de travail

Lorsque vous créez un cluster Red Hat OpenShift on IBM Cloud basé sur du métal nu ou un nouveau pool de travailleurs dans IBM Cloud VPC, deux VNI sont automatiquement créées et attachées statiquement à chaque nœud de travailleur basé sur du métal nu. Un VNI gère le trafic régulier des travailleurs (réseau de pods, UDNs superposés et communication avec le maître). Le deuxième VNI sert de support aux attachements dynamiques de VNI que vous gérez.

Pièces jointes dynamiques du VNI

Vous pouvez créer et gérer des VNI à la demande après la création d'un cluster. Les VNI dynamiques peuvent être attachés à des travailleurs spécifiques ou configurés pour flotter entre les travailleurs d'une même zone, en suivant VM les charges de travail pendant la migration en direct.

Assistance à la migration en direct

Avec les VNI attachés à des nœuds de travail en métal nu, les migrations en direct des VM basées sur la virtualisation OpenShift peuvent préserver les connexions réseau. Le VNI flotte implicitement et suit la charge de travail entre les instances de travail en métal nu au sein de la même zone.

Pour les limitations et considérations importantes concernant les VNI, voir Limitations et considérations.

Rattachement de comptes croisés

Sur Red Hat OpenShift on IBM Cloud, les nœuds de travail ne sont pas provisionnés dans votre compte, ce qui signifie que la gestion du cycle de vie des VNI est légèrement différente de celle des instances de métal nu des VPC autonomes. L'administrateur du cluster Red Hat OpenShift on IBM Cloud n'a pas la même visibilité sur les pièces jointes des VNI car elles sont attachées à des charges de travail qui ne sont pas visibles dans le compte. Les différences dans la gestion des VNI sont couvertes dans cette documentation.

Pour plus d'informations sur les VNI sur les instances VPC bare metal autonomes, voir À propos des interfaces réseau virtuelles.

Création d'un UDN primaire

Pour utiliser un réseau primaire défini par l'utilisateur pour les pods ou la charge de travail VM, il faut d'abord créer l'UDN lui-même.

Exemple de réseau défini par l'utilisateur d'un cluster qui peut être utilisé dans plusieurs espaces de noms :

apiVersion: k8s.ovn.org/v1
kind: ClusterUserDefinedNetwork
metadata:
  name: primary
spec:
  namespaceSelector:
    matchLabels:
      kubernetes.io/metadata.name: green
  network:
    layer2:
      ipam:
        lifecycle: Persistent
      role: Primary
      subnets:
        - 10.0.0.0/24
    topology: Layer2

Ensuite, créez le(s) espace(s) de noms qui l'utiliseront. L'espace de noms doit contenir un label spécifique (appelé k8s.ovn.org/primary-user-defined-network) lors de sa création pour l'utilisation de l'UDN primaire.

Exemple :

kind: Namespace
apiVersion: v1
metadata:
  name: green
  labels:
    k8s.ovn.org/primary-user-defined-network: ''

Une fois le (C)UDN et les espaces de noms en place, toute charge de travail créée dans cet espace de noms accèdera à l'UDN par la route par défaut.

Création d'un UDN secondaire

La configuration de l'UDN secondaire est similaire à celle de l'UDN primaire, mais le rôle est défini sur Secondary. Pour plus d'informations, voir la documentation sur les réseaux multiples à l'adresse Red Hat OpenShift.

Installation de l'opérateur NMState

OpenShift Service de virtualisation Les clusters intègrent l'opérateur NMState, qui est géré par le module complémentaire « openshift-virtualization ». Ignorez cette étape si vous utilisez le service de virtualisation.

1. Déployez l'opérateur NMState à partir de OperatorHub dans la console Red Hat OpenShift on IBM Cloud ou en utilisant le CLI.

2. Créer une instance de NMState avec la configuration par défaut.

   apiVersion: nmstate.io/v1
   kind: NMState
   metadata:
     name: nmstate
   spec:
     probeConfiguration:
       dns:
         host: root-servers.net
   

Création du pont OVS

OpenShift Service de virtualisation Les clusters disposent des ressources NNCP requises, préconfigurées. Vous ne devez créer ces ressources manuellement que pour les clusters standard d' OpenShift s dont l'installation de Virtualization s'effectue manuellement via OpenShift.

1. Créez un pont OVS dédié auquel eth1 est attaché en déployant la ressource personnalisée NMState suivante.

   apiVersion: nmstate.io/v1
   kind: NodeNetworkConfigurationPolicy
   metadata:
     name: "br-eth1"
   spec:
     desiredState:
       interfaces:
       - name: "br-eth1"
         description: A dedicated OVS bridge with a NIC as a port
         type: ovs-bridge
         state: up
         bridge:
           allow-extra-patch-ports: true
           options:
             stp: false
           port:
           - name: "eth1"
   

2. Vérifiez l'état de la ressource personnalisée et attendez que tous les nœuds de cluster concernés réconcilient la demande de création de pont.

3. Patch le nouveau pont OVS avec le pont par défaut en créant la ressource personnalisée NMState suivante. Remplacez vpc-vlans par le nom de votre réseau.

   apiVersion: nmstate.io/v1
   kind: NodeNetworkConfigurationPolicy
   metadata:
     name: "vpc-vlans"
   spec:
     desiredState:
       ovn:
         bridge-mappings:
         - localnet: "vpc-vlans"
           bridge: "br-eth1"
           state: present
   

4. Vérifiez l'état de la ressource personnalisée et attendez que tous les nœuds de cluster concernés réconcilient la demande de mappage de pont.

Création d'un réseau localnet défini par l'utilisateur

Créer un UDN ou ClusterUserDefinedNetwork (CUDN) qui met à disposition le trafic des VNI en utilisant le VLAN sélectionné.

apiVersion: k8s.ovn.org/v1
kind: ClusterUserDefinedNetwork
metadata:
  name: "vlan250"
spec:
  namespaceSelector:
    matchExpressions:
    - key: kubernetes.io/metadata.name
      operator: In
      values:
      - "default"
  network:
    topology: Localnet
    localnet:
      role: "Secondary"
      physicalNetworkName: "vpc-vlans"
      ipam:
        mode: Disabled
      vlan:
        mode: Access
        access:
          id: 250

Remplacez les valeurs suivantes :

• vlan250: Le nom de votre CUDN
• default: L'espace de noms dans lequel vous souhaitez utiliser le CUDN
• vpc-vlans: Le nom du réseau physique que vous avez défini dans le mappage du pont
• 250: ID VLAN souhaité (plage : 1-500)

Ceci conclut la plomberie réseau d'un VLAN spécifique. Vous pouvez définir plusieurs CUDN en utilisant différents ID VLAN tout en réutilisant les mappages de ponts.

IBM Cloud Après avoir terminé la configuration de l'UDN localnet, vous pouvez attacher des VNI au cluster en utilisant la console IBM Cloud ou la commande CLI ks vni. Voir les exemples dans les sections suivantes.

Avant de commencer

1. Créez des VNI dans votre VPC avec la configuration de sous-réseau et d'adresse IP appropriée.

2. Assurez-vous que vous disposez des autorisations nécessaires pour gérer à la fois le cluster et les VNI.

Exemple

ibmcloud ks vni attach baremetal --vni 0716-aac49630-f3b4-4ef6-9a3a-5145481697ba --worker kube-c9pqfcmw0tq431jdnrrg-mycluster-default-00000123 --vlan 251

Exemple de sortie

OK
Successfully attached VNI 0716-aac49630-f3b4-4ef6-9a3a-5145481697ba to worker node kube-c9pqfcmw0tq431jdnrrg-mycluster-default-00000123.
Worker Node ID                                         VNI ID                                      VLAN ID
kube-c9pqfcmw0tq431jdnrrg-mycluster-default-00000123   0716-aac49630-f3b4-4ef6-9a3a-5145481697ba   251

Exemple de sortie

ibmcloud ks vni ls --cluster-id c9pqfcmw0tq431jdnrrg

OK
VNI ID                                      Worker Node                                            IP Address   MAC Address         VLAN   Floating   Auto-delete
0716-d97d3626-acb2-476b-8b12-bcafa1dec5bb   kube-c9pqfcmw0tq431jdnrrg-mycluster-default-00000456   10.240.1.5   02:00:02:00:73:A5   250    -          false
0716-aac49630-f3b4-4ef6-9a3a-5145481697ba   kube-c9pqfcmw0tq431jdnrrg-mycluster-default-00000123   10.240.1.4   02:00:01:00:73:A5   251    -          false

Exemple

ibmcloud ks vni detach --vni 0716-aac49630-f3b4-4ef6-9a3a-5145481697ba --worker kube-c9pqfcmw0tq431jdnrrg-mycluster-default-00000123

Detach VNI 0716-aac49630-f3b4-4ef6-9a3a-5145481697ba from worker node kube-c9pqfcmw0tq431jdnrrg-mycluster-default-00000123? This action cannot be undone. [y/N]> y
OK
Successfully detached VNI 0716-aac49630-f3b4-4ef6-9a3a-5145481697ba from worker node kube-c9pqfcmw0tq431jdnrrg-mycluster-default-00000123.

Pourquoi ne puis-je pas attacher des pods ordinaires à des UDN localnet?

Les UDN Localnet ont la gestion des adresses IP (IPAM) désactivée du côté de l'OVN, ce qui signifie que l'attribution statique d'adresses IP aux pods ne se fait pas à partir de l'OVN. Cette configuration est conçue pour les charges de travail VM qui utilisent DHCP ou configurent des IP statiques dans le système d'exploitation invité. Ces options ne sont pas disponibles pour les charges de travail en pods.

Pourquoi la migration en direct est-elle en attente dans les pools de travailleurs?

Différents groupes de travailleurs peuvent avoir différentes saveurs de travailleurs avec des CPU de différentes générations et capacités. Si l'ensemble des fonctionnalités du CPU est visible de manière transparente pour la charge de travail VM, vous ne pouvez pas migrer le site VM vers un autre travailleur qui ne prend pas en charge toutes les fonctionnalités du CPU. Vous pouvez limiter les caractéristiques visibles de l'unité centrale du système d'exploitation invité au début afin d'obtenir une meilleure compatibilité entre les différents types de travailleurs.

Pourquoi les VNI dynamiques attachés ne fonctionnent-ils pas?

Vérifiez les points suivants :

• Vérifiez que l'ID VLAN dans le CUDN correspond à l'ID VLAN dans l'attachement VNI. Le VPC DHCP peut encore fonctionner sans trafic supplémentaire si le VLAN n'est pas adapté.
• Si le flottement n'est pas activé, assurez-vous que la charge de travail est planifiée sur le travailleur auquel la VNI est attachée.
• Vérifiez que le pont OVS dédié et le mappage sont présents sur les travailleurs. Vérifier l'état de la ressource NodeNetworkConfigurationPolicy.