Hinweis
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, sich anzumelden oder das Verzeichnis zu wechseln.
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, das Verzeichnis zu wechseln.
Vorsicht
Der Kubernetes SIG Network und der Sicherheitsreaktionsausschuss kündigte die bevorstehende Einstellung des Projekts Ingress NGINX an, wobei die Wartung im März 2026 endet. Für AKS-Cluster, die das Anwendungsrouting-Add-on mit NGINX verwenden, ist heute keine sofortige Aktion erforderlich. Microsoft wird offizielle Unterstützung für kritische Sicherheitspatches für NGINX Ingress-Ressourcen für das Anwendungsrouting bis November 2026 bereitstellen.
AKS passt sich dem Upstream-Kubernetes an, indem es auf Gateway-API als langfristigen Standard für Ingress und L7-Traffic-Management wechselt. Wir empfehlen Ihnen, ihren Migrationspfad basierend auf Ihrem aktuellen Setup zu planen:
- Benutzer des Add-on Application Routing: Produktions-Workloads werden noch bis November 2026 vollständig unterstützt. Migrieren Sie auf die Application Routing Gateway API-Implementierung für eine Gateway API-basierte Verwaltung des Datenverkehrs im Eingang.
-
OSS NGINX-Benutzer haben mehrere Optionen:
- Migrieren Sie zum Anwendungsrouting-Add-On mit NGINX , um von offiziellem Support bis November 2026 zu profitieren, während Sie Ihre langfristige Gateway-API-Migration planen.
- Migrieren Sie auf die Application Routing Gateway API-Implementierung für eine Gateway API-basierte Verwaltung des Datenverkehrs im Eingang.
- Migrieren Sie zu Anwendungsgateway für Container, die sowohl die Ingress-API als auch die Gateway-API unterstützen.
- Dienstgitterbenutzer: Wenn Sie ein Dienstgitter einführen möchten, berücksichtigen Sie das Istio-basierte Dienstgitter-Add-On. Verwenden Sie Istio Ingress heute, und planen Sie die Migration zur Istio-Gateway-API, die jetzt GA ist.
Die Eingangssteuerung in AKS ist eine Kubernetes-Ressource, die den Zugriff des externen HTTP-ähnlichen Datenverkehrs auf Dienste innerhalb eines Clusters verwaltet. Die AKS-Eingangssteuerung kann Dienste wie Lastenausgleich, SSL-Beendigung und namensbasiertes virtuelles Hosting bereitstellen. Weitere Informationen über die Kubernetes-Eingangssteuerung finden Sie in der Dokumentation zur Kubernetes-Eingangssteuerung.
Beginnen Sie für die meisten Produktionsworkloads mit AKS Automatic. AKS Automatic ist der empfohlene produktionsbereite Standardwert in AKS und bietet verwaltete Standardwerte für Netzwerk, Skalierung, Sicherheit, Überwachung und Upgrades. Dies bedeutet, dass Sie mit dem verwalteten Eingangspfad beginnen und nur zu spezielleren Optionen wechseln können, wenn Sie eine tiefere Kontrolle über Topologie, Routingverhalten oder Dienstgitterintegration benötigen.
Verwenden Sie AKS Standard, wenn Sie eine explizitere Kontrolle über die Auswahl des Eingangscontrollers, die Bereitstellungstopologie oder die erweiterte Netzwerkintegration benötigen.
AKS-Clustermodi und Ingress
AKS unterstützt zwei Clustermodi:
- AKS Automatic: Empfohlener Ausgangspunkt für die meisten Produktionsworkloads. Dies reduziert den Betriebsaufwand und bietet Ihnen vorkonfigurierte Standardwerte für Ingress und zugehörige Netzwerkkomponenten.
- AKS Standard: Am besten geeignet, wenn Sie eine direkte Kontrolle über das Hosting des eingehenden Controllers, die Dienstbereitstellung und erweiterte Muster für die Datenverkehrssteuerung benötigen.
Der Eingangsleitfaden in diesem Artikel gilt für beide Modi. Der Hauptunterschied besteht darin, wer mehr der Plattformstandardwerte besitzt und wie viel Anpassung Sie direkt verwalten müssen.
Eingangscontroller
Beim Verwalten von Anwendungsdatenverkehr bieten Eingangscontroller erweiterte Funktionen, indem sie auf Ebene 7 arbeiten. Sie können HTTP-Datenverkehr basierend auf der eingehenden URL an verschiedene Anwendungen weiterleiten, sodass intelligentere und flexiblere Datenverkehrsverteilungsregeln möglich sind. Beispielsweise kann ein Eingangscontroller abhängig vom URL-Pfad den Datenverkehr an verschiedene Microservices leiten und so die Effizienz und Organisation Ihrer Dienste verbessern.
Wird dagegen ein Dienst des Typs „LoadBalancer“ (Lastenausgleich) erstellt, wird eine zugrunde liegende Azure Load Balancer-Ressource eingerichtet. Dieser Lastenausgleich funktioniert auf Ebene 4 und verteilt Datenverkehr an die Pods in Ihrem Dienst auf einem angegebenen Port. Dienste der Ebene 4 haben jedoch keine Kenntnis der tatsächlichen Anwendungen und können diese Arten von komplexen Routingregeln nicht implementieren.
Ein Verständnis des Unterschieds zwischen diesen beiden Ansätzen hilft bei der Auswahl des richtigen Tools für Ihre Anforderungen an die Datenverkehrsverwaltung.
Wenn Sie AKS Automatic verwenden, beginnen Sie zuerst mit dem verwalteten Eingangspfad, und verwenden Sie spezialisiertere Optionen nur, wenn Ihre Workload sie benötigt. In AKS Standard haben Sie mehr Flexibilität, um den Eingangscontroller und die Topologie auszuwählen, die ihrer Architektur am besten entspricht.
Vergleichen von Eingangsoptionen
Funktionsvergleich
In der folgenden Tabelle sind die Featureunterschiede zwischen den verschiedenen Eingangscontrolleroptionen aufgeführt. Für die meisten Produktions-AKS-Workloads ist in AKS Automatic der verwaltete Ingress-Ansatz die empfohlene Standardoption, sofern Sie nicht ausdrücklich benutzerdefiniertes Routing, eine Service-Mesh-Integration oder einen von Azure gehosteten Ingress benötigen.
| Funktion | Erweiterung für Anwendungsrouting | Application Gateway für Container | Azure Service Mesh /Istio-Dienstgitter |
|---|---|---|---|
| Eingangs-/Gatewaycontroller | NGINX-Eingangscontroller | Azure Application Gateway für Containers | Istio Ingress Gateway |
| API | Eingangs-API | Ingress-API und Gateway-API | Istio Ingress-API |
| Hosting | In-cluster | In Azure gehostet | In-cluster |
| Skalierung | Automatische Skalierung | Automatische Skalierung | Automatische Skalierung |
| Lastenausgleich | Intern/extern | Extern | Intern/extern |
| SSL-Beendigung | In-cluster | Ja: Offboarding und E2E SSL | In-cluster |
| mTLS | – | Ja: Frontend und Back-End | Ja |
| Statische IP-Adresse | Ja | FQDN (keine statische IP) | – |
| In Azure Key Vault gespeicherte SSL-Zertifikate | Ja | Ja | – |
| Azure DNS-Integration für die DNS-Zonenverwaltung | Ja | Ja | – |
Wann jeder Eingangscontroller verwendet werden soll
In der folgenden Tabelle sind die verschiedenen Szenarien aufgeführt, in denen Sie die einzelnen Eingangscontroller verwenden können:
| Eingangsoptionen | Verwendung |
|---|---|
| Verwaltetes NGINX – Add-On für Anwendungsrouting | • Im Cluster gehostete, anpassbare und skalierbare NGINX-Eingangscontroller. • Grundlegende Lastenausgleichs- und Routingfunktionen. • Interne und externe Lastenausgleichskonfiguration. • Konfiguration statischer IP-Adressen. • Integration mit Azure Key Vault für die Zertifikatverwaltung. • Integration in Azure DNS Zonen für die öffentliche und private DNS-Verwaltung. • 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 mitbringen. • Erweiterte Datenverkehrsverwaltungsfunktionen wie automatische Wiederholungen, Ausfallsicherheit der Verfügbarkeitszone, gegenseitige Authentifizierung (mTLS) zum Back-End-Ziel, Datenverkehrsaufteilung/gewichteter Roundrobin und automatische Skalierung. • Integration mit Azure Key Vault für die Zertifikatverwaltung. • Integration in Azure DNS Zonen für die öffentliche und private DNS-Verwaltung. • 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. |
Hinweis
Das Istio-Add-On unterstützt derzeit keine Gateway-API für Istio-Eingangsdatenverkehr.
Erstellen einer Eingangsressource
Das Add-On für Anwendungsrouting ist die empfohlene Methode zum Konfigurieren eines eingehenden Controllers in AKS und für die meisten Workloads der empfohlene verwaltete Einstiegspfad in AKS Automatic. Das Anwendungsrouting-Add-On ist ein vollständig verwalteter Eingangscontroller für AKS, der die folgenden Features bereitstellt:
- Einfache Konfiguration von verwalteten NGINX-Eingangscontrollern basierend auf Kubernetes NGINX Ingress Controller.
- Integration in Azure DNS für die Verwaltung öffentlicher und privater Zone.
- SSL-Beendigung mit Zertifikaten, die in Azure Key Vault gespeichert sind
Für die meisten Produktionsworkloads ist dies der richtige Standardwert für den Anfang. Wenn Sie eine benutzerdefinierte Eingangstopologie, Azure gehosteten Eingangs- oder Dienstgitterverhalten benötigen, können Sie zu einer der anderen Eingangsoptionen wechseln.
Weitere Informationen zum Add-On für Anwendungsrouting finden Sie unter Verwalteter NGINX-Ingress mit dem Add-On für Anwendungsrouting.
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.
Dies bleibt eine wichtige Designauswahl sowohl in AKS Automatic als auch in AKS Standard, da die Quell-IP-Behandlung die Observability, die Auditierbarkeit und das Anwendungsverhalten unabhängig vom Clustermodus beeinflusst.
Weitere Informationen zur Beibehaltung der Clientquell-IP finden Sie unter Netzwerkkonzepte für Anwendungen in Azure Kubernetes Service (AKS).