Na internete (servisná sieť) a tu je ďalšia. Hurá! Ale prečo? Potom chcem vyjadriť svoj názor, že by bolo lepšie, keby sa servisné siete objavili pred 10 rokmi, pred príchodom kontajnerových platforiem, ako sú Docker a Kubernetes. Nehovorím, že môj uhol pohľadu je lepší alebo horší ako ostatné, ale keďže služobné oká sú pomerne zložité zvieratá, viaceré uhly pohľadu im pomôžu lepšie ich pochopiť.
Budem hovoriť o platforme dotCloud, ktorá bola postavená na viac ako stovke mikroslužieb a podporovala tisíce kontajnerových aplikácií. Vysvetlím problémy, ktorým sme čelili pri jeho vývoji a spustení, a ako môžu (alebo nemohli) pomôcť servisné siete.
História dotCloud
Písal som o histórii dotCloud a možnostiach architektúry pre túto platformu, ale nehovoril som veľa o sieťovej vrstve. Ak sa nechcete ponoriť do čítania o dotCloud, tu je podstata v skratke: je to platforma PaaS ako služba, ktorá umožňuje zákazníkom spúšťať širokú škálu aplikácií (Java, PHP, Python...), s podporou širokého spektra údajov služby (MongoDB, MySQL, Redis...) a pracovný postup ako Heroku: Nahráte svoj kód na platformu, ona vytvorí obrázky kontajnerov a nasadí ich.
Poviem vám, ako bola návštevnosť smerovaná na platformu dotCloud. Nie preto, že by to bolo obzvlášť cool (hoci systém na svoju dobu fungoval dobre!), ale predovšetkým preto, že s modernými nástrojmi môže takýto dizajn ľahko implementovať v krátkom čase skromný tím, ak potrebuje spôsob, ako smerovať premávku medzi skupinami. mikroslužieb alebo množstva aplikácií. Týmto spôsobom môžete porovnať možnosti: čo sa stane, ak všetko vyviniete sami alebo použijete existujúcu sieť služieb. Štandardná voľba je vyrobiť si ho sami alebo kúpiť.
Smerovanie premávky pre hostované aplikácie
Aplikácie na dotCloud môžu odhaliť koncové body HTTP a TCP.
koncové body HTTP dynamicky pridané do konfigurácie klastra vyrovnávača zaťaženia . Je to podobné tomu, čo dnes robia zdroje v Kubernetes a nástroj na vyvažovanie záťaže .
Klienti sa pripájajú ku koncovým bodom HTTP prostredníctvom vhodných domén za predpokladu, že názov domény ukazuje na vyrovnávače zaťaženia dotCloud. Nič zvláštne.
Koncové body TCP spojené s číslom portu, ktoré sa potom odovzdá všetkým kontajnerom v tomto zásobníku prostredníctvom premenných prostredia.
Klienti sa môžu pripojiť ku koncovým bodom TCP pomocou príslušného názvu hostiteľa (niečo ako gateway-X.dotcloud.com) a čísla portu.
Tento názov hostiteľa sa rozdelí na klaster serverov „nats“ (nesúvisí s ), ktorý bude smerovať prichádzajúce TCP spojenia do správneho kontajnera (alebo v prípade služieb s vyrovnávaním zaťaženia do správnych kontajnerov).
Ak poznáte Kubernetes, pravdepodobne vám to pripomenie Služby .
Na platforme dotCloud neexistovali žiadne ekvivalentné služby : Pre jednoduchosť sa k službám pristupovalo rovnakým spôsobom zvnútra aj mimo platformy.
Všetko bolo organizované celkom jednoducho: počiatočné implementácie smerovacích sietí HTTP a TCP mali pravdepodobne len niekoľko stoviek riadkov Pythonu. Jednoduché (povedal by som naivné) algoritmy, ktoré sa zdokonaľovali s rastom platformy a objavovaním sa ďalších požiadaviek.
Nebolo potrebné rozsiahle refaktorovanie existujúceho kódu. najmä môže priamo použiť adresu získanú prostredníctvom premenných prostredia.
Ako sa to líši od modernej siete služieb?
Obmedzené viditeľnosť. Nemali sme vôbec žiadne metriky pre smerovaciu sieť TCP. Pokiaľ ide o smerovanie HTTP, neskoršie verzie zaviedli podrobné metriky HTTP s kódmi chýb a časmi odozvy, ale moderné siete služieb idú ešte ďalej a poskytujú integráciu so systémami zberu metrík, ako je napríklad Prometheus.
Viditeľnosť je dôležitá nielen z prevádzkového hľadiska (na pomoc pri riešení problémov), ale aj pri vydávaní nových funkcií. Ide o bezpečnosť и .
Efektívnosť smerovania je tiež obmedzený. V smerovacej sieti dotCloud musela všetka prevádzka prechádzať cez zhluk vyhradených smerovacích uzlov. To znamenalo potenciálne prekročenie viacerých hraníc AZ (zóna dostupnosti) a výrazné zvýšenie latencie. Pamätám si kód na riešenie problémov, ktorý robil viac ako sto SQL dotazov na stránku a otváral nové pripojenie k SQL serveru pre každý dotaz. Pri lokálnom spustení sa stránka načíta okamžite, no v dotCloud trvá načítanie niekoľko sekúnd, pretože každé TCP spojenie (a následný SQL dotaz) trvá desiatky milisekúnd. V tomto konkrétnom prípade problém vyriešili trvalé pripojenia.
Moderné obslužné siete sú lepšie pri riešení takýchto problémov. V prvom rade kontrolujú smerovanie spojov pri zdroji. Logický postup je rovnaký: клиент → меш → сервис, ale teraz mesh funguje lokálne a nie na vzdialených uzloch, takže spojenie клиент → меш je lokálny a veľmi rýchly (mikrosekundy namiesto milisekúnd).
Moderné servisné siete tiež implementujú inteligentnejšie algoritmy vyrovnávania záťaže. Monitorovaním stavu backendov môžu posielať viac prevádzky do rýchlejších backendov, čo vedie k zlepšeniu celkového výkonu.
zabezpečenia tiež lepšie. Smerovacia sieť dotCloud bežala úplne na EC2 Classic a nešifrovala prevádzku (na základe predpokladu, že ak sa niekomu podarilo nasadiť sniffer na sieťovú prevádzku EC2, už ste mali veľké problémy). Moderné servisné siete transparentne chránia všetku našu prevádzku, napríklad vzájomnou TLS autentifikáciou a následným šifrovaním.
Smerovanie prevádzky pre služby platformy
Dobre, diskutovali sme o návštevnosti medzi aplikáciami, ale čo samotná platforma dotCloud?
Samotná platforma pozostávala z približne stovky mikroslužieb zodpovedných za rôzne funkcie. Niektorí akceptovali požiadavky od ostatných a niektorí boli pracovníkmi na pozadí, ktorí sa pripájali k iným službám, ale sami neprijímali pripojenia. V každom prípade musí každá služba poznať koncové body adries, ku ktorým sa potrebuje pripojiť.
Mnoho služieb na vysokej úrovni môže používať smerovaciu sieť opísanú vyššie. V skutočnosti mnohé z viac ako stovky mikroslužieb dotCloud boli nasadené ako bežné aplikácie na samotnej platforme dotCloud. Ale malý počet nízkoúrovňových služieb (najmä tých, ktoré implementujú túto smerovaciu sieť) potreboval niečo jednoduchšie, s menším počtom závislostí (keďže sa pri práci nemohli spoľahnúť sami na seba – starý dobrý problém sliepok a vajec).
Tieto nízkoúrovňové kritické služby boli nasadené spustením kontajnerov priamo na niekoľkých kľúčových uzloch. V tomto prípade neboli použité štandardné služby platformy: linker, plánovač a runner. Ak sa chcete porovnať s modernými kontajnerovými platformami, je to ako spustenie riadiaceho lietadla docker run priamo na uzloch, namiesto delegovania úlohy na Kubernetes. Koncepčne je to dosť podobné , ktorý používa alebo pri zavádzaní samostatného klastra.
Tieto služby boli odhalené jednoduchým a hrubým spôsobom: súbor YAML uvádzal ich mená a adresy; a každý klient si musel vziať kópiu tohto súboru YAML na nasadenie.
Na jednej strane je mimoriadne spoľahlivý, pretože nevyžaduje podporu externého úložiska kľúčov a hodnôt, ako je napríklad Zookeeper (nezabudnite, etcd alebo Consul v tom čase neexistovali). Na druhej strane to sťažilo presun služieb. Zakaždým, keď sa uskutoční presun, všetci klienti dostanú aktualizovaný súbor YAML (a potenciálne sa reštartujú). Nie veľmi pohodlné!
Následne sme začali implementovať novú schému, kde sa každý klient pripájal na lokálny proxy server. Namiesto adresy a portu potrebuje poznať iba číslo portu služby a pripojiť sa cez localhost. Lokálny proxy spracuje toto pripojenie a odošle ho skutočnému serveru. Teraz, keď presúvate backend na iný počítač alebo škálujete, namiesto aktualizácie všetkých klientov stačí aktualizovať všetky tieto lokálne proxy; a reštart už nie je potrebný.
(Plánovalo sa aj zapuzdrenie prevádzky v pripojeniach TLS a umiestnenie ďalšieho proxy servera na prijímacej strane, ako aj overenie certifikátov TLS bez účasti prijímajúcej služby, ktorá je nakonfigurovaná tak, aby prijímala pripojenia iba na localhost. Viac o tom neskôr).
Toto je veľmi podobné od Airbnb, ale podstatný rozdiel je v tom, že SmartStack je implementovaný a nasadený do produkcie, zatiaľ čo interný smerovací systém dotCloud bol odložený, keď sa z dotCloud stal Docker.
Osobne považujem SmartStack za jedného z predchodcov systémov ako Istio, Linkerd a Consul Connect, pretože všetky sledujú rovnaký vzor:
- Spustite proxy na každom uzle.
- Klienti sa pripájajú k proxy.
- Riadiaca rovina aktualizuje konfiguráciu proxy pri zmene koncových serverov.
- ... Zisk!
Moderná implementácia servisnej siete
Ak by sme dnes potrebovali implementovať podobnú sieť, mohli by sme použiť podobné princípy. Napríklad nakonfigurujte internú zónu DNS mapovaním názvov služieb na adresy v priestore 127.0.0.0/8. Potom spustite HAProxy na každom uzle v klastri a akceptujte pripojenia na každej adrese služby (v tejto podsieti 127.0.0.0/8) a presmerovanie/vyrovnanie záťaže na príslušné backendy. Konfiguráciu HAProxy je možné ovládať , čo vám umožňuje ukladať informácie o backende v etcd alebo Consul a v prípade potreby automaticky posielať aktualizovanú konfiguráciu do HAProxy.
Presne takto funguje Istio! Ale s určitými rozdielmi:
- Využitie namiesto HAProxy.
- Ukladá konfiguráciu backendu cez Kubernetes API namiesto etcd alebo Consul.
- Službám sú prideľované adresy na internej podsieti (adresy Kubernetes ClusterIP) namiesto 127.0.0.0/8.
- Má ďalší komponent (Citadel) na pridanie vzájomnej autentifikácie TLS medzi klientom a servermi.
- Podporuje nové funkcie, ako je prerušenie obvodu, distribuované sledovanie, nasadenie kanárikov atď.
Poďme sa rýchlo pozrieť na niektoré rozdiely.
Splnomocnenec vyslanca
Envoy Proxy napísal Lyft [konkurent Uberu na trhu taxíkov - cca. pruh]. V mnohom sa podobá na iné proxy (napr. HAProxy, Nginx, Traefik...), ale Lyft ich napísal, pretože potrebovali funkcie, ktoré iným proxy chýbali, a zdalo sa im múdrejšie vytvoriť nový, než rozširovať existujúci.
Envoy je možné použiť aj samostatne. Ak mám konkrétnu službu, ktorá sa potrebuje pripojiť k iným službám, môžem ju nakonfigurovať tak, aby sa pripojila k Envoy, a potom dynamicky nakonfigurovať a prekonfigurovať Envoy s umiestnením iných služieb, pričom získam množstvo skvelých doplnkových funkcií, ako je napríklad viditeľnosť. Namiesto vlastnej klientskej knižnice alebo vloženia sledovania hovorov do kódu posielame návštevnosť do služby Envoy a tá pre nás zhromažďuje metriky.
Ale Envoy je tiež schopný pracovať ako dátová rovina (údajová rovina) pre sieť služieb. To znamená, že Envoy je teraz nakonfigurovaný pre túto sieť služieb riadiaca rovina (riadiaca rovina).
Riadiaca rovina
V riadiacej rovine sa Istio spolieha na Kubernetes API. Toto sa veľmi nelíši od používania confd, ktorá sa spolieha na etcd alebo Consul na zobrazenie sady kľúčov v dátovom úložisku. Istio používa Kubernetes API na zobrazenie množiny zdrojov Kubernetes.
Medzi tým a potom: Osobne som to považoval za užitočné ktorý znie:
Kubernetes API Server je „hlúpy server“, ktorý ponúka ukladanie, vytváranie verzií, overovanie, aktualizáciu a sémantiku pre zdroje API.
Istio je navrhnutý na prácu s Kubernetes; a ak ho chcete používať mimo Kubernetes, musíte spustiť inštanciu servera Kubernetes API (a pomocnú službu etcd).
Servisné adresy
Istio sa spolieha na adresy ClusterIP, ktoré prideľuje Kubernetes, takže služby Istio dostávajú internú adresu (nie v rozsahu 127.0.0.0/8).
Prevádzka na adresu ClusterIP pre konkrétnu službu v klastri Kubernetes bez Istio je zachytená kube-proxy a odoslaná na backend tohto proxy. Ak vás zaujímajú technické podrobnosti, kube-proxy nastaví pravidlá iptables (alebo vyrovnávače záťaže IPVS, v závislosti od toho, ako je nakonfigurovaný), aby prepísali cieľové IP adresy pripojení smerujúcich na adresu ClusterIP.
Po nainštalovaní Istio do klastra Kubernetes sa nič nezmení, kým nie je explicitne povolené pre daného spotrebiteľa alebo dokonca celý menný priestor zavedením kontajnera. sidecar do vlastných podov. Tento kontajner spustí inštanciu Envoy a nastaví sadu pravidiel iptables na zachytenie prevádzky smerujúcej do iných služieb a presmerovanie tejto prevádzky na Envoy.
Po integrácii s Kubernetes DNS to znamená, že náš kód sa môže pripojiť podľa názvu služby a všetko „funguje“. Inými slovami, náš kód vydáva otázky ako http://api/v1/users/4242potom api vyriešiť žiadosť o 10.97.105.48, pravidlá iptables zachytia pripojenia z 10.97.105.48 a postúpia ich lokálnemu proxy Envoy a tento lokálny proxy postúpi požiadavku skutočnému backendovému API. Fíha!
Dodatočné volániky
Istio tiež poskytuje end-to-end šifrovanie a autentifikáciu prostredníctvom mTLS (vzájomné TLS). Komponent s názvom Citadela.
Je tam aj komponent mixér, o ktoré môže vyslanec požiadať z každého požiadajte o špeciálne rozhodnutie o tejto požiadavke v závislosti od rôznych faktorov, ako sú hlavičky, zaťaženie backendu atď... (nebojte sa: existuje veľa spôsobov, ako udržať Mixer spustený, a aj keď zlyhá, Envoy bude pokračovať v práci v poriadku ako zástupca).
A samozrejme sme spomenuli viditeľnosť: Envoy zhromažďuje obrovské množstvo metrík a zároveň poskytuje distribuované sledovanie. Ak v architektúre mikroslužieb musí jedna požiadavka API prejsť cez mikroslužby A, B, C a D, potom po prihlásení distribuované sledovanie pridá k požiadavke jedinečný identifikátor a uloží tento identifikátor prostredníctvom čiastkových žiadostí pre všetky tieto mikroslužby, čo umožní všetky súvisiace hovory, ktoré sa majú zachytiť, meškania atď.
Vyvinúť alebo kúpiť
Istio má povesť komplexnosti. Naproti tomu vytvorenie smerovacej siete, ktorú som opísal na začiatku tohto príspevku, je pomerne jednoduché pomocou existujúcich nástrojov. Má teda zmysel vytvoriť si namiesto toho vlastnú sieť služieb?
Ak máme skromné potreby (nepotrebujeme viditeľnosť, istič a iné jemnosti), potom prichádzajú myšlienky na vývoj vlastného nástroja. Ak však použijeme Kubernetes, možno to ani nebude potrebné, pretože Kubernetes už poskytuje základné nástroje na zisťovanie služieb a vyrovnávanie záťaže.
Ale ak máme pokročilé požiadavky, potom sa „nákup“ servisnej siete javí ako oveľa lepšia možnosť. (Toto nie je vždy „kúpa“, pretože Istio je open source, ale stále musíme investovať čas inžinierstva, aby sme to pochopili, nasadili a spravovali.)
Mám si vybrať Istio, Linkerd alebo Consul Connect?
Doteraz sme hovorili len o Istio, ale toto nie je jediná sieť služieb. Populárna alternatíva - , a je toho viac .
Čo si vybrať?
Úprimne, neviem. Momentálne sa nepovažujem za dostatočne kompetentného odpovedať na túto otázku. Je tam niekoľko s porovnaním týchto nástrojov a dokonca .
Jedným sľubným prístupom je použitie nástroja ako je . Implementuje vrstvu abstrakcie na zjednodušenie a zjednotenie rozhraní API vystavených sieťami služieb. Namiesto toho, aby sme sa učili špecifické (a podľa môjho názoru pomerne zložité) API rôznych servisných sietí, môžeme použiť jednoduchšie konštrukty SuperGloo – a jednoducho prepínať z jedného na druhý, ako keby sme mali prechodný konfiguračný formát popisujúci HTTP rozhrania a backendy schopné generovania skutočnej konfigurácie pre Nginx, HAProxy, Traefik, Apache...
Trochu som fušoval s Istio a SuperGloo a v ďalšom článku chcem ukázať, ako pridať Istio alebo Linkerd do existujúceho klastra pomocou SuperGloo a ako ten druhý vykoná prácu, to znamená, že vám umožní prejsť z z jednej servisnej siete do druhej bez prepísania konfigurácií.
Zdroj: hab.com