Implementera infrastrukturåterhämtning med Kubernetes
För implementering av infrastrukturbaserad motståndskraft kan du använda ett tjänstnät. Utöver motståndskraft som inte kräver kodändringar tillhandahåller tjänstnät trafikhantering, principer, säkerhet, stark identitet och överskådlighet. Din app är frikopplad från dessa operativa funktioner, som flyttas till infrastrukturskiktet. Arkitekturmässigt består ett tjänstnät av två komponenter: ett kontrollplan och ett dataplan.
Kontrollplanskomponenten har många komponenter som stöder hantering av tjänstnätet. Komponenternas lager omfattar vanligtvis:
- Ett hanteringsgränssnitt som kan vara ett användargränssnitt eller ett API.
- Regler och principdefinitioner som definierar hur tjänstnätet ska implementera specifika funktioner.
- Säkerhetshantering för bland annat stark identitet, och certifikat för mTLS.
- Mått eller överskådlighet för insamling och aggregering av mått och telemetri från apparna.
Komponenten för dataplanet består av proxyservrar som matas in transparent tillsammans med varje tjänst. Detta kallas sidecar-mönstret. Varje proxy är konfigurerad för att styra nätverkstrafiken in och ut från podden som innehåller din tjänst. Konfigurationen gör att varje proxy kan konfigureras att:
- Skydda trafik via mTLS.
- Dirigera trafik dynamiskt.
- Tillämpa principer på trafik.
- Samla in mått- och spårningsinformation.
Några populära tjänstnätsalternativ för Kubernetes-kluster är Linkerd, Istio och Consul. I den här modulen ligger fokus på Linkerd. Följande diagram visar interaktioner mellan komponenter i data- och kontrollplanen:
Jämförelse med kodbaserade metoder
Linkerds huvudsakliga strategi för felhantering omfattar återförsök och tidsgränser. Eftersom Linkerd har en systemisk vy över hela klustret kan det använda återhämtningsstrategier på nya sätt. Ett exempel är att försöka igen på ett sätt som gör det möjligt att lägga till maximalt 20 procents extra belastning på måltjänsten. Den måttbaserade vyn i Linkerd gör att det kan anpassas dynamiskt efter klustertillstånd i realtid. Den här metoden lägger till en extra dimension vad gäller hantering av klustret, men den lägger inte till någon kod.
Med en kodbaserad metod, till exempel Polly, gäller följande:
- Du måste gissa vilka parametrar för återförsök och tidsgräns som är lämpliga.
- Du måste fokusera på en specifik HTTP-begäran.
Det finns inget rimligt sätt att svara på ett infrastrukturfel i koden för din app. Tänk dig de hundratals eller tusentals begäranden som bearbetas samtidigt. Även ett återförsök med exponentiell begränsning (gånger antalet begäranden) kan överbelasta en tjänst.
Infrastrukturbaserade metoder som Linkerd är däremot inte medvetna om appens interna funktioner. Till exempel är komplexa databastransaktioner osynliga för Linkerd. Sådana transaktioner kan skyddas från fel med hjälp av Polly.
I kommande enheter implementerar du motståndskraft för kupongtjänsten med hjälp av Polly och Linkerd.