Planera ditt klusternätverk för Azure Red Hat OpenShift med värdbaserade kontrollplan (förhandsversion)

Azure Red Hat OpenShift med värdbaserade kontrollplan distribuerar arbetsnoder till ditt Azure virtuella nätverk och använder ett dedikerat undernät för att upprätta privat anslutning mellan det värdbaserade kontrollplanet och dina arbetsnoder. Du måste planera layouten för det virtuella nätverket, undernäten och IP-adressintervallen innan du skapar klustret.

Planera beräkningskapacitet

Nodpooler ger beräkningskapacitet. En nodpool är en grupp arbetsnoder som delar samma VM-storlek, diskkonfiguration och tillgänglighetszon. Du kan skapa flera nodpooler i ett enda kluster för att köra olika arbetsbelastningstyper på olika maskinvara. Information om vm-storlekar för arbetsnoder som stöds finns i Storlekar på virtuella datorer som stöds. Flera beslut om nodpooler påverkar nätverkslayouten direkt, så du måste planera beräkningskapaciteten innan du storleksanpassar nätverket.

Genom att svara på följande frågor kan du planera undernäten och IP-adressintervallen för klustret:

• Hur många nodpooler kommer du att köra? Antalet nodpooler avgör hur många undernät du kan behöva. Om alla pooler delar klustrets standardarbetsundernät räcker det med ett undernät. Om du tilldelar separata undernät till olika pooler lägger var och en till dina CIDR-krav för det virtuella nätverket och datorn.
• Kommer du att driftsätta över flera tillgänglighetszoner? Varje nodpool distribueras till en enda tillgänglighetszon. För att distribuera arbetsbelastningar mellan zoner för hög tillgänglighet behöver du en separat nodpool och eventuellt ett separat undernät för varje zon. Fler zoner innebär fler undernät och en större CIDR för datorn.
• Kommer varje nodpool att använda ett eget undernät? Nodpooler distribueras till klustrets standardarbetsundernät om du inte anger ett annat undernät. Separata undernät ger dig nätverksisolering mellan nodpooler, men varje undernät måste passa in i datorns CIDR-intervall och adressutrymme för virtuella nätverk.
• Hur många noder kommer du att köra som mest? Det maximala antalet noder, inklusive maxvärden för automatisk skalning, avgör hur stort varje undernät måste vara. Klustret stöder högst 500 noder totalt i alla pooler.
• Kommer du att lägga till fler nodpooler senare? Klustrets CIDR-intervall kan inte ändras när det har skapats. Om du planerar att lägga till nodpooler med nya undernät i framtiden måste datorns CIDR och virtuella nätverk ha tillräckligt med adressutrymme för att rymma dem.

Tips/Råd

Storleksexempel: Ett kluster med 3 tillgänglighetszoner, upp till 50 noder per zon och ett separat undernät per zon behöver tre /26 undernät (64 adresser vardera, 50 noder plus Azure reserverade adresser) och ett /29 undernät för VNet-integrering. Alla fyra undernäten får plats i en /24 dators CIDR (256 adresser). Om du planerar att lägga till fler nodpooler senare använder du en större CIDR-dator, till exempel /22 eller /16 för att lämna plats för ytterligare undernät.

Krav för undernät

Det virtuella nätverket måste innehålla följande komponenter:

• Arbetsundernät – standardundernätet där klustrets arbetsnoder distribueras. När du skapar en nodpool distribueras den till det här undernätet om du inte anger ett annat undernät. Om du planerar att distribuera nodpooler i flera tillgänglighetszoner kan du skapa ett separat undernät för varje zon. Alla nodpoolundernät måste finnas i samma virtuella nätverk som klustret. Ändra storlek på varje undernät baserat på antalet arbetsnoder som du planerar att köra i det.
• VNet-integreringsundernät – ett dedikerat undernät som möjliggör privat anslutning mellan det värdbaserade kontrollplanet (som körs i Red Hats Azure-konto) och arbetsnoderna i din prenumeration. Den måste uppfylla följande krav:
  • Minsta storlek på /29
  • Finns i samma virtuella nätverk som arbetsundernätet
  • Delas inte med arbetsundernätet eller några nodpoolundernät
• Nätverkssäkerhetsgrupper – Om du associerar en nätverkssäkerhetsgrupp (NSG) med ett arbets-, nodpool- eller VNet-integreringsundernät granskar du dess regler mot den trafik som beskrivs i Nödvändig nätverkssäkerhetsgrupptrafik. Du tilldelar NSG:er direkt till undernät.

Nödvändig nätverkssäkerhetsgrupptrafik

Nätverkssäkerhetsgruppen (NSG) som är associerad med nodpoolen och VNet-integreringsundernäten måste tillåta följande trafik:

