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:
- Überlagerungsnetzwerkmodell: Überlagerungsnetzwerke sind das am häufigsten verwendete Netztechnologiemodell in Kubernetes. Pods erhalten eine IP-Adresse von einem privaten, logisch getrennten CIDR vom Subnetz des virtuellen Azure-Netzwerks, in dem AKS-Knoten bereitgestellt werden. Dieses Modell ermöglicht eine einfachere, verbesserte Skalierbarkeit im Vergleich zum flachen Netzwerkmodell.
- Flaches Netzwerkmodell: Ein flaches Netzwerkmodell in AKS weist Pods die IP-Adressen von einem Subnetz aus demselben virtuellen Azure-Netzwerk wie die AKS-Knoten zu. Der gesamte Datenverkehr, der Ihre Cluster verlässt, wird nicht per SNAT behandelt, und die Pod-IP-Adresse wird direkt für das Ziel verfügbar gemacht. Dieses Modell kann für Szenarios wie das Verfügbarmachen von Pod-IP-Adressen für externe Dienste nützlich sein.
Weitere Informationen zu Netzwerkmodellen in AKS finden Sie unter CNI-Netztechnologie in AKS.
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: