Implementera infrastrukturåterhämtning med Kubernetes

Om du vill implementera infrastrukturbaserad återhämtning kan du använda ett service-mesh. Förutom återhämtning utan att ändra kod ger ett servicenät trafikhantering, princip, säkerhet, stark identitet och observerbarhet. Appen är frikopplad från dessa driftfunktioner som flyttas till infrastrukturlagret. Arkitekturmässigt består ett servicenät av två komponenter: ett kontrollplan och ett dataplan.

Kontrollplanskomponenten har många komponenter som stöder hantering av tjänstnätet. I komponentinventeringen ingår 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 saker som stark identitet och certifikat för mTLS.
• Mått eller observerbarhet för att samla in och aggregera mått och telemetri från apparna.

Komponenten för dataplanet består av proxyservrar som transparent matas in tillsammans med varje tjänst, vilket 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. Med den här konfigurationen kan varje proxy konfigureras för att:

• Säker trafik via mTLS.
• Dirigera trafik dynamiskt.
• Tillämpa principer på trafik.
• Samla in mått och spårningsinformation.

Några populära service mesh-alternativ för Kubernetes-kluster är Linkerd, Istio och Consul. Den här modulen fokuserar på Linkerd. Följande diagram visar interaktioner mellan komponenter i data- och kontrollplan:

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ådant sätt att du lägger till maximalt 20 procent extra belastning på måltjänsten. Med Linkerds måttbaserade vy kan den anpassas dynamiskt till klusterförhållanden i realtid. Den här metoden lägger till ytterligare en dimension för att hantera klustret, men lägger inte till någon kod.

Med en kodbaserad metod, till exempel med Polly, kan du:

• Krävs för att gissa vilka parametrar för återförsök och tidsgräns som är lämpliga.
• Fokusera på en specifik HTTP-begäran.

Det finns inget rimligt sätt att svara på ett infrastrukturfel i appens kod. Överväg de hundratals eller tusentals begäranden som bearbetas samtidigt. Även ett nytt försök med exponentiell back-off (antal gånger begäranden) kan översvämma 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 mot misslyckande med Polly.

I kommande enheter implementerar du motståndskraft för kupongtjänsten med hjälp av Polly och Linkerd.