Conditions préalables à la configuration des réseaux définis par l'utilisateur (UDN) d'Open Virtual Network (OVN) sur Red Hat OpenShift on IBM Cloud

Configurez les prérequis ponctuels du réseau défini par l'utilisateur (CUDN) du cluster OVN pour les réseaux « Localnet » et « Layer 2 Primary » sur Red Hat OpenShift on IBM Cloud.

Ce tutoriel explique comment mettre en place les prérequis pour les réseaux locaux CUDN et les réseaux primaires de couche 2 sur Red Hat® OpenShift® Kubernetes Service sur IBM Cloud. Toutes les tâches décrites dans ce tutoriel sont effectuées une fois par cluster.

Présentation de Localnet

Red Hat OpenShift Kubernetes Service Les réseaux Localnet nécessitent une configuration supplémentaire que les clients n'effectuent pas dans ROVS. Ce tutoriel explique les étapes à suivre.

Préparation du cluster « Red Hat OpenShift on IBM Cloud »

Le cluster « Red Hat OpenShift » sur IBM Cloud nécessite l'opérateur NMState. NMState assure une configuration réseau persistante pour les ponts et les réseaux physiques. Cette étape permet d'installer l'opérateur.

Gardez à l'esprit les points suivants :

  • Une fois le manifeste appliqué, l'installation prend entre 5 et 10 minutes.
  • Ne créez qu'un seul pont par interface.
  • N'essayez pas de modifier le pont sur eth0.

Copiez le bloc de code suivant dans un fichier et exécutez-le à l'aide de la commande « oc apply -f step0a.yml » pour installer l'opérateur NMState.

---
apiVersion: v1
kind: Namespace
metadata:
  name: openshift-nmstate
spec:
  finalizers:
  - kubernetes
---
apiVersion: operators.coreos.com/v1
kind: OperatorGroup
metadata:
  name: openshift-nmstate
  namespace: openshift-nmstate
spec:
  targetNamespaces:
  - openshift-nmstate
---
apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
  name: kubernetes-nmstate-operator
  namespace: openshift-nmstate
spec:
  channel: stable
  installPlanApproval: Automatic
  name: kubernetes-nmstate-operator
  source: redhat-operators
  sourceNamespace: openshift-marketplace

Attendez que l'opérateur enregistre la définition de ressource personnalisée (CRD) « NMState » avant de créer la ressource personnalisée « NMState ». Si vous appliquez la ressource NMState avant que le CRD ne soit créé, vous obtenez une erreur du type « no matches for kind "NMState" in version "nmstate.io/v1" ».

Exécutez les commandes suivantes pour effectuer une interrogation jusqu'à ce que le CRD apparaisse, puis attendez qu'il atteigne l'état « Established ».

until oc get crd nmstates.nmstate.io >/dev/null 2>&1; do echo "Waiting for NMState CRD..."; sleep 10; done
oc wait --for=condition=established crd/nmstates.nmstate.io --timeout=300s

Vérifiez que tous les CRD NMState sont bien installés.

oc get crd | grep nmstate

Exemple de sortie :

nmstates.nmstate.io                                               ...
nodenetworkconfigurationenactments.nmstate.io                     ...
nodenetworkconfigurationpolicies.nmstate.io                       ...
nodenetworkstates.nmstate.io                                      ...

Une fois les CRD prêts, copiez le bloc de code suivant dans un fichier et appliquez-le à l'aide de la commande « oc apply -f step0b.yml » pour créer la ressource personnalisée « NMState ».

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

Mise en œuvre de la configuration en pont

Appliquez la configuration de base du pont pour utiliser la deuxième carte d'interface réseau (NIC) PCI-VNI (Peripheral Component Interconnect-Virtual Network Interface) (eth1).

Copiez le bloc de code suivant dans un fichier et exécutez-le à l'aide de la commande « oc apply -f step1.yml ».

---
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"

Attendez que cette configuration soit appliquée à tous les nœuds avant de passer à l'étape suivante.

% oc get NodeNetworkConfigurationPolicy br-eth1
NAME      STATUS      REASON
br-eth1   Available   SuccessfullyConfigured

Application de la configuration de mappage des ponts

Appliquez la configuration de base du pont de mappage.

Copiez le bloc de code suivant dans un fichier et exécutez-le à l'aide de la commande « oc apply -f step2.yml ».

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

Création d'un préfixe secondaire personnalisé et de sous-réseaux pour votre VPC

Les réseaux locaux peuvent utiliser des sous-réseaux VPC secondaires pour chaque réseau. Cet exemple utilise trois nouveaux sous-réseaux issus d'un nouveau préfixe VPC. Vous pouvez remplacer n'importe quel préfixe ou réseau, ou utiliser les valeurs par défaut du VPC.

Création d'un nouveau préfixe VPC

Créez un nouveau préfixe pour chaque zone. Cet exemple utilise le superréseau 198.18.0.0/16 et crée trois préfixes (sous-réseaux) /18, à raison d'un par zone.

