Bearbeiten

Erweiterte Microservicearchitektur in Azure Kubernetes Service (AKS)

Azure Application Gateway
Azure Container Registry
Azure Kubernetes Service (AKS)
Azure Virtual Network

Diese Referenzarchitektur beschreibt mehrere Konfigurationen, die beim Ausführen von Microservices in Azure Kubernetes Services zu berücksichtigen sind. Die Themen umfassen das Konfigurieren von Netzwerkrichtlinien, die automatische Skalierung von Pods sowie die verteilte Ablaufverfolgung in einer auf Microservices basierenden Anwendung.

Diese Architektur baut auf der AKS-Baselinearchitektur auf, dem von Microsoft empfohlenen Ausgangspunkt für die AKS-Infrastruktur. Die AKS-Baseline enthält Infrastrukturfeatures wie Microsoft Entra-Workloadidentität, Einschränkungen für ein- und ausgehende Daten, Ressourcenlimits und andere sichere AKS-Infrastrukturkonfigurationen. Diese Infrastrukturdetails werden in diesem Dokument nicht behandelt. Es wird empfohlen, sich mit der AKS-Baseline vertraut zu machen, bevor Sie mit dem Microserviceinhalt fortfahren.

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

Aufbau

Network diagram showing the hub-spoke network with two peered virtual networks and the Azure resources this implementation uses.

Laden Sie eine Visio-Datei dieser Architektur herunter.

Wenn Sie lieber mit einem einfacheren Beispiel für Microservices in AKS beginnen möchten, finden Sie dies unter Microservicearchitektur in AKS.

Workflow

Dieser Anforderungsfluss implementiert die Cloudentwurfsmuster Publisher-Subscriber (Herausgeber-Abonnent), Competing Consumers (Konkurrierende Consumer) und Gateway Routing. Der Messagingfluss wird wie folgt fortgesetzt:

  1. Eine HTTPS-Anforderung wird gesendet, um eine Drohnenabholung zu planen. Die Anforderungen durchlaufen Azure Application Gateway in die Erfassungswebanwendung, die als clusterinterner Microservice in AKS ausgeführt wird.

  2. Die Erfassungswebanwendung erzeugt eine Nachricht und sendet sie an die Service Bus-Nachrichtenwarteschlange.

  3. Das Back-End-System weist eine Drohne zu und benachrichtigt den Benutzer. Der Workflow:

    • Nutzt Nachrichteninformationen aus der Service Bus-Nachrichtenwarteschlange.
    • Sendet eine HTTPS-Anforderung an den Delivery-Microservice (Lieferung), der Daten an externen Datenspeicher von Azure Cache for Redis übergibt.
    • Sendet eine HTTPS-Anforderung an den „Drone Scheduler“-Microservice (Drohnenzeitplaner).
    • Sendet eine HTTPS-Anforderung an den Package-Microservice (Paket), der Daten an externen MongoDB-Datenspeicher übergibt.

  4. Eine HTTPS GET-Anforderung wird verwendet, um den Lieferstatus zurückzugeben. Diese Anforderung durchläuft Application Gateway in den Delivery-Microservice.

  5. Der Delivery-Microservice liest Daten aus Azure Cache for Redis.

Komponenten

Diese Architektur verwendet die folgenden Azure-Komponenten:

Azure Kubernetes Service ist ein Azure-Angebot, das einen verwalteten Kubernetes-Cluster bereitstellt. Bei Verwendung von AKS wird der Kubernetes-API-Server von Azure verwaltet. Die Kubernetes-Knoten oder -Knotenpools sind zugänglich und können vom Clusteroperator verwaltet werden.

Die in dieser Architektur verwendeten AKS-Infrastrukturfeatures umfassen Folgendes:

Azure Virtual Networks sind isolierte und hochsichere Umgebungen zum Ausführen virtueller Computer (VMs) und Anwendungen. Diese Referenzarchitektur verwendet eine gepeerte virtuelle Hub-Spoke-Netzwerktopologie. Das virtuelle Hubnetzwerk enthält die Subnetze von Azure Firewall und Azure Bastion. Das virtuelle Spoke-Netzwerk enthält die Subnetze des AKS-Systems und des Benutzerknotenpools sowie das Azure Application Gateway-Subnetz.

Azure Private Link ordnet bestimmte private IP-Adressen zu, um von privaten Endpunkten innerhalb des AKS-Systems und des Subnetzes des Benutzerknotenpools aus auf Azure Container Registry und Key Vault zuzugreifen.

