Overwegingen voor netwerktopologie en connectiviteit voor Azure Red Hat OpenShift

Bekijk ontwerpoverwegingen en aanbevelingen voor netwerktopologie en -connectiviteit wanneer u de Azure Red Hat OpenShift-landingszoneversneller gebruikt.

Ontwerpoverwegingen

• Azure Red Hat OpenShift vereist een primair subnet en secundair subnet.

  • Gebruik het primaire subnet om de hoofdknooppunten van het cluster te implementeren.
  • Gebruik het secundaire subnet om de werkknooppunten van het cluster te implementeren.
  • Het secundaire subnet en het primaire subnet moeten beide een minimale /27 route zijn.
  • U kunt het secundaire subnet of het primaire subnet niet wijzigen nadat u het cluster hebt geïmplementeerd.
  • Aan het primaire subnet en het secundaire subnet kan geen netwerkbeveiligingsgroep zijn gekoppeld. Het Azure Red Hat OpenShift-cluster maakt en beheert automatisch een netwerkbeveiligingsgroep.
  • Het secundaire subnet en het primaire subnet kunnen niet overlappen met on-premises netwerken of met een ander netwerk in Azure.

• Plan zorgvuldig IP-adressen en de grootte van het subnet van het virtuele netwerk om het cluster te schalen. Mogelijk moet u knooppunten toevoegen.

• U kunt Azure Red Hat OpenShift-services en -routes beschikbaar maken met behulp van openbare of interne load balancers. Stel interne load balancers in hetzelfde subnet in als de secundaire knooppunten. In een beperkt uitgaand cluster kunt u geen openbare load balancers gebruiken vanwege asymmetrische routering.

• Azure Red Hat OpenShift maakt gebruik van CoreDNS om naamomzetting te bieden aan pods die in het cluster worden uitgevoerd.

  • CoreDNS lost cluster-interne domeinen rechtstreeks op.
  • Azure Red Hat OpenShift ondersteunt ook aangepaste DNS-servers in het virtuele netwerk.
  • Andere domeinen worden doorgestuurd naar de DNS-servers die u configureert in Azure Virtual Network. De DNS-servers zijn de standaard Azure DNS-resolver of aangepaste DNS-servers die u configureert op het niveau van het virtuele netwerk.
  • U kunt DNS-doorsturen aanpassen in Azure Red Hat OpenShift CoreDNS.
  • Als er geen aangepaste DNS-servers zijn geconfigureerd in het virtuele netwerk, gebruikt Azure Red Hat OpenShift de standaard-Azure DNS-resolver.

  Zie DNS-configuratie voor privé-eindpunten in Azure voor meer informatie over DNS.

• U kunt uitgaand (uitgaand) netwerkverkeer verzenden via Azure Firewall of via een virtueel netwerkapparaatcluster.

  • Azure Red Hat OpenShift-clusters hebben standaard onbeperkte internettoegang via uitgaand verkeer.
  • U kunt Azure Red Hat OpenShift implementeren met beperkt uitgaand verkeer door een door de gebruiker gedefinieerde route (UDR) toe te voegen die een 0.0.0.0/0 route naar Azure Firewall of een virtueel netwerkapparaat heeft. Azure Red Hat OpenShift heeft een vergrendelingsfunctie voor uitgaand verkeer dat toegang garandeert, zelfs als het uitgaande verkeer wordt beperkt door een firewallapparaat of op een andere wijze.
  • U kunt kiezen uit twee Azure Red Hat OpenShift-implementatiemodellen:
    • Privé-API-servereindpunt en privé-ingangscontroller
    • Eindpunt van openbare API-server en openbare ingangscontroller
  • Als u onbeperkte uitgaande toegang gebruikt, moet u uitgaande poorten zorgvuldig beheren om ervoor te zorgen dat u niet alle beschikbare uitgaande poorten gebruikt. Zie Source Network Address Translation (SNAT) gebruiken voor uitgaande verbindingen voor meer informatie.

• Standaard kunnen alle pods in een Azure Red Hat OpenShift-cluster zonder beperkingen verkeer verzenden en ontvangen. Alle pods in een project zijn toegankelijk vanaf andere pods en netwerkeindpunten. Als u een of meer pods in een project wilt isoleren, kunt u objecten in het project maken NetworkPolicy om de toegestane binnenkomende verbindingen aan te geven. Red Hat OpenShift softwaregedefinieerde netwerken (SDN) ondersteunt het gebruik van netwerkbeleid in de standaardmodus voor netwerkisolatie.

• Een service-mesh biedt mogelijkheden zoals verkeerbeheer, tolerantie, beleid, beveiliging, sterke identiteit en waarneembaarheid. Zie De verschillen tussen Service Mesh en Istio voor meer informatie over Red Hat OpenShift Service Mesh.

• Wereldwijde mechanismen voor taakverdeling, zoals Azure Traffic Manager en Azure Front Door , vergroten de tolerantie door verkeer over meerdere clusters te routeren, mogelijk in verschillende Azure-regio's.