NSG-association	Riktning	Source	Destination	Destinationshamnar
Undernät för arbets- eller nodpool	Utgående	Undernät för arbets- eller nodpool	Överordnat klusterundernät	TCP 443 och 6443
Undernät för VNet-integrering	Inkommande	Undernät för arbets- eller nodpool	Undernät för VNet-integrering	TCP 443 och 8443

Dessa anslutningar gör det möjligt för arbetsnoder att nå den värdbaserade kube-apiservern och det värdbaserade kontrollplanet. Om en NSG Neka-regel blockerar nödvändig trafik kan du inte skapa nodpooler.

Utför någon av följande åtgärder för att åtgärda en neka-regel som blockerar ett obligatoriskt flöde:

• Ta bort regeln Neka.
• Begränsa Deny-regeln så att den inte matchar den obligatoriska källan, destinationen och portarna.
• Lägg till en Tillåt-regel som matchar den nödvändiga källan, målet och portarna och har högre prioritet än regeln Neka. I en NSG har en lägre numerisk prioritet en högre prioritet.

Azure Red Hat OpenShift med värdbaserade kontrollplan utvärderar TCP-regler och jokerteckenregler som innehåller de portar som krävs. Neka regler för orelaterade portar, UDP-trafik eller orelaterade mål påverkar inte den här valideringen. Dessa regler kan dock fortfarande blockera annan trafik.

CIDR-krav

I följande tabell beskrivs kraven för det virtuella nätverket och CIDR:

Nätverkskrav	Standardinställning	Description
CIDR-intervall för dator	10.0.0.0/16	IP-adressintervallet för beräkningsnoder. Den måste omfatta alla CIDR-adressintervall för dina virtuella nätverksundernät, inklusive eventuella undernät som du planerar att använda för ytterligare nodpooler. Undernät måste vara sammanhängande. Minst 128 adresser (/25) stöds för distributioner i en enda tillgänglighetszon. Minst 256 adresser (/24) stöds för distributioner i flera tillgänglighetszoner.
Tjänst-CIDR-intervall	172.30.0.0/16	IP-adressintervallet för Kubernetes-tjänst-IP-adresser. Intervallet måste vara tillräckligt stort för din arbetsbelastning och får inte överlappa med någon extern tjänst som nås inifrån klustret.
Pod CIDR-intervall	10.128.0.0/14	IP-adressintervallet för poddar. Intervallet måste vara tillräckligt stort för din arbetsbelastning och får inte överlappa med någon extern tjänst som nås inifrån klustret.
Värdprefix	23	Den undernätsprefixlängd som allokerats till varje nod för dess poddar. Ett värde för 23 tilldelar ett /23 undernät (512 IP-adresser) per nod från poddens CIDR-intervall.

Använd standardvärdena om de inte uppfyller dina krav. Om du behöver ändra något av dessa värden följer du dessa riktlinjer:

• Podd-, tjänst- och dator-CIDR får inte överlappa varandra.
• Podd- och tjänst-CIDR får inte överlappa med adressintervall som används i nätverket eller externa tjänster som nås inifrån klustret.
• Datorns CIDR måste omfatta alla virtuella nätverksundernät som används av klustret, inklusive arbetsundernätet, eventuella ytterligare nodpoolundernät och undernätet för VNet-integrering. Om du planerar att lägga till nodpooler med separata undernät i framtiden kontrollerar du att datorns CIDR är tillräckligt stor för att inkludera dem. Om ditt virtuella nätverk till exempel använder 10.0.0.0/16omfattar standarddatorns CIDR 10.0.0.0/16 för alla undernät.
• Poddnätverket använder icke-utfällbara IP-adresser och används endast i klustrets programvarudefinierade nätverk.

Anslutning till privata kluster

Om du väljer en privat API-server, en privat standardingress eller båda, måste du upprätta en privat nätverksanslutning mellan användarnas nätverk och klustrets virtuella nätverk innan du distribuerar klustret. Utan den här anslutningen kan administratörer, CI/CD-pipelines och slutanvändare inte nå de privata slutpunkterna.

Vanliga anslutningsalternativ är:

• Azure VNet-peering – Anslut två Azure virtuella nätverk så att resurser i varje nätverk kan kommunicera med varandra.
• Azure VPN Gateway – Anslut ditt lokala nätverk till klustrets virtuella nätverk via en VPN-tunnel från plats till plats.
• Azure ExpressRoute – Upprätta en privat, dedikerad anslutning från ditt lokala nätverk för att Azure via en anslutningsleverantör.

När du planerar anslutning till privata nätverk ska du se till att IP-adressintervallen för de sammankopplade eller anslutna nätverken inte överlappar klustrets dator-CIDR-, pod-CIDR- eller tjänst-CIDR-intervall.

Nästa steg

Skapa ett kluster