Čau Habr! Předkládám vaší pozornosti překlad článku "Datová rovina servisní sítě vs řídicí rovina" autor Matt Klein.

Tentokrát jsem „chtěl a přeložil“ popis obou komponent servisní sítě, datové roviny a řídicí roviny. Tento popis se mi zdál nejsrozumitelnější a nejzajímavější, a hlavně vedoucí k pochopení „Je to vůbec nutné?

Vzhledem k tomu, že myšlenka „Service mesh“ se za poslední dva roky stala stále populárnější (Původní článek 10. října 2017) a počet účastníků v prostoru se zvýšil, zaznamenal jsem úměrný nárůst zmatků mezi celou technická komunita ohledně toho, jak porovnávat a porovnávat různá řešení.

Situaci nejlépe shrnuje následující série tweetů, které jsem napsal v červenci:

Service mesh zmatek #1: Linkerd ~ = Nginx ~ = Haproxy ~ = Envoy. Žádný z nich se nevyrovná Istiovi. Istio je něco úplně jiného. 1 /

První jsou jednoduše datové roviny. Sami o sobě nic nedělají. Musí mít náladu na něco víc. 2/

Istio je příkladem řídicí roviny, která spojuje díly dohromady. Toto je další vrstva. /konec

Předchozí tweety zmiňují několik různých projektů (Linkerd, NGINX, HAProxy, Envoy a Istio), ale co je důležitější, představují obecné koncepty datové roviny, servisní sítě a řídicí roviny. V tomto příspěvku udělám krok zpět a pohovořím o tom, co myslím pojmy „datová rovina“ a „kontrolní rovina“ na velmi vysoké úrovni, a poté promluvím o tom, jak se termíny vztahují na projekty zmíněné v tweetech.

Co je to vlastně servisní síť?

Obrázek 1: Přehled servisní sítě

Obrázek 1 ilustruje koncept sítě služeb na její nejzákladnější úrovni. Existují čtyři clustery služeb (AD). Každá instance služby je přidružena k místnímu proxy serveru. Veškerý síťový provoz (HTTP, REST, gRPC, Redis atd.) z jedné instance aplikace je předán přes lokální proxy do příslušných externích clusterů služeb. Tímto způsobem instance aplikace nezná síť jako celek a je si vědoma pouze svého místního proxy. Ve skutečnosti byla síť distribuovaného systému odstraněna ze služby.

Datová rovina

V servisní síti provádí server proxy umístěný lokálně pro aplikaci následující úkoly:

• Zjištění služby. Jaké služby/aplikace jsou dostupné pro vaši aplikaci?
• Kontrola zdravotního stavu. Jsou instance služeb vrácené zjišťováním služby v pořádku a připraveny přijmout síťový provoz? To může zahrnovat jak aktivní (např. odezva/kontrola stavu), tak pasivní (např. použití 3 po sobě jdoucích chyb 5xx jako indikace nezdravého stavu služby) kontroly stavu.
• Směrování. Při příjmu požadavku na „/foo“ ze služby REST, kterému clusteru služeb má být požadavek odeslán?
• Vyvažování zátěže. Jakmile byl během směrování vybrán cluster služeb, do které instance služby by měl být požadavek odeslán? S jakým časovým limitem? S jakým nastavením vypínání? Pokud se požadavek nezdaří, měl by se opakovat?
• Autentizace a autorizace. U příchozích požadavků lze volající službu kryptograficky identifikovat/autorizovat pomocí mTLS nebo jiného mechanismu? Pokud je rozpoznán/autorizován, je povoleno volat požadovanou operaci (koncový bod) na službě nebo by měla být vrácena neověřená odpověď?
• Pozorovatelnost. Pro každý požadavek by měly být generovány podrobné statistiky, protokoly/protokoly a distribuovaná trasovací data, aby operátoři mohli pochopit distribuovaný tok provozu a problémy s laděním, jakmile nastanou.

Datová rovina je zodpovědná za všechny předchozí body v servisní síti. Ve skutečnosti je místním proxy pro službu (sidecar) datová rovina. Jinými slovy, datová rovina je zodpovědná za podmíněné vysílání, předávání a monitorování každého síťového paketu, který je odeslán do nebo ze služby.

Řídící rovina

Síťová abstrakce, kterou poskytuje místní proxy v datové rovině, je kouzelná(?). Jak však proxy ve skutečnosti ví o cestě „/foo“ ke službě B? Jak lze použít data zjišťování služby, která jsou vyplněna požadavky proxy? Jak jsou nakonfigurovány parametry pro vyrovnávání zátěže, časový limit, přerušení obvodu atd.? Jak nasadíte aplikaci pomocí modré/zelené metody nebo metody elegantního přechodu provozu? Kdo konfiguruje nastavení ověřování a autorizace v celém systému?

Všechny výše uvedené položky jsou pod kontrolou řídicí roviny obslužné sítě. Řídicí rovina vezme sadu izolovaných bezstavových proxy a přemění je na distribuovaný systém.

Myslím, že důvod, proč mnoho technologů považuje oddělené koncepty datové roviny a řídicí roviny za matoucí, je ten, že pro většinu lidí je datová rovina známá, zatímco řídicí rovina je cizí/nepochopená. S fyzickými síťovými routery a přepínači pracujeme již delší dobu. Chápeme, že pakety/požadavky musí jít z bodu A do bodu B a že k tomu můžeme použít hardware a software. Nová generace softwarových proxy jsou jednoduše luxusní verze nástrojů, které používáme již dlouhou dobu.

Obrázek 2: Lidská řídicí rovina

Řídící roviny však používáme již dlouhou dobu, i když většina provozovatelů sítí nemusí tuto část systému spojovat s žádnou technologickou komponentou. Důvod je jednoduchý:
Většina dnes používaných řídicích letadel jsme... my.

Na obrázek 2 ukazuje to, čemu říkám „lidská řídicí rovina“. V tomto typu nasazení, které je stále velmi běžné, pravděpodobně nevrlý lidský operátor vytváří statické konfigurace - potenciálně prostřednictvím skriptů - a nasazuje je pomocí nějakého speciálního procesu na všechny proxy. Proxy pak začnou používat tuto konfiguraci a začnou zpracovávat datovou rovinu pomocí aktualizovaných nastavení.

Obrázek 3: Pokročilá řídicí rovina servisní sítě

Na obrázek 3 ukazuje „rozšířenou“ řídicí rovinu servisní sítě. Skládá se z následujících částí:

• Člověk: Stále existuje člověk (doufejme, že méně naštvaný), který činí rozhodnutí na vysoké úrovni týkající se celého systému jako celku.
• Řídicí rovina UI: Osoba komunikuje s nějakým typem uživatelského rozhraní za účelem ovládání systému. Může to být webový portál, aplikace příkazového řádku (CLI) nebo nějaké jiné rozhraní. Pomocí uživatelského rozhraní má operátor přístup ke globálním parametrům konfigurace systému, jako jsou:
  • Řízení nasazení, modrá/zelená a/nebo postupný přechod provozu
  • Možnosti autentizace a autorizace
  • Specifikace směrovací tabulky, například když aplikace A požaduje informace o "/foo", co se stane
  • Nastavení load balanceru, jako jsou časové limity, opakování, nastavení přerušení obvodu atd.
• Plánovač pracovní zátěže: Služby běží na infrastruktuře prostřednictvím určitého typu systému plánování/orchesttrace, jako je Kubernetes nebo Nomad. Plánovač je zodpovědný za načtení služby spolu s jejím místním proxy.
• Zjištění služby. Když plánovač spouští a zastavuje instance služby, nahlásí stav systému zjišťování služeb.
• Rozhraní API pro konfiguraci proxy postranního vozíku : Lokální proxy dynamicky extrahují stav z různých systémových komponent pomocí případně konzistentního modelu bez zásahu operátora. Celý systém, skládající se ze všech aktuálně spuštěných instancí služeb a lokálních proxy serverů, nakonec konverguje do jednoho ekosystému. Envoy's universal data plane API je jedním z příkladů, jak to funguje v praxi.

Účelem řídicí roviny je v podstatě nastavit politiku, která bude nakonec přijata datovou rovinou. Pokročilejší řídicí roviny odstraní z operátora více částí některých systémů a vyžadují méně ruční obsluhy, za předpokladu, že fungují správně!...

Datová rovina a řídicí rovina. Shrnutí datové roviny vs. kontrolní roviny

• Datová rovina servisní sítě: Ovlivňuje každý paket/požadavek v systému. Zodpovědný za zjišťování aplikací/služeb, kontrolu stavu, směrování, vyvažování zátěže, ověřování/autorizaci a pozorovatelnost.
• Ovládací rovina servisní sítě: Poskytuje zásady a konfiguraci pro všechny běžící datové roviny v rámci servisní sítě. Nedotýká se žádných balíčků/požadavků v systému. Řídicí rovina přemění všechny datové roviny na distribuovaný systém.

Aktuální projektová krajina

Po pochopení výše uvedeného vysvětlení se podívejme na současný stav projektu service mesh.

• Datové roviny: Linkerd, NGINX, HAProxy, Envoy, Traefik
• Řídící letadla: Istio, Nelson, SmartStack

Než abych se pouštěl do hloubkové analýzy každého z výše uvedených řešení, budu se stručně věnovat některým bodům, o kterých se domnívám, že právě teď způsobují v ekosystému velký zmatek.

Linkerd byl jedním z prvních proxy serverů datové roviny pro síť služeb na začátku roku 2016 a odvedl skvělou práci při zvyšování povědomí a pozornosti k modelu návrhu sítě služeb. Asi 6 měsíců poté se Envoy připojil k Linkerd (ačkoli byl v Lyftu od konce roku 2015). Linkerd a Envoy jsou dva projekty, které jsou nejčastěji zmiňovány při diskuzi o servisních sítích.

Istio bylo oznámeno v květnu 2017. Cíle projektu Istio jsou velmi podobné rozšířené řídicí rovině zobrazené v obrázek 3. Envoy for Istio je výchozí proxy. Istio je tedy řídicí rovina a Envoy je datová rovina. V krátké době vyvolalo Istio spoustu vzrušení a jako náhrada za Envoy se začaly integrovat další datové roviny (Linkerd i NGINX prokázaly integraci s Istio). Skutečnost, že v rámci stejné řídicí roviny lze použít různé datové roviny, znamená, že řídicí rovina a datová rovina nemusí být nutně těsně propojeny. API, jako je generická datová rovina API Envoy, může tvořit most mezi dvěma částmi systému.

Nelson a SmartStack pomáhají dále ilustrovat oddělení řídicí roviny a datové roviny. Nelson používá Envoy jako svého proxy a vytváří spolehlivou řídicí rovinu pro servisní síť založenou na zásobníku HashiCorp, tj. Nomád atd. SmartStack byl možná první z nové vlny servisních sítí. SmartStack vytváří řídicí rovinu kolem HAProxy nebo NGINX, což demonstruje schopnost oddělit řídicí rovinu od servisní sítě od datové roviny.

Architektura mikroservisů s obslužnou sítí si získává stále více pozornosti (právem!) a tímto směrem začíná pracovat stále více projektů a dodavatelů. Během několika příštích let uvidíme spoustu inovací jak v datové rovině, tak v řídicí rovině, stejně jako další míchání různých komponent. V konečném důsledku by se architektura mikroslužeb měla stát pro operátora transparentnější a kouzelnější (?).
Doufám, že méně a méně podrážděná.

Klíčové věci

• Servisní síť se skládá ze dvou různých částí: datové roviny a řídicí roviny. Obě součásti jsou povinné a bez nich systém nebude fungovat.
• Každý je obeznámen s řídicí rovinou a v tomto bodě byste řídicí rovinou mohli být vy!
• Všechny datové roviny spolu soutěží o funkce, výkon, konfigurovatelnost a rozšiřitelnost.
• Všechny řídicí roviny si navzájem konkurují ve funkcích, konfigurovatelnosti, rozšiřitelnosti a snadném použití.
• Jedna řídicí rovina může obsahovat správné abstrakce a rozhraní API, takže lze použít více datových rovin.

Zdroj: www.habr.com