Freigeben über

Einblick in Dienste für Kubernetes mit Azure Arc-Unterstützung

  • Artikel

Einblick ist eine Anwendungseigenschaft, die sich darauf bezieht, wie gut der interne Zustand oder Status eines Systems von seinen externen Ausgaben her verstanden werden kann. Wir messen Computersysteme, indem wir CPU-Zeit, Arbeitsspeicher, Speicherplatz auf dem Datenträger, Latenz, Fehler und andere Metriken beobachten. Je besser ein System beobachtet werden kann, desto einfacher können wir verstehen, was es tut, indem wir es beobachten.

Der Einblick in ein System wirkt sich erheblich auf seine Betriebskosten aus. Einblick bietende Systeme liefern ihren Operators aussagekräftige, als Handlungsbasis taugliche Daten, sodass sie günstige Ergebnisse und geringere Ausfallzeiten erzielen. Mehr Informationen bedeuten nicht zwangsläufig, dass das System besseren Einblick bietet. Tatsächlich kann die Menge der von einem System erzeugten Informationen manchmal erschweren, wertvolle Zustandssignale aus dem von der Anwendung erzeugten Wust an Informationen herauszulesen.

Der Einblick in Dienste ist wichtig, da er Ihnen hilft, die Leistung von auf dynamischen Architekturen basierenden verteilten und Cloudsystemen und die darin auftretenden Probleme zu verstehen.

Die Implementierung einer Lösung für den Einblick in Dienste kann Ihnen bei Folgendem helfen:

  • Sicherstellen, dass Endbenutzer Ihre Anwendung nutzen können und Ihre geschäftlichen Erwartungen erfüllt werden.
  • Verständnis für ein ganzes System und sein Zusammenspiel in einem einzigen Bildschirm gewinnen.
  • Einrichten einer Basislinie für Ihr System und Verstehen, wie verschiedene Umstände die Leistung Ihres Systems beeinflussen.
  • Generieren von Aktionselementen aus unerwarteten Szenarien und Verhaltensweisen heraus.

Kubernetes mit Azure Arc-Unterstützung bietet zwei integrierte Erweiterungsoptionen, die Ihnen dabei helfen, Einblick in Dienste zu erreichen: Open Service Mesh und das selbstgehostete Gateway. Diese Optionen werden in den folgenden Abschnitten zu Überlegungen zum Entwurf ausführlicher erläutert.

Aufbau

Das folgende Diagramm veranschaulicht die drei Säulen des Einblicks in Dienste mit Auswirkungen auf das Datenvolumen.

Diagramm: Säulen für den Einblick in Dienste

Das folgende Diagramm zeigt verschiedene Open Service Mesh-Komponenten, die in einem Kubernetes-Cluster mit Azure Arc-Unterstützung ausgeführt werden. Es zeigt auch eine im Dienstnetz aktivierte Beispielanwendung, die automatisch mit einem Envoy-Sidecar-Container konfiguriert wird.

Diagramm: Ausführung von Open Service Mesh in Kubernetes mit Azure Arc-Unterstützung

Überlegungen zum Entwurf

Die drei Säulen des Einblicks sind Metriken, Protokolle und Ablaufverfolgungen. Integrieren Sie sie in Ihre Einblickstrategie, damit Ihr System beobachtet werden kann.

  • Metriken sind numerische Werte, die einen Aspekt eines Systems zu einem bestimmten Zeitpunkt beschreiben und immer in regelmäßigen Abständen erfasst werden.

Der folgende Screenshot zeigt eine Visualisierung einer Beispiel-HTTP-Anforderungsmetrik für einen Dienst. Die Metrik in diesem Beispiel wird über einen angegebenen Zeitraum jede Minute als HTTP-Anforderungsrate angezeigt.

