Uw clusternetwerk plannen voor Azure Red Hat OpenShift met gehoste besturingsvlakken (preview)

Azure Red Hat OpenShift met gehoste besturingsvlakken implementeert werkknooppunten in uw Azure virtueel netwerk en maakt gebruik van een toegewezen subnet om een privéverbinding tot stand te brengen tussen het gehoste besturingsvlak en uw werkrolknooppunten. U moet de indeling van uw virtuele netwerk, subnetten en IP-adresbereiken plannen voordat u het cluster maakt.

Rekencapaciteit plannen

Knooppuntgroepen bieden rekencapaciteit. Een knooppuntgroep is een groep werkknooppunten die dezelfde VM-grootte, schijfconfiguratie en beschikbaarheidszone delen. U kunt meerdere knooppuntgroepen in één cluster maken om verschillende workloadtypen op verschillende hardware uit te voeren. Zie Ondersteunde vm-grootten van virtuele machines voor ondersteunde werkknooppunten. Verschillende beslissingen voor knooppuntgroepen zijn rechtstreeks van invloed op uw netwerkindeling, dus u moet uw rekencapaciteit plannen voordat u de grootte van uw netwerk wijzigt.

Door de volgende vragen te beantwoorden, kunt u de subnetten en IP-adresbereiken voor uw cluster plannen:

• Hoeveel nodepools gebruikt u? Het aantal knooppuntgroepen bepaalt hoeveel subnetten u mogelijk nodig hebt. Als alle pools het standaardwerksubnet van het cluster delen, is één subnet voldoende. Als u afzonderlijke subnetten toewijst aan verschillende pools, wordt elk subnet toegevoegd aan de CIDR-vereisten van uw virtuele netwerk en machine.
• Wilt u over meerdere beschikbaarheidszones uitrollen? Elke knooppuntgroep wordt geïmplementeerd in één beschikbaarheidszone. Als u workloads wilt distribueren tussen zones voor hoge beschikbaarheid, hebt u een afzonderlijke knooppuntgroep en mogelijk een afzonderlijk subnet voor elke zone nodig. Meer zones betekent meer subnetten en een grotere machine-CIDR.
• Gebruikt elke knooppuntgroep een eigen subnet? Knooppuntgroepen worden geïmplementeerd in het standaardwerksubnet van het cluster, tenzij u een ander subnet opgeeft. Afzonderlijke subnetten bieden u netwerkisolatie tussen knooppuntgroepen, maar elk subnet moet binnen het CIDR-bereik van uw machine en de adresruimte van het virtuele netwerk passen.
• Hoeveel knooppunten laat je op piekmomenten draaien? Het maximale aantal knooppunten, inclusief de maxima voor automatisch schalen, bepaalt hoe groot elk subnet moet zijn. Het cluster ondersteunt maximaal 500 knooppunten in alle pools.
• Voegt u later meer knooppuntgroepen toe? De CIDR-bereiken van het cluster kunnen niet worden gewijzigd nadat het cluster is gemaakt. Als u van plan bent om in de toekomst knooppuntgroepen met nieuwe subnetten toe te voegen, moeten de CIDR en het virtuele netwerk van uw computer voldoende adresruimte hebben om deze toe te passen.

Subnetvereisten

Uw virtuele netwerk moet de volgende onderdelen bevatten:

• Worker-subnet: het standaardsubnet waarin de werkknooppunten van het cluster worden geïmplementeerd. Wanneer u een knooppuntgroep maakt, wordt deze geïmplementeerd in dit subnet, tenzij u een ander subnet opgeeft. Als u van plan bent om knooppuntgroepen in meerdere beschikbaarheidszones te implementeren, kunt u voor elke zone een afzonderlijk subnet maken. Alle subnetten van de knooppuntgroep moeten zich in hetzelfde virtuele netwerk bevinden als het cluster. Pas de grootte van elk subnet aan op basis van het aantal werknodes dat u erin wilt uitvoeren.
• VNet-integratiesubnet: een toegewezen subnet dat privéconnectiviteit mogelijk maakt tussen het gehoste besturingsvlak (uitgevoerd in het Azure-account van Red Hat) en de werkrolknooppunten in uw abonnement. Deze moet voldoen aan de volgende vereisten:
  • Minimale grootte van /28
  • Zich in hetzelfde virtuele netwerk bevinden als het werksubnet
  • Niet gedeeld met het worker-subnet of een van de subnetten van de nodepool
