Freigeben über

Microservicearchitektur in Azure Kubernetes Service

Microsoft Entra ID
Azure Container Registry
Azure Kubernetes Service (AKS)
Azure Managed Redis
Azure Pipelines
Azure Monitor

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. Dieser Dienst bietet verbesserte Leistung, integrierte Durchsetzung von Netzwerkrichtlinien und verbesserte Überwachbarkeit über die erweiterte Extended Berkeley Packet Filter (eBPF)-basierte Datenebene. Weitere Informationen zum Entwerfen von Microservices finden Sie unter Microservices-Architekturdesign.

Architecture

Diagramm, das die Microservices auf der AKS-Referenzarchitektur zeigt.

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 (FQDN) des Load Balancers (managed ingress controller), um eine Drohnenabholung 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 führt die folgenden Aktionen aus:

    • Verwendet Nachrichteninformationen aus der Servicebus-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 durchläuft den verwalteten Eingangscontroller an den Übermittlungs-Microservice. Anschließend liest der Übermittlungs-Microservice Daten aus Azure Managed Redis vor.

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 virtuellen Azure-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 ein verwalteter NGINX-basierter Eingangscontroller über ein Anwendungsrouting-Add-On verwendet. Der Eingangscontroller implementiert das API-Gateway Muster für Microservices.

  • Externe Datenspeicher wie Azure SQL-Datenbank oder Azure Cosmos DB werden von zustandslosen Microservices 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 Orte 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 erfordert die Integration der Microsoft Entra-ID, um eine verwaltete Identität für den Zugriff auf die Azure-Containerregistrierung und die Bereitstellung von Azure-Ressourcen wie Lastenausgleichsmodulen und verwalteten Datenträgern bereitzustellen. Jede workload, die im AKS-Cluster bereitgestellt wird, 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 die Microsoft Entra Workload-ID , um sie 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 mit der Containerregistrierung mithilfe seiner Microsoft Entra-Identität authentifizieren. Microservice-Containerimages werden erstellt und an die Containerregistrierung übertragen. In dieser Architektur speichert die 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 auf AKS erstellen und bereitstellen. In dieser Architektur erstellt und stellt Azure Pipelines die Drohnen-Liefer-Microservices auf AKS 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 ist 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. Es kann die Observability für Microservices bereitstellen, einschließlich Datenfluss, 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 bietet, ohne dass die Infrastrukturverwaltung erforderlich ist. 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, ein 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 Netzwerke empfiehlt diese Architektur, aufgrund ihrer Leistung und integrierten Richtlinienerzwingung, Azure CNI, unterstützt von Cilium. Sie können jedoch alternative Netzwerkoptionen wie Azure CNI Overlay für spezielle Szenarien verwenden.

Von Bedeutung

Wenn Sie Windows-Knoten in Ihrer Microservices-Architektur benötigen, überprüfen Sie die aktuelle Linux-only-Einschränkung von Cilium, und planen Sie entsprechend für gemischte Betriebssystempools. Weitere Informationen finden Sie unter Einschränkungen von Azure CNI betrieben von Cilium.

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

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

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

Netzwerk- und Netzwerkrichtlinie

Verwenden Sie für Produktions-Microservices-Bereitstellungen auf AKS Azure CNI, unterstützt von Cilium als Netzwerklösung. 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.

  • Erzwingung von Netzwerkrichtlinien: Cilium erzwingt Kubernetes NetworkPolicy-Ressourcen, ohne dass ein separates Netzwerkrichtlinienmodul wie Azure Network Policy 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, unterstützt durch Cilium, unterstützt sowohl virtuelle Netzwerk-Routing- als auch Overlay-Pod-Adresszuweisungsmodelle basierend auf den Netzwerkarchitektur-Anforderungen Ihrer Arbeitslast.

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 "Alle verweigern"-Richtlinien, und erlauben Sie selektiv nur den erforderlichen Datenverkehr zwischen Microservices. 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:

In Kubernetes behandelt ein Eingangscontroller in erster Linie die Funktionalität eines API-Gateways. Die Ingress- und Ingress-Controller 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.

  • Offload-Funktionalität von den Back-End-Diensten, z. B. SSL-Beendigung, Authentifizierung, IP-Adresseinschränkungen oder Clientrateneinschränkung (auch als Einschränkung bezeichnet).

