In der Vergangenheit Wir haben uns die Grundkomponenten von Service Mesh Istio angesehen, uns mit dem System vertraut gemacht und die wichtigsten Fragen beantwortet, die sich normalerweise beim Einstieg in die Arbeit mit Istio stellen. In diesem Teil werden wir uns mit der Organisation der Sammlung von Rückverfolgungsinformationen über ein Netzwerk befassen.
Das erste, was vielen Entwicklern und Systemadministratoren in den Sinn kommt, wenn sie das Wort „Service Mesh“ hören, ist die Nachverfolgung. Tatsächlich fügen wir jedem Netzwerkknoten einen speziellen Proxyserver hinzu, über den der gesamte TCP-Verkehr läuft. Es scheint, dass es jetzt einfach möglich ist, Informationen über alle Netzwerkinteraktionen im Netzwerk zu senden. Leider gibt es in der Realität viele Nuancen, die berücksichtigt werden müssen. Schauen wir sie uns an.
Irrtum Nummer eins: Wir können Wanderdaten kostenlos online erhalten.
Tatsächlich können wir relativ kostenlos nur die durch Pfeile verbundenen Knoten unseres Systems und die Datenrate ermitteln, die zwischen den Diensten übertragen wird (eigentlich nur die Anzahl der Bytes pro Zeiteinheit). In den meisten Fällen kommunizieren unsere Dienste jedoch über ein Protokoll der Anwendungsschicht, z. B. HTTP, gRPC, Redis usw. Und natürlich möchten wir Tracing-Informationen speziell für diese Protokolle sehen; wir möchten die Anfragerate sehen, nicht die Datenrate. Wir möchten die Latenz von Anfragen mithilfe unseres Protokolls verstehen. Schließlich möchten wir den vollständigen Weg sehen, den eine Anfrage von der Anmeldung bei unserem System bis zum Erhalt einer Antwort vom Benutzer durchläuft. Dieses Problem ist nicht mehr so einfach zu lösen.
Schauen wir uns zunächst an, wie das Senden von Tracing-Spans aus architektonischer Sicht in Istio aussieht. Wie wir uns aus dem ersten Teil erinnern, verfügt Istio über eine separate Komponente namens Mixer zum Sammeln von Telemetriedaten. In der aktuellen Version 1.0.* erfolgt der Versand jedoch direkt von Proxy-Servern, nämlich vom Envoy-Proxy. Der Envoy-Proxy unterstützt standardmäßig das Senden von Tracing-Spans mithilfe des Zipkin-Protokolls. Es ist möglich, andere Protokolle anzubinden, allerdings nur über ein Plugin. Mit Istio erhalten wir sofort einen zusammengestellten und konfigurierten Envoy-Proxy, der ausschließlich das Zipkin-Protokoll unterstützt. Wenn wir beispielsweise das Jaeger-Protokoll verwenden und Tracing-Spans über UDP senden möchten, müssen wir unser eigenes Istio-Proxy-Image erstellen. Es gibt Unterstützung für benutzerdefinierte Plugins für istio-proxy, es befindet sich jedoch noch in der Alpha-Version. Wenn wir also auf eine Vielzahl benutzerdefinierter Einstellungen verzichten wollen, verringert sich der Umfang der verwendeten Technologien zum Speichern und Empfangen von Tracing-Spans. Von den Hauptsystemen können Sie jetzt tatsächlich Zipkin selbst oder Jaeger verwenden, aber alles mithilfe des Zipkin-kompatiblen Protokolls dorthin senden (was viel weniger effizient ist). Das Zipkin-Protokoll selbst beinhaltet das Senden aller Tracing-Informationen an die Sammler über das HTTP-Protokoll, was recht teuer ist.
Wie ich bereits sagte, wollen wir Protokolle auf Anwendungsebene verfolgen. Das bedeutet, dass die Proxy-Server, die neben jedem Dienst stehen, verstehen müssen, welche Art von Interaktion gerade stattfindet. Standardmäßig konfiguriert Istio alle Ports als reines TCP, was bedeutet, dass keine Traces gesendet werden. Damit Traces gesendet werden können, müssen Sie zunächst diese Option in der Haupt-Mesh-Konfiguration aktivieren und, was sehr wichtig ist, alle Ports von Kubernetes-Diensteinheiten entsprechend dem Protokoll benennen, das im Dienst verwendet wird. Das ist zum Beispiel so:
apiVersion: v1
kind: Service
metadata:
name: nginx
spec:
ports:
- port: 80
targetPort: 80
name: http
selector:
app: nginxSie können auch zusammengesetzte Namen wie http-magic verwenden (Istio erkennt http und erkennt diesen Port als http-Endpunkt). Das Format ist: Proto-Extra.
Um nicht eine große Anzahl von Konfigurationen zu patchen, um das Protokoll zu bestimmen, können Sie einen schmutzigen Workaround verwenden: Patchen Sie die Pilot-Komponente in dem Moment, in dem sie gerade benötigt wird . Am Ende wird es natürlich notwendig sein, diese Logik auf Standard umzustellen und auf eine Namenskonvention für alle Ports umzustellen.
Um zu verstehen, ob das Protokoll wirklich korrekt definiert ist, müssen Sie in einen der Sidecar-Container mit Envoy-Proxy gehen und eine Anfrage an den Admin-Port der Envoy-Schnittstelle mit dem Standort /config_dump stellen. In der resultierenden Konfiguration müssen Sie sich das Operationsfeld des gewünschten Dienstes ansehen. Es wird in Istio als Kennung dafür verwendet, wo die Anfrage gestellt wird. Um den Wert dieses Parameters in Istio anzupassen (wir sehen ihn dann in unserem Tracing-System), muss beim Start des Sidecar-Containers das Flag serviceCluster angegeben werden. Es kann beispielsweise wie folgt aus Variablen berechnet werden, die von der Downward-Kubernetes-API abgerufen wurden:
--serviceCluster ${POD_NAMESPACE}.$(echo ${POD_NAME} | sed -e 's/-[a-z0-9]*-[a-z0-9]*$//g')
Ein gutes Beispiel, um zu verstehen, wie die Nachverfolgung in Envoy funktioniert, ist .
Der Endpunkt selbst zum Senden von Tracing-Spans muss auch in den Startflags des Envoy-Proxys angegeben werden, zum Beispiel: --zipkinAddress tracing-collector.tracing:9411
Missverständnis Nummer zwei: Wir können über das System sofort und kostengünstig vollständige Spuren von Anfragen erhalten
Leider ist es nicht. Die Komplexität der Implementierung hängt davon ab, wie Sie das Zusammenspiel der Dienste bereits implementiert haben. Warum so?
Tatsache ist, dass es nicht ausreicht, einfach den gesamten Datenverkehr abzufangen, damit istio-proxy die Korrespondenz eingehender Anfragen an einen Dienst mit denen, die denselben Dienst verlassen, verstehen kann. Sie benötigen eine Art Kommunikationskennung. Der HTTP-Envoy-Proxy verwendet spezielle Header, anhand derer der Envoy versteht, welche spezifische Anfrage an den Dienst bestimmte Anfragen an andere Dienste generiert. Liste solcher Header:
- x-Anfrage-ID
- x-b3-traceid,
- x-b3-spanid,
- x-b3-parentspanid,
- x-b3-abgetastet,
- x-b3-Flaggen,
- x-ot-span-context.
Wenn Sie einen einzelnen Punkt haben, zum Beispiel einen Basis-Client, in dem Sie eine solche Logik hinzufügen können, dann ist alles in Ordnung, Sie müssen nur warten, bis diese Bibliothek für alle Clients aktualisiert wird. Wenn Sie jedoch über ein sehr heterogenes System verfügen und es keine Vereinheitlichung beim Übergang von Dienst zu Dienst über das Netzwerk gibt, wird dies höchstwahrscheinlich ein großes Problem darstellen. Ohne das Hinzufügen einer solchen Logik werden alle Rückverfolgungsinformationen nur „einstufig“ sein. Das heißt, wir erhalten alle Interaktionen zwischen Diensten, sie werden jedoch nicht in einzelne Durchgangsketten durch das Netzwerk eingefügt.
Abschluss
Istio bietet ein praktisches Tool zum Sammeln von Tracing-Informationen über ein Netzwerk. Sie müssen sich jedoch darüber im Klaren sein, dass Sie für die Implementierung Ihr System anpassen und die Funktionen der Istio-Implementierung berücksichtigen müssen. Infolgedessen müssen zwei Hauptpunkte gelöst werden: Definieren des Protokolls auf Anwendungsebene (das vom Envoy-Proxy unterstützt werden muss) und Einrichten der Weiterleitung von Informationen über die Verbindung von Anfragen an den Dienst von Anfragen des Dienstes (unter Verwendung von Headern). , im Fall des HTTP-Protokolls). Wenn diese Probleme gelöst sind, verfügen wir über ein leistungsstarkes Tool, das es uns ermöglicht, Informationen aus dem Netzwerk transparent zu sammeln, selbst in sehr heterogenen Systemen, die in vielen verschiedenen Sprachen und Frameworks geschrieben sind.
Im nächsten Artikel über Service Mesh befassen wir uns mit einem der größten Probleme bei Istio – dem hohen RAM-Verbrauch durch jeden Sidecar-Proxy-Container – und besprechen, wie Sie damit umgehen können.
Source: habr.com