Screenshot: HTTP-Anforderungsmetrik für einen Dienst

  • Protokolle können verschiedene Datentypen speichern, die über eigene Strukturen verfügen. Ein Protokoll enthält Details zu Transaktionen, mit denen Sie eine vollständigere Story für ein bestimmtes Ereignis erhalten können. Anwendungsprotokolle enthalten in der Regel Zeitstempel, Protokollebenen und alle Informationen, die erforderlich sind, um den Kontext eines Ereignisses zu verstehen. Protokolle werden gesammelt und zur Speicherung und Analyse an einen Protokolldienst gesendet.

  • Verteilte Ablaufverfolgung ist eine Diagnosetechnik, die Benutzern bei der Lokalisierung von Fehlern und Leistungsproblemen innerhalb von Anwendungen hilft, insbesondere solcher, die über mehrere Computer oder Prozesse verteilt sind. Diese Technik verfolgt Anforderungen durch eine Anwendung nach, indem sie die von verschiedenen Anwendungskomponenten geleistete Arbeit miteinander korreliert und sie von anderer Arbeit trennt, die die Anwendung möglicherweise für gleichzeitige Anforderungen leistet.

Der folgende Screenshot zeigt eine Visualisierung einer End-to-End-Transaktion mithilfe von Application Insights. Dieses Visual ermöglicht ein einfaches Verständnis von Antwortzeiten, Antwortcodes und Ausnahmen, die zwischen Anfragen in einer Transaktionskette auftreten.

Screenshot: Ablaufverfolgung für eine End-to-End-Transaktion

Die drei Säulen von Metriken, Protokollen und verteilter Ablaufverfolgung sind miteinander verbunden. Metriken werden als numerische Werte in einer Zeitreihendatenbank gespeichert. Außerdem sind sie viel kleiner als Protokolle, wodurch sie leichter auszuwerten sind und sich für Warnungen nahezu in Echtzeit eignen. Protokolle erfassen und vermitteln viel mehr Informationen als Metriken, was sie für ein intensiveres Debuggen qualifiziert. Ablaufverfolgungen sind anforderungsbezogene Elemente und nützlich, um einen Einblick in eine Anforderung zu erhalten, da sie verschiedene Komponenten eines verteilten Systems durchlaufen.

In der folgenden Tabelle sind die Sammlungswirkungen für die drei Säulen dargestellt.

Sammlungseigenschaft Metriken Protokolle Verteilte Ablaufverfolgung
Konten für jede Transaktion Ja Ja Keine (Stichproben)
Immun gegen Kardinalitätsprobleme No Ja Ja
Kosten Niedrig Hoch Niedrig

Es gibt verschiedene Möglichkeiten, den Einblick in Dienste zu erreichen. Sie können ein Dienstnetz verwenden, um ihn auf der Plattformebene durchzuführen, wo Ihre Anwendung nicht bekannt und unverändert ist. Sie können eine Anwendung auch mit einer Bibliothek instrumentieren, was häufig mit einem APM-Tool (Application Performance Monitoring) wie Application Insights durchgeführt wird. API-Gateways bieten den Einblick in den Nord-Süd-Datenverkehr, aber es fehlt der den Einblick in die Pod-zu-Pod-Kommunikation und die benutzerfreundliche Konfiguration im großen Stil.

In den folgenden Abschnitten wird erläutert, wie Sie ein Dienstnetz und das für Azure Arc verfügbare selbst gehostete API-Gateway verwenden können, um Einblick in Dienste zu erreichen.

Dienstnetz

