Internetis palju artikleid ilotka teenuseahelat (service mesh), ja siin on veel üks. Hooray! Aga miks? Kuna soovin jagada oma arvamust, et oleks parem, kui teenuseahelad oleks ilmunud 10 aastat tagasi enne konteineriplatformide, nagu Docker ja Kubernetes, väljatulekut. Ma ei väida, et minu seisukoht on parem või halvem kui teised, kuid kuna teenuseahelad on üsna keerulised nähtused, siis mitmekesisus aitab neid paremini mõista.

Räägin dotCloudi platvormist, mis oli üles ehitatud rohkem kui sajale mikroteenusele ja toetas tuhandeid rakendusi konteinerites. Selgitan probleeme, millega me silmitsi seisisime selle arendamise ja juurutamise ajal, ja kuidas teenuseahelad oleksid võinud aidata (või mitte).

dotCloudi ajalugu

Olen juba kirjutanud dotCloudi ajaloost ja arhitektuuri valikust selle platvormi jaoks, kuid vähe olen rääkinud võrgu tasemest. Kui te ei soovi eelmisse artiklisse süveneda eelmise artikli dotCloudi kohta, siis lühidalt öeldes: see on platvorm teenusena PaaS, mis võimaldab klientidel käivitada laias valikus rakendusi (Java, PHP, Python ...) laiaulatusliku andmete teenuste toetusega (MongoDB, MySQL, Redis ...) ning töökäiguga nagu Heroku: te laadite oma koodi platvormile, see ehitab konteinerite pildid ja juurutab need.

Räägin, kuidas suunati liiklust dotCloudi platvormile. Mitte sellepärast, et see oleks olnud eriti suurepärane (kuigi oma aja kohta töötas süsteem hästi!), vaid eelkõige seetõttu, et tänapäevaste vahendite abil võib sellise disaini kiiresti ellu viia tagasihoidlik meeskond, kui neil on vaja liikluse suunamiseks lahendust hulga mikroteenuste või rakenduste vahel. Samuti saab võrrelda valikuid: mis juhtub, kui arendate kõik ise või kasutate olemasolevat teenuseahelat. Tavaline valik: teha ise või osta.

Liikluse suunamine hosted rakendustele

dotCloudi rakendused saavad pakkuda HTTP ja TCP lõpp-punkte.

HTTP lõpp-punktid lisatakse dünaamiliselt koormuse tasakaalustajate konfiguratsiooni Hipache. See on sarnane sellele, mida teevad tänapäeval ressursid Ingress Kuberneteses ja koormuse tasakaalustaja nagu Traefik.

Kliendid saavad ühenduda HTTP lõpp-punktidega vastavate domeenide kaudu, eeldusel et domeeninimi osutab dotCloudi koormuse tasakaalustajatele. Pole midagi erilist.

TCP lõpp-punktid on port number, which is then passed to all containers of this stack via environment variables.

Clients can connect to TCP endpoints using the appropriate hostname (something like gateway-X.dotcloud.com) and port number.

This hostname resolves to a cluster of servers "nats" (not related to NATS), which will route incoming TCP connections to the correct container (or, in the case of load balanced services, to the correct containers).

If you are familiar with Kubernetes, this might remind you of services NodePort.

On the dotCloud platform, there was no equivalent of services ClusterIP: for simplicity, access to services happened equally from inside and outside the platform.

Everything was organized quite simply: the initial implementations of HTTP and TCP routing networks were probably just a few hundred lines of Python. Simple (I would say naive) algorithms that were refined as the platform grew and additional requirements emerged.

Extensive refactoring of the existing code was not required. In particular, 12-factor applications can directly use an address obtained via environment variables.

How does this differ from modern service meshes?

Limited observability. We had no metrics at all for the TCP routing grid. As for HTTP routing, later versions introduced detailed HTTP metrics with error codes and response times, but modern service meshes go even further, providing integration with metric collection systems like Prometheus, for example.

Observability is important not only from an operational perspective (to aid in troubleshooting) but also when releasing new features. We're talking about safe blue-green deployment ja canary deployment.

Routing efficiency on samuti piiratud. DotCloudi marsruutimisvõrgus pidi kogu liiklus läbima pühendatud marsruutimise sõlmede klastrisse. See tähendas potentsiaalset mitme AZ (saavailability zone) piiri ületamist ja märkimisväärset latentsuse suurenemist. Mäletan, kuidas lahendasin probleeme koodiga, mis tegi lehe kohta rohkem kui sada SQL-päringut ning avas iga päringu jaoks uue ühenduse SQL-serveriga. Kohalikult käivitades laadib leht hetkega, kuid dotCloudis kestab laadimine mitu sekundit, kuna iga TCP-ühenduse (ja sellele järgneva SQL-päringu) jaoks kulub kümneid millisekundeid. Selles konkreetses olukorras lahendati probleem püsivate ühendustega.

Kaasaegsed teenuste meshid lahendavad selliseid probleeme paremini. Esiteks kontrollivad nad, et ühendused marsruutides allikast. Loogiline voog on sama: klient → mesh → teenus, kuid nüüd töötab mesh kohalikult, mitte eemal asuvates sõlmedes, seetõttu on ühendus klient → mesh kohalik ja väga kiire (mikrosekundid, mitte millisekundid).

Kaasaegsed teenuste meshid rakendavad ka nutikamaid koormuse tasakaalustamise algoritme. Kontrollides tagurpidi teenuste töökindlust, saavad nad saata rohkem liiklust kiirematele tagurpidi teenustele, mis viib üldise jõudluse paranemiseni.

Turvalisus on samuti parem. DotCloudi marsruutimisvõrk töötas täielikult EC2 Classicus ja ei krüpteerinud liiklust (pidades silmas, et kui keegi suutis paigaldada snifferi EC2 võrgu liiklusele, on teil juba tõsised probleemid). Kaasaegsed teenuste meshid kaitsevad meie liiklust läbipaistvalt, näiteks vastastikuse TLS-autentimise ja sellele järgnenud krüpteerimise abil.

Liikluse marsruutimine platvormi teenustele

Noh, oleme arutanud liiklust rakenduste vahel, kuid kuidas on lood dotCloudi platvormiga endaga?

Platvorm ise koosnes umbes sajast mikroteenusest, mis vastutasid erinevate funktsioonide eest. Ühed võtsid vastu päringud teistelt, teised olid taustatöötajad, kes ühendusid teiste teenustega, kuid ei võtnud ise ühendusi vastu. Igatahes peab iga teenus teadma lõpp-punkte, millega ühendust võtta.

Paljud kõrgema taseme teenused võivad kasutada ülaltoodud marsruutimisvõrku. Tegelikult on paljud dotCloudi üle saja mikroteenusest juurutatud tavaliste rakendustena dotCloudi platvormil. Kuid väike hulk madala taseme teenuseid (eriti need, mis rakendavad seda marsruutimisvõrku) vajas midagi lihtsamat, väiksemate sõltuvustega (sest nad ei saanud sõltuda iseenesest – vana hea kana ja muna probleem).

Need madala taseme, olulised teenused juurutati konteinerite käivitamisega otse mitmel peamisel sõlmel. Sellega ei kaasatud platvormi tavaparuseid: komposiit, ajakava ja jooksja. Kui soovite võrrelda kaasaegsete konteinerite platvormidega, sarnaneb see juhtimistasandi käivitamisega docker run otse sõlmedes, selle asemel et delegeerida ülesanne Kubernetesile. See on üsna sarnane kontseptsioonile staatilised moodulid (podid), mida kasutab kubeadm või bootkube autonoomse klastrite laadimisel.

Need teenused ekspekteeriti lihtsal ja toorel viisil: YAML-failis loeteldi nende nimed ja aadressid; iga klient pidi juurutamiseks võtma koopia sellest YAML-failist.

Ühelt poolt on see äärmiselt usaldusväärne, kuna see ei vaja välist võtmete/väärtuste salvestusruumi, nagu Zookeeper (ärge unustage, et sel ajal et cetd või Consul ei eksisteerinud). Teiselt poolt raskendas see teenuste liigutamist. Iga kord, kui teenust liigutati, pidid kõik kliendid saama värskendatud YAML-faili (ja potentsiaalselt taaskäivituma). Mitte just mugav!

Hiljem hakkasime rakendama uut skeemi, kus iga klient ühendas kohaliku vaheserveriga. Aadressi ja porti teadmiseks on tal piisavalt ainult teenuse pordi number ning ühenda läbi localhost. Kohalik vaheserver haldab seda ühendust ja suunab selle tegelikule serverile. Nüüd, kui taustateenust liigutatakse teisele masinale või skaleeritakse, tuleb suure hulga klientide värskendamise asemel värskendada ainult kõiki neid kohalikke vaheserve; ja taaskäivitamine ei ole enam vajalik.

(Samuti kavandati salvestada liiklus TLS-ühendustes ja paigaldada veel üks vaheserver vastuvõtupoolele, samuti kontrollida TLS-sertifikaate ilma vastuvõtuteenuse osalemiseta, mis on seadistatud ühenduste vastuvõtmiseks ainult) localhost. (Sellega latter).

See on väga sarnane SmartStack Airbnb'lt, kuid peamine erinevus on see, et SmartStack on ellu viidud ja tootmises, samas kui dotCloud'i sisemine marsruutimissüsteem pandi kinni, kui dotCloud muutus Dockeriks.

