Microservicearchitektur in Azure Kubernetes Service

In dieser Referenzarchitektur wird veranschaulicht, wie eine Microserviceanwendung 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. Im Artikel werden in erster Linie die Infrastruktur- und DevOps-Aspekte der Verwaltung von Microservices auf AKS erläutert. Weitere Informationen zum Entwerfen von Microservices finden Sie unter Microservices-Architekturdesign.

Eine Referenzimplementierung dieser Architektur ist auf GitHub-verfügbar.

Aufbau

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.

Wenn Sie ein Beispiel für einen erweiterten Microservice sehen möchten, der auf der AKS-Basisarchitekturbasiert, lesen Sie die erweiterte AKS-Mikroservicesarchitektur.

Workflow

Dieser Anforderungsfluss implementiert den Herausgeberabonnent, konkurrierenden Verbraucherund Gatewayrouting Clouddesignmustern.

Der folgende Datenfluss entspricht dem vorherigen Diagramm:

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

   • Der verwaltete Eingangscontroller leitet die Anforderung an den Aufnahme-Microservice weiter.

   • Der Aufnahme-Microservice verarbeitet die Anforderungs- und Warteschlangenübermittlungsanforderungen in einer Azure Service Bus-Warteschlange.

2. Der Workflow-Microservice:

   • Nutzt Nachrichteninformationen aus der Service Bus-Nachrichtenwarteschlange.

   • Sendet eine HTTPS-Anforderung an den Übermittlungs-Microservice, der Daten an den externen Datenspeicher im Azure Cache für Redis übergibt.

   • Sendet eine HTTPS-Anforderung an den Drohnen-Planer 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 durchläuft den verwalteten Eingangscontroller an den Übermittlungs-Microservice. Anschließend liest der Übermittlungs-Microservice Daten aus dem Azure-Cache für Redis vor.

Weitere Informationen zur Microservices-Beispielanwendung finden Sie unter Microservices-Referenzimplementierungsbeispiel.

Komponenten

• AKS ist ein verwalteter Kubernetes-Cluster, der in der Azure-Cloud gehostet wird. AKS verringert die Komplexität und den operativen Mehraufwand für die Kubernetes-Verwaltung, indem ein Großteil dieser Verantwortung an Azure übertragen wird.

• An ingress server macht HTTP(S)-Routen für Dienste innerhalb des Clusters verfügbar. Die Referenzimplementierung verwendet einen verwalteten NGINX-basierten Eingangscontroller über ein Anwendungsrouting-Add-On. Der Eingangscontroller implementiert das API-Gateway Muster für Microservices.

• Externe Datenspeicher, z. B. Azure SQL-Datenbank oder Azure Cosmos DB, werden von zustandslosen Mikroservices zum Schreiben ihrer Daten und anderer Statusinformationen verwendet. Die Referenzimplementierung verwendet Azure Cosmos DB, Azure Cache für Redis, Azure Cosmos DB für MongoDB und Service Bus als Datenspeicher oder Orte zum Speichern des Zustands.

• Microsoft Entra ID ist für den AKS-Cluster erforderlich. Sie stellt eine verwaltete Identität bereit, die für den Zugriff auf die Azure-Containerregistrierung und für den Zugriff auf Azure-Ressourcen wie Lastenausgleichsgeräte und verwaltete Datenträger verwendet wird. Workloads, die auf einem AKS-Cluster bereitgestellt werden, erfordern außerdem eine Identität in Microsoft Entra, um auf microsoft entra-geschützte Ressourcen zuzugreifen, z. B. Azure Key Vault und Microsoft Graph. In dieser Referenzarchitektur Microsoft Entra Workload ID in Kubernetes integriert und Stellt Workloads mit Identitäten bereit. Sie können auch verwaltete Identitäten oder Anwendungsanmeldeinformationen für jede Workload verwenden.

