ProHoster > Blogs > Administrācija > Konteineri, mikropakalpojumi un servisa tīkli

Konteineri, mikropakalpojumi un servisa tīkli

Internetā Ä·ekars raksti Š¾ servisa tÄ«kls (servisa tÄ«kls), un Å”eit ir vēl viens. Urrā! Bet kāpēc? Tad vēlos izteikt savu viedokli, ka bÅ«tu bijis labāk, ja servisa tÄ«kli bÅ«tu parādÄ«juÅ”ies pirms 10 gadiem, pirms tādu konteineru platformu kā Docker un Kubernetes parādÄ«Å”anās. Es nesaku, ka mans viedoklis ir labāks vai sliktāks par citiem, taču, tā kā servisa tÄ«kli ir diezgan sarežģīti dzÄ«vnieki, vairāki viedokļi palÄ«dzēs tos labāk izprast.

Es runāŔu par platformu dotCloud, kas tika veidota uz vairāk nekā simts mikropakalpojumiem un atbalstÄ«ja tÅ«kstoÅ”iem konteinerizētu lietojumprogrammu. Es izskaidroÅ”u problēmas, ar kurām saskārāmies, izstrādājot un ievieÅ”ot to, un kā pakalpojumu tÄ«kli varētu (vai nevarēja) palÄ«dzēt.

DotCloud vēsture

Esmu rakstÄ«jis par dotCloud vēsturi un Ŕīs platformas arhitektÅ«ras izvēlēm, taču neesmu daudz runājis par tÄ«kla slāni. Ja nevēlaties ienirt lasÄ«Å”anā pēdējais raksts par dotCloud, Å”eit ir Ä«sumā bÅ«tÄ«ba: tā ir PaaS platforma kā pakalpojums, kas ļauj klientiem palaist plaÅ”u lietojumprogrammu klāstu (Java, PHP, Python...) ar atbalstu plaÅ”am datu diapazonam. pakalpojumi (MongoDB, MySQL, Redis...) un darbplÅ«sma, piemēram, Heroku: jÅ«s augÅ”upielādējat savu kodu platformā, tā izveido konteinera attēlus un izvieto tos.

Es jums pastāstÄ«Å”u, kā satiksme tika novirzÄ«ta uz platformu dotCloud. Ne tāpēc, ka tas bÅ«tu Ä«paÅ”i forÅ”s (lai gan sistēma savam laikam darbojās labi!), bet galvenokārt tāpēc, ka ar moderniem rÄ«kiem Ŕādu dizainu var viegli ieviest Ä«sā laikā pieticÄ«gai komandai, ja viņiem ir nepiecieÅ”ams veids, kā novirzÄ«t satiksmi starp bariem. no mikropakalpojumiem vai virkni lietojumprogrammu. Tādā veidā jÅ«s varat salÄ«dzināt iespējas: kas notiek, ja visu izstrādājat pats vai izmantojat esoÅ”u pakalpojumu tÄ«klu. Standarta izvēle ir izgatavot to paÅ”am vai iegādāties.

Satiksmes marÅ”rutÄ“Å”ana mitinātajām lietojumprogrammām

Lietojumprogrammas vietnē dotCloud var atklāt HTTP un TCP galapunktus.

HTTP galapunkti dinamiski pievienots slodzes balansētāja klastera konfigurācijai Hipache. Tas ir lÄ«dzÄ«gi tam, ko resursi dara Å”odien IekļūŔana in Kubernetes un slodzes balansētājs, piemēram Traefik.

Klienti savienojas ar HTTP galapunktiem, izmantojot atbilstoÅ”us domēnus, ja domēna nosaukums norāda uz dotCloud slodzes balansētājiem. Nekas Ä«paÅ”s.

TCP galapunkti saistÄ«ts ar porta numuru, kas pēc tam tiek nodots visiem konteineriem Å”ajā kaudzē, izmantojot vides mainÄ«gos.

Klienti var izveidot savienojumu ar TCP galapunktiem, izmantojot atbilstoÅ”o resursdatora nosaukumu (piemēram, gateway-X.dotcloud.com) un porta numuru.

Å is resursdatora nosaukums tiek izmantots servera klasterim ā€œnatsā€ (nav saistÄ«ts ar Nats), kas novirzÄ«s ienākoÅ”os TCP savienojumus uz pareizo konteineru (vai slodzes lÄ«dzsvarotu pakalpojumu gadÄ«jumā uz pareizajiem konteineriem).

Ja esat pazīstams ar Kubernetes, iespējams, tas jums atgādinās par pakalpojumiem Mezglu ports.

DotCloud platformā nebija lÄ«dzvērtÄ«gu pakalpojumu ClusterIP: VienkārŔības labad pakalpojumiem tika piekļūts vienādi gan no platformas iekÅ”puses, gan ārpus tās.

Viss tika organizēts pavisam vienkārÅ”i: sākotnēji HTTP un TCP marÅ”rutÄ“Å”anas tÄ«klu ievieÅ”ana, iespējams, bija tikai daži simti Python rindiņu. VienkārÅ”i (es teiktu naivi) algoritmi, kas tika pilnveidoti, platformai augot un parādÄ«jās papildu prasÄ«bas.

PlaÅ”a esoŔā koda pārstrukturÄ“Å”ana nebija nepiecieÅ”ama. It Ä«paÅ”i, 12 faktoru lietotnes var tieÅ”i izmantot adresi, kas iegÅ«ta, izmantojot vides mainÄ«gos.

Kā tas atŔķiras no mūsdienu pakalpojumu tīkla?

Ierobežots redzamÄ«ba. Mums vispār nebija TCP marÅ”rutÄ“Å”anas tÄ«kla metrikas. Runājot par HTTP marÅ”rutÄ“Å”anu, jaunākās versijās tika ieviesta detalizēta HTTP metrika ar kļūdu kodiem un atbildes laikiem, taču mÅ«sdienu pakalpojumu tÄ«kli sniedzas vēl tālāk, nodroÅ”inot integrāciju ar metrikas vākÅ”anas sistēmām, piemēram, Prometheus.

RedzamÄ«ba ir svarÄ«ga ne tikai no darbÄ«bas viedokļa (lai palÄ«dzētu novērst problēmas), bet arÄ« izlaižot jaunas funkcijas. Runa ir par droŔību zili zaļa izvietoÅ”ana Šø kanāriju izvietoÅ”ana.

MarÅ”rutÄ“Å”anas efektivitāte ir arÄ« ierobežots. DotCloud marÅ”rutÄ“Å”anas tÄ«klā visai satiksmei bija jānotiek caur Ä«paÅ”u marÅ”rutÄ“Å”anas mezglu kopu. Tas nozÄ«mēja iespēju Ŕķērsot vairākas AZ (pieejamÄ«bas zonas) robežas un ievērojami palielināt latentumu. Es atceros problēmu novērÅ”anas kodu, kas veica vairāk nekā simts SQL vaicājumu katrā lapā un katram vaicājumam atvēra jaunu savienojumu ar SQL serveri. Palaižot lokāli, lapa tiek ielādēta uzreiz, bet programmā dotCloud tās ielāde aizņem dažas sekundes, jo katrs TCP savienojums (un turpmākais SQL vaicājums) aizņem desmitiem milisekundu. Å ajā konkrētajā gadÄ«jumā problēmu atrisināja pastāvÄ«gi savienojumi.

MÅ«sdienu servisa tÄ«kli labāk risina Ŕādas problēmas. Pirmkārt, viņi pārbauda, ā€‹ā€‹vai savienojumi ir marÅ”rutēti avotā. LoÄ£iskā plÅ«sma ir tāda pati: ŠŗŠ»ŠøŠµŠ½Ń‚ ā†’ Š¼ŠµŃˆ ā†’ сŠµŃ€Š²Šøс, bet tagad tÄ«kls darbojas lokāli, nevis attālos mezglos, tāpēc savienojums ŠŗŠ»ŠøŠµŠ½Ń‚ ā†’ Š¼ŠµŃˆ ir lokāls un ļoti ātrs (mikrosekundes, nevis milisekundes).

MÅ«sdienu pakalpojumu tÄ«kli ievieÅ” arÄ« viedākus slodzes lÄ«dzsvaroÅ”anas algoritmus. Pārraugot aizmugursistēmu stāvokli, tās var nosÅ«tÄ«t vairāk trafika uz ātrākām aizmugursistēmām, tādējādi uzlabojot vispārējo veiktspēju.

