Freigeben über

Migrieren Ihrer Workload von Service Fabric zu AKS

  • Artikel

Viele Organisationen wechseln zu containerisierten Apps als Teil eines Pushs, um moderne App-Entwicklung, bewährte Methoden für die Wartung und cloudeigene Architekturen zu übernehmen. Da sich Technologien weiter entwickeln, müssen Organisationen die vielen containerisierten App-Plattformen auswerten, die in der öffentlichen Cloud verfügbar sind.

Es gibt keine Einheitslösung für Apps, aber Organisationen stellen häufig fest, dass Azure Kubernetes Service (AKS) die Anforderungen für viele ihrer containerisierten Anwendungen erfüllt. AKS ist ein verwalteter Kubernetes-Dienst, der Anwendungsbereitstellungen über Kubernetes vereinfacht, indem die Steuerungsebene verwaltet wird, um Kerndienste für Anwendungsworkloads bereitzustellen. Viele Organisationen verwenden AKS als primäre Infrastrukturplattform und Übergangsworkloads, die auf anderen Plattformen auf AKS gehostet werden.

In diesem Artikel wird beschrieben, wie containerisierte Apps von Azure Service Fabric zu AKS migriert werden. In diesem Artikel wird davon ausgegangen, dass Sie mit Service Fabric vertraut sind, aber daran interessiert sind, zu erfahren, wie die Features und Funktionen von Service Fabric im Vergleich zu AKS aussehen. Der Artikel enthält auch bewährte Methoden, die Sie während der Migration berücksichtigen sollten.

Vergleich von AKS mit Service Fabric

Lesen Sie zunächst "Auswählen eines Azure-Computediensts" zusammen mit anderen Azure-Computediensten. In diesem Abschnitt werden bemerkenswerte Ähnlichkeiten und Unterschiede erläutert, die für die Migration relevant sind.

Sowohl Service Fabric als auch AKS sind Containerorchestratoren. Service Fabric bietet Unterstützung für mehrere Programmiermodelle, aber AKS unterstützt nur Container.

  • Programmiermodelle: Service Fabric unterstützt mehrere Möglichkeiten zum Schreiben und Verwalten Ihrer Dienste, einschließlich Linux- und Windows-Containern, Reliable Services, Reliable Actors, ASP.NET Core und ausführbaren Gastdateien.

  • Container auf AKS: AKS unterstützt nur die Containerisierung mit Windows- und Linux-Containern, die auf containerlaufzeitcontainern ausgeführt werden, die automatisch verwaltet werden.

Sowohl Service Fabric als auch AKS bieten Integrationen mit anderen Azure-Diensten, einschließlich Azure Pipelines, Azure Monitor, Azure Key Vault und Microsoft Entra ID.

Wesentliche Unterschiede

Wenn Sie einen herkömmlichen Service Fabric-Cluster anstelle eines verwalteten Clusters bereitstellen, müssen Sie eine Clusterressource explizit mit vielen unterstützenden Ressourcen in Ihren Azure Resource Manager-Vorlagen (ARM-Vorlagen) oder Bicep-Modulen definieren. Zu diesen Ressourcen gehört eine VM-Skalierungsgruppe für jeden Clusterknotentyp, Netzwerksicherheitsgruppen und Lastenausgleichsmodule. Es liegt in Ihrer Verantwortung, sicherzustellen, dass diese Ressourcen ordnungsgemäß konfiguriert sind. Im Gegensatz dazu besteht das Kapselungsmodell für verwaltete Service Fabric-Cluster aus einer einzigen verwalteten Clusterressource. Alle zugrunde liegenden Ressourcen für den Cluster werden abstrahiert und von Azure verwaltet.

AKS vereinfacht die Bereitstellung eines verwalteten Kubernetes-Clusters in Azure, indem der Betriebsaufwand in Azure deaktiviert wird. Das AKS ein gehosteter Kubernetes-Dienst ist, führt Azure wichtige Aufgaben aus, z. B. Systemüberwachung und Wartung für die Infrastruktur. Azure verwaltet die Kubernetes-Masterknoten, sodass Sie die Agentknoten nur verwalten und verwalten müssen.

Um Ihre Workload von Service Fabric auf AKS zu verschieben, müssen Sie die Unterschiede in der zugrunde liegenden Infrastruktur verstehen, damit Sie Ihre containerisierten Anwendungen sicher migrieren können. In der folgenden Tabelle werden die Funktionen und Features der beiden Hostingplattformen verglichen.

Funktion oder Komponente Service Fabric AKS
Nicht containerisierte Anwendungen Ja Nein
Linux- und Windows-Container Ja Ja
Von Azure verwaltete Steuerungsebene Nein Ja
Unterstützung für zustandslose und zustandsbehaftete Workloads Ja Ja
Platzierung des Workerknotens Virtual Machine Scale Sets, kundenseitig konfiguriert Virtual Machine Scale Sets, von Azure verwaltet
Konfigurationsmanifest XML YAML
Azure Monitor-Integration Ja Ja
Native Unterstützung für Reliable Services- und Reliable Actor-Muster Ja Nein
WCF-basierter Kommunikationsstapel für Reliable Services Ja Nein
Permanenter Speicher Azure Files-Volumetreiber Unterstützung für verschiedene Speichersysteme, z. B. verwaltete Datenträger, Azure Files und Azure Blob Storage über CSI Storage-Klassen, persistentes Volume und Ansprüche auf persistente Volumes
Netzwerkmodi Azure Virtual Network-Integration Unterstützung für mehrere Netzwerk-Plug-Ins (Azure CNI, Kubenet, BYOCNI), Netzwerkrichtlinien (Azure, Calico) und Eingangsdatencontroller (Application Gateway-Eingangsdatencontroller, NGINX usw.)
Eingangsdatencontroller Ein Reverseproxy, der in Service Fabric integriert ist. Dieser unterstützt die in einem Service Fabric-Cluster ausgeführten Microservices beim Ermitteln von und Kommunizieren mit anderen Diensten mit HTTP-Endpunkten. Sie können Traefik auch in Service Fabric verwenden. Verwalteter NGINX-Eingangscontroller, BYO-Eingangs-Open Source- und kommerzielle Controller, die plattformverwaltete öffentliche oder interne Lastenausgleichsgeräte verwenden, z . B. NGINX-Eingangscontroller und Anwendungsgateway-Eingangscontroller

Hinweis

Wenn Sie Windows-Container in Service Fabric verwenden, empfiehlt es sich, sie auf AKS zu verwenden, um Ihre Migration zu vereinfachen.

Schritte bei der Migration

Im Allgemeinen sind die Migrationsschritte von Service Fabric zu AKS wie folgt.

Diagramm, das die Migrationsschritte von Service Fabric zu AKS zeigt.

  1. Richten Sie die Bereitstellungsarchitektur ein, und erstellen Sie den AKS-Cluster. AKS bietet verschiedene Optionen zum Konfigurieren des Clusterzugriffs, des Knotens und der Pod-Skalierbarkeit, des Netzwerkzugriffs und der Konfiguration und vieles mehr. Weitere Informationen zu einer typischen Bereitstellungsarchitektur finden Sie unter Beispielarchitektur. Die AKS-Basisarchitektur bietet außerdem Richtlinien für die Clusterbereitstellung und -überwachung. Die AKS-Konstruktion bietet Schnellstartvorlagen für die Bereitstellung Ihres AKS-Clusters basierend auf geschäftlichen und technischen Anforderungen.

  2. Die Service Fabric-Anwendung wird neu erstellt. Wenn Sie Programmiermodelle wie "Zuverlässige Dienste" oder "Zuverlässige Akteure" verwenden oder andere Service Fabric-spezifische Konstrukte verwenden, müssen Sie Ihre Anwendung möglicherweise neu erstellen. Verwenden Sie verteilte Anwendungslaufzeit (Distributed Application Runtime, Dapr),um die Zustandsverwaltung zu implementieren, wenn Sie von zuverlässigen Diensten migrieren. Kubernetes bietet Muster und Beispiele für die Migration von zuverlässigen Akteuren.

  3. Packen Sie die Anwendung als Container. Visual Studio bietet Optionen zum Generieren der Dockerfile-Datei und zum Verpacken der Anwendung als Container. Pushen Sie die Containerimages, die Sie erstellen, in die Azure-Containerregistrierung.

  4. Schreiben Sie XML-Konfigurationsdateien von Service Fabric als Kubernetes-YAML-Dateien neu. Sie stellen die Anwendung mithilfe von YAML-Dateien oder als Paket mithilfe von Helm-Diagrammen in AKS bereit. Weitere Informationen finden Sie unter Anwendungs- und Dienstmanifest.

  5. Stellen Sie die Anwendung im AKS-Cluster bereit.

  6. Verschieben Sie den Datenverkehr basierend auf Ihren Bereitstellungsstrategien auf den AKS-Cluster, und überwachen Sie das Verhalten, die Verfügbarkeit, die Leistung der Anwendung.