• Containerregistrierung können verwendet werden, um private Containerimages zu speichern, die für den Cluster bereitgestellt werden. AKS kann sich mit der Containerregistrierung mithilfe seiner Microsoft Entra-Identität authentifizieren. In der Referenzimplementierung werden Microservice-Containerimages erstellt und an die Containerregistrierung übertragen.

• Azure Pipelines ist Teil der Azure DevOps-Suite und führt automatisierte Builds, Tests und Bereitstellungen aus. Ein kontinuierliche Integration und kontinuierliche Bereitstellung (CI/CD) Ansatz wird in Mikroserviceumgebungen dringend gefördert. Verschiedene Teams können microservices unabhängig mithilfe von Azure-Pipelines auf AKS erstellen und bereitstellen.

• 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 veröffentlicht, bereitgestellt, versionsiert und aktualisiert werden kann.

• Azure Monitor erfasst und speichert Metriken und Protokolle, Anwendungstelemetrie und Plattformmetriken für Azure-Dienste. Azure Monitor wird mit AKS integriert, um Metriken von Controllern, Knoten und Containern zu erfassen.

• Application Insights überwacht Microservices und Container. Sie kann verwendet werden, um Mikroservices zu beobachten, einschließlich Datenverkehrsfluss, End-to-End-Latenz und Fehlerprozentsatz. Die Integrität der Microservices und die Beziehungen zwischen ihnen können auf einer einzelnen Anwendungszuordnung angezeigt werden.

Alternativen

Azure Container Apps bietet eine verwaltete Serverlose Kubernetes-Erfahrung. 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 des verwalteten Eingangsgateways in AKS können Sie Alternativen wie Anwendungsgateway für Container, Istio-Eingangsgateway 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 Microservices, die Zustandsinformationen verwalten müssen, stellt Dapr eine Abstraktionsebene für die Verwaltung des Microservice-Zustands bereit.

Sie können GitHub-Aktionen 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

Das Beispiel Microservice-Referenzimplementierung implementiert die in diesem Artikel beschriebenen Architekturkomponenten und -praktiken. In diesem Beispiel verwaltet ein fiktives Unternehmen namens Fabrikam, Inc., 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.

Das Szenario zielt darauf ab, die Microservices-Architektur und die bewährten Methoden für die Bereitstellung in AKS zu veranschaulichen.

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

Überlegungen

Diese Überlegungen bilden die Säulen des Azure Well-Architected Framework, einer Reihe von Leitprinzipien, die Sie zur Verbesserung der Qualität eines Workloads verwenden können. Weitere Informationen finden Sie unter Microsoft Azure Well-Architected Framework.

Entwurf

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.

Datenspeicher

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 Option besteht darin, ein persistentes Datenvolume mithilfe von Azure Disk Storage oder Azure Files auf einer Lösung bereitzustellen. Weitere Informationen finden Sie unter Speicheroptionen für Anwendungen 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 querschnittsübergreifende Aufgaben ausführen, z. B. Authentifizierung, SSL-Beendigung (Secure Sockets Layer) und Ratelimitierung. 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 Eingangs- und Eingangscontroller funktioniert in Verbindung mit:

• 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.

• Offload-Funktionalität von den Back-End-Diensten, z. B. SSL-Beendigung, Authentifizierung, IP-Adressbeschränkungen oder Clientratenbeschränkungen (Einschränkunggenannt).

Es gibt Eingangscontroller für Reverseproxys, darunter NGINX, HAProxy, Traefik und Azure Application Gateway. AKS bietet mehrere verwaltete Eingangsoptionen. Sie können über das Anwendungsrouting-Add-On Application Gateway für Container aus einem verwalteten NGINX-basierten Eingangscontroller auswählen. Alternativ können Sie das Istio-Eingangsgateway als Eingangscontroller auswählen. Weitere Informationen finden Sie unter Ingress in AKS.

Die Eingangsressourcen Kubernetes-Objekte wurden durch die komplexere und vielseitige Kubernetes-Gateway-API ersetzt. Eingangscontroller und Gateway-API sind sowohl Kubernetes-Objekte, die für das Datenverkehrsverwaltungsrouting als auch für den Lastenausgleich verwendet werden. Die Gateway-API ist für die Definition von L4- und L7-Routingregeln in Kubernetes als generische, ausdrucksstarke, erweiterbare und rollenorientierte API konzipiert.

Der Eingangscontroller fungiert als Edgerouter oder Reverseproxy. Ein Reverseproxyserver ist ein potenzieller Engpass oder einzelner Fehlerpunkt. Daher wird empfohlen, mindestens zwei Replikate bereitzustellen, um eine hohe Verfügbarkeit sicherzustellen.

Gründe für die Auswahl von Eingangscontrollern oder Gateway-API

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, besteht möglicherweise kein sofortiger Übergang zur Kubernetes-Gateway-API.

Sie sollten die Gateway-API verwenden:

• Wenn Sie sich mit komplexen Routingkonfigurationen, Datenverkehrsteilungen und erweiterten Strategien für die Datenverkehrsverwaltung befassen. Die Flexibilität der Routenressourcen der Kubernetes-Gateway-API ist von entscheidender Bedeutung.

• 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.

Zuverlässigkeit

Zuverlässigkeit stellt sicher, dass Ihre Anwendung Ihre Verpflichtungen gegenüber den Kunden erfüllen kann. 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 in demselben Cluster bereitstellen und ggf. Hunderte von Microservices vorhanden sind, wird die Verwaltung schwierig, falls alle in demselben Namespace enthalten sind. Namespaces ermöglichen Ihnen außerdem Folgendes:

• 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, können Sie Namespaces als praktischen Mechanismus verwenden, um Bereiche zu steuern, für die jedes Team bereitstellen kann. So kann z. B. dem Entwicklungsteam A nur Zugriff auf Namespace A gewährt werden, und das Entwicklungsteam B kann nur Zugriff auf Namespace B über Kubernetes RBAC-Richtlinienerhalten.

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

Ordnen Sie Hilfsdienste in einem separaten Namespace an. Beispielsweise können Sie Clusterüberwachungstools wie Elasticsearch und Prometheus in einem Überwachungsnamespace bereitstellen.

Integritätstests

Kubernetes definiert drei Arten von Integritätssonden, 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.

Wenn Sie über Probes nachdenken, ist es wichtig, sich daran zu erinnern, wie ein Dienst in Kubernetes funktioniert. Ein Dienst verfügt über einen Bezeichnungsmarkierer, der einer Gruppe von null oder mehr Pods entspricht. 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, erhalten Datenverkehr. Wenn ein Container abstürzt, beendet Kubernetes den Pod und plant einen Ersatz.

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

Liveness-Probes werden verwendet, um zu überprüfen, ob ein Pod ausgeführt wird, aber nicht ordnungsgemäß funktioniert und neu gestartet werden muss. Wenn beispielsweise ein Container 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 eine Liveness-Sonde einrichten, wird festgestellt, dass ein Container nicht reagiert und Kubernetes auffordert, den Pod neu zu starten, wenn der Container wiederholt den Probepunkt fehlschlägt.

Berücksichtigen Sie die folgenden Punkte beim Entwerfen von Probes für Microservices.

• Wenn Ihr Code eine lange Startzeit hat, besteht die Gefahr, dass ein Liveness-Prüfpunkt einen Fehler meldet, bevor der Start abgeschlossen ist. Um den Start einer Livenesssonde zu verzögern, verwenden Sie die Startsonde, oder verwenden Sie die initialDelaySeconds Einstellung mit der Livenesssonde.

• Eine Liveness-Sonde hilft nur, wenn der Neustart des Pods wahrscheinlich in einen fehlerfreien Zustand versetzt wird. Sie können eine Liveness-Sonde verwenden, um Speicherlecks oder unerwartete Deadlocks zu minimieren, aber es gibt keinen Grund, einen Pod neu zu starten, der sofort fehlschlägt.

• In einigen Fällen werden Bereitschaftstests genutzt, um abhängige Dienste zu überprüfen. 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 aber zu unerwarteten Problemen führen. Möglicherweise ist ein externer Dienst vorübergehend nicht verfügbar. Diese Nichtverfügbarkeit führt dazu, dass die Bereitschaftssonde für alle Pods in Ihrem Dienst fehlschlägt, was dazu führt, dass der Lastenausgleich entfernt wird. Durch diese Entfernung entstehen kaskadierende Fehler vorgelagert.

  Ein besserer Ansatz besteht darin, die Wiederholungsbehandlung innerhalb Ihres Diensts zu implementieren, damit Ihr Dienst bei vorübergehenden Fehlern ordnungsgemäß wiederhergestellt werden kann. Alternativ können Wiederholungsbehandlungs-, Fehlertoleranz- und Schaltkreisbrecher mithilfe des Istio-Dienstgitters implementiert werden, um eine robuste Architektur zu erstellen, die Mikroservicefehler verarbeiten kann.

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 das Front-End die Back-End-Dienste nicht für Ressourcen oder umgekehrt verhungern kann. Ressourcenkontingente können dabei helfen, Ressourcen innerhalb desselben Clusters mehreren Microservice-Entwicklungsteams zuzuweisen.

Sicherheit

Sicherheit bietet Sicherheitsmaßnahmen gegen bewusste Angriffe und den Missbrauch Ihrer wertvollen Daten und Systeme. Weitere Informationen finden Sie unter Prüfliste zur Entwurfsüberprüfung für sicherheitsrelevante.

TLS- und SSL-Verschlüsselung

In vielen Implementierungen wird der Eingangscontroller für die SSL-Beendigung verwendet. Im Rahmen 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.

Rufen Sie für Produktionsworkloads signierte Zertifikate von vertrauenswürdigen Zertifizierungsstellen ab.

Möglicherweise müssen Sie Ihre Zertifikate auch je nach den Richtlinien der Organisation drehen. Sie können Key Vault verwenden, um Zertifikate zu drehen, die microservices verwenden. Weitere Informationen finden Sie unter Konfigurieren der automatischen Rotation von Zertifikaten in Key Vault.

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 die nutzungsbasierten Dienste oder Benutzer zum Authentifizieren und Autorisieren des Zugriffs auf den Microservice mithilfe von Zertifikaten, Anmeldeinformationen und RBAC-Mechanismen anfordern. Microsoft Entra-ID kann verwendet werden, um OAuth 2.0-Token für die Autorisierungzu implementieren. Dienstgitter wie Istio bieten auch Autorisierungs- und Authentifizierungsmechanismen für Microservices, einschließlich OAuth-Tokenüberprüfung und tokenbasiertes Routing. Die Referenzimplementierung deckt keine Microservice-Authentifizierungs- und Autorisierungsszenarien ab.

Geheimnisverwaltung und Anwendungsanmeldeinformationen

Anwendungen und Dienste benötigen häufig Anmeldeinformationen, mit denen sie sich an externen Diensten, z.B. Azure Storage oder SQL-Datenbank, anmelden können. Die Herausforderung besteht darin, diese Anmeldeinformationen sicher aufzubewahren und vor der Offenlegung zu schützen.

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 der Microsoft Entra-ID gespeichert ist. Sie verwendet diese Identität, um sich bei einem Azure-Dienst zu authentifizieren. Die Anwendung oder der Dienst hat einen Dienstprinzipal, der in der Microsoft Entra-ID erstellt und sich mithilfe von OAuth 2.0-Token authentifiziert. Der im Prozess ausgeführte Code 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 Microsoft Entra-Identitäten einzelnen Pods in AKS zuweisen, indem Sie Microsoft Entra Workload IDverwenden.

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 von Microsoft stammenden 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 können Sie einen oder mehrere geheime Schlüssel aus Key Vault als Volume bereitstellen. Das Volume liest die Geheimnisse aus Key Vault aus. Der Pod kann dann die geheimen Schlüssel wie ein normales Volume lesen. Weitere Informationen finden Sie unter Verwenden des Key Vault-Anbieters für den CSI-Treiber für den Geheimen Speicher in einem AKS-Cluster-. Der Pod authentifiziert sich selbst mithilfe einer Workloadidentität oder eines Benutzers oder einer vom System zugewiesenen verwalteten Identität. Weitere Informationen finden Sie unter Verbinden Ihres Azure-Identitätsanbieters mit dem Key Vault Secrets Store-CSI-Treiber in Azure Kubernetes Service (AKS).