Azure Application Gateway , zusammen mit Web Application Firewall (WAF), macht HTTP(S)-Routen für den AKS-Cluster verfügbar und führt einen Lastenausgleich des Webdatenverkehrs für die Webanwendung durch. Diese Architektur verwendet den Azure Application Gateway-Eingangsdatencontroller (AGIC) als Kubernetes-Eingangsdatencontroller.

Azure Bastion bietet sicheren Remotedesktopprotokoll- (RDP) und SSH-Zugriff (Secure Shell) auf VMs in den virtuellen Netzwerken durch Verwendung einer Secure Socket Layer („Schicht sicherer Sockets“, SSL), ohne dass die VMs über öffentliche IP-Adressen verfügbar gemacht werden müssen.

Azure Firewall ist ein Netzwerksicherheitsdienst, der alle Azure Virtual Network-Ressourcen schützt. Die Firewall lässt nur genehmigte Dienste und vollqualifizierte Domänennamen (FQDNs) als ausgehenden Datenverkehr zu.

Externer Speicher und andere Komponenten:

Azure Key Vault speichert und verwaltet Sicherheitsschlüssel für AKS-Dienste.

Azure Container Registry speichert private Containerimages, die im AKS-Cluster ausgeführt werden können. AKS führt die Authentifizierung bei Container Registry mit seiner verwalteten Microsoft Entra-Identität durch. Sie können auch andere Containerregistrierungen nutzen, z. B. Docker Hub.

Azure Cosmos DB speichert Daten mithilfe der Open-Source-Lösung Azure Cosmos DB for MongoDB. Microservices sind normalerweise zustandslos und schreiben ihren Zustand in externe Datenspeicher. Azure Cosmos DB is eine NoSQL-Datenbank mit Open-Source-APIs for MongoDB und Cassandra.

Azure Service Bus bietet zuverlässiges Cloud-Messaging-as-a-Service (MaaS) und einfache Hybridintegration. Service Bus unterstützt asynchrone Messagingmuster, die bei Microserviceanwendungen üblich sind.

Azure Cache for Redis fügt der Anwendungsarchitektur eine Zwischenspeicherungsebene hinzu, um die Geschwindigkeit und Leistung bei hohen Datenverkehrslasten zu verbessern.

Azure Monitor erfasst und speichert Metriken und Protokolle, einschließlich Anwendungstelemetriedaten sowie Azure-Plattform- und -Dienstmetriken. Sie können diese Daten verwenden, um die Anwendung zu überwachen, Warnungen und Dashboards einzurichten sowie Analysen der Grundursache von Fehlern durchzuführen.

Andere OSS-Komponenten (Operations Support System):

Helm ist ein Paket-Manager für Kubernetes, der Kubernetes-Objekte als einzelne Einheit bündelt, die Sie veröffentlichen, bereitstellen, mit einer Versionsangabe versehen und aktualisieren können.

Azure Key Vault Secret Store-CSI-Anbieter ruft in Azure Key Vault gespeicherte Geheimnisse ab und verwendet die CSI-Treiberschnittstelle des Geheimnisspeichers, um sie in Kubernetes-Pods einzubinden.

Flux , eine offene und erweiterbare Continuous Delivery-Lösung für Kubernetes, die vom GitOps-Toolkit unterstützt wird.

Szenariodetails

Die im vorherigen Diagramm gezeigte Fabrikam Drone Delivery Shipping-Beispiel-App implementiert die in diesem Artikel beschriebenen Architekturkomponenten und -methoden. In diesem Beispiel verwaltet Fabrikam, Inc., ein fiktives Unternehmen, eine Flotte von Drohnen. Unternehmen registrieren sich bei dem Dienst, und Benutzer können eine Drohne anfordern, die auszuliefernde Waren abholt. Wenn ein Kunde einen Abholtermin festlegt, weist das Back-End-System eine Drohne zu und teilt dem Benutzer die voraussichtliche Lieferzeit mit. Während der Durchführung der Lieferung kann der Kunde die Position der Drohne mit einer kontinuierlich aktualisierten ETA nachverfolgen.

Mögliche Anwendungsfälle

Diese Lösung eignet sich ideal für die Flugzeug-, Raumfahrt- und Luftfahrtindustrie.

Empfehlungen

Implementieren Sie diese Empfehlungen, wenn Sie erweiterte AKS-Microservicearchitekturen bereitstellen.