DroŔība arÄ« labāk. DotCloud marÅ”rutÄ“Å”anas tÄ«kls pilnÄ«bā darbojās uz EC2 Classic un neÅ”ifrēja trafiku (pamatojoties uz pieņēmumu, ka, ja kādam izdevās ievietot sniffer EC2 tÄ«kla trafikā, jums jau bija lielas problēmas). MÅ«sdienu pakalpojumu tÄ«kli pārredzami aizsargā visu mÅ«su trafiku, piemēram, ar savstarpēju TLS autentifikāciju un sekojoÅ”u Å”ifrÄ“Å”anu.

Trafika marŔrutēŔana platformas pakalpojumiem

Labi, mēs esam apsprieduÅ”i trafiku starp lietojumprogrammām, bet kā ar paÅ”u platformu dotCloud?

Pati platforma sastāvēja no aptuveni simts mikropakalpojumiem, kas atbild par dažādām funkcijām. Daži pieņēma pieprasÄ«jumus no citiem, un daži bija fona darbinieki, kuri izveidoja savienojumu ar citiem pakalpojumiem, bet paÅ”i nepieņēma savienojumus. Jebkurā gadÄ«jumā katram pakalpojumam ir jāzina to adreÅ”u galapunkti, ar kurām tam nepiecieÅ”ams izveidot savienojumu.

Daudzi augsta lÄ«meņa pakalpojumi var izmantot iepriekÅ” aprakstÄ«to marÅ”rutÄ“Å”anas tÄ«klu. Faktiski daudzi no dotCloud vairāk nekā simts mikropakalpojumiem ir izvietoti kā parastas lietojumprogrammas paŔā dotCloud platformā. Taču nelielam skaitam zema lÄ«meņa pakalpojumu (Ä«paÅ”i tiem, kas ievieÅ” Å”o marÅ”rutÄ“Å”anas tÄ«klu) bija nepiecieÅ”ams kaut kas vienkārŔāks ar mazākām atkarÄ«bām (jo viņi nevarēja bÅ«t atkarÄ«gi no sevis, lai darbotos ā€” vecā labā vistas un olu problēma).

Å ie zemā lÄ«meņa, misijai kritiskie pakalpojumi tika izvietoti, palaižot konteinerus tieÅ”i dažos galvenajos mezglos. Å ajā gadÄ«jumā standarta platformas pakalpojumi netika izmantoti: saistÄ«tājs, plānotājs un skrējējs. Ja vēlaties salÄ«dzināt ar mÅ«sdienu konteineru platformām, tas ir tāpat kā ar vadÄ«bas plaknes vadÄ«Å”anu docker run tieÅ”i mezglos, nevis deleģēt uzdevumu Kubernetes. Tas ir diezgan lÄ«dzÄ«gs koncepcijā statiskie moduļi (podi), ko tā izmanto kubeadm vai bootkube sāknējot atseviŔķu klasteru.

Å ie pakalpojumi tika atklāti vienkārŔā un neapstrādātā veidā: YAML failā bija norādÄ«ti to vārdi un adreses; un katram klientam bija jāpaņem Ŕī YAML faila kopija izvietoÅ”anai.

No vienas puses, tas ir ārkārtÄ«gi uzticams, jo tam nav nepiecieÅ”ams atbalsts no ārēja atslēgu/vērtÄ«bu krātuves, piemēram, Zookeeper (atcerieties, etcd vai Consul tajā laikā neeksistēja). No otras puses, tas apgrÅ«tināja pakalpojumu pārvietoÅ”anu. Katru reizi, kad tika veikta pārvietoÅ”ana, visi klienti saņems atjauninātu YAML failu (un, iespējams, tiks restartēts). Nav ļoti ērti!

Pēc tam mēs sākām ieviest jaunu shēmu, kurā katrs klients pieslēdzās lokālajam starpniekserveri. Adreses un porta vietā tam ir jāzina tikai pakalpojuma porta numurs un jāizveido savienojums, izmantojot localhost. Vietējais starpniekserveris apstrādā Å”o savienojumu un pārsÅ«ta to faktiskajam serverim. Tagad, pārvietojot aizmugursistēmu uz citu maŔīnu vai mērogojot, tā vietā, lai atjauninātu visus klientus, ir jāatjaunina tikai visi Å”ie lokālie starpniekserveri; un atsāknÄ“Å”ana vairs nav nepiecieÅ”ama.

