Infrastructuurtolerantie implementeren met Kubernetes
Om infrastructuurgebonden veerkracht te implementeren, kunt u een service meshgebruiken. Afgezien van tolerantie zonder code te wijzigen, biedt een service-mesh verkeerbeheer, beleid, beveiliging, sterke identiteit en waarneembaarheid. Uw app wordt losgekoppeld van deze operationele mogelijkheden, die worden verplaatst naar de infrastructuurlaag. Architectuur gesproken bestaat een service-mesh uit twee onderdelen: een besturingsvlak en een gegevensvlak.
Het besturingsvlak onderdeel 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 definiëren hoe de service-mesh specifieke mogelijkheden moet implementeren.
- Beveiligingsbeheer voor zaken als sterke identiteit en certificaten voor mTLS.
- Metrische gegevens of waarneembaarheid voor het verzamelen en aggregeren van metrische gegevens en telemetrie van de apps.
Het gegevensvlak onderdeel 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:
- Verkeer beveiligen via mTLS.
- Verkeer dynamisch routeren.
- Beleid toepassen op verkeer.
- Verzamel metrische gegevens en traceringsgegevens.
Enkele populaire service mesh-opties voor Kubernetes-clusters zijn Linkerd, Istio en Consul. Deze module richt zich op Linkerd. In het volgende diagram ziet u interacties tussen onderdelen in 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 is het opnieuw proberen om een maximum van 20 procent extra belasting toe te voegen aan de doelservice. Met de weergave op basis van metrische gegevens van Linkerd kan deze dynamisch worden aangepast aan clusteromstandigheden in realtime. Met deze methode wordt een andere dimensie toegevoegd voor het beheren van het cluster, maar er wordt geen code toegevoegd.
Met een op code gebaseerde benadering, zoals met Polly, kunt u het volgende doen:
- U moet raden welke parameters voor nieuwe pogingen en time-outs geschikt zijn.
- Richt u op een specifieke HTTP-aanvraag.
Er is geen redelijke manier om te reageren op een infrastructuurfout in de code van uw app. Houd rekening met de honderden of duizenden aanvragen die tegelijkertijd worden verwerkt. Zelfs een nieuwe poging met exponentieel uitstel, vermenigvuldigd met het aantal verzoeken, 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 beschermd tegen fouten.
In toekomstige eenheden implementeert u tolerantie voor de couponservice met behulp van Polly en Linkerd.