Application Gateway-Eingangscontroller (AGIC)

API-Gatewayrouting ist ein allgemeines Microserviceentwurfsmuster. Ein API-Gateway fungiert als Reverseproxy, der Anforderungen von Clients an Microservices weiterleitet. Die Kubernetes-Eingangsressource und der Eingangsdatencontroller verarbeiten die meisten API-Gatewayfunktionen wie folgt:

Clientanforderungen werden an die richtigen Back-End-Dienste weitergeleitet, was einen einzelnen Endpunkt für Clients bereitstellt und dabei hilft, Clients von Diensten zu entkoppeln.

  • Mehrere Anforderungen werden in einer einzelnen Anforderung aggregiert, um „Chatter“ zwischen dem Client und dem Back-End zu verringern.
  • Funktionalitäten wie SSL-Terminierung, Authentifizierung, IP-Einschränkungen sowie Clientratenbegrenzung oder Drosselung werden von den Back-End-Diensten abgeladen.

Der Zustand des AKS-Clusters wird in eine Application Gateway-spezifische Konfiguration übersetzt und mittels Azure Resource Manager angewendet.

Externe Eingangsdatencontroller vereinfachen die Erfassung von Datenverkehr in AKS-Clustern, verbessern die Sicherheit und Leistung und sparen Ressourcen. Diese Architektur verwendet den Azure Application Gateway-Eingangsdatencontroller (AGIC) für die Eingangsdatensteuerung. Wenn Sie Application Gateway verwenden, um den gesamten Datenverkehr zu verarbeiten, ist kein zusätzlicher Lastenausgleich mehr notwendig. Da Pods direkte Verbindungen mit Application Gateway herstellen, verringert sich die Anzahl der erforderlichen Hops, was zu einer besseren Leistung führt.

Application Gateway verfügt über integrierte Funktionen für die automatische Skalierung, im Gegensatz zu clusterinternen Eingangsdatencontrollern, die aufskaliert werden müssen, wenn sie eine unerwünschte Menge an Computeressourcen verbrauchen. Application Gateway kann Layer-7-Routing und SSL-Terminierung durchführen und verfügt über End-to-End-TLS (Transport Layer Security), die in eine integrierte Web Application Firewall (WAF) integriert ist.

Für die Datenerfassungsoption AGIC müssen Sie CNI-Netzwerke aktivieren, wenn Sie den AKS-Cluster konfigurieren, da Application Gateway in einem Subnetz des virtuellen AKS-Netzwerks bereitgestellt wird. Mehrinstanzenfähige Workloads oder ein einzelner Cluster, der Entwicklungs- und Testumgebungen unterstützt, könnten mehr Eingangsdatencontroller erfordern.

Zero Trust-Netzwerkrichtlinien

Netzwerkrichtlinien geben an, wie AKS-Pods miteinander und mit anderen Netzwerkendpunkten kommunizieren dürfen. Standardmäßig ist jeglicher ein- und ausgehender Datenverkehr zu und von Pods zulässig. Wenn Sie entwerfen, wie Ihre Microservices miteinander und mit anderen Endpunkten kommunizieren, sollten Sie die Berücksichtigung eines Zero Trust-Prinzips in Betracht ziehen, bei dem der Zugriff auf einen Dienst, ein Gerät, eine Anwendung oder ein Datenrepository eine explizite Konfiguration erfordert.

Eine Strategie zur Implementierung einer Zero Trust-Richtlinie besteht darin, eine Netzwerkrichtlinie zu erstellen, die jeglichen ein- und ausgehenden Datenverkehr zu und von allen Pods innerhalb des Zielnamespace verweigert. Das folgende Beispiel zeigt eine „Alles verweigern“-Richtlinie, die für alle Pods gelten würde, die sich im Namespace „backend-dev“ befinden.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-all
  namespace: backend-dev
spec:
  podSelector: {}
  policyTypes:
  - Ingress
  - Egress

Sobald eine restriktive Richtlinie festgelegt ist, beginnen Sie damit, bestimmte Netzwerkregeln zu definieren, um ein- und ausgehenden Datenverkehr bei jedem Pod im Microservice zuzulassen. Im folgenden Beispiel wird die Netzwerkrichtlinie auf alle Pods im Namespace „backend-dev“ mit einer Bezeichnung angewendet, die app.kubernetes.io/component: backend entspricht. Die Richtlinie verweigert jeglichen Datenverkehr, es sei denn, er stammt von einem Pod mit einer Bezeichnung, die app.kubernetes.io/part-of: dronedelivery entspricht.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: package-v010-dev-np-allow-ingress-traffic
  namespace: backend-dev
