Netzwerkkonzepte für Azure Red Hat OpenShift

Dieser Artikel bietet eine Übersicht über Azure Red Hat OpenShift Networking auf OpenShift 4-Clustern. Sie enthält 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 liegen Ihre Control-Plane-Knoten und Worker-Knoten jeweils in einem eigenen Subnetz. Jedes Subnetz verwendet einen internen und einen öffentlichen Load Balancer.

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

  • Der Clusterinstallationsprozess erstellt diesen internen Lastenausgleich. Er verteilt den Datenverkehr auf den API-Server im internen Netzwerk (api-int) und überträgt den internen Dienstdatenverkehr. Knoten auf Steuerungsebene und Workerknoten befinden sich im Back-End-Pool.
  • Der Cloudcontroller-Manager kann zusätzliche interne Front-End-IPs für den Lastenausgleich erstellen, wenn Sie einen Kubernetes-Dienst vom Typ LoadBalancer mit der Anmerkung service.beta.kubernetes.io/azure-load-balancer-internal: "true"erstellen. Diese IPs unterscheiden sich von der vom RP verwalteten internal-lb-ip-v4.

• Aro

  • Dieser Endpunkt wird für den gesamten öffentlichen Netzwerkverkehr 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. Diesem Endpunkt wird eine öffentliche ausgehende IP-Adresse zugewiesen, damit Steuerungsebenen auf Azure Resource Manager zugreifen und den Clusterstatus zurückmelden 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.
    • Als Folge der beiden vorherigen Punkte besteht die einzige Möglichkeit, ephemerale SNAT-Ports hinzuzufügen, indem öffentliche LoadBalancer-Typdienste zu Azure Red Hat OpenShift hinzugefügt werden.

• aro-nsg

  • Wenn Sie einen Dienst verfügbar machen, erstellt die API eine Regel in dieser Netzwerksicherheitsgruppe, damit der Datenverkehr hindurchfließen und über Port 6443 die Steuerungsebene sowie die Knoten erreichen kann.
  • Diese Netzwerksicherheitsgruppe lässt standardmäßig den gesamten ausgehenden Datenverkehr zu. Ausgehender Datenverkehr kann aktuell nur auf die Azure Red Hat OpenShift-Steuerungsebene beschränkt werden.

• Azure Container Registry

  • Die Containerregistrierung wird intern von Microsoft bereitgestellt und verwendet. Sie ist schreibgeschützt und nicht für die Verwendung durch Azure Red Hat OpenShift-Benutzer*innen vorgesehen.
    • Diese Registry stellt Host-Plattform-Images und Clusterkomponenten bereit. Beispiele wären etwa Container für die Überwachung oder Protokollierung.
    • Verbindungen zu dieser Registrierung erfolgen über einen privaten Endpunkt (interne Konnektivität zwischen Azure Diensten).
    • Standardmäßig ist diese interne Registry außerhalb des Clusters nicht verfügbar.

• Privater 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

• Ingress: Das OVN-Kubernetes Netzwerk-Plugin unterstützt Ingress-Netzwerkrichtlinien. Die Netzwerkrichtlinie ist standardmäßig aktiviert, und Benutzer erzwingen sie. Ingress-Netzwerkrichtlinien entsprechen der V1-NetworkPolicy.

• Egress: OpenShift unterstützt Egress-Netzwerkrichtlinien durch die Funktion Egress-Firewall. Jeder Namespace oder jedes Projekt kann nur eine Egress-Richtlinie haben. Der Namespace „default“ unterstützt keine Egress-Richtlinien. Das System wertet Egress-Richtlinien der Reihe nach aus, von der ersten bis zur letzten.

Netzwerkgrundlagen in OpenShift

Azure Red Hat OpenShift verwendet OVN-Kubernetes als Clusternetzwerk-Plug-In. OVN-Kubernetes stellt ein Überlagerungsnetzwerk mithilfe von Geneve-Tunneln bereit und implementiert die CNI-Spezifikation (Container Network Interface). OVN-Kubernetes verfügt über eine integrierte Erzwingung von Netzwerkrichtlinien. Das Overlay verwaltet die Pod-zu-Pod-Kommunikation, sodass Ihre virtuellen Netzwerke keine zusätzlichen Routen benötigen.

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.
• Der standardmäßige Pod-CIDR ist 10.128.0.0/14.
• Die Standard-Service-CIDR ist 172.30.0.0/16.
• Die CIDRs von Pod- und Service-Netzwerken sollten sich nicht mit anderen in Ihrem Netzwerk verwendeten Adressbereichen überschneiden. Sie dürfen nicht innerhalb des IP-Adressbereichs des virtuellen Netzwerk Ihres Clusters liegen.
• Pod-CIDRs sollten mindestens die Größe /18 haben. (Das Pod-Netzwerk ist nicht routingfähige IPs und wird nur innerhalb des Clusterüberlagerungsnetzwerks 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 Cluster, die das OVN-Kubernetes Netzwerk-Plug-In verwenden, können Sie Egress-IPs konfigurieren. Weitere Informationen finden Sie unter Konfigurieren einer Egress-IP-Adresse.

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.
  • Öffentlich – API-Server kann über externe Netzwerke zugegriffen werden.
  • Privat – Der API-Server hat eine private IP-Adresse aus dem Subnetz der Kontrollebene zugewiesen bekommen, die nur über verbundene Netzwerke (gekoppelte virtuelle Netzwerke und andere Subnetze im Cluster) erreichbar ist.
• Ingress Visibility – Legen Sie die API-Sichtbarkeit beim Ausführen des Befehls az aro create fest.
  • Öffentliche Routen werden standardmäßig an einen öffentlichen Standard-Load-Balancer übermittelt. (Die Standardeinstellung kann geändert werden.)
  • Private Routen verwenden standardmäßig einen internen Load Balancer. (Die Standardeinstellung kann geändert werden.)

Netzwerksicherheitsgruppen

Netzwerksicherheitsgruppen werden in der Ressourcengruppe des Knotens erstellt, die für Benutzer gesperrt ist. 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

Azure Red Hat OpenShift verwendet CoreDNS als In-Cluster-DNS-Anbieter, und Sie können ihn nicht ersetzen. Sie können die Domänenweiterleitung für direkte Abfragen für bestimmte Domänen an Ihre eigenen DNS-Server konfigurieren. Weitere Informationen finden Sie in der Dokumentation zur Verwendung der DNS-Weiterleitung.

Nächste Schritte

Weitere Informationen zum ausgehenden Datenverkehr und dazu, welche Egressszenarien von Azure Red Hat OpenShift unterstützt werden, finden Sie in der Dokumentation zu den Support-Richtlinien.