Ahoj, Habr! Představuji vám překlad článku „Data plane a control plane v síti služeb“ autora Matt Klein.

Tentokrát jsem „chtěl a přeložil“ popis obou komponent sítí služeb, data plane a control plane. Tento popis mi přišel nejjasnější a nejzajímavější, a co je nejdůležitější, vede k pochopení „Potřebujeme to vůbec?“.

Vzhledem k tomu, že myšlenka „Sítě služeb (Service mesh)“ se stává stále populárnější v posledních dvou letech (původní článek z 10. října 2017), a počet účastníků v tomto prostoru vzrostl, viděl jsem úměrný růst zmatku v technické komunitě ohledně toho, jak porovnávat a proti sobě postavit různá řešení.

Nejlépe tuto situaci popsat následujícími sériemi tweetů, které jsem napsal v červenci:

Zmatek v síti služeb (service mesh) č. 1: Linkerd ~ = Nginx ~ = Haproxy ~ = Envoy. Žádný z nich není rovný Istio. Istio je něco zcela jiného. 1 /

První jsou prostě datové plochy (data planes). Samy o sobě nic nedělají. Musí být konfigurovány na něco většího. 2 /

Istio je příkladem řídicí plochy (control plane), která spojuje jednotlivé části dohromady. To je jiná vrstva. /konec

V předchozích tweetech je zmíněno několik různých projektů (Linkerd, NGINX, HAProxy, Envoy a Istio), ale co je důležitější, uvádějí se společné pojmy datové plochy (data plane), sítě služeb (service mesh) a řídicí plochy (control plane). V tomto příspěvku udělám krok zpět a řeknu, co myslím pod pojmy „datová plocha (data plane)“ a „řídicí plocha (control plane)“ na velmi vysoké úrovni, a poté vysvětlím, jak se tyto termíny vztahují k projektům zmíněným v tweetech.

Co je to síť služeb (What is a service mesh, really)?

Obrázek 1: Přehled sítě služeb (Service mesh overview)

Obr. 1 ilustruje koncept sítě služeb (service mesh) na nejzákladnější úrovni. Existují čtyři servisní clustry (A-D). Každý instance služby je propojena s lokálním proxy serverem. Veškerý síťový provoz (HTTP, REST, gRPC, Redis atd.) z jednotlivé instance aplikace je směrován přes lokální proxy server do odpovídajících vnějších servisních clusterů. Tím pádem instance aplikace neví o celé síti a zná pouze svůj lokální proxy. Ve skutečnosti je síť distribuovaného systému odstraněna od služby.

Datová plocha (Data plane)

V síti služeb (service mesh) vykonává lokální proxy server pro aplikaci následující úkoly:

Objevování služeb (Service discovery). Jaké služby/aplikace jsou dostupné pro vaši aplikaci?
Kontrola zdravotního stavu (Health checking). Jsou instance služeb vrácené objevením služeb (service discovery) funkční a připravené přijímat síťový provoz? To může zahrnovat jak aktivní (např. kontrolu odpovědi / healthcheck), tak pasivní (např. použití 3 po sobě jdoucích 5xx chyb jako indikace nezdravého stavu služby) kontroly zdravotního stavu.
Směrování (Routing). Když obdržíte od služby REST dotaz na „/foo“, do kterého servisního clusteru by měl být dotaz odeslán?
Zatížení vyrovnávání (Load balancing). Poté, co byl během směrování vybrán cluster služby, do které instance služby by měl být dotaz odeslán? S jakým časovým limitem? S jakými nastaveními přerušení obvodu (circuit breaking)? Pokud dotaz selže, měl by být zopakován?
Autentizace a autorizace (Authentication and authorization). Může být volající služba pro příchozí dotazy kryptograficky identifikována/autorizována pomocí mTLS nebo jiného mechanismu? Pokud je identifikována/autorizována, je jí povoleno volat požadovanou operaci (endpoint) ve službě nebo by měla být vrácena neautentizovaná odpověď?
Pozorovatelnost (Observability). Pro každý dotaz by měly být generovány podrobné statistiky, protokoly a údaje o distribuovaném sledování, aby operátoři mohli porozumět distribuovanému toku provozu a problémům s laděním, jak se objevují.

Za všechny předchozí body v servisní síti (service mesh) odpovídá datová plocha (data plane). V podstatě, lokální proxy pro službu (sidecar) a je datovou plochou (data plane). Jinými slovy, datová plocha (data plane) odpovídá za podmínkovou transkripci, přenos a pozorování každého síťového balíčku, který je odesílán do služby nebo z ní.

Řídící plocha (The control plane)

Síťová abstrakce, kterou poskytuje místní proxy v datové rovině (data plane), je kouzelná (?). Přesto, jak se proxy server skutečně dozvídá o trase „/foo“ k službě B? Jak mohou být data objevování služeb (service discovery), která jsou vyplněna proxy požadavky, využita? Jak jsou nakonfigurovány parametry vyvážení zátěže, časového limitu (timeout), přerušení obvodu (circuit breaking) atd.? Jak se provádí nasazení aplikace pomocí modré/zelené (blue/green) metody nebo metody postupného přesměrování provozu? Kdo nastavuje parametry systémového ověřování a autorizace?

Všechny výše uvedené body spadají pod kontrolní rovinu (control plane) servisní sítě (service mesh). Kontrolní rovina (control plane) bere soubor izolovaných proxy-servery bez stavu a přetváří je na distribuovaný systém.

Myslím si, že důvod, proč mnoho techniků považuje oddělené pojmy datové roviny (data plane) a kontrolní roviny (control plane) za matoucí, je v tom, že většina lidí je obeznámena s datovou rovinou, zatímco kontrolní rovina je pro ně cizí/neznámá. Dlouho pracujeme s fyzickými síťovými routery a přepínači. Chápeme, že pakety/požadavky musejí jít z bodu A do bodu B a co můžeme použít k tomu hardwaru a softwaru. Nová generace softwarových proxy je prostě módní verzí nástrojů, které jsme používali již dlouhou dobu.

Obrázek 2: Lidská kontrolní rovina (Human control plane)

Přesto jsme již dlouho používali kontrolní roviny (control plane), i když většina síťových operátorů nemusí tuto část systému spojovat s žádnou technologickou komponentou. Důvod je jednoduchý:
Většina dnes používaných kontrolních rovin (control plane) jsou… my.

Na na obrázku 2 Zobrazeno je to, co nazývám „Lidská řídicí rovina (Human control plane)“. V tomto typu nasazení, které se stále velmi často vyskytuje, člověk-operátor, pravděpodobně podrážděný, vytváří statické konfigurace - potenciálně pomocí skriptů - a nasazuje je pomocí nějakého speciálního procesu na všechny proxy servery. Poté proxy začnou používat tuto konfiguraci a přistupují k zpracování datové roviny (data plane) pomocí aktualizovaných nastavení.

Obrázek 3: Rozšířená řídicí rovina servisní sítě (Advanced service mesh control plane)

Na na obrázku 3 je zobrazena „rozšířená“ řídicí rovina (control plane) servisní sítě (service mesh). Skládá se z následujících částí:

Člověk (The human): Pořád je tu člověk (doufejme, méně rozčilený), který přijímá rozhodnutí na vysoké úrovni týkající se celého systému.
Uživatelské rozhraní řídicí roviny (Control plane UI): Člověk interaguje s nějakým typem uživatelského rozhraní pro řízení systému. Může to být webový portál, příkazová řádka (CLI) nebo nějaké jiné rozhraní. Pomocí uživatelského rozhraní má operátor přístup k takovým globálním parametrům konfigurace systému, jako jsou:
- Správa nasazení, blue/green a/nebo postupné přesměrování provozu
- Parametry autentizace a autorizace
- Specifikace směrovací tabulky, například co se stane, když aplikace A požaduje informace o „/foo“
- Nastavení vyrovnávače zátěže, například časové limity (timeouts), opakování pokusů (retries), parametry přerušení řetězce (circuit breaking) atd.
Plánovač pracovního zatížení (Workload scheduler): Služby jsou spuštěny v infrastruktuře prostřednictvím systému plánování/orkestrace určitého typu, například Kubernetes nebo Nomad. Plánovač je zodpovědný za spuštění služby spolu s jejím lokálním proxy serverem.
Objevování služeb (Service discovery). Když plánovač spouští a zastavuje instance služby, informuje o stavu dostupnosti systému objevování služeb.
API konfigurace lokálního proxy serveru (Sidecar proxy configuration APIs) : Místní proxy servery dynamicky získávají stav z různých komponent systému podle modelu „konečné shody“ (eventually consistent) bez účasti operátora. Celý systém, skládající se ze všech aktuálně spuštěných instancí služeb a místních proxy serverů, se nakonec spojuje do jedné ekosystémy. API univerzální datové roviny (data plane) v Envoy je jedním z příkladů toho, jak to funguje v praxi.

V zásadě je cílem řídící roviny (control plane) stanovit pravidla, která budou nakonec přijata datovou rovinou (data plane). Pokročilejší řídící roviny (control plane) odstraní od operátora více detailů některých systémů a budou vyžadovat méně ručního řízení, pokud budou fungovat správně!..

Datová rovina a řídící rovina. Souhrn (Data plane vs. control plane summary)

Datová rovina servisní sítě (Service mesh data plane): zasahuje do každého paketu / požadavku v systému. Odpovídá za objevování aplikací / služeb, kontrolu dostupnosti, směrování, vyvažování zátěže, autentizaci / autorizaci a pozorovatelnost.
Řídící rovina servisní sítě (Service mesh control plane): poskytuje pravidla a konfiguraci pro všechny fungující datové roviny v rámci servisní sítě. Nezasahuje do žádných paketů / požadavků v systému. Řídící rovina transformuje všechny datové roviny na distribuovaný systém.

Aktuální stav projektu (Current project landscape)

Po pochopení výše uvedeného vysvětlení se podívejme na aktuální stav projektu „servisní sítě (service mesh)“.

Datové roviny (Data planes): Linkerd, NGINX, HAProxy, Envoy, Traefik
Řídící roviny (Control planes): Istio, Nelson, SmartStack

Místo toho, abych se podrobně zabýval každým z výše uvedených řešení, stručně se dotknu několika bodů, které podle mého názoru vyvolávají většinu zmatku v ekosystému právě teď.

Na začátku roku 2016 byl Linkerd jedním z prvních proxy serverů datové roviny (data plane) pro servisní síť (service mesh) a udělal fantastickou práci při zvyšování povědomí a pozornosti na model návrhu „servisní síť“ (service mesh). Přibližně po 6 měsících se k Linkerd připojil Envoy (i když pracoval ve Lyftu od konce roku 2015). Linkerd a Envoy jsou dva projekty, které se nejčastěji zmiňují při diskusi o servisních sítích (service mesh).

Istio bylo oznámeno v květnu 2017. Cíle projektu Istio jsou velmi podobné rozšířené řídicí rovině (control plane), která je znázorněna na na obrázku 3. Envoy pro Istio je proxy server „ve výchozím nastavení“. Tím pádem je Istio řídicí rovinou (control plane) a Envoy je datovou rovinou (data plane). V krátkém čase Istio vyvolalo mnoho vzrušení a jiné datové roviny (data plane) začaly integraci jako náhradu za Envoy (jak Linkerd, tak NGINX demonstrovaly integraci s Istio). Skutečnost, že v jedné řídicí rovině (control plane) lze používat různé datové roviny (data plane), znamená, že řídicí rovina (control plane) a datová rovina (data plane) nemusí být nutně úzce spojeny. Takové API jako univerzální API datové roviny (data plane) Envoy může tvořit most mezi oběma částmi systému.

Nelson a SmartStack dále pomáhají ilustrovat rozdělení řídicí roviny (control plane) a datové roviny (data plane). Nelson používá Envoy jako svůj proxy a vytváří spolehlivou řídicí rovinu (control plane) servisní sítě (service mesh) na základě zásobníku HashiCorp, tj. Nomad atd. SmartStack se stal pravděpodobně prvním z nové vlny servisních sítí (service mesh). SmartStack formuje řídicí rovinu (control plane) kolem HAProxy nebo NGINX a demonstruje možnost oddělení řídicí roviny (control plane) servisní sítě (service mesh) a datové roviny (data plane).

Mikroslužbová architektura se síťovou službou (service mesh) získává stále více pozornosti (správně!), a stále více projektů a dodavatelů začíná v této oblasti pracovat. V průběhu několika následujících let uvidíme mnoho inovací jak v datové rovině (data plane), tak v řídící rovině (control plane), a také další mísení různých komponent. Nakonec by mikroslužbová architektura měla být pro operátora transparentnější a kouzelnější (? ).
Doufám, že stále méně a méně podrážděného.

Klíčové body (Key takeaways)

Síťová služba (service mesh) se skládá ze dvou různých částí: datové roviny (data plane) a řídící roviny (control plane). Oba komponenty jsou povinné, a bez nich systém nebude fungovat.
Všichni známe řídící rovinu (control plane), a v tuto chvíli můžete být vy tou řídící rovinou (control plane)!
Všechny datové roviny (data plane) soutěží navzájem v funkcích, výkonu, konfigurovatelnosti a rozšiřitelnosti.
Všechny řídící roviny (control plane) soutěží navzájem v funkcích, konfigurovatelnosti, rozšiřitelnosti a použitelnosti.
Jedna řídící rovina (control plane) může obsahovat správné abstrakce a API, aby bylo možné používat více datových rovin (data plane).

Zdroj: habr.com