Microservices-Architektur auf Azure Kubernetes Service

Diese Architektur zeigt eine Microservices-Anwendung, die für Azure Kubernetes Service (AKS) bereitgestellt wird. Es beschreibt eine grundlegende AKS-Konfiguration, die Sie als Ausgangspunkt für die meisten Bereitstellungen verwenden können. In diesem Artikel wird davon ausgegangen, dass Sie ein grundlegendes Verständnis von Kubernetes haben. Es hebt die Aspekte der Infrastruktur und des DevOps bei der Verwaltung von Microservices auf AKS hervor. Für Produktionsbereitstellungen empfiehlt diese Architektur, Azure CNI zu verwenden, das von Cilium als Netzwerklösung unterstützt wird. Azure CNI mit Unterstützung von Cilium bietet verbesserte Leistung, integrierte Durchsetzung von Netzwerkrichtlinien und eine verbesserte Beobachtbarkeit durch seine auf Extended Berkeley Packet Filter (eBPF) basierende Datenebene. Weitere Informationen zum Entwerfen von Microservices finden Sie unter Microservices-Architekturdesign.

Architecture

Helm ist eine Marke der Cloud Native Computing Foundation (CNCF). Die Verwendung dieser Marke impliziert keine Empfehlung.

Laden Sie eine Visio-Datei dieser Architektur herunter.

Ein Beispiel für einen fortschrittlicheren Microservice, der auf der AKS-Basisarchitektur basiert, finden Sie in der erweiterten AKS-Microservices-Architektur.

Datenfluss

Dieser Anforderungsfluss implementiert die Cloudentwurfsmuster Publisher-Subscriber (Herausgeber-Abonnent), Competing Consumers (Konkurrierende Consumer) und Gateway Routing.

Der folgende Datenfluss entspricht dem vorherigen Diagramm:

1. Die Clientanwendung sendet eine JSON-Nutzlast über HTTPS an den öffentlichen vollqualifizierten Domänennamen (Fully Qualified Domain Name, FQDN) des Lastenausgleichs (verwalteter Eingangscontroller), um eine Drohnenabholung zu planen.

   • Der verwaltete Ingress-Controller leitet die Anforderung an den Ingestions-Microservice weiter.

   • Der Erfassungs-Microservice verarbeitet die Anforderung und reiht Übermittlungsanforderungen in eine Azure Service Bus-Warteschlange ein.

2. Der Workflow-Microservice führt die folgenden Aktionen aus:

   • Nutzt Nachrichteninformationen aus der Service Bus-Nachrichtenwarteschlange

   • Sendet eine HTTPS-Anforderung an den Übermittlungs-Microservice, der Daten an den externen Datenspeicher in Azure Managed Redis übergibt.

   • Sendet eine HTTPS-Anforderung an den Drohnen-Scheduler Microservice

   • Sendet eine HTTPS-Anforderung an den Microservice-Paket, der Daten an die externe Datenspeicherung in MongoDB übergibt.

3. Eine HTTPS GET-Anforderung gibt den Zustellungsstatus zurück. Diese Anforderung wird über den verwalteten Eingangscontroller an den Übermittlungs-Microservice weitergeleitet. Anschließend liest der Übermittlungs-Microservice Daten aus Azure Managed Redis.

Components

• AKS ist ein verwalteter Kubernetes-Dienst, der die Microservices-Container hosten und orchestriert. In dieser Architektur bietet AKS die Laufzeitplattform für die Bereitstellung, Skalierung und Verwaltung der Microservices der Drohnenbereitstellungsanwendung.

• Azure CNI unterstützt von Cilium ist die empfohlene Netzwerklösung, um eine direkte Verbindung mit einem Azure virtuellen Netzwerk herzustellen. In dieser Architektur werden IP-Adressen aus dem virtuellen Netzwerk an Pods zugewiesen, und es werden integrierte Funktionen für Netzwerkrichtlinien sowie Verkehrssichtbarkeit bereitgestellt.

• Ein Eingangsserver macht HTTP- und HTTPS-Routen für Dienste innerhalb eines Clusters verfügbar. In dieser Architektur wird die Gateway-API-Implementierung für das Anwendungsrouting als Ingress-Controller verwendet. Der Eingangscontroller implementiert das API-Gateway Muster für Microservices.

• Externe Datenspeicher wie Azure SQL-Datenbank oder Azure Cosmos DB werden von zustandslosen Mikroservices verwendet, um ihre Daten und andere Statusinformationen zu schreiben. In dieser Architektur dienen Azure Cosmos DB, Azure Managed Redis, Azure DocumentDB und Service Bus als Datenspeicher oder Speicherorte zum Speichern des Zustands.

• Microsoft Entra ID ist ein cloudbasierter Identitäts- und Zugriffsverwaltungsdienst, der Authentifizierungs- und Autorisierungsfunktionen für den AKS-Cluster und bereitgestellte Workloads bereitstellt. AKS benötigt die Integration mit Microsoft Entra ID, um eine verwaltete Identität für den Zugriff auf Azure Container Registry und die Bereitstellung von Azure-Ressourcen wie Load Balancers und verwalteten Datenträgern bereitzustellen. Jede auf dem AKS-Cluster bereitgestellte Workload erfordert eine Identität für den Zugriff auf Microsoft Entra geschützte Ressourcen, z. B. Azure Key Vault und Microsoft Graph. Diese Architektur verwendet Microsoft Entra Workload ID, um in Kubernetes zu integrieren und sichere Identitäten für Workloads bereitzustellen. Alternativ können Sie verwaltete Identitäten oder Anwendungsanmeldeinformationen für die Workloadauthentifizierung verwenden.

