Stöd för flera undernät i värdnätverkstjänsten
Gäller för: Windows Server 2025, Windows Server 2022
Användning av flera undernät per nätverk stöds nu i Värdnätverkstjänst (HNS) för Windows-containrar. Tidigare begränsade HNS Kubernetes containerslutpunktskonfigurationer till att endast använda prefixlängden för det underliggande undernätet. HNS har förbättrats så att du kan använda mer restriktiva undernät, till exempel undernät med längre prefixlängd, samt flera undernät per Windows-arbetsnod. Den första CNI (Container Networking Interface) som kan den här funktionen är Calico för Windows. Calico Network Policies är en nätverks- och nätverkssäkerhetslösning med öppen källkod som grundades av Tigera.
Du kan bara använda flera undernät i HNS för l2bridge, l2tunneloch overlay nätverksdrivrutiner. Dessa nätverksdrivrutiner kan exponera flera undernät och sedan tillåta att varje slutpunkt binder till ett av dessa undernät.
HNS och HCS (Host Compute Service) arbetar tillsammans för att skapa containrar och koppla slutpunkter till ett nätverk. Du kan interagera med HNS med hjälp av HNS Powershell-hjälpmodulen.
Calico-krav
Stöd för flera undernät för Calico CNI kräver att undernätet delas upp i mindre IP-block. Alla IP-block måste dela samma gateway, men varje IP-block kan ha en egen separat sändningsdomän. För att maximera IPV4-allokeringen så att den blir så effektiv som möjligt måste Calico skapa mycket små IP-block (så små som ett block = fyra IP-adresser), förutom att ange mycket små prefix på containerslutpunkter (så små som /32).
En fullständig implementering av Calico IP Address Management (IPAM) fungerar på följande sätt:
Calicos IPAM-funktion är utformad för att allokera IP-adresser till arbetsbelastningar på begäran. Calico har också stöd för flera IP-pooler för administrativ gruppering. När du konfigurerar en allokering för en viss arbetsbelastning kan uppsättningen tillåtna pooler begränsas av konfigurationen, vilket möjliggör olika användningsfall. Följ riktlinjerna nedan för olika användningsfall:
- Använd flera olika pooler för att öka kapaciteten.
- För l2bridge nätverk i ett rack konfigurerar du en IP-pool per rack där värdarna i ett rack bara kan allokera från en viss pool.
- Använd en IP-pool per stacknivå där klientdelspoddar får IP-adresser från en klientdelspool (som kan vara offentlig), men serverdelspoddar (eventuellt på samma värd) tar emot IP-adresser från ett annat intervall. Detta gör att Calico kan passa in med aggressiva krav för nätverkspartitionering (vilket kan behövas för att arbeta med äldre brandväggar).
- Använd mycket små mikropooler, en för varje nivå i en stack. Eftersom dessa pooler är så små kräver de att varje värd stöder arbetsbelastningar från flera pooler.
IP-adresser allokeras alltid från block, och de kan vara associerade med en viss värd. En värd försöker alltid tilldela IP-adresser från ett av sina egna affinblock om det finns utrymme (och endast om blocket kommer från en tillåten pool för den angivna arbetsbelastningen). Om inget av värdens befintliga block har utrymme, kommer värden att försöka ta i anspråk ett nytt block från en tillåten pool. Om inga tomma block är tillgängliga, lånar värden en IP-adress från något block i en tillåten pool med ledigt utrymme, även om blocket är kopplat till en annan värd.
Calico förlitar sig på längsta prefixmatchningsrutting för att stödja aggregering. Varje värd annonserar rutter för alla sina affina block och annonserar /32 rutter för alla IP-adresser som den har lånat tillfälligt. Eftersom en /32-väg är mer specifik kommer avlägsna värdar som behöver vidarebefordra till en /32-väg att använda /32-vägen istället för den bredare /26-vägen till värden med affine-blocket.
Eftersom Calico är ett dirigerat L3-nätverk är det värt att notera att /26-vägarna inte är avsedda att vara undernät. Det finns till exempel ingen nätverks- eller sändningsadress. och adresserna "0" och "255" för ett block används som vanliga IP-adresser.
Krav för Calico HNS-dataplan
Det finns flera Calico-anslutningskrav och principkrav för att aktivera flera undernät i HNS:
- Alla arbetsbelastningar på samma värd måste ha anslutning till varandra och till fjärrpoddar.
- Alla paketsökvägar mellan poddar bör ha följande oavsett om avsändaren och mottagaren finns på samma värd eller inte och om de kommer åt varandra antingen direkt eller via ip-adressen för tjänstklustret:
- Principer för åtkomstkontrollistor (ACL) för utgående och ingående trafik måste tillämpas.
- Både utgående policy för den sändande podden och ingående policy för den mottagande podden måste tillåta trafiken.
- Alla Calico-programmerade ACL-regler bör kunna visa podd-IP-adresser.
- Värdar och poddar måste kunna nå varandra och nå poddar på andra värdar via vägar som har lärts via BGP (Border Gateway Protocol).
Flera IP-block enligt värdkrav
För att stödja flera IP-block per värd, granska följande krav:
- För en viss enskild IP-pool måste dataplanet tillåta att poddar läggs till med IP-adresser från olika, uppdelade IP-block. IP-poolen kan till exempel vara 10.0.0.0/16, men en värd kan kräva ett par slumpmässiga block: 10.0.123.0/26 och 10.0.200.0/26.
- Poolen och storleken på blocken behöver inte vara kända före den första allokeringen. Detta rekommenderas starkt.
- Andra block från samma pool kan finnas på andra värdar.
- Det gemensamma prefixet för de olika blocken kan överlappa värdens egen IP-adress.
Krav för att stödja IP-lån
Calico IPAM allokerar IP-adresser till värd i block för aggregeringsändamål. Om IP-poolen är full kan noder också låna IP-adresser från blocket för en annan nod. I BGP-sammanhang annonserar låntagaren sedan en mer specifik /32-väg för den lånade IP-adressen och därefter dirigeras trafiken för den IP-adressen till den låntagande värden.
Windows-noder stöder inte den här lånemekanismen. De lånar inte IP-adresser även om IP-poolen är full, och de markerar sina block så att Linux-noder inte heller lånar från dem.
Krav för att stödja mikropooler
Om du vill använda mikropooler tas kravet på att reservera fyra IP-adresser per block bort. I användningsfallet för mikropooler används mycket små pooler och mycket små block, så fyra IP-adresser per block slösar bort de flesta IP-adresser. Du kan kräva ett litet antal reserverade IP-adresser, antingen per värd eller per pool. Bästa praxis är att alla layer 2 stödbegränsningarna upphävs (till exempel bör det inte finnas något stöd för sändning och inga reserverade IP-adresser).
Skapa ett undernät och ett IP-undernät med PowerShell
Innan du fortsätter kontrollerar du att HNS.V2.psm1-modulen är installerad från HNS PowerShell-galleriet.
Följande steg beskriver hur du skapar ett undernät och ett IP-undernät med hjälp av exempel.
Kör följande kommando för att skapa am l2bridge nätverk med ett 192.168.0.0/16-undernät som innehåller ett 192.168.1.0/24 IP-undernät och ett 192.168.2.0/24 IP-undernät:
$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})Om du vill lägga till ett nytt 172.16.0.0/16-undernät som innehåller ett 172.16.1.0/16 IP-undernät i l2bridge- nätverk kör du följande kommando:
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"})Om du vill lägga till ett nytt 172.16.2.0/24 IP-undernät i undernätet 172.16.0.0/16 kör du följande kommando:
New-HnsIPSubnet -NetworkID $net1.ID -SubnetID $net2.Subnets[1].ID -IPSubnets @{"IpAddressPrefix"="172.16.2.0/24";"Flags"=0}
Om du vill ta bort IP-undernäten använder du följande steg:
Kör följande kommando för att ta bort IP-undernätet 172.16.2.0/24:
$net2 = Get-HnsNetwork -ID $net1.ID Remove-HnsIpSubnet -NetworkID $net1.ID -SubnetID $net2.Subnets[1].ID -IPSubnets @{"ID"=$net2.Subnets[1].IPSubnets[1].ID}Om du vill ta bort undernätet 172.16.0.0/16 kör du följande kommando:
Remove-HnsSubnet -NetworkID $net1.ID -Subnets @{"ID"=$net2.Subnets[1].ID}