Implementace odolnosti infrastruktury pomocí Kubernetes
K implementaci odolnosti založené na infrastruktuře můžete použít síť služeb. Kromě odolnosti beze změny kódu poskytuje 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 funkcí, které se přesunou do vrstvy infrastruktury. V architektuře 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:
- Rozhraní pro správu, které může být uživatelské rozhraní nebo rozhraní API.
- Pravidla a definice zásad, které definují, jak by síť služeb měla implementovat konkrétní možnosti.
- Správa zabezpečení pro věci, jako je silná identita a certifikáty pro mTLS.
- Metriky nebo pozorovatelnost pro shromažďování a agregaci metrik a telemetrie z aplikací
Komponenta datové roviny se skládá z proxy serverů, které jsou transparentně nasazeny spolu s každou službou, což je známé jako vzor 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 konfiguraci každého proxy serveru na:
- Zabezpečte provoz přes mTLS.
- Dynamicky směrujte provoz.
- Použijte zásady pro provoz.
- Shromážděte metriky a informace 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 dat a řídicích rovin:
Porovnání přístupů založených na kódu
Hlavní strategie zpracování chyb Linkerd zahrnuje opakování a časové limity. 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 opakovaný pokus tak, aby se přidalo maximálně 20 % dodatečného zatížení na cílovou službu. Zobrazení založené na metrikách linkerdu umožňuje dynamicky se přizpůsobovat podmínkám clusteru v reálném čase. Tento přístup přidá další dimenzi pro správu clusteru, ale nepřidá žádný kód.
S přístupem založeným na kódu, jako je například Polly, můžete:
- Je potřeba odhadnout, které parametry opakování a časového limitu jsou vhodné.
- Zaměřte 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 žádostí, které se zpracovávají současně. Dokonce i opakování s exponenciálním zpožděním (násobky počtu požadavků) může přeplnit službu.
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 mohou být chráněny před selháním pomocí Polly.
V nadcházejících modulech implementujete odolnost kuponové služby pomocí Polly a Linkerd.