• Container Registry ist ein verwalteter Dienst, der private Container-Images speichern kann und in einem Cluster bereitgestellt wird. AKS kann sich mithilfe der Microsoft Entra Identität beim Container Registry authentifizieren. Microservice-Container-Images werden erstellt und in die Container-Registry übertragen. In dieser Architektur speichert Container Registry die privaten Containerimages für die Microservices, die im AKS-Cluster bereitgestellt werden.

• Azure Pipelines ist Teil der Azure DevOps Suite und führt automatisierte Builds, Tests und Bereitstellungen aus. Ein kontinuierlicher Integrations- und kontinuierlicher Bereitstellungsansatz (CI/CD) wird in Microservice-Umgebungen dringend empfohlen. Verschiedene Teams können microservices unabhängig mithilfe von Azure Pipelines für AKS erstellen und bereitstellen. In dieser Architektur baut Azure Pipelines die Drohnen-Liefer-Microservices auf AKS aus und stellt sie bereit.

• Helm ist ein Paket-Manager für Kubernetes, der einen Mechanismus zum Bündeln und Standardisieren von Kubernetes-Objekten in einer einzigen Einheit bereitstellt, die Sie veröffentlichen, bereitstellen, versionieren und aktualisieren können. In dieser Architektur verpackt Helm die Drohnenlieferungs-Microservices für die Bereitstellung auf AKS.

• Azure Monitor ist eine Überwachungsplattform, die Metriken und Protokolle, Anwendungstelemetrie und Plattformmetriken für Azure Dienste sammelt und speichert. In dieser Architektur wird Azure Monitor in AKS integriert, um Metriken von Controllern, Knoten und Containern zu sammeln.

• Application Insights ist ein Tool zur Leistungsüberwachung, das Microservices und Container überwacht. Er kann Einblicke in Microservices bieten, einschließlich Datenverkehrsfluss, End-to-End-Latenz und Fehlerprozentsatz. Sie kann den Gesundheitszustand der Mikroservices und die Beziehungen zwischen ihnen auf einer einzelnen Anwendungskarte anzeigen. In dieser Architektur überwacht Application Insights die Gesundheit und Leistung der Drohnen-Liefer-Microservices und zeigt ihre Beziehungen auf einer Anwendungskarte.

Alternatives

Azure Container Apps ist eine verwaltete serverlose Plattform, die eine Kubernetes-basierte Erfahrung ohne Infrastrukturverwaltung bietet. Sie dient als einfachere Alternative zu AKS zum Hosten von Microservices, wenn Sie keinen direkten Zugriff auf Kubernetes oder seine APIs benötigen und keine Kontrolle über die Clusterinfrastruktur benötigen.

Anstelle der Anwendungsroutinggateway-API-Implementierung in AKS können Sie Alternativen wie Anwendungsgateway für Container, das Istio-Dienstgitter-Add-On oder nicht Microsoft Lösungen verwenden. Weitere Informationen finden Sie unter Ingress in AKS.

Sie können Containerimages in Nicht-Microsoft-Containerregistrierungen wie Docker Hub speichern.

Für Netzwerke wird in dieser Architektur zwar Azure CNI unterstützt von Cilium wegen seiner Leistungsfähigkeit und der integrierten Richtlinienerzwingung empfohlen, aber Sie können für bestimmte Szenarien alternative Netzwerklösungen wie Azure CNI-Overlay verwenden.

Für Microservices, die Zustandsinformationen verwalten müssen, stellt Dapr eine Abstraktionsebene für die Verwaltung des Microservice-Zustands bereit.

Sie können GitHub Actions verwenden, um Microservices zu erstellen und bereitzustellen, oder Nicht-Microsoft CI/CD-Lösungen wie Jenkins auswählen.

Die Mikroservice-Observierbarkeit kann mit alternativen Werkzeugen wie Kialierreicht werden.

Szenariodetails

Ein fiktives Unternehmen namens Fabrikam, Inc., verwaltet eine Flotte von Drohnenflugzeugen. Unternehmen registrieren sich bei dem Dienst, und Benutzer können eine Drohne anfordern, die auszuliefernde Waren abholt. Wenn ein Kunde eine Abholung plant, weist das Back-End-System eine Drohne zu und benachrichtigt den Benutzer mit einer geschätzten Lieferzeit. Wenn die Lieferung läuft, kann der Kunde den Standort der Drohne mit einer kontinuierlich aktualisierten geschätzten Lieferzeit verfolgen.

Potenzielle Anwendungsfälle

Übernehmen Sie die folgenden bewährten Methoden aus dem Szenario zum Entwerfen komplexer mikroservicesbasierter Anwendungen in AKS:

• Komplexe Webanwendungen
• Geschäftslogik, die mithilfe von Microservice-Designprinzipien entwickelt wurde

Considerations

Diese Überlegungen implementieren die Säulen des Azure Well-Architected-Frameworks, die eine Reihe von Leitsätzen sind, die Sie verwenden können, um die Qualität einer Arbeitsauslastung zu verbessern. Weitere Informationen finden Sie unter Microsoft Azure Well-Architected Framework.

Design

Diese Referenzarchitektur konzentriert sich auf Microservices, aber viele der empfohlenen Methoden gelten für andere Workloads, die auf AKS ausgeführt werden.

Microservices

Ein Microservice ist eine lose gekoppelte, unabhängig bereitstellbare Codeeinheit. Microservices kommunizieren normalerweise über gut definierte APIs und können per Dienstermittlung ermittelt werden. Das Kubernetes-Dienstobjekt ist eine typische Methode zum Modellieren von Microservices in Kubernetes.

