Netzwerkarchitektur für AKS auf Azure Local

Dieses Szenario veranschaulicht, wie Sie Netzwerkkonzepte für die Bereitstellung von Azure Kubernetes Service-Knoten (AKS) in AKS-Clustern entwerfen und implementieren.

Dieser Artikel enthält Empfehlungen für den Netzwerkentwurf für Kubernetes-Knoten und -Container. Er ist Teil eines aus zwei Artikeln bestehenden Leitfadens für die Architekturbaseline. Mehr zu den Empfehlungen für die Baselinearchitektur finden Sie hier.

Aufbau

Die folgende Abbildung zeigt die Netzwerkarchitektur für Azure Kubernetes-Dienst in Azure Local oder Windows Server 2019/2022-Rechenzentrumsclustern:

Laden Sie eine Visio-Datei dieser Architektur herunter.

Das Szenario umfasst die folgenden Komponenten und Funktionen:

• Azure Stack HCI, Version 22H2, ist eine Hyperconverged Infrastructure (HCI)-Clusterlösung, die virtualisierte Windows- und Linux-Workloads und deren Speicher in einer lokalen Hybridumgebung hostet. Azure Local instance is implemented as a 2-4 node cluster.
• Ein Windows Server 2019/2022 Datacenter-Failovercluster besteht aus einer Gruppe unabhängiger Computer, die miteinander interagieren und somit die Verfügbarkeit und Skalierbarkeit von Clusterrollen erhöhen.
• Azure Kubernetes Service auf azure Local ist eine lokale Implementierung von Azure Kubernetes Service (AKS), die die Ausführung containerisierter Anwendungen im großen Maßstab automatisiert.
• Active Directory Domain Services ist eine hierarchische Struktur, in der Informationen zu Objekten im Netzwerk gespeichert werden. Die Lösung bietet eine Identitätsprüfungs- und Zugriffslösung für Identitäten, die Benutzern, Computern, Anwendungen oder anderen Ressourcen innerhalb einer Sicherheitsgrenze zugeordnet sind.
• Der Verwaltungscluster, der auch als AKS-Host bezeichnet wird, ist für die Bereitstellung und Verwaltung mehrerer Workloadcluster zuständig. Der Verwaltungscluster nutzt eine IP-Adresse aus dem Knotenpool. Sie sollten jedoch für Updatevorgänge zwei weitere IP-Adressen reservieren. Der Verwaltungscluster nutzt auch eine IP-Adresse aus dem Pool virtueller IP-Adressen.
• Der Workloadcluster ist eine hochverfügbare Bereitstellung von Kubernetes unter Verwendung von Linux-VMs zur Ausführung von Komponenten auf Kubernetes-Steuerungsebene und von Linux- und/oder Windows-Workerknoten.
  • Steuerungsebene. Wird in einer Linux-Distribution ausgeführt und enthält API-Serverkomponenten für die Interaktion mit der Kubernetes-API und einen verteilten Schlüssel-Wert-Speicher (etcd) zum Speichern aller Konfigurationen und Daten des Clusters. Die Steuerungsebene nutzt eine IP-Adresse aus dem Knotenpool und eine aus dem Pool virtueller IP-Adressen.
  • Lastenausgleich. Wird auf einer Linux-VM ausgeführt und stellt Dienste zum Lastenausgleich für den Workloadcluster bereit. Die Steuerungsebene nutzt eine IP-Adresse aus dem Knotenpool und eine aus dem Pool virtueller IP-Adressen.
  • Workerknoten. Werden unter einem Windows- oder Linux-Betriebssystem ausgeführt, das containerisierte Anwendungen hostet. Sie nutzen IP-Adressen aus dem Knotenpool, aber Sie sollten mindestens drei weitere IP-Adressen für Updatevorgänge einplanen.
  • Kubernetes-Ressourcen. Pods stellen eine einzelne Instanz Ihrer Anwendung dar, die in der Regel eine 1:1-Zuordnung zu einem Container aufweisen. Bestimmte Pods können jedoch mehrere Container enthalten. Bereitstellungen stellen einen oder mehrere identische Pods dar. Pods und Bereitstellungen werden logisch in einem Namespace gruppiert, der den Zugriff zur Verwaltung der Ressourcen steuert. Sie nutzen 1 IP-Adresse pro Pod im Pool virtueller IP-Adressen.