(Tāpat bija plānots iekapsulēt trafiku TLS savienojumos un ievietot citu starpniekserveri saņēmēja pusē, kā arī pārbaudīt TLS sertifikātus bez saņēmēja pakalpojuma līdzdalības, kas ir konfigurēts, lai pieņemtu savienojumus tikai localhost. Vairāk par to vēlāk).

Tas ir ļoti lÄ«dzÄ«gs SmartStack no Airbnb, taču bÅ«tiskā atŔķirÄ«ba ir tā, ka SmartStack ir ieviests un izvietots ražoÅ”anā, savukārt dotCloud iekŔējā marÅ”rutÄ“Å”anas sistēma tika apturēta, kad dotCloud kļuva par Docker.

Es personÄ«gi uzskatu, ka SmartStack ir viens no tādu sistēmu priekÅ”tečiem kā Istio, Linkerd un Consul Connect, jo tās visas ievēro vienu un to paÅ”u modeli:

  • Palaidiet starpniekserveri katrā mezglā.
  • Klienti izveido savienojumu ar starpniekserveri.
  • VadÄ«bas plakne atjaunina starpniekservera konfigurāciju, kad mainās aizmugursistēmas.
  • ... Peļņa!

Mūsdienīga servisa tīkla ievieŔana

Ja mums Å”odien bÅ«tu nepiecieÅ”ams ieviest lÄ«dzÄ«gu tÄ«klu, mēs varētu izmantot lÄ«dzÄ«gus principus. Piemēram, konfigurējiet iekŔējo DNS zonu, kartējot pakalpojumu nosaukumus ar adresēm Å”ajā telpā 127.0.0.0/8. Pēc tam palaidiet HAProxy katrā klastera mezglā, pieņemot savienojumus katrā pakalpojuma adresē (Å”ajā apakÅ”tÄ«klā 127.0.0.0/8) un slodzes novirzÄ«Å”anu/lÄ«dzsvaroÅ”anu uz atbilstoÅ”ajām aizmugursistēmām. HAProxy konfigurāciju var kontrolēt confd, ļaujot saglabāt aizmugursistēmas informāciju programmā etcd vai Consul un automātiski nosÅ«tÄ«t atjaunināto konfigurāciju HAProxy, kad nepiecieÅ”ams.

Tas ir gandrīz tas, kā Istio darbojas! Bet ar dažām atŔķirībām:

  • Lietojumi SÅ«tņa pilnvarnieks HAProxy vietā.
  • Saglabā aizmugursistēmas konfigurāciju, izmantojot Kubernetes API, nevis etcd vai Consul.
  • Pakalpojumiem tiek pieŔķirtas adreses iekŔējā apakÅ”tÄ«klā (Kubernetes ClusterIP adreses), nevis 127.0.0.0/8.
  • Ir papildu komponents (Citadele), lai pievienotu savstarpēju TLS autentifikāciju starp klientu un serveriem.
  • Atbalsta jaunas funkcijas, piemēram, ķēdes pārtraukumu, izplatÄ«tu izsekoÅ”anu, kanāriju izvietoÅ”anu utt.

ÄŖsi apskatÄ«sim dažas atŔķirÄ«bas.

Sūtņa pilnvarnieks

Envoy Proxy uzrakstÄ«ja Lyft [Uber konkurents taksometru tirgÅ« - apm. josla]. Tas daudzējādā ziņā ir lÄ«dzÄ«gs citiem starpniekserveriem (piemēram, HAProxy, Nginx, Traefik...), taču Lyft rakstÄ«ja savējo, jo viņiem bija vajadzÄ«gas funkcijas, kuru trÅ«ka citiem starpniekserveriem, un Ŕķita gudrāk izveidot jaunu, nevis paplaÅ”ināt esoÅ”o.