spec:
  podSelector:
    matchLabels:
      app.kubernetes.io/component: backend
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app.kubernetes.io/part-of: dronedelivery
    ports:
    - port: 80
      protocol: TCP

Weitere Informationen zu Kubernetes-Netzwerkrichtlinien und weitere Beispiele für potenzielle Standardrichtlinien finden Sie unter Netzwerkrichtlinien in der Kubernetes-Dokumentation.

Ressourcenkontingente

Ressourcenkontingente sind eine Möglichkeit für Administratoren, um Ressourcen innerhalb eines Entwicklungsteams oder Projekts zu reservieren und zu begrenzen. Sie können Ressourcenkontingente für einen Namespace festlegen und diese verwenden, um Grenzwerte festzulegen für:

  • Computeressourcen, z.B. CPU und Arbeitsspeicher oder GPUs.
  • Speicherressourcen, einschließlich der Anzahl der Volumes oder der Speicherplatzmenge für eine angegebene Speicherklasse.
  • Objektanzahl, z. B die maximale Anzahl von Geheimnissen, Diensten oder Aufträgen, die erstellt werden können.

Sobald die kumulierte Summe der Ressourcenanforderungen oder -grenzwerte das zugewiesene Kontingent überschreitet, sind keine weiteren Bereitstellungen möglich.

Ressourcenkontingente stellen sicher, dass der gesamte Satz von Pods, der dem Namespace zugewiesen ist, das Ressourcenkontingent des Namespace nicht überschreiten kann. Das Front-End kann die Back-End-Dienste hinsichtlich Ressourcen nicht blockieren (oder umgekehrt).

Wenn Sie Ressourcenkontingente definieren, müssen alle im Namespace erstellten Pods in ihren Podspezifikationen Grenzwerte oder Anforderungen enthalten. Wenn diese Werte nicht angeben werden, wird die Bereitstellung abgelehnt.

Das folgende Beispiel zeigt eine Podspezifikation, die Ressourcenkontingentanforderungen und -grenzwerte festlegt:

requests:
  cpu: 100m
  memory: 350Mi
limits:
  cpu: 200m
  memory: 500Mi

Weitere Informationen zu Ressourcenkontingenten finden Sie unter:

Automatische Skalierung

Kubernetes unterstützt automatische Skalierung, um die Anzahl der Pods zu erhöhen, die einer Bereitstellung zugeordnet sind, oder um die Knoten im Cluster zu erhöhen, um die insgesamt verfügbaren Computeressourcen zu erhöhen. Automatische Skalierung ist ein selbstkorrigierendes autonomes Feedbacksystem. Zwar können Sie Pods und Knoten manuell skalieren, doch die automatische Skalierung minimiert die Wahrscheinlichkeit, dass Dienste bei hoher Auslastung hinsichtlich Ressourcen blockiert werden. Bei einer Strategie für die automatische Skalierung müssen sowohl Pods als auch Knoten berücksichtigt werden.

Automatische Skalierung von Clustern

Die Cluster-Autoskalierung (CA) skaliert die Anzahl der Knoten. Falls Pods aufgrund von Ressourceneinschränkungen nicht geplant werden können, stellt die automatische Skalierung des Clusters mehr Knoten bereit. Sie definieren eine Mindestzahl von Knoten, um den AKS-Cluster und Ihre Workloads in Betrieb zu halten, sowie eine Höchstzahl von Knoten für hohen Datenverkehr. Die Cluster-Autoskalierung überprüft alle paar Sekunden auf ausstehende Pods oder leere Knoten und skaliert den AKS-Cluster entsprechend.

Das folgende Beispiel zeigt die Konfiguration der Cluster-Autoskalierung aus der ARM-Vorlage:

"autoScalerProfile": {
    "scan-interval": "10s",
    "scale-down-delay-after-add": "10m",
    "scale-down-delay-after-delete": "20s",
    "scale-down-delay-after-failure": "3m",
    "scale-down-unneeded-time": "10m",
    "scale-down-unready-time": "20m",
    "scale-down-utilization-threshold": "0.5",
    "max-graceful-termination-sec": "600",
    "balance-similar-node-groups": "false",
    "expander": "random",
    "skip-nodes-with-local-storage": "true",
    "skip-nodes-with-system-pods": "true",
    "max-empty-bulk-delete": "10",
    "max-total-unready-percentage": "45",
    "ok-total-unready-count": "3"
},