Es gibt Eingangscontroller für Reverseproxys, darunter NGINX, HAProxy, Traefik und Azure Application Gateway. AKS bietet mehrere verwaltete Eingangsoptionen. Sie können aus einem verwalteten NGINX-basierten Ingress-Controller über das Anwendungsrouting-Add-On oder das Application Gateway for Containers auswählen. Sie können auch ein Istio-Ingress-Gateway als Ingress-Controller 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 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.

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.

Partition 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 Hilfsdienste in einem separaten Namespace an. Sie können beispielsweise Clusterüberwachungstools wie Elasticsearch und Prometheus in einem Überwachungsnamespace bereitstellen.

Gesundheitsprüfungen

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.

Um Probes zu verstehen, überprüfen Sie zunächst, 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 nicht bereit, Datenverkehr zu empfangen, auch 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 diese langsamen Startcontainer verwenden. Dieser Ansatz verhindert, dass Kubernetes sie beenden, bevor sie die Möglichkeit haben, vollständig zu initialisieren.

Liveness-Prüfungen überprüfen, ob der Pod läuft, aber nicht ordnungsgemäß funktioniert und einen Neustart benötigt. 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 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 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 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 abzumildern, 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 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 kann das Istio-Dienstgitter die Wiederholungsbehandlung, Fehlertoleranz und Schaltschalter implementieren. Dieser Ansatz erstellt eine robuste Architektur, die Mikroservicefehler behandeln kann.

Verwenden Sie zum Beheben von Microservice-Integritätsproblemen die Netzwerkbeobachtbarkeitsfeatures 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 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. 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.

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

Je nach den Richtlinien Ihrer Organisation müssen Sie möglicherweise auch Ihre Zertifikate erneuern. Sie können Key Vault verwenden, um Zertifikate zu drehen, die microservices verwenden. Weitere Informationen finden Sie unter Konfigurieren der automatischen Rotation des Zertifikats im Key Vault.

Netzwerksegmentierung und Richtlinien

Implementieren Sie die Netzwerksegmentierung zwischen Mikroservices mithilfe von Kubernetes NetworkPolicy-Ressourcen. Wenn Sie Azure CNI verwenden, das von Cilium unterstützt wird, erzwingt die eBPF-Datenebene Netzwerkrichtlinien.

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

  • Wenden Sie Zero-Trust-Prinzipien an. 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 die nutzungsbasierten Dienste oder Benutzer zum Authentifizieren und Autorisieren des Zugriffs auf den Microservice mithilfe von Zertifikaten, Anmeldeinformationen und RBAC-Mechanismen anfordern. Sie können die 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 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 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 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 einer vom Benutzer zugewiesenen oder vom System zugewiesenen verwalteten Identität. Weitere Informationen finden Sie unter Verbinden Ihres Azure-Identitätsanbieters mit dem CSI-Treiber "Key Vault Secrets Store" in AKS.

  • HashiCorp Vault: Von Microsoft Entra verwaltete Identitäten ermöglichen Kubernetes-Anwendungen die Authentifizierung mit 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. Geheimnisse werden in etcd gespeichert, bei dem es sich um einen verteilten Schlüsselwertspeicher handelt. Bei AKS wird etcd im ruhenden Zustand verschlüsselt. Microsoft verwaltet die Verschlüsselungsschlüssel.

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

  • Zentrale Kontrolle von geheimen Schlüsseln
  • Verschlüsselung ruhender Geheimnisse
  • Zentrale Schlüsselverwaltung
  • Zugriffssteuerung geheimer Schlüssel
  • Zentrales Lebenszyklusmanagement
  • Auditing

Diese Architektur 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 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 Containerüberwachungslösung in Azure Monitor inMicrosoft Sentinel oder eine vorhandene SIEM-Lösung (Security Information and Event Management) integrieren.

  • Ü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 Container-Registrierungsdienste, um das Patchen von Images zu automatisieren. Ein Containerimage besteht aus verschiedenen Ebenen. Die Basisebenen umfassen das Betriebssystemimage und Anwendungsframeworkimages wie 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 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 Microservices-Architekturen.

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.

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.

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

Azure-Lastenausgleich

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 Azure-Pipelines für CI/CD-Aufgaben. 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

Für Log Analytics werden Ihnen Dateneinnahme 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.

Contributors

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

Hauptautor:

Andere Mitwirkende:

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

Nächste Schritte