Air an eadar-lìn (mogal seirbheis), agus seo fear eile. Hooray! Ach carson? An uairsin, tha mi airson mo bheachd a chuir an cèill gum biodh e air a bhith na b’ fheàrr nan nochd mogaill seirbheis 10 bliadhna air ais, mus tàinig àrd-ùrlaran soithichean mar Docker agus Kubernetes. Chan eil mi ag ràdh gu bheil mo bheachd nas fheàrr no nas miosa na feadhainn eile, ach leis gur e beathaichean gu math iom-fhillte a th’ ann am mogalan seirbheis, cuidichidh grunn bheachdan le bhith gan tuigsinn nas fheàrr.
Bruidhnidh mi mun àrd-ùrlar dotCloud, a chaidh a thogail air còrr air ceud microservices agus a thug taic do mhìltean de thagraidhean so-ghiùlain. Mìnichidh mi na dùbhlain a bha romhainn ann a bhith ga leasachadh agus ga chur air bhog, agus mar a dh’ fhaodadh (no nach b’ urrainn) mogaill seirbheis cuideachadh.
Eachdraidh dotCloud
Tha mi air sgrìobhadh mu eachdraidh dotCloud agus na roghainnean ailtireachd airson an àrd-ùrlar seo, ach cha do bhruidhinn mi mòran mun ìre lìonra. Mura h-eil thu airson dàibheadh a-steach don leughadh mu dheidhinn dotCloud, seo an geàrr-chunntas gu h-aithghearr: is e àrd-ùrlar-mar-a-seirbheis PaaS a th’ ann a leigeas le luchd-ceannach raon farsaing de thagraidhean a ruith (Java, PHP, Python ...), le taic airson raon farsaing de dhàta seirbheisean (MongoDB, MySQL, Redis ...) agus sruth-obrach mar Heroku: Bidh thu a’ luchdachadh suas do chòd chun àrd-ùrlar, bidh e a’ togail ìomhaighean soithich agus gan cleachdadh.
Innsidh mi dhut mar a chaidh trafaic a stiùireadh chun àrd-ùrlar dotCloud. Chan ann air sgàth gu robh e gu sònraichte fionnar (ged a dh’ obraich an siostam gu math airson na h-ùine aige!), Ach gu sònraichte air sgàth le innealan ùr-nodha faodar dealbhadh mar seo a chuir an gnìomh gu furasta ann an ùine ghoirid le sgioba beag ma tha feum aca air dòigh air trafaic a chuir eadar buidheann. de microservices no dòrlach de thagraidhean. San dòigh seo, faodaidh tu coimeas a dhèanamh eadar na roghainnean: dè thachras ma leasaicheas tu a h-uile càil thu fhèin no ma chleachdas tu mogal seirbheis a tha ann mu thràth. Is e an roghainn àbhaisteach a dhèanamh leat fhèin no a cheannach.
Slighe trafaic airson tagraidhean aoigheachd
Faodaidh tagraidhean air dotCloud puingean crìochnachaidh HTTP agus TCP a nochdadh.
Puingean crìochnachaidh HTTP air a chur gu dinamach ri rèiteachadh brabhsair cothromachadh luchdan . Tha seo coltach ris na tha goireasan a’ dèanamh an-diugh ann an Kubernetes agus cothromachadh luchdan mar .
Bidh luchd-dèiligidh a’ ceangal ri puingean-crìochnachaidh HTTP tro raointean iomchaidh, cho fad ‘s a tha an t-ainm fearainn a’ comharrachadh luchd-cothromachaidh luchdan dotCloud. Chan eil dad sònraichte.
Puingean crìochnachaidh TCP co-cheangailte ri àireamh puirt, a thèid an uairsin chun a h-uile inneal san stac sin tro chaochladairean àrainneachd.
Faodaidh teachdaichean ceangal ri puingean crìochnachaidh TCP a’ cleachdadh an ainm aoigheachd iomchaidh (rudeigin mar gateway-X.dotcloud.com) agus àireamh puirt.
Bidh an t-ainm aoigheachd seo a’ fuasgladh don bhuidheann frithealaiche “nats” (nach eil càirdeach dha ), a bheir ceanglaichean TCP a-steach don t-soitheach cheart (no, a thaobh seirbheisean cothromach luchd, gu na soithichean ceart).
Ma tha thu eòlach air Kubernetes, is dòcha gum bi seo gad chuimhneachadh air Seirbheisean .
Cha robh seirbheisean co-ionann air an àrd-ùrlar dotCloud : Airson sìmplidh, chaidh cothrom fhaighinn air seirbheisean san aon dòigh taobh a-staigh agus taobh a-muigh an àrd-ùrlair.
Chaidh a h-uile càil a chuir air dòigh gu sìmplidh: is dòcha nach robh anns a’ chiad bhuileachadh de lìonraidhean slighe HTTP agus TCP ach beagan cheudan loidhnichean de Python gach fear. Algorithms sìmplidh (chanainn naive) a chaidh ùrachadh mar a dh’ fhàs an àrd-ùrlar agus mar a nochd riatanasan a bharrachd.
Cha robh feum air ath-leasachadh mòr air a' chòd a bha ann mar-thà. Gu sònraichte, is urrainn dhaibh an seòladh a gheibhear tro chaochladairean àrainneachd a chleachdadh gu dìreach.
Ciamar a tha seo eadar-dhealaichte bho mhogal seirbheis ùr-nodha?
Earranta faicsinneachd. Cha robh meatrach sam bith againn airson mogal slighe TCP idir. Nuair a thig e gu slighe HTTP, thug dreachan nas fhaide air adhart a-steach meatrach HTTP mionaideach le còdan mearachd agus amannan freagairt, ach bidh mogalan seirbheis ùr-nodha a’ dol eadhon nas fhaide, a’ toirt seachad amalachadh le siostaman cruinneachaidh meatrach mar Prometheus, mar eisimpleir.
Tha faicsinneachd cudromach chan ann a-mhàin bho shealladh obrachaidh (gus cuideachadh le duilgheadasan fhuasgladh), ach cuideachd nuair a bhios tu a’ leigeil a-mach feartan ùra. Tha e mu dheidhinn sàbhailte и .
Èifeachdas slighe cuideachd cuingealaichte. Ann am mogal slighe dotCloud, bha aig a h-uile trafaic ri dhol tro bhuidheann de nodan slighe sònraichte. Bha seo a’ ciallachadh a dh’ fhaodadh a bhith a’ dol thairis air grunn chrìochan AZ (Sòn ri fhaotainn) agus a’ meudachadh gu mòr latency. Tha cuimhne agam air còd fuasglaidh dhuilgheadasan a bha a’ dèanamh còrr air ceud ceist SQL air gach duilleag agus a’ fosgladh ceangal ùr ri frithealaiche SQL airson gach ceist. Nuair a bhios tu a’ ruith gu h-ionadail, bidh an duilleag a’ luchdachadh sa bhad, ach ann an dotCloud bheir e beagan dhiog airson a luchdachadh oir bidh gach ceangal TCP (agus ceist SQL às deidh sin) a’ toirt deichean de mhillean-thiogaidean. Anns a 'chùis shònraichte seo, dh' fhuasgail ceanglaichean leantainneach an duilgheadas.
Tha mogal seirbheis ùr-nodha nas fheàrr air dèiligeadh ri duilgheadasan mar sin. An toiseach, bidh iad a 'dèanamh cinnteach gu bheil ceanglaichean air an stiùireadh anns an stòr. Tha an sruth loidsigeach mar an ceudna: клиент → меш → сервис, ach a-nis tha am mogal ag obair gu h-ionadail agus chan ann air nodan iomallach, mar sin an ceangal клиент → меш ionadail agus gu math luath (microseconds an àite milliseconds).
Bidh mogalan seirbheis ùr-nodha cuideachd a’ cur an gnìomh algorithms cothromachaidh luchdan nas buige. Le bhith a’ cumail sùil air slàinte backends, faodaidh iad barrachd trafaic a chuir gu backends nas luaithe, a’ leantainn gu coileanadh iomlan nas fheàrr.
Tèarainteachd nas fheàrr cuideachd. Bha am mogal slighe dotCloud a’ ruith gu tur air EC2 Classic agus cha do chuir e a-steach trafaic (stèidhichte air a’ bharail ma chaidh aig cuideigin air sniffer a chuir air trafaic lìonra EC2, bha thu ann an trioblaid mhòr mu thràth). Bidh mogalan seirbheis ùr-nodha gu follaiseach a’ dìon ar trafaic gu lèir, mar eisimpleir, le dearbhadh TLS dha chèile agus crioptachadh às deidh sin.
A 'stiùireadh trafaig airson seirbheisean àrd-ùrlair
Ceart gu leòr, tha sinn air trafaic a dheasbad eadar tagraidhean, ach dè mu dheidhinn an àrd-ùrlar dotCloud fhèin?
Bha an àrd-ùrlar fhèin air a dhèanamh suas de mu cheud microservices le uallach airson diofar dhleastanasan. Ghabh cuid ri iarrtasan bho chàch, agus bha cuid nan luchd-obrach cùl-fhiosrachaidh a bha a’ ceangal ri seirbheisean eile ach nach do ghabh ri ceanglaichean iad fhèin. Ann an suidheachadh sam bith, feumaidh fios a bhith aig gach seirbheis air puingean crìochnachaidh nan seòlaidhean ris am feum e ceangal.
Faodaidh mòran de sheirbheisean àrd-ìre am mogal slighe a tha air a mhìneachadh gu h-àrd a chleachdadh. Gu dearbh, chaidh mòran de chòrr air ceud microservices dotCloud a chleachdadh mar thagraidhean cunbhalach air an àrd-ùrlar dotCloud fhèin. Ach bha feum aig àireamh bheag de sheirbheisean aig ìre ìosal (gu h-àraidh an fheadhainn a tha a’ cur an gnìomh a’ mhogal slighe seo) air rudeigin nas sìmplidh, le nas lugha de dh’ eisimeileachd (leis nach b’ urrainn dhaibh a bhith an urra riutha fhèin a bhith ag obair - an t-seann dhuilgheadas cearc is ugh).
Chaidh na seirbheisean ìre ìosal seo a bha deatamach airson misean a chleachdadh le bhith a’ ruith shoithichean gu dìreach air beagan phrìomh nodan. Anns a 'chùis seo, cha deach seirbheisean àrd-ùrlair àbhaisteach a chleachdadh: ceangail, clàr-ama agus ruitheadair. Ma tha thu airson coimeas a dhèanamh ri àrd-ùrlaran soithichean an latha an-diugh, tha e coltach ri bhith a’ ruith plèana smachd le docker run gu dìreach air na nodan, an àite a bhith a’ tiomnadh na h-obrach gu Kubernetes. Tha e gu math coltach ann am bun-bheachd , a tha e a' cleachdadh no nuair a bhios tu a’ togail brabhsair leis fhèin.
Chaidh na seirbheisean sin fhoillseachadh ann an dòigh shìmplidh agus amh: bha faidhle YAML a' liostadh an ainmean agus an seòlaidhean; agus bha aig gach neach-dèiligidh ri leth-bhreac den fhaidhle YAML seo a ghabhail airson a chleachdadh.
Air an aon làimh, tha e air leth earbsach leis nach eil feum air taic bho stòr iuchair / luach bhon taobh a-muigh leithid Zookeeper (cuimhnich, msaa no cha robh Consal ann aig an àm sin). Air an làimh eile, rinn e duilich seirbheisean a ghluasad. Gach uair a chaidh gluasad a dhèanamh, gheibheadh a h-uile neach-dèiligidh faidhle YAML ùraichte (agus is dòcha ath-thòiseachadh). Nach eil e glè chofhurtail!
Às deidh sin, thòisich sinn air sgeama ùr a chuir an gnìomh, far an robh gach neach-dèiligidh ceangailte ri frithealaiche progsaidh ionadail. An àite seòladh agus port, chan fheum e ach fios a bhith aige air àireamh port na seirbheis, agus ceangal troimhe localhost. Bidh an neach-ionaid ionadail a’ làimhseachadh a’ cheangail seo agus ga chuir air adhart chun fhìor fhrithealaiche. A-nis, nuair a ghluaiseas tu an backend gu inneal no sgèileadh eile, an àite a bhith ag ùrachadh a h-uile neach-dèiligidh, chan fheum thu ach na proxies ionadail sin ùrachadh; agus chan eil feum air ath-thòiseachadh tuilleadh.
(Bhathas an dùil cuideachd an trafaic a chuairteachadh ann an ceanglaichean TLS agus frithealaiche progsaidh eile a chuir air an taobh faighinn, a bharrachd air teisteanasan TLS a dhearbhadh às aonais com-pàirt na seirbheis faighinn, a tha air a rèiteachadh gus gabhail ri ceanglaichean a-mhàin air localhost. Barrachd air seo nas fhaide air adhart).
Tha seo glè choltach ri bho Airbnb, ach is e an eadar-dhealachadh mòr gu bheil SmartStack air a chuir an gnìomh agus air a chuir gu cinneasachadh, fhad ‘s a chaidh siostam slighe a-staigh dotCloud a chuir air ais nuair a thàinig dotCloud gu bhith na Docker.
Tha mi gu pearsanta den bheachd gu bheil SmartStack mar aon den fheadhainn a bha air thoiseach air siostaman mar Istio, Linkerd agus Consul Connect oir tha iad uile a’ leantainn an aon phàtran:
- Ruith neach-ionaid air gach nód.
- Bidh teachdaichean a’ ceangal ris an neach-ionaid.
- Bidh am plèana smachd ag ùrachadh rèiteachadh an neach-ionaid nuair a dh’ atharraicheas backends.
- ... prothaid!
Cur an gnìomh mogal seirbheis ùr-nodha
Nam feumadh sinn cliath den aon seòrsa a chuir an gnìomh an-diugh, dh’ fhaodadh sinn prionnsapalan co-chosmhail a chleachdadh. Mar eisimpleir, rèitich sòn DNS a-staigh le bhith a’ mapadh ainmean seirbheis gu seòlaidhean san àite 127.0.0.0/8. An uairsin ruith HAProxy air gach nód sa bhuidheann, a’ gabhail ri ceanglaichean aig gach seòladh seirbheis (san subnet sin 127.0.0.0/8) agus ath-stiùireadh/cothromachadh an luchd gu backends iomchaidh. Faodar smachd a chumail air rèiteachadh HAProxy , a’ toirt cothrom dhut fiosrachadh backend a stòradh ann an etcd no Consul agus gu fèin-obrachail a’ putadh rèiteachadh ùraichte gu HAProxy nuair a bhios feum air.
Seo gu ìre mhòr mar a tha Istio ag obair! Ach le beagan eadar-dhealachaidhean:
- Cleachdaidhean an àite HAProxy.
- A’ stòradh rèiteachadh backend tro Kubernetes API an àite etcd no Consul.
- Thathas a’ toirt seachad seòlaidhean air seirbheisean air an subnet a-staigh (seòlaidhean Kubernetes ClusterIP) an àite 127.0.0.0/8.
- Tha pàirt a bharrachd aige (Citadel) gus dearbhadh TLS a chuir ris eadar an neach-dèiligidh agus na frithealaichean.
- A’ toirt taic do fheartan ùra leithid briseadh cuairteachaidh, lorg sgaoilte, cleachdadh canary, msaa.
Bheir sinn sùil aithghearr air cuid de na h-eadar-dhealachaidhean.
Tosgaire Proxy
Chaidh Envoy Proxy a sgrìobhadh le Lyft [co-fharpaiseach Uber anns a’ mhargaidh tacsaidhean - timcheall air. lain]. Tha e coltach ann an iomadh dòigh ri proxies eile (me HAProxy, Nginx, Traefik ...), ach sgrìobh Lyft an cuid aca leis gu robh feum aca air feartan nach robh aig luchd-ionaid eile, agus bha e coltach gu robh e na bu ghlice fear ùr a dhèanamh seach a bhith a’ leudachadh an tè a th’ ann.
Faodar teachdaire a chleachdadh leis fhèin. Ma tha seirbheis shònraichte agam a dh’ fheumas ceangal ri seirbheisean eile, is urrainn dhomh a rèiteachadh gus ceangal ri Tosgaire, agus an uairsin rèiteachadh agus ath-dhealbhadh gu dinamach Tosgaire le suidheachadh sheirbheisean eile, fhad ‘s a tha mi a’ faighinn tòrr gnìomh a bharrachd math, leithid faicsinneachd. An àite leabharlann teachdaiche àbhaisteach no a bhith a’ stealladh lorgan gairm a-steach don chòd, bidh sinn a’ cur trafaic gu Tosgaire, agus bidh e a’ cruinneachadh mheatairean dhuinn.
Ach tha Envoy cuideachd comasach air obrachadh mar plèana dàta (plèana dàta) airson mogal na seirbheis. Tha seo a’ ciallachadh gu bheil Envoy a-nis air a rèiteachadh airson a’ mhogal seirbheis seo plèana smachd (plèana smachd).
Plèana smachd
Airson an itealan smachd, tha Istio an urra ri Kubernetes API. Chan eil seo gu math eadar-dhealaichte bho bhith a’ cleachdadh confd, a tha an urra ri etcd no Consal gus an seata iuchraichean fhaicinn anns a’ bhùth dàta. Bidh Istio a’ cleachdadh an Kubernetes API gus seata de ghoireasan Kubernetes fhaicinn.
Eadar seo agus an uairsin: Bha seo feumail dhomh gu pearsanta a tha a' leughadh:
Tha an Kubernetes API Server na “fhrithealaiche balbh” a tha a ’tabhann stòradh, dreach, dearbhadh, ùrachadh, agus semantics airson goireasan API.
Tha Istio air a dhealbhadh gus obrachadh le Kubernetes; agus ma tha thu airson a chleachdadh taobh a-muigh Kubernetes, feumaidh tu eisimpleir a ruith den fhrithealaiche Kubernetes API (agus an t-seirbheis cuideachaidh msaa).
Seòlaidhean seirbheis
Tha Istio an urra ri seòlaidhean ClusterIP a bhios Kubernetes a’ riarachadh, gus am faigh seirbheisean Istio seòladh a-staigh (chan ann san raon 127.0.0.0/8).
Tha trafaic gu seòladh ClusterIP airson seirbheis sònraichte ann am buidheann Kubernetes às aonais Istio air a ghlacadh le kube-proxy agus air a chuir gu backend an neach-ionaid sin. Ma tha ùidh agad anns an fhiosrachadh theicnigeach, bidh kube-proxy a’ stèidheachadh riaghailtean iptables (no luchd-cothromachaidh luchdan IPVS, a rèir mar a tha e air a rèiteachadh) gus seòlaidhean IP ceann-uidhe nan ceanglaichean a tha a’ dol gu seòladh ClusterIP ath-sgrìobhadh.
Aon uair ‘s gu bheil Istio air a chuir a-steach air cruinneachadh Kubernetes, chan atharraich dad gus am bi e air a chomasachadh gu sònraichte airson neach-ceannach sònraichte, no eadhon an t-àite ainm gu lèir, le bhith a’ toirt a-steach soitheach sidecar a-steach do phònaichean àbhaisteach. Bidh an soitheach seo a’ tionndadh eisimpleir de Thosgaire agus a’ stèidheachadh seata de riaghailtean iptables gus casg a chuir air trafaic a’ dol gu seirbheisean eile agus an trafaic sin ath-stiùireadh gu Tosgaire.
Nuair a thèid am filleadh a-steach le Kubernetes DNS, tha seo a’ ciallachadh gum faod an còd againn ceangal a dhèanamh le ainm seirbheis agus tha a h-uile dad “dìreach ag obair.” Ann am faclan eile, tha an còd againn a’ toirt a-mach ceistean mar http://api/v1/users/4242an uairsin api fuasgladh iarrtas airson 10.97.105.48, cuiridh na riaghailtean iptables casg air ceanglaichean bho 10.97.105.48 agus cuiridh iad air adhart iad chun neach-ionaid ionadail Envoy, agus cuiridh an neach-ionaid ionadail seo an t-iarrtas air adhart chun an API backend fhèin. Phew!
Freiceadan a bharrachd
Bidh Istio cuideachd a’ toirt seachad crioptachadh agus dearbhadh deireadh-gu-deireadh tro mTLS (TLS co-phàirteach). Co-phàirt ris an canar Citadel.
Tha co-phàirt ann cuideachd Measgadair, a dh’ fhaodas an Tosgaire iarraidh gach fear iarrtas airson co-dhùnadh sònraichte a dhèanamh mun iarrtas sin a rèir diofar fhactaran leithid bannan-cinn, backend load, msaa ... (na gabh dragh: tha iomadh dòigh ann gus Mixer a chumail a’ dol, agus eadhon ged a thuiteas e, cumaidh an Tosgaire ag obair gu math mar neach-ionaid).
Agus, gu dearbh, thug sinn iomradh air faicsinneachd: bidh an Tosgaire a’ cruinneachadh tòrr mheatairean fhad ‘s a tha iad a’ toirt seachad lorg sgaoilte. Ann an ailtireachd microservices, ma dh’ fheumas aon iarrtas API a dhol tro mhicro-sheirbheisean A, B, C, agus D, an uairsin nuair a thèid thu a-steach, cuiridh lorg sgaoilte aithnichear sònraichte ris an iarrtas agus stòraichidh e an aithnichear sin thairis air fo-iarrtasan gu na microservices sin uile, a’ ceadachadh a h-uile fios co-cheangailte ri bhith air a ghlacadh, dàil, msaa.
Leasaich no ceannaich
Tha cliù aig Istio airson a bhith iom-fhillte. An coimeas ri sin, tha togail a ’mhogal slighe a mhìnich mi aig toiseach na dreuchd seo gu math sìmplidh a’ cleachdadh innealan a th ’ann. Mar sin, a bheil e ciallach do mhogal seirbheis fhèin a chruthachadh na àite?
Ma tha feumalachdan beaga againn (chan eil feum againn air faicsinneachd, inneal-brisidh agus seòlaidhean eile), thig smuaintean gu bhith a’ leasachadh ar n-inneal fhèin. Ach ma chleachdas sinn Kubernetes, is dòcha nach bi feum air eadhon leis gu bheil Kubernetes mu thràth a’ toirt seachad innealan bunaiteach airson lorg seirbheis agus cothromachadh luchdan.
Ach ma tha riatanasan adhartach againn, tha e coltach gu bheil “ceannach” mogal seirbheis na roghainn fada nas fheàrr. (Chan e “ceannach” a tha seo an-còmhnaidh oir tha Istio na stòr fosgailte, ach feumaidh sinn fhathast ùine innleadaireachd a thasgadh airson a thuigsinn, a chleachdadh agus a riaghladh.)
Am bu chòir dhomh Istio, Linkerd no Consul Connect a thaghadh?
Gu ruige seo cha do bhruidhinn sinn ach mu Istio, ach chan e seo an aon mhogal seirbheis. Roghainn mòr-chòrdte - , agus tha tuilleadh ann .
Dè a thaghas tu?
Gu h-onarach, chan eil fhios agam. Aig an àm seo chan eil mi gam mheas fhèin comasach gu leòr airson a’ cheist seo a fhreagairt. Tha beagan ann le coimeas de na h-innealan sin agus eadhon .
Is e aon dòigh gealltanach a bhith a’ cleachdadh inneal mar . Bidh e a’ buileachadh còmhdach tarraing-às gus na APIan a tha fosgailte le mogalan seirbheis a dhèanamh nas sìmplidhe agus aonachadh. An àite a bhith ag ionnsachadh na APIan sònraichte (agus, nam bheachd-sa, an ìre mhath iom-fhillte) de dhiofar mogalan seirbheis, is urrainn dhuinn na togalaichean nas sìmplidh aig SuperGloo a chleachdadh - agus atharrachadh gu furasta bho aon gu fear eile, mar gum biodh cruth rèiteachaidh eadar-mheadhanach againn a’ toirt cunntas air eadar-aghaidh HTTP agus backends comasach. de bhith a’ gineadh an fhìor rèiteachadh airson Nginx, HAProxy, Traefik, Apache ...
Tha mi air beagan deasbaid a dhèanamh le Istio agus SuperGloo, agus anns an ath artaigil tha mi airson sealltainn mar a chuireas mi Istio no Linkerd ri buidheann a tha ann mu thràth a’ cleachdadh SuperGloo, agus mar a gheibh an tè mu dheireadh an obair, is e sin, leigidh e leat gluasad bho aon mhogal seirbheis gu fear eile gun a bhith ag ath-sgrìobhadh rèiteachaidhean.
Source: www.habr.com