Ma arvan isiklikult, et SmartStack on üks eelkäijaid sellistele süsteemidele nagu Istio, Linkerd ja Consul Connect, sest kõik nad järgivad sama mustrit:

• Vaheserveri käivitamine igas sõlmes.
• Kliendid ühenduvad vaheserveriga.
• Halduse tase uuendab vaheserveri konfiguratsiooni, kui tagaplaneed muutuvad.
• … Kasum!

Kaasaegne teenuse-mesi rakendus

Kui me peame vajalikuks sellist võrku täna rakendada, saame kasutada sarnaseid põhimõtteid. Näiteks seadistada sisemine DNS-zona, seostades teenuste nimed aadressidega 127.0.0.0/8. Seejärel käivitada HAProxy igas klastrisõlmes, aktsepteerides ühendusi igas teenuse aadressis (selles alavõrgus 127.0.0.0/8) ja suunates/koormust tasakaalustades vastavatele tagaplaneedele. HAProxy konfiguratsiooni saab hallata confd, võimaldades tagaplaneedi teavet salvestada etcd-s või Consulis ning automaatselt edastada uuendatud konfiguratsiooni HAProxy-le, kui see on vajalik.

Nii töötab umbes Istio! Aga mõningate erinevustega:

• avalikustatakse Envoy Proxy HAProxy asemel.
• Hoida tagaplaneedi konfiguratsiooni läbi Kubernetes API, mitte etcd-s või Consulis.
• Teenustele määratakse aadressid sisemises alavõrgus (Kubernetes ClusterIP aadressid) 127.0.0.0/8 asemel.
• Omab täiendavat komponenti (Citadel), et lisada TLS-i vastastikust autentimist kliendi ja serverite vahel.
• Toetab uusi funktsioone, nagu ahela katkestamine, jaotatud jälgimine, kannujuhtide juurutamine jne.

Vaadakem lühidalt mõningaid erinevusi.

Envoy Proxy

Envoy Proxy kirjutas Lyft [konkurent Uberile taksoturul - tõlkija märkus]. See sarnaneb suuresti teiste vaheserveritega (nt HAProxy, Nginx, Traefik…), kuid Lyft kirjutas oma, sest neile olid vajalikud funktsioonid, mida teistes vaheserverites ei olnud, ja tundus mõistlikum luua uus, kui olemasolevat laiendada.

Envoy saab kasutada iseseisvalt. Kui mul on konkreetne teenus, mis peab ühenduma teiste teenustega, saan ma seadistada selle ühenduma Envoy'ga ning seejärel dünaamiliselt konfigureerida ja uuesti seadistada Envoy'd teiste teenuste asukoha määramisel, saades sealjuures palju suurepäraseid lisafunktsioone, näiteks jälgitavuse. Kohandatud kliendi teegiga või jälituskoodi integreerimise asemel suuname liikluse Envoy'le, mis kogub meie jaoks mõõdikud.

Kuid Envoy on ka võimeline töötama kui andmete tasand (data plane) teenuste võrgu jaoks. See tähendab, et nüüd konfigureeritakse Envoy selle teenuste võrgu jaoks kontrolli tasandina (control plane).

Kontrolli tasand

Kontrolli tasandis toetub Istio Kubernetes API-le. See ei erine väga confd kasutamisest,mis tugineb etcd-le või Consulile andmehoidlas võtmete kogumi vaatamiseks. Istio jälgib Kubernetes API kaudu Kubernetes'e ressursside kogumit.

Vahepeal: isiklikult tundus mulle kasulik see Kubernetes API kirjeldus, mis ütleb:

Kubernetes API server on "rumal server", mis pakub salvestamise, versiooni haldamise, valideerimise, uuendamise ja API ressursside semantika teenuseid.

Istio on loodud töötama koos Kubernetes'ega; ja kui soovite seda kasutada väljaspool Kubernetes't, peate käivitama Kubernetes API serveri eksemplari (ja abiteenusele etcd).

Teenuste aadressid

Istio toetub ClusterIP aadressidele, mida määrab Kubernetes, nii et Istio teenused saavad sisemise aadressi (mitte vahemikus 127.0.0.0/8).

Liiklus ClusterIP aadressile konkreetse teenuse jaoks Kubernetes klastris ilma Istio't, võetakse kinni kube-proxy poolt ja suunatakse selle proxy teenuse serveri osasse. Kui teid huvitavad tehnilised detailid, siis kube-proxy seadistab iptables reeglid (või IPVS koormuse jagajad, sõltuvalt sellest, kuidas see on seadistatud), et kirjutada sihtaadresside IP-aadresse ümber, mis saadetakse ClusterIP aadressile.

Pärast Istio seadistamist Kubernetes klastris ei muutu midagi, kuni see ei ole selgelt aktiveeritud selle tarbija või isegi kogu nimede ruumi jaoks, sisestades konteineri sidecar kohandatud podidesse. See konteiner käivitab Envoy eksemplari ja seadistab rea iptables reegleid, et võtta kinni liiklus, mis läheb teistesse teenustesse, ning suunata see liiklus Envoy'le.

Kubernetes DNS integreerimisel tähendab see, et meie kood saab ühenduda teenuse nime kaudu ja kõik "lihtsalt töötab". Teisisõnu, meie kood saadab päringuid, nagu http://api/v1/users/4242, siis api lahendab päringu aadressile 10.97.105.48, iptables reeglid püüavad kinni ühendused aadressilt 10.97.105.48 ja suunavad need kohaliku Envoy-proksisse, mis suunab päringu tegelikule API-tagaplaanile. Pfuh!

Täpsemad detailid

Istio pakub ka otsešifreerimist ja autentimist läbi mTLS (vastastikune TLS). Selle eest vastutab komponent, mille nimi on Citadel.

Lisaks on olemas komponent Mixer, mida Envoy saab küsida of each päringu osas, et teha erilisi otsuseid selle päringu kohta erinevate tegurite, nagu päised, tagaplaanide koormus jms, põhjal... (ärge muretsege: on palju viise, kuidas tagada Mixer'i töö; isegi kui see ebaõnnestub, toimib Envoy endiselt normaalselt proksina).

Ja loomulikult mainisime jälgitavust: Envoy kogub tohutul hulgal metrikoone, pakkudes samas jaotatud jälgitavust. Mikroteenuste arhitektuuris, kui üks API päring peab läbima mikroteenused A, B, C ja D, lisab jaotatud jälgitavus süsteemi sisenedes päringule ainulaadse identifikaatori ja hoiab seda identifikaatorit alampäringutes kõigis neist mikroteenustest, võimaldades salvestada kõik seotud kutsed, nende viivitused jne.

Arendada või osta

Istio maine on keerulise süsteemina. Vastupidi, selle marsruudivõrgu loomine, mida ma selle postituse alguses kirjeldasin, on olemasolevate tööriistade abil suures osas lihtne. Nii et kas on mõtet luua oma teenuse mesh selle asemel?

Kui meie vajadused on tagasihoidlikud (ei vaja jälgitavust, aasema katkestajat ja muid peensusi), siis tekivad mõtted oma tööriista arendamise üle. Kuid kui me kasutame Kubernetes't, võib see isegi mitte vajalik olla, kuna Kubernetes pakub juba baasvahendeid teenuste avastamiseks ja koormuse tasakaalustamiseks.

Aga kui meie nõuded on keerulisemad, tundub, et teenuse mesh „ostmine” on palju parem variant. (See ei tähenda alati just „ostmist”, kuna Istio on avatud lähtekoodiga, kuid meil on ikkagi vajalik investeerida inseneri aega, et mõista selle toimimist, juurutada ja hallata).

Kuidas valida: Istio, Linkerd või Consul Connect?

Kuigi oleme seni rääkinud ainult Istio-st, ei ole see ainus teenuse vahejuht. Populaarne alternatiiv on Linkerd, ning on veel Consul Connect.

Mida valida?

Ausalt öeldes ei tea ma. Praegu ei pea ma end selle küsimuse vastamiseks piisavalt pädevaks. On mitmeid huvitavaid artikleid võrdlusi nende tööriistade vahel ja isegi võrdlushinnanguid.

Üks paljulubavaid lähenemisviise on kasutada tööriista nagu SuperGloo. See rakendab abstraktsioonikihi, et lihtsustada ja ühtlustada API-sid, mida teenuse vahejuht pakub. Selle asemel, et õppida tundma erinevate (ja minu arvates suhteliselt keeruliste) teenuse vahejuhi API-sid, saame kasutada lihtsamaid konstruktsioone SuperGloo - ja vahetada sujuvalt ühelt teisele, justkui oleks meil vahelahendus, mis kirjeldab HTTP-liideseid ja taustateenuseid, suudab genereerida reaalse konfiguratsiooni Nginx, HAProxy, Traefik, Apache... jaoks.

Olen natuke katsetanud Istio ja SuperGloo, ning järgmises artiklis soovin näidata, kuidas lisada Istio või Linkerd olemasolevasse klastrisse SuperGloo abil, ja kui hästi viimane oma tööga hakkama saab, s.o võimaldades vahetada ühelt teenuse vahejuhtilt teisele ilma konfiguratsioonide ümberkirjutamiseta.

Allikas: habr.com