Implementieren von Infrastrukturresilienz mit Kubernetes
Sie können ein Dienstnetz verwenden, um die infrastrukturbasierte Resilienz zu implementieren. Abgesehen von der Resilienz ohne Codeänderung kann ein Dienstnetz auch für die Datenverkehrsverwaltung, Richtlinien, Sicherheit, starke Identität und Einblicke verwendet werden. Ihre App ist von diesen betrieblichen Funktionen entkoppelt, die auf die Infrastrukturebene verschoben werden. Aus architektonischer Sicht besteht ein Dienstnetz aus zwei Komponenten: einer Steuerungsebene und einer Datenebene.
Die Steuerungsebene verfügt über eine Reihe von Komponenten, die die Verwaltung des Dienstnetzes (Service Mesh) unterstützen. Der Bestand an Komponenten umfasst in der Regel Folgendes:
- eine Verwaltungsschnittstelle, die eine Benutzeroberfläche oder eine API sein kann
- Regeln und Richtliniendefinitionen, die definieren, wie das Dienstnetz bestimmte Funktionen implementieren soll
- Sicherheitsverwaltung für Elemente wie starke Identität und Zertifikate für mTLS (Mutual Transport Layer Security)
- Metriken oder Einblicke zum Erfassen und Aggregieren von Metriken und Telemetriedaten aus den Apps
Die Komponente für die Datenebene besteht aus Proxys, die in Verbindung mit den einzelnen Diensten transparent eingefügt werden. Dieses Muster wird als Sidecar-Muster bezeichnet. Jeder Proxy ist so konfiguriert, dass der Netzwerkdatenverkehr in den bzw. aus dem Pod, der Ihren Dienst enthält, gesteuert wird. Mit dieser Konfiguration können die einzelnen Proxys für Folgendes konfiguriert werden:
- Sichern des Datenverkehrs über mTLS
- dynamisches Weiterleiten von Datenverkehr
- Anwenden von Richtlinien auf Datenverkehr
- Sammeln von Metriken und Ablaufverfolgungsinformationen
Einige beliebte Dienstnetzoptionen für Kubernetes-Cluster sind Linkerd, Istio und Consul. Der Fokus in diesem Modul liegt auf Linkerd. Die folgende Abbildung zeigt Interaktionen zwischen Komponenten innerhalb der Daten- und Steuerungsebenen:
Vergleich mit codebasierten Ansätzen
Die wichtigste Fehlerbehandlungsstrategie von Linkerd umfasst Wiederholungen und Timeouts. Da Linkerd über eine systemische Ansicht des gesamten Clusters verfügt, können Resilienzstrategien damit auf neuartige Weisen eingesetzt werden. Ein Beispiel hierfür sind Wiederholungsversuche, bei denen maximal 20 Prozent zusätzliche Last für den Zieldienst hinzugefügt werden. Durch die metrikbasierte Ansicht von Linkerd ist eine dynamische Anpassung an die Clusterbedingungen in Echtzeit möglich. Bei diesem Ansatz wird eine weitere Dimension zur Verwaltung des Clusters, aber kein Code hinzugefügt.
Mit einem codebasierten Ansatz wie mit Polly ist Folgendes möglich:
- Abschätzen, welche Wiederholungs- und Timeoutparameter geeignet sind
- Konzentrieren auf eine bestimmte HTTP-Anforderung
Es gibt keinen angemessenen Ansatz, um im Code Ihrer App auf einen Infrastrukturfehler zu reagieren. Denken Sie daran, dass Hunderte oder Tausende von Anforderungen 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. Komplexe Datenbanktransaktionen sind für Linkerd beispielsweise nicht sichtbar. Solche Transaktionen können mit Polly vor einem Ausfall geschützt werden.
In den nächsten Lerneinheiten implementieren Sie die Resilienz für den Coupondienst mithilfe von Polly und Linkerd.