Prise en charge de plusieurs sous-réseaux dans Host Networking Service

S'applique à Windows Server 2022

L’utilisation de plusieurs sous-réseaux par réseau est désormais prise en charge dans le service de mise en réseau hôte (HNS) pour les conteneurs Windows. Auparavant, les configurations de point de terminaison de conteneur Kubernetes restreintes HNS n’utilisent que la longueur du préfixe du sous-réseau sous-jacent. HNS a été amélioré afin de pouvoir utiliser des sous-réseaux plus restrictifs, tels que des sous-réseaux avec une longueur de préfixe plus longue, ainsi que plusieurs sous-réseaux par nœud Worker Windows. La première interface de mise en réseau de conteneurs (CNI) qui peut cette fonctionnalité est Calico pour Windows. Les stratégies réseau Calico sont un réseau open source et une solution de sécurité réseau fondée par Tigera.

Vous pouvez utiliser plusieurs sous-réseaux dans HNS uniquement pour les pilotes réseau l2bridge, l2tunnel et superposition . Ces pilotes réseau peuvent exposer plusieurs sous-réseaux, puis autoriser chaque point de terminaison à se lier à l’un de ces sous-réseaux.

HNS et hcS (Host Compute Service) fonctionnent ensemble pour créer des conteneurs et attacher des points de terminaison à un réseau. Vous pouvez interagir avec HNS à l’aide du module HNS PowerShell Helper.

Exigences de Calico

La prise en charge de plusieurs sous-réseaux pour le CNI Calico nécessite de subdivider le sous-réseau en blocs IP plus petits. Tous les blocs IP doivent partager la même passerelle, mais chaque bloc IP peut avoir son propre domaine de diffusion distinct. Pour optimiser l’allocation IPV4 afin qu’elle soit aussi efficace que possible, Calico nécessite la création de blocs IP très petits (aussi petits qu’un bloc = quatre adresses IP), en plus de définir des préfixes très petits sur des points de terminaison de conteneur (aussi petits que /32).

Une implémentation complète de Calico Gestion des adresses IP (IPAM) fonctionne comme suit :

La fonction IPAM de Calico est conçue pour allouer des adresses IP aux charges de travail à la demande. Calico prend également en charge plusieurs pools IP pour le regroupement d’administration. Lors de la configuration d’une allocation pour une charge de travail particulière, l’ensemble de pools autorisés peut être limité par la configuration, ce qui permet différents cas d’usage. Suivez les instructions ci-dessous pour différents cas d’usage :

• Utilisez plusieurs pools disjoints pour augmenter la capacité.
• Pour les réseaux l2bridge au sein d’un rack, configurez un pool IP par rack où les hôtes d’un rack ne peuvent allouer qu’à partir d’un pool particulier.
• Utilisez un pool IP par niveau de pile où les pods frontaux obtiennent des adresses IP à partir d’un pool frontal (qui peut être public), mais les pods principaux (potentiellement sur le même hôte) reçoivent des adresses IP d’une plage différente. Cela permet à Calico de s’adapter aux exigences de partitionnement réseau agressives (comme cela peut être nécessaire pour travailler avec des pare-feu hérités).
• Utilisez des micro pools très petits, un pour chaque niveau d’une pile. Étant donné que ces pools sont si petits, ils nécessitent que chaque hôte prennent en charge les charges de travail de plusieurs pools.

Les adresses IP sont toujours allouées à partir de blocs, et ces blocs peuvent être affineux à un hôte particulier. Un hôte essaie toujours d’affecter des adresses IP de l’un de ses propres blocs affine s’il y a de l’espace (et uniquement si le bloc provient d’un pool autorisé pour la charge de travail donnée). Si aucun des blocs existants de l’hôte n’a d’espace, l’hôte tente de revendiquer un nouveau bloc à partir d’un pool autorisé. Si aucun bloc vide n’est disponible, l’hôte emprunte une adresse IP à partir d’un bloc dans un pool autorisé qui dispose d’un espace libre disponible, même si ce bloc est affine à un autre hôte.

Calico s’appuie sur le routage de correspondance de préfixe le plus long pour prendre en charge l’agrégation. Chaque hôte publie des itinéraires pour tous ses blocs affine et publie des itinéraires /32 pour les adresses IP qu’il a empruntées. Étant donné qu’une route /32 est plus spécifique, les hôtes distants qui doivent transférer vers le /32 utiliseront l’itinéraire /32 au lieu de l’itinéraire /26 plus large vers l’hôte avec le bloc affine.

Étant donné que Calico est un réseau L3 routé, il est important de noter que les itinéraires /26 ne sont pas destinés à être des sous-réseaux. Par exemple, il n’existe aucune adresse réseau ou de diffusion ; et les adresses « 0 » et « 255 » d’un bloc sont utilisées comme adresses IP normales.

Exigences du plan de données Calico HNS

Il existe plusieurs exigences de connectivité et de stratégie Calico pour activer plusieurs sous-réseaux dans HNS :

