Concevoir votre réseau pour la virtualisation d' Red Hat OpenShift s sur IBM Cloud VPC

Concevez le réseau pour la virtualisation « Red Hat OpenShift » sur IBM Cloud VPC, en couvrant la mise en réseau VPC, le réseau défini par logiciel (SDN) d’ OpenShift, ainsi que les réseaux définis par l’utilisateur (User-Defined Networks) d’Open Virtual Networking (OVN).

La conception du réseau dans la virtualisation Red Hat OpenShift sur IBM Cloud VPC comporte les couches distinctes suivantes.

Réseau VPC
Red Hat OpenShift réseautage
Réseau OVN

Les éléments clés de l'architecture du réseau sont présentés dans le diagramme suivant.

Red Hat OpenShift Virtualisation sur le réseau Virtualisation sur le réseau Virtualisation sur le réseau IBM Cloud — Red Hat OpenShift IBM Cloud

IBM Cloud VPC réseautage

Vous utilisez le réseau IBM Cloud VPC pour déployer et gérer les ressources en nuage. Il constitue la base de vos charges de travail, y compris les serveurs virtuels, les conteneurs et les déploiements bare metal, qui peuvent contribuer à assurer la segmentation, la sécurité et l'évolutivité du réseau.

Vous devez créer un VPC pour mettre en place un service « Red Hat® OpenShift® ». Kubernetes Service groupe.

Réseau privé par défaut avec sous-réseaux

Vous devez créer un sous-réseau VPC dans au moins une zone de disponibilité pour provisionner un cluster Red Hat OpenShift Kubernetes Service. Pour plus d'informations, voir Réseau privé par défaut avec sous-réseaux.

Équilibreurs de charge

Un contrôleur d'entrée Red Hat OpenShift est déployé dans votre cluster Red Hat OpenShift Kubernetes Service et sert de point d'entrée pour le trafic réseau externe. Dans un cluster Red Hat OpenShift Kubernetes Service, un équilibreur de charge d'application VPC est automatiquement créé par cluster pour exposer le contrôleur d'entrée. Pour plus d'informations, voir les répartiteurs de charge.

Red Hat OpenShift Kubernetes Service remplit les fonctions suivantes.

Le service DNS résout le sous-domaine de la route au nom d'hôte de l'équilibreur de charge VPC.
L'équilibreur de charge VPC résout le nom d'hôte VPC en une adresse IP externe disponible d'un service de contrôleur d'entrée dont le bon fonctionnement a été signalé.
L'équilibreur de charge du VPC envoie la demande à un service de contrôleur d'entrée.
Le contrôleur Ingress transmet la demande à l'adresse IP privée de l'application pod sur le réseau privé.

Points de terminaison virtuels privés

Les points d'extrémité privés virtuels (VPE) dans les environnements Red Hat OpenShift Kubernetes Service sont principalement utilisés pour permettre une connectivité privée entre le cluster Red Hat OpenShift et les services de la plateforme IBM Cloud sans que le trafic réseau ne traverse l'internet public.

Le tableau suivant répertorie tous les points de terminaison privés virtuels qui sont automatiquement provisionnés par IBM Cloud pour les opérations essentielles du cluster.