Ein Dienstnetz bietet Funktionen wie Datenverkehrsverwaltung, Resilienz, Richtlinienerzwingung, Transportsicherheit, Identitätssicherheit und Einblick in Ihre Workloads. Ihre Anwendung ist von diesen betriebsbezogenen Funktionen abgekoppelt, und sie werden vom Dienstnetz von der Anwendungsschicht herunter auf die Infrastrukturebene verschoben. Dies erfolgt über einen leistungsstarken Proxy, der allen eingehenden und ausgehenden Datenverkehr an Ihren Dienst vermittelt.

  • Kubernetes mit Azure Arc-Unterstützung unterstützt Open Service Mesh (OSM), ein CNCF-Projekt (Cloud Native Computing Foundation), das als Erweiterung bereitgestellt wird. Open Service Mesh ist ein schlankes, erweiterbares, cloudbasiertes Dienstnetz, mit dem Benutzer die Standardfunktionen für den Einblick für sehr dynamische Microservice-Umgebungen einheitlich verwalten, sichern und erhalten können.
  • Weitere beliebte Dienstnetze, die Unterstützung von Anbietern erfordern, sind Istio, Consul Connect und Linkerd.
  • Je nachdem, welche Funktionen Sie bei der Implementierung eines Dienstnetzes verwenden, kann den Anwendungsoperators zusätzliche Verantwortung für die Festlegung einer Konfiguration für die einzelnen Dienst (z. B. Zugriffsregeln und Onboardingdienste) auferlegt werden. Darüber hinaus müssen Clusteroperators den Dienstnetzcontroller verwalten und beachten. Aufgrund der Art und Weise, wie das Dienstnetz das Sidecar-Muster verwendet, werden Zugriffsprotokolle von Dienstnetz-Steuerungsebene und Sidecar beim Debuggen von Eingang und Ausgang benötigt.

Dienstnetzeinblick

Einblick ist eine wichtige Funktionalität unter den vielen, die Dienstnetze bereitstellen. Wählen Sie ein Dienstnetz aus, das Ihre Mindestanforderungen an den Einblick erfüllt, damit Sie die Komplexität und die Anzahl der Komponenten, die das Dienstnetz enthalten kann und die konfiguriert werden müssen, reduzieren können. Bewerten Sie die folgenden allgemeinen Features und Anwendungsfälle des Einblicks, die Dienstnetze bereitstellen:

  • Metrikengenerierung einschließlich der vier goldenen Signale: Latenz, Datenverkehr, Fehler und Sättigung.
  • Die RED-Methode (Rates-calls/sec, Errors, Duration-call latencies; Aufrufe/Sekunde, Fehler, Dauer Aufruflatenzen), die eine Teilmenge der vier goldenen Signale ist und verwendet wird, um Dienste zu messen. Ihr Dienstnetz sollte eine standardisierte Möglichkeit zum Sammeln von RED-Metriken, Ablaufverfolgungen usw. bieten.
  • Von der Erweiterung der Abdeckungsbreite bis zu allen Diensten, die Teil Ihres Dienstnetzes sind, wird der Einblick ausgeweitet.
  • Features weiten die Einführung des Einblicks durch automatische Instrumentierung aller Dienste aus.
  • Starke Integration in Diensteinblicksäulen. Ihr Dienstnetz sollte in der Lage sein, Metriken auszulesen und Protokolle zu sammeln, die in Ihrer Überwachungslösung angezeigt werden. Stellen Sie sicher, dass die Telemetriesammlung Ihres Dienstnetzes Ihre geschäftlichen Anforderungen unterstützt und gut in Ihre vorhandene Überwachungslösung integriert wird.

Das folgende Diagramm zeigt ein Beispiel für die Dienstnetzproxy-Funktionalität der Datensammlung und -weiterleitung.

Diagramm: Beispieleinblick mit einem Dienstnetzproxy

Selbstgehostetes API Management-Gateway

Mit der Integration zwischen Azure API Management und Azure Arc in Kubernetes können Sie die API Management-Gatewaykomponente als Erweiterung in Ihrem Kubernetes-Cluster mit Azure Arc-Unterstützung bereitstellen. Dadurch kann eine containerisierte Version des API Management-Gateways im Cluster ausgeführt werden. Alle selbstgehosteten Gateways werden über den API Management-Dienst verwaltet, mit dem sie sich im Verbund befinden. So profitieren Sie von Transparenz und einheitlichen Verwaltungsfunktionen für alle internen und externen APIs.