• Toutes les charges de travail sur le même hôte doivent avoir une connectivité entre elles et à des pods distants.
• Tous les chemins d’accès de paquets entre les pods doivent avoir les éléments suivants si l’expéditeur et le destinataire sont colocalisés sur le même hôte et s’ils accèdent directement ou par l’adresse IP du cluster de service :
  • Les stratégies de sortie et de sortie de liste de contrôle d’accès (ACL) doivent s’appliquer.
  • La stratégie de sortie du pod d’envoi et la stratégie d’entrée du pod de réception doivent autoriser le trafic.
  • Toutes les règles ACL programmées par Calico doivent être en mesure d’afficher les adresses IP de pod.
• Les hôtes et les pods doivent être en mesure d’atteindre les uns les autres et d’atteindre des pods sur d’autres hôtes sur des itinéraires appris via le protocole BGP (Border Gateway Protocol).

Plusieurs blocs IP par configuration requise pour l’hôte

Pour prendre en charge plusieurs blocs IP par hôte, passez en revue les exigences suivantes :

• Pour un pool d’adresses IP unique donné, le plan de données doit autoriser l’ajout de pods avec des adresses IP provenant de blocs IP disjoints différents. Par exemple, le pool d’adresses IP peut être 10.0.0.0/16, mais un hôte peut revendiquer une paire de blocs aléatoires : 10.0.123.0/26 et 10.0.200.0/26.
• Le pool et la taille des blocs n’ont pas besoin d’être connus avant la première allocation. Cette vérification est fortement recommandée.
• D’autres blocs du même pool peuvent être présents sur d’autres hôtes.
• Le préfixe commun des différents blocs peut chevaucher la propre adresse IP de l’hôte.

Conditions requises pour prendre en charge les emprunts IP

Calico IPAM alloue des adresses IP à héberger dans des blocs à des fins d’agrégation. Si le pool d’adresses IP est plein, les nœuds peuvent également emprunter des adresses IP à partir du bloc d’un autre nœud. En termes BGP, l’emprunteur publie ensuite une route plus spécifique /32 pour l’adresse IP empruntée, puis le trafic pour cette adresse IP est acheminé vers l’hôte d’emprunt.

Les nœuds Windows ne prennent pas en charge ce mécanisme d’emprunt. Ils n’empruntent pas d’adresses IP même si le pool d’adresses IP est plein et marquent leurs blocs afin que les nœuds Linux ne les empruntent pas non plus.

Conditions requises pour prendre en charge les micropools

Pour utiliser des micropools, la nécessité de réserver quatre adresses IP par bloc est supprimée. Dans le cas d’usage du micropool, très petits pools et très petits blocs sont utilisés, donc quatre adresses IP par bloc gaspillent la plupart des adresses IP. Vous pouvez exiger un petit nombre d’adresses IP réservées par hôte ou par pool. Une bonne pratique consiste à avoir toutes les restrictions de prise en charge de couche 2 levées (par exemple, il ne doit pas y avoir de prise en charge de la diffusion et aucune adresse IP réservée).

Créer un sous-réseau et un sous-réseau IP à l’aide de PowerShell

Avant de continuer, vérifiez que le module HNS.V2.psm1 est installé à partir de la galerie PowerShell HNS.

Les étapes suivantes expliquent comment créer un sous-réseau et un sous-réseau IP à l’aide d’exemples.

1. Pour créer un réseau am l2bridge avec un sous-réseau IP 192.168.0.0/16 qui contient un sous-réseau IP 192.168.1.0/24 et un sous-réseau IP 192.168.2.0/24, exécutez la commande suivante :

   $net1 = New-HnsNetwork -Type L2Bridge -Name Test1 -AddressPrefix "192.168.0.0/16" -Gateway "192.168.0.1" -Verbose -IPSubnets @(@{"IpAddressPrefix"="192.168.1.0/24";"Flags"=0},@{"IpAddressPrefix"="192.168.2.0/24";"Flags"=[IPSubnetFlags]::EnableBroadcast})
   

2. Pour ajouter un nouveau sous-réseau 172.16.0.0/16 qui contient un sous-réseau IP 172.1.0/16 au réseau l2bridge , exécutez la commande suivante :

   New-HnsSubnet -NetworkID $net1.ID -Subnets @{
       "IpAddressPrefix"="172.16.0.0/16";
       "Routes"=@(@{"NextHop"="172.16.0.1";"DestinationPrefix"="0.0.0.0"});
       "IpSubnets"=@(@{"IpAddressPrefix"="172.16.1.0/24"})
   

3. Pour ajouter un nouveau sous-réseau IP 172.16.2.0/24 au sous-réseau 172.16.0.0/16, exécutez la commande suivante :

   New-HnsIPSubnet -NetworkID $net1.ID -SubnetID $net2.Subnets[1].ID -IPSubnets @{"IpAddressPrefix"="172.16.2.0/24";"Flags"=0}
   

Pour supprimer les sous-réseaux IP, procédez comme suit :

1. Pour supprimer le sous-réseau IP 172.16.2.0/24, exécutez la commande suivante :

      $net2 = Get-HnsNetwork -ID $net1.ID
      Remove-HnsIpSubnet -NetworkID $net1.ID -SubnetID $net2.Subnets[1].ID -IPSubnets @{"ID"=$net2.Subnets[1].IPSubnets[1].ID}
   

2. Pour supprimer le sous-réseau 172.16.0.0/16, exécutez la commande suivante :

   Remove-HnsSubnet -NetworkID $net1.ID -Subnets @{"ID"=$net2.Subnets[1].ID}