Implementieren der Infrastrukturresilienz mit Kubernetes
Um infrastrukturbasierte Resilienz zu implementieren, können Sie ein Dienstgitter verwenden. Neben der Resilienz ohne Codeänderung bietet ein Service Mesh eine Datenverkehrsverwaltung, Richtlinien, Sicherheit, starke Identität und Überwachbarkeit. Ihre App wird von diesen operativen Funktionen entkoppelt, die auf die Infrastrukturebene verschoben werden. Architektonisch besteht ein Dienstgitter aus zwei Komponenten: einer Steuerebene und einer Datenebene.
Die Steuerungsebene verfügt über eine Reihe von Komponenten, die die Verwaltung des Dienstnetzes (Service Mesh) unterstützen. Der Komponentenbestand umfasst in der Regel Folgendes:
- Eine Verwaltungsschnittstelle, die eine Benutzeroberfläche oder eine API sein kann.
- Regeln und Richtliniendefinitionen, die definieren, wie das Dienstgitter bestimmte Funktionen implementieren soll.
- Sicherheitsverwaltung für Dinge wie starke Identität und Zertifikate für mTLS.
- Metriken oder Beobachtbarkeit zum Sammeln und Aggregieren von Metriken und Telemetrie aus den Apps.
Die Datenebenenkomponente besteht aus Proxys, die transparent zusammen mit jedem Dienst eingefügt werden, der als Sidecar-Muster bezeichnet wird. Jeder Proxy ist so konfiguriert, dass der Netzwerkdatenverkehr in und außerhalb des Pods gesteuert wird, der Ihren Dienst enthält. Diese Konfiguration ermöglicht es jedem Proxy, folgendes zu konfigurieren:
- Sicherer Datenverkehr über mTLS.
- Dynamisches Weiterleiten von Datenverkehr.
- Anwenden von Richtlinien auf Datenverkehr.
- Sammeln Sie Metriken und Tracing-Informationen.
Einige beliebte Dienstgitteroptionen für Kubernetes-Cluster sind Linkerd, Istio und Konsul. Dieses Modul konzentriert sich auf Linkerd. Das folgende Diagramm zeigt Interaktionen zwischen Komponenten innerhalb der Daten- und Steuerebenen:
Vergleich mit codebasierten Ansätzen
Die Hauptfehlerbehandlungsstrategie von Linkerd umfasst Wiederholungen und Timeouts. Da Linkerd eine systemische Sicht auf den gesamten Cluster hat, kann er Resilienzstrategien auf neuartige Weise einsetzen. Ein Beispiel hierfür sind Wiederholungsversuche, bei denen maximal 20 Prozent zusätzliche Last für den Zieldienst hinzugefügt werden. Die metrikbasierte Ansicht von Linkerd ermöglicht es, sich dynamisch an Clusterbedingungen in Echtzeit anzupassen. Dieser Ansatz fügt dem Verwalten des Clusters eine weitere Dimension hinzu, fügt jedoch keinen Code hinzu.
Mit einem codebasierten Ansatz, z. B. mit Polly, können Sie:
- Es ist erforderlich, zu erraten, welche Wiederholungs- und Timeoutparameter geeignet sind.
- Konzentrieren Sie sich auf eine bestimmte HTTP-Anforderung.
Es gibt keine vernünftige Möglichkeit, auf einen Infrastrukturfehler im App-Code zu reagieren. Berücksichtigen Sie die Hunderte oder Tausende von Anforderungen, die gleichzeitig verarbeitet werden. Sogar eine Wiederholung mit exponentiellem Backoff (Anzahl der Anforderungen) kann einen Dienst überlasten.
Bei infrastrukturbasierten Ansätzen wie Linkerd werden interne Komponenten von Apps dagegen nicht berücksichtigt. Beispielsweise sind komplexe Datenbanktransaktionen für Linkerd unsichtbar. Solche Transaktionen können vor Fehlern mit Polly geschützt werden.
In anstehenden Einheiten implementieren Sie Resilienz für den Coupon-Dienst mithilfe von Polly und Linkerd.