Beispiel Architektur

AKS und Azure bieten Ihnen die Flexibilität, Ihre Umgebung so zu konfigurieren, dass sie Ihren geschäftlichen Anforderungen entspricht. AKS ist gut mit anderen Azure-Diensten integriert. Die AKS-Basisarchitektur ist ein Beispiel.

Diagramm einer AKS-Baselinearchitektur

Machen Sie sich als Ausgangspunkt mit einigen wichtigen Kubernetes-Konzepten vertraut und überprüfen Sie dann einige Beispielarchitekturen:

Hinweis

Wenn Sie eine Workload von Service Fabric zu AKS migrieren, können Sie Service Fabric Reliable Actors durch den Dapr-Baustein Actors ersetzen. Sie können Service Fabric Reliable Collections durch den Dapr-Baustein Zustandsverwaltung ersetzen.

Dapr stellt APIs bereit, die die Microservice-Konnektivität vereinfachen. Weitere Informationen finden Sie in der Einführung in Dapr. Es wird empfohlen, Dapr als AKS-Erweiterung zu installieren.

Anwendungs- und Dienstmanifest

Service Fabric und AKS verfügen über unterschiedliche Anwendungs- und Dienstmanifestdateitypen und -konstrukte. Service Fabric verwendet XML-Dateien für die Anwendungs- und Dienstdefinition. AKS verwendet das Kubernetes YAML-Dateimanifest, um Kubernetes-Objekte zu definieren. Es gibt keine Tools, die speziell für die Migration einer Service Fabric-XML-Datei zu einer Kubernetes-YAML-Datei vorgesehen sind. Sie können jedoch erfahren, wie YAML-Dateien auf Kubernetes funktionieren, indem Sie die folgenden Ressourcen überprüfen.

Mit Helm können Sie parametrisierte YAML-Manifeste definieren und generische Vorlagen erstellen, indem Sie statische, hartcodierte Werte durch Platzhalter ersetzen, die Sie durch benutzerdefinierte Werte ersetzen können, die zur Bereitstellungszeit bereitgestellt werden. Die resultierenden Vorlagen, die die benutzerdefinierten Werte enthalten, werden als gültige Manifeste für Kubernetes gerendert.

Kustomize führt eine vorlagenlose Möglichkeit zum Anpassen der Anwendungskonfiguration ein, die die Verwendung von Standardanwendungen vereinfacht. Sie können Kustomize zusammen mit Helm oder als Alternative zu Helm verwenden.

Weitere Informationen zu Helm und Kustomize finden Sie in den folgenden Ressourcen:

Netzwerk

AKS bietet zwei Optionen für das zugrunde liegende Netzwerk:

  • Bringen Sie Ihr eigenes virtuelles Azure-Netzwerk mit, um die AKS-Clusterknoten in ein Subnetz aus einem virtuellen Netzwerk bereitzustellen, das Sie bereitstellen.

  • Lassen Sie den AKS-Ressourcenanbieter ein neues virtuelles Azure-Netzwerk für Sie in der Knotenressourcengruppe erstellen, die alle azure-Ressourcen enthält, die ein Cluster verwendet.

Wenn Sie die zweite Option auswählen, verwaltet Azure das virtuelle Netzwerk.