In den folgenden Zeilen in der ARM-Vorlage werden die minimalen und maximalen Knoten für die Cluster-Autoskalierung festgelegt:

"minCount": 2,
"maxCount": 5,

Automatische Skalierung von Pods

Die horizontale automatische Podskalierung (Horizontal Pod Autoscaler, HPA) skaliert Pods auf Grundlage der beobachteten CPU-, Arbeitsspeicher- oder benutzerdefinierten Metriken. Zum Konfigurieren der horizontalen Podskalierung geben Sie Zielmetriken sowie die Mindest- und Höchstzahl von Replikaten in der Kubernetes-Bereitstellungspodspezifikation an. Führen Sie einen Auslastungstest mit Ihren Diensten durch, um diese Zahlen zu ermitteln.

Cluster-Autoskalierung (CA) und HPA arbeiten gut zusammen. Aktivieren Sie also beide Autoskalierungsoptionen in Ihrem AKS-Cluster. HPA skaliert die Anwendung, während die Cluster-Autoskalierung die Infrastruktur skaliert.

Im folgenden Beispiel werden Ressourcenmetriken für HPA festgelegt:

apiVersion: autoscaling/v2beta2
kind: HorizontalPodAutoscaler
metadata:
  name: delivery-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: delivery
  minReplicas: 2
  maxReplicas: 5
  metrics:
    - type: Resource
      resource:
        name: cpu
        targetAverageUtilization: 60

HPA achtet auf die tatsächlich genutzten Ressourcen oder anderen Metriken ausgeführter Pods, aber die Cluster-Autoskalierung stellt Knoten für Pods bereit, die noch nicht geplant sind. Daher untersucht die Cluster-Autoskalierung die angeforderten Ressourcen, wie in der Podspezifikation angegeben. Verwenden Sie Auslastungstests, um diese Werte zu optimieren.

Integritätstests

Kubernetes führt einen Lastenausgleich für den Datenverkehr zu Pods aus, die mit einer Bezeichnungsauswahl für einen Dienst übereinstimmen. Nur Pods, die erfolgreich gestartet wurden und fehlerfrei sind, erhalten Datenverkehr. Falls ein Container abstürzt, entfernt Kubernetes den Pod und plant einen Ersatz.

In Kubernetes kann ein Pod zwei Arten von Integritätstests verfügbar machen:

  • Der Livetest teilt Kubernetes mit, ob ein Pod erfolgreich gestartet wurde und fehlerfrei ist.
  • Der Bereitschaftstest teilt Kubernetes mit, ob ein Pod bereit ist, Anforderungen zu akzeptieren.

Die Livetests verarbeiten Pods, die noch ausgeführt werden, aber fehlerhaft sind und neu gestartet werden sollten. Wenn z. B. ein Container, der HTTP-Anforderungen bedient, nicht mehr reagiert, stürzt der Container nicht ab, beendet aber die Verarbeitung von Anforderungen. Der HTTP-Livetest reagiert nicht mehr, was Kubernetes mitteilt, dass der Pod neu gestartet werden muss.

Es kann vorkommen, dass ein Pod noch nicht für den Empfang von Datenverkehr bereit ist, obwohl er erfolgreich gestartet wurde. Beispielsweise kann die Anwendung, die im Container ausgeführt wird, noch Initialisierungsaufgaben ausführen. Der Bereitschaftstest zeigt an, ob der Pod für den Empfang von Datenverkehr bereit ist.

Microservices sollten Endpunkte in ihrem Code verfügbar machen, die Integritätstests ermöglichen, wobei Verzögerung und Timeout speziell auf die von ihnen durchgeführten Tests zugeschnitten sein sollten. Die HPA-Formel verlässt sich fast ausschließlich auf die „Bereit“-Phase eines Pod. Daher ist es wichtig, dass Integritätstests vorhanden und genau sind.

Monitoring

In einer Microserviceanwendung ist die Überwachung der Anwendungsleistungsverwaltung (Application Performance Management, APM) wichtig, um Anomalien zu erkennen, Probleme zu diagnostizieren und die Abhängigkeiten zwischen Diensten schnell zu verstehen. Application Insights, das Bestandteil von Azure Monitor ist, bietet APM-Überwachung für Liveanwendungen, die in .NET Core, Node.js, Java und vielen anderen Anwendungssprachen geschrieben sind.

