Überlegungen zur Netzwerktopologie und -konnektivität für AKS

Überlegungen zum Entwurf

Azure Kubernetes Service (AKS) bietet drei verschiedene Netzwerkmodelle für Containernetzwerke: Kubenet, CNI Overlay und CNI. Jedes dieser Modelle verfügt über einzigartige Features und Vorteile, die Flexibilität und Skalierbarkeitsoptionen für Containernetzwerke in AKS bieten.

Kubenet

Kubenet ist eine grundlegende Netzwerklösung, die IP-Adressraum spart und eine einfache Konfiguration ermöglicht. Dies ist ideal für kleine AKS-Cluster mit weniger als 400 Knoten, bei denen die manuelle Verwaltung und Beibehaltung benutzerdefinierter Routen akzeptabel ist. Es eignet sich für Szenarien, in denen interne oder externe Lastenausgleichsmodule ausreichen, um Pods von außerhalb des Clusters zu erreichen.

Azure CNI

Azure CNI ist ein Netzwerkmodell, das für erweiterte Netzwerke entwickelt wurde. Es bietet vollständige VNET-Konnektivität für Pods und ermöglicht Pod-zu-Pod- und Pod-zu-VM-Konnektivität. Somit ist es ideal für Szenarien, in denen erweiterte AKS-Features wie virtuelle Knoten erforderlich sind. Es eignet sich für Szenarien, in denen ausreichend IP-Adressraum verfügbar ist und externe Ressourcen Pods direkt erreichen müssen. AKS-Netzwerkrichtlinien werden auch mit Azure CNI unterstützt.

Azure CNI Overlay

Azure CNI Overlay wurde entwickelt, um IP-Adressengpässe zu beheben und die Netzwerkkonfiguration zu vereinfachen. Es eignet sich für Szenarien, in denen die Skalierung von bis zu 1000 Knoten und 250 Pods pro Knoten ausreicht und ein zusätzlicher Hop für die Podkonnektivität akzeptabel ist. Anforderungen an den ausgehenden AKS-Datenverkehr können auch mit Azure CNI Overlay erfüllt werden.

Eine Zusammenfassung der empfohlenen Anwendungsfälle pro Netzwerkmodell finden Sie unter Vergleichen von Netzwerkmodellen in AKS.

Darüber hinaus ist es beim Entwerfen Ihres AKS-Clusters wichtig, die IP-Adressierung und die Größe des Subnetzes des virtuellen Netzwerks sorgfältig zu planen, um die Skalierung zu unterstützen. Virtuelle Knoten können für eine schnelle Clusterskalierung verwendet werden, aber es gibt einige bekannte Einschränkungen.

AKS-Cluster unterstützen SKUs vom Typ Basic und Standard Azure Load Balancer, und Dienste können mit öffentlichen oder internen Lastenausgleichsmodulen verfügbar gemacht werden. AKS verwendet CoreDNS, um die Namensauflösung für Pods bereitzustellen, die im Cluster ausgeführt werden, und ausgehender Netzwerkdatenverkehr kann über eine Azure Firewall oder ein virtuelles Anwendung-Cluster im Netzwerk gesendet werden.

Standardmäßig können alle Pods in einem AKS-Cluster Datenverkehr ohne Einschränkungen senden und empfangen. Kubernetes-Netzwerkrichtlinien können jedoch verwendet werden, um die Sicherheit zu verbessern und den Datenverkehr zwischen Pods in einem AKS-Cluster zu filtern. Für AKS stehen zwei Netzwerkrichtlinienmodelle zur Verfügung: Azure-Netzwerkrichtlinien und Calico.

AKS richtet schließlich eine Netzwerksicherheitsgruppe (NSG) in dem Subnetz ein, in dem der Cluster bereitgestellt wird. Es wird empfohlen, diese NSG nicht manuell zu bearbeiten, aber in AKS bereitgestellte Dienste können sie beeinflussen.

Insgesamt können die Auswahl des geeigneten Netzwerkmodells und die sorgfältige Planung von Netzwerkressourcen dazu beitragen, die Leistung, Sicherheit und Kosten Ihres AKS-Clusters zu optimieren.

Private Cluster

Die IP-Sichtbarkeit des AKS-Clusters kann entweder öffentlich oder privat sein. Private Cluster machen die Kubernetes-API über eine private IP-Adresse verfügbar, aber nicht über eine öffentliche IP-Adresse. Diese private IP-Adresse wird im virtuellen AKS-Netzwerk durch einen privaten Endpunkt dargestellt. Der Zugriff auf die Kubernetes-API sollte nicht über die IP-Adresse, sondern über den vollqualifizierten Domänennamen (FQDN) erfolgen. Die Auflösung vom FQDN der Kubernetes-API zu ihrer IP-Adresse wird in der Regel von einer Zone mit privatem Azure-DNS ausgeführt. Diese DNS-Zone kann von Azure in der AKS-Knotenressourcengruppeerstellt werden, oder Sie können eine vorhandene DNS-Zone angeben.

In Anlehnung an bewährte Methoden auf Unternehmensebene wird die DNS-Auflösung für Azure-Workloads von zentralisierten DNS-Servern angeboten, die im Konnektivitätsabonnement bereitgestellt werden, entweder in einem virtuellen Hubnetzwerk oder in einem virtuellen Netzwerk mit gemeinsam genutzten Diensten, das mit einer Azure Virtual WAN-Instanz verbunden ist. Diese Server lösen bedingt Azure-spezifische und öffentliche Namen mithilfe von Azure DNS (IP-Adresse 168.63.129.16) sowie private Namen mithilfe von DNS-Unternehmensservern auf. Diese zentralen DNS-Server sind jedoch nicht in der Lage, den FQDN der AKS-API aufzulösen, solange sie nicht mit der für den AKS-Cluster erstellten privaten DNS-Zone verbunden sind. Jede AKS-Instanz erhält eine eindeutige private DNS-Zone, da dem Zonennamen eine zufällige GUID vorangestellt ist. Daher sollte für jeden neuen AKS-Cluster die zugehörige private DNS-Zone mit dem virtuellen Netzwerk verbunden werden, in dem sich die zentralen DNS-Server befinden.

Alle virtuellen Netzwerke sollten so konfiguriert werden, dass sie diese zentralen DNS-Server zur Namensauflösung verwenden. Wenn das virtuelle AKS-Netzwerk jedoch so konfiguriert ist, dass es die zentralen DNS-Server verwendet, und diese DNS-Server noch nicht mit der privaten DNS-Zone verbunden sind, können die AKS-Knoten den FQDN der Kubernetes-API nicht auflösen, und bei der Erstellung des AKS-Clusters tritt ein Fehler auf. Das virtuelle AKS-Netzwerk sollte erst nach der Erstellung des Clusters so konfiguriert werden, dass es die zentralen DNS-Server verwendet.

Sobald der Cluster erstellt ist, wird die Verbindung zwischen der privaten DNS-Zone und dem virtuellen Netzwerk erstellt, in dem die zentralen DNS-Server bereitgestellt werden. Das virtuelle AKS-Netzwerk wurde ebenfalls so konfiguriert, dass es die zentralen DNS-Server im Konnektivitätsabonnement verwendet, und der Administratorzugriff auf die AKS-Kubernetes-API folgt dem folgenden Flow:

Hinweis

Die Abbildungen in diesem Artikel spiegeln den Entwurf unter Verwendung des traditionellen Hub-and-Spoke-Konnektivitätsmodells wider. Zielzonen auf Unternehmensebene können sich für das Virtual WAN-Konnektivitätsmodell entscheiden, bei dem sich die zentralen DNS-Server in einem virtuellen Netzwerk mit gemeinsam genutzten Diensten befinden, das mit einem Virtual WAN-Hub verbunden ist.

1. Der Administrator löst den FQDN der Kubernetes-API auf. Die lokalen DNS-Server leiten die Anforderung an die autorisierenden Server weiter – die DNS-Resolver in Azure. Diese Server leiten die Anforderung an den Azure DNS-Server (168.63.129.16) weiter, der die IP-Adresse aus der Zone mit privatem Azure-DNS abruft.
2. Nach der Auflösung der IP-Adresse wird der Datenverkehr zur Kubernetes-API je nach Konnektivitätsmodell vom lokalen Standort zum VPN- oder ExpressRoute-Gateway in Azure geleitet.
3. Der private Endpunkt hat eine /32-Route im virtuellen Hubnetzwerk eingeführt. Die VPN- und ExpressRoute-Gateways senden den Datenverkehr direkt an den privaten Kubernetes-API-Endpunkt, der im virtuellen AKS-Netzwerk bereitgestellt wird.

Datenverkehr von Anwendungsbenutzer*innen zum Cluster

Eingangsdatencontroller können verwendet werden, um in den AKS-Clustern ausgeführte Anwendungen verfügbar zu machen.

