Infrastructuurtolerantie implementeren met Kubernetes
Als u op infrastructuur gebaseerde tolerantie wilt implementeren, kunt u een servicemesh gebruiken. Behalve dat er bij een servicemesh sprake is van tolerantie zonder dat er code bij te pas komt, levert deze ook verkeerbeheer, beleid, beveiliging, een sterke identiteit en waarneembaarheid. Uw app wordt losgekoppeld van deze operationele mogelijkheden, die worden verplaatst naar de infrastructuurlaag. Vanuit het perspectief van de architectuur bestaat een servicemesh uit twee onderdelen: een besturingsvlak en een gegevensvlak.
Het besturingsvlakonderdeel bevat veel onderdelen die ondersteuning bieden voor het beheer van de service-mesh. De inventaris van onderdelen omvat doorgaans:
- Een beheerinterface, die een gebruikersinterface of een API kan zijn.
- Regels en beleidsdefinities die bepalen hoe de servicemesh specifieke mogelijkheden moet implementeren.
- Beveiligingsbeheer voor zaken als sterke identiteit en certificaten voor mTLS.
- Metrische gegevens of waarneembaarheid voor het verzamelen en samenvoegen van metrische gegevens en telemetriegegevens van de apps.
Het gegevensvlakonderdeel bestaat uit proxy's die transparant naast elke service worden geïnjecteerd. Dit wordt het Sidecar-patroon genoemd. Elke proxy is geconfigureerd voor het beheren van het netwerkverkeer in en uit de pod die uw service bevat. Met deze configuratie kan elke proxy worden geconfigureerd voor:
- Het beveiligen van verkeer via mTLS.
- Het dynamisch doorsturen van verkeer.
- Het toepassen van beleid op verkeer.
- Het verzamelen van metrische gegevens en traceringsinformatie.
Enkele populaire servicemesh-opties voor Kubernetes-clusters zijn Linkerd, Istio en Consul. Deze module is gericht op Linkerd. In het volgende diagram ziet u de interacties tussen onderdelen op de gegevens- en besturingsvlakken:
Vergelijking met op code gebaseerde benaderingen
De belangrijkste foutafhandelingsstrategie van Linkerd bestaat uit nieuwe pogingen en time-outs. Omdat Linkerd een systemische weergave van het hele cluster heeft, kan het tolerantiestrategieën op nieuwe manieren gebruiken. Een voorbeeld hiervan is dat nieuwe pogingen worden ondernomen waarbij maximaal 20 procent extra belasting aan de doelservice mag worden toegevoegd. Omdat Linkerd een op metrische gegevens gebaseerd perspectief hanteert, kan het zich dynamisch en in realtime aan de omstandigheden van een cluster aanpassen. Met deze benadering wordt een andere dimensie toegevoegd voor het beheren van het cluster, zonder dat er code wordt toegevoegd.
Met een op code gebaseerde benadering, zoals bij Polly:
- Ben u verplicht om te gissen welke parameters voor opnieuw proberen en het toepassen van time-outs geschikt zijn.
- Richt u zich op een specifieke HTTP-aanvraag.
Er is geen redelijke manier om te reageren op een infrastructuurfout in de code van uw app. Denk aan de honderden of duizenden aanvragen die tegelijkertijd worden verwerkt. Zelfs een nieuwe poging met exponentieel afzien van activiteit (maal het aantal aanvragen) kan een service overbelasten.
Daarentegen zijn op infrastructuur gebaseerde benaderingen zoals Linkerd niet op de hoogte van de interne werking van apps. Complexe databasetransacties zijn bijvoorbeeld onzichtbaar voor Linkerd. Dergelijke transacties kunnen met Polly worden beveiligd tegen fouten.
In toekomstige eenheden implementeert u tolerantie voor de couponservice met behulp van Polly en Linkerd.