Hinweis
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, sich anzumelden oder das Verzeichnis zu wechseln.
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, das Verzeichnis zu wechseln.
Azure Red Hat OpenShift mit gehosteten Steuerebenen stellt Arbeitsknoten in Ihrem Azure virtuellen Netzwerk bereit und verwendet ein dediziertes Subnetz, um eine private Verbindung zwischen der gehosteten Steuerungsebene und Ihren Arbeitsknoten herzustellen. Sie müssen ihr virtuelles Netzwerklayout, Subnetze und IP-Adressbereiche planen, bevor Sie den Cluster erstellen.
Planen der Computekapazität
Knotenpools bieten Rechenkapazität. Ein Knotenpool ist eine Gruppe von Workerknoten, die dieselbe VM-Größe, Datenträgerkonfiguration und Verfügbarkeitszone gemeinsam nutzen. Sie können mehrere Knotenpools in einem einzigen Cluster erstellen, um unterschiedliche Workloadtypen auf unterschiedlicher Hardware auszuführen. Informationen zu den unterstützten VM-Größen für Workerknoten finden Sie unter Unterstützte VM-Größen. Mehrere Entscheidungen zum Knotenpool wirken sich direkt auf Ihr Netzwerklayout aus, daher müssen Sie Ihre Rechenkapazität planen, bevor Sie Ihr Netzwerk dimensionieren.
Wenn Sie die folgenden Fragen beantworten, können Sie die Subnetze und IP-Adressbereiche für Ihren Cluster planen:
- Wie viele Knotenpools möchten Sie betreiben? Die Anzahl der Knotenpools bestimmt, wie viele Subnetze Sie möglicherweise benötigen. Wenn alle Pools das Standardmäßige Worker-Subnetz des Clusters gemeinsam nutzen, reicht ein Subnetz aus. Wenn Sie verschiedenen Pools separate Subnetze zuweisen, fügt jeder zu den CIDR-Anforderungen Ihres virtuellen Netzwerks und Ihrer Computer hinzu.
- Werden Sie über Verfügbarkeitszonen hinweg bereitstellen? Jeder Knotenpool wird in einer einzelnen Verfügbarkeitszone bereitgestellt. Um Workloads für hohe Verfügbarkeit über Zonen zu verteilen, benötigen Sie einen separaten Knotenpool und potenziell ein separates Subnetz für jede Zone. Mehr Zonen bedeuten mehr Subnetze und einen größeren Computer CIDR.
- Wird jeder Knotenpool sein eigenes Subnetz verwenden? Knotenpools werden im Standard-Worker-Subnetz des Clusters bereitgestellt, es sei denn, Sie geben ein anderes Subnetz an. Separate Subnetze bieten Ihnen die Netzwerkisolation zwischen Knotenpools, aber jedes Subnetz muss in den CIDR-Bereich des Computers und den virtuellen Netzwerkadressraum passen.
- Wie viele Knoten werden Sie in der Spitzenlast betreiben? Die maximale Knotenanzahl, einschließlich der Höchstwerte für die automatische Skalierung, bestimmt, wie groß jedes Subnetz sein muss. Der Cluster unterstützt maximal 500 Knoten insgesamt für alle Pools.
- Werden Sie später weitere Knotenpools hinzufügen? Die CIDR-Bereiche des Clusters können nach der Erstellung nicht mehr geändert werden. Wenn Sie in Zukunft Knotenpools mit neuen Subnetzen hinzufügen möchten, muss Ihr Computer-CIDR und das virtuelle Netzwerk über genügend Adressraum verfügen, um sie aufzunehmen.
Tipp
Beispiel für größenanpassung: Ein Cluster mit 3 Verfügbarkeitszonen, bis zu 50 Knoten pro Zone und ein separates Subnetz pro Zone benötigt drei /26 Subnetze (jeweils 64 Adressen, wobei 50 Knoten plus Azure reservierte Adressen enthalten sind) und ein /29 VNet-Integrationssubnetz.
Alle vier Subnetze passen in einen /24-Computer CIDR (256 Adressen).
Wenn Sie später weitere Knotenpools hinzufügen möchten, verwenden Sie eine größere Maschinen-CIDR wie /22 oder /16, um Platz für zusätzliche Subnetze zu lassen.
Subnetzanforderungen
Ihr virtuelles Netzwerk muss die folgenden Komponenten enthalten:
- Worker-Subnetz – Das Standardsubnetz , in dem die Arbeitsknoten des Clusters bereitgestellt werden. Wenn Sie einen Knotenpool erstellen, wird er in diesem Subnetz bereitgestellt, es sei denn, Sie geben ein anderes Subnetz an. Wenn Sie Knotenpools in mehreren Verfügbarkeitszonen bereitstellen möchten, können Sie für jede Zone ein separates Subnetz erstellen. Alle Knotenpoolsubnetze müssen sich im selben virtuellen Netzwerk wie der Cluster befinden. Dimensionieren Sie jedes Subnetz anhand der Anzahl der Workerknoten, die Sie darin ausführen möchten.
-
VNet-Integrationssubnetz – ein dediziertes Subnetz, das private Konnektivität zwischen der gehosteten Steuerebene (ausgeführt im Azure-Konto von Red Hat) und den Workerknoten in Ihrem Abonnement ermöglicht. Sie muss die folgenden Anforderungen erfüllen:
- Mindestgröße für
/29 - Befindet sich im selben virtuellen Netzwerk wie das Worker-Subnetz
- Nicht mit dem Worker-Subnetz oder Knotenpool-Subnetzen geteilt
- Mindestgröße für
- Netzwerksicherheitsgruppen – Wenn Sie einem Worker, einem Knotenpool oder einem VNet-Integrationssubnetz eine Netzwerksicherheitsgruppe (NSG) zuordnen, überprüfen Sie deren Regeln anhand des erforderlichen Datenverkehrs, der unter Erforderlicher Datenverkehr für Netzwerksicherheitsgruppen beschrieben wird. Sie weisen NSGs direkt den Subnetzen zu.
Erforderlicher Datenverkehr der Netzwerksicherheitsgruppe
Die mit dem Knotenpool und den VNet-Integrationssubnetzen verbundene Netzwerksicherheitsgruppe (Network Security Group, NSG) muss den folgenden Datenverkehr zulassen:
| NSG-Zuordnung | Richtung | Source | Destination | Zielports |
|---|---|---|---|---|
| Worker- oder Knotenpool-Subnetz | Ausgehend | Worker- oder Knotenpool-Subnetz | Übergeordnetes Cluster-Subnetz | TCP 443 und 6443 |
| VNet-Integrationssubnetz | Eingehend | Worker-Subnetz oder Knotenpool-Subnetz | VNet-Integrationssubnetz | TCP 443 und 8443 |
Mit diesen Verbindungen können Workerknoten den gehosteten Kube-API-Server und die gehostete Steuerungsebene erreichen. Wenn eine NSG-Verweigerungsregel den erforderlichen Datenverkehr blockiert, können Sie keine Knotenpools erstellen.
Führen Sie eine der folgenden Aktionen aus, um eine Verweigerungsregel zu beheben, die einen erforderlichen Fluss blockiert:
- Entfernen Sie die Verweigerungsregel.
- Schränken Sie die Deny-Regel so ein, dass sie nicht auf die erforderliche Quelle, das erforderliche Ziel und die erforderlichen Ports zutrifft.
- Fügen Sie eine Zulassungsregel hinzu, die der erforderlichen Quelle, dem Ziel und den Ports entspricht und eine höhere Priorität hat als die Verweigerungsregel. In einer NSG hat eine niedrigere numerische Priorität eine höhere Priorität.
Azure Red Hat OpenShift mit gehosteten Steuerebenen wertet TCP-Regeln und Wildcardregeln aus, die die erforderlichen Ports enthalten. Regeln zum Verweigern für nicht zugehörige Ports, UDP-Datenverkehr oder nicht zugehörige Ziele haben keinen Einfluss auf diese Validierung. Diese Regeln können jedoch weiterhin anderen Datenverkehr blockieren.
CIDR-Anforderungen
In der folgenden Tabelle werden die Anforderungen für virtuelle Netzwerke und CIDR beschrieben:
| Netzwerkanforderung | Vorgabe | Beschreibung |
|---|---|---|
| CIDR-Bereich des Computers | 10.0.0.0/16 |
Der IP-Adressbereich für Computeknoten. Sie muss alle CIDR-Adressbereiche für Ihre virtuellen Netzwerksubnetze umfassen, einschließlich aller Subnetze, die Sie für zusätzliche Knotenpools verwenden möchten. Subnetze müssen zusammenhängend sein. Für Bereitstellungen in einer einzelnen Verfügbarkeitszone werden mindestens 128 Adressen (/25) unterstützt. Eine Mindestanzahl von 256 Adressen (/24) wird für Bereitstellungen in mehreren Verfügbarkeitszonen unterstützt. |
| Dienst-CIDR-Bereich | 172.30.0.0/16 |
Der IP-Adressbereich für Kubernetes-Dienst-IPs. Der Bereich muss groß genug sein, um Ihre Workload zu bewältigen, und er darf sich nicht mit einem externen Dienst überschneiden, auf den innerhalb des Clusters zugegriffen wird. |
| Pod CIDR-Bereich | 10.128.0.0/14 |
Der IP-Adressbereich für Pods. Der Bereich muss groß genug sein, um Ihre Workload zu bewältigen, und er darf sich nicht mit einem externen Dienst überschneiden, auf den innerhalb des Clusters zugegriffen wird. |
| Hostpräfix | 23 |
Die Länge des Subnetzpräfixes, die jedem Knoten für seine Pods zugewiesen ist. Ein Wert von 23 weist jedem Knoten ein /23-Subnetz (512 IP-Adressen) aus dem Pod-CIDR-Bereich zu. |
Verwenden Sie die Standardwerte, es sei denn, sie erfüllen Ihre Anforderungen. Wenn Sie einen dieser Werte ändern müssen, befolgen Sie die folgenden Richtlinien:
- Die Pod-, Dienst- und Computer-CIDRs dürfen sich nicht miteinander überlappen.
- Die Pod- und Service-CIDRs dürfen sich nicht mit Adressbereichen überschneiden, die in Ihrem Netzwerk oder von externen Diensten verwendet werden, auf die aus dem Cluster zugegriffen wird.
- Der Computer-CIDR muss alle virtuellen Netzwerksubnetze umfassen, die vom Cluster verwendet werden, einschließlich des Workersubnetz, aller zusätzlichen Knotenpoolsubnetze und des VNet-Integrationssubnetzes. Wenn Sie in Zukunft Knotenpools mit separaten Subnetzen hinzufügen möchten, stellen Sie sicher, dass der Computer-CIDR groß genug ist, um sie einzuschließen. Wenn Ihr VNet z. B. verwendet
10.0.0.0/16, deckt der Standardcomputer-CIDR10.0.0.0/16alle Subnetze ab. - Das Pod-Netzwerk verwendet nicht routingfähige IP-Adressen und wird nur innerhalb des softwaredefinierten Netzwerks des Clusters verwendet.
Private Clusterkonnektivität
Wenn Sie einen privaten API-Server, einen privaten Standardausgang oder beides auswählen, müssen Sie eine private Netzwerkkonnektivität zwischen den Netzwerken Ihrer Benutzer und dem virtuellen Netzwerk des Clusters einrichten, bevor Sie den Cluster bereitstellen. Ohne diese Konnektivität können Administratoren, CI/CD-Pipelines und Endbenutzer die privaten Endpunkte nicht erreichen.
Zu den allgemeinen Konnektivitätsoptionen gehören:
- Azure VNet-Peering – Verbinden Sie zwei Azure virtuellen Netzwerke, sodass Ressourcen in jedem Netzwerk miteinander kommunizieren können.
- Azure VPN Gateway – Verbinden Sie Ihr lokales Netzwerk über einen STANDORT-zu-Standort-VPN-Tunnel mit dem virtuellen Netzwerk des Clusters.
- Azure ExpressRoute – Einrichten einer privaten, dedizierten Verbindung von Ihrem lokalen Netzwerk zu Azure über einen Verbindungsanbieter.
Stellen Sie bei der Planung privater Netzwerkkonnektivität sicher, dass sich die IP-Adressbereiche der per Peering verbundenen oder verbundenen Netzwerke nicht mit den Machine-CIDR-, Pod-CIDR- oder Service-CIDR-Bereichen des Clusters überschneiden.