• Eingangsdatencontroller bieten Routing auf Anwendungsebene auf Kosten einer leichten Zunahme der Komplexität.
• Eingangsdatencontroller können die WAF-Funktionalität (Web Application Firewall) integrieren.
• Eingangsdatencontroller können außerhalb und innerhalb von Clustern ausgeführt werden:
  • Ein außerhalb des Clusters ausgeführter Eingangsdatencontroller verlagert die Compute-Instanz (z. B. HTTP-Routing von Datenverkehr oder TLS-Abschluss) auf einen anderen Dienst außerhalb von AKS, z. B. auf das AGIC-Add-On (Azure Application Gateway Ingress Controller).
  • Eine im Cluster ausgeführte Lösung beansprucht AKS-Clusterressourcen für die Compute-Instanz (z. B. HTTP-Routing von Datenverkehr oder TLS-Abschluss). Innerhalb des Clusters ausgeführte Eingangsdatencontroller können niedrigere Kosten bieten, aber sie erfordern eine sorgfältige Ressourcenplanung und Wartung.
• Das grundlegende Add-On für das HTTP-Anwendungsrouting ist zwar benutzerfreundlich, besitzt aber einige Einschränkungen, wie unter HTTP-Anwendungsrouting dokumentiert.

Eingangsdatencontroller können Anwendungen und APIs mit einer öffentlichen oder einer privaten IP-Adresse verfügbar machen.

• Die Konfiguration sollte auf den Entwurf der Filterung in ausgehender Richtung abgestimmt sein, um asymmetrisches Routing zu vermeiden. UDRs können (unter Umständen), aber nicht zwingend, zu asymmetrischem Routing führen. Application Gateway kann SNAT auf Datenverkehr anwenden, d. h., dass der zurückkehrende Datenverkehr an den Application Gateway-Knoten und nicht an die UDR-Route zurückgeleitet wird, wenn UDR nur für Internetdatenverkehr eingerichtet ist.
• Wenn ein TLS-Abschluss erforderlich ist, muss die Verwaltung von TLS-Zertifikaten berücksichtigt werden.

Der Datenverkehr der Anwendung kann entweder von lokalen Standorten oder aus dem öffentlichen Internet stammen. In der folgenden Abbildung wird ein Beispiel beschrieben, in dem ein Azure Application Gateway für Reverseproxy-Verbindungen zu den Clustern sowohl von lokalen Standorten als auch vom öffentlichen Internet aus konfiguriert ist.

Der Datenverkehr von lokalen Standorten folgt dem Ablauf der nummerierten blauen Legenden im vorherigen Diagramm.

1. Der Client löst den der Anwendung zugewiesenen FQDN auf, entweder mithilfe der im Konnektivitätsabonnement bereitgestellten DNS-Server oder mithilfe lokaler DNS-Server.
2. Nach der Auflösung des FQDN der Anwendung in eine IP-Adresse (die private IP-Adresse des Anwendungsgateways) wird der Datenverkehr über ein VPN- oder ExpressRoute-Gateway geleitet.
3. Das Routing im Gatewaysubnetz ist so konfiguriert, dass die Anforderung an die Web Application Firewall gesendet wird.
4. Die Web Application Firewall sendet gültige Anforderungen an die Workload, die im AKS-Cluster ausgeführt wird.

Das Azure Application Gateway kann in diesem Beispiel in demselben Abonnement wie der AKS-Cluster bereitgestellt werden, da dessen Konfiguration eng mit den in AKS bereitgestellten Workloads verbunden ist und daher vom gleichen Anwendungsteam verwaltet wird. Der Zugriff aus dem Internet folgt dem Ablauf der nummerierten grünen Legenden im vorherigen Diagramm.

1. Clients aus dem öffentlichen Internet lösen den DNS-Namen für die Anwendung mithilfe von Azure Traffic Manager auf. Alternativ können auch andere globale Lastenausgleichstechnologien wie Azure Front Door verwendet werden.
2. Der öffentliche FQDN der Anwendung wird von Traffic Manager in die öffentliche IP-Adresse des Anwendungsgateways aufgelöst, auf das die Clients über das öffentliche Internet zugreifen.
3. Das Anwendungsgateway greift auf die in AKS bereitgestellte Workload zu.

Hinweis

Diese Flows sind nur für Webanwendungen gültig. Nicht-Webanwendungen sind nicht Gegenstand dieses Artikels. Sie können über die Azure Firewall im virtuellen Hubnetzwerk oder den sicheren virtuellen Hub verfügbar gemacht werden, wenn Sie das Virtual WAN-Konnektivitätsmodell verwenden.

Alternativ kann der Datenverkehr für webbasierte Anwendungen so gestaltet werden, dass er sowohl die Azure Firewall im Konnektivitätsabonnement als auch die WAF im virtuellen AKS-Netzwerk durchläuft. Dieser Ansatz hat den Vorteil, dass er einen etwas höheren Schutz bietet, z. B. mithilfe der auf Azure Firewall-Intelligence basierenden Filterung, um Datenverkehr von bekannten schädlichen IP-Adressen im Internet abzuweisen. Dies hat jedoch auch einige Nachteile. Beispielsweise den Verlust der ursprünglichen Client-IP-Adresse und die zusätzliche Koordination zwischen Firewall und Anwendungsteams, wenn Anwendungen verfügbar gemacht werden. Dies liegt daran, dass in der Azure Firewall entsprechende DNAT-Regeln (Destination Network Address Translation) erforderlich sind.

Datenverkehr von den AKS-Pods zu den Back-End-Diensten

Die innerhalb des AKS-Clusters ausgeführten Pods müssen möglicherweise auf Back-End-Dienste wie Azure Storage, Azure SQL-Datenbanken oder Azure Cosmos DB NoSQL-Datenbanken zugreifen. VNet-Dienstendpunkte und Private Link können verwendet werden, um die Konnektivität zu diesen verwalteten Azure-Diensten zu sichern.

Wenn Sie private Azure-Endpunkte für den Datenverkehr im Back-End verwenden, kann die DNS-Auflösung für die Azure-Dienste mithilfe von Zonen mit privatem Azure-DNS erfolgen. Da sich die DNS-Konfliktlöser für die gesamte Umgebung im virtuellen Hubnetzwerk befinden (oder im virtuellen Netzwerk der gemeinsam genutzten Dienste, wenn Sie das Virtual WAN-Konnektivitätsmodell verwenden), sollten diese privaten Zonen im Konnektivitätsabonnement erstellt werden. Zur Erstellung des A-Eintrags, der zur Auflösung des FQDN des privaten Diensts erforderlich ist, können Sie die private DNS-Zone (im Konnektivitätsabonnement) dem privaten Endpunkt (im Anwendungsabonnement) zuordnen. Dieser Vorgang erfordert bestimmte Berechtigungen in diesen Abonnements.

Es ist zwar möglich, die A-Einträge manuell zu erstellen, aber die Zuordnung der privaten DNS-Zone zum privaten Endpunkt führt zu einer Einrichtung, die weniger anfällig für Fehlkonfigurationen ist.

Die Back-End-Konnektivität von AKS-Pods zu Azure PaaS-Diensten, die über private Endpunkte verfügbar gemacht werden, folgt dieser Sequenz:

1. Die AKS-Pods lösen den FQDN von Azure PaaS (Platform-as-a-Service) mithilfe der zentralen DNS-Server im Konnektivitätsabonnement auf, die als benutzerdefinierte DNS-Server im virtuellen AKS-Netzwerk definiert sind.
2. Die aufgelöste IP-Adresse ist die private IP-Adresse der privaten Endpunkte, auf die direkt von den AKS-Pods zugegriffen wird.

Der Datenverkehr zwischen den AKS-Pods und den privaten Endpunkten verläuft standardmäßig nicht durch die Azure Firewall im virtuellen Hubnetzwerk (oder des sicheren virtuellen Hubs, wenn Sie Virtual WAN verwenden), selbst wenn der AKS-Cluster für die Filterung in ausgehender Richtung mit Azure Firewall konfiguriert ist. Der Grund dafür ist, dass der private Endpunkt eine /32-Route in den Subnetzen des virtuellen Netzwerks der Anwendung erstellt, in denen AKS bereitgestellt wird.

Entwurfsempfehlungen

• Wenn Ihre Sicherheitsrichtlinie vorschreibt, die Kubernetes-API mit einer privaten IP-Adresse (statt einer öffentlichen IP-Adresse) zu verwenden, stellen Sie einen privaten AKS-Cluster bereit.
  • Verwenden Sie beim Erstellen eines privaten Clusters benutzerdefinierte private DNS-Zonen, anstatt eine private DNS-Zone des Systems für den Erstellungsprozess zu verwenden.
• Verwenden Sie Azure Container Networking Interface (CNI) als Netzwerkmodell, es sei denn, Sie verfügen nur über einen begrenzten Bereich von IP-Adressen, die dem AKS-Cluster zugewiesen werden können.
  • Beachten Sie die Dokumentation bezüglich der IP-Adressplanung mit CNI.
  • Informationen zum Überprüfen möglicher Einschränkungen mithilfe von Windows Server-Knotenpools und virtuellen Knoten finden Sie unter Häufig gestellte Fragen zur Windows-Unterstützung in AKS.