Privéclusters

Een IP-adres van een Azure Red Hat OpenShift API-cluster kan openbaar of privé zijn. Privéclusters maken de Azure Red Hat OpenShift-API beschikbaar via een privé-IP-adres, maar niet via een openbaar IP-adres. De Azure Red Hat OpenShift-API mag niet worden geopend via het IP-adres. In plaats daarvan opent u de Azure Red Hat OpenShift-API via de FQDN (Fully Qualified Domain Name). Azure DNS zet de FQDN van de Azure Red Hat OpenShift API om in het IP-adres.

In overeenstemming met bewezen bewezen procedures voor azure-landingszones wordt DNS-omzetting voor Azure-workloads aangeboden door gecentraliseerde DNS-servers die zijn geïmplementeerd in het connectiviteitsabonnement. Azure DNS-servers bevinden zich in een virtueel hubnetwerk of in een virtueel netwerk van gedeelde services dat is verbonden met een exemplaar van Azure Virtual WAN. De DNS-servers zetten azure-specifieke en openbare namen voorwaardelijk om met behulp van Azure DNS (IP-adres 168.63.129.16). De servers omzetten privénamen met behulp van bedrijfs-DNS-servers. Dit connectiviteitsmodel is gebruikelijk en het is belangrijk dat u privétoegang tot andere Azure-resources toestaat als u privé-eindpunten gebruikt.

Verkeer van toepassingsgebruikers naar het cluster

Gebruik binnenkomende controllers (inkomend verkeer) om toepassingen beschikbaar te maken die worden uitgevoerd in de Azure Red Hat OpenShift-clusters.

• Toegangsbeheerobjectcontrollers bieden routering op toepassingsniveau met slechts een lichte toename van complexiteit.
• Azure Red Hat OpenShift maakt een algemene DNS-vermelding die de toegang tot blootgestelde toepassingen in het cluster vereenvoudigt. Een voorbeeld van een DNS-vermelding is *.apps.<cluster-ID>.<region>.aroapp.io. Het is handig voor een privécluster om verkeer voor de toepassing te routeren.
• Azure Red Hat OpenShift biedt een ingebouwde controller en routes voor inkomend verkeer.
• U kunt Azure Red Hat OpenShift-toegangsbeheerobjecten gebruiken met Azure Front Door.
• Stem uw configuratie af met het ontwerp voor uitgaand filteren om asymmetrische routering te voorkomen. UDR's kunnen asymmetrische routering veroorzaken.
• Als voor uw scenario TLS-beëindiging is vereist, kunt u overwegen hoe u TLS-certificaten gaat beheren.

Belangrijk

Als u Azure Firewall gebruikt om uitgaand verkeer te beperken en een UDR te maken om al het uitgaande verkeer af te dwingen, moet u ervoor zorgen dat u een geschikte DNAT-regel (Destination Network Address Translation) in Azure Firewall maakt om inkomend verkeer correct toe te staan. Als u Azure Firewall met een UDR gebruikt, wordt de installatie van inkomend verkeer verbroken vanwege asymmetrische routering. Het probleem treedt op als het Azure Red Hat OpenShift-subnet een standaardroute heeft die naar het privé-IP-adres van de firewall gaat, maar u een openbare load balancer (inkomend verkeer of kubernetes-service van het type Load Balancer) gebruikt. In dit geval wordt het binnenkomende load balancer-verkeer ontvangen via het openbare IP-adres, maar het retourpad gaat via het privé-IP-adres van de firewall. Omdat de firewall stateful is, wordt het geretourneerde pakket verwijderd omdat de firewall geen tot stand gebrachte sessie detecteert. Zie Azure Firewall integreren met Azure Standard Load Balancer voor meer informatie over het integreren van Azure Firewall met uw inkomend verkeer of service load balancer.

In de volgende stappen wordt de stroom beschreven als u Azure Front Door gebruikt met een privécluster van Azure Red Hat OpenShift en een controller voor inkomend verkeer:

1. Clients van het openbare internet omgezet de DNS-naam voor de toepassing die verwijst naar Azure Front Door.
2. Azure Front Door maakt gebruik van de Azure Private Link-service om toegang te krijgen tot het privé-IP-adres van de load balancer van het interne Azure-netwerk en toegang te krijgen tot een toepassing in de Azure Red Hat OpenShift-controller voor inkomend verkeer.

In deze stappen wordt de stroom beschreven voor een niet-webtoepassing die toegang heeft tot een privécluster van Azure Red Hat OpenShift:

1. Clients van het openbare internet omgezet de DNS-naam voor de toepassing die verwijst naar het openbare IP-adres van Azure Firewall of een virtueel netwerkapparaat.
2. Azure Firewall of het virtuele netwerkapparaat stuurt het verkeer (DNAT) door naar het privécluster van Azure Red Hat OpenShift met behulp van het privé-IP-adres van de load balancer van het interne Azure-netwerk om toegang te krijgen tot de toepassing in de Azure Red Hat OpenShift-ingangscontroller.