Service Fabric bietet keine Auswahl an Netzwerk-Plug-Ins. Wenn Sie AKS verwenden, müssen Sie eine der folgenden Optionen auswählen:

  • kubenet Mit kubenet erhalten Knoten eine IP-Adresse aus dem Subnetz des virtuellen Azure-Netzwerks. Pods erhalten eine IP-Adresse aus einem Adressraum, der sich logisch vom Subnetz des virtuellen Azure-Netzwerks der Knoten unterscheidet. Die Netzwerkadressübersetzung (NAT, Network Address Translation) wird dann so konfiguriert, dass die Pods Ressourcen im virtuellen Azure-Netzwerk erreichen können. Die Quell-IP-Adresse des Datenverkehrs wird über NAT in die primäre IP-Adresse des Knotens übersetzt. Dieser Ansatz reduziert erheblich die Anzahl der IP-Adressen, die Sie in Ihrem Netzwerkadressraum für die Verwendung von Pods reservieren müssen.

  • Azure CNI. Wenn Sie container Networking Interface (CNI) verwenden, erhält jeder Pod eine IP-Adresse aus dem Subnetz und kann direkt darauf zugegriffen werden. Diese IP-Adressen müssen in Ihrem Netzwerkadressraum eindeutig sein und im Voraus geplant werden. Jeder Knoten verfügt über einen Konfigurationsparameter für die maximale Anzahl von Pods, die er unterstützt. Anschließend reservieren Sie die entsprechende Anzahl von IP-Adressen für jeden Knoten. Dieser Ansatz erfordert mehr Planung und führt oft zu einer Erschöpfung der IP-Adresse oder der Notwendigkeit, Cluster in einem größeren Subnetz neu zu erstellen, wenn die Anforderungen Ihrer Anwendung wachsen. Sie können die maximale Anzahl von Pods konfigurieren, die beim Erstellen des Clusters oder beim Erstellen neuer Knotenpools für einen Knoten bereitgestellt werden können.

  • Azure CNI Overlay-Netzwerk. Wenn Sie Azure CNI Overlay verwenden, werden die Clusterknoten in einem Azure Virtual Network-Subnetz bereitgestellt. Pods werden IP-Adressen aus einem privaten CIDR zugewiesen, die sich logisch von der Adresse des virtuellen Netzwerks unterscheiden, das die Knoten hostet. Pod- und Knotendatenverkehr innerhalb des Clusters verwendet ein Überlagerungsnetzwerk. NAT verwendet die IP-Adresse des Knotens, um Ressourcen außerhalb des Clusters zu erreichen. Diese Lösung speichert eine erhebliche Anzahl virtueller Netzwerk-IP-Adressen und hilft Ihnen, Ihren Cluster nahtlos auf große Größen zu skalieren. Ein zusätzlicher Vorteil besteht darin, dass das private CIDR in verschiedenen AKS-Clustern wiederverwendet werden kann, sodass der für containerisierte Anwendungen in AKS verfügbare IP-Speicherplatz erweitert wird.

  • Azure CNI Powered by Cilium Azure CNI Powered by Cilium kombiniert die robuste Steuerungsebene von Azure CNI mit der Datenebene von Cilium , um leistungsstarke Netzwerke und erhöhte Sicherheit zu bieten.

  • Verwendung Ihres eigenen CNI-Plug-Ins. Kubernetes stellt standardmäßig kein Netzwerkschnittstellensystem bereit. Diese Funktionalität wird von Netzwerk-Plug-Ins bereitgestellt. AKS bietet mehrere unterstützte CNI-Plug-Ins. Weitere Informationen zu unterstützten Plug-Ins finden Sie unter Netzwerkkonzepte für Anwendungen in AKS.

Windows-Container unterstützen derzeit nur das Azure CNI-Plug-In . Es stehen verschiedene Optionen für Netzwerkrichtlinien und Eingangscontroller zur Verfügung.