• Azure Arc ist ein cloudbasierter Dienst, der das auf dem Azure Resource Manager basierende Verwaltungsmodell um Nicht-Azure-Ressourcen erweitert, einschließlich virtueller Computer (VMs), Kubernetes-Cluster und containerisierter Datenbanken.
• Azure Policy ist ein cloudbasierter Dienst, der Azure- und lokale Ressourcen durch die Integration mit Azure Arc auswertet, indem Eigenschaften mit anpassbaren Geschäftsregeln verglichen werden.
• Azure Monitor ist ein cloudbasierter Dienst, der Verfügbarkeit und Leistung Ihrer Anwendungen und Dienste durch Bereitstellung einer umfassenden Lösung für das Sammeln, Analysieren und Reagieren auf Telemetriedaten aus Ihren cloudbasierten und lokalen Umgebungen maximiert.
• Microsoft Defender for Cloud ist ein einheitliches Sicherheitsverwaltungssystem für die Infrastruktur, das den Sicherheitsstatus Ihrer Rechenzentren stärkt und erweiterten Bedrohungsschutz für Ihre Hybridworkloads in der Cloud- und lokalen Umgebung bietet.

Komponenten

• Windows Server 2019/2022 Datacenter-Failovercluster
• Azure Kubernetes Service (AKS)
• Windows Admin Center
• Ein Azure-Abonnement
• Azure Arc
• Was ist die rollenbasierte Zugriffssteuerung (Role-Based Access Control, RBAC) für Azure-Ressourcen?
• Azure Monitor
• Microsoft Defender für Cloud

Szenariodetails

Die Anwendungsfälle für dieses Szenario sind im ersten Artikel der Reihe, Baselinearchitektur, beschrieben.

Netzwerk für Kubernetes-Knoten

Die hauptüberlegung des Netzwerkdesigns für die AKS auf Azure Local ist die Auswahl des Netzwerkmodells, das genügend IP-Adressen bereitstellt. AKS auf Azure Local verwendet virtuelle Netzwerke, um IP-Adressen den Kubernetes-Knotenressourcen zuzuweisen. Es gibt zwei Modelle für die Zuweisung von IP-Adressen:

• Statische IP-Netzwerke sind besser vorhersehbar, verursachen aber zusätzlichen Aufwand bei der Erstkonfiguration.
• DHCP-Netzwerke (Dynamic Host Configuration Protocol) nutzen die dynamische Zuweisung von IP-Adressen und sind weniger aufwändig, aber Sie müssen darauf achten, dass der verfügbare Pool von IP-Adressen nicht vollständig ausgeschöpft wird. Außerdem müssen Sie Reservierungen und Ausschlussbereiche für Pools virtueller IP-Adressen und bestimmte clusterweite Ressourcen wie den Cloud-Agent-Dienst verwalten.

Bei beiden Zuweisungsmodellen müssen IP-Adressen für Folgendes eingeplant werden:

• Pool virtueller IP-Adressen
• Kubernetes-Knoten-VM-IP-Pool

Pool virtueller IP-Adressen

Ein virtueller IP-Pool ist eine Reihe von IP-Adressen, die für alle AKS in der lokalen Azure-Bereitstellung obligatorisch sind. Planen Sie die Anzahl der IP-Adressen im Pool virtueller IP-Adressen basierend auf der Anzahl von Workloadclustern und Kubernetes-Diensten. Der Pool virtueller IP-Adressen stellt IP-Adressen für die folgenden Ressourcentypen bereit:

• Der Cloud-Agent erfordert eine Floating IP-Adresse aus dem Pool virtueller IP-Adressen.

• Die API-Serverkomponente, die innerhalb der Kubernetes Virtual Appliance-VM (KVA) im Verwaltungscluster ausgeführt wird, verwendet eine IP-Adresse aus dem Pool virtueller IP-Adressen. Der API-Server ist eine Komponente der Kubernetes-Steuerungsebene, die die Kubernetes-API verfügbar macht. Der API-Server ist das Front-End für die Kubernetes-Steuerungsebene. Die KVA ist ein virtueller Computer, auf dem Mariner Linux ausgeführt und ein Kubernetes-Cluster gehostet wird. Die IP-Adresse ist unverankert und wird auch für alle anderen KVA-VM verwendet, die Sie in AKS auf Azure Local bereitstellen. Die KVA-VM hostet auch einen Kubernetes-Lastenausgleichsdienst für virtuelle IP-Adressen.

• Planen Sie die IP-Adressierung für die Anzahl der VMs auf Steuerungsebene, die auf den Zielservern bereitgestellt werden, da sie auch weitere IP-Adressen aus dem Pool virtueller IP-Adressen nutzen. Die Überlegungen werden im nächsten Abschnitt beschrieben.

• Der Zielcluster enthält eine Lastenausgleichs-VM, die als HAProxy fungiert und den Pool virtueller IP-Adressen für den Zielcluster besitzt. Diese VM macht alle Kubernetes-Dienste über den Pool virtueller IP-Adressen verfügbar.

• Anwendungen, die in Kubernetes-Pods ausgeführt werden, nutzen IP-Adressen aus dem Pool virtueller IP-Adressen.

• Das HAProxy-Lastenausgleichsmodul wird als spezialisierte VM bereitgestellt und kann zum Lastenausgleich von mehreren Endpunkten eingehender Anforderungen eingesetzt werden. Sie nutzen IP-Adressen aus dem Pool virtueller IP-Adressen, und Sie müssen die IP-Adressierung für jeden Workloadcluster planen.