Die Konfiguration des selbstgehosteten Gateways, um eingehenden Datenverkehr an Ihre Dienste zu leiten, erfordert die Erstellung von Richtlinien. Seine Verwaltung kann komplexer werden, da Ihre Diensteskala wächst.

Weitere Informationen finden Sie in der Übersicht zum selbstgehosteten Gateway.

API Management: Einblick in das selbstgehostete Gateway

Das selbstgehostete Gateway gibt Metriken, StdOut- und StdErr-Protokolle aus. Es werden Metriken ausgegeben, die von einer ConfigMap in Ihrem Cluster konfiguriert werden können. Informationen zur erweiterten Überwachung mit API Management finden Sie unter Erweiterte Überwachung.

Der Einblick in das selbstgehostete Gateway berücksichtigt den externen Datenverkehr (Nord-Süd) in Ihrem Cluster, jedoch nicht den Pod-to-Pod-Datenverkehr innerhalb Ihres Clusters (Ost-West).

Cloudmetriken und Protokolle: Metriken werden standardmäßig an Azure Monitor ausgegeben. Mit Log Analytics können Sie Containerprotokolle des selbst gehosteten Gateways mithilfe von Azure Monitor für Container erfassen und anzeigen. Weitere Informationen finden Sie unter Konfigurieren von lokalen Metriken und Protokollen für selbstgehostete Gateways für Azure API Management.

Lokale Metriken und Protokolle: Metriken und Protokolle Ihres selbst gehosteten Gateways können in Ihr lokales Überwachungstool integriert oder von Config Map ausgegeben werden. Metriken können für die Veröffentlichung auf Metrikservern konfiguriert werden. Gatewayprotokolle werden standardmäßig an StdOut und StdErr ausgegeben. Weitere Informationen finden Sie unter Konfigurieren von lokalen Metriken und Protokollen für selbstgehostete Gateways für Azure API Management.

Technologievergleichstabelle

In der folgenden Tabelle sind Unterschiede zwischen Implementierungsoptionen aufgeführt, die Ihnen bei der Auswahl einer Methode zum Abrufen des Einblicks in Dienste helfen.

Funktion Dienstnetz Anwendungsleistungsüberwachung Selbstgehostetes API-Gateway
Ost-West-Datenverkehr wird unterstützt Ja Ja No
Metrikfunktion Ja Ja Ja
Protokollierungsfunktion Ja Ja Benutzerdefinierte Implementierung
Funktion „Verteilte Ablaufverfolgung“ Ja Ja Ja
Implementierungsebene Network Application Network
Unterstützte Protokolle HTTP(S), TCP, gRPC – HTTP(S), Websockets
Konfigurationsverantwortung Clusteroperators Anwendungsentwickler Anwendungs- und Clusteroperators
Konfigurationskomplexität für den Einblick Niedrig Hoch Medium

Entwurfsempfehlungen

Implementieren Sie Open Service Mesh, um Einblick in Zustand und Leistung Ihrer Dienste zu erhalten. Open Service Mesh verwendet Sidecar-Proxys, die als separater Container in dieselben Pods eingefügt werden, in die auch Ihre Workloads eingefügt werden, um Telemetriedaten abzurufen. Diese Proxys fangen den gesamten ein- und ausgehenden HTTP-Datenverkehr Ihrer Workloads ab und berichten die Daten an Open Service Mesh. Dank dieses Systems müssen Dienstentwickler ihren Code nicht instrumentieren, um Telemetriedaten zu sammeln.

Aktivieren Sie Open Service Mesh mithilfe der Kubernetes-Clustererweiterungsfunktion mit Azure Arc-Unterstützung, mit der Microsoft die Steuerungsebene für Sie verwalten kann. Weitere Informationen finden Sie unter Open Service Mesh mit Azure Arc-Unterstützung.