In AKS können Sie Kubernetes-Netzwerkrichtlinien verwenden, um die dienstinterne Kommunikation voneinander zu trennen und zu schützen, indem Sie kontrollieren, welche Komponenten miteinander kommunizieren können. Standardmäßig können alle Pods in einem Kubernetes-Cluster Datenverkehr ohne Einschränkungen senden und empfangen. Zur Verbesserung der Sicherheit können Sie Azure-Netzwerkrichtlinien oder Calico-Netzwerkrichtlinien verwenden, um Regeln zu definieren, mit denen der Datenverkehrsfluss zwischen Microservices gesteuert wird.

Wenn Sie den Azure-Netzwerkrichtlinien-Manager nutzen möchten, müssen Sie das Azure CNI-Plug-In verwenden. Sie können Calico-Netzwerkrichtlinien entweder mit dem Azure CNI-Plug-In oder mit dem kubenet CNI-Plug-In verwenden. Die Verwendung des Azure-Netzwerkrichtlinien-Managers für Windows-Knoten wird nur unter Windows Server 2022 unterstützt. Weitere Informationen finden Sie unter Sicherer Datenverkehr zwischen Pods durch Netzwerkrichtlinien in Azure Kubernetes Service (AKS). Weitere Informationen zu AKS-Netzwerken finden Sie unter Netzwerke in AKS.

In Kubernetes fungiert ein Eingangsdatencontroller als Dienstproxy und Vermittler zwischen einem Dienst und der Außenwelt, sodass externer Datenverkehr auf den Dienst zugreifen kann. Der Dienstproxy bietet in der Regel verschiedene Funktionen wie TLS-Abschluss, pfadbasiertes Anforderungsrouting, Lastenausgleich und Sicherheitsfeatures wie Authentifizierung und Autorisierung. Eingangscontroller bieten außerdem eine weitere Abstraktions- und Steuerungsebene für das Routing externer Datenverkehr an Kubernetes-Dienste basierend auf HTTP- und HTTPS-Regeln. Diese Ebene bietet eine genauere Steuerung des Datenverkehrsflusses und des Datenverkehrsmanagements.

In AKS gibt es mehrere Optionen zum Bereitstellen, Ausführen und Betreiben eines Eingangscontrollers. Eine Option ist der Application Gateway Ingress Controller, mit dem Sie Azure-App Lication Gateway als Eingangscontroller für TLS-Beendigung, pfadbasiertes Routing und als Webzugriffsfirewall verwenden können. Eine weitere Option ist der verwaltete NGINX-Eingangscontroller, der die azureverwaltete Option für den weitverwendeten NGINX-Eingangscontroller bereitstellt. Traefik-Eingangscontroller ist ein weiterer beliebter Eingangscontroller für Kubernetes.

Jeder dieser Eingangsdatencontroller weist Stärken und Schwächen auf. Berücksichtigen Sie die Anforderungen der Anwendung und der Umgebung, um zu entscheiden, welches verwendet werden soll. Achten Sie darauf, dass Sie die neueste Version von Helm verwenden und Zugriff auf das entsprechende Helm-Repository haben, wenn Sie einen nicht verwalteten Eingangscontroller installieren.

Permanenter Speicher

Sowohl Service Fabric als auch AKS verfügen über Mechanismen zum Bereitstellen von persistentem Speicher für containerisierte Anwendungen. In Service Fabric stellt der Azure Files-Volumetreiber, der ein Docker-Volume-Plug-In ist, Azure Files-Volumes für Linux- und Windows-Container bereit. Es wird als Service Fabric-Anwendung gepackt, die auf einem Service Fabric-Cluster bereitgestellt werden kann, um Volumes für andere containerisierte Service Fabric-Anwendungen im Cluster bereitzustellen. Weitere Informationen finden Sie unter Azure Files-Volumetreiber für Service Fabric.

Anwendungen, die in AKS ausgeführt werden, müssen möglicherweise Daten aus einem beständigen Dateisystem speichern und abrufen. AKS lässt sich in Azure-Speicherdienste wie azure managed disks, Azure Files, Blob Storage und Azure NetApp Storage (ANF) integrieren. Es ist auch in Nicht-Microsoft-Speichersysteme wie Rook und GlusterFS über Container Storage Interface (CSI)-Treiber integriert.

CSI ist ein Standard für die Bereitstellung von Block- und Dateispeichersystemen für containerisierte Workloads in Kubernetes. Nicht-Microsoft-Speicheranbieter, die CSI verwenden, können Plug-Ins schreiben, bereitstellen und aktualisieren, um neue Speichersysteme in Kubernetes verfügbar zu machen oder vorhandene zu verbessern, ohne den kernigen Kubernetes-Code zu ändern und auf die Veröffentlichungszyklen zu warten.

Mit der CSI-Speichertreiberunterstützung auf AKS können Sie diese Azure-Speicherdienste nativ verwenden:

  • Azure Disks. Sie können Azure Disks zum Erstellen einer Kubernetes-DataDisk-Ressource verwenden. Datenträger können Azure Premium-Speicher verwenden, der von leistungsstarken SSDs unterstützt wird, oder Azure-Standardspeicher, der von standardmäßigen HDDs oder SSDs unterstützt wird. Für die meisten Produktions- und Entwicklungsworkloads wird die Verwendung von Storage Premium empfohlen. Azure-Datenträger werden als ReadWriteOnce eingebunden und sind nur für einen einzelnen Knoten in AKS verfügbar. Verwenden Sie für Speichervolumes, auf die mehrere Pods gleichzeitig zugreifen können, Azure Files.

    Im Gegensatz dazu unterstützt Service Fabric die Erstellung eines Clusters oder eines Knotentyps, der verwaltete Datenträger verwendet, jedoch keine Anwendungen, die dynamisch angefügte verwaltete Datenträger über einen deklarativen Ansatz erstellen. Weitere Informationen finden Sie unter Bereitstellen eines Azure Service Fabric-Clusterknotentyps mit verwalteten Datenträgern.

  • Azure Files Sie können Azure Files verwenden, um eine SMB 3.0 oder 3.1-Dateifreigabe bereitzustellen, die von einem Azure Storage-Konto auf Pods unterstützt wird. Mit Azure Files können Daten über mehrere Knoten und Pods hinweg gemeinsam genutzt werden. Von Azure Files kann auf Standardfestplatten basierender Speicher vom Typ „Azure Storage Standard“ oder auf Hochleistungs-SSDs basierender Speicher vom Typ „Azure Storage Premium“ genutzt werden.

    Service Fabric stellt einen Azure Files-Volumetreiber als Docker-Volume-Plug-In bereit, das Azure Files-Volumes für Docker-Container bereitstellt. Service Fabric stellt eine Version des Treibers für Windows-Cluster und eine für Linux-Cluster bereit.

  • Blobspeicher. Azure Blob Storage kann verwendet werden, um einen Blobspeicher (oder Objektspeicher) als Dateisystem in einem Container oder Pod einzubinden. Durch die Verwendung von Blob Storage kann Ihr Cluster Anwendungen unterstützen, die mit großen unstrukturierten Datasets wie Protokolldateien, Bildern oder Dokumenten, HPC-Daten und mehr arbeiten. Wenn Sie Ihre Daten in Azure Data Lake Storage erfassen, können Sie sie den Speicher direkt in AKS einbinden und verwenden, ohne ein anderes Interimsdateisystem zu konfigurieren. Service Fabric unterstützt keinen Mechanismus zum Einbinden von Blobspeicher im deklarativen Modus.

Weitere Informationen zu Speicheroptionen finden Sie unter Speicher in AKS.

Anwendungs- und Clusterüberwachung

Sowohl Service Fabric als auch AKS bieten eine native Integration mit Azure Monitor und den zugehörigen Diensten wie Log Analytics. Überwachung und Diagnose sind für die Entwicklung, Das Testen und Bereitstellen von Workloads in einer beliebigen Cloudumgebung von entscheidender Bedeutung. Die Überwachung umfasst die Infrastruktur- und Anwendungsüberwachung.

So können Sie beispielsweise die Nutzung Ihrer Anwendungen, die Aktionen der Service Fabric-Plattform, die Ressourcenverwendung (mithilfe von Leistungsindikatoren) sowie die allgemeine Integrität Ihres Clusters nachverfolgen. Auf der Grundlage dieser Informationen können Sie Probleme diagnostizieren, beheben und in Zukunft vermeiden. Weitere Informationen finden Sie unter Überwachung und Diagnose für Azure Service Fabric. Wenn Sie containerisierte Anwendungen in einem Service Fabric-Cluster hosten und betreiben, müssen Sie die Containerüberwachungslösung einrichten, um Containerereignisse und Protokolle anzuzeigen.