SÅ«tni var izmantot atseviŔķi. Ja man ir konkrēts pakalpojums, kuram nepiecieÅ”ams izveidot savienojumu ar citiem pakalpojumiem, es varu to konfigurēt, lai izveidotu savienojumu ar Envoy, un pēc tam dinamiski konfigurēt un pārkonfigurēt Envoy ar citu pakalpojumu atraÅ”anās vietu, vienlaikus iegÅ«stot daudz lielisku papildu funkcionalitāti, piemēram, redzamÄ«bu. Tā vietā, lai izveidotu pielāgotu klienta bibliotēku vai kodā ievadÄ«tu zvanu pēdas, mēs nosÅ«tām trafiku uz Envoy, un tas apkopo metriku mÅ«su vietā.

Bet SÅ«tnis ir spējÄ«gs strādāt arÄ« kā datu plakne (datu plakne) servisa tÄ«klam. Tas nozÄ«mē, ka Envoy tagad ir konfigurēts Å”im pakalpojuma tÄ«klam vadÄ«bas plakne (vadÄ«bas plakne).

Vadības plakne

VadÄ«bas plaknei Istio paļaujas uz Kubernetes API. Tas Ä«paÅ”i neatŔķiras no confd lietoÅ”anas, kas paļaujas uz etcd vai Consul, lai skatÄ«tu atslēgu kopu datu krātuvē. Istio izmanto Kubernetes API, lai skatÄ«tu Kubernetes resursu kopu.

Starp Å”o un pēc tam: Man personÄ«gi tas Ŕķita noderÄ«gi Kubernetes API aprakstskas skan:

Kubernetes API serveris ir ā€œmēms serverisā€, kas piedāvā API resursu glabāŔanu, versiju izveidi, validāciju, atjaunināŔanu un semantiku.

Istio ir paredzēts darbam ar Kubernetes; un, ja vēlaties to izmantot ārpus Kubernetes, jums ir jāpalaiž Kubernetes API servera gadījums (un etcd palīga pakalpojums).

Servisa adreses

Istio paļaujas uz ClusterIP adresēm, kuras pieŔķir Kubernetes, tāpēc Istio pakalpojumi saņem iekŔējo adresi (nav diapazonā 127.0.0.0/8).

DatplÅ«smu uz ClusterIP adresi noteiktam pakalpojumam Kubernetes klasterÄ« bez Istio pārtver kube starpniekserveris un nosÅ«ta uz Ŕī starpniekservera aizmugursistēmu. Ja jÅ«s interesē tehniskā informācija, kube-proxy iestata iptables kārtulas (vai IPVS slodzes balansētājus atkarÄ«bā no tā, kā tas ir konfigurēts), lai pārrakstÄ«tu to savienojumu galamērÄ·a IP adreses, kas ved uz ClusterIP adresi.

Kad Istio ir instalēts Kubernetes klasterÄ«, nekas nemainās, kamēr tas nav skaidri iespējots konkrētam patērētājam vai pat visai nosaukumvietai, ievieÅ”ot konteineru. sidecar pielāgotās pākstÄ«s. Å is konteiners izveidos sÅ«tņa gadÄ«jumu un iestatÄ«s iptables noteikumu kopu, lai pārtvertu datplÅ«smu uz citiem pakalpojumiem un novirzÄ«tu Å”o trafiku uz Envoy.

Integrējot ar Kubernetes DNS, tas nozÄ«mē, ka mÅ«su kods var izveidot savienojumu ar pakalpojuma nosaukumu un viss ā€œtikai darbojasā€. Citiem vārdiem sakot, mÅ«su kods izdod tādus vaicājumus kā http://api/v1/users/4242tad api atrisināt pieprasÄ«jumu 10.97.105.48, iptables kārtulas pārtvers savienojumus no 10.97.105.48 un pārsÅ«tÄ«s tos vietējam sÅ«tņa starpniekserveri, un Å”is vietējais starpniekserveris pārsÅ«tÄ«s pieprasÄ«jumu faktiskajam aizmugursistēmas API. Fu!

Papildu volāni

Istio nodroÅ”ina arÄ« pilnÄ«gu Å”ifrÄ“Å”anu un autentifikāciju, izmantojot mTLS (savstarpēju TLS). Komponents ar nosaukumu Citadele.

Ir arÄ« sastāvdaļa Mikseris, ko sÅ«tnis var pieprasÄ«t no katra pieprasÄ«jums pieņemt Ä«paÅ”u lēmumu par Å”o pieprasÄ«jumu atkarÄ«bā no dažādiem faktoriem, piemēram, galvenēm, aizmugursistēmas slodzes utt... (neuztraucieties: ir daudzi veidi, kā turpināt Mixer darbÄ«bu, un pat ja tas avarē, Envoy turpinās strādāt labi kā starpniekserveris) .

