Netzwerkkonzepte für Anwendungen in Azure Kubernetes Service (AKS)
Bei einem containerbasierten Ansatz mit Microservices für die Anwendungsentwicklung arbeiten die Anwendungskomponenten zusammen, um die jeweiligen Aufgaben zu verarbeiten. Kubernetes bietet verschiedene Ressourcen, die diese Zusammenarbeit ermöglichen:
- Sie können eine Verbindung mit Anwendungen herstellen und diese intern oder extern verfügbar machen.
- Sie können hochverfügbare Anwendungen erstellen, indem Sie für Ihre Anwendungen einen Lastenausgleich vornehmen.
- Zur Steigerung der Sicherheit können Sie den Fluss des Netzwerkdatenverkehrs in oder zwischen Pods und Knoten beschränken.
- Für komplexere Anwendungen können Sie den eingehenden Datenverkehr für den SSL/TLS-Abschluss oder ein Weiterleiten mehrerer Komponenten konfigurieren.
In diesem Artikel werden die wichtigsten Konzepte vorgestellt, mit denen Sie Netzwerke für Ihre Anwendungen in AKS bereitstellen:
Grundlegendes zu Kubernetes-Netzwerken
Kubernetes verwendet eine virtuelle Netzwerkschicht, um den Zugriff innerhalb und zwischen Ihren Anwendungen oder deren Komponenten zu verwalten:
Kubernetes-Knoten und virtuelles Netzwerk: Kubernetes-Knoten sind mit einem virtuellen Netzwerk verbunden. Durch dieses Setup können Pods (grundlegende Bereitstellungseinheiten in Kubernetes) sowohl eingehende als auch eine ausgehende Konnektivität aufweisen.
kube-proxy-Komponente: kube-proxy wird auf jedem Knoten ausgeführt und ist für die Bereitstellung der erforderlichen Netzwerkfeatures verantwortlich.
In Bezug auf bestimmte Kubernetes-Funktionen:
- Lastenausgleich: Sie können einen Lastenausgleich verwenden, um den Netzwerkdatenverkehr gleichmäßig auf verschiedene Ressourcen zu verteilen.
- Eingangsdatencontroller: Diese erleichtern das Layer-7-Routing, das für die Weiterleitung von Anwendungsdatenverkehr unerlässlich ist.
- Steuerung des ausgehenden Datenverkehrs: Kubernetes ermöglicht es Ihnen, ausgehenden Datenverkehr von Clusterknoten zu verwalten und zu steuern.
- Netzwerkrichtlinien: Diese Richtlinien ermöglichen Sicherheitsmaßnahmen und filtern nach Netzwerkdatenverkehr in Pods.
Im Kontext der Azure-Plattform:
- Azure optimiert virtuelle Netzwerke für AKS-Cluster (Azure Kubernetes Service).
- Das Erstellen eines Kubernetes-Lastenausgleichs in Azure richtet gleichzeitig die entsprechende Azure-Lastenausgleichsressource ein.
- Wenn Sie Netzwerkports für Pods öffnen, konfiguriert Azure automatisch die erforderlichen Regeln für die Netzwerksicherheitsgruppe.
- Azure kann auch externe DNS-Konfigurationen für das HTTP-Anwendungsrouting verwalten, wenn neue Eingangsrouten eingerichtet werden.
Virtuelle Azure-Netzwerke
In AKS können Sie einen Cluster bereitstellen, der eines der folgenden Netzwerkmodelle verwendet:
Kubenet-Netzwerk
Die Netzwerkressourcen werden normalerweise bei der Bereitstellung des AKS-Clusters erstellt und konfiguriert.
Azure Container Networking Interface (CNI)-Netzwerke
Der AKS-Cluster ist mit vorhandenen virtuellen Netzwerkressourcen und -konfigurationen verbunden.
Kubenet-Netzwerke – „Basic“ (Grundlegend)
Die Netzwerkoption kubenet ist die Standardkonfiguration für die AKS-Clustererstellung. Mit kubenet geschieht Folgendes:
- Knoten erhalten eine IP-Adresse aus dem Subnetz des virtuellen Azure-Netzwerks.
- Pods erhalten eine IP-Adresse aus einem logisch anderen Adressraum als dem Subnetz des virtuellen Azure-Netzwerks der Knoten.
- Die Netzwerkadressübersetzung (NAT, Network Address Translation) wird dann so konfiguriert, dass die Pods Ressourcen im virtuellen Azure-Netzwerk erreichen können.
- Die Quell-IP-Adresse des Datenverkehrs wird in die primäre IP-Adresse des Knotens übersetzt.
Knoten verwenden das Kubernetes-Plug-In kubenet. Sie können die Azure-Plattform die virtuellen Netzwerke für Sie erstellen und konfigurieren lassen oder Ihren AKS-Cluster in einem bestehenden Subnetz des virtuellen Netzwerks bereitstellen.
Nur die Knoten erhalten eine routingfähige IP-Adresse. Die Pods verwenden NAT, um mit anderen Ressourcen außerhalb des AKS-Clusters zu kommunizieren. Dieser Ansatz reduziert die Anzahl der IP-Adressen, die Sie in Ihrem Netzwerkadressraum für die Verwendung von Pods reservieren müssen.
Hinweis
Obwohl kubenet die Standardnetzwerkoption für einen AKS-Cluster zum Erstellen eines virtuellen Netzwerks und Subnetzes ist, wird sie nicht für Produktionsbereitstellungen empfohlen. Für die meisten Produktionsbereitstellungen sollten Sie Azure CNI-Netzwerke planen und verwenden, da diese überragende Skalierbarkeit und Leistungsmerkmale aufweisen.
Weitere Informationen finden Sie unter Konfigurieren von kubernet-Netzwerken für AKS-Cluster.
Azure CNI-Netzwerke – „Advanced“ (Erweitert)
Mit Azure CNI erhält jeder Pod eine IP-Adresse aus dem Subnetz und kann direkt angesprochen werden. Diese IP-Adressen müssen im Voraus geplant werden und in Ihrem Netzwerkadressraum eindeutig sein. Jeder Knoten verfügt über einen Konfigurationsparameter für die maximale Anzahl von Pods, die er unterstützt. Die entsprechende Anzahl von IP-Adressen pro Knoten wird dann im Voraus reserviert. Dieser Ansatz kann dazu führen, dass sich bei zunehmenden Anwendungsanforderungen die IP-Adressen erschöpfen oder dass Cluster in einem größeren Subnetz neu erstellt werden müssen. Daher ist eine richtige Planung wichtig. Sie können das Feature Azure CNI-Netzwerk für die dynamische Zuordnung von IP-Adressen und erweiterte Subnetzunterstützung aktivieren, um diese Planungsherausforderungen zu vermeiden.
Hinweis
Aufgrund von Kubernetes-Einschränkungen muss der Name der Ressourcengruppe, der Name des virtuellen Netzwerks und der Subnetzname 63 Zeichen oder kleiner sein.
Anders als bei Kubenet wird der Datenverkehr zu Endpunkten in demselben virtuellen Netzwerk nicht zur primären IP-Adresse des Knotens übersetzt (NAT). Die Quelladresse für den Datenverkehr im virtuellen Netzwerk ist die Pod-IP-Adresse. Datenverkehr außerhalb des virtuellen Netzwerks wird weiterhin per NAT zur primären IP-Adresse des Knotens geleitet.
Knoten verwenden das Kubernetes-Plug-In Azure CNI.
Weitere Informationen finden Sie unter Konfigurieren der Azure CNI für einen AKS-Cluster.
Azure CNI Overlay-Netzwerk
Azure CNI Overlay stellt eine Weiterentwicklung von Azure CNI dar, mit der Skalierbarkeits- und Planungsherausforderungen behoben werden, die sich aus der Zuweisung von virtuelle Netzwerk IP-Adressen zu Pods ergeben. Azure CNI Overlay weist privaten CIDR-IPs zu Pods zu. Die privaten IPs sind vom virtuellen Netzwerk getrennt und können in mehreren Clustern wiederverwendet werden. Azure CNI Overlay kann über die in Kubenet-Clustern erzwungene Grenze von 400 Knoten hinaus skaliert werden. Azure CNI Overlay wird für die meisten Cluster empfohlen.
Azure CNI Powered by Cilium
Azure CNI Powered by Cilium verwendet Cilium, um leistungsstarke Netzwerke, Einblicke und Netzwerkrichtlinienerzwingung bereitzustellen. Es wird nativ in Azure CNI Overlay für die skalierbare IP-Adressverwaltung (IPAM) integriert.
Darüber hinaus erzwingt Cilium standardmäßig Netzwerkrichtlinien, ohne dass ein separates Netzwerkrichtlinienmodul erforderlich ist. Azure CNI Powered by Cilium kann durch die Verwendung von eBPF-Programmen und einer effizienteren API-Objektstruktur über die Azure Network Policy Manager-Grenzwerte von 250 Knoten/20-K-Pod hinaus skaliert werden.
Azure CNI Powered by Cilium wird für Cluster, die die Durchsetzung von Netzwerkrichtlinien erfordern, empfohlen.
Bring Your Own CNI
Es ist möglich, mit dem Feature Bring Your Own CNI in AKS ein Microsoft-fremdes CNI zu installieren.
Vergleich der Netzwerkmodelle
Sowohl kubenet als auch Azure CNI bieten Netzwerkkonnektivität für Ihre AKS-Cluster. Es gibt jedoch jeweils Vor- und Nachteile. Ganz allgemein gelten die folgenden Überlegungen:
kubenet
- Spart IP-Adressraum
- Verwendet den internen oder externen Lastenausgleich von Kubernetes, um die Pods von außerhalb des Clusters zu erreichen.
- Erfordert eine manuelle Verwaltung und Wartung von benutzerdefinierten Routen (UDRs)
- Maximal 400 Knoten pro Cluster
Azure CNI
- Pods erhalten vollständige VM-Konnektivität und können direkt über die private IP-Adresse aus verbundenen Netzwerken erreicht werden.
- Erfordert mehr IP-Adressraum
| Netzwerkmodell | Verwendung |
|---|---|
| Kubenet | • Die Erhaltung des IP-Adressraums hat Priorität. • Einfache Konfiguration. • Weniger als 400 Knoten pro Cluster. • Interne oder externe Kubernetes-Lastenausgleichsmodule, die für das Erreichen von Pods von außerhalb des Clusters ausreichen. • Manuelles Verwalten und Beibehalten benutzerdefinierter Routen ist akzeptabel. |
| Azure CNI | • Für Pods ist vollständige VNET-Konnektivität erforderlich. • Erweiterte AKS-Features (z. B. virtuelle Knoten) sind erforderlich. • Ausreichender IP-Adressraum ist verfügbar. • Pod-zu-Pod- und Pod-zu-Pod-zu-VM-Konnektivität ist erforderlich. • Externe Ressourcen müssen Pods direkt erreichen. • AKS-Netzwerkrichtlinien sind erforderlich. |
| Azure CNI Overlay | • Ein Mangel an IP-Adressen ist ein Problem. • Das Skalieren von bis zu 1.000 Knoten und 250 Pods pro Knoten ist ausreichend. • Zusätzlicher Hop für Podkonnektivität ist akzeptabel. • Einfachere Servernetzwerkkonfiguration. • AKS-Ausgangsanforderungen können erfüllt werden. |
Folgende Unterschiede treten im Verhalten von kubenet und Azure CNI auf:
| Funktion | Kubenet | Azure CNI | Azure CNI Overlay | Azure CNI Powered by Cilium |
|---|---|---|---|---|
| Bereitstellen von Clustern in vorhandenen oder neuen virtuellen Netzwerken | Unterstützt – benutzerdefinierte Routen werden manuell angewandt. | Unterstützt | Unterstützt | Unterstützt |
| Pod-Pod-Konnektivität | Unterstützt | Unterstützt | Unterstützt | Unterstützt |
| Pod-VM-Konnektivität; VM im gleichen virtuellen Netzwerk | Funktioniert, wenn vom Pod initiiert | Funktioniert in beide Richtungen | Funktioniert, wenn vom Pod initiiert | Funktioniert, wenn vom Pod initiiert |
| Pod-VM-Konnektivität; VM in virtuellem Peernetzwerk | Funktioniert, wenn vom Pod initiiert | Funktioniert in beide Richtungen | Funktioniert, wenn vom Pod initiiert | Funktioniert, wenn vom Pod initiiert |
| Lokaler Zugriff per VPN oder ExpressRoute | Funktioniert, wenn vom Pod initiiert | Funktioniert in beide Richtungen | Funktioniert, wenn vom Pod initiiert | Funktioniert, wenn vom Pod initiiert |
| Zugriff auf Ressourcen, die von Dienstendpunkten geschützt werden | Unterstützt | Unterstützt | Unterstützt | |
| Verfügbarmachen von Kubernetes-Diensten über einen Lastenausgleichsdienst, App Gateway oder einen Eingangscontroller | Unterstützt | Unterstützt | Unterstützt | Dieselben Einschränkungen gelten bei Verwendung des Überlagerungsmodus |
| Unterstützung für Windows Knotenpools | Nicht unterstützt | Unterstützt | Unterstützt | Nur für Linux verfügbar. Nicht für Windows. |
| Standard: Azure DNS und private Zonen | Unterstützt | Unterstützt | Unterstützt |
Weitere Informationen zu Azure CNI und kubenet und zur Ermittlung der besten Option finden Sie unter Konfigurieren von Azure CNI-Netzwerken in AKS und Verwenden von kubenet-Netzwerken in AKS.
Supportumfang der Netzwerkmodelle
Unabhängig vom verwendeten Netzwerkmodell können kubenet und Azure CNI mit einer der folgenden Methoden bereitgestellt werden:
- Die Azure-Plattform kann die Ressourcen des virtuellen Netzwerks automatisch erstellen und konfigurieren, wenn Sie einen AKS-Cluster erstellen.
- Sie können die Ressourcen des virtuellen Netzwerks manuell erstellen und konfigurieren und an diese Ressourcen anfügen, wenn Sie Ihren AKS-Cluster erstellen.
Auch wenn Funktionen wie Dienstendpunkte oder benutzerdefinierte Routen (UDRs) mit kubenet und Azure CNI unterstützt werden, legen die Supportrichtlinien für AKS fest, welche Änderungen Sie vornehmen können. Beispiel:
- Wenn Sie die Ressourcen des virtuellen Netzwerks für einen AKS-Cluster manuell erstellen, werden Sie unterstützt, wenn Sie Ihre eigenen benutzerdefinierten Routen oder Dienstendpunkte konfigurieren.
- Wenn die Azure-Plattform die Ressourcen des virtuellen Netzwerks automatisch für Ihren AKS-Cluster erstellt, können Sie diese von AKS verwalteten Ressourcen nicht manuell ändern, um Ihre eigenen benutzerdefinierten Routen oder Dienstendpunkte zu konfigurieren.
Eingangsdatencontroller
Beim Erstellen eines Diensts vom Typ „LoadBalancer“ erstellen Sie auch eine zugrunde liegende Azure Load Balancer-Ressource. Der Load Balancer wird zum Verteilen von Datenverkehr an die Pods in Ihrem Dienst an einem bestimmten Port konfiguriert.
LoadBalancer funktioniert nur in Schicht 4. Auf Schicht 4 hat der Dienst keine Kenntnis von den tatsächlichen Anwendungen und kann keine weiteren Überlegungen zum Netzwerkrouting vornehmen.
Eingangsdatencontroller funktionieren in Schicht 7 und können intelligentere Regeln zum Verteilen des Anwendungsdatenverkehrs verwenden. Eingangscontroller leiten HTTP-Datenverkehr in der Regel auf Grundlage der eingehenden URL an verschiedene Anwendungen weiter.
Vergleichen von Eingangsoptionen
In der folgenden Tabelle sind die Funktionsunterschiede zwischen den verschiedenen Eingangscontrolleroptionen aufgeführt:
| Funktion | Anwendungsrouting-Add-On | Application Gateway für Container | Azure Service Mesh/Istio-basiertes Dienstnetz |
|---|---|---|---|
| Eingangs-/Gatewaycontroller | NGINX-Eingangscontroller | Azure Application Gateway für Containers | Istio Ingress Gateway |
| API | Eingehende API | Ingress-API und Gateway-API | Gateway-API |
| Hosting | Im Cluster | In Azure gehostet | Im Cluster |
| Skalieren | Automatische Skalierung | Automatische Skalierung | Automatische Skalierung |
| Lastenausgleich | Intern/extern | Extern | Intern/extern |
| SSL-Terminierung | Im Cluster | Ja: Offboarding und E2E SSL | Im Cluster |
| mTLS | N/V | Ja zum Back-End | N/V |
| Statische IP-Adresse | N/V | FQDN | N/V |
| In Azure Key Vault gespeicherte SSL-Zertifikate | Ja | Ja | N/V |
| Azure DNS-Integration für die DNS-Zonenverwaltung | Ja | Ja | N/V |
In der folgenden Tabelle sind die verschiedenen Szenarien aufgeführt, in denen Sie die einzelnen Eingangscontroller verwenden können:
| Eingangsoptionen | Einsatzgebiete |
|---|---|
| Verwaltetes NGINX: Anwendungsrouting-Add-On | • Im Cluster gehostete, anpassbare und skalierbare NGINX-Eingangscontroller. • Grundlegende Lastenausgleichs- und Routingfunktionen. • Interne und externe Lastenausgleichskonfiguration. • Konfiguration der öffentlichen IP-Adresse. • Integration in Azure Key Vault für die Zertifikatverwaltung. • Integration in Azure DNS für die Verwaltung öffentlicher und privater Zone. • Unterstützt die Ingress-API. |
| Application Gateway für Container | • Von Azure gehostetes Eingangsgateway. • Flexible Bereitstellungsstrategien, die vom Controller verwaltet werden oder Ihr eigenes Anwendungsgateway für Container. • Erweiterte Datenverkehrsverwaltungsfunktionen wie automatische Wiederholungen, Ausfallsicherheit der Verfügbarkeitszone, gegenseitige Authentifizierung (mTLS) zum Back-End-Ziel, Datenverkehrsaufteilung/gewichteter Roundrobin und automatische Skalierung. • Integration in Azure Key Vault für die Zertifikatverwaltung. • Integration in Azure DNS für die Verwaltung öffentlicher und privater Zone. • Unterstützt die Ingress- und Gateway-APIs. |
| Istio Ingress Gateway | • Basierend auf Envoy, bei Verwendung mit Istio für ein Dienstnetz. • Erweiterte Datenverkehrsverwaltungsfunktionen wie Geschwindigkeitsbegrenzung und Verbindungsunterbrechung. • Unterstützung für mTLS • Unterstützung für die Gateway-API. |
Erstellen einer Eingangsressource
Das Anwendungsrouting-Add-On ist die empfohlene Methode zum Konfigurieren eines Eingangsdatencontrollers in AKS. Das Anwendungsrouting-Add-On ist ein vollständig verwalteter Eingangsdatencontroller für Azure Kubernetes Service (AKS), der die folgenden Funktionen bereitstellt:
Einfache Konfiguration von verwalteten NGINX-Eingangsdatencontrollern basierend auf NGINX-Eingangsdatencontrollern für Kubernetes
Integration in Azure DNS für die Verwaltung öffentlicher und privater Zone.
SSL-Beendigung mit Zertifikaten, die in Azure Key Vault gespeichert sind
Weitere Informationen zum Anwendungsrouting-Add-On finden Sie unter Verwalteter NGINX-Eingang mit dem Anwendungsrouting-Add-On.
Beibehaltung der Clienquell-IP
Konfigurieren Sie den Eingangscontroller so, dass die Quell-IP des Clients bei Anforderungen an Container im AKS-Cluster beibehalten wird. Wenn der Eingangscontroller die Anforderung eines Clients an einen Container im AKS-Cluster weiterleitet, ist die ursprüngliche Quell-IP dieser Anforderung für den Zielcontainer nicht verfügbar. Wenn Sie die Beibehaltung der Clientquell-IP aktivieren, ist die Quell-IP für den Client im Anforderungsheader unter X-Forwarded-For verfügbar.
Wenn Sie die Beibehaltung der Clientquell-IP auf dem Eingangscontroller verwenden, können Sie kein TLS-Pass-Through verwenden. Die Beibehaltung der Clientquell-ID und TLS-Pass-Through-können mit anderen Diensten verwendet werden, z. B. dem LoadBalancer-Typ.
Weitere Informationen zur Beibehaltung der Clientquell-IP finden Sie unter Netzwerkkonzepte für Anwendungen in Azure Kubernetes Service (AKS).
Steuern des ausgehenden Datenverkehrs
AKS-Cluster werden in einem virtuellen Netzwerk bereitgestellt und weisen ausgehende Abhängigkeiten von Diensten außerhalb dieses virtuellen Netzwerks auf. Diese ausgehenden Abhängigkeiten werden fast vollständig mit vollqualifizierten Domänennamen (FQDNs) definiert. Standardmäßig verfügen AKS-Cluster über uneingeschränkten ausgehenden Internetzugriff, sodass die von Ihnen ausgeführten Knoten und Dienste bei Bedarf auf externe Ressourcen zugreifen können. Nötigenfalls können Sie den ausgehenden Datenverkehr einschränken.
Weitere Informationen finden Sie unter Steuern des ausgehenden Datenverkehrs für Clusterknoten in Azure Kubernetes Service (AKS).
Netzwerksicherheitsgruppen
Eine Netzwerksicherheitsgruppe filtert den Datenverkehr für virtuelle Computer wie die AKS-Knoten. Beim Erstellen von Diensten (z. B. LoadBalancer) konfiguriert die Azure-Plattform automatisch alle erforderlichen Netzwerksicherheitsgruppen-Regeln.
Sie müssen Netzwerksicherheitsgruppen-Regeln nicht manuell konfigurieren, um den Datenverkehr für Pods in einem AKS-Cluster zu filtern. Sie können alle erforderlichen Ports und die Weiterleitung im Rahmen Ihrer Kubernetes-Dienstmanifeste definieren und das Erstellen oder Aktualisieren der entsprechenden Regeln der Azure-Plattform überlassen.
Sie können auch Netzwerkrichtlinien verwenden, um automatisch Filterregeln für den Datenverkehr auf Pods anzuwenden.
Weitere Informationen finden Sie unter Filtern von Netzwerkdatenverkehr mit Netzwerksicherheitsgruppen.
Netzwerkrichtlinien
Standardmäßig können alle Pods in einem AKS-Cluster Datenverkehr ohne Einschränkungen senden und empfangen. Aus Sicherheitsgründen definieren Sie Regeln, die den Datenverkehrsfluss steuern, z. B.:
- Back-End-Anwendungen werden nur für erforderliche Front-End-Dienste verfügbar gemacht.
- Datenbankkomponenten sind nur für die Anwendungsebenen zugänglich, die eine Verbindung damit herstellen.
Netzwerkrichtlinien sind ein in AKS verfügbares Kubernetes-Feature, mit dem Sie den Datenverkehrsfluss zwischen Pods steuern können. Anhand von Einstellungen wie zugewiesene Bezeichnungen, Namespace oder Port für den Datenverkehr können Sie Datenverkehr zulassen oder verweigern. Während Netzwerksicherheitsgruppen für AKS-Knoten besser geeignet sind, stellen Netzwerkrichtlinien eine geeignetere cloudnative Methode zum Steuern des Datenverkehrsflusses für Pods dar. Wenn Pods in einem AKS-Cluster dynamisch erstellt werden, können erforderliche Netzwerkrichtlinien automatisch angewendet werden.
Weitere Informationen finden Sie unter Sicherer Datenverkehr zwischen Pods durch Netzwerkrichtlinien in Azure Kubernetes Service (AKS).
Nächste Schritte
Um mit AKS-Netzwerken zu beginnen, erstellen und konfigurieren Sie einen AKS-Cluster mit Ihren eigenen IP-Adressbereichen unter Verwendung von kubenet oder Azure CNI.
Entsprechende bewährte Methoden finden Sie unter Best Practices für Netzwerkkonnektivität und Sicherheit in AKS.
Weitere Informationen zu den wesentlichen Konzepten von Kubernetes und AKS finden Sie in den folgenden Artikeln: