Nätverkstopologi och anslutningsöverväganden för Azure Red Hat OpenShift

Granska designöverväganden och rekommendationer för nätverkstopologi och anslutning när du använder Acceleratorn Azure Red Hat OpenShift-landningszon.

Utformningsbeaktanden

• Azure Red Hat OpenShift kräver ett primärt undernät och ett sekundärt undernät.

  • Använd det primära undernätet för att distribuera klustrets huvudnoder.
  • Använd det sekundära undernätet för att distribuera klustrets arbetsnoder.
  • Det sekundära undernätet och det primära undernätet bör båda vara en minsta /27 väg.
  • Du kan inte ändra det sekundära undernätet eller det primära undernätet när du har distribuerat klustret.
  • Det primära undernätet och det sekundära undernätet kan inte ha en nätverkssäkerhetsgrupp associerad med dem. Azure Red Hat OpenShift-klustret skapar och hanterar automatiskt en nätverkssäkerhetsgrupp.
  • Det sekundära undernätet och det primära undernätet kan inte överlappa med lokala nätverk eller med något annat nätverk i Azure.

• Planera noggrant IP-adresser och storleken på det virtuella nätverksundernätet för att stödja skalning av klustret. Du kan behöva lägga till noder.

• Du kan exponera Azure Red Hat OpenShift-tjänster och vägar med hjälp av offentliga eller interna lastbalanserare. Konfigurera interna lastbalanserare i samma undernät som de sekundära noderna. I ett begränsat utgående kluster kan du inte använda offentliga lastbalanserare på grund av asymmetrisk routning.

• Azure Red Hat OpenShift använder CoreDNS för att ge namnmatchning till poddar som körs i klustret.

  • CoreDNS löser direkt klusterinterna domäner.
  • Azure Red Hat OpenShift stöder även anpassade DNS-servrar i det virtuella nätverket.
  • Andra domäner vidarebefordras till de DNS-servrar som du konfigurerar i Azure Virtual Network. DNS-servrarna är antingen azure DNS-standardlösaren eller alla anpassade DNS-servrar som du konfigurerar på den virtuella nätverksnivån.
  • Du kan anpassa DNS-vidarebefordran i Azure Red Hat OpenShift CoreDNS.
  • Om inga anpassade DNS-servrar har konfigurerats i det virtuella nätverket använder Azure Red Hat OpenShift standardlösningen för Azure DNS.

  Mer information om DNS finns i DNS-konfiguration för privata slutpunkter i Azure.

• Du kan skicka utgående nätverkstrafik (utgående) via Azure Firewall eller via ett kluster för virtuell nätverksinstallation.

  • Som standard har Azure Red Hat OpenShift-kluster obegränsad utgående internetåtkomst.
  • Du kan distribuera Azure Red Hat OpenShift med begränsad utgående trafik genom att lägga till en användardefinierad väg (UDR) som har en 0.0.0.0/0 väg till Azure Firewall eller till en virtuell nätverksinstallation. Azure Red Hat OpenShift har en utgående låsningsfunktion som garanterar åtkomst, även om den utgående trafiken begränsas av en brandväggsinstallation eller på annat sätt.
  • Du kan välja mellan två Azure Red Hat OpenShift-distributionsmodeller:
    • Privat API-serverslutpunkt och privat ingresskontrollant
    • Offentlig API-serverslutpunkt och offentlig ingresskontrollant
  • Om du använder obegränsad utgående åtkomst måste du noggrant hantera utgående portar för att vara säker på att du inte använder alla tillgängliga utgående portar. Mer information finns i Använda SNAT (Source Network Address Translation) för utgående anslutningar.

• Som standard kan alla poddar i ett Azure Red Hat OpenShift-kluster skicka och ta emot trafik utan begränsningar. Alla poddar i ett projekt är tillgängliga från andra poddar och nätverksslutpunkter. Om du vill isolera en eller flera poddar i ett projekt kan du skapa NetworkPolicy objekt i projektet för att ange tillåtna inkommande anslutningar. Red Hat OpenShift programvarudefinierade nätverk (SDN) stöder användning av nätverksprincip i standardläget för nätverksisolering.

• Ett servicenät innehåller funktioner som trafikhantering, återhämtning, princip, säkerhet, stark identitet och observerbarhet. Mer information om Red Hat OpenShift Service Mesh finns i Service Mesh- och Istio-skillnader.

• Globala belastningsutjämningsmekanismer som Azure Traffic Manager och Azure Front Door ökar motståndskraften genom att dirigera trafik över flera kluster, eventuellt i olika Azure-regioner.

Privata kluster

En IP-adress för Azure Red Hat OpenShift API-klustret kan vara antingen offentlig eller privat. Privata kluster exponerar Azure Red Hat OpenShift-API:et över en privat IP-adress men inte över en offentlig. Azure Red Hat OpenShift-API:et ska inte nås via dess IP-adress. I stället får du åtkomst till Azure Red Hat OpenShift-API:et via dess fullständigt kvalificerade domännamn (FQDN). Azure DNS löser Azure Red Hat OpenShift API FQDN till dess IP-adress.

I enlighet med beprövade metoder i Azure-landningszonen erbjuds DNS-matchning för Azure-arbetsbelastningar av centraliserade DNS-servrar som distribueras i anslutningsprenumerationen. Azure DNS-servrar finns antingen i ett virtuellt navnätverk eller i ett virtuellt nätverk för delade tjänster som är anslutet till en instans av Azure Virtual WAN. DNS-servrarna löser villkorligt Azure-specifika och offentliga namn med hjälp av Azure DNS (IP-adress 168.63.129.16). Servrarna löser privata namn med hjälp av företagets DNS-servrar. Den här anslutningsmodellen är vanlig och det är viktigt att tillåta privat åtkomst till andra Azure-resurser om du använder privata slutpunkter.

Trafik från programanvändare till klustret

Använd inkommande styrenheter för att exponera program som körs i Azure Red Hat OpenShift-kluster.

• Ingresskontrollanter tillhandahåller routning på programnivå med bara en liten ökning av komplexiteten.
• Azure Red Hat OpenShift skapar en allmän DNS-post som förenklar åtkomsten till exponerade program i klustret. Ett exempel på DNS-post är *.apps.<cluster-ID>.<region>.aroapp.io. Det är användbart för ett privat kluster att dirigera trafik för programmet.
• Azure Red Hat OpenShift erbjuder en inbyggd ingresskontrollant och vägar.
• Du kan använda Azure Red Hat OpenShift-ingress med Azure Front Door.
• Justera konfigurationen med utgående filtreringsdesign för att undvika asymmetrisk routning. UDR:er kan potentiellt orsaka asymmetrisk routning.
• Om ditt scenario kräver TLS-avslutning bör du överväga hur du ska hantera TLS-certifikat.

Viktigt!

Om du använder Azure Firewall för att begränsa utgående trafik och skapa en UDR för att tvinga all utgående trafik ska du se till att du skapar en lämplig DNAT-regel (Destination Network Address Translation) i Azure Firewall för att tillåta inkommande trafik korrekt. Användning av Azure Firewall med en UDR bryter ingresskonfigurationen på grund av asymmetrisk routning. Problemet uppstår om Azure Red Hat OpenShift-undernätet har en standardväg som går till brandväggens privata IP-adress, men du använder en offentlig lastbalanserare (ingress eller Kubernetes-tjänst av typen Load Balancer). I det här fallet tas den inkommande lastbalanserarens trafik emot via dess offentliga IP-adress, men retursökvägen går igenom brandväggens privata IP-adress. Eftersom brandväggen är tillståndskänslig släpper den det returnerade paketet eftersom brandväggen inte identifierar en etablerad session. Information om hur du integrerar Azure Firewall med din ingress- eller tjänstlastbalanserare finns i Integrera Azure Firewall med Azure Standard Load Balancer.

Följande steg beskriver flödet om du använder Azure Front Door med ett privat Azure Red Hat OpenShift-kluster och ingresskontrollant:

1. Klienter från det offentliga Internet löser DNS-namnet för programmet som pekar på Azure Front Door.
2. Azure Front Door använder Azure Private Link-tjänsten för att komma åt den privata IP-adressen för den interna Azure-nätverkslastbalanseraren och få åtkomst till ett program i Azure Red Hat OpenShift-ingressstyrenheten.

De här stegen beskriver flödet för ett icke-webbprogram som har åtkomst till ett privat Azure Red Hat OpenShift-kluster:

1. Klienter från det offentliga Internet löser DNS-namnet för programmet som pekar på den offentliga IP-adressen för Azure Firewall eller en virtuell nätverksinstallation.
2. Azure Firewall eller den virtuella nätverksinstallationen vidarebefordrar trafiken (DNAT) till det privata Azure Red Hat OpenShift-klustret med hjälp av den privata IP-adressen för den interna Azure-nätverkslastbalanseraren för att få åtkomst till programmet i Azure Red Hat OpenShift-ingressstyrenheten.

