Implementace odolnosti infrastruktury pomocí Kubernetes
K implementaci odolnosti založené na infrastruktuře můžete použít sítě služby. Kromě odolnosti beze změny kódu nabízí síť služeb správu provozu, zásady, zabezpečení, silnou identitu a pozorovatelnost. Vaše aplikace je oddělená od těchto provozních možností, které se přesunou do vrstvy infrastruktury. Z pohledu architektury se síť služeb skládá ze dvou komponent: řídicí roviny a roviny dat.
Komponenta řídicí roviny má mnoho komponent, které podporují správu sítě služeb. Inventář komponent obvykle zahrnuje následující komponenty:
- Rozhraní pro správu, což může být uživatelské rozhraní nebo rozhraní API
- Definice pravidel a zásad, které definují způsob, jakým má síť služeb implementovat konkrétní možnosti
- Správa zabezpečení položek, jako je silná identita a certifikáty pro mTLS
- Metriky nebo pozorovatelnost pro shromažďování a agregaci metrik a telemetrie z aplikací
Komponenta roviny dat se skládá z proxy serverů, které jsou transparentně vloženy spolu s každou službou; to se označuje jako model Sidecar. Každý proxy server je nakonfigurovaný tak, aby kontroloval síťový provoz v podu, který obsahuje vaši službu. Tato konfigurace umožňuje, aby každé proxy bylo nakonfigurováno na:
- Zabezpečený provoz prostřednictvím mTLS
- Dynamické směrování provozu
- Použití zásad na provoz
- Shromažďování metrik a informací o trasování
Mezi oblíbené možnosti sítí služeb pro clustery Kubernetes patří Linkerd, Istio a Consul. Tento modul se zaměřuje na Linkerd. Následující diagram znázorňuje interakce mezi komponentami v rámci rovin dat a řídicích rovin:
Porovnání s přístupy založenými na kódu
Hlavní strategie zpracování chyb linkerd se skládá z opakování a časových limitů. Vzhledem k tomu, že Linkerd má systémový pohled na celý cluster, může využívat strategie odolnosti v nových způsobech. Příkladem je opakování takovým způsobem, který přidá maximálně 20 % dalšího zatížení v cílové službě. Pohled založený na metrikách umožňuje řešení Linkerd dynamicky se adaptovat na okolnosti clusteru v reálném čase. Tento přístup přidává ke správě clusteru další dimenzi, nepřidává ale žádný kód.
Přístup založený na kódu, například s využitím Polly:
- Vyžaduje, abyste odhadli, jaké parametry opakování a časových limitů jsou vhodné.
- Zaměřuje se na konkrétní požadavek HTTP.
Neexistuje žádný rozumný způsob, jak reagovat na selhání infrastruktury v kódu vaší aplikace. Vezměte v úvahu stovky nebo tisíce požadavků, které se současně zpracovávají. Dokonce i opakování s exponenciálním zpomalením (počet požadavků) může službu zahltit.
Naproti tomu přístupy založené na infrastruktuře, jako je Linkerd, neví o interních aplikacích. Například složité databázová transakce jsou pro Linkerd neviditelné. Tyto transakce lze chránit před selháním pomocí Polly.
V nadcházejících lekcích implementujete odolnost kuponové služby pomocí Polly a Linkerd.