Di înternetê de (tevra karûbarê), û li vir yekî din heye. Hooray! Lê çima? Dûv re, ez dixwazim nêrîna xwe bibêjim ku dê çêtir bûya ku torgilokên karûbarê 10 sal berê, berî hatina platformên konteynerê yên wekî Docker û Kubernetes xuya bibûna. Ez nabêjim ku nêrîna min ji yên din çêtir an xirabtir e, lê ji ber ku mêşên karûbar heywanên pir tevlihev in, gelek nêrîn dê ji bo baştir fêmkirina wan bibin alîkar.
Ez ê qala platforma dotCloud-ê bikim, ku li ser sed mîkro-servîsan hatî çêkirin û bi hezaran serîlêdanên konteyneran piştgirî kir. Ez ê di pêşkeftin û destpêkirina wê de kêşeyên ku em pê re rû bi rû mane re vebêjim, û ka meşkên karûbarê çawa dikarin (an nekarîn) bibin alîkar.
Dîroka dotCloud
Min li ser dîroka dotCloud û vebijarkên mîmarî yên ji bo vê platformê nivîsî, lê min pir li ser qata torê neaxivî. Ger hûn naxwazin di xwendinê de bikevin di derbarê dotCloud-ê de, li vir bi kurtasî xalek heye: ew platformek PaaS-wek-karûbar e ku dihêle xerîdar cûrbecûr serîlêdanan (Java, PHP, Python...) bimeşînin, bi piştgirîya cûrbecûr daneyan. karûbar (MongoDB, MySQL, Redis...) û xebatek mîna Heroku: Hûn koda xwe li platformê bar dikin, ew wêneyên konteynerê ava dike û wan bi cih dike.
Ez ê ji we re vebêjim ka seyrûsefer çawa berbi platforma dotCloud ve hatî rêve kirin. Ne ji ber ku ew bi taybetî xweş bû (her çend pergal ji bo dema xwe baş dixebitî!), lê di serî de ji ber ku bi amûrên nûjen sêwiranek weha bi hêsanî dikare di demek kurt de ji hêla tîmek hûrgelê ve were bicîh kirin heke ew hewceyê rêyek ji bo rêgirtina seyrûseferê di navbera komekê de be. mîkroxizmet an komek serîlêdan. Bi vî rengî, hûn dikarin vebijarkan bidin ber hev: çi diqewime heke hûn her tiştî bi xwe pêşve bibin an tevnek karûbarê heyî bikar bînin. Hilbijartina standard ev e ku hûn wê bi xwe çêbikin an bikirin.
Rêvekirina trafîkê ji bo serîlêdanên mêvandar
Serlêdanên li ser dotCloud dikarin xalên dawiya HTTP û TCP eşkere bikin.
xalên dawî yên HTTP bi awayekî dînamîkî li veavakirina komê ya balansa barkirinê zêde kirin . Ev dişibihe ya ku çavkanî îro dikin di Kubernetes de û balansek barkirinê mîna .
Xerîdar bi navgînên guncan ve bi xalên dawiya HTTP-ê ve girêdidin, bi şertê ku navê domainê balansên barkirinê yên dotCloud nîşan bide. Ne tiştekî taybet.
xalên dawî yên TCP bi jimareyek portê ve girêdayî ye, ku dûv re bi navgîniya guhêrbarên hawîrdorê ji hemî konteynerên di wê stakê re tê şandin.
Xerîdar dikarin bi karanîna navnîşa mêvandarê guncan (tiştek mîna gateway-X.dotcloud.com) û jimareya portê bi xalên dawiya TCP-ê ve girêbidin.
Ev navê mêvandar bi koma servera "nats" re (ne girêdayî ye ), ya ku dê girêdanên TCP-ê yên hatinî berbi konteynera rast (an jî, di warê karûbarên hevseng ên barkirinê de, ber bi konteynerên rast ve bi rê ve bibe).
Heke hûn bi Kubernetes re nas dikin, ev ê dibe ku hûn Karûbaran bi bîr bînin .
Li ser platforma dotCloud karûbarên wekhev tune bûn : Ji bo hêsaniyê, karûbar hem ji hundur û hem jî ji derveyî platformê bi heman rengî hatin gihîştin.
Her tişt bi hêsanî hate organîze kirin: pêkanînên destpêkê yên torên rêvekirina HTTP û TCP belkî tenê çend sed xetên Python bûn. Algorîtmayên hêsan (ez ê bêjim naîf) yên ku her ku platform mezin bû û hewcedariyên zêde derketin holê hatin paqij kirin.
Refaktorkirina berfireh a koda heyî ne hewce bû. Gelek rindik, dikare rasterast navnîşana ku ji hêla guhêrbarên hawîrdorê ve hatî wergirtin bikar bîne.
Ev ji tevna karûbarê nûjen çawa cûda ye?
Limited dîtinî. Ji bo tevna rêvekirina TCP qet metrîka me tunebû. Dema ku dor tê ser rêvekirina HTTP, guhertoyên paşîn pîvanên hûrgulî yên HTTP-ê bi kodên xeletiyê û demên bersivdayînê destnîşan kirin, lê tevnên karûbarê nûjen hîn bêtir diçin, mînakî, bi pergalên berhevkirina metrîkan re mîna Prometheus re entegrasyonê peyda dikin.
Visibility ne tenê ji perspektîfek operasyonê girîng e (ji bo ku hûn pirsgirêkên pirsgirêkan çareser bikin), lê her weha dema ku taybetmendiyên nû berdan. Ew li ser ewlehiyê ye и .
karîgerîya rê jî sînorkirî ye. Di tevna rêvekirina dotCloud de, pêdivî bû ku hemî seyrûsefer di nav komek girêkên rêvekirinê yên diyarkirî de derbas bibe. Ev tê vê wateyê ku potansiyel derbaskirina sînorên pirjimar AZ (Zêdeya Berdestî) û bi girîngî zêdekirina derengbûnê. Tê bîra min koda çareserkirina pirsgirêkan ku li ser her rûpelê zêdetirî sed lêpirsînên SQL çêdikir û ji bo her pirsê pêwendiyek nû ji servera SQL re vedike. Dema ku li herêmî tê xebitandin, rûpel tavilê tê barkirin, lê di dotCloud de barkirina çend saniyan digire ji ber ku her pêwendiya TCP-ê (û pirsiyara SQL ya paşîn) bi deh milî çirkeyan digire. Di vê rewşa taybetî de, girêdanên domdar pirsgirêk çareser kirin.
Tûrên karûbarê nûjen di çareserkirina pirsgirêkên weha de çêtir in. Berî her tiştî, ew kontrol dikin ku girêdan têne rêve kirin di çavkaniyê de. Herikîna mantiqî heman e: клиент → меш → сервис, lê naha tevn herêmî û ne li ser girêkên dûr kar dike, ji ber vê yekê girêdan клиент → меш herêmî ye û pir bi lez e (li şûna mîlîçirkeyan mîkroçirkeyan).
Tûrên karûbarê nûjen di heman demê de algorîtmayên hevsengiya barkirinê jîrtir bicîh tînin. Bi çavdêriya tenduristiya paşîn, ew dikarin bêtir seyrûseferê bişînin paşverûyên bileztir, ku di encamê de performansa giştî çêtir dibe.
Ewlekariyê baştir jî. Tora rêvekirina dotCloud bi tevahî li ser EC2 Classic dimeşand û seyrûseferê şîfre nekir (li ser bingeha texmînê ku heke kesek karibe snifferek bide ser seyrûsefera torê EC2, hûn jixwe di tengasiyek mezin de bûn). Tûrên karûbarê nûjen bi zelalî hemî seyrûsefera me diparêzin, mînakî, bi piştrastkirina hevdu TLS û şîfrekirina paşîn.
Rêvekirina trafîkê ji bo karûbarên platformê
Baş e, me li ser seyrûsefera di navbera serlêdanan de nîqaş kir, lê di derbarê platforma dotCloud bixwe de çi?
Platform bixwe ji sed mîkroxizmetên ku ji fonksiyonên cihêreng berpirsiyar in pêk dihat. Hin daxwazên kesên din qebûl kirin, û hin jî xebatkarên paşerojê bûn ku bi karûbarên din ve girêdayî bûn lê bi xwe girêdan qebûl nekirin. Di her rewşê de, her karûbar divê xalên dawî yên navnîşanên ku ew hewce ne ku pê ve girêdayî bizanibe.
Dibe ku gelek karûbarên asta bilind tevna rêvekirinê ya ku li jor hatî destnîşan kirin bikar bînin. Di rastiyê de, gelek ji zêdetirî sed mîkroxizmetên dotCloud wekî serîlêdanên birêkûpêk li ser platforma dotCloud bixwe hatine bicîh kirin. Lê hejmarek hindik karûbarên nizm (nemaze yên ku vê tevna rêvekirinê pêk tînin) hewcedarî tiştek hêsan, bi hindik ve girêdayî bûn (ji ber ku ew nekarîn bi xwe ve girêdayî bixebitin - pirsgirêka mirîşk û hêkan a kevn).
Van karûbarên nizm, mîsyonên krîtîk bi rêvekirina konteyniran rasterast li ser çend girêkên sereke hatin bicîh kirin. Di vê rewşê de, karûbarên platformê yên standard nehatin bikar anîn: linker, scheduler û runner. Heke hûn dixwazin bi platformên konteynerê yên nûjen re bidin ber hev, ew mîna ku pê re balafirek kontrolê dimeşîne ye docker run rasterast li ser girêkan, li şûna ku peywirê bidin Kubernetes. Di konseptê de pir dişibihe , ku ew bikar tîne an dema bootkirina komek serbixwe.
Van karûbaran bi rengekî sade û xav hatin eşkere kirin: dosyayek YAML nav û navnîşanên wan destnîşan kir; û her xerîdar neçar bû ku kopiyek vê pelê YAML ji bo bicîhkirinê bigire.
Ji aliyek ve, ew zehf pêbawer e ji ber ku ew piştgirîya mifteyek / dikanek nirxê derveyî mîna Zookeeper (ji bîr bîne, etcd an Konsul wê demê tunebû) hewce nake. Ji aliyê din ve, veguhestina xizmetan zehmet kir. Her gava ku tevgerek hate çêkirin, hemî xerîdar dê pelek YAML-ya nûvekirî bistînin (û dibe ku ji nû ve dest pê bikin). Ne pir rehet!
Dûv re, me dest bi pêkanîna nexşeyek nû kir, ku her xerîdar bi serverek proxy ya herêmî ve girêdayî ye. Li şûna navnîşek û portê, ew tenê hewce dike ku jimareya portê ya karûbarê zanibe, û pê ve girêdayî be localhost. Proxy herêmî vê pêwendiyê digire û wê ber bi servera rastîn ve dişîne. Naha, dema ku paşîn berbi makîneyek din veguhezînin an pîvandin, li şûna ku hûn hemî xerîdar nûve bikin, hûn tenê hewce ne ku van hemî proxeyên herêmî nûve bikin; û reboot êdî ne hewce ye.
(Di heman demê de hate plan kirin ku seyrûsefera di girêdanên TLS de were vegirtin û serverek din a proxy li aliyê wergirtinê were danîn, û her weha sertîfîkayên TLS bêyî tevlêbûna karûbarê wergirtinê verast bike, ku ji bo pejirandina girêdanan tenê li ser ve hatî mîheng kirin localhost. Li ser vê paşê bêtir).
Ev pir dişibe ji Airbnb, lê ciyawaziya girîng ev e ku SmartStack tê sepandin û di hilberînê de tê bicîh kirin, dema ku dotCloud bû Docker pergala rêveçûna hundurîn a dotCloud raxistî bû.
Ez bixwe SmartStack wekî yek ji pêşekên pergalên mîna Istio, Linkerd û Consul Connect dihesibînim ji ber ku ew hemî heman şêwazê dişopînin:
- Li ser her girêkek proxy bimeşînin.
- Xerîdar bi proxy ve girêdidin.
- Balafira kontrolê gava ku paşnav diguhezin veavakirina proxy nûve dike.
- ... Profit!
Pêkanîna nûjen a tevna karûbarê
Ger hewce bû ku me îro torgilokek wekhev bicîh bîne, em dikarin prensîbên wekhev bikar bînin. Mînakî, herêmek DNS-ya navxweyî bi nexşeya navên karûbarê li navnîşanên li cîhê mîheng bikin 127.0.0.0/8. Dûv re HAProxy-ê li ser her girêkek di komê de bimeşînin, girêdanên li her navnîşana karûbarê (di wê jêrtorê de) qebûl bikin 127.0.0.0/8) û beralîkirina / hevsengkirina barkirinê berbi paşînên guncan. Veavakirina HAProxy dikare were kontrol kirin , dihêle hûn agahdariya paşîn di etcd an Konsul de hilînin û gava ku hewce be bixweber veavakirina nûvekirî bişopînin HAProxy.
Bi vî rengî Istio pir çawa dixebite! Lê bi hin cûdahiyan:
- Bikaranîn li şûna HAProxy.
- Li şûna etcd an Konsul, veavakirina paşîn bi navgîniya Kubernetes API-yê difiroşe.
- Xizmet li şûna 127.0.0.0/8 navnîşanên li jêrtora navxweyî (navnîşanên Kubernetes ClusterIP) têne veqetandin.
- Pêvekek pêvek heye (Citadel) ku di navbera xerîdar û pêşkêşkeran de piştrastkirina TLS-ya hevdu zêde bike.
- Taybetmendiyên nû yên wekî şikandina çerxerê, şopandina belavbûyî, bicihkirina canary, hwd piştgirî dike.
Ka em bi lez li hin cûdahiyan binihêrin.
Nûnerê Nûnerê
Envoy Proxy ji hêla Lyft ve hatî nivîsandin [hevrikê Uber di sûka taksiyê de - nêzîkê. kûçe]. Ew bi gelek awayan dişibihe proxeyên din (mînak HAProxy, Nginx, Traefik...), lê Lyft ya wan nivîsand ji ber ku wan hewceyê taybetmendiyên ku proxyên din jê tune bûn, û jêhatîtir xuya bû ku meriv yekî nû çêbike ne ku ya heyî dirêj bike.
Envoy dikare bi serê xwe were bikar anîn. Ger karûbarek min a taybetî hebe ku hewce dike ku bi karûbarên din ve were girêdan, ez dikarim wê mîheng bikim da ku bi Envoy ve were girêdan, û dûv re bi rengek dînamîkî bi cîhê karûbarên din re Envoy mîheng bikim û ji nû ve mîheng bikim, di heman demê de gelek fonksiyonên din ên mezin, wek xuyangiyê, werdigirim. Li şûna pirtûkxaneyek xerîdar a xwerû an xistina şopên bangê li kodê, em seyrûseferê ji Envoy re dişînin, û ew ji me re metrikan berhev dike.
Lê Envoy di heman demê de dikare wekî kar bike balafira daneyan (balafira daneyan) ji bo tevna karûbarê. Ev tê vê wateyê ku nûnerê nuha ji bo vê xizmeta mesh tê mîheng kirin balafira kontrolê (balafira kontrolê).
Balafira kontrolê
Ji bo balafira kontrolê, Istio xwe dispêre Kubernetes API. Ev ji bikaranîna confd ne pir cûda ye, ku xwe dispêre etcd an Konsul ji bo dîtina komek kilîtan li dikana daneyê. Istio API-ya Kubernetes bikar tîne da ku komek çavkaniyên Kubernetes bibîne.
Di navbera vê û paşê de: Min bi xwe ev kêrhatî dît ku dixwîne:
Pêşkêşkara Kubernetes API "pêşkêşkerek lal" e ku ji bo çavkaniyên API-ê hilanîn, guhertokirin, pejirandin, nûvekirin û semantîk pêşkêşî dike.
Istio hatiye dîzaynkirin ku bi Kubernetes re bixebite; û heke hûn dixwazin wê li derveyî Kubernetes bikar bînin, wê hingê hûn hewce ne ku mînakek servera Kubernetes API (û karûbarê alîkarê etcd) bimeşînin.
Navnîşanên xizmetê
Istio xwe dispêre navnîşanên ClusterIP-ê yên ku Kubernetes vediqetîne, ji ber vê yekê karûbarên Istio navnîşanek navxweyî werdigirin (ne di rêzê de 127.0.0.0/8).
Trafîka navnîşana ClusterIP-ê ya ji bo karûbarek taybetî di komek Kubernetes de bêyî Istio ji hêla kube-proxy ve tê girtin û ji pişta wê proxy re tê şandin. Heke hûn bi hûrguliyên teknîkî re eleqedar in, kube-proxy qaîdeyên iptables (an hevsengên barkirina IPVS-ê, li gorî ka ew çawa hatî mîheng kirin) saz dike da ku navnîşanên IP-ya armancê yên girêdanên ku diçin navnîşana ClusterIP ji nû ve binivîsin.
Dema ku Istio li ser komek Kubernetes were saz kirin, tiştek nayê guhertin heya ku ew bi eşkereyî ji bo xerîdarek diyarkirî, an tewra cîhê navan jî, bi danasîna konteynerek vekirî neyê çalak kirin. sidecar nav polên xwerû. Ev konteynir dê mînakek Envoy bizivirîne û komek rêgezên iptables saz bike da ku seyrûsefera ku diçe karûbarên din bigire û wê seyrûseferê beralî bike Envoy.
Gava ku bi Kubernetes DNS re yekgirtî ye, ev tê vê wateyê ku kodê me dikare bi navê karûbarê û her tiştî "tenê bixebite." Bi gotinek din, koda me pirsên mîna pirs dike http://api/v1/users/4242paşê api daxwaza çareser bikin 10.97.105.48, qaîdeyên iptables dê girêdanên ji 10.97.105.48-ê ve bigire û wan bişîne nûnerê Envoy herêmî, û ew proxy herêmî dê daxwazê bişîne API-ya paşerojê ya rastîn. Heyf!
firaxên din
Istio di heman demê de bi mTLS (TLS hevbeş) şîfrekirin û pejirandina dawî-bi-dawî peyda dike. Parçeyek tê gotin kelha.
Pêkhateyek jî heye Navhevxistok, ku Şand dikare daxwaz bike ji her yekê daxwaz bikin ku li ser wê daxwazê biryarek taybetî bidin ku li gorî faktorên cihêreng ên wekî sernav, barkirina piştê, hwd... (xem neke: gelek awayên xebitandina Mixer hene, û heke ew têk biçe jî, Envoy dê xebata xwe bidomîne baş wekî wekîlê).
Û, bê guman, me behsa dîtbariyê kir: Envoy dema ku şopandina belavkirî peyda dike hejmareke mezin ji metrîkan berhev dike. Di mîmariya mîkroxizmetê de, heke yek daxwazek API-yê divê di mîkroxizmetên A, B, C, û D re derbas bibe, wê hingê piştî têketinê, şopandina belavkirî dê nasnameyek yekta li daxwazê zêde bike û vê nasnameyê bi jêr-daxwazan ji van hemî mîkroxizmetan re hilîne, bihêle. hemî bangên peywendîdar bêne girtin. dereng, hwd.
Pêşvebirin an bikirin
Istio bi tevlihevbûna xwe navûdeng e. Berevajî vê yekê, avakirina rêwîtiya ku min di destpêka vê postê de diyar kir, bi karanîna amûrên heyî re têkildar e. Ji ber vê yekê, gelo ew wate dike ku li şûna mestê karûbarê xwe biafirîne?
Ger hewcedariyên me yên hûrgelî hebin (hewcedariya me bi dîtinê, şkestinek û hûrguliyên din tune), wê hingê raman têne pêşkeftina amûra xwe. Lê heke em Kubernetes bikar bînin, dibe ku ew ne hewce be ji ber ku Kubernetes jixwe amûrên bingehîn ji bo vedîtina karûbar û hevsengkirina barkirinê peyda dike.
Lê heke pêdiviyên me yên pêşkeftî hebin, wê hingê "kirîna" tevna karûbarê vebijarkek pir çêtir xuya dike. (Ev her gav ne "kirîn" e ji ber ku Istio çavkaniyek vekirî ye, lê dîsa jî pêdivî ye ku em wextê endezyariyê veberhênan bikin da ku wê fêm bikin, bicîh bikin û îdare bikin.)
Ma ez Istio, Linkerd an Consul Connect hilbijêrin?
Heya nuha me tenê li ser Istio peyivî, lê ev ne tenê tevna karûbarê ye. Alternatîfek populer e , û bêtir heye .
Çi hilbijêre?
Bi rastî, ez nizanim. Niha ez xwe têra xwe jêhatî nabînim ku bersiva vê pirsê bidim. Çend hene bi berhevdana van amûran û heta .
Nêzîkatiyek sozdar ev e ku meriv amûrek mîna bikar bîne . Ew qatek abstraction bicîh tîne da ku API-yên ku ji hêla tevnên karûbarê ve têne xuyang kirin hêsan û yek bikin. Li şûna ku em API-yên taybetî (û, bi dîtina min, nisbeten tevlihev) yên tevnên karûbarê cihêreng fêr bibin, em dikarin avahîyên hêsan ên SuperGloo-yê bikar bînin - û bi hêsanî ji yek biguhezînin yekî din, mîna ku me formatek veavakirina navîn hebe ku navbeynkariya HTTP û paşvekêşan diyar dike. çêkirina konfigurasyona rastîn ji bo Nginx, HAProxy, Traefik, Apache...
Min piçekî bi Istio û SuperGloo re mijûl kir, û di gotara din de ez dixwazim nîşan bidim ka meriv çawa Istio an Linkerd li komek heyî bi karanîna SuperGloo zêde dike, û ya paşîn çawa karê pêk tîne, ango destûrê dide te ku ji yek tevna karûbarê ji ya din re bêyî ku veavakirinan binivîsîne.
Source: www.habr.com