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