AKS verfügt jedoch über eine integrierte Integration in Azure Monitor und Container Insights, die darauf ausgelegt ist, die Leistung von containerisierten Workloads zu überwachen, die in der Cloud bereitgestellt werden. Container Insights ermöglicht den Einblick in die Leistung, indem anhand der Metrik-API die in Kubernetes verfügbaren Speicher- und Prozessormetriken von Controllern, Knoten und Containern erfasst werden.

Nach der Aktivierung der Überwachung über Kubernetes-Cluster werden Metriken und Containerprotokolle für Sie automatisch mittels einer Containerversion des Log Analytics-Agents für Linux erfasst. Metriken werden an die Metrikdatenbank in Azure Monitor gesendet. Protokolldaten werden an Ihren Log Analytics-Arbeitsbereich gesendet. Auf diese Weise können Sie Überwachungs- und Telemetriedaten sowohl für den AKS-Cluster als auch für die containerisierten Anwendungen abrufen, die darauf ausgeführt werden. Weitere Informationen finden Sie unter Überwachen von Azure Kubernetes Service (AKS) mit Azure Monitor.

Als Alternative oder Begleitlösung zu Container Insights können Sie Ihren AKS-Cluster so konfigurieren, dass Metriken im verwalteten Azure Monitor-Dienst für Prometheus erfasst werden. Mit dieser Konfiguration können Sie Metriken im großen Maßstab sammeln und analysieren, indem Sie eine Prometheus-kompatible Überwachungslösung verwenden, die auf dem Prometheus-Projekt basiert. Mit dem vollständig verwalteten Dienst können Sie die Prometheus-Abfragesprache (PromQL) verwenden, um die Leistung der überwachten Infrastruktur und Workloads zu analysieren. Außerdem können Sie Warnungen empfangen, ohne die zugrunde liegende Infrastruktur betreiben zu müssen.

Der verwaltete Azure Monitor-Dienst für Prometheus ist eine Komponente von Azure Monitor-Metriken. Er bietet mehr Flexibilität bei den Typen von Metrikdaten, die Sie mithilfe von Azure Monitor sammeln und analysieren können. Prometheus-Metriken teilen einige Features mit Plattform- und benutzerdefinierten Metriken, aber sie verfügen über zusätzliche Features, um Open-Source-Tools wie PromQLund Grafana besser zu unterstützen.

Sie können den verwalteten Azure Monitor-Dienst für Prometheus als Datenquelle sowohl für Azure Managed Grafana als auch für selbstgehostete Grafana-Instanzen konfigurieren, die auf einer Azure-VM ausgeführt werden kann. Weitere Informationen finden Sie unter Verwenden des verwalteten Azure Monitor-Diensts für Prometheus als Datenquelle für Grafana mithilfe einer verwalteten Systemidentität.

Add-Ons für AKS

Wenn Sie von Service Fabric zu AKS migrieren, sollten Sie die Verwendung von Add-Ons und Erweiterungen in Betracht ziehen. AKS bietet zusätzliche unterstützte Funktionen für Ihre Cluster über Add-Ons und Erweiterungen wie Kubernetes Event-driven Autocaling (KEDA) und GitOps Flux v2. Viele weitere Integrationen von Open-Source-Projekten und Drittanbietern werden häufig mit AKS verwendet. Die AKS-Supportrichtlinie deckt keine Open Source- und Nicht-Microsoft-Integrationen ab. Weitere Informationen finden Sie unter Add-Ons, Erweiterungen und andere Integrationen mit Azure Kubernetes Service.

Beitragende

Dieser Artikel wird von Microsoft gepflegt. Er wurde ursprünglich von folgenden Mitwirkenden geschrieben:

Hauptautoren:

Melden Sie sich bei LinkedIn an, um nicht öffentliche LinkedIn-Profile anzuzeigen.

Nächste Schritte