Kubernetes-Knoten-VM-IP-Pool

Kubernetes-Knoten werden als virtuelle Computer in einer AKS in einer lokalen Azure-Bereitstellung bereitgestellt. Stellen Sie sicher, dass Sie die Anzahl der IP-Adressen entsprechend der Gesamtanzahl der Kubernetes-Knoten planen und mindestens drei weitere IP-Adressen hinzufügen, die während des Upgradeprozesses verwendet werden. Für die Konfiguration statischer IP-Adressen müssen Sie den IP-Adressenpoolbereich der VM des Kubernetes-Knotens angeben, was bei der DHCP-Zuordnung nicht erforderlich ist. Planen Sie zusätzliche IP-Adressen für Folgendes ein:

• Die KVA-VM verwendet auch weitere IP-Adressen für Kubernetes aus dem IP-Adressenpool der VM des Kubernetes-Knotens. Planen Sie, während des Updateprozesses IP-Adressen hinzuzufügen, da die KVA-VM dieselbe virtuelle IP-Adresse für den API-Dienst verwendet, aber eine separate IP-Adresse aus dem IP-Pool der VM des Kubernetes-Knotens benötigt.
• VMs auf Steuerungsebene nutzen für den API-Serverdienst eine IP-Adresse aus dem IP-Adressenpool der VM des Kubernetes-Knotens. Diese VMs hosten auch den Azure Arc-Agent, der zu Verwaltungszwecken eine Verbindung mit dem Azure-Portal herstellt.
• Knoten in einem Knotenpool (Linux oder Windows) nutzen IP-Adressen aus dem IP-Adressenpool, der der VM des Kubernetes-Knotens zugeordnet ist.

Der Dienst Microsoft On-Premise Cloud

Planen Sie den IP-Adressbereich für die lokale Microsoft-Cloud (MOC), der den Verwaltungsstapel ermöglicht, sodass die virtuellen Computer auf Azure Local in der Cloud verwaltet werden. Die IP-Adresszuweisung für den MOC-Dienst befindet sich im zugrunde liegenden physischen Netzwerk, und die FÜR die lokalen Azure-Clusterknoten konfigurierten IP-Adressen befinden sich in Ihrem Rechenzentrum. Sie können IP-Adressen für die physischen Knoten Ihrer Azure Local in einer der folgenden Konfigurationen konfigurieren:

• Azure Local cluster nodes with a DHCP-based IP address allocation mode. Der MOC-Dienst ruft eine IP-Adresse vom DHCP-Dienst ab, die im physischen Netzwerk angezeigt wird.
• Azure Local cluster nodes with a static IP allocation model. Die IP-Adresse für den MOC-Clouddienst muss explizit als IP-Bereich im Format Classless Inter-Domain Routing (CIDR) angegeben werden und muss sich im selben Subnetz wie die IP-Adressen von Azure Local Cluster-Knoten befinden.

Lastenausgleich in AKS auf Azure Local

Für eine kleine Bereitstellung können Sie den integrierten Lastenausgleich verwenden, der als Linux-VM bereitgestellt wird und HAProxy und KeepAlive verwendet, um den Datenverkehr an Anwendungsdienste zu senden, die als Teil des AKS-Clusters bereitgestellt werden. Der HAProxy-Lastenausgleich konfiguriert Pods als Endpunkte im Lastenausgleich. Er nimmt einen Lastenausgleich für Anforderungen an den Kubernetes-API-Server vor und verwaltet den Datenverkehr zu Anwendungsdiensten.

Sie können auch einen benutzerdefinierten Lastenausgleich zum Verwalten des Datenverkehrs Ihrer Dienste verwenden. Das benutzerdefinierte Lastenausgleichsmodul bietet der Bereitstellung zusätzliche Flexibilität und stellt sicher, dass AKS auf Azure Local zusammen mit vorhandenen Bereitstellungen wie Software Defined Network (SDN)-Bereitstellungen funktioniert, die Lastenausgleichsgeräte verwenden. Für benutzerdefinierte Lastenausgleichsmodule stellt „kube-virtual IP“ Kubernetes-Clustern eine virtuelle IP-Adresse und einen Lastenausgleich für die Steuerungsebene und Kubernetes Service-Instanzen des Typs LoadBalancer bereit. Der Dienst „kube-virtual IP“ wird automatisch auf jedem Workerknoten bereitgestellt.

AKS auf Azure Local unterstützt auch die Verwendung von MetalLB oder anderen OSS Kubernetes-basierten Lastenausgleichsmodulen, um den datenverkehrsgebundenen Datenverkehr für Dienste in einem Workloadcluster zu ausgleichen. MetalLB ist eine Lastenausgleichsimplementierung für Bare-Metal-Kubernetes-Cluster, die Standardroutingprotokolle wie BGP (Border Gateway Protocol) verwendet. Es kann sowohl mit Netzwerk-Add-Ons als auch mit Calico und Flannel funktionieren. Sie müssen jedoch sicherstellen, dass der während der Installation von AKS auf Azure Local bereitgestellte virtuelle IP-Adressbereich nicht mit dem für den benutzerdefinierten Lastenausgleich geplanten IP-Adressbereich überlappt.

Bereitstellen dieses Szenarios

Bereitstellen eines Eingangsdatencontrollers

Erwägen Sie die Implementierung eines Eingangsdatencontrollers für die TLS-Terminierung, von Reversible Proxy oder des konfigurierbaren Routings von Datenverkehr. Eingangsdatencontroller agieren auf Schicht 7 und unterstützen intelligente Regeln zum Verteilen von Anwendungsdatenverkehr. Mithilfe von Ressourcen für eingehende Kubernetes-Daten werden Eingangsregeln und Routen für einzelne Kubernetes-Dienste konfiguriert. Wenn Sie einen Eingangsdatencontroller definieren, konsolidieren Sie die Regeln für das Routing von Datenverkehr in einer einzelnen Ressource, die als Teil Ihres Clusters ausgeführt wird.

Verwenden Sie einen Eingangsdatencontroller, um Dienste über extern erreichbare URLs verfügbar zu machen. Der Eingangsdatencontroller macht HTTP- und HTTPS-Routen von außerhalb des Clusters für Dienste innerhalb des Clusters verfügbar. Das Datenverkehrsrouting wird mit Regeln gesteuert, die für die Eingangsressource definiert sind. Die HTTP-Eingangsregeln enthalten die folgenden Informationen:

• Einen optionalen Host. Wenn Sie keine Hostinformationen angeben, gilt die Regel für den gesamten eingehenden HTTP-Datenverkehr.
• Eine Liste mit Pfaden, denen ein Back-End zugeordnet ist, das mit service.name und service.port.name oder service.port.number definiert ist.
• Ein Back-End, das eine Kombination aus Dienst- und Portnamen bereitstellt.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: hello-world
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /
    kubernetes.io/ingress.class: "nginx"
spec:
  rules:
  - host: test.example.com
     http:
       paths:
       - path: /hello-world
          pathType: Prefix
          backend:
            service:
              name: hello-world
              port:
                 number: 8080

Verwenden Sie einen Eingangsdatencontroller, um den Datenverkehr zwischen verschiedenen Back-Ends der Anwendung auszugleichen. Der Datenverkehr wird aufgeteilt und basierend auf den Pfadinformationen an verschiedene Dienstendpunkte und Bereitstellungen gesendet.

Um HTTP-Datenverkehr an mehrere Hostnamen mit derselben IP-Adresse weiterzuleiten, können Sie für jeden Host eine andere Eingangsressource verwenden. Der Datenverkehr, der von der IP-Adresse des Lastenausgleichs stammt, wird basierend auf dem Hostnamen und Pfad in der Eingangsregel weitergeleitet.

Containernetzwerkkonzepte in Azure Kubernetes Service (AKS) auf Azure Local

Kubernetes stellt eine Abstraktionsebene für ein virtuelles Netzwerk bereit, sodass die containerbasierten Anwendungen intern oder extern kommunizieren können. Die Komponente kube-proxy wird auf jedem Knoten ausgeführt und kann entweder direkten Zugriff auf den Dienst bereitstellen, Datenverkehr mithilfe von Lastenausgleichsinstanzen verteilen oder für komplexeres Anwendungsrouting Eingangsdatencontroller verwenden. Kubernetes nutzt Dienste, um eine Reihe von Pods logisch zu gruppieren und Netzwerkkonnektivität bereitzustellen. Die folgenden Kubernetes-Dienste sind verfügbar:

• Cluster IP: Dieser Dienst erstellt für ausschließlich interne Anwendungen eine interne IP-Adresse.
• NodePort: Dieser Dienst erstellt auf dem zugrunde liegenden Knoten eine Portzuordnung, über die mithilfe der IP-Adresse und des Ports des Knotens der direkte Zugriff auf die Anwendung erfolgen kann.
• LoadBalancer: Sie können Kubernetes-Dienste mithilfe von Lastenausgleichsregeln oder einem Eingangsdatencontroller extern verfügbar machen.
• ExternalName: Dieser Dienst verwendet für die Kubernetes-Anwendung einen bestimmten DNS-Eintrag.

Kubernetes-Netzwerke

In AKS auf Azure Local kann der Cluster mithilfe eines der folgenden Netzwerkmodelle bereitgestellt werden:

• Project Calico-Netztechnologie. Dies ist ein Standardnetzwerkmodell für AKS auf Azure Local und basiert auf einem Open-Source-Netzwerk, das Netzwerksicherheit für Container, virtuelle Computer und systemeigene hostbasierte Workloads bereitstellt. Die Calico-Netzwerkrichtlinie kann auf jede Art von Endpunkt angewendet werden, z. B. Pods, Container, VMs oder Hostschnittstellen. Jede Richtlinie besteht aus Regeln, die ein- und ausgehenden Datenverkehr mithilfe von Aktionen steuern, welche den Datenverkehr zwischen Quell- und Zielendpunkten entweder zulassen, verweigern, protokollieren oder weiterleiten können. Calico kann entweder den erweiterten Berkeley-Paketfilter (eBPF) von Linux oder die Netzwerkpipeline für Linux-Kernel für die Zustellung von Datenverkehr verwenden. Calico wird auch unter Windows mithilfe des Host Networking Service (HNS) zum Erstellen von Namespaces im Netzwerk pro Containerendpunkt unterstützt. Im Kubernetes-Netzwerkmodell erhält jeder Pod eine eigene IP-Adresse, die von Containern innerhalb dieses Pods gemeinsam genutzt wird. Pods kommunizieren im Netzwerk über Pod-IP-Adressen, und die Isolation wird mithilfe von Netzwerkrichtlinien definiert. Calico verwendet CNI-Plug-Ins (Container Network Interface) zum Hinzufügen oder Löschen von Pods im Kubernetes-Podnetzwerk und CNI IPAM-Plug-Ins (IP Address Management) zum Zuordnen und Freigeben von IP-Adressen.
• Flannel-Überlagerungsnetzwerk. Flannel erstellt eine virtuelle Netzwerkschicht, die das Hostnetzwerk überlagert. Das Überlagerungsnetzwerk nutzt die Kapselung der Netzwerkpakete über das vorhandene physische Netzwerk. Flannel vereinfacht die IP-Adressverwaltung (IPAM), unterstützt die Wiederverwendung von IP-Adressen zwischen verschiedenen Anwendungen und Namespaces und bietet eine logische Trennung von Containernetzwerken vom untergeordneten Netzwerk, das von den Kubernetes-Knoten verwendet wird. Die Netzwerkisolation wird mithilfe von VXLAN (Virtual eXtensible Local Area Network) erreicht, einem Kapselungsprotokoll, das Rechenzentrumskonnektivität mithilfe von Tunneling bereitstellt, um Layer-2-Verbindungen über ein zugrunde liegendes Layer-3-Netzwerk zu strecken. Flannel wird sowohl von Linux-Containern mit DaemonSet als auch von Windows-Containern mit Flannel-CNI-Plug-In unterstützt.

Azure Local Networking Design

Das allgemeine Netzwerkdesign umfasst Planungsaktivitäten für Azure Local.

Beginnen Sie zunächst mit der Planung der Hardware und Installation von Azure Local. Sie können entweder integrierte Systeme von einem Microsoft-Hardwarepartner mit dem vorinstallierten Azure Stack HCI OS erwerben oder validierte Knoten kaufen und das Betriebssystem selbst installieren. Azure Local ist als Virtualisierungshost vorgesehen, sodass Kubernetes-Serverrollen innerhalb von virtuellen Computern ausgeführt werden müssen.

Physische Netzwerkanforderungen für Azure Local

Microsoft zertifiziert keine Netzwerkswitches, aber es gelten bestimmte Anforderungen, die der Gerätehersteller erfüllen muss:

• Standard: IEEE 802.1Q mit Definition eines virtuellen lokales Netzwerks (VLAN).
• Standard: IEEE 802.1Q mit Definition von Priority Flow Control (PFC).
• Standard: IEEE 802.1Qaz mit Definition von Enhanced Transmission Selection (ETS).
• Standard: IEEE 802.1AB mit Definition des LLTD-Protokolls (Link Layer Topology Discovery).

Hostnetzwerkanforderungen für Azure Local

Erwägen Sie den Einsatz eines Netzwerkadapters, der mit der Zusatzqualifikation (Additional Qualification, AQ) Standard oder Premium für Windows SDDC (Software Defined Data Center) zertifiziert ist.

Stellen Sie sicher, dass der Netzwerkadapter Folgendes unterstützt:

• Dynamic Virtual Machine Multi-Queue (Dynamic VMMQ oder d.VMMQ) ist eine intelligente, empfangsseitige Technologie zur automatischen Optimierung der Verarbeitung von Netzwerkdatenverkehr auf CPU-Kernen.
• Remote Direct Memory Access (RDMA) ist eine Auslagerung des Netzwerkstapels an den Netzwerkadapter. Dies ermöglicht es dem SMB-Speicherdatenverkehr, bei der Verarbeitung das Betriebssystem zu umgehen.
• Mit Gast-RDMA können Sie bei SMB-Workloads für VMs von den gleichen Vorteilen wie bei Verwendung von RDMA auf Hosts profitieren.
• Switch Embedded Teaming (SET) ist eine softwarebasierte Teamingtechnologie.

Erwägen Sie die Verwendung von Network ATC, das eine absichtsbasierte Steuerung bietet, um die Konfiguration des Hostnetzwerks zu vereinfachen.