Verkeer van de Azure Red Hat OpenShift-pods naar back-endservices

De pods die worden uitgevoerd in het Azure Red Hat OpenShift-cluster moeten mogelijk toegang hebben tot back-endservices zoals Azure Storage, Azure Key Vault, Azure SQL Database en Azure Cosmos DB. U kunt service-eindpunten voor virtuele netwerken en Azure Private Link gebruiken om de connectiviteit met deze door Azure beheerde services te beveiligen.

Als u privé-eindpunten van Azure gebruikt voor back-endverkeer, kunt u Azure Privé-DNS zones gebruiken voor DNS-omzetting voor de Azure-services. Omdat de DNS-resolvers voor de hele omgeving zich in het virtuele hubnetwerk bevinden (of in het virtuele netwerk van de gedeelde services, als u het Virtual WAN-connectiviteitsmodel gebruikt), maakt u deze privézones in het connectiviteitsabonnement. Als u de A-record wilt maken die nodig is om de FQDN van de privéservice om te zetten, kunt u de privé-DNS-zone in het connectiviteitsabonnement koppelen aan het privé-eindpunt in het toepassingsabonnement. Voor deze bewerking zijn specifieke machtigingen in deze abonnementen vereist.

U kunt de A-records handmatig maken, maar het koppelen van de privé-DNS-zone aan het privé-eindpunt resulteert in een installatie die minder gevoelig is voor onjuiste configuraties.

Back-endconnectiviteit van Azure Red Hat OpenShift-pods naar PaaS-services (Platform as a Service) die beschikbaar zijn via privé-eindpunten, volgen deze reeks:

1. De Azure Red Hat OpenShift-pods omzetten de FQDN van de Azure PaaS met behulp van de centrale DNS-servers in het connectiviteitsabonnement, die worden gedefinieerd als aangepaste DNS-servers in het virtuele Azure Red Hat OpenShift-netwerk.
2. Het opgeloste IP-adres is het privé-IP-adres van de privé-eindpunten, die rechtstreeks vanuit de Azure Red Hat OpenShift-pods worden geopend.

Verkeer tussen de Azure Red Hat OpenShift-pods en de privé-eindpunten gaat standaard niet via het Azure Firewall-exemplaar in het virtuele hubnetwerk (of de beveiligde virtuele hub, als u een virtual WAN gebruikt), zelfs niet als het Azure Red Hat OpenShift-cluster is geconfigureerd voor uitgaand filteren met Azure Firewall. Het privé-eindpunt maakt een /32 route in de subnetten van het virtuele toepassingsnetwerk waarin Azure Red Hat OpenShift is geïmplementeerd.

Ontwerpaanaanvelingen

• Als uw beveiligingsbeleid vereist dat u een privé-IP-adres gebruikt voor de Azure Red Hat OpenShift-API, implementeert u een privé-Azure Red Hat OpenShift-cluster.
• Gebruik Azure DDoS Protection om het virtuele netwerk dat u gebruikt voor het Azure Red Hat OpenShift-cluster te beveiligen, tenzij u Azure Firewall of Web Application Firewall in een gecentraliseerd abonnement gebruikt.
• Gebruik de DNS-configuratie die is gekoppeld aan de algehele netwerkinstallatie met Azure Virtual WAN of een hub- en spoke-architectuur, Azure DNS-zones en uw eigen DNS-infrastructuur.
• Gebruik Azure Private Link om netwerkverbindingen te beveiligen en gebruik privé-IP-verbindingen met andere beheerde Azure-services die ondersteuning bieden voor Private Link, zoals Azure Storage, Azure Container Registry, Azure SQL Database en Azure Key Vault.
• Gebruik een ingangscontroller om geavanceerde HTTP-routering en -beveiliging te bieden en om één eindpunt voor toepassingen te bieden.
• Alle webtoepassingen die u configureert voor het gebruik van inkomend verkeer, moeten TLS-versleuteling gebruiken en mogen geen toegang toestaan via niet-versleutelde HTTP.
• Gebruik Azure Front Door met Web Application Firewall om Azure Red Hat OpenShift-toepassingen veilig op internet te publiceren.
• Als uw beveiligingsbeleid vereist dat u al het uitgaande internetverkeer inspecteert dat wordt gegenereerd in het Azure Red Hat OpenShift-cluster, beveiligt u uitgaand netwerkverkeer met behulp van Azure Firewall of een virtueel netwerkapparaat van derden dat is geïmplementeerd in het virtuele netwerk van de beheerde hub. Zie Uitgaand verkeer beheren naar een Azure Red Hat OpenShift-cluster voor meer informatie.
• Gebruik de Standard-laag van Azure Load Balancer in plaats van de Basic-laag voor niet-webtoepassingen.

Volgende stappen

• Plan uw resourceorganisatie voor Azure Red Hat OpenShift.