• HashiCorp Vault: von Microsoft Entra verwaltete Identitäten ermöglichen Kubernetes-Anwendungen die Authentifizierung bei HashiCorp Vault. Sie können den Tresor 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. Die Geheimnisse werden in „etcd“ gespeichert, wobei es sich um einen verteilten Schlüssel-Wert-Speicher handelt. Bei AKS wird etcd im ruhenden Zustand verschlüsselt. Microsoft verwaltet die Verschlüsselungsschlüssel.

Die Verwendung einer Lösung wie Key Vault bietet mehrere Vorteile, darunter:

• Zentralisierte Steuerung der Geheimnisse
• Stellen Sie sicher, dass alle geheimen Schlüssel im Ruhezustand verschlüsselt sind.
• Zentrale Schlüsselverwaltung
• Zugriffssteuerung für Geheimnisse
• Schlüssellebenszyklusverwaltung.
• Rechnungsprüfung.

Die Referenzimplementierung speichert Azure Cosmos DB-Verbindungszeichenfolgen und andere geheime Schlüssel im Key Vault. Die Referenzimplementierung verwendet eine verwaltete Identität für Microservices, um sich bei Key Vault zu authentifizieren und geheime Schlüssel zuzugreifen.

Container- und Orchestratorsicherheit

Die folgenden empfohlenen Methoden können Ihnen dabei helfen, Ihre Pods und Container zu sichern.

• Ü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. Darüber hinaus können Sie Protokolle aus Containerüberwachungslösung in Azure Monitor integrieren, um Microsoft Sentinel oder eine vorhandene SIEM-Lösung (Security Information and Event Management) zu.

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

• Automatisieren sie das Patchen von Bildern. Verwenden Sie Azure Container Registry-Aufgaben, ein Feature der Containerregistrierung, um das Patchen von Images zu automatisieren. Ein Containerimage besteht aus verschiedenen Ebenen. Die Basisebenen enthalten das Betriebssystemimage und die Anwendungsframework-Images, 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 vorgelagert gepatcht werden, ist es wichtig, Ihre eigenen Images zu aktualisieren, zu testen und erneut bereitzustellen, damit Sie keine bekannten Sicherheitsrisiken hinterlassen. Azure Container Registry-Aufgaben können dabei helfen, diesen Prozess zu automatisieren.

• Speichern Sie Bilder in einer vertrauenswürdigen privaten Registrierung. Verwenden Sie eine vertrauenswürdige private Registrierung wie Containerregistrierung oder Docker Trusted Registry, um Bilder zu speichern. Verwenden Sie einen Validierungswebhook in Kubernetes, um sicherzustellen, dass Pods nur Bilder aus der vertrauenswürdigen Registrierung 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 zur Bereitstellung von CI/CD

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 Workloads in Containern können Sie den Containerimages vertrauen, die für die Produktion bereitgestellt werden.

Weitere Informationen zu den Herausforderungen finden Sie unter CI/CD für Microservicearchitekturen.

Die Verwendung eines Dienstgitters wie Istio kann bei CI/CD-Prozessen wie Canarybereitstellungen, A/B-Tests von Microservices und mehrstufigen Rollouts mit prozentbasierten Datenverkehrsteilungen helfen.