Application Insights:

  • Protokolliert HTTP-Anforderungen, einschließlich Wartezeit und Ergebniscode.
  • Aktiviert standardmäßig verteilte Ablaufverfolgung.
  • Umfasst eine Vorgangs-ID in Ablaufverfolgungen, damit Sie alle Ablaufverfolgungen für einen bestimmten Vorgang zuordnen können.
  • Enthält häufig zusätzliche Kontextinformationen in Ablaufverfolgungen.

Um Telemetriedaten von Diensten einen Kontext in der Kubernetes-Welt zu geben, integrieren Sie Azure Monitor-Telemetriedaten in AKS, um Metriken von Controllern, Knoten und Containern sowie um Container- und Knotenprotokolle zu erfassen. Wenn Sie .NET verwenden, reichert die Application Insights für Kubernetes-Bibliothek Application Insights-Telemetriedaten mit Image-, Container-, Knoten-, Pod-, Bezeichnungs- und Replikatgruppeninformationen an.

Das folgende Diagramm zeigt ein Beispiel für das Anwendungsabhängigkeitsdiagramm, das Application Insights für die Telemetrieablaufverfolgung eines AKS-Microservice generiert:

Example of an Application Insights dependency map for an AKS microservices application.

Weitere Informationen zu Optionen zum Instrumentieren gängiger Sprachen für die Application Insights-Integration finden Sie unter Anwendungsüberwachung für Kubernetes.

Überlegungen

Diese Überlegungen beruhen auf den Säulen des Azure Well-Architected Frameworks, d. h. einer Reihe von Grundsätzen, mit denen die Qualität von Workloads verbessert werden kann. Weitere Informationen finden Sie unter Microsoft Azure Well-Architected Framework.

Skalierbarkeit

Berücksichtigen Sie bei der Planung der Skalierbarkeit die folgenden Punkte.

  • Kombinieren Sie die automatisch Skalierung nicht mit der imperativen oder deklarativen Verwaltung der Anzahl von Replikaten. Benutzer und eine Autoskalierung, die beide versuchen, die Anzahl der Replikate zu ändern, können zu unerwartetem Verhalten führen. Wenn HPA aktiviert ist, verringern Sie die Anzahl der Replikate auf die Mindestzahl, die bereitgestellt werden soll.

  • Ein Nebeneffekt der automatischen Skalierung von Pods ist, dass Pods häufig erstellt oder ausgeschlossen werden können, wenn Ereignisse mit horizontalem Auf- und Abskalieren eintreten. So verringern Sie diese Auswirkungen

    • Verwenden Sie Bereitschaftstests, um Kubernetes mitzuteilen, wann ein neuer Pod Datenverkehr akzeptieren kann.
    • Nutzen Sie Budgets für die Unterbrechung von Pods, um einzuschränken, wie viele Pods gleichzeitig aus einem Dienst ausgeschlossen werden können.

  • Da Sie die VM-Größe nach dem Erstellen des Clusters nicht mehr ändern können, führen Sie zunächst eine Kapazitätsplanung durch. Hierbei können Sie eine geeignete VM-Größe für die Agent-Knoten wählen, die beim Erstellen des Clusters verwendet werden soll.

  • Für mehrinstanzenfähige oder andere erweiterte Workloads können Anforderungen an die Knotenpoolisolation vorliegen, die mehr und wahrscheinlich kleinere Subnetze erfordern. Weitere Informationen zum Erstellen von Knotenpools mit eindeutigen Subnetzen, finden Sie unter Hinzufügen eines Knotenpools mit einem eindeutigen Subnetz. Organisationen haben unterschiedliche Standards für ihre Hub-Spoke-Implementierungen. Achten Sie darauf, die Richtlinien Ihrer Organisation zu befolgen.

Verwaltbarkeit

Berücksichtigen Sie bei der Planung der Verwaltbarkeit die folgenden Punkte.

  • Verwalten Sie die AKS-Clusterinfrastruktur über eine automatisierte Bereitstellungspipeline. Die Referenzimplementierung für diese Architektur bietet einen GitHub Actions-Workflow, auf den Sie beim Erstellen Ihrer Pipeline verweisen können.

  • Die Workflowdatei stellt nur die Infrastruktur, nicht die Workload, in der bereits vorhandenen virtuellen Netzwerk- und Microsoft Entra-Konfiguration bereit. Durch die getrennte Bereitstellung von Infrastruktur und Workload können Sie unterschiedliche Lebenszyklus- und Betriebsbedenken behandeln.

  • Betrachten Sie Ihren Workflow als Mechanismus für die Bereitstellung in einer anderen Region, wenn ein regionaler Fehler vorliegt. Erstellen Sie die Pipeline so, dass Sie einen neuen Cluster in einer neuen Region mit Parameter- und Eingabeänderungen bereitstellen können.

Sicherheit

Sicherheit bietet Schutz vor vorsätzlichen Angriffen und dem Missbrauch Ihrer wertvollen Daten und Systeme. Weitere Informationen finden Sie unter Übersicht über die Säule „Sicherheit“.

Berücksichtigen Sie bei der Planung der Sicherheit die folgenden Punkte.

  • Ein AKS-Pod authentifiziert sich selbst mithilfe einer in Microsoft Entra ID gespeicherten Workloadidentität. Die Verwendung einer Workloadidentität ist vorzuziehen, da sie keinen geheimen Clientschlüssel erfordert.

  • Mit verwalteten Identitäten kann der ausführende Prozess schnell Azure Resource Manager OAuth 2.0-Token abrufen. Kennwörter oder Verbindungszeichenfolgen sind nicht erforderlich. In AKS können Sie einzelnen Pods Identitäten zuweisen, indem Sie eine Microsoft Entra-Workload-ID verwenden.

  • Jedem Dienst in der Microserviceanwendung sollte eine eindeutige Workloadidentität zugewiesen werden, um RBAC-Zuweisungen mit geringsten Rechten zu ermöglichen. Sie sollten nur Diensten Identitäten zuweisen, für die sie erforderlich sind.

  • In Fällen, in denen eine Anwendungskomponente Kubernetes-API-Zugriff erfordert, stellen Sie sicher, dass Anwendungspods für die Verwendung eines Dienstkontos mit API-Zugriff im entsprechenden Umfang konfiguriert sind. Weitere Informationen zum Konfigurieren und Verwalten von Kubernetes-Dienstkonten finden Sie unter Verwalten von Kubernetes-Dienstkonten.

  • Nicht alle Azure-Dienste unterstützen die Datenebenenauthentifizierung mit Microsoft Entra ID. Verwenden Sie Azure Key Vault zum Speichern von Anmeldeinformationen oder Anwendungsgeheimnissen für diese Dienste, für Dienste von Drittanbietern oder für API-Schlüssel. Azure Key Vault bietet eine zentrale Verwaltung, Zugriffssteuerung, Verschlüsselung von ruhenden Daten und Überwachung aller Schlüssel und Geheimnisse.

  • In AKS können Sie ein oder mehrere Geheimnisse aus Key Vault als Volume bereitstellen. Der Pod kann die Key Vault-Geheimnisse dann wie ein reguläres Volume lesen. Weitere Informationen finden Sie auf GitHub im Projekt secrets-store-csi-driver-provider-azure.

Kostenoptimierung

Bei der Kostenoptimierung geht es um die Suche nach Möglichkeiten, unnötige Ausgaben zu reduzieren und die Betriebseffizienz zu verbessern. Weitere Informationen finden Sie unter Übersicht über die Säule „Kostenoptimierung“.

  • Kostenaspekte werden im Kostenabschnitt des Microsoft Azure Well-Architected Framework beschrieben. Verwenden Sie den Azure-Preisrechner, um die Kosten für Ihr spezifisches Szenario abzuschätzen.

  • Bei der Bereitstellung, Verwaltung und dem Betrieb des Kubernetes-Clusters fallen in AKS keine Kosten an. Sie bezahlen nur die VM-Instanzen sowie die Speicher- und Netzwerkressourcen, die von Ihrem Cluster genutzt werden. Die automatische Clusterskalierung kann die Kosten des Clusters erheblich reduzieren, indem leere oder nicht verwendete Knoten entfernt werden.

  • Die voraussichtlichen Kosten der erforderlichen Ressourcen können Sie mithilfe des Preisrechners ermitteln.

  • Erwägen Sie die Aktivierung AKS-Kostenanalyse für die granulare Kostenzuordnung von Clusterinfrastrukturen durch Kubernetes spezifische Konstrukte.

Nächste Schritte