• Netwerkbeveiligingsgroepen - Als u een netwerkbeveiligingsgroep (NSG) koppelt aan een workerknooppunt, knooppuntgroep of VNet-integratiesubnet, controleer dan of de regels overeenkomen met het vereiste verkeer dat wordt beschreven in Vereist netwerkbeveiligingsgroepverkeer. U wijst NSG's rechtstreeks toe aan subnetten.

Vereist netwerkbeveiligingsgroepverkeer

De netwerkbeveiligingsgroep (NSG) die is gekoppeld aan de knooppuntgroep en VNet-integratiesubnetten moeten het volgende verkeer toestaan:

Met deze verbindingen kunnen werkknooppunten de gehoste kube-apiserver en het gehoste besturingsvlak bereiken. Als een NSG-Deny-regel het vereiste verkeer blokkeert, kunt u geen nodepools maken.

Als u een regel voor weigeren wilt herstellen die een vereiste stroom blokkeert, voert u een van de volgende acties uit:

• Verwijder de regel Weigeren.
• Verfijn de regel Weigeren zodat deze niet overeenkomt met de vereiste bron, bestemming en poorten.
• Voeg een regel toestaan toe die overeenkomt met de vereiste bron, bestemming en poorten en heeft een hogere prioriteit dan de regel Weigeren. In een NSG heeft een lagere numerieke prioriteit een hogere prioriteit.

Azure Red Hat OpenShift met gehoste besturingsvlakken evalueert TCP-regels en jokertekenregels die de vereiste poorten bevatten. Regels voor weigeren voor niet-gerelateerde poorten, UDP-verkeer of niet-gerelateerde bestemmingen hebben geen invloed op deze validatie. Deze regels kunnen echter nog steeds ander verkeer blokkeren.

CIDR-vereisten

In de volgende tabel worden de vereisten voor het virtuele netwerk en CIDR beschreven:

Gebruik de standaardwaarden, tenzij ze niet voldoen aan uw vereisten. Als u een van deze waarden wilt wijzigen, volgt u deze richtlijnen:

• De pod-, service- en machine-CIDR's mogen niet met elkaar overlappen.
• De pod- en service-CIDR’s mogen niet overlappen met adresbereiken die in gebruik zijn op uw netwerk of met externe services die vanuit het cluster worden benaderd.
• De machine-CIDR moet alle subnetten van het virtuele netwerk omvatten die door het cluster worden gebruikt, inclusief het werkersubnet, eventuele extra subnetten van knooppuntgroepen en het subnet voor VNet-integratie. Als u in de toekomst knooppuntgroepen met afzonderlijke subnetten wilt toevoegen, moet u ervoor zorgen dat de CIDR van de machine groot genoeg is om ze op te nemen. Als uw VNet bijvoorbeeld gebruikmaakt van 10.0.0.0/16, omvat de standaard-CIDR voor machines van 10.0.0.0/16 alle subnetten.
• Het podnetwerk maakt gebruik van niet-routable IP-adressen en wordt alleen gebruikt in het softwaregedefinieerde netwerk van het cluster.

Privéclusterconnectiviteit

Als u kiest voor een privé-API-server, een privé-standaard-ingress of beide, moet u een private netwerkverbinding tot stand brengen tussen de netwerken van uw gebruikers en het virtuele netwerk van het cluster voordat u het cluster uitrolt. Zonder deze connectiviteit kunnen beheerders, CI/CD-pijplijnen en eindgebruikers de privé-eindpunten niet bereiken.

Algemene connectiviteitsopties zijn:

• Azure VNet-peering: verbind twee Azure virtuele netwerken, zodat resources in elk netwerk met elkaar kunnen communiceren.
• Azure VPN-gateway : verbind uw on-premises netwerk met het virtuele netwerk van het cluster via een site-naar-site-VPN-tunnel.
• Azure ExpressRoute: maak een persoonlijke, toegewezen verbinding vanaf uw on-premises netwerk om te Azure via een connectiviteitsprovider.

Zorg er bij het plannen van privénetwerkconnectiviteit voor dat de IP-adresbereiken van de gepeerde of verbonden netwerken niet overlappen met de machine-, pod- of service-CIDR-bereiken van het cluster.

Volgende stappen