Remarque
L’accès à cette page requiert une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page requiert une autorisation. Vous pouvez essayer de modifier des répertoires.
Azure Red Hat OpenShift avec des plans de contrôle hébergés déploie des nœuds Worker dans votre réseau virtuel Azure et utilise un sous-réseau dédié pour établir une connectivité privée entre le plan de contrôle hébergé et vos nœuds Worker. Vous devez planifier la disposition, les sous-réseaux et les plages d’adresses IP de votre réseau virtuel avant de créer le cluster.
Planifier la capacité de calcul
Les pools de nœuds fournissent une capacité de calcul. Un pool de nœuds est un groupe de nœuds Worker qui partagent la même taille de machine virtuelle, la configuration du disque et la zone de disponibilité. Vous pouvez créer plusieurs pools de nœuds dans un seul cluster pour exécuter différents types de charges de travail sur différents matériels. Pour connaître les tailles de machine virtuelle de nœud Worker prises en charge, consultez Tailles de machine virtuelle prises en charge. Plusieurs décisions de pool de nœuds affectent directement la disposition de votre réseau. Vous devez donc planifier votre capacité de calcul avant de dimensionner votre réseau.
Répondre aux questions suivantes vous aide à planifier les sous-réseaux et les plages d’adresses IP de votre cluster :
- Combien de pools de nœuds exécuterez-vous ? Le nombre de pools de nœuds détermine le nombre de sous-réseaux dont vous avez besoin. Si tous les pools partagent le sous-réseau worker par défaut du cluster, un sous-réseau suffit. Si vous attribuez des sous-réseaux distincts à différents pools, chacun ajoute à vos exigences ciDR de réseau virtuel et de machine virtuelle.
- Allez-vous déployer dans les zones de disponibilité ? Chaque pool de nœuds est déployé dans une seule zone de disponibilité. Pour répartir les charges de travail entre les zones pour la haute disponibilité, vous avez besoin d’un pool de nœuds distinct et potentiellement d’un sous-réseau distinct pour chaque zone. D’autres zones signifient davantage de sous-réseaux et un CIDR d’ordinateur plus grand.
- Chaque pool de nœuds utilisera-t-il son propre sous-réseau ? Les pools de nœuds se déploient dans le sous-réseau worker par défaut du cluster, sauf si vous spécifiez un autre sous-réseau. Les sous-réseaux distincts vous permettent d’isoler le réseau entre les pools de nœuds, mais chaque sous-réseau doit correspondre à la plage CIDR de votre machine et à l’espace d’adressage du réseau virtuel.
- Combien de nœuds ferez-vous fonctionner en période de pointe ? Le nombre maximal de nœuds, y compris les maximums de mise à l’échelle automatique, détermine la taille de chaque sous-réseau. Le cluster prend en charge un total maximal de 500 nœuds sur tous les pools.
- Ajouterez-vous d’autres pools de nœuds ultérieurement ? Les plages CIDR du cluster ne peuvent pas être modifiées après la création. Si vous envisagez d’ajouter des pools de nœuds avec de nouveaux sous-réseaux à l’avenir, votre machine CIDR et votre réseau virtuel doivent disposer d’un espace d’adressage suffisant pour les prendre en charge.
Conseil / Astuce
Exemple de dimensionnement : Un cluster avec 3 zones de disponibilité, jusqu’à 50 nœuds par zone, et un sous-réseau distinct par zone a besoin de trois /26 sous-réseaux (64 adresses chacune, qui hébergent 50 nœuds plus Azure adresses réservées) et un /28 sous-réseau d’intégration de réseau virtuel.
Les quatre sous-réseaux s’intègrent dans un /24 CIDR de machine (256 adresses).
Si vous envisagez d’ajouter d’autres pools de nœuds ultérieurement, utilisez un CIDR d’ordinateur plus grand, tel que /22 ou /16 pour laisser place à des sous-réseaux supplémentaires.
Configuration requise du sous-réseau
Votre réseau virtuel doit contenir les composants suivants :
- Sous-réseau worker : sous-réseau par défaut où les nœuds Worker du cluster sont déployés. Lorsque vous créez un pool de nœuds, il se déploie dans ce sous-réseau, sauf si vous spécifiez un autre sous-réseau. Si vous envisagez de déployer des pools de nœuds sur plusieurs zones de disponibilité, vous pouvez créer un sous-réseau distinct pour chaque zone. Tous les sous-réseaux de pool de nœuds doivent se trouver dans le même réseau virtuel que le cluster. Dimensionnez chaque sous-réseau en fonction du nombre de nœuds de travail que vous prévoyez d’y déployer.
-
Sous-réseau d'intégration de réseau virtuel : sous-réseau dédié qui permet une connectivité privée entre le plan de contrôle hébergé (exécuté dans le compte Azure red Hat) et les nœuds Worker de votre abonnement. Elle doit répondre aux exigences suivantes :
- Taille minimale de
/28 - Situé dans le même réseau virtuel que le sous-réseau de travail
- Non partagé avec le sous-réseau worker ou les sous-réseaux de pool de nœuds
- Taille minimale de
- Groupes de sécurité réseau - Si vous associez un groupe de sécurité réseau (NSG) à un worker, à un pool de nœuds ou à un sous-réseau d’intégration de réseau virtuel, vérifiez que ses règles autorisent le trafic requis décrit dans Trafic requis pour le groupe de sécurité réseau. Vous affectez directement des groupes de sécurité réseau aux sous-réseaux.
Trafic d’un groupe de sécurité réseau requis
Le groupe de sécurité réseau (NSG) associé au pool de nœuds et aux sous-réseaux d’intégration de réseau virtuel doit autoriser le trafic suivant :
| Association NSG | Direction | Source | Destination | Ports de destination |
|---|---|---|---|---|
| Sous-réseau du worker ou du pool de nœuds | Sortant | Sous-réseau du worker ou du pool de nœuds | Sous-réseau du cluster parent | TCP 443 et 6443 |
| Sous-réseau d’intégration VNet | Trafic entrant | Sous-réseau du worker ou du pool de nœuds | Sous-réseau d’intégration VNet | TCP 443 et 8443 |
Ces connexions permettent aux nœuds de travail d’accéder au kube-apiserver hébergé et au plan de contrôle hébergé. Si une règle Deny de groupe de sécurité réseau bloque le trafic requis, vous ne pouvez pas créer des pools de nœuds.
Pour corriger une règle de refus qui bloque un flux requis, effectuez l’une des actions suivantes :
- Supprimez la règle Refuser.
- Limitez la règle Deny afin qu’elle ne corresponde pas à la source, à la destination et aux ports requis.
- Ajoutez une règle Allow qui correspond à la source, à la destination et aux ports requis et qui a une priorité supérieure à la règle Refuser. Dans un NSG, plus le numéro de priorité est bas, plus la priorité est élevée.
Azure Red Hat OpenShift avec les plans de contrôle hébergés évalue les règles TCP et les règles génériques qui incluent les ports requis. Les règles de refus pour les ports non liés, le trafic UDP ou les destinations non liées n’affectent pas cette validation. Toutefois, ces règles peuvent toujours bloquer d’autres trafics.
Exigences CIDR
Le tableau suivant décrit les exigences de réseau virtuel et CIDR :
| Configuration réseau requise | Par défaut | Description |
|---|---|---|
| Plage CIDR de la machine | 10.0.0.0/16 |
Plage d’adresses IP pour les nœuds de calcul. Il doit englober toutes les plages d’adresses CIDR pour vos sous-réseaux de réseau virtuel, y compris les sous-réseaux que vous envisagez d’utiliser pour des pools de nœuds supplémentaires. Les sous-réseaux doivent être contigus. Au moins 128 adresses (/25) sont prises en charge pour les déploiements de zones de disponibilité uniques. Au moins 256 adresses (/24) sont prises en charge pour plusieurs déploiements de zones de disponibilité. |
| Plage CIDR de service | 172.30.0.0/16 |
Plage d’adresses IP pour les adresses IP du service Kubernetes. La plage doit être suffisamment grande pour prendre en charge votre charge de travail, et elle ne doit pas chevaucher un service externe accessible à partir du cluster. |
| Plage CIDR des pods | 10.128.0.0/14 |
Plage d’adresses IP pour les pods. La plage doit être suffisamment grande pour prendre en charge votre charge de travail, et elle ne doit pas chevaucher un service externe accessible à partir du cluster. |
| Préfixe d’hôte | 23 |
Longueur du préfixe de sous-réseau allouée à chaque nœud pour ses pods. Une valeur de 23 attribue un sous-réseau /23 (512 adresses IP) par nœud à partir de la plage CIDR des pods. |
Utilisez les valeurs par défaut, sauf si elles ne répondent pas à vos besoins. Si vous devez modifier l’une de ces valeurs, suivez ces instructions :
- Le pod, le service et les CIDR de machine ne doivent pas se chevaucher.
- Les CIDR de pod et de service ne doivent pas chevaucher les plages d’adresses utilisées sur votre réseau ou les services externes accessibles à partir du cluster.
- Le CIDR de la machine doit englober tous les sous-réseaux de réseau virtuel utilisés par le cluster, y compris le sous-réseau worker, tous les sous-réseaux de pool de nœuds supplémentaires et le sous-réseau d’intégration au réseau virtuel. Si vous envisagez d’ajouter des pools de nœuds avec des sous-réseaux distincts à l’avenir, assurez-vous que le CIDR de l’ordinateur est suffisamment grand pour les inclure. Par exemple, si votre réseau virtuel utilise
10.0.0.0/16, le CIDR de l’ordinateur par défaut couvre10.0.0.0/16tous les sous-réseaux. - Le réseau de pods utilise des adresses IP non routables et est utilisé uniquement à l’intérieur du réseau défini par le logiciel du cluster.
Connectivité de cluster privé
Si vous choisissez un serveur d’API privé, une entrée privée par défaut, ou les deux, vous devez établir une connectivité réseau privée entre les réseaux de vos utilisateurs et le réseau virtuel du cluster avant de déployer le cluster. Sans cette connectivité, les administrateurs, les pipelines CI/CD et les utilisateurs finaux ne peuvent pas atteindre les points de terminaison privés.
Les options de connectivité courantes sont les suivantes :
- Peering de réseaux virtuels Azure - Connectez deux réseaux virtuels Azure afin que les ressources de chaque réseau puissent communiquer les unes avec les autres.
- Passerelle VPN Azure : connectez votre réseau local au réseau virtuel du cluster via un tunnel VPN de site à site.
- Azure ExpressRoute : établissez une connexion privée dédiée de votre réseau local à Azure via un fournisseur de connectivité.
Lors de la planification de la connectivité réseau privée, assurez-vous que les plages d’adresses IP des réseaux en peering ou connectés ne se chevauchent pas avec la plage CIDR des machines du cluster, la plage CIDR des pods ou la plage CIDR des services.