Points d'extrémité privés virtuels qui sont provisionnés pour les opérations de cluster.
noeud final privé virtuel	Géré par	Description
iks-api	Kubernetes Service API	Accès privé à l'API IBM Cloud Kubernetes Service Opérations de gestion du cluster (commandes kubectl, oc) Communication entre le nœud de travail et le plan de contrôle Opérations CLI IBM Cloud (commandes `ibmcloud ks` ) Permet des configurations de cluster uniquement privées
iks-riaas	Services d'infrastructure VPC	Accès privé aux API de l'infrastructure VPC Approvisionnement des nœuds de travail et gestion du cycle de vie Attachement et gestion des volumes de stockage Opérations de réseau VPC (équilibreurs de charge, groupes de sécurité) Gestion des ressources d'infrastructure Utilisé par IBM Cloud cluster autoscaler, les pilotes CSI de stockage pour les opérations de volume, les services d'approvisionnement des équilibreurs de charge, les contrôleurs du cycle de vie des nœuds de travail
iks-registry	Registre de conteneurs	Accès privé à IBM Cloud Container Registry Extraction d'images de conteneurs sans passer par l'internet public Accès aux espaces de noms des registres publics et privés Élimination des frais de sortie publics pour l'extraction d'images
iks-<cluster_id>	Instance de cluster spécifique	Point de terminaison privé spécifique à votre instance de cluster Accès direct à l'API du cluster Utilisé pour les configurations de cluster uniquement privées Alternative au point de terminaison API régional Utilisé par les outils qui nécessitent un accès direct au cluster, une communication de service à service au sein du VPC, des schémas d'accès au cluster privé
iks-cos-config	Cloud Object Storage (Configuration)	Accès privé à l'API de configuration de IBM Cloud Object Storage Opérations de gestion et de configuration des bacs Gestion de la politique IAM et du contrôle d'accès Opérations d'accréditation des services
iks-cos	Cloud Object Storage (Données)	Accès privé à IBM Cloud Object Storage S3 API Opérations du plan de données du stockage d'objets (PUT/GET/DELETE) Transfert de données de sauvegarde et de restauration Accès au stockage de données d'application

Red Hat OpenShift Réseaux de virtualisation

Red Hat OpenShift La virtualisation utilise les capacités de mise en réseau du site Red Hat OpenShift pour fournir une mise en réseau flexible et définie par logiciel pour les serveurs virtuels qui s'exécutent parallèlement aux charges de travail conteneurisées. Il est important de comprendre la différence entre la mise en réseau de serveurs virtuels et la mise en réseau de pods. Chaque serveur virtuel fonctionne dans un pod virt-launcher qui est toujours connecté au réseau de pods par défaut.

┌────────────────────────────────┐
│          Worker Node           │
│  ┌──────────────────────────┐  │
│  │      virt-launcher       │  │  ← Kubernetes Pod Security Context
│  │          pod             │  │
│  │  ┌────────────────────┐  │  │
│  │  │   virtual server   │  │  │  ← KVM/QEMU Hypervisor Isolation
│  │  │       (QEMU)       │  │  │
│  │  └────────────────────┘  │  │
│  └──────────────────────────┘  │
└────────────────────────────────┘

En fonction de la manière dont vous provisionnez et configurez votre serveur virtuel, il partage un réseau de pods (ou il peut se connecter à différents réseaux en utilisant multus).

L'exemple suivant décrit le réseau de pods par défaut dans Red Hat OpenShift que vous pouvez modifier avec OVN- Kubernetes networking.

Réseaux de pods (réseau de clusters)

Chaque pod se voit attribuer une adresse IP privée issue du réseau du cluster selon le protocole CIDR (Classless Inter-Domain Routing)
Assure la communication entre les nœuds d'un pod à l'autre
Les pods communiquent directement en utilisant leurs IP privées au sein du cluster
Les politiques de réseau contrôlent le trafic de pod à pod au niveau de la couche 3/4
Modèle de réseau plat - tous les pods peuvent communiquer par défaut
Pas de NAT entre les pods (communication directe de pod à pod)
Les politiques de réseau assurent la segmentation et la sécurité
Découverte de services basée sur le DNS au sein d'une grappe
Lorsqu'un serveur virtuel s'exécute au sein du pod « virt-launcher », son adresse IP est soumise à une traduction d'adresses réseau (NAT) vers l'adresse IP du pod « virt-launcher »

Masquage d'adresse IP (NAT source (SNAT))

Lorsque les pods établissent des connexions sortantes vers des réseaux externes, l'adresse IP source est masquée
L'adresse IP source du paquet de requête est remplacée par l'adresse IP du nœud de travail sur lequel s'exécute le pod
Le masquage d'IP est nécessaire car les IP des pods ne sont pas routables en dehors du cluster
Le trafic de retour est démasqué vers l'IP du pod d'origine
Les services externes voient les demandes provenant des IP des nœuds de travail, et non des IP des pods

ClusterIP service

Les services fournissent des points d'extrémité stables et un équilibrage de la charge pour les pods. Ils font abstraction des IP des pods et fournissent des points d'accès cohérents pour les applications. Le service ClusterIP assure les fonctions suivantes.

Crée une IP virtuelle ( ClusterIP ) accessible uniquement au sein du cluster
ClusterIP est le type de service par défaut s'il n'est pas spécifié
Fournit un équilibrage de charge interne entre les pods de backend
Utilise kube-proxy ou OVN- Kubernetes pour la distribution du trafic

Les cas d'utilisation suivants sont un exemple de ce à quoi sert un site ClusterIP.

Communication interne des microservices
Services backend ne nécessitant pas d'accès externe
Services de base de données accessibles uniquement par les charges de travail en grappe
Découverte de services inter-pods

Service NodePort

Expose le service sur un port statique (30000-32767) sur chaque nœud de travailleur
Rend le service accessible par <NodeIP>:<NodePort>
Création automatique du service ClusterIP
Le trafic à destination de n'importe quel site NodePort est acheminé vers le service

L'exemple suivant montre le flux de trafic NodePort.

Le client externe se connecte à <WorkerNodeIP>:<NodePort>
Les nœuds transmettent le trafic au service ClusterIP
Le service équilibre la charge entre les pods de backend
La réponse emprunte le chemin inverse avec le SNAT (traduction d'adresse réseau source)

Les cas d'utilisation suivants sont un exemple de ce à quoi sert NodePorts.

Environnements de développement et de test
Accès externe rapide sans répartiteur de charge
Intégration avec des équilibreurs de charge externes
Solutions personnalisées d'équilibrage de la charge

Service d'équilibreur de charge

Sur IBM Cloud Red Hat OpenShift Kubernetes Service, le service d'équilibreur de charge fournit automatiquement un équilibreur de charge de réseau VPC ou un équilibreur de charge d'application. Le service d'équilibrage de charge assure les fonctions suivantes.

Mise à disposition automatique d'un équilibreur de charge externe
Attribue une IP externe ou un nom d'hôte au service
Création automatique des services NodePort et ClusterIP
Fournit un équilibrage de charge de niveau 4 aux backends des services

L'exemple suivant montre le flux de trafic dans un VPC.

Un client externe se connecte à l'équilibreur de charge VPC IP ou nom d'hôte
L'équilibreur de charge du VPC distribue les données au nœud de travail NodePorts
Node vers le service ClusterIP
Le service équilibre la charge entre les pods de backend

Les cas d'utilisation suivants sont un exemple de ce à quoi servent les équilibreurs de charge.

Applications de production nécessitant un accès externe dédié
Protocoles non HTTP (services TCP ou UDP )
Applications nécessitant des adresses IP externes stables
Services qui contournent la couche d'entrée ou d'acheminement

Red Hat OpenShift itinéraires

Red Hat OpenShift Les routes exposent les services au trafic réseau externe en associant des noms de domaine complets (FQDN) aux services backend, ce qui rend les applications accessibles depuis l'extérieur du cluster. La liste suivante présente les principales caractéristiques de Red Hat OpenShift Routes.

Routage de la couche 7 - HTTP / HTTPS trafic avec routage basé sur le nom d'hôte
DNS automatique - les itinéraires utilisent le sous-domaine du cluster : <route-name>-<namespace>.apps.<cluster-domain>
Itinéraires non sécurisés ( HTTP )
Terminaison TLS
- Itinéraires terminés par le bord ( TLS au niveau du routeur)
- Itinéraires de passage ( TLS à Pod)
- Recryptage des itinéraires ( TLS au niveau du routeur et du Pod)
HAProxy-est mis en œuvre par le contrôleur d'entrée (routeur) Red Hat OpenShift
Gestion du trafic - Routage basé sur le chemin, division du trafic et affinité de session

Réseau virtuel ouvert (OVN)

Le plug-in CNI (Container Network Interface) OVN- Kubernetes est l'option réseau recommandée pour la virtualisation « Red Hat OpenShift », qui prend en charge les cas d'utilisation de mise en réseau de serveurs virtuels fonctionnant parallèlement à la mise en réseau traditionnelle des pods. OVN- Kubernetes repose sur Open Virtual Networking (OVN) et utilise Open vSwitch (OVS) sur chaque nœud de travail. Il prend en charge la multi-location, NetworkPolicies, et les serveurs virtuels hybrides ainsi que la mise en réseau des pods. Red Hat OpenShift on IBM Cloud VPC prend en charge OVN- Kubernetes en tant que plug-in de mise en réseau par défaut.

Pour les administrateurs familiarisés avec VMware vSphere et NSX-T, consultez la section « Réseau OVN » sur OpenShift destinée aux administrateurs d' vSphere, qui présente une correspondance entre les concepts OVN et leurs équivalents dans vSphere.

Dans Red Hat OpenShift avec OVN, les trois topologies de réseau suivantes fournissent une connectivité réseau secondaire aux pods et aux serveurs virtuels.

Couche 2 ( L2 )- Domaines de diffusion L2 définis par logiciel en utilisant l'encapsulation Geneve
Couche 3 ( L3 )- Segments de réseau routés avec des sous-réseaux IP personnalisés. Un réseau « L3 » dispose d'un CIDR (Classless Inter-Domain Routing) distinct pour chaque nœud.
Localnet - Accès direct au réseau physique sous-jacent VLANs

Dans Red Hat OpenShift Virtualization on IBM Cloud, OVN layer 2 et OVN localnet sont les deux principales topologies utilisées avec les réseaux définis par l'utilisateur (UDN).

La couche 2 de l'OVN fournit un réseau superposé similaire aux segments superposés NSX en utilisant l'encapsulation Geneve pour créer des domaines de diffusion L2 définis par logiciel à travers le cluster. Ces réseaux sont isolés des sous-réseaux du VPC. Ils nécessitent un pod de passerelle ou un serveur virtuel connecté à un réseau local OVN pour assurer l'entrée et la sortie vers le sous-réseau VPC et une route VPC.
OVN Localnet fournit un accès VLAN au réseau VPC sous-jacent et est similaire aux segments soutenus par VLAN de NSX. Dans IBM Cloud VPC, cette connectivité directe permet aux serveurs virtuels et aux pods de se connecter directement aux sous-réseaux VPC en utilisant une interface réseau virtuelle (VNI) et des attachements VLAN.

Le diagramme suivant présente une vue d'ensemble de la mise en réseau des serveurs virtuels avec OVN et multus. Par défaut, Kubernetes (et Red Hat OpenShift ) attribue une interface réseau unique à chaque pod en utilisant un plug-in CNI primaire (tel que OVN- Kubernetes ). Multus in Red Hat OpenShift est un plug-in CNI qui permet d'utiliser plusieurs interfaces réseau pour les pods et les serveurs virtuels.

Dans un premier temps, seul le réseau OVN de niveau 2 est disponible.

Réseaux définis par l'utilisateur OVN

Red Hat OpenShift Virtualisation

Un réseau défini par l'utilisateur (UDN) dans Red Hat OpenShift est un réseau personnalisé fourni par OVN- Kubernetes. Un UDN remplace le réseau cluster par défaut (également connu sous le nom de réseau pod par défaut). Les UDN permettent de créer des réseaux avec leurs propres sous-réseaux IP, passerelles et domaines de routage. Les UDN sont indépendants du réseau de pods primaire et sont généralement utilisés lorsque les charges de travail requièrent les fonctions suivantes.

Isolation du réseau par rapport aux autres applications de la grappe
Plages d'adresses IP personnalisées ou sous-réseaux se chevauchant
Contrôle direct du trafic est-ouest entre les espaces de noms ou les charges de travail sélectionnés
Intégration avec des serveurs virtuels ( Red Hat OpenShift virtualization) qui nécessitent plusieurs interfaces réseau
Segments de réseau dédiés pour répondre aux exigences de sécurité ou de conformité

Contrairement au réseau de pods par défaut, les UDN sont explicitement rattachés à des espaces de noms. Chaque UDN crée un commutateur logique supplémentaire dans OVN. Lorsqu'un UDN est désigné comme réseau principal défini par l'utilisateur de l'espace de noms, tous les pods et serveurs virtuels de cet espace de noms l'utilisent comme réseau principal au lieu du réseau par défaut du cluster.

Le Cluster User-Defined Network (CUDN) étend le concept UDN en fournissant une ressource à l'échelle du cluster qui n'appartient à aucun espace de noms spécifique. Un CUDN est créé et associé à un ou plusieurs espaces de noms. Contrairement aux ressources NetworkAttachmentDefinition (NAD) adaptées à l'espace de noms, qui nécessitent une ressource par espace de noms, un CUDN crée automatiquement des NAD dans les espaces de noms lorsque ces derniers sont ajoutés à la définition du CUDN.

Les UDN offrent des options de mise en réseau flexibles basées sur la portée, la méthode d'attachement et la topologie :

Champ d'application du réseau

UDN à espace de noms - Définition de réseau limitée à un seul espace de noms, nécessitant une adresse NetworkAttachmentDefinitions distincte pour chaque espace de noms
CUDN à l'échelle du cluster - Définition du réseau disponible à l'échelle du cluster, créant automatiquement NetworkAttachmentDefinitions dans les espaces de noms sélectionnés

Méthode de fixation

Réseau primaire - Il s'agit du réseau par défaut pour tous les pods/serveurs virtuels de l'espace de noms, qui remplace le réseau par défaut du cluster
Réseau secondaire - Attaché par Multus CNI pour fournir des interfaces réseau supplémentaires aux pods/serveurs virtuels en plus du réseau primaire

Topologie de réseau

Couche 2 - Domaine de diffusion « L2 » défini par logiciel, grâce à l'encapsulation Geneve qui permet la découverte via le protocole ARP (Address Resolution Protocol) et la communication de MAC à MAC
Couche 3 - Segments de réseau routés avec des sous-réseaux IP et des passerelles personnalisés
Localnet - Accès VLAN direct aux sous-réseaux VPC sous-jacents à l'aide d'interfaces réseau virtuelles (VNI)

Vous pouvez combiner ces caractéristiques pour créer des solutions de mise en réseau personnalisées. Par exemple, un CUDN à l'échelle d'un cluster qui utilise la topologie localnet peut fournir plusieurs espaces de noms avec un accès direct au sous-réseau VPC en tant que réseau primaire ou secondaire.

OVN Réseaux de couche 2

Un réseau OVN de couche 2 est un domaine de diffusion de couche 2 défini par logiciel qui est similaire à un segment de superposition NSX ou à un VLAN traditionnel. La couche 2 est entièrement mise en œuvre dans OVN en utilisant l'encapsulation Geneve sur l'infrastructure réseau existante du cluster. Un réseau de couche 2 permet aux pods et aux serveurs virtuels de communiquer comme s'ils se trouvaient sur le même segment Ethernet, avec une prise en charge de la découverte ARP, de la diffusion, de la multidiffusion et de la communication directe MAC à MAC.

Un cluster Red Hat OpenShift dispose d'un réseau cluster primaire où les pods et les serveurs virtuels reçoivent des IP à partir du CIDR du cluster par défaut qui est acheminé via OVN. Vous définissez un réseau secondaire de couche 2 par le biais d'un ClusterUserDefinedNetwork (CUDN) ou d'un UDN à espace de noms. Un réseau secondaire de couche 2 est un réseau supplémentaire que vous créez en plus du réseau de pods par défaut.

Les éléments suivants sont des caractéristiques essentielles des réseaux de couche 2.

Fournir des domaines de diffusion de couche 2 créés par OVN avec IPAM, attribution de MAC et connectivité
Pas de résolution DNS intégrée pour les noms de pods sur les réseaux secondaires
Le trafic provenant du réseau de couche 2 principal fait l'objet d'une traduction d'adresse réseau (NAT) au niveau de la source lorsqu'il quitte le serveur virtuel; il est également acheminé vers le réseau de couche 2, dont l'accès peut être configuré à l'aide d' FRR-K8s s et de routes VPC
Les réseaux secondaires de niveau 2 sont isolés par défaut et n'ont pas d'accès direct à l'internet, sauf s'ils sont explicitement configurés
Convient à la communication entre serveurs virtuels au sein du cluster et aux applications dépendantes de la multidiffusion

OVN Réseaux locaux

Un réseau OVN Localnet fournit aux serveurs virtuels et aux pods un accès VLAN direct à l'infrastructure réseau VPC sous-jacente. OVN Localnet permet aux serveurs virtuels et aux pods de se connecter aux sous-réseaux VPC à l'aide d'une interface réseau virtuelle (VNI) et d'attachements VLAN.

Avec les attachements VLAN, vous pouvez attacher directement les serveurs virtuels qui fonctionnent sur Red Hat OpenShift Virtualization aux sous-réseaux VPC. Cette approche vous permet d'utiliser la conception de votre sous-réseau VPC existant pour des serveurs virtuels nouveaux ou migrés, en fournissant un réseau cohérent pour l'ensemble de vos charges de travail.

Le réseau local exige que chaque carte d'interface réseau de serveur virtuel attachée à un sous-réseau VPC remplisse les conditions suivantes :

Une ressource Virtual Network Interface (VNI) qui définit une adresse IP réservée dans le sous-réseau VPC et un ou plusieurs groupes de sécurité qui contrôlent le trafic entrant et sortant vers la VNI.
Attachement d'un VLAN à un serveur bare metal. La fonctionnalité de « floating » de cette connexion VLAN, qui détermine si celle-ci peut être déplacée d'un nœud de travail à un autre, doit être activée pour que le serveur virtuel puisse être migré en direct vers un autre nœud de travail.
UN ID VLAN. La balise VLAN associe l'interface PCI aux nœuds de travail. En général, cette association est une correspondance biunivoque entre l'ID du VLAN et le sous-réseau du VPC.

Lorsque vous concevez des règles de groupe de sécurité pour les réseaux locaux, tenez compte du fait qu'une partie de la commutation de réseau s'effectue au sein d'OVS sur le nœud de travail et n'atteint jamais l'infrastructure VPC. Les règles des groupes de sécurité ne s'appliquent qu'au trafic qui traverse la structure du réseau VPC. Le trafic entre les serveurs virtuels situés sur le même nœud de travail peut contourner les contrôles de sécurité du VPC.

Les exemples suivants illustrent des cas d'utilisation de Localnet.

Serveurs virtuels migrés nécessitant des adresses IP de sous-réseau VPC existantes
Intégration avec les groupes de sécurité VPC et les politiques de réseau existants
Connectivité directe avec d'autres ressources VPC
Exigences de conformité pour la segmentation du réseau par l'utilisation de sous-réseaux VPC
Architectures hybrides nécessitant un adressage IP cohérent entre VPC et Red Hat OpenShift Virtualisation

Etapes suivantes

Maintenant que vous comprenez la conception du réseau pour la virtualisation Red Hat OpenShift, explorez ces sujets connexes :

Sécurité: Examiner les considérations relatives à la conception de la sécurité, y compris les politiques de réseau et les CSC
Calcul: Explorer les options de conception de calcul pour les nœuds de travail
Stockage: Apprendre les modèles de conception de stockage pour les volumes persistants
Observabilité: Comprendre les solutions d'observabilité pour la surveillance des réseaux