Trafik från Azure Red Hat OpenShift-poddar till serverdelstjänster

Poddarna som körs i Azure Red Hat OpenShift-klustret kan behöva komma åt serverdelstjänster som Azure Storage, Azure Key Vault, Azure SQL Database och Azure Cosmos DB. Du kan använda tjänstslutpunkter för virtuellt nätverk och Azure Private Link för att skydda anslutningen till dessa Azure-hanterade tjänster.

Om du använder privata Azure-slutpunkter för serverdelstrafik kan du använda Privata DNS-zoner i Azure för DNS-matchning för Azure-tjänsterna. Eftersom DNS-matcharna för hela miljön finns i det virtuella hubbnätverket (eller i det virtuella nätverket för delade tjänster, om du använder Virtual WAN-anslutningsmodellen) skapar du dessa privata zoner i anslutningsprenumerationen. Om du vill skapa den A-post som krävs för att matcha FQDN för den privata tjänsten kan du associera den privata DNS-zonen i anslutningsprenumerationen med den privata slutpunkten i programprenumerationen. Den här åtgärden kräver specifika behörigheter i dessa prenumerationer.

Du kan skapa A-posterna manuellt, men om du kopplar den privata DNS-zonen till den privata slutpunkten resulterar det i en konfiguration som är mindre benägen att felkonfigureras.

Serverdelsanslutning från Azure Red Hat OpenShift-poddar till PaaS-tjänster (Plattform som en tjänst) som exponeras via privata slutpunkter följer den här sekvensen:

1. Azure Red Hat OpenShift-poddarna löser FQDN för Azure PaaS med hjälp av de centrala DNS-servrarna i anslutningsprenumerationen, som definieras som anpassade DNS-servrar i det virtuella Azure Red Hat OpenShift-nätverket.
2. Den lösta IP-adressen är den privata IP-adressen för de privata slutpunkterna, som nås direkt från Azure Red Hat OpenShift-poddarna.

Trafik mellan Azure Red Hat OpenShift-poddarna och de privata slutpunkterna går som standard inte via Azure Firewall-instansen i det virtuella hubbnätverket (eller den säkra virtuella hubben, om du använder ett virtuellt WAN), även om Azure Red Hat OpenShift-klustret har konfigurerats för utgående filtrering med Azure Firewall. Den privata slutpunkten skapar en /32 väg i undernäten för det virtuella programnätverket där Azure Red Hat OpenShift distribueras.

Designrekommendationer

• Om din säkerhetsprincip kräver att du använder en privat IP-adress för Azure Red Hat OpenShift-API:et distribuerar du ett privat Azure Red Hat OpenShift-kluster.
• Använd Azure DDoS Protection för att skydda det virtuella nätverk som du använder för Azure Red Hat OpenShift-klustret om du inte använder Azure Firewall eller Web Application Firewall i en centraliserad prenumeration.
• Använd DNS-konfigurationen som är länkad till den övergripande nätverkskonfigurationen med Azure Virtual WAN eller en hubb- och ekerarkitektur, Azure DNS-zoner och din egen DNS-infrastruktur.
• Använd Azure Private Link för att skydda nätverksanslutningar och använda privata IP-baserade anslutningar till andra hanterade Azure-tjänster som stöder Private Link, till exempel Azure Storage, Azure Container Registry, Azure SQL Database och Azure Key Vault.
• Använd en ingresskontrollant för att tillhandahålla avancerad HTTP-routning och säkerhet och för att erbjuda en enda slutpunkt för program.
• Alla webbprogram som du konfigurerar för att använda en ingress bör använda TLS-kryptering och bör inte tillåta åtkomst via okrypterad HTTP.
• Använd Azure Front Door med Brandvägg för webbprogram för att publicera Azure Red Hat OpenShift-program på ett säkert sätt på Internet.
• Om din säkerhetsprincip kräver att du inspekterar all utgående Internettrafik som genereras i Azure Red Hat OpenShift-klustret kan du skydda utgående nätverkstrafik med hjälp av Azure Firewall eller en virtuell nätverksinstallation från tredje part som distribueras i det hanterade virtuella hubbens virtuella nätverk. Mer information finns i Kontrollera utgående trafik till ett Azure Red Hat OpenShift-kluster.
• Använd Azure Load Balancer Standard-nivån i stället för Basic-nivån för icke-webbprogram.

Nästa steg

• Planera din resursorganisation för Azure Red Hat OpenShift.