Netzwerkkonzepte für Azure Red Hat OpenShift

Dieser Leitfaden enthält eine Übersicht über Netzwerke in Azure Red Hat OpenShift in OpenShift 4-Clustern sowie ein Diagramm und eine Liste wichtiger Endpunkte. Weitere Informationen zu wichtigen OpenShift-Netzwerkkonzepten finden Sie in der Netzwerkdokumentation für Azure Red Hat OpenShift 4.

Wenn Sie Azure Red Hat OpenShift in OpenShift 4 bereitstellen, befindet sich Ihr gesamter Cluster in einem virtuellen Netzwerk. Innerhalb dieses virtuellen Netzwerks befinden sich Ihre Steuerungsebenen- und Workerknoten jeweils in einem eigenen Subnetz. Von den Subnetzen wird jeweils ein interner und ein öffentlicher Lastenausgleich verwendet.

Hinweis

Informationen zu den neuesten Änderungen in ARO finden Sie unter Neuerungen in Azure Red Hat OpenShift.

Netzwerkkomponenten

Die folgende Liste enthält wichtige Netzwerkkomponenten in einem Azure Red Hat OpenShift-Cluster:

• aro-pls

  • Hierbei handelt es sich um einen Azure Private Link-Endpunkt, der von Site Reliability Engineers bei Microsoft und Red Hat genutzt wird, um den Cluster zu verwalten.

• aro-internal

  • Dieser Endpunkt gleicht den Datenverkehr an den API-Server und den internen Dienstdatenverkehr aus. Knoten auf Steuerungsebene und Workerknoten befinden sich im Back-End-Pool.
  • Dieser Lastenausgleich wird nicht standardmäßig erstellt. Er wird erstellt, wenn Sie einen Dienst vom Typ „LoadBalancer“ mit den korrekten Anmerkungen erstellen. Beispiel: service.beta.kubernetes.io/azure-load-balancer-internal: "true".

• aro

  • Dieser Endpunkt wird für öffentlichen Datenverkehr verwendet. Wenn Sie eine Anwendung und eine Route erstellen, ist dieser Endpunkt der Pfad für eingehenden Datenverkehr.
  • Wenn die API öffentlich ist, wird Datenverkehr durch diesen Endpunkt an den API-Server weitergeleitet und ausgeglichen. Von diesem Endpunkt wird eine öffentliche ausgehende IP-Adresse zugewiesen, damit Knoten der Steuerungsebene auf Azure Resource Manager zugreifen und Informationen zur Clusterintegrität zurückgeben können.
  • Dieser Lastenausgleich deckt auch ausgehende Internetkonnektivität beliebiger Pods ab, die in den Workerknoten ausgeführt werden (über Azure Load Balancer-Ausgangsregeln).
    • Ausgangsregeln können aktuell nicht konfiguriert werden. Durch sie werden jedem Knoten 1.024 TCP-Ports zugewiesen.
    • Da „DisableOutboundSnat“ in den LB-Regeln nicht konfiguriert ist, können Pods als IP-Adresse für ausgehenden Datenverkehr eine beliebige öffentliche IP-Adresse erhalten, die in dieser ALB-Instanz konfiguriert ist.
    • Aufgrund der beiden vorherigen Punkte müssen ARO öffentliche Dienste vom Typ „LoadBalancer“ hinzugefügt werden, wenn Sie kurzlebige SNAT-Ports hinzufügen möchten.

• aro-nsg

  • Wenn Sie einen Dienst verfügbar machen, wird von der API eine Regel in dieser Netzwerksicherheitsgruppe erstellt, damit der Datenverkehr weitergeleitet wird und die Steuerungsebene sowie die Knoten über Port 6443 erreichen kann.
  • Durch diese Netzwerksicherheitsgruppe wird standardmäßig der gesamte ausgehende Datenverkehr zugelassen. Ausgehender Datenverkehr kann aktuell nur auf die Azure Red Hat OpenShift-Steuerungsebene beschränkt werden.

• Azure Container Registry

  • Hierbei handelt es sich um eine von Microsoft intern bereitgestellte und verwendete Containerregistrierung. Sie ist schreibgeschützt und nicht für die Verwendung durch Azure Red Hat OpenShift-Benutzer*innen vorgesehen.
    • Durch diese Registrierung werden Hostplattformimages und Clusterkomponenten bereitgestellt. Beispiele wären etwa Container für die Überwachung oder Protokollierung.
    • Verbindungen mit dieser Registrierung werden über den Dienstendpunkt hergestellt (interne Konnektivität zwischen Azure-Diensten).
    • Diese interne Registrierung steht außerhalb des Clusters nicht zur Verfügung.

• Private Link

  • Eine Private Link-Instanz ermöglicht die Netzwerkkonnektivität von einer Verwaltungsebene zu einem Cluster. Diese wird von Site Reliability Engineers bei Microsoft und Red Hat verwendet, um die Clusterverwaltung zu vereinfachen.

Netzwerkrichtlinien

• Eingehender Datenverkehr: Die Netzwerkrichtlinie für eingehenden Datenverkehr wird im Rahmen von OpenShift SDN unterstützt. Diese Netzwerkrichtlinie ist standardmäßig aktiviert, und die Erzwingung wird von Benutzern durchgeführt. Die Netzwerkrichtlinie für eingehenden Datenverkehr ist zwar mit der V1-Netzwerkrichtlinie (V1 NetworkPolicy) kompatibel, die Typen „Egress“ (Ausgehend) und „IPBlock“ (IP-Block) werden jedoch noch nicht unterstützt.

• Ausgehender Datenverkehr: Die Netzwerkrichtlinien für ausgehenden Datenverkehr werden mithilfe der Firewall für ausgehenden Datenverkehr in OpenShift unterstützt. Pro Namespace bzw. Projekt gibt es jeweils nur eine einzelne Richtlinie für ausgehenden Datenverkehr. Richtlinien für ausgehenden Datenverkehr werden im „Standard“-Namespace nicht unterstützt und nacheinander (von der ersten bis zur letzten) ausgewertet.

Netzwerkgrundlagen in OpenShift

OpenShift Software Defined Networking (SDN) wird verwendet, um ein Overlaynetzwerk mithilfe von Open vSwitch (OVS) zu konfigurieren. Hierbei handelt es sich um eine OpenFlow-Implementierung, die auf der CNI-Spezifikation (Container Network Interface, Containernetzwerkschnittstelle) basiert. Das SDN unterstützt verschiedene Plug-Ins. „Network Policy“ ist das Plug-In, das in Azure Red Hat in OpenShift 4 verwendet wird. Da die gesamte Netzwerkkommunikation durch SDN verwaltet wird, sind für die Kommunikation zwischen Pods keine zusätzlichen Routen in Ihren virtuellen Netzwerken erforderlich.

Netzwerk für Azure Red Hat OpenShift

Bei den folgenden Punkten handelt es sich um spezifische Netzwerkfeatures für Azure Red Hat OpenShift:

• Benutzer*innen können ihr Azure Red Hat OpenShift-Cluster in einem vorhandenen virtuellen Netzwerk erstellen, oder bei der Erstellung des Clusters ein neues virtuelles Netzwerk erstellen.
• Pod- und Dienstnetzwerk-CIDRs sind konfigurierbar.
• Knoten und Steuerungsebenen befinden sich in unterschiedlichen Subnetzen.
• Die VNet-Subnetze der Knoten und Steuerungsebenen müssen eine Mindestgröße von /27 haben.
• Das klassenlose domänenübergreifende Standardrouting des Pods ist 10.128.0.0/14.
• Das klassenlose domänenübergreifende Standardrouting des Diensts ist 172.30.0.0/16.
• CIDRs von Pod- und Dienstnetzwerken sollten sich nicht mit anderen in Ihrem Netzwerk verwendeten Adressbereichen überlappen. Sie dürfen nicht innerhalb des IP-Adressbereichs des virtuellen Netzwerk Ihres Clusters liegen.
• Pod-CIDRs müssen eine Mindestgröße von /18 haben. (Beim Podnetzwerk handelt es sich um nicht routingfähige IP-Adressen, und es wird ausschließlich innerhalb von OpenShift SDN verwendet.)
• Jedem Knoten wird ein Subnetz vom Typ „/23“ (512 IP-Adressen) für die zugehörigen Pods zugewiesen. Dieser Wert kann nicht geändert werden.
• Ein Pod kann nicht an mehrere Netzwerke angefügt werden.
• Für private ARO-Cluster, die das OVN-Kubernetes Netzwerk-Plugin verwenden, können Sie Egress-IPs konfigurieren. Weitere Informationen finden Sie unter Konfigurieren einer IP-Adresse für ausgehenden Datenverkehr.

Netzwerkeinstellungen

Für Azure Red Hat OpenShift 4-Cluster stehen folgende Netzwerkeinstellungen zur Verfügung:

• API Visibility (API-Sichtbarkeit): Legen Sie die API-Sichtbarkeit beim Ausführen des Befehls az aro create fest.
  • „Public“ (Öffentlich): Auf den API-Server kann von externen Netzwerken zugegriffen werden.
  • „Private“ (Privat): Vom API-Server wurde eine private IP-Adresse aus dem Subnetz der Steuerungsebene zugewiesen, und der Zugriff ist nur über verbundene Netzwerke (über das Peering virtueller Netzwerke und andere Subnetze im Cluster) möglich.
• Ingress Visibility (Sichtbarkeit für eingehenden Datenverkehr): Legen Sie die API-Sichtbarkeit beim Ausführen des Befehls az aro create fest.
  • „Public“ (öffentlich) leitet standardmäßig an eine öffentliche Load Balancer Standard-Instanz weiter. (Die Standardeinstellung kann geändert werden.)
  • „Private“ leitet standardmäßig an einen internen Lastenausgleich weiter. (Die Standardeinstellung kann geändert werden.)

Netzwerksicherheitsgruppen

Netzwerksicherheitsgruppen werden in der (für Benutzer gesperrten) Ressourcengruppe des Knotens erstellt. Die Netzwerksicherheitsgruppen werden direkt den Subnetzen zugewiesen und nicht den NICs des Knotens. Die Netzwerksicherheitsgruppen sind unveränderlich. Benutzer*innen verfügen nicht über die Berechtigungen, sie zu ändern.

Mit einem öffentlich sichtbaren API-Server können keine Netzwerksicherheitsgruppen erstellt und den NICs zugewiesen werden.

Domänenweiterleitung

Von Azure Red Hat OpenShift wird CoreDNS verwendet. Die Domänenweiterleitung kann konfiguriert werden. In Ihren virtuellen Netzwerken kann kein eigenes DNS verwendet werden. Weitere Informationen finden Sie in der Dokumentation zur Verwendung der DNS-Weiterleitung.

Nächste Schritte

Weitere Informationen zu ausgehendem Datenverkehr und zur Unterstützung von Azure Red Hat OpenShift in diesem Zusammenhang finden Sie unter Unterstützungsrichtlinien in Azure Red Hat OpenShift.