ic is vpc-addrc my-vpc-zone-1-vms my-vpc us-south-1 198.18.0.0/18 --default true
ic is vpc-addrc my-vpc-zone-2-vms my-vpc us-south-2 198.18.64.0/18
ic is vpc-addrc my-vpc-zone-3-vms my-vpc us-south-3 198.18.128.0/18

Création de nouveaux sous-réseaux VPC

Créez trois sous-réseaux VPC (prod, db et app) pour la zone 1.

ic is subnetc zone1-vm-prod my-vpc us-south-1 --ipv4-cidr-block 198.18.0.0/24
ic is subnetc zone1-vm-db my-vpc us-south-1 --ipv4-cidr-block 198.18.1.0/24
ic is subnetc zone1-vm-app my-vpc us-south-1 --ipv4-cidr-block 198.18.2.0/24

Configurer une passerelle publique si nécessaire

Assurez-vous qu'une passerelle publique soit associée à chaque zone. Dans le cas contraire, le sous-réseau reste privé.

Récupérez l'identifiant de chaque sous-réseau. Dans cet exemple, le sous-réseau « zone1-vm-prod » est sélectionné.

ic is subnets | awk ' $8 ~ /yourVPC-NAME_GOES-HERE/'

Exemple de sortie :

0716-16da748a-5159-480c-b809-5f9e4750028b   zone1-vm-app    available   198.18.2.0/24   249/256   stone-likeness-bagging-headcount   pgw-0ec02020-2f74-11f1-b0c5-bfe21078e55b   potato-farm   us-south-1   Default
0716-74a2d06b-de5c-40c2-8311-38dbff74ce62   zone1-vm-db     available   198.18.1.0/24   249/256   stone-likeness-bagging-headcount   -                                          potato-farm   us-south-1   Default
0716-efd14367-eed3-429d-b390-ea17f0e8cfb1   zone1-vm-prod   available   198.18.0.0/24   249/256   stone-likeness-bagging-headcount   pgw-0ec02020-2f74-11f1-b0c5-bfe21078e55b   potato-farm   us-south-1   Default

Association d'une passerelle publique au sous-réseau

Associez une passerelle publique au sous-réseau zone1-vm-prod en utilisant l'ID de sous-réseau 0716-efd14367-eed3-429d-b390-ea17f0e8cfb1.

ic is subnet-public-gateway-attach zone1-vm-prod --pgw r134-053cb8b1-d966-4b02-9f20-5fcbeda76048

Vous devez répéter cette étape pour chaque nouveau sous-réseau et chaque zone. Les passerelles publiques sont définies par VPC et par zone.

Niveau 2 : Réseau de plomberie principal

Les réseaux primaires de couche 2 nécessitent la mise en place d'une infrastructure initiale avant que l'utilisateur final puisse les utiliser.

Avant de pouvoir utiliser les réseaux principaux de couche 2, vous devez effectuer certaines opérations de configuration initiale.

Installation du routeur FRR OVN Pod

Appliquez le correctif « Red Hat OpenShift » sur le cluster IBM Cloud afin de rendre disponible l'option « Free Range Routing » (FRR) dans le pod « Open Virtual Networking » (OVN). Appliquez le correctif suivant pour activer FRR en tant que fournisseur de routage supplémentaire et pour acheminer les annonces de routage dans la configuration OVN- Kubernetes.

oc patch Network.operator.openshift.io cluster --type=merge -p='{"spec":{"additionalRoutingCapabilities":{"providers":["FRR"]},"defaultNetwork":{"ovnKubernetesConfig":{"routeAdvertisements":"Enabled"}}}}'

Activation de la mise en réseau entre espaces de noms

Appliquez la configuration réseau de base qui autorise la communication entre espaces de noms pour les réseaux définis par l'utilisateur en cluster (CUDN) annoncés via le protocole BGP (Border Gateway Protocol). Cette configuration assouplit le comportement par défaut en matière d'isolation du réseau défini par l'utilisateur (UDN). Enregistrez le manifeste suivant dans un fichier et appliquez-le à l'aide de la commande « oc apply -f step0.yml ».

# Permit intra-CUDN-namespace traffic
---
apiVersion: v1
kind: ConfigMap
metadata:
  namespace: openshift-network-operator
  name: ovn-kubernetes-config-overrides
data:
  advertised-udn-isolation-mode: "loose"

Activation du sélecteur d'annonces de route

Ajoutez des annonces de routage pour configurer OVN afin qu'il diffuse les réseaux de pods via BGP à l'aide du pod OVN FRR. Enregistrez le manifeste suivant dans un fichier et appliquez-le à l'aide de la commande « oc apply -f step1.yml ».

Les réseaux doivent porter la mention « advertise: true ».

# Add the RouteAdvertisements
---
kind: RouteAdvertisements
apiVersion: k8s.ovn.org/v1
metadata:
  name: default
spec:
  nodeSelector: {}
  frrConfigurationSelector: {}
  networkSelectors:
    - networkSelectionType: ClusterUserDefinedNetworks
      clusterUserDefinedNetworkSelector:
        networkSelector:
          matchLabels:
            advertise: "true"
  advertisements:
    - "PodNetwork"
---