Datenspeicherung

In einer Microservices-Architektur sollten Dienste keine Datenspeicherlösungen freigeben. Jeder Dienst sollte ein eigenes Dataset verwalten, um ausgeblendete Abhängigkeiten zwischen Diensten zu vermeiden. Die Datentrennung verhindert unbeabsichtigte Kopplung zwischen Diensten. Dieser Vorgang kann auftreten, wenn Dienste dieselben zugrunde liegenden Datenschemas verwenden. Wenn Dienste ihre eigenen Datenspeicher verwalten, können sie den richtigen Datenspeicher für ihre speziellen Anforderungen verwenden. Weitere Informationen finden Sie unter Überlegungen zu Daten für Microservices.

Vermeiden Sie das Speichern dauerhafter Daten im lokalen Clusterspeicher, da diese Methode die Daten an den Knoten bindet. Verwenden Sie stattdessen einen externen Dienst wie SQL-Datenbank oder Azure Cosmos DB. Eine weitere Möglichkeit besteht darin, ein persistentes Datenvolume mithilfe von Azure Disk Storage oder Azure Files an eine Lösung bereitzustellen. Weitere Informationen finden Sie unter Speicheroptionen für Anwendungen in AKS.

Netzwerk- und Netzwerkrichtlinie

Verwenden Sie Azure CNI, betrieben durch Cilium, als Netzwerklösung für Produktions-Microservices-Bereitstellungen auf AKS. Dieser Ansatz bietet verschiedene Vorteile für Microservices-Architekturen:

• Leistung und Skalierbarkeit: Die eBPF-basierte Datenebene verbessert die Leistung des Dienstroutings und unterstützt größere Cluster mit geringerer Latenz im Vergleich zu herkömmlichen Netzwerklösungen.

• Network-Richtlinienerzwingung: Cilium erzwingt Kubernetes NetworkPolicy-Ressourcen, ohne dass ein separates Netzwerkrichtlinienmodul wie Azure Netzwerkrichtlinien-Manager oder Calico erforderlich ist. Diese Integration vereinfacht die Clusterkonfiguration und reduziert den Betriebsaufwand.

• Observability: Die eBPF-Datenebene bietet Einblicke in den Netzwerkdatenverkehr, einschließlich DNS-Abfragen (Domain Name System), Pod-to-Pod-Flüssen und Dienst-zu-Dienst-Kommunikation. Diese Sichtbarkeit hilft bei der Problembehandlung bei Mikroserviceinteraktionen und bei der Identifizierung von Leistungsengpässen.

• Flexible IP-Adressverwaltung: Azure CNI in Verbindung mit Cilium unterstützt sowohl Modelle für virtuelles Netzwerkrouting als auch für Overlay-Pod-IP-Adresszuweisung, basierend auf den Netzwerkarchitekturanforderungen Ihrer Workload.

Wenn Sie Netzwerkrichtlinien für Microservices implementieren, befolgen Sie ein Zero Trust-Architekturprinzip, indem Sie explizit definieren, welche Dienste miteinander kommunizieren können. Beginnen Sie mit Deny-All-Richtlinien, und lassen Sie selektiv nur den erforderlichen Datenverkehr zwischen Microservices zu. Weitere Informationen finden Sie unter Bewährte Methoden für Netzwerkrichtlinien in AKS.

API gateway

API-Gateways sind ein allgemeines Microserviceentwurfsmuster. Ein API-Gateway befindet sich zwischen externen Clients und den Microservices. Das Gateway dient als Reverseproxy und leitet Anforderungen von Clients an Microservices weiter. Ein API-Gateway kann auch verschiedene querschnittliche Aufgaben wie Authentifizierung, SSL-Terminierung und Ratenbegrenzung durchführen. Weitere Informationen finden Sie in den folgenden Ressourcen:

• Verwenden von API-Gateways in Microservices-

• Auswählen einer API-Gatewaytechnologie

In Kubernetes behandelt ein Eingangscontroller in erster Linie die Funktionalität eines API-Gateways. Der Eingang und der Eingangscontroller arbeiten zusammen, um die folgenden Aktionen auszuführen:

• Leiten Sie Clientanforderungen an die richtigen Back-End-Microservices weiter. Dieses Routing stellt einen einzelnen Endpunkt für Clients bereit und hilft, Clients von Diensten zu entkoppeln.

• Aggregieren Sie mehrere Anforderungen in einer einzigen Anforderung, um die Chattigkeit zwischen dem Client und dem Back-End zu reduzieren.

• Auslagern von Funktionen aus den Back-End-Diensten, z. B. SSL-Terminierung, Authentifizierung, IP-Adresseinschränkungen oder Clientratenbegrenzung (als Drosselung bezeichnet).

Es gibt Ingress-Controller für Reverse-Proxys. AKS bietet mehrere verwaltete Eingangsoptionen. Sie können zwischen der Kubernetes-Gateway-API über das Anwendungsrouting-Add-On oder anwendungsgateway für Container wählen. Alternativ können Sie ein Istio-basiertes Dienstgitter-Add-On als Eingangscontroller auswählen. Weitere Informationen finden Sie unter Ingress in AKS.

Kubernetes hat Eingangsressourcen durch die komplexere und vielseitigere Gateway-API ersetzt. Ingress-Controller und die Gateway-API sind Kubernetes-Objekte, die das Routing des Datenverkehrs und den Lastenausgleich steuern. Die Gateway-API ist eine moderne Sammlung generischer, ausdrucksstarker, erweiterbarer und rollenorientierter APIs für die Definition von Routingregeln der Ebenen 4 und 7 in Kubernetes.

Der Ingress-Controller fungiert als Edge-Router oder Reverse-Proxy. Ein Reverseproxyserver ist ein potenzieller Engpass oder einzelner Fehlerpunkt. Daher wird empfohlen, mindestens zwei Replikate bereitzustellen, um eine hohe Verfügbarkeit sicherzustellen.

Wann sollte man Ingress-Controller oder die Gateway-API auswählen?

Eingangsressourcen eignen sich für die folgenden Anwendungsfälle:

• Eingangscontroller sind einfach einzurichten und eignen sich für kleinere und weniger komplexe Kubernetes-Bereitstellungen, die einfache Konfiguration priorisieren.

• Wenn Sie derzeit Ingresscontroller in Ihrem Kubernetes-Cluster konfiguriert haben und diese Ihre Anforderungen effektiv erfüllen, müssen Sie nicht sofort zur Kubernetes-Gateway-API wechseln.

Verwenden Sie die Gateway-API, wenn die folgenden Faktoren zutreffen:

• Wenn Sie sich mit komplexen Routingkonfigurationen, Datenverkehrsteilungen und erweiterten Strategien für die Datenverkehrsverwaltung befassen. Kubernetes Gateway API Route-Ressourcen bieten in diesen Fällen die erforderliche Flexibilität.

• Wenn Netzwerkanforderungen benutzerdefinierte Lösungen oder die Integration von Nicht-Microsoft-Plug-Ins benötigen. Der Ansatz der Kubernetes-Gateway-API basierend auf benutzerdefinierten Ressourcendefinitionen kann eine erweiterte Erweiterbarkeit bieten.

Reliability

Zuverlässigkeit trägt dazu bei, dass Ihre Anwendung die Verpflichtungen erfüllen kann, die Sie für Ihre Kunden vornehmen. Weitere Informationen finden Sie unter Prüfliste zur Entwurfsüberprüfung für Zuverlässigkeit.

Partitionieren von Microservices

Verwenden Sie Namespaces, um Dienste im Cluster zu organisieren. Jedes Objekt in einem Kubernetes-Cluster gehört zu einem Namespace. Es empfiehlt sich, Namespaces zum Organisieren der Ressourcen im Cluster zu verwenden.

Namespaces tragen dazu bei, Namenskonflikte zu vermeiden. Wenn mehrere Teams Microservices im selben Cluster bereitstellen, mit möglicherweise Hunderten von Microservices, wird die Verwaltung in einem einzigen Namespace schwierig. Mit Namespaces können Sie auch die folgenden Aktionen ausführen:

• Wenden Sie Ressourceneinschränkungen auf einen Namespace an, sodass der Gesamtsatz von Pods, die diesem Namespace zugewiesen sind, das Ressourcenkontingent des Namespaces nicht überschreiten kann.

• Wenden Sie Richtlinien auf Namespaceebene an, einschließlich rollenbasierter Zugriffssteuerung (RBAC) und Sicherheitsrichtlinien.

Wenn mehrere Teams Microservices entwickeln und bereitstellen, bieten Namespaces einen praktischen Mechanismus zum Steuern von Bereichen, für die jedes Team bereitstellen kann. Beispielsweise gewähren Kubernetes-RBAC-Richtlinien dem Entwicklungsteam nur zugriff auf namespace A und gewähren dem Entwicklungsteam B nur Zugriff auf Namespace B.

Bei einer Microservices-Architektur sollten Sie die Mikroservices in gebundenen Kontexten organisieren und Namespaces für jeden gebundenen Kontext erstellen. Beispielsweise können alle Microservices, die mit dem gebundenen Kontext der Auftragserfüllung zusammenhängen, in denselben Namespace gehen. Alternativ hierzu können Sie auch einen Namespace für jedes Entwicklungsteam erstellen.

Ordnen Sie Dienstprogramme in einem eigenen Namespace an. Sie können beispielsweise Clusterüberwachungstools wie Elasticsearch und Prometheus in einem Überwachungsnamespace bereitstellen.

Gesundheitsprüfungen

Kubernetes definiert drei Arten von Integritätstests, die ein Pod verfügbar machen kann:

• Bereitschaftssonde: teilt Kubernetes mit, ob der Pod bereit ist, Anforderungen zu akzeptieren.

• Liveness-Probe: teilt Kubernetes mit, ob ein Pod entfernt und eine neue Instanz gestartet werden soll.

• Startsonde: teilt Kubernetes mit, ob der Pod gestartet wird.

Um Probes zu verstehen, überprüfen Sie zunächst, wie ein Dienst in Kubernetes funktioniert. Ein Dienst hat einen Label-Selektor, der mit einer Gruppe von null oder mehr Pods übereinstimmt. Kubernetes führt für den Datenverkehr einen Lastenausgleich auf die Pods durch, die die Auswahlkriterien erfüllen. Nur Pods, die erfolgreich gestartet werden und fehlerfrei sind, empfangen Datenverkehr. Wenn ein Container abstürzt, beendet Kubernetes den Pod und plant einen Ersatz.

Manchmal ist ein Pod nicht bereit, Datenverkehr zu empfangen, selbst wenn er erfolgreich gestartet wird. Es können beispielsweise Initialisierungsaufgaben ausgeführt werden, z. B. wenn die Anwendung, die im Container ausgeführt wird, Daten in den Arbeitsspeicher lädt oder Konfigurationsdateien liest. Sie können eine Startsonde für Container mit langsamen Start verwenden. Dieser Ansatz verhindert, dass Kubernetes sie beenden, bevor sie die Möglichkeit haben, vollständig zu initialisieren.

Liveness-Tests überprüfen, ob ein Pod ausgeführt wird, aber nicht ordnungsgemäß funktioniert und neu gestartet werden muss. Wenn ein Container beispielsweise HTTP-Anforderungen verarbeitet, aber plötzlich nicht mehr reagiert, ohne abstürzen zu müssen, erkennt die Liveness-Probe dieses Ereignis und löst einen Neustart des Pods aus. Wenn Sie einen Liveness-Test einrichten, erkennt dieser, wenn ein Container nicht reagiert, und fordert Kubernetes auf, den Pod neu zu starten, wenn der Container den Test wiederholt nicht besteht.

Berücksichtigen Sie beim Gestalten von Sonden für Microservices die folgenden Punkte:

• Wenn Ihr Code eine lange Startzeit hat, meldet eine Liveness-Probe möglicherweise einen Fehler, bevor der Start abgeschlossen ist. Um den Start eines Liveness-Tests zu verzögern, verwenden Sie den Startup-Test, oder verwenden Sie die Einstellung initialDelaySeconds mit dem Liveness-Test.

• Ein Liveness-Test ist nur hilfreich, wenn ein Neustart des Pods diesen wahrscheinlich wieder in einen fehlerfreien Zustand versetzt. Sie können einen Liveness-Test verwenden, um Arbeitsspeicherverluste oder unerwartete Deadlocks zu mindern, aber starten Sie keinen Pod neu, von dem Sie erwarten, dass er sofort wieder fehlschlägt.

• Manchmal überprüfen Bereitschaftssonden abhängige Dienste. Wenn für einen Pod beispielsweise eine Abhängigkeit von einer Datenbank besteht, kann mit dem Test ggf. die Datenbankverbindung überprüft werden. Dieser Ansatz kann jedoch unerwartete Probleme verursachen. Möglicherweise ist ein externer Dienst vorübergehend nicht verfügbar. Diese Nichtverfügbarkeit führt dazu, dass der Readiness-Test für alle Pods in Ihrem Dienst fehlschlägt, was zu deren Entfernung aus dem Lastenausgleich führt. Durch diese Entfernung entstehen kaskadierende Ausfälle im vorgelagerten Bereich.

  Ein besserer Ansatz besteht darin, die Wiederholungsbehandlung innerhalb Ihres Diensts zu implementieren, damit Ihr Dienst bei vorübergehenden Fehlern ordnungsgemäß wiederhergestellt werden kann. Alternativ kann das Istio-Service Mesh Wiederholungsbehandlung, Fehlertoleranz und Trennschalter implementieren. Dieser Ansatz erstellt eine robuste Architektur, die Mikroservicefehler behandeln kann.

Verwenden Sie zur Problembehandlung bei der Integrität von Microservices die Features für die Netzwerkbeobachtbarkeit in Advanced Container Networking Services. Die eBPF-Datenebene erfasst detaillierte Informationen zum Netzwerkfluss zwischen Microservices, die Ihnen dabei helfen, Konnektivitätsprobleme, DNS-Lösungsprobleme oder Netzwerkrichtlinienfehler zu identifizieren, die sich auf den Dienststatus auswirken können.

Ressourceneinschränkungen

Ressourcenkonflikte können sich auf die Verfügbarkeit eines Diensts auswirken. Definieren Sie Ressourceneinschränkungen für Container, sodass ein einzelner Container die Clusterressourcen wie Arbeitsspeicher und CPU nicht überfordern kann. Bei Ressourcen, die keine Container sind, z. B. Threads oder Netzwerkverbindungen, sollten Sie das Bulkhead-Muster verwenden, um Ressourcen zu isolieren.

Verwenden Sie Ressourcenkontingente, um die für einen Namespace zulässigen Gesamtressourcen einzuschränken. Diese Einschränkung stellt sicher, dass Front-End-Dienste keine Ressourcen verbrauchen, die Back-End-Dienste benötigen, und Back-End-Dienste verbrauchen keine Ressourcen, die Front-End-Dienste benötigen. Ressourcenkontingente können dabei helfen, Ressourcen innerhalb desselben Clusters mehreren Microservice-Entwicklungsteams zuzuweisen.

Security

Sicherheit bietet Sicherheitsmaßnahmen gegen bewusste Angriffe und den Missbrauch Ihrer wertvollen Daten und Systeme. Weitere Informationen finden Sie unter Entwurfsprüfliste für die Sicherheit.

TLS- und SSL-Verschlüsselung

In vielen Implementierungen wird der Eingangscontroller für die SSL-Beendigung verwendet. Als Teil der Bereitstellung des Eingangscontrollers müssen Sie ein TLS-Zertifikat (Transport Layer Security) erstellen oder importieren. Verwenden Sie selbstsignierte Zertifikate nur für Entwicklungs- und Testzwecke. Weitere Informationen finden Sie unter Einrichten eines benutzerdefinierten Domänennamens und EINES SSL-Zertifikats mit dem Anwendungsrouting-Add-On.

Erhalten Sie signierte Zertifikate von vertrauenswürdigen Zertifizierungsstellen für Produktionsumgebungen.

Je nach den Richtlinien Ihrer Organisation müssen Sie möglicherweise auch Ihre Zertifikate erneuern. Sie können Key Vault verwenden, um Zertifikate zu rotieren, die Microservices verwenden. Weitere Informationen finden Sie unter Zertifikatautomatische Rotation in Key Vault konfigurieren.

Netzwerksegmentierung und Richtlinien

Implementieren Sie die Netzwerksegmentierung zwischen Mikroservices mithilfe von Kubernetes NetworkPolicy-Ressourcen. Wenn Sie Azure CNI mit Cilium verwenden, erzwingt die eBPF-Datenebene Netzwerkrichtlinien.

Befolgen Sie die folgenden bewährten Methoden für Netzwerkrichtlinien in Mikroservices-Architekturen:

• Anwenden von Zero Trust-Prinzipien. Beginnen Sie mit verweigern-alle Netzwerkrichtlinien auf Namespace-Ebene und erlauben Sie explizit nur den erforderlichen Datenverkehr zwischen Microservices.

• Segmentierung nach abgegrenztem Kontext. Erstellen Sie Namespaces für jeden gebundenen Kontext in Ihrer Microservices-Architektur, und wenden Sie Netzwerkrichtlinien an, um den Datenverkehr zwischen diesen Kontexten zu steuern.

• Ausgehenden Datenverkehr kontrollieren. Verwenden Sie Netzwerkrichtlinien, um ausgehenden Datenverkehr von Microservices auf genehmigte externe Dienste und Endpunkte zu beschränken.

• Überwachen der Richtlinieneffizienz. Verwenden Sie die Observability-Features der Cilium eBPF-Datenebene, um die Durchsetzung von Netzwerkrichtlinien zu überwachen und blockierten Datenverkehr zu identifizieren, der auf Falschkonfigurationen oder Sicherheitsprobleme hinweisen kann.

RBAC

Wenn mehrere Teams Microservices gleichzeitig entwickeln und bereitstellen, können AKS RBAC-Mechanismen eine präzise Kontrolle und Filterung von Benutzeraktionen ermöglichen. Sie können entweder Kubernetes RBAC oder Azure RBAC mit Microsoft Entra ID verwenden, um den Zugriff auf die Clusterressourcen zu steuern. Weitere Informationen finden Sie unter Zugriffs- und Identitätsoptionen für AKS.

Authentifizierung und Autorisierung

Microservices können von den konsumierenden Diensten oder Benutzern verlangen, durch die Verwendung von Zertifikaten, Anmeldeinformationen und RBAC-Mechanismen den Zugriff auf die Microservices zu authentifizieren und zu autorisieren. Sie können Microsoft Entra ID verwenden, um OAuth 2.0-Token für die Autorisierung zu implementieren. Dienstgitter wie das Istio-Dienstgitter bieten auch Autorisierungs- und Authentifizierungsmechanismen für Microservices, einschließlich OAuth-Tokenüberprüfung und tokenbasiertes Routing.

Geheimnisverwaltung und Anwendungsanmeldeinformationen

Anwendungen und Dienste benötigen häufig Anmeldeinformationen, mit denen sie eine Verbindung mit externen Diensten wie Azure Storage oder SQL-Datenbank herstellen können. Die Herausforderung besteht darin, diese Anmeldeinformationen sicher zu halten und Lecks zu verhindern.

Verwenden Sie für Azure Ressourcen nach Möglichkeit verwaltete Identitäten. Eine verwaltete Identität ist wie eine eindeutige ID für eine Anwendung oder einen Dienst, die in Microsoft Entra ID gespeichert ist. Sie verwendet diese Identität, um sich mit einem Azure Dienst zu authentifizieren. Für die Anwendung oder den Dienst wurde ein Dienstprinzipal in Microsoft Entra ID erstellt, und die Authentifizierung erfolgt mithilfe von OAuth 2.0-Token. Der Code, der innerhalb des Prozesses ausgeführt wird, kann das Token transparent abrufen. Dieser Ansatz trägt dazu bei, dass Sie keine Kennwörter oder Verbindungszeichenfolgen speichern müssen. Um verwaltete Identitäten zu verwenden, können Sie einzelnen Pods in AKS Microsoft Entra Identitäten zuweisen, indem Sie Microsoft Entra Workload ID verwenden.

Selbst wenn Sie verwaltete Identitäten verwenden, müssen Sie möglicherweise noch einige Anmeldeinformationen oder andere geheime Anwendungsschlüssel speichern. Dieser Speicher ist für Azure Dienste erforderlich, die keine verwalteten Identitäten, Nicht-Microsoft-Dienste oder API-Schlüssel unterstützen. Sie können die folgenden Optionen verwenden, um geheime Schlüssel sicherer zu speichern:

• Key Vault: In AKS kann man ein oder mehrere Geheimnisse aus Key Vault als Volume einbinden. Das Volume liest die Geheimnisse aus Key Vault aus. Der Pod kann die Geheimnisse dann wie ein reguläres Volume lesen. Weitere Informationen finden Sie unter Verwenden Sie den Key Vault-Anbieter für den Secrets Store CSI-Treiber in einem AKS-Cluster. Der Pod authentifiziert sich selbst mithilfe einer Workloadidentität oder einer benutzer- oder systemseitig zugewiesenen verwalteten Identität. Weitere Informationen finden Sie unter Verbinden Sie Ihren Azure Identity Provider mit dem Key Vault Secrets Store CSI-Treiber in AKS.

• HashiCorp Vault: Microsoft Entra verwaltete Identitäten ermöglichen Kubernetes-Anwendungen die Authentifizierung mit HashiCorp Vault. Sie können den Tresor in Kubernetes bereitstellen. Erwägen Sie die Ausführung in einem separaten dedizierten Cluster von Ihrem Anwendungscluster.

• Kubernetes Geheimnisse: Eine weitere Option ist die Verwendung von Kubernetes-Geheimnissen. Diese Option ist die einfachste Konfiguration, aber die geringste Sicherheit. Geheimnisse werden in etcd gespeichert, bei dem es sich um einen verteilten Schlüsselwertspeicher handelt. AKS verschlüsselt etcd im Ruhezustand. Microsoft verwaltet die Verschlüsselungsschlüssel.

Verwenden Sie eine Lösung wie Key Vault, um die folgenden Vorteile zu erzielen:

• Zentrale Kontrolle von Geheimnissen
• Verschlüsselung von Geheimnissen im Ruhezustand
• Zentrale Schlüsselverwaltung
• Zugriffssteuerung von Geheimnissen
• Zentrales Lebenszyklusmanagement
• Auditing

Diese Architektur verwendet eine verwaltete Identität für Microservices, um sich beim Key Vault zu authentifizieren und auf Geheimnisse zuzugreifen.

Einschränken des Netzwerkzugriffs auf PaaS-Ressourcen

Diese Architektur verwendet Azure Netzwerksicherheitsperimeter, um den Zugriff auf Service Bus und Key Vault einzuschränken. Ordnen Sie Microsoft.ServiceBus/namespaces und Microsoft.KeyVault/vaults einem gemeinsamen Perimeter zu und blockieren Sie öffentlichen Datenverkehr standardmäßig.

Diese Architektur leitet ausgehenden Datenverkehr nicht über ein NAT-Gateway oder eine Egress-Firewall, sodass der AKS-Cluster keine statische ausgehende IP-Adresse hat. Umfangsperimeterzugriffsregeln nach Abonnement (dem Abonnement, das den AKS-Cluster hostt) und nicht nach IP-Bereich, was eine stabile, bekannte Quell-IP erfordert, um effektiv zu sein. Wenn Sie später eine Lösung wie Azure Firewall mit SNAT einführen, um dem Cluster eine statische Ausgangsidentität zu geben, können Sie stattdessen die Regeln auf diese statische IP-Adresse beschränken.

Alternativ können Sie private Endpunkte für Service Bus und Key Vault verwenden. Dieser Ansatz entfernt den zugriff auf öffentliche Endpunkte für diese Ressourcen und erfordert die Planung von privatem DNS und privater Konnektivität im Netzwerkdesign.

Container- und Orchestratorsicherheit

Die folgenden empfohlenen Methoden können ihnen dabei helfen, Ihre Pods und Container zu schützen:

• Überwachen Sie auf Bedrohungen. Überwachen sie auf Bedrohungen, indem Sie Microsoft Defender für Container oder eine Nicht-Microsoft-Funktion verwenden. Wenn Sie Container auf einem virtuellen Computer (VM) hosten, verwenden Sie Microsoft Defender für Server oder eine Nicht-Microsoft-Funktion. Sie können Protokolle auch aus der Lösung Containerüberwachung in Azure Monitor in Microsoft Sentinel oder eine vorhandene SIEM-Lösung (Security Information and Event Management) integrieren.

• Überwachen Sie Sicherheitsrisiken. Überwachen Sie kontinuierlich Images und ausgeführte Container für bekannte Sicherheitsrisiken, indem Sie Microsoft Defender für Container oder eine Nicht-Microsoft-Lösung verwenden.

• Automatisieren sie das Patchen von Bildern. Verwenden Sie Container-Registrierungsdienste, um das Patchen von Images zu automatisieren. Ein Containerimage besteht aus verschiedenen Ebenen. Die Basisebenen enthalten das Betriebssystemimage und Anwendungsframeworkimages, z. B. ASP.NET Core oder Node.js. Die Basisimages werden in der Regel vor den Anwendungsentwicklern erstellt, und andere Projektbetreuer verwalten sie. Wenn diese Images weiter oben gepatcht werden, müssen Sie Ihre eigenen Images aktualisieren, testen und erneut bereitstellen, damit Sie keine bekannten Sicherheitslücken hinterlassen. Containerregistrierungsaufgaben können dabei helfen, diesen Prozess zu automatisieren.

• Speichern Sie Bilder in einer vertrauenswürdigen privaten Registrierung. Verwenden Sie ein vertrauenswürdiges privates Registry wie das Container Registry oder Docker Trusted Registry, um Abbildungen zu speichern. Verwenden Sie einen validierenden Admission Webhook in Kubernetes, um sicherzustellen, dass Pods nur Images aus der vertrauenswürdigen Registry abrufen können.

• Wenden Sie das Prinzip der geringsten Rechte an. Führen Sie Container nicht im privilegierten Modus aus. Im privilegierten Modus hat ein Container Zugriff auf alle Geräte auf dem Host. Vermeiden Sie nach Möglichkeit die Ausführung von Prozessen als Root-Benutzer innerhalb von Containern. Container bieten keine vollständige Isolation aus Sicherheitsgründen, daher ist es besser, einen Containerprozess als nicht privilegierter Benutzer auszuführen.

Überlegungen zum CI/CD-Einsatz

Berücksichtigen Sie die folgenden Ziele eines robusten CI/CD-Prozesses für eine Microservices-Architektur:

• Jedes Team kann die eigenen Dienste unabhängig erstellen und bereitstellen, ohne dass andere Teams hierdurch beeinträchtigt oder gestört werden.

• Bevor eine neue Version eines Diensts in der Produktion bereitgestellt wird, wird er für die Entwicklung, den Test und die Q-&A-Umgebungen zur Überprüfung bereitgestellt. Jede Phase verfügt über so genannte „Quality Gates“.

• Eine neue Version eines Diensts kann parallel zur vorherigen Version bereitgestellt werden.

• Es sind ausreichende Richtlinien für die Zugriffssteuerung vorhanden.

• Bei containerisierten Workloads können Sie den Containerimages vertrauen, die in der Produktion eingesetzt werden.

Weitere Informationen zu den Herausforderungen finden Sie unter CI/CD für Microservices-Architekturen.

Die Verwendung eines Service Mesh wie Istio kann bei CI/CD-Prozessen helfen, z. B. bei Canary-Bereitstellungen, A/B-Tests von Microservices und gestaffelten Rollouts mit prozentualen Datenverkehrsaufteilungen.

Weitere Informationen zu spezifischen Empfehlungen und bewährten Methoden finden Sie unter Build a CI/CD pipeline for microservices on Kubernetes with Azure DevOps and Helm.

Kostenoptimierung

Die Kostenoptimierung konzentriert sich auf Möglichkeiten, unnötige Ausgaben zu reduzieren und die betriebliche Effizienz zu verbessern. Weitere Informationen finden Sie unter Design Review-Checkliste für die Kostenoptimierung.

Um die Kosten der Ressourcen in dieser Architektur zu schätzen, verwenden Sie diese vorkonfigurierte Schätzung im Azure Preisrechner. Passen Sie die Werte an, um zu sehen, wie sich die Kosten basierend auf Ihren spezifischen Anforderungen ändern.

Beachten Sie die folgenden Punkte für einige der in dieser Architektur verwendeten Dienste.

AKS

• In der Stufe "Frei" fallen keine Kosten für AKS in Bereitstellung, Verwaltung und Betrieb des Kubernetes-Clusters an. Sie zahlen nur für die VM-Instanzen, Speicher und Netzwerkressourcen, die Ihr Kubernetes-Cluster nutzt.

• Erwägen Sie den Einsatz des Horizontalen Pod-Autoscalers (HPA), um Mikroservices je nach Last automatisch ein- oder auszuskalieren.

• Konfigurieren Sie den Cluster Autoscaler (CA), um die Knoten je nach Last hoch- oder herunterzufahren.

• Erwägen Sie die Verwendung Spotknoten, um nicht kritische Mikroservices zu hosten.

• Überprüfen Sie die bewährten Methoden für die Kostenoptimierung für AKS.

Azure Load Balancer

• Die Gebühren werden nur anhand der Anzahl von konfigurierten Lastenausgleichsregeln und Ausgangsregeln berechnet. Eingehende NAT-Regeln sind kostenlos. Es gibt keine stündliche Gebühr für Load Balancer, wenn keine Regeln konfiguriert sind.

Azure Pipelines

• Diese Referenzarchitektur verwendet Azure Pipelines für CI/CD-Aufgaben. Ihnen steht ein kostenloser, von Microsoft gehosteter Job mit 1.800 Minuten pro Monat sowie ein selbstgehosteter Job mit unbegrenzten Minuten zur Verfügung. Zusätzliche Arbeitsplätze verursachen mehr Kosten.

Azure Monitor

• Ihnen werden die Datenerfassung und -aufbewahrung in Rechnung gestellt. Die vorkonfigurierte Schätzung umfasst Log Analytics, Prometheus-Metriken und Application Insights.

Operative Exzellenz

Operational Excellence deckt die Betriebsprozesse ab, mit denen eine Anwendung bereitgestellt und in der Produktion ausgeführt wird. Weitere Informationen finden Sie in der Checkliste zur Designüberprüfung für operationale Exzellenz.

Diese Referenzarchitektur enthält Bicep-Dateien für die Bereitstellung von Cloudressourcen und deren Abhängigkeiten. Sie können Azure Pipelines verwenden, um diese Bicep Dateien bereitzustellen und schnell verschiedene Umgebungen einzurichten, z. B. replizierte Produktionsszenarien. Dieser Ansatz hilft Ihnen, Kosten zu sparen, indem Sie Auslastungstestumgebungen nur bei Bedarf bereitstellen.

Erwägen Sie, die Kriterien für die Workloadisolation zu befolgen, um Ihre Bicep-Datei zu strukturieren. Eine Arbeitsauslastung wird in der Regel als beliebige Funktionalitätseinheit definiert. Sie können z. B. eine separate Bicep Datei für den Cluster und dann eine andere Datei für die abhängigen Dienste haben. Sie können Azure DevOps verwenden, um CI/CD mit Workloadisolation durchzuführen, da jede Workload ihrem eigenen Team zugeordnet und verwaltet wird.

Contributors

Microsoft verwaltet diesen Artikel. Die folgenden Mitwirkenden haben diesen Artikel geschrieben.

Hauptautor:

• Francis Simy Nazareth | Senior Technical Specialist

Andere Mitwirkende:

• Alessandro Vozza | Senior Technical Specialist

Um nicht-öffentliche LinkedIn-Profile zu sehen, melden Sie sich bei LinkedIn an.

Nächste Schritte

• Verwenden eines Dienstprinzipals mit AKS
• Containerschutz in Defender for Cloud
• Planen der Bereitstellung von Defender for Servers
• Containerüberwachungslösung in Azure Monitor
• Microsoft Sentinel
• Container-Image-Builds und deren Wartung mithilfe von Container-Registry-Tasks automatisieren

Verwandte Ressourcen

• Erweiterte AKS-Microservices-Architektur.
• CI/CD für Microservices-Architekturen
• CI/CD für Microservices auf Kubernetes