• Schützen Sie das für den AKS-Cluster verwendete virtuelle Netzwerk mit Azure DDoS Protection, es sei denn, Sie verwenden Azure Firewall oder eine WAF in einem zentralisierten Abonnement.
• Verwenden Sie die DNS-Konfiguration in Verbindung mit der gesamten Netzwerkeinrichtung mit Azure Virtual WAN oder Hub-and-Spoke-Architektur, Azure DNS-Zonen und Ihrer eigenen DNS-Infrastruktur.
• Verwenden Sie Private Link, um Netzwerkverbindungen zu sichern und private IP-basierte Konnektivität zu anderen verwendeten verwalteten Azure-Diensten zu verwenden, die Private Link unterstützen, wie Azure Storage, Azure Container Registry, Azure SQL-Datenbank und Azure Key Vault.
• Verwenden Sie einen Eingangsdatencontroller, um erweitertes HTTP-Routing und Sicherheit sowie einen einzelnen Endpunkt für Anwendungen bereitzustellen.
• Alle Webanwendungen, die für die Verwendung eines Eingangsdatencontrollers konfiguriert sind, sollten TLS-Verschlüsselung verwenden und keinen Zugriff über unverschlüsseltes HTTP zulassen. Diese Richtlinie wird bereits durchgesetzt, wenn das Abonnement die in Richtlinien in Referenzimplementierungen von Landebereichen im Unternehmensmaßstab empfohlenen Richtlinien enthält.
• Wenn Sie die Compute- und Speicherressourcen Ihres AKS-Clusters schonen möchten, können Sie einen außerhalb des Clusters ausgeführten Eingangsdatencontroller verwenden.
  • Verwenden Sie das Add-On Azure Application Gateway Ingress Controller (AGIC), bei dem es sich um einem vom Erstanbieter verwalteten Azure-Dienst handelt.
  • Mit AGIC stellen Sie ein dediziertes Azure Application Gateway für jeden AKS-Cluster bereit und nutzen nicht dasselbe Application Gateway für mehrere AKS-Cluster.
  • Wenn es keine Einschränkungen hinsichtlich Ressourcen oder Betrieb gibt oder AGIC die erforderlichen Features nicht bietet, verwenden Sie einen innerhalb des Clusters ausgeführten Eingangsdatencontroller wie NGINX, Traefik oder eine andere von Kubernetes unterstützte Lösung.
• Verwenden Sie für sicherheitskritische oder internetseitige interne Webanwendungen eine Web Application Firewall mit dem Eingangsdatencontroller.
  • Zum Schutz von webbasierten Anwendungen sind Azure Application Gateway und Azure Front Door beide mit der Azure Web Application Firewall integriert.
• Wenn Ihre Sicherheitsrichtlinie die Überprüfung des gesamten vom AKS-Cluster ausgehenden Internetdatenverkehrs vorschreibt, schützen Sie den ausgehenden Netzwerkdatenverkehr mithilfe von Azure Firewall oder einem virtuellen Netzwerkgerät (Network Virtual Appliance, NVA) eines Drittanbieters, das im (verwalteten) virtuellen Hubnetzwerk verwendet wird. Weitere Informationen finden Sie unter Einschränken des ausgehenden Datenverkehrs. Der ausgehende AKS-Typ UDR erfordert das Zuordnen einer Routingtabelle zum AKS-Knotensubnetz, sodass es derzeit nicht mit der dynamischen Routeninjektion verwendet werden kann, die von Azure Virtual WAN und Azure Route Server unterstützt wird.
• Verwenden Sie für nicht private Cluster autorisierte IP-Adressbereiche.
• Verwenden Sie die Standardebene von Azure Load Balancer anstelle der Basic-Ebene.
• Beim Entwerfen eines Kubernetes-Clusters in Azure ist eine der wichtigsten Überlegungen die Auswahl des geeigneten Netzwerkmodells für Ihre spezifischen Anforderungen. Azure Kubernetes Service (AKS) bietet drei verschiedene Netzwerkmodelle: Kubenet, Azure CNI und Azure CNI Overlay. Um eine fundierte Entscheidung zu treffen, ist es wichtig, die Funktionen und Merkmale jedes Modells zu verstehen.

Einen Funktionsvergleich zwischen den drei Netzwerkmodellen in AKS – Kubenet, Azure CNI und Azure CNI Overlay – finden Sie unter Vergleichen von Netzwerkmodellen in AKS.