Internetis (teenindusvõrk) ja siin on veel üks. Hurraa! Aga miks? Seejärel tahan avaldada oma arvamust, et teenindusvõrgud oleksid olnud paremad 10 aastat tagasi, enne konteinerplatvormide, nagu Docker ja Kubernetes, tulekut. Ma ei väida, et minu vaatenurk on teistest parem või halvem, aga kuna teenindusvõrgud on üsna keerulised loomad, siis mitmed vaatenurgad aitavad neid paremini mõista.
Räägin dotCloudi platvormist, mis ehitati enam kui sajale mikroteenusele ja toetas tuhandeid rakendusi konteinerites. Selgitan väljakutseid, millega selle väljatöötamisel ja käivitamisel kokku puutusime ning kuidas teenindusvõrgud võivad (või mitte) aidata.
dotcloudi ajalugu
Olen juba kirjutanud dotCloudi ajaloost ja selle platvormi arhitektuuri valikust, kuid pole võrgukihist palju rääkinud. Kui lugeda ei taha dotCloudi kohta on selle sisu siin: see on PaaS-i platvorm teenusena, mis võimaldab klientidel käitada mitmesuguseid rakendusi (Java, PHP, Python jne), toetades laia valikut andmeteenuseid ( MongoDB, MySQL, Redis...) ja töövoog nagu Heroku: laadite oma koodi platvormile üles, see loob konteineri kujutised ja juurutab need.
Räägin teile, kuidas liiklus dotCloudi platvormile suunati. Mitte sellepärast, et see oleks eriti lahe (kuigi süsteem töötas oma aja kohta hästi!), vaid eelkõige seetõttu, et moodsate tööriistade abil saab tagasihoidlik meeskond sellise disaini hõlpsalt lühikese aja jooksul ellu viia, kui on vaja marsruutimist. liiklust hunniku mikroteenuste või hunniku rakenduste vahel. Seega saate võrrelda võimalusi: mis juhtub, kui arendate kõike ise või kasutate olemasolevat teenindusvõrku. Standardvalik: tehke ise või ostke.
Liikluse suunamine hostitud rakenduste jaoks
DotCloudi rakendused võivad paljastada HTTP ja TCP lõpp-punktid.
HTTP lõpp-punktid lisatakse dünaamiliselt koormuse tasakaalustaja klastri konfiguratsiooni . See on sarnane sellega, mida ressursid praegu teevad Kubernetes ja koormuse tasakaalustaja nagu .
Kliendid loovad ühenduse HTTP-otspunktidega sobivate domeenide kaudu, eeldusel, et domeeninimi osutab dotCloudi koormuse tasakaalustajatele. Ei midagi erilist.
TCP lõpp-punktid seostatakse pordi numbriga, mis seejärel edastatakse keskkonnamuutujate kaudu kõikidele selle virna konteineritele.
Kliendid saavad TCP lõpp-punktidega ühenduse luua, kasutades sobivat hostinime (näiteks gateway-X.dotcloud.com) ja pordi numbrit.
See hostinimi lahendab serveriklastri "nats" (pole seotud ), mis suunab sissetulevad TCP-ühendused õigesse konteinerisse (või tasakaalustatud koormusega teenuste puhul õigetesse konteineritesse).
Kui olete Kubernetesiga tuttav, tuletab see teile tõenäoliselt teenuseid meelde .
DotCloudi platvormil ei olnud samaväärseid teenuseid : lihtsuse huvides toimus juurdepääs teenustele samamoodi nii platvormi seest kui ka väljastpoolt.
Kõik oli korraldatud üsna lihtsalt: HTTP ja TCP marsruutimisvõrkude algsed teostused olid ilmselt vaid paarsada Pythoni rida. Lihtsad (ma ütleks, et naiivsed) algoritmid, mis on platvormi kasvu ja lisanõuete tekkimisega viimistletud.
Olemasoleva koodi ulatuslik ümbertegemine polnud vajalik. Eriti, saab otse kasutada keskkonnamuutujate kaudu saadud aadressi.
Kuidas see erineb kaasaegsest teenindusvõrgust?
Piiratud nähtavus. Meil polnud TCP-marsruutimisvõrgu jaoks üldse mõõdikuid. HTTP-marsruutimise osas on uuematel versioonidel üksikasjalikud HTTP-mõõdikud veakoodide ja reageerimisaegadega, kuid kaasaegsed teenindusvõrgud lähevad veelgi kaugemale, pakkudes integratsiooni mõõdikute kogumissüsteemidega, nagu näiteks Prometheus.
Nähtavus on oluline mitte ainult töö seisukohalt (et aidata probleeme tõrkeotsinguga), vaid ka uute funktsioonide väljalaskmisel. Turvalisusest rääkides и .
Marsruutimise efektiivsus on samuti piiratud. DotCloudi marsruutimisvõrgus pidi kogu liiklus läbima spetsiaalsete marsruutimissõlmede klastri. See tähendas potentsiaalselt mitme AZ (kättesaadavusala) piiride ületamist ja latentsusaja märkimisväärset suurenemist. Mäletan tõrkeotsingu koodi, mis tegi üle saja SQL-päringu lehekülje kohta ja avas iga päringu jaoks uue ühenduse SQL-serveriga. Lokaalselt käivitades laaditakse leht koheselt, kuid dotCloudis kulub selle laadimiseks mõni sekund, kuna iga TCP-ühendus (ja sellele järgnev SQL-päring) võtab aega kümneid millisekundeid. Sel konkreetsel juhul lahendasid püsivad ühendused probleemi.
Kaasaegsed teenindusvõrgud suudavad selliste probleemidega paremini toime tulla. Esiteks kontrollivad nad ühenduste marsruutimist allikas. Loogiline voog on sama: клиент → меш → сервис, kuid nüüd töötab võrk lokaalselt ja mitte kaugsõlmedes, seega ühendus клиент → меш on lokaalne ja väga kiire (millisekundite asemel mikrosekundid).
Kaasaegsed teenindusvõrgud rakendavad ka nutikamaid koormuse tasakaalustamise algoritme. Taustaprogrammide seisukorda jälgides saavad nad saata rohkem liiklust kiirematesse taustaprogrammidesse, mille tulemuseks on parem üldine jõudlus.
turvalisus on ka parem. DotCloudi marsruutimisvõrk töötas täielikult EC2 Classicu peal ega krüpteerinud liiklust (eeldusel, et kui kellelgi õnnestus EC2 võrguliiklusele nuusutaja panna, olete juba suures hädas). Kaasaegsed teenindusvõrgud kaitsevad läbipaistvalt kogu meie liiklust, näiteks vastastikuse TLS-i autentimise ja sellele järgneva krüptimisega.
Liikluse suunamine platvormiteenuste jaoks
Olgu, me oleme arutanud rakenduste vahelist liiklust, aga kuidas on lood dotCloudi platvormiga?
Platvorm ise koosnes umbes sajast mikroteenusest, mis vastutasid erinevate funktsioonide eest. Mõned võtsid vastu teiste taotlusi ja mõned olid taustatöötajad, kes ühendusid teiste teenustega, kuid ei võtnud ise ühendust. Mõlemal juhul peab iga teenus teadma nende aadresside lõpp-punkte, millega ta peab ühenduse looma.
Paljud kõrgetasemelised teenused võivad kasutada ülalkirjeldatud marsruutimisvõrku. Tegelikult on paljud enam kui XNUMX dotCloudi mikroteenusest juurutatud tavaliste rakendustena dotCloudi platvormil endal. Kuid vähesed madala tasemega teenused (eriti need, mis seda marsruutimisvõrku rakendavad) vajasid midagi lihtsamat, vähemate sõltuvustega (kuna nende töö ei saa sõltuda iseendast – vana hea kana ja muna probleem).
Need madala taseme olulised teenused juurutati konteinerite käitamisega otse mõnes võtmesõlmes. Samal ajal ei olnud kaasatud standardsed platvormiteenused: linker, planeerija ja jooksja. Kui soovite võrrelda kaasaegsete konteinerplatvormidega, on see nagu juhtlennuki käivitamine docker run otse sõlmedesse, selle asemel, et delegeerida ülesanne Kubernetesele. See on kontseptsioonilt üsna sarnane , mis kasutab või eraldiseisva klastri käivitamisel.
Need teenused avalikustati lihtsal ja toores viisil: YAML-failis oli loetletud nende nimed ja aadressid; ja iga klient pidi juurutamiseks võtma sellest YAML-failist koopia.
Ühest küljest on see ülimalt töökindel, sest ei vaja välise võtme/väärtuse poe tuge, nagu näiteks Zookeeper (mäletate, etcd või Consul polnud tol ajal olemas). Teisest küljest raskendas see teenuste teisaldamist. Iga kord, kui käik tehti, pidid kõik kliendid hankima värskendatud YAML-faili (ja potentsiaalselt uuesti laadima). Pole eriti mugav!
Seejärel hakkasime juurutama uut skeemi, kus iga klient ühendus kohaliku puhverserveriga. Aadressi ja pordi asemel peab see teadma ainult teenuse pordi numbrit ja ühenduma selle kaudu localhost. Kohalik puhverserver tegeleb selle ühendusega ja edastab selle tegelikule serverile. Nüüd tuleb taustaprogrammi teise masinasse teisaldamisel või skaleerimisel kõigi klientide värskendamise asemel värskendada ainult kõiki neid kohalikke puhverservereid; ja taaskäivitamist pole enam vaja.
(Samuti oli plaanis kapseldada liiklus TLS-ühendustesse ja paigaldada vastuvõtvale poolele teine puhverserver, samuti kontrollida TLS-sertifikaate ilma vastuvõtva teenuse osaluseta, mis on konfigureeritud ühendusi vastu võtma ainult localhost. Sellest lähemalt hiljem).
See on väga sarnane Airbnb-st, kuid oluline erinevus seisneb selles, et SmartStack on juurutatud ja kasutusele võetud tootmises, samas kui dotCloudi sisemine marsruutimissüsteem pandi kasti, kui dotCloud muutus Dockeriks.
Isiklikult pean SmartStacki üheks selliste süsteemide nagu Istio, Linkerd ja Consul Connect eelkäijaks, kuna need kõik järgivad sama mustrit:
- Käivitage iga sõlme puhverserver.
- Kliendid ühenduvad puhverserveriga.
- Juhttasand värskendab puhverserveri konfiguratsiooni, kui taustaprogrammid muutuvad.
- … Kasum!
Kaasaegne teenindusvõrgu rakendamine
Kui meil on täna vaja sarnast võrgustikku rakendada, saame kasutada sarnaseid põhimõtteid. Näiteks seadistage sisemine DNS-tsoon, vastendades teenusenimed ruumis olevate aadressidega 127.0.0.0/8. Seejärel käivitage HAProxy igas klastri sõlmes, aktsepteerides ühendusi igal teenuseaadressil (selles alamvõrgus 127.0.0.0/8) ja koormuse ümbersuunamine/tasakaalustamine vastavatesse taustaprogrammidesse. HAProxy konfiguratsiooni saab hallata , mis võimaldab teil salvestada taustateavet etcd-s või Consulis ja vajadusel automaatselt lükata värskendatud konfiguratsiooni HAProxy-sse.
Nii Istio töötab! Kuid mõningate erinevustega:
- Kasutab HAProxy asemel.
- Salvestab taustaprogrammi konfiguratsiooni etcd või Consuli asemel Kubernetes API kaudu.
- Teenustele eraldatakse aadressid sisemises alamvõrgus (Kubernetes ClusterIP-aadressid) 127.0.0.0/8 asemel.
- Sellel on täiendav komponent (Citadel), et lisada vastastikune TLS-i autentimine kliendi ja serverite vahel.
- Toetab uusi funktsioone, nagu voolukatkestus, hajutatud jälgimine, kanaari juurutamine jne.
Vaatame lühidalt mõningaid erinevusi.
Saadik volikiri
Envoy Proxy kirjutas Lyft [Uberi konkurent taksoturul – ca. per.]. See sarnaneb paljuski teiste puhverserveritega (nt HAProxy, Nginx, Traefik...), kuid Lyft kirjutas oma, kuna neil oli vaja funktsioone, mida teistel puhverserveritel ei ole ja tundus mõttekam teha uus, mitte laiendada. olemasolevat.
Saadikut saab ise kasutada. Kui mul on konkreetne teenus, mis vajab ühenduse loomist teiste teenustega, saan selle seadistada Envoyga ühenduse loomiseks ning seejärel dünaamiliselt konfigureerida ja ümber seadistada Envoy koos teiste teenuste asukohaga, pakkudes samal ajal palju suurepäraseid lisasid, nagu nähtavus. Kohandatud klienditeegi või kõne jälgimiskoodi sisestamise asemel saadame liikluse Envoyle ja see kogub meie eest mõõdikuid.
Envoy on aga võimeline töötama ka andmetasand (andmetasand) teenindusvõrgu jaoks. See tähendab, et nüüd on selle teenusevõrgu jaoks Envoy konfigureeritud juhtimistasand (juhttasand).
Juhttasand
Juhttasandil tugineb Istio Kubernetes API-le. See ei erine eriti confd kasutamisest, mis tugineb andmesalves võtmete komplekti otsimiseks tarkvarale etcd või Consul. Istio vaatab Kubernetese API kaudu läbi Kubernetese ressursside komplekti.
Selle ja siis vahel: Mulle isiklikult oli see kasulik mis ütleb:
Kubernetes API server on "loll server", mis pakub salvestusruumi, versioonide loomist, valideerimist, värskendamist ja API ressursside semantikat.
Istio on loodud Kubernetesiga töötamiseks; ja kui soovite seda kasutada väljaspool Kubernetest, peate käivitama Kubernetes API serveri eksemplari (ja etcd abiteenuse).
Teeninduse aadressid
Istio tugineb Kubernetesi eraldatud ClusterIP-aadressidele, nii et Istio teenused saavad siseaadressi (mitte vahemikus 127.0.0.0/8).
Kubernetese klastri konkreetse teenuse ClusterIP-aadressile suunatud liiklus ilma Istiota peatab kube-puhverserver ja saadetakse puhverserveri tagaossa. Kui olete huvitatud tehnilistest üksikasjadest, seadistab kube-proxy iptablesi reeglid (või IPVS-i koormuse tasakaalustajad, olenevalt konfiguratsioonist), et kirjutada ümber Clusteri IP-aadressile minevate ühenduste sihtkoha IP-aadressid.
Kui Istio on Kubernetese klastrisse installitud, ei muutu midagi enne, kui see on konkreetse tarbija või isegi kogu nimeruumi jaoks selgesõnaliselt lubatud konteineri kasutuselevõtuga sidecar kohandatud kaunadele. See konteiner käivitab Envoy eksemplari ja seadistab iptablesi reeglite komplekti, et peatada liiklus teistele teenustele ja suunata see liiklus Envoysse.
Kubernetes DNS-iga integreerituna tähendab see, et meie kood saab ühenduse luua teenuse nime järgi ja kõik lihtsalt töötab. Teisisõnu, meie kood väljastab selliseid päringuid nagu http://api/v1/users/4242siis api taotlus lahendada 10.97.105.48, iptablesi reeglid katkestavad ühendused alates 10.97.105.48 ja suunavad need ümber kohalikule Envoy puhverserverile, mis edastab päringu tegelikule API taustaprogrammi. Pheh!
Täiendavad volangid
Istio pakub ka täielikku krüptimist ja autentimist mTLS-i (vastastikuse TLS) kaudu. Komponent nimega Kants.
On ka komponent Mikser, mida saadik saab taotleda iga taotlus teha selle taotluse kohta eriotsus sõltuvalt erinevatest teguritest, nagu päised, taustalaadimine jne... (ärge muretsege: Mikseri töös hoidmiseks on palju tööriistu ja isegi kui see kokku jookseb, jätkab Envoy tööd puhverserverina).
Ja muidugi mainisime nähtavust: Envoy kogub tohutul hulgal mõõdikuid, pakkudes samal ajal hajutatud jälgimist. Kui mikroteenuste arhitektuuris peab üks API päring läbima mikroteenuste A, B, C ja D, lisab hajutatud jälgimine sisselogimisel päringule kordumatu identifikaatori ja salvestab selle identifikaatori alampäringute kaudu kõikidele nendele mikroteenustele, võimaldades saate jäädvustada kõik seotud kõned, nende viivitused jne.
Arenda või osta
Istio on tuntud kui keeruline süsteem. Seevastu selle postituse alguses kirjeldatud marsruutimisvõrgu ehitamine on olemasolevate tööriistadega suhteliselt lihtne. Niisiis, kas on mõttekas luua selle asemel oma teenindusvõrk?
Kui meil on tagasihoidlikud vajadused (ei vaja nähtavust, kaitselülitit ja muid peensusi), siis tulevad mõtted oma tööriista arendamisele. Kuid kui me kasutame Kubernetest, ei pruugi see isegi vajalik olla, sest Kubernetes pakub juba põhitööriistu teenuse tuvastamiseks ja koormuse tasakaalustamiseks.
Kuid kui meil on täpsemad nõuded, tundub teenindusvõrgu "ostmine" palju parem valik. (See ei ole alati "ost", kuna Istio on avatud lähtekoodiga, kuid selle mõistmiseks, juurutamiseks ja haldamiseks peame siiski investeerima projekteerimisaega.)
Mida valida: Istio, Linkerd või Consul Connect?
Siiani oleme rääkinud ainult Istiost, kuid see pole ainus teenindusvõrk. Populaarne alternatiiv on , kuid on rohkemgi .
Mida valida?
Ausalt öeldes ma ei tea. Hetkel ei pea ma end piisavalt pädevaks, et sellele küsimusele vastata. Neid on vähe nende tööriistade võrdlusega ja isegi .
Üks paljutõotav lähenemisviis on kasutada sellist tööriista nagu . See rakendab teenusevõrkude pakutavate API-de lihtsustamiseks ja ühtlustamiseks abstraktsioonikihti. Selle asemel, et õppida erinevate teenindusvõrkude spetsiifilisi (ja minu arvates suhteliselt keerukaid) API-sid, saame kasutada lihtsamaid SuperGloo konstruktsioone – ja lülituda hõlpsalt ühelt teisele, justkui oleks meil vahepealne konfiguratsioonivorming, mis kirjeldaks HTTP liideseid ja taustaprogramme. võimeline genereerima tegeliku konfiguratsiooni Nginxi, HAProxy, Traefiki, Apache'i jaoks…
Mängisin veidi Istio ja SuperGlooga ning järgmises artiklis tahan näidata, kuidas SuperGloo abil olemasolevasse klastrisse Istiot või Linkerdi lisada ja kuidas viimane oma tööd teeb ehk võimaldab lülituda ühest teenindusvõrgust teise ilma konfiguratsioone ümber kirjutamata.
Allikas: www.habr.com