Rearchitect AWS EKS-Webanwendung für Azure Kubernetes Service (AKS)

Nachdem Sie nun ein besseres Verständnis der Plattformunterschiede zwischen AWS und Azure haben, untersuchen wir die Webanwendungsarchitektur auf AWS und die Änderungen, die erforderlich sind, um sie mit Azure Kubernetes Service (AKS) kompatibel zu machen.

Yelb-Anwendungsarchitektur

Die Yelb-Beispielwebanwendung besteht aus einer Front-End-Komponente, die aufgerufen wird yelb-ui, und einer Anwendungskomponente, die aufgerufen wird yelb-appserver.

Architekturdiagramm der Yelb-Webanwendung.

Der yelb-ui JavaScript-Code dient dem Browser. Dieser Code wird aus einer Angular-Anwendung kompiliert. Die yelb-ui Komponente kann je nach Bereitstellungsmodell auch einen nginx Proxy enthalten. Dies yelb-appserver ist eine Sinatra-Anwendung , die mit einem Cacheserver (redis-server) und einer Postgres-Back-End-Datenbank (yelb-db) interagiert. Redis Cache speichert die Anzahl der Seitenaufrufe, während PostgreSQL die Stimmen speichert. Beide Dienste werden auf Kubernetes bereitgestellt, ohne einen verwalteten Dienst zum Speichern von Daten in AWS oder Azure zu verwenden.

Die ursprüngliche Yelb-Anwendung ist eigenständig und basiert nicht auf externen Diensten, sodass Sie sie ohne Codeänderungen von AWS zu Azure migrieren können. In Azure können Sie Azure Managed Redis und Azure Database für PostgreSQL als Ersatz für die redis Cache- und PostgreSQL-Dienste verwenden, die auf AKS bereitgestellt werden.

Mit der Yelb-Beispielanwendung können Benutzer über eine Reihe von Alternativen (Restaurants) abstimmen und Kreisdiagramme basierend auf der Anzahl der empfangenen Stimmen dynamisch aktualisieren. Die Anwendung verfolgt auch die Anzahl der Seitenaufrufe und zeigt den Hostnamen der yelb-appserver Instanz an, die die API-Anforderung nach einer Abstimmung oder einer Seitenaktualisierung bedient. Mit diesem Feature können Sie die Anwendung unabhängig oder gemeinsam demoieren.

Screenshot der Yelb-Dienstschnittstelle.

Architektur auf AWS

Um Webanwendungen und APIs vor allgemeinen Web-Exploits zu schützen, bietet AWS Web Application Firewall (WAF) und AWS Firewall Manager an.

Zuordnen von AWS-Diensten zu Azure-Diensten

Um die AWS-Workload in Azure mit minimalen Änderungen neu zu erstellen, verwenden Sie ein Azure-Äquivalent für jeden AWS-Dienst. In der folgenden Tabelle sind die Dienstzuordnungen zusammengefasst:

Dienstzuordnung AWS-Dienst Azure-Dienst
Webzugriffsfirewall AWS Web Application Firewall (WAF) Azure Web Application Firewall (WAF)
Anwendungslastenausgleich Application Load Balancer (ALB) Azure Application GatewayAnwendungsgateway für Container (AGC)
Inhaltsübermittlungsnetzwerk Amazon CloudFront Azure Front Door (AFD)
Orchestrierung Elastic Kubernetes Service (EKS) Azure Kubernetes Service (AKS)
Geheimnistresor AWS Key Management Service (KMS) Azure Key Vault
Containerregistrierung Amazon Elastic Container Registry (ECR) Azure Container Registry (ACR)
Domänennamenserver (DNS) Amazon Route 53 Azure DNS
Zwischenspeicherung Amazon ElastiCache Azure Managed Redis
NoSQL Amazon DynamoDB Azure-Datenbank für PostgreSQL

Einen umfassenden Vergleich zwischen Azure- und AWS-Diensten finden Sie im Vergleich zwischen AWS und Azure-Diensten.

Architektur in Azure

In dieser Lösung wird die Yelb-Anwendung in einem AKS-Cluster bereitgestellt und über einen Eingangscontroller wie den NGINX-Eingangscontroller verfügbar gemacht. Der Ingress-Controller-Dienst wird über einen internen (oder privaten) Load Balancer bereitgestellt. Weitere Informationen zur Verwendung eines internen Lastenausgleichs zum Einschränken des Zugriffs auf Ihre Anwendungen in AKS finden Sie unter Verwenden eines internen Lastenausgleichs mit Azure Kubernetes Service (AKS).

Dieses Beispiel unterstützt die Installation eines verwalteten NGINX-Eingangscontrollers mit dem Anwendungsrouting-Add-On oder einem nicht verwalteten NGINX-Eingangscontroller mithilfe des Helm-Diagramms. Das Anwendungsrouting-Add-On mit NGINX-Eingangscontroller bietet die folgenden Features:

Weitere Konfigurationen finden Sie in den folgenden Artikeln:

Die Yelb-Anwendung wird mit einer Azure Application Gateway-Ressource gesichert, die in einem dedizierten Subnetz innerhalb desselben virtuellen Netzwerks wie der AKS-Cluster oder in einem peered virtual network bereitgestellt wird. Sie können den Zugriff auf die Yelb-Anwendung mithilfe der Azure-Webanwendungsfirewall (WAF) sichern, die einen zentralen Schutz von Webanwendungen vor gängigen Exploits und Sicherheitsrisiken bietet.

Design der Lösungsarchitektur

Das folgende Diagramm zeigt die empfohlene Architektur in Azure:

Diagramm der Lösung basierend auf dem Application Gateway WAFv2- und NGINX-Eingangscontroller.

Die Lösungsarchitektur besteht aus folgenden Komponenten:

  1. Das Anwendungsgateway verarbeitet TLS-Beendigung und kommuniziert mit der Back-End-Anwendung über HTTPS.
  2. Der Anwendungsgatewaylistener verwendet ein SSL-Zertifikat, das aus Azure Key Vault abgerufen wurde.
  3. Die dem Listener zugeordnete Azure WAF-Richtlinie führt OWASP-Regeln und benutzerdefinierte Regeln für eingehende Anforderungen aus und blockiert böswillige Angriffe.
  4. Die HTTP-Einstellungen für das Anwendungsgateway rufen die Yelb-Anwendung über HTTPS auf Port 443 auf.
  5. Der Application Gateway-Back-End-Pool und Integritätstests rufen den NGINX-Eingangsdatencontroller über den internen AKS-Lastenausgleich mithilfe von HTTPS auf.
  6. Der NGINX-Eingangscontroller verwendet den internen AKS-Lastenausgleich.
  7. Der AKS-Cluster ist mit dem Azure Key Vault-Anbieter für Secrets Store CSI Driver-Add-On konfiguriert, um Geheimnisse, Zertifikate und Schlüssel aus Azure Key Vault über ein CSI-Volume abzurufen.
  8. Eine SecretProviderClass ruft dasselbe Zertifikat ab, das vom Anwendungsgateway aus Azure Key Vault verwendet wird.
  9. Ein Kubernetes-Ingressobjekt verwendet den NGINX-Eingangscontroller, um die Anwendung über HTTPS über den internen AKS-Lastenausgleich verfügbar zu machen.
  10. Der Yelb-Dienst ist vom Typ ClusterIP und wird über den NGINX-Eingangscontroller verfügbar gemacht.

Ausführliche Anweisungen zum Bereitstellen der Yelb-Anwendung auf AKS mithilfe dieser Architektur finden Sie im Begleitbeispiel.

Alternative Lösungen

Azure bietet mehrere Optionen zum Bereitstellen einer Webanwendung auf einem AKS-Cluster und zum Sichern mit einer Webanwendungsfirewall:

Der Application Gateway Ingress Controller (AGIC) ist eine Kubernetes-Anwendung, sodass Sie das native Application Gateway L7-Lastenausgleich von Azure nutzen können, um Cloud-Software über das Internet für Ihre Azure Kubernetes Service (AKS)-Workloads verfügbar zu machen. AGIC überwacht den Kubernetes-Cluster, auf dem es gehostet wird, und aktualisiert kontinuierlich ein Anwendungsgateway, sodass ausgewählte Dienste für das Internet verfügbar gemacht werden.

Diagramm der Lösung basierend auf dem Azure-Anwendungsgateway-Eingangscontroller.

Der Ingress-Controller läuft in seinem eigenen Pod auf dem AKS-Cluster. AGIC überwacht eine Teilmenge von Kubernetes-Ressourcen auf Änderungen, übersetzt den Status des Clusters in eine spezifische Konfiguration des Anwendungsgateways und wendet sie auf Azure Resource Manager (ARM) an. Weitere Informationen finden Sie unter Was ist application Gateway Ingress Controller?.

Die folgende Tabelle enthält Vor- und Nachteile des Application Gateway Ingress Controller (AGIC):

Vorteile Benachteiligungen
* Native Integration: AGIC bietet native Integration mit Azure-Diensten, insbesondere Azure-Anwendungsgateway, das ein nahtloses und effizientes Routing von Datenverkehr zu Diensten ermöglicht, die auf AKS ausgeführt werden.
* Vereinfachte Bereitstellungen: Die Bereitstellung von AGIC als AKS-Add-on ist im Vergleich zu anderen Methoden einfacher. Es ermöglicht eine schnelle und einfache Einrichtung eines Application Gateway und eines AKS-Clusters mit aktiviertem AGIC.
* Vollständig verwalteter Dienst: AGIC als Add-On ist ein vollständig verwalteter Dienst, der Vorteile wie automatische Updates und erhöhte Unterstützung von Microsoft bietet. Dadurch wird sichergestellt, dass der Ingress-Controller up-to-date bleibt und eine zusätzliche Unterstützungsebene hinzufügt.		 * Single Cloud-Ansatz: AGIC wird in erster Linie von Kunden übernommen, die einen Single-Cloud-Ansatz einführen. Es ist möglicherweise nicht die beste Wahl, wenn Sie eine Multicloud-Architektur benötigen, bei der die Bereitstellung auf verschiedenen Cloudplattformen eine Anforderung ist. In diesem Fall sollten Sie einen cloudagnostischen Eingangscontroller wie NGINX, Traefik oder HAProxy verwenden, um Vendo-Lockin-Probleme zu vermeiden.

Weitere Informationen finden Sie in den folgenden Ressourcen:

  • Last updated on