Weitere Informationen zu spezifischen Empfehlungen und bewährten Methoden finden Sie unter Erstellen einer CI/CD-Pipeline für Microservices auf Kubernetes mit Azure DevOps und 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 Prüfliste für die Überprüfung der Kostenoptimierung.

Verwenden Sie den Azure-Preisrechner, um die voraussichtlichen Kosten zu ermitteln. Weitere Überlegungen werden im Abschnitt Kosten in Microsoft Azure Well-Architected Frameworkbeschrieben.

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

AKS

• In der kostenlosen Stufefallen 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 die Verwendung horizontalen Pod-Autoskalierung, um Mikroservices automatisch zu skalieren oder sie je nach Last zu skalieren.

• Konfigurieren Sie Clusterautoskalierung so, dass die Knoten je nach Last skaliert oder skaliert werden.

• 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.

• Um die Kosten der erforderlichen Ressourcen zu schätzen, verwenden Sie den AKS-Rechner.

Azure Load Balancer

Die Gebühren werden nur anhand der Anzahl von konfigurierten Lastenausgleichsregeln und Ausgangsregeln berechnet. Eingehende Netzwerkadressenübersetzungsregeln sind kostenlos. Für Load Balancer Standard fallen keine Kosten auf Stundenbasis an, wenn keine Regeln konfiguriert sind. Weitere Informationen finden Sie unter Azure Load Balancer-Preis.

Azure Pipelines

Diese Referenzarchitektur verwendet nur Azure Pipelines. Azure stellt die Pipeline als einzelner Dienst bereit. Sie haben einen kostenlosen von Microsoft gehosteten Auftrag mit 1.800 Minuten für jeden Monat für CI/CD und einen selbst gehosteten Auftrag mit unbegrenzten Minuten für jeden Monat zugelassen. Zusätzliche Arbeitsplätze verursachen mehr Kosten. Weitere Informationen finden Sie unter Preise für Azure DevOps-Dienste.

Azure Monitor

Bei Nutzung von Azure Monitor Log Analytics werden Datenerfassung und -aufbewahrung in Rechnung gestellt. Weitere Informationen finden Sie unter Azure Monitor – Preise.

Operative Exzellenz

Operational Excellence deckt die Betriebsprozesse ab, mit denen eine Anwendung bereitgestellt und in der Produktion ausgeführt wird. Weitere Informationen finden Sie unter Prüfliste für die Überprüfung von Operational Excellence.

Diese Referenzarchitektur umfasst 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.

Beachten Sie die Kriterien für die Workloadisolation, um Ihre Bicep-Datei zu strukturieren. Eine Arbeitsauslastung wird in der Regel als beliebige Funktionalitätseinheit definiert. Sie können beispielsweise 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.

Bereitstellen dieses Szenarios

Führen Sie die Schritte im GitHub-Repository aus, um die Referenzimplementierung für diese Architektur bereitzustellen. Weitere Informationen finden Sie unter AKS Microservices-Referenzimplementierung.

Beitragende

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

Hauptautor:

• Francis Simy Nazareth | Senior Technical Specialist

Andere Mitwirkende:

• Paolo Salvatori | Leitender Kundeningenieur
• Alessandro Vossa | Senior Technical Specialist

Um nichtöffentliche LinkedIn-Profile anzuzeigen, 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 oder einer vorhandenen SIEM-Lösung
• Defender für Cloud oder eine Nicht-Microsoft-Lösung, die über Azure Marketplace verfügbar ist
• Automatisieren von Containerimagebuilds und -wartungen mit Azure-Containerregistrierungsaufgaben

Zugehörige Ressourcen

• Informationen zum Durcharbeiten eines komplexeren Microservices-Beispiels finden Sie unter Advanced AKS microservices architecture.
• Informationen dazu, wie wir die Leistung dieser Anwendung gemessen haben, finden Sie unter Leistungsoptimierungsszenario: Verteilte Geschäftstransaktionen.
• CI/CD für Microservices-Architekturen
• CI/CD für Microservices in Kubernetes