Un, protams, mēs pieminējām redzamÄ«bu: Envoy apkopo milzÄ«gu daudzumu metrikas, vienlaikus nodroÅ”inot izplatÄ«tu izsekoÅ”anu. Ja mikropakalpojumu arhitektÅ«rā vienam API pieprasÄ«jumam ir jānokļūst caur mikropakalpojumiem A, B, C un D, ā€‹ā€‹tad pēc pieteikÅ”anās izplatÄ«tā izsekoÅ”ana pievienos pieprasÄ«jumam unikālu identifikatoru un saglabās Å”o identifikatoru, izmantojot apakÅ”pieprasÄ«jumus visiem Å”iem mikropakalpojumiem, ļaujot visi saistÄ«tie zvani, kas jāuztver.aizkavÄ“Å”anās utt.

Izstrādāt vai iegādāties

Istio ir pazÄ«stams kā sarežģīts. Turpretim marÅ”rutÄ“Å”anas tÄ«kla izveide, ko es aprakstÄ«ju Ŕīs ziņas sākumā, ir salÄ«dzinoÅ”i vienkārÅ”a, izmantojot esoÅ”os rÄ«kus. Tātad, vai ir jēga tā vietā izveidot savu pakalpojumu tÄ«klu?

Ja mums ir pieticÄ«gas vajadzÄ«bas (nav vajadzÄ«ga redzamÄ«ba, automātiskais slēdzis un citi smalkumi), tad rodas domas par sava instrumenta izstrādi. Bet, ja mēs izmantojam Kubernetes, tas var pat nebÅ«t vajadzÄ«gs, jo Kubernetes jau nodroÅ”ina pamata rÄ«kus pakalpojumu atklāŔanai un slodzes lÄ«dzsvaroÅ”anai.

Bet, ja mums ir paaugstinātas prasÄ«bas, servisa tÄ«kla ā€œiegādāŔanāsā€ Ŕķiet daudz labāks risinājums. (Tas ne vienmēr ir pirkums, jo Istio ir atvērtā koda avots, taču mums joprojām ir jāiegulda inženierijas laiks, lai to saprastu, izvietotu un pārvaldÄ«tu.)

Vai man izvēlēties Istio, Linkerd vai Consul Connect?

LÄ«dz Å”im esam runājuÅ”i tikai par Istio, taču tas nav vienÄ«gais servisa tÄ«kls. Populāra alternatÄ«va - Linkerd, un ir vēl vairāk Consul Connect.

Ko izvēlēties?

GodÄ«gi sakot, es nezinu. Å obrÄ«d neuzskatu, ka esmu pietiekami kompetents, lai atbildētu uz Å”o jautājumu. Ir daži interesanti raksti ar Å”o rÄ«ku salÄ«dzinājumu un pat etaloniem.

Viena daudzsoloÅ”a pieeja ir izmantot lÄ«dzÄ«gu rÄ«ku SuperGloo. Tas ievieÅ” abstrakcijas slāni, lai vienkārÅ”otu un apvienotu API, ko atklāj pakalpojumu tÄ«kli. Tā vietā, lai apgÅ«tu dažādu pakalpojumu tÄ«klu specifiskās (un, manuprāt, salÄ«dzinoÅ”i sarežģītās) API, mēs varam izmantot SuperGloo vienkārŔākas konstrukcijas un viegli pārslēgties no vienas uz otru, it kā mums bÅ«tu starpposma konfigurācijas formāts, kas apraksta HTTP saskarnes un aizmugursistēmas. faktiskās konfigurācijas Ä£enerÄ“Å”ana Nginx, HAProxy, Traefik, Apache...

Esmu nedaudz parunājis ar Istio un SuperGloo, un nākamajā rakstā vēlos parādÄ«t, kā pievienot Istio vai Linkerd esoÅ”am klasterim, izmantojot SuperGloo, un kā pēdējais paveic darbu, tas ir, ļauj pārslēgties no no viena pakalpojuma tÄ«kla uz otru, nepārrakstot konfigurācijas.

Avots: www.habr.com

Pievieno komentāru