AKS auf einem lokalen Azure-Gerät erfordert eine zuverlässige Netzwerkverbindung mit hoher Bandbreite und geringer Latenz zwischen jedem Serverknoten. Vergewissern Sie sich, dass mindestens ein Netzwerkadapter verfügbar und für die Clusterverwaltung reserviert ist. Vergewissern Sie sich, dass physische Switches in Ihrem Netzwerk so konfiguriert sind, dass sie Datenverkehr für beliebige VLANs zulassen, die Sie verwenden möchten.

Virtueller Switch

Azure Local vereinfacht das Netzwerkdesign, indem ein virtueller Switch konfiguriert wird, der für die Netzwerkklassifizierung verwendet werden kann. Die virtuelle Netzwerkschnittstellenkarte (VNIC) kann in verschiedenen VLANs für die Hosts platziert werden, um einen unterschiedlichen Datenverkehrsfluss für die folgenden Netzwerke zu ermöglichen:

• Verwaltungsnetzwerk. Das Verwaltungsnetzwerk ist Teil des Nord-Süd-Netzwerks und dient zur Hostkommunikation.
• Computenetzwerk. Das Computenetzwerk ist Teil des Nord-Süd-Netzwerks und wird für VM-Datenverkehr verwendet. Verwenden Sie QOS (Quality of Service), SR-IOV (Single-Root I/O Virtualization) und vRDMA (virtual Remote Direct Memory Access), um die Netzwerkleistung bedarfsabhängig zu optimieren.
• Speichernetzwerk: Das Speichernetzwerk ist Teil des Ost-West-Netzwerks und erfordert RDMA mit einem empfohlenen Durchsatz von mindestens 10 GB. Sie wird für die Livemigration der VMs verwendet.
• VM-Gastnetzwerk.

Vorteil von Ost-West-Datenverkehr durch RDMA-Datenverkehr

Ost-West Netzwerkdatenverkehr stellt die Kommunikation zwischen den Hosts dar und lässt keinen Zugriff von außen zu. Datenverkehr bleibt innerhalb des ToR-Switches (Top of Rack) und der Layer-2-Grenzen. Dies schließt die folgenden Typen von Datenverkehr ein:

• Clustertakte und Kommunikation zwischen Knoten
• [SMB] Speicherbusebene
• [SMB] Für Cluster freigegebenes Volume
• [SMB] Speicherneuerstellung

Nord-Süd-Datenverkehr

North-South Datenverkehr ist der externe Datenverkehr, der die AKS in der lokalen Azure-Instanz erreicht. Sie können den Datenverkehr für die Palette der Azure-Dienste planen, die durch die Integration von Azure ARC die Überwachung, Abrechnung und Sicherheitsverwaltung ermöglichen. Nord-Süd-Datenverkehr hat die folgenden Merkmale:

• Datenverkehr fließt von einem ToR-Switch zum Spine oder vom Spine zu einem ToR-Switch.
• Datenverkehr verlässt das physische Rack oder überschreitet eine Layer-3-Grenze (IP).
• Datenverkehr umfasst Verwaltungs- (PowerShell, Windows Admin Center), Compute- (VM) und zwischen Standorten auftretenden Stretched Cluster-Datenverkehr.
• Verwendet einen Ethernet-Switch für Konnektivität mit dem physischen Netzwerk.

AKS auf Azure Local kann mehrere Clusternetzwerkbereitstellungsoptionen verwenden:

• Zusammengeführtes Netzwerk unter Kombination mehrerer Netzwerkabsichten (Verwaltung, Compute, Speicher). Dies ist die empfohlene Bereitstellung für mehr als drei physische Knoten und erfordert, dass alle physischen Netzwerkadapter mit denselben ToR-Switches verbunden sind. ROCEv2 wird unbedingt empfohlen.
• Die switchlose Bereitstellung nutzt die Nord-Süd-Kommunikation als Netzwerkteam, indem Compute- und Verwaltungsnetzwerke kombiniert werden.
• Hybridbereitstellung als Kombination beider Bereitstellungen.

Empfehlungen

Die folgenden Empfehlungen gelten für die meisten Szenarios. Halten Sie sich an die Empfehlungen, es sei denn, Sie haben eine spezielle Anforderung, die Vorrang hat.

Netzwerkempfehlungen

Das wichtigste Problem beim Netzwerkdesign für die AKS auf Azure Local ist die Auswahl eines Netzwerkmodells, das genügend IP-Adressen für Ihren Kubernetes-Cluster und seine Dienste und Anwendungen bereitstellt.

• Erwägen Sie die Implementierung statischer IP-Adressen, damit AKS auf Azure Local die IP-Adresszuweisung steuern kann.

• Dimensionieren Sie die IP-Adressbereiche ordnungsgemäß, damit Sie über genügend freie IP-Adressen für einen Kubernetes-Knotenpool und einen Pool virtueller IP-Adressen verfügen. Stellen Sie sicher, dass Ihr Pool virtueller IP-Adressen groß genug ist, damit Sie bei einem Upgrade parallele Upgrades verwenden können, die mehr IP-Adressen erfordern. Sie können Folgendes planen:

  • Adressierung/Hostnamen für Proxyeinstellungen
  • IP-Adressen für die Steuerungsebene des Zielclusters
  • IP-Adressen für Azure Arc
  • IP-Adressen für die horizontale Skalierung von Worker- und Steuerungsebenenknoten in Zielclustern

• Ihr Pool virtueller IP-Adressen sollte groß genug sein, um die Bereitstellung der Anwendungsdienste zu unterstützen, die Konnektivität mit dem externen Router erfordern.

• Implementieren Sie Calico CNI, um eine erweiterte Netzwerkrichtlinie für die Steuerung der Pod- und Anwendungskommunikation bereitzustellen.

• Stellen Sie sicher, dass sich die physischen Clusterknoten (HCI oder Windows Server) im selben Rack befinden und mit denselben ToR-Switches verbunden sind.

• Deaktivieren Sie IPv6 auf allen physischen Netzwerkadaptern.

• Stellen Sie sicher, dass der vorhandene virtuelle Switch und sein Name auf allen Clusterknoten identisch sind.

• Stellen Sie sicher, dass alle Subnetze, die Sie für den Cluster definieren, untereinander und in das Internet routingfähig sind.

• Stellen Sie sicher, dass die Netzwerkkonnektivität zwischen lokalen Azure-Hosts und den VMs des Mandanten besteht.

• Aktivieren Sie dynamische DNS-Updates in Ihrer DNS-Umgebung, damit AKS auf Azure Local den generischen Clusternamen des Cloud-Agents im DNS-System für die Ermittlung registrieren kann.

• Erwägen Sie die Implementierung der Klassifizierung von Netzwerkdatenverkehr anhand seiner Richtung:

  • North-South Datenverkehr ist der Datenverkehr von Azure Local und rest des Netzwerks,
    • Verwaltung
    • Compute
    • Stretched Cluster-Datenverkehr zwischen Standorten
  • East-West Datenverkehr in Azure Local:
    • Speicherdatenverkehr einschließlich Livemigration zwischen Knoten im selben Cluster.
    • Ethernet-Switch oder direkte Verbindung.

Modelle für den Speicherdatenverkehr

• Verwenden Sie mehrere Subnetze und VLANs, um den Speicherdatenverkehr in Azure Local zu trennen.
• Erwägen Sie die Implementierung der Zuordnung von Bandbreite für verschiedener Datenverkehrstypen.

Überlegungen

Beim Microsoft Azure Well-Architected Framework handelt es sich um eine Zusammenstellung von Grundsätzen, die bei diesem Szenario berücksichtigt werden. Diese Grundsätze bilden den Rahmen für die folgenden Überlegungen.

Zuverlässigkeit

• Integrierte Resilienz, inhärent in softwaredefiniertem Compute von Microsoft (Failovercluster von Hyper-V-Knoten), Speicher (geschachtelte Resilienz über das Feature „Direkte Speicherplätze“) und Netzwerken (softwaredefinierte Netzwerke).
• Erwägen Sie die Auswahl des Netzwerkswitches, der Branchenstandards unterstützt und eine zuverlässige Kommunikation zwischen Knoten gewährleistet. Die folgenden Standards umfassen Folgendes:
  • Standard: IEEE 802.1Q
  • Standard IEEE 802.1Qbb
  • Standard IEEE 802.1 Qas
  • Standard IEEE 802.1 AB
• Erwägen Sie die Implementierung mehrerer Hosts im Verwaltungs-und Kubernetes-Cluster, um die Mindestverfügbarkeit für Workloads zu erreichen.
• AKS auf Azure Local verwendet Failoverclustering und Livemigration für hohe Verfügbarkeit und Fehlertoleranz. Die Livemigration ist eine Hyper-V-Funktion, mit der Sie ausgeführte VMs ohne wahrgenommene Downtime transparent von einem Hyper-V-Host zu einem anderen migrieren können.
• Stellen Sie sicher, dass die Dienste, auf die im Abschnitt Architektur verwiesen wird, in der Region unterstützt werden, in der Azure Arc bereitgestellt wird.

Sicherheit

• Sichern Sie den Datenverkehr zwischen Pods mithilfe von Netzwerkrichtlinien in AKS auf Azure Local.
• Der API-Server in AKS auf Azure Local enthält die Zertifizierungsstelle, die Zertifikate für die Kommunikation vom Kubernetes-API-Server an kubeletsigniert.
• Verwenden Sie einmaliges Anmelden (SSO) von Microsoft Entra, um eine sichere Verbindung mit dem Kubernetes-API-Server herzustellen.
• Mit der rollenbasierten Zugriffssteuerung in Azure (Azure RBAC) können Sie den Zugriff auf Azure Arc-fähige Kubernetes-Versionen in Azure-Umgebungen und lokalen Umgebungen mit Microsoft Entra-Identitäten verwalten. Weitere Informationen finden Sie unter Verwenden von Azure RBAC für die Kubernetes-Autorisierung.