Um Verfügbarkeit und Leistung Ihrer Anwendungen und Dienste zu maximieren, aktivieren Sie Azure Monitor Container Insights für Azure Arc-fähige Kubernetes-Cluster. Dies bietet eine umfassende Lösung für das Sammeln, Analysieren und Behandeln von Telemetriedaten aus Ihren Cloud- und lokalen Umgebungen. Open Service Mesh mit Azure Arc-Unterstützung ist tief in Azure Monitor integriert und bietet Ihnen so eine nahtlose Methode zum Anzeigen und Reagieren auf kritische KPIs, die von OSM-Metriken und Anwendungscontainerprotokollen bereitgestellt werden. Sie können OSM-Metriken mit folgenden Schritten aktivieren. Für die verteilte Ablaufverfolgung empfehlen wir Jaeger, was in Ihre OSM-Steuerungsebene integriert werden kann.

Open Service Mesh bietet auch dokumentierte Einblickintegrationen für Metriken mit Prometheus und Grafana, Ablaufverfolgung mit Jaeger und Protokollweiterleitung mit Fluent Bit. Diese Integrationen bieten alternative Optionen, wenn Sie keine Azure-Überwachungslösungen verwenden. Sie können diese Integrationen bei Bedarf zur Erweiterung auf andere interne Überwachungstools verwenden.

Zumindest sollten Sie die folgenden drei RED-Metriken definieren und sie für alle Dienste messen:

  • Anforderungsrate: Die Anzahl der Anforderungen, die der Dienst pro Sekunde empfängt.
  • Fehler: Die Anzahl der Anforderungen, bei denen Fehler aufgetreten sind, oder die Rate der Anforderungen pro Sekunde, bei denen Fehler aufgetreten sind.
  • Dauer: Die Zeit, die ein Dienst benötigt, um eine Anforderung zu behandeln.

Open Service Mesh stellt mehrere vordefinierte Dienstarbeitsmappen in Azure Monitor bereit, sodass Sie keine Dashboards und Diagramme manuell einrichten müssen. Mit dieser detaillierten Telemetrie können Sie das Dienstverhalten beobachten und die Problembehandlung, Wartung und Optimierung Ihrer Anwendungen durchführen. Die Verwendung der OSM-Überwachungsarbeitsmappe in Azure Monitor ermöglicht Folgendes:

  • Sie erhalten einen Überblick über alle Dienste in Ihrem Netz und wichtige Metriken auf Dienstebene für drei der vier goldenen Signale der Überwachung: Latenz, Anforderungen und Fehler.
  • Sie können Warnungen für Ziele auf Dienstebene (Service Level Objectives, SLOs) definieren, überprüfen und festlegen, die die für Benutzer sichtbare Leistung Ihres Diensts zusammenfassen.
  • Sie können Metrikdiagramme für einzelne Dienste anzeigen, sodass Sie sie mithilfe von Filtern und Aufschlüsselungen eingehend analysieren können, und Daten nach Antwortcode, Protokoll, Zielpod, Datenverkehrsquelle und vielen anderen Kriterien durchsuchen.

Verwenden Sie Visualisierungen aus der Jaeger-Benutzeroberfläche für folgende Zwecke:

  • Beobachten Sie eine Topologiediagrammvisualisierung, die zeigt, welche Microservices miteinander kommunizieren, wohin Anforderungen gerichtet werden und wie lange sie dauern.
  • Überprüfen Sie zur Überwachung verteilter Systeme und deren Problembehandlung, wie und wann bestimmte Anforderungen und Antworten auftreten.

Der Einblick in Dienste ist nur eine Disziplin Ihrer Cloudüberwachungsstrategie. Weitere Informationen zu Verwaltungsdisziplinen finden Sie unter Verwaltungsdisziplinen: wichtiger Entwurfsbereich.

Nächste Schritte

Weitere Informationen zu Ihrer Hybrid- und Multicloudumgebung finden Sie in den folgenden Artikeln: