Um Internet (Service Mesh), an hei ass en aneren. Hour! Mee firwat? Dann wëll ech meng Meenung ausdrécken datt et besser gewiescht wier wann Service Meshes virun 10 Joer erschéngen, ier d'Entstoe vu Containerplattforme wéi Docker a Kubernetes. Ech soen net datt mäi Standpunkt besser oder méi schlëmm ass wéi anerer, awer well Service Meshes zimlech komplex Déieren sinn, wäerte verschidde Standpunkter hëllefen se besser ze verstoen.
Ech wäert iwwer d'dotCloud Plattform schwätzen, déi op iwwer honnert Mikroservicer gebaut gouf an Dausende vu containeriséierte Applikatiounen ënnerstëtzt huet. Ech erklären d'Erausfuerderunge fir eis z'entwéckelen an ze lancéieren, a wéi Service Meshes kéinten (oder net) hëllefen.
Geschicht vun dotCloud
Ech hunn iwwer d'Geschicht vun dotCloud an d'Architekturwahlen fir dës Plattform geschriwwen, awer ech hunn net vill iwwer d'Netzschicht geschwat. Wann Dir net wëllt an d'Liesen tauchen iwwer dotCloud, hei ass de Wénkel an enger Nossschuel: et ass eng PaaS Plattform-as-a-Service, déi Clienten erlaabt eng breet Palette vun Uwendungen ze lafen (Java, PHP, Python ...), mat Ënnerstëtzung fir eng breet Palette vun Daten Servicer (MongoDB, MySQL, Redis ...) an e Workflow wéi Heroku: Dir lued Äre Code op d'Plattform erop, et baut Container Biller an deployéiert se.
Ech wäert Iech soen wéi de Verkéier op d'dotCloud Plattform geleet gouf. Net well et besonnesch cool war (obwuel de System fir seng Zäit gutt geschafft huet!), mee virun allem well mat modernen Tools esou en Design einfach a kuerzer Zäit vun enger bescheidener Equipe ëmgesat ka ginn, wa se e Wee brauchen fir den Traffic tëscht enger Rëtsch ze routen vu Mikroservicer oder eng Rëtsch Uwendungen. Op dës Manéier kënnt Dir d'Optiounen vergläichen: wat geschitt wann Dir alles selwer entwéckelt oder en existente Servicemesh benotzt. De Standardwahl ass et selwer ze maachen oder et ze kafen.
Traffic Routing fir gehost Uwendungen
Uwendungen op dotCloud kënnen HTTP- an TCP-Endpunkte exponéieren.
HTTP Endpunkte dynamesch op d'Laaschtbalancer Cluster Konfiguratioun bäigefüügt . Dëst ass ähnlech wéi d'Ressourcen haut maachen an Kubernetes an engem Laaschtbalancer wéi .
D'Clientë verbannen mat HTTP-Endpunkte duerch entspriechend Domainen, virausgesat datt den Domain Numm op dotCloud Lastbalancer weist. Näischt Extras.
TCP Endpunkter mat enger Portnummer assoziéiert, déi dann un all Container an deem Stack iwwer Ëmfeldvariablen weidergeleet gëtt.
Cliente kënne mat TCP Endpunkte verbannen mat dem passenden Hostnumm (eppes wéi Gateway-X.dotcloud.com) a Portnummer.
Dëse Hostnumm léist op den "nats" Servercluster (net verbonne mat ), déi erakommen TCP Verbindungen op de richtege Container routert (oder, am Fall vun load-equilibréierte Servicer, op déi richteg Container).
Wann Dir mat Kubernetes vertraut sidd, wäert dëst Iech wahrscheinlech un d'Servicer erënneren .
Et goufe keng gläichwäerteg Servicer op der dotCloud Plattform : Fir Simplicitéit, Servicer goufen déi selwecht Manéier souwuel vu bannen an ausserhalb der Plattform zougänglech.
Alles war ganz einfach organiséiert: déi initial Implementatioune vun HTTP an TCP Routing Netzwierker ware wahrscheinlech nëmmen e puer honnert Zeilen Python all. Einfach (ech géif soen naiv) Algorithmen déi raffinéiert goufen wéi d'Plattform gewuess ass an zousätzlech Ufuerderunge erschéngen.
Extensiv Refactoring vum existente Code war net erfuerderlech. Besonnesch, kann direkt d'Adress benotzen, déi duerch Ëmweltvariablen kritt gëtt.
Wéi ass dëst anescht wéi e modernen Service Mesh?
Limitéiert Visibilitéit. Mir hu guer keng Metriken fir den TCP Routing Mesh. Wann et ëm HTTP Routing kënnt, hunn spéider Versioune detailléiert HTTP Metriken mat Fehlercoden an Äntwertzäiten agefouert, awer modern Service Meshes ginn nach méi wäit, fir Integratioun mat Metriken Sammlungssystemer wéi Prometheus, zum Beispill.
Visibilitéit ass wichteg net nëmmen aus enger operationeller Perspektiv (fir Probleemer ze léisen), awer och wann Dir nei Features verëffentlecht. Et geet ëm sécher и .
Routing Effizienz ass och limitéiert. Am dotCloud Routing Mesh, all Traffic huet missen duerch e Cluster vun dedizéierten Routing Noden goen. Dëst bedeit potenziell méi AZ (Availability Zone) Grenzen ze iwwerschreiden an d'Latenz wesentlech ze erhéijen. Ech erënnere mech un de Problembehandlungscode deen iwwer honnert SQL Ufroen pro Säit gemaach huet an eng nei Verbindung mam SQL Server fir all Ufro opmaacht. Wann Dir lokal leeft, lued d'Säit direkt, awer an dotCloud dauert et e puer Sekonnen fir ze lueden, well all TCP Verbindung (a spéider SQL Ufro) Zénger vu Millisekonnen dauert. An dësem besonnesche Fall hunn persistent Verbindungen de Problem geléist.
Modern Service Meshes si besser mat esou Problemer ze këmmeren. Éischt vun all, si kontrolléieren, datt Verbindungen rout sinn a Quell. De logesche Floss ass déiselwecht: клиент → меш → сервис, awer elo funktionnéiert de Mesh lokal an net op Fernknoten, also d'Verbindung клиент → меш ass lokal a ganz séier (Mikrosekonnen amplaz Millisekonnen).
Modern Service Meshes implementéieren och méi intelligent Belaaschtungsalgorithmen. Duerch d'Iwwerwaachung vun der Gesondheet vun de Backends kënne se méi Traffic op méi séier Backends schécken, wat zu enger verbesserter Gesamtleeschtung resultéiert.
Sécherheet och besser. Den DotCloud Routing Mesh leeft ganz op EC2 Classic an huet de Traffic net verschlësselt (baséiert op der Virgab datt wann een et fäerdeg bruecht huet e Sniffer op EC2 Netzverkéier ze setzen, Dir sidd scho a grousse Probleemer). Modern Service Meshes schützen transparent all eise Traffic, zum Beispill, mat géigesäitege TLS Authentifikatioun a spéider Verschlësselung.
Routing Traffic fir Plattform Servicer
Okay, mir hunn den Traffic tëscht Uwendungen diskutéiert, awer wat iwwer d'dotCloud Plattform selwer?
D'Plattform selwer bestoung aus ongeféier honnert Mikroservicer verantwortlech fir verschidde Funktiounen. E puer hunn Ufroe vun aneren akzeptéiert, an e puer waren Hannergrondaarbechter, déi mat anere Servicer verbonne sinn, awer selwer keng Verbindungen akzeptéiert hunn. Op jidde Fall muss all Service d'Ennpunkte vun den Adressen kennen, mat deenen et muss konnektéieren.
Vill High-Level Servicer kënnen d'Routing Mesh benotzen, déi uewen beschriwwen ass. Tatsächlech sinn vill vun dotCloud méi wéi honnert Mikroservicer als regulär Uwendungen op der dotCloud Plattform selwer ofgesat ginn. Awer eng kleng Zuel vu Low-Level Servicer (besonnesch déi, déi dëse Routing Mesh implementéieren) brauche eppes méi einfach, mat manner Ofhängegkeeten (well se net op sech selwer hänke konnten fir ze schaffen - de gudden alen Poulet an Ee Problem).
Dës niddereg-Niveau, missionskritesch Servicer goufen ofgesat andeems se Container direkt op e puer Schlësselknäppchen lafen. An dësem Fall goufen Standard Plattform Servicer net benotzt: Linker, Scheduler a Leefer. Wann Dir wëllt mat modern Container Plattformen ze vergläichen, et ass wéi eng Kontroll Fliger Lafen mat docker run direkt op den Wirbelen, amplaz d'Aufgab op Kubernetes ze delegéieren. Et ass zimlech ähnlech am Konzept , déi et benotzt oder wann Dir e Standalone Cluster boott.
Dës Servicer goufen op eng einfach a rau Manéier ausgesat: eng YAML Datei huet hir Nimm an Adressen opgelëscht; an all Client huet eng Kopie vun dëser YAML-Datei fir Ofbau ze huelen.
Engersäits ass et extrem zouverlässeg well et net d'Ënnerstëtzung vun engem externen Schlëssel / Wäertgeschäft wéi Zookeeper erfuerdert (erënnert, etcd oder Consul war zu där Zäit net existéiert). Op der anerer Säit huet et et schwéier gemaach Servicer ze plënneren. All Kéier wann eng Beweegung gemaach gouf, kréien all Clienten eng aktualiséiert YAML-Datei (a potenziell nei starten). Net ganz bequem!
Duerno hu mir ugefaang en neie Schema ëmzesetzen, wou all Client mat engem lokale Proxy Server verbonnen ass. Amplaz vun enger Adress an Hafen, brauch et nëmmen d'Portnummer vum Service ze kennen, a verbënnt iwwer localhost. De lokale Proxy handhabt dës Verbindung a schéckt se op den aktuellen Server weider. Elo, wann Dir de Backend op eng aner Maschinn oder Skala bewegt, anstatt all Clienten ze aktualiséieren, musst Dir nëmmen all dës lokal Proxyen aktualiséieren; an e Restart ass net méi erfuerderlech.
(Et war och geplangt fir de Traffic an TLS Verbindungen ze kapsuléieren an en anere Proxy-Server op der Empfangssäit ze setzen, souwéi TLS Zertifikater z'iwwerpréiwen ouni d'Participatioun vum Empfangsservice, deen konfiguréiert ass fir Verbindungen nëmmen op localhost. Méi iwwer dëst méi spéit).
Dëst ass ganz ähnlech wéi vun Airbnb, awer de wesentlechen Ënnerscheed ass datt SmartStack implementéiert an op d'Produktioun ofgesat gëtt, während dem dotCloud säin internen Routingsystem ofgeschaaft gouf wéi dotCloud Docker gouf.
Ech perséinlech betruechten SmartStack als ee vun de Virgänger fir Systemer wéi Istio, Linkerd a Consul Connect well se all datselwecht Muster verfollegen:
- Laf e Proxy op all Node.
- D'Clientë verbannen mam Proxy.
- De Kontrollplan aktualiséiert d'Proxykonfiguratioun wann d'Backends änneren.
- ... Gewënn!
Modern Ëmsetzung vun engem Service Mesh
Wa mir haut en ähnlecht Gitter misste implementéieren, kënne mir ähnlech Prinzipien benotzen. Zum Beispill, eng intern DNS Zone konfiguréieren andeems Dir Servicenimm op Adressen am Raum kartéiert 127.0.0.0/8. Fuert dann HAProxy op all Node am Cluster, akzeptéiert Verbindungen op all Serviceadress (an deem Subnet 127.0.0.0/8) a Viruleedung / Balance vun der Laascht op déi entspriechend Backends. HAProxy Konfiguratioun kann kontrolléiert ginn , erlaabt Iech Backend Informatioun an etcd oder Consul ze späicheren an automatesch aktualiséiert Konfiguratioun op HAProxy ze drécken wann néideg.
Dëst ass zimlech wéi Istio funktionnéiert! Awer mat e puer Differenzen:
- Benotzt amplaz HAProxy.
- Späichert Backend Konfiguratioun iwwer Kubernetes API amplaz etcd oder Consul.
- D'Servicer ginn Adressen am internen Subnet zougewisen (Kubernetes ClusterIP Adressen) amplaz 127.0.0.0/8.
- Huet eng zousätzlech Komponent (Citadel) fir géigesäiteg TLS Authentifikatioun tëscht dem Client a Server ze addéieren.
- Ënnerstëtzt nei Funktiounen wéi Circuit Break, verdeelt Tracing, Kanaresch Deployment, etc.
Loosst eis séier e puer vun den Ënnerscheeder kucken.
Envoy Proxy
Envoy Proxy gouf vum Lyft [Uber säi Konkurrent am Taximaart geschriwwen - ca. laan]. Et ass op vill Manéiere ähnlech wéi aner Proxyen (zB HAProxy, Nginx, Traefik ...), awer Lyft huet hir geschriwwen well se Features gebraucht hunn déi aner Proxyen feelen, an et schéngt méi schlau en neien ze maachen anstatt déi existent ze verlängeren.
Envoy kann eleng benotzt ginn. Wann ech e spezifesche Service hunn, dee muss mat anere Servicer konnektéieren, kann ech et konfiguréieren fir mat Envoy ze verbannen, an dann dynamesch konfiguréieren an den Envoy mat der Lag vun anere Servicer rekonfiguréieren, wärend vill super zousätzlech Funktionalitéit kritt, wéi Visibilitéit. Amplaz vun enger personaliséierter Clientsbibliothéik oder Uruffspuren an de Code ze sprëtzen, schécken mir Traffic op Envoy, an et sammelt Metriken fir eis.
Awer Envoy ass och fäeg ze schaffen als daten Fliger (Dateplang) fir de Service Mesh. Dëst bedeit datt Envoy elo fir dëse Service Mesh konfiguréiert ass Kontroll Fliger (Kontrollplan).
Kontroll Fliger
Fir de Kontrollebene hänkt Istio op der Kubernetes API. Dëst ass net ganz anescht wéi d'Benotzung vu confd, déi op etcd oder Consul hänkt fir de Set vu Schlësselen am Dategeschäft ze gesinn. Istio benotzt de Kubernetes API fir eng Rei vu Kubernetes Ressourcen ze gesinn.
Tëscht dësem an dann: Ech perséinlech fonnt dat nëtzlech déi liest:
De Kubernetes API Server ass en "domm Server" dee Späicheren, Versiounen, Validatioun, Aktualiséierung a Semantik fir API Ressourcen ubitt.
Istio ass entwéckelt fir mat Kubernetes ze schaffen; a wann Dir et ausserhalb vu Kubernetes benotze wëllt, da musst Dir eng Instanz vum Kubernetes API Server lafen (an den etcd Helper Service).
Service Adressen
Istio baséiert op ClusterIP Adressen déi Kubernetes allocéiert, sou datt Istio Servicer eng intern Adress kréien (net am Beräich 127.0.0.0/8).
Traffic op d'ClusterIP Adress fir e spezifesche Service an engem Kubernetes Cluster ouni Istio gëtt vu Kube-Proxy ofgefaangen an op de Backend vun deem Proxy geschéckt. Wann Dir un d'technesch Detailer interesséiert sidd, setzt kube-Proxy iptables Regelen op (oder IPVS Lastbalancer, jee no wéi et konfiguréiert ass) fir d'Zil-IP Adresse vun de Verbindungen op d'ClusterIP Adress ëmzeschreiwen.
Wann Istio op engem Kubernetes Cluster installéiert ass, ännert näischt bis et explizit fir e bestëmmte Konsument aktivéiert ass, oder souguer de ganze Nummraum, andeems en Container agefouert gëtt. sidecar an personaliséiert Pods. Dëse Container wäert eng Instanz vum Envoy opmaachen an eng Rei vun iptables Reegelen opsetzen fir den Traffic op aner Servicer z'ënnerscheeden an dee Verkéier op Envoy ze redirectéieren.
Wann integréiert mat Kubernetes DNS, heescht dat datt eise Code mam Servicenumm konnektéiere kann an alles "just funktionnéiert." An anere Wierder, eise Code stellt Ufroe wéi http://api/v1/users/4242dann api léisen Ufro fir 10.97.105.48, d'iptables Regelen interceptéieren Verbindunge vum 10.97.105.48 a weiderginn se un de lokalen Envoy Proxy, an dee lokale Proxy wäert d'Ufro un déi aktuell Backend API weiderginn. Pff!
Zousätzlech Frills
Istio bitt och end-to-end Verschlësselung an Authentifikatioun iwwer mTLS (géigesäiteg TLS). Eng Komponent genannt Zitadell.
Et gëtt och e Bestanddeel Mixer, déi den Envoy kann ufroen vun all eenzel Ufro fir eng speziell Entscheedung iwwer dës Ufro ze huelen ofhängeg vu verschiddene Faktoren wéi Header, Backend Belaaschtung, etc ... (maacht keng Suergen: et gi vill Weeër fir de Mixer lafend ze halen, an och wann et crasht, wäert den Envoy weider schaffen fein als Proxy).
An natierlech hu mir Visibilitéit ernimmt: Envoy sammelt eng rieseg Quantitéit vu Metriken wärend verdeelt Tracing ubitt. An enger Mikrodéngschtarchitektur, wann eng eenzeg API Ufro muss duerch Mikroservicer A, B, C, an D passéieren, dann beim Login, verdeelt Tracing gëtt en eenzegaartegen Identifizéierer un d'Ufro derbäi a späichert dësen Identifizéierer duerch Ënnerufroen un all dës Mikroservicer, wat erlaabt all Zesummenhang Uruff opgeholl ze ginn. Verspéidungen, etc.
Entwéckelen oder kafen
Istio huet e Ruff fir komplex ze sinn. Am Géigesaz, de Routing Mesh ze bauen, deen ech am Ufank vun dësem Post beschriwwen hunn ass relativ einfach mat existéierende Tools. Also, mécht et Sënn fir Ären eegene Service Mesh amplaz ze kreéieren?
Wa mir bescheide Bedierfnesser hunn (mir brauche keng Visibilitéit, e Circuit Breaker an aner Subtletien), da komme Gedanken fir eis eegent Tool z'entwéckelen. Awer wa mir Kubernetes benotzen, ass et vläicht net emol gebraucht well Kubernetes scho Basis Tools fir Service Entdeckung a Laaschtbalancéierung ubitt.
Awer wa mir fortgeschratt Ufuerderunge hunn, da "kaafen" e Service Mesh schéngt eng vill besser Optioun ze sinn. (Dëst ass net ëmmer e "Kaafen" well Istio Open Source ass, awer mir mussen nach ëmmer Ingenieurszäit investéieren fir se ze verstoen, z'installéieren an ze managen.)
Soll ech Istio, Linkerd oder Consul Connect wielen?
Bis elo hu mir nëmmen iwwer Istio geschwat, awer dëst ass net deen eenzegen Service Mesh. Populär Alternativ - , an et gëtt méi .
Wat ze wielen?
Éierlech gesot, ech weess et net. Am Moment fannen ech mech net kompetent genuch fir dës Fro ze beäntweren. Et ginn e puer mat engem Verglach vun dësen Tools a souguer .
Eng villverspriechend Approche ass en Tool ze benotzen wéi . Et implementéiert eng Abstraktiounsschicht fir d'APIs ze vereinfachen an ze vereenegen, déi duerch Service Meshes ausgesat sinn. Amplaz déi spezifesch (an menger Meenung no, relativ komplex) APIe vu verschiddene Service-Meshen ze léieren, kënne mir SuperGloo's méi einfach Konstruktioune benotzen - a liicht vun engem op dat anert wiesselen, wéi wa mir en Zwëschenkonfiguratiounsformat hätten, deen HTTP-Interfaces a Backends beschreift. déi aktuell Konfiguratioun fir Nginx, HAProxy, Traefik, Apache ...
Ech hunn e bëssen mat Istio a SuperGloo gedoppelt, an am nächsten Artikel wëll ech weisen wéi een Istio oder Linkerd zu engem existente Cluster mat SuperGloo addéiere kann, a wéi dee Leschten d'Aarbecht gemaach kritt, dat heescht, erlaabt Iech ze wiesselen vun engem Service Mesh zu engem aneren ouni Configuratioun iwwerschreiwe.
Source: will.com