Überlegungen zur Netzwerktopologie und Konnektivität für Azure Red Hat OpenShift

Sehen Sie sich die Überlegungen und Empfehlungen zum Entwurf für die Netzwerktopologie und Konnektivität bei der Verwendung des Azure Red Hat OpenShift-Zielzonenbeschleunigers an.

Überlegungen zum Entwurf

• Azure Red Hat OpenShift erfordert ein primäres Subnetz und ein sekundäres Subnetz.

  • Verwenden Sie das primäre Subnetz, um die Masterknoten des Clusters bereitzustellen.
  • Verwenden Sie das sekundäre Subnetz, um die Arbeitsknoten des Clusters bereitzustellen.
  • Sowohl beim sekundären als auch beim primären Subnetz sollte es sich um eine minimale /27-Route handeln.
  • Sie können das sekundäre oder primäre Subnetz nach der Bereitstellung des Clusters nicht ändern.
  • Dem primären Subnetz und sekundären Subnetz kann keine Netzwerksicherheitsgruppe zugeordnet sein. Der Azure Red Hat OpenShift-Cluster erstellt automatisch eine Netzwerksicherheitsgruppe und verwaltet diese.
  • Das sekundäre Subnetz und das primäre Subnetz können sich nicht mit lokalen Netzwerken oder anderen Netzwerken in Azure überlappen.

• Planen Sie die IP-Adressen und die Größe des Subnetzes des virtuellen Netzwerks (VNet) sorgfältig, um eine Skalierung des Clusters zu unterstützen. Möglicherweise müssen Sie Knoten hinzufügen.

• Sie können Azure Red Hat OpenShift-Dienste und -Routen mithilfe von öffentlichen oder internen Lastenausgleichsmodulen verfügbar machen. Richten Sie interne Lastenausgleichsmodule im gleichen Subnetz wie die sekundären Knoten ein. In einem eingeschränkten Ausgangscluster (ausgehender Datenverkehr) können Sie aufgrund des asymmetrischen Routings keine öffentlichen Lastenausgleichsmodule verwenden.

• Azure Red Hat OpenShift verwendet CoreDNS für die Namensauflösung von Pods, die im Cluster ausgeführt werden.

  • CoreDNS löst clusterinterne Domänen direkt auf.
  • Azure Red Hat OpenShift unterstützt auch benutzerdefinierte Domänennamenserver (DNS-Server) im virtuellen Netzwerk.
  • Andere Domänen werden an die DNS-Server weitergeleitet, die Sie in Azure Virtual Network konfigurieren. Bei den DNS-Servern handelt es sich entweder um die standardmäßige Azure DNS-Auflösung oder um beliebige benutzerdefinierte DNS-Server, die Sie auf der Ebene des virtuellen Netzwerks konfigurieren.
  • Sie können die DNS-Weiterleitung in Azure Red Hat OpenShift CoreDNS anpassen.
  • Wenn keine benutzerdefinierten DNS-Server im virtuellen Netzwerk konfiguriert sind, verwendet Azure Red Hat OpenShift die standardmäßige Azure DNS-Auflösung.

  Weitere Informationen zu DNS finden Sie unter DNS-Konfiguration für private Azure-Endpunkte.

• Sie können ausgehenden Netzwerkdatenverkehr über Azure Firewall oder über einen Cluster virtueller Netzwerkgeräte senden.

  • Standardmäßig verfügen Azure Red Hat OpenShift-Cluster über uneingeschränkten ausgehenden Internetzugriff.
  • Sie können Azure Red Hat OpenShift mit eingeschränktem ausgehendem Datenverkehr bereitstellen, indem Sie eine benutzerdefinierte Route (User-Defined Route, UDR) hinzufügen, die über eine 0.0.0.0/0-Route zu Azure Firewall oder zu einem virtuellen Netzwerkgerät verfügt. Azure Red Hat OpenShift bietet einen Sperrmodus für ausgehende Daten, der den Zugriff auch dann gewährleistet, wenn der ausgehende Datenverkehr durch ein Firewallgerät oder auf andere Weise eingeschränkt wird.
  • Sie können zwischen zwei Azure Red Hat OpenShift-Bereitstellungsmodellen wählen:
    • Privater API-Serverendpunkt und privater Eingangsdatencontroller
    • Öffentlicher API-Serverendpunkt und öffentlicher Eingangsdatencontroller
  • Wenn Sie den uneingeschränkten ausgehenden Zugriff verwenden, müssen Sie ausgehende Ports sorgfältig verwalten, um sicherzustellen, dass nicht alle verfügbaren ausgehenden Ports verwendet werden. Weitere Informationen finden Sie unter Verwenden der Quell-Netzwerkadressenübersetzung (Source Network Address Translation, SNAT) für ausgehende Verbindungen.

• Standardmäßig können alle Pods in einem Azure Red Hat OpenShift-Cluster Datenverkehr ohne Einschränkungen senden und empfangen. Auf alle Pods in einem Projekt kann von anderen Pods und über Netzwerkendpunkte zugegriffen werden. Wenn Sie einen oder mehrere Pods in einem Projekt isolieren möchten, können Sie NetworkPolicy-Objekte im Projekt erstellen, um die zulässigen eingehenden Verbindungen anzugeben. Red Hat OpenShift-SDN (Software-Defined Networking) unterstützt die Verwendung von Netzwerkrichtlinien im Standard-Netzwerkisolationsmodus.

• Ein Dienstnetz verfügt über Funktionen für die Bereiche Datenverkehrsverwaltung, Resilienz, Richtlinie, Sicherheit, sichere Identität und Einblick. Weitere Informationen zu Red Hat OpenShift Service Mesh finden Sie unter Unterschiede zwischen Service Mesh und Istio.

• Globale Lastenausgleichsmechanismen wie Azure Traffic Manager und Azure Front Door erhöhen die Resilienz, indem sie den Datenverkehr über mehrere Cluster leiten, die sich möglicherweise in verschiedenen Azure-Regionen befinden.

Private Cluster

Eine Azure Red Hat OpenShift-API-Cluster-IP-Adresse kann öffentlich oder privat sein. Private Cluster machen die Azure Red Hat OpenShift-API über eine private IP-Adresse verfügbar, aber nicht über eine öffentliche IP-Adresse. Auf die Azure Red Hat OpenShift-API sollte nicht über ihre IP-Adresse zugegriffen werden. Greifen Sie stattdessen über den vollqualifizierten Domänennamen (Fully Qualified Domain Name, FQDN) auf die Azure Red Hat OpenShift-API zu. Azure DNS löst den FQDN der Azure Red Hat OpenShift-API in die IP-Adresse der API auf.

Im Einklang mit bewährten Praktiken für Azure-Zielzonen wird die DNS-Auflösung für Azure-Workloads von zentralisierten DNS-Servern angeboten, die im Konnektivitätsabonnement bereitgestellt werden. Azure DNS-Server befinden sich entweder in einem virtuellen Hubnetzwerk oder in einem virtuellen Netzwerk mit gemeinsam genutzten Diensten, das mit einer Azure Virtual WAN-Instanz verbunden ist. Die DNS-Server lösen Azure-spezifische und öffentliche Namen bedingt mithilfe von Azure DNS (IP-Adresse 168.63.129.16) auf. Die Server lösen private Namen mithilfe von DNS-Unternehmensservern auf. Dies ist ein gängiges Konnektivitätsmodell, und es ist wichtig, privaten Zugriff auf andere Azure-Ressourcen zuzulassen, wenn Sie private Endpunkte verwenden.

Datenverkehr von Anwendungsbenutzern zum Cluster

Verwenden Sie Eingangsdatencontroller, um Anwendungen verfügbar zu machen, die in den Azure Red Hat OpenShift-Clustern ausgeführt werden.

• Eingangsdatencontroller bieten Routing auf Anwendungsebene und erhöhen die Komplexität nur geringfügig.
• Azure Red Hat OpenShift erstellt einen generischen DNS-Eintrag, der den Zugriff auf verfügbar gemachte Anwendungen im Cluster vereinfacht. Ein Beispiel für einen DNS-Eintrag ist *.apps.<cluster-ID>.<region>.aroapp.io. Für einen privaten Cluster ist das Weiterleiten des Datenverkehrs für die Anwendung sinnvoll.
• Azure Red Hat OpenShift bietet einen integrierten Eingangsdatencontroller und Routen.
• Sie können den Azure Red Hat OpenShift-Eingangsdatencontroller mit Azure Front Door verwenden.
• Stimmen Sie Ihre Konfiguration mit dem Entwurf der Filterung von ausgehendem Datenverkehr ab, um asymmetrisches Routing zu vermeiden. UDRs können potenziell asymmetrisches Routing verursachen.
• Wenn Ihr Szenario einen TLS-Abschluss erfordert, sollten Sie überlegen, wie Sie TLS-Zertifikate verwalten.

Wichtig

Wenn Sie ausgehenden Datenverkehr mithilfe von Azure Firewall einschränken und eine UDR zum Erzwingen des gesamten ausgehenden Datenverkehrs erstellen, müssen Sie in Azure Firewall eine entsprechende Regel für die Ziel-Netzwerkadressenübersetzung (Destination Network Address Translation, DNAT) erstellen, um ausgehenden Datenverkehr zuzulassen. Durch die Verwendung von Azure Firewall mit einer UDR wird das Setup für eingehenden Datenverkehr aufgrund von asymmetrischem Routing unterbrochen. Das Problem tritt auf, wenn das Azure Red Hat OpenShift-Subnetz über eine Standardroute zur privaten IP-Adresse der Firewall verfügt, Sie aber einen öffentlichen Lastenausgleich verwenden (Eingangs- oder Kubernetes-Dienst vom Typ Load Balancer). In diesem Fall wird der eingehende Load Balancer-Datenverkehr über die öffentliche IP-Adresse empfangen, während der Rückpfad über die private IP-Adresse der Firewall verläuft. Die Firewall löscht das zurückgegebene Paket, weil sie zustandsbehaftet ist und keine vorhandene Sitzung erkennt. Informationen zur Integration von Azure Firewall in ihren Eingangs- oder Service Dienst-Load Balancer finden Sie unter Integrieren von Azure Firewall mit Azure Load Balancer Standard.

In den folgenden Schritten wird der Ablauf bei der Verwendung von Azure Front Door mit einem privaten Azure Red Hat OpenShift-Cluster und einem Eingangsdatencontroller beschrieben:

1. Clients aus dem öffentlichen Internet lösen den DNS-Namen für die Anwendung auf, die auf Azure Front Door verweist.
2. Azure Front Door verwendet den Azure Private Link-Dienst, um auf die private IP-Adresse des Azure-internen Netzwerklastenausgleichs und eine Anwendung im Azure Red Hat OpenShift-Eingangsdatencontroller zuzugreifen.

In diesen Schritten wird der Ablauf für eine nicht webbasierte Anwendung beschrieben, die auf einen privaten Azure Red Hat OpenShift-Cluster zugreift:

1. Clients aus dem öffentlichen Internet lösen den DNS-Namen für die Anwendung auf, die auf die öffentliche IP-Adresse von Azure Firewall oder eines virtuellen Netzwerkgeräts verweist.
2. Azure Firewall oder das virtuelle Netzwerkgerät leiten den Datenverkehr (DNAT) an den privaten Azure Red Hat OpenShift-Cluster weiter, indem sie mit der privaten IP-Adresse des Azure-internen Netzwerklastenausgleichs auf die Anwendung im Azure Red Hat OpenShift-Eingangsdatencontroller zugreifen.

Datenverkehr von den Azure Red Hat OpenShift-Pods an Back-End-Dienste

Die Pods, die im Azure Red Hat OpenShift-Cluster ausgeführt werden, müssen möglicherweise auf Back-End-Dienste wie Azure Storage, Azure Key Vault, Azure SQL-Datenbank und Azure Cosmos DB zugreifen. Sie können VNet-Dienstendpunkte und Azure Private Link verwenden, um die Konnektivität mit diesen verwalteten Azure-Diensten zu sichern.

Wenn Sie private Azure-Endpunkte für den Back-End-Datenverkehr nutzen, können Sie für die DNS-Auflösung für die Azure-Dienste private Azure-DNS-Zonen verwenden. Da sich die DNS-Auflösungen für die gesamte Umgebung im virtuellen Hubnetzwerk befinden (oder im virtuellen Netzwerk mit gemeinsam genutzten Diensten, wenn Sie das Virtual WAN-Konnektivitätsmodell verwenden), erstellen Sie diese privaten Zonen im Konnektivitätsabonnement. Zum Erstellen des A-Eintrags, der zur Auflösung des FQDN des privaten Diensts erforderlich ist, können Sie die private DNS-Zone im Konnektivitätsabonnement dem privaten Endpunkt im Anwendungsabonnement zuordnen. Dieser Vorgang erfordert bestimmte Berechtigungen in diesen Abonnements.

Sie können die A-Einträge manuell erstellen, die Zuordnung der privaten DNS-Zone zum privaten Endpunkt führt jedoch zu einem Setup, das weniger anfällig für Fehlkonfigurationen ist.

Die Back-End-Konnektivität von Azure Red Hat OpenShift-Pods mit Azure-PaaS-Diensten (Platform as a Service), die über private Endpunkte verfügbar gemacht werden, folgt diesem Ablauf:

1. Die Azure Red Hat OpenShift-Pods lösen den FQDN der Azure-PaaS-Dienste mithilfe der zentralen DNS-Server im Konnektivitätsabonnement auf, die als benutzerdefinierte DNS-Server im virtuellen Azure Red Hat OpenShift-Netzwerk definiert sind.
2. Die aufgelöste IP-Adresse ist die private IP-Adresse der privaten Endpunkte, auf die die Azure Red Hat OpenShift-Pods direkt zugreifen.

Datenverkehr zwischen den Azure Red Hat OpenShift-Pods und den privaten Endpunkten wird standardmäßig nicht über die Azure Firewall-Instanz im virtuellen Hubnetzwerk (oder den sicheren virtuellen Hub, wenn Sie Virtual WAN verwenden) geleitet, auch wenn der Azure Red Hat OpenShift-Cluster für die Filterung von ausgehendem Datenverkehr mit Azure Firewall konfiguriert ist. Der private Endpunkt erstellt eine /32-Route in den Subnetzen des virtuellen Anwendungsnetzwerks, in dem Azure Red Hat OpenShift bereitgestellt wird.

Entwurfsempfehlungen

• Wenn Ihre Sicherheitsrichtlinie erfordert, dass Sie eine private IP-Adresse für die Azure Red Hat OpenShift-API verwenden, stellen Sie einen privaten Azure Red Hat OpenShift-Cluster bereit.
• Schützen Sie das für den Azure Red Hat OpenShift-Cluster verwendete virtuelle Netzwerk mit Azure DDoS Protection, es sei denn, Sie verwenden Azure Firewall oder Web Application Firewall in einem zentralisierten Abonnement.
• Verwenden Sie die DNS-Konfiguration, die mit der gesamten Netzwerkeinrichtung mit Azure Virtual WAN oder einer Hub-and-Spoke-Architektur, Azure DNS-Zonen und Ihrer eigenen DNS-Infrastruktur verknüpft ist.
• Sichern Sie Netzwerkverbindungen mit Azure Private Link, und verwenden Sie private IP-basierte Konnektivität mit anderen verwalteten Azure-Diensten, die Private Link unterstützen (z. B. Azure Storage, Azure Container Registry, Azure SQL-Datenbank und Azure Key Vault).
• Verwenden Sie einen Eingangsdatencontroller, um erweitertes HTTP-Routing und Sicherheit sowie einen einzelnen Endpunkt für Anwendungen bereitzustellen.
• Alle Webanwendungen, die Sie zur Verwendung eines Eingangsdatencontrollers konfigurieren, sollten die TLS-Verschlüsselung verwenden und keinen Zugriff über unverschlüsseltes HTTP zulassen.
• Verwenden Sie Azure Front Door mit Web Application Firewall, um Azure Red Hat OpenShift-Anwendungen sicher im Internet zu veröffentlichen.
• Wenn Ihre Sicherheitsrichtlinie die Überprüfung des gesamten vom Azure Red Hat OpenShift-Cluster ausgehenden Internetdatenverkehrs vorschreibt, schützen Sie den ausgehenden Netzwerkdatenverkehr mit Azure Firewall oder einem virtuellen Netzwerkgerät eines Drittanbieters, das im verwalteten virtuellen Hubnetzwerk bereitgestellt wird. Weitere Informationen finden Sie unter Steuern des ausgehenden Datenverkehrs an einen Azure Red Hat OpenShift-Cluster.
• Verwenden Sie für nicht webbasierte Anwendungen den Tarif Azure Load Balancer Standard anstelle des Basic-Tarifs.

Nächste Schritte

• Planen Sie Ihre Ressourcenorganisation für Azure Red Hat OpenShift.