Bearbeiten

Share via

Netzwerkarchitektur für AKS in Azure Stack HCI

Azure Stack
Windows Server

Dieses Szenario veranschaulicht, wie Sie Netzwerkkonzepte für die Bereitstellung von Azure Kubernetes Service-Knoten (AKS) in AKS-Hybridclustern 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 Service in Azure Stack HCI- oder Windows Server 2019/2022 Datacenter-Failoverclustern:

Conceptual graphic showing network baseline architecture.

Laden Sie eine Visio-Datei dieser Architektur herunter.

Das Szenario umfasst die folgenden Komponenten und Funktionen:

  • Azure Stack HCI (20H2) ist eine HCI-Clusterlösung (Hyperconverged Infrastruktur, hyperkonvergente Infrastruktur), mit der virtualisierte Windows- und Linux-Workloads und ihr Speicher in einer lokalen Hybridumgebung gehostet werden. Ein Azure Stack HCI-Cluster wird mit 2–4 Knoten implementiert.
  • 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 in Azure Stack HCI (AKS hybrid) ist eine lokale Implementierung von Azure Kubernetes Service (AKS), mit dem die Ausführung containerisierter Anwendungen im großen Stil automatisiert wird.
  • [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

  • [Azure Stack HCI (20H2)][1]
  • [Windows Server 2019/2022 Datacenter-Failovercluster][]
  • [Azure Kubernetes Service (AKS)][]
  • [Windows Admin Center][]
  • [Azure-Abonnement][]
  • [Azure Arc][2]
  • [Rollenbasierte Azure-Zugriffssteuerung (RBAC)][]
  • [Azure Monitor][3]
  • [Microsoft Defender for Cloud][4]

Szenariodetails

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

Netzwerk für Kubernetes-Knoten

Der wichtigste Aspekt beim Netzwerkentwurf für AKS in Azure Stack HCI ist die Auswahl eines Netzwerkmodells, das genügend IP-Adressen bereitstellt. AKS in Azure Stack HCI ordnet den Ressourcen der Kubernetes-Knoten IP-Adressen über virtuelle Netzwerke zu. 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 Pool virtueller IP-Adressen ist eine Zusammenstellung von IP-Adressen, die für jede Bereitstellung von AKS in Azure Stack HCI 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 eine Floating IP und wird auch für jede andere KVA-VM verwendet, die Sie in AKS in Azure Stack HCI 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 in einer AKS in Azure Stack HCI-Bereitstellung als VMs 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 Microsoft On-Premise Cloud (MOC), der den Verwaltungsstapel so aktiviert, dass die VMs in Azure Stack HCI in der Cloud verwaltet werden. Die IP-Adresszuordnung für den MOC-Dienst hängt vom zugrunde liegenden physischen Netzwerk und den IP-Adressen ab, die für die Azure Stack HCI-Clusterknoten in Ihrem Rechenzentrum konfiguriert sind. Sie können die IP-Adressen für die physischen Knoten Ihrer Azure Stack HCI-Instanz auf eine der folgenden Arten konfigurieren:

  • Azure Stack HCI-Clusterknoten mit einem DHCP-basierten IP-Adresszuordnungsmodell. Der MOC-Dienst ruft eine IP-Adresse vom DHCP-Dienst ab, die im physischen Netzwerk angezeigt wird.
  • Azure Stack HCI-Clusterknoten mit einem statischen IP-Adresszuordnungsmodell. Die IP-Adresse für den MOC-Clouddienst muss explizit als IP-Adressbereich im CIDR-Format (Classless Inter-Domain Routing) angegeben werden und sich im selben Subnetz wie die IP-Adressen der Azure Stack HCI-Clusterknoten befinden.

Lastenausgleich in AKS in Azure Stack HCI

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. Der benutzerdefinierte Lastenausgleich bietet zusätzliche Flexibilität für die Bereitstellung und stellt sicher, dass AKS in Azure Stack HCI zusammen mit vorhandenen Bereitstellungen funktioniert, z. B. SDN-Bereitstellungen (Software Defined Network), die Lastenausgleichsmodule nutzen. 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 in Azure Stack HCI unterstützt auch die Verwendung von MetalLB oder anderen OSS Kubernetes-basierten Lastenausgleichen, um den Datenverkehr für Dienste in einem Workloadcluster auszugleichen. MetalLB ist eine Lastenausgleichsimplementierung für Bare-Metal-Kubernetes-Cluster, die Standardroutingprotokolle wie BGP (Border Gateway Protocol) verwendet. Dies kann mit beiden Netzwerk-Add-Ons Calico und Flannel funktionieren. Sie müssen jedoch sicherstellen, dass sich der bei der Installation von AKS in Azure Stack HCI bereitgestellte virtuelle IP-Adressbereich nicht mit dem für den benutzerdefinierten Lastenausgleich vorgesehenen IP-Adressbereich überschneidet.

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 Stack HCI

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 in Azure Stack HCI kann der Cluster mit einem der folgenden Netzwerkmodelle bereitgestellt werden:

  • [Project Calico-Netztechnologie][] Dies ist ein standardmäßiges Netztechnologiemodell für AKS in Azure Stack HCI, das auf einem Open-Source-Netzwerk basiert und Netzwerksicherheit für Container, virtuelle Computer und native hostbasierte Workloads bietet. 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 Stack HCI-Netzwerkentwurf

Der allgemeine Netzwerkentwurf umfasst Planungsaktivitäten für Azure Stack HCI.

Beginnen Sie zunächst mit der Planung der Hardware und Installation von Azure Stack HCI. Sie können entweder bei einem Microsoft-Hardwarepartner integrierte Systeme erwerben, bei dem das Azure Stack HCI-Betriebssystem vorinstalliert ist, oder geprüfte Knoten kaufen und das Betriebssystem selbst installieren. Azure Stack HCI ist als Virtualisierungshost vorgesehen, weshalb Kubernetes-Serverrollen auf VMs ausgeführt werden müssen.

Anforderungen an das physische Netzwerk für Azure Stack HCI

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).

Anforderungen an das Hostnetzwerk für Azure Stack HCI

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 in Azure Stack HCI erfordert eine Netzwerkverbindung mit hoher und zuverlässiger Bandbreite sowie geringer Latenz zwischen den einzelnen 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 Stack HCI vereinfacht den Netzwerkentwurf, indem ein virtueller Switch konfiguriert wird, der zur 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 den AKS in Azure Stack HCI-Cluster 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.

Für AKS in Azure Stack HCI stehen mehrere Optionen zum Bereitstellen von Clusternetzwerken zur Verfügung:

  • 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 Hauptaugenmerk beim Netzwerkentwurf für AKS in Azure Stack HCI liegt auf der 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 in Azure Stack HCI die Zuweisung von IP-Adressen 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.

  • Vergewissern Sie sich, dass Netzwerkkonnektivität zwischen Azure Stack HCI-Hosts und den Mandanten-VMs besteht.

  • Aktivieren Sie dynamische DNS-Updates in Ihrer DNS-Umgebung, damit AKS in Azure Stack HCI 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:

    • Nord-Süd-Datenverkehr ist der Datenverkehr von Azure Stack HCI und dem restlichen Netzwerk
      • Verwaltung
      • Compute
      • Stretched Cluster-Datenverkehr zwischen Standorten
    • Ost-West-Datenverkehr innerhalb von Azure Stack HCI:
      • Speicherdatenverkehr einschließlich Livemigration zwischen Knoten im selben Cluster.
      • Ethernet-Switch oder direkte Verbindung.

Modelle für den Speicherdatenverkehr

  • Arbeiten Sie mit mehreren Subnetze und VLANs, um Speicherdatenverkehr in Azure Stack HCI 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 in Azure Stack HCI arbeitet zum Zweck der Hochverfügbarkeit und Fehlertoleranz mit Failoverclustering und Livemigration. 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

  • Schützen Sie den Datenverkehr zwischen Pods mittels Netzwerkrichtlinien in AKS in Azure Stack HCI.
  • Der API-Server in AKS in Azure Stack HCI enthält die Zertifizierungsstelle, die Zertifikate für die Kommunikation zwischen dem Kubernetes-API-Server und kubelet signiert.
  • 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, denn die Abrechnungseinheit für AKS in Azure Stack HCI ist ein virtueller Kern.
  • 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 in Azure Stack HCI. Es kann auf der VM mit Windows 10/11 oder Windows Server installiert werden, die in Azure registriert werden und sich in der gleichen Domäne wie der Azure Stack HCI- oder Windows Server Datacenter-Cluster befinden muss.
  • 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][Azure Arc-fähiger Kubernetes-Dienst], 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 Azure Stack HCI-Plattform vereinfacht auch die Nutzung virtueller Netzwerke für AKS in Azure Stack HCI-Clustern, indem das „zugrunde liegende“ Netzwerk auf hoch verfügbare Weise bereitgestellt wird.

Effiziente Leistung

  • Verwenden Sie für Azure Stack HCI zertifizierte Hardware, um Betriebszeit und Leistung von Anwendungen zu verbessern, Verwaltung und Betrieb zu vereinfachen und die Gesamtkosten zu senken.
  • 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 Bereitstellung von AKS in Azure Stack HCI 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:

Andere Mitwirkende:

Nächste Schritte