Kostenoptimierung

• Mithilfe des Azure-Preisrechners können Sie die Kosten für die in der Architektur verwendeten Dienste schätzen. Weitere bewährte Methoden finden Sie im Abschnitt Grundsätze der Kostenoptimierung in den Artikeln zum Microsoft Azure Well-Architected Framework.
• Erwägen Sie die Implementierung von Hyperthreading auf Ihrem physischen Computer, um die Kosten zu optimieren, da die AKS auf der lokalen Azure-Abrechnungseinheit ein virtueller Kern ist.
• Die Funktionalität der Azure Arc-Steuerungsebene wird ohne zusätzliche Kosten bereitgestellt. Dazu gehören die Unterstützung der Ressourcenorganisation durch Azure-Verwaltungsgruppen und -Tags sowie die Zugriffssteuerung durch Azure RBAC. Azure-Dienste, die in Verbindung mit Azure Arc-fähigen Servern genutzt werden, verursachen Kosten entsprechend ihrer Nutzung.
• Aus Gründen der Kosteneffizienz können Sie bis zu zwei Clusterknoten mit nur vier Datenträgern und 64 Gigabyte (GB) Arbeitsspeicher pro Knoten verwenden. Sie können Interconnects ohne Switches zwischen Knoten nutzen, um die Kosten weiter zu minimieren. Auf diese Weise entfällt die Notwendigkeit der Verwendung redundanter Switchgeräte.

Optimaler Betrieb

• Vereinfachte Verwaltung dank Windows Admin Center. Windows Admin Center ist die Benutzeroberfläche zum Erstellen und Verwalten von AKS auf Azure Local. Sie kann auf windows 10/11- oder Windows Server-VM installiert werden, die in Azure registriert werden müssen und sich in derselben Domäne wie der Lokale Azure- oder Windows Server-Rechenzentrumscluster befinden.
• Integration in Azure Arc oder einer Reihe von Azure-Diensten, die mehr Verwaltungs-, Wartungs- und Resilienzfunktionen bieten (Azure Monitor, Azure Backup).
• Wenn Ihr Kubernetes-Cluster an Azure Arc angefügt ist, können Sie Ihren Kubernetes-Cluster über GitOps verwalten. Bewährte Methoden zum Herstellen einer Verbindung eines hybriden Kubernetes-Clusters mit Azure Arc finden Sie im Szenario Azure Arc-Hybridverwaltung und -bereitstellung für Kubernetes-Cluster.
• Die lokale Azure-Plattform trägt auch dazu bei, virtuelle Netzwerke für AKS auf lokalen Azure-Instanzen zu vereinfachen, indem das "zugrunde liegende" Netzwerk auf hochverfüzbarte Weise bereitgestellt wird.

Effiziente Leistung

• Verwenden Sie azure Local certified hardware for improved application uptime and performance, simplified management and operations, and lower total cost of ownership.
• Speicher: Direkte Speicherplätze
  • Volumekonfiguration (geschachtelte bidirektionale Spiegelung im Vergleich zu geschachtelter, spiegelbeschleunigter Parität)
  • Datenträgerkonfiguration (Zwischenspeichern, Ebenen)
• Stellen Sie sicher, dass sich die sich physisch im selben Rack befinden und mit denselben ToR-Switches verbunden sind.
• Planen Sie IP-Adressreservierungen zum Konfigurieren von AKS-Hosts, Workloadclustern, Cluster-API-Servern, Kubernetes Service-Instanzen und Anwendungsdiensten. Microsoft empfiehlt, mindestens 256 IP-Adressen für die AKS-Bereitstellung in Azure Local zu reservieren.
• Erwägen Sie die Implementierung eines Eingangsdatencontrollers, der auf Layer 7 funktioniert und intelligentere Regeln zum Verteilen von Anwendungsdatenverkehr verwendet.
• Verwenden Sie für umfangreiche Workloads die GPU-Beschleunigung (Graphics Processing Unit).

Beitragende

Dieser Artikel wird von Microsoft gepflegt. Er wurde ursprünglich von folgenden Mitwirkenden geschrieben:

Hauptautoren:

• Lisa DenBeste | Project Management Program Manager
• Kenny Harder | Project Manager
• Mike Kostersitz | Principal Program Manager Lead
• Meg Olsen | Principal
• Nate Waters | Product Marketing Manager

Andere Mitwirkende:

• Walter Oliver | Senior Program Manager

Nächste Schritte

• Übersicht über AKS

Zugehörige Ressourcen

• Basisarchitektur für AKS in Azure Local