Hello, Habr! Ipinakita ko sa iyong pansin ang isang pagsasalin ng artikulo "Serbisyo ng mesh data plane vs control plane" may-akda Matt Klein.

Sa pagkakataong ito, "nais at isinalin" ko ang paglalarawan ng parehong bahagi ng service mesh, data plane at control plane. Ang paglalarawang ito ay tila sa akin ang pinakanaiintindihan at kawili-wili, at ang pinakamahalaga ay humahantong sa pag-unawa sa "Kailangan ba talaga?"

Habang ang ideya ng isang "Service mesh" ay naging lalong popular sa nakalipas na dalawang taon (Orihinal na artikulo Oktubre 10, 2017) at ang bilang ng mga kalahok sa espasyo ay tumaas, nakita ko ang isang katapat na pagtaas ng kalituhan sa buong tech na komunidad tungkol sa kung paano ihambing at ihambing ang iba't ibang mga solusyon.

Ang sitwasyon ay pinakamahusay na buod ng mga sumusunod na serye ng mga tweet na isinulat ko noong Hulyo:

Pagkalito ng mesh ng serbisyo #1: Linkerd ~ = Nginx ~ = Haproxy ~ = Envoy. Wala sa kanila ang katumbas ni Istio. Istio ay isang bagay na ganap na naiiba. 1 /

Ang una ay simpleng mga eroplano ng data. Sa kanilang sarili, wala silang ginagawa. Dapat ay nasa mood sila para sa isang bagay na higit pa. 2/

Ang Istio ay isang halimbawa ng isang control plane na nagbubuklod sa mga bahagi. Ito ay isa pang layer. /tapos

Ang mga nakaraang tweet ay nagbanggit ng ilang magkakaibang proyekto (Linkerd, NGINX, HAProxy, Envoy, at Istio), ngunit higit na mahalaga ay ipinakilala ang mga pangkalahatang konsepto ng data plane, service mesh, at control plane. Sa post na ito, kukuha ako ng isang hakbang pabalik at pag-uusapan kung ano ang ibig kong sabihin sa mga terminong "data plane" at "control plane" sa napakataas na antas, at pagkatapos ay pag-uusapan kung paano nalalapat ang mga termino sa mga proyektong binanggit sa mga tweet.

Ano ba talaga ang service mesh?

Larawan 1: Pangkalahatang-ideya ng mesh ng serbisyo

Figure 1 inilalarawan ang konsepto ng isang service mesh sa pinakapangunahing antas nito. Mayroong apat na service cluster (AD). Ang bawat instance ng serbisyo ay nauugnay sa isang lokal na proxy server. Ang lahat ng trapiko sa network (HTTP, REST, gRPC, Redis, atbp.) mula sa isang instance ng application ay ipinapasa sa isang lokal na proxy patungo sa naaangkop na mga panlabas na cluster ng serbisyo. Sa ganitong paraan, hindi alam ng instance ng application ang network sa kabuuan at alam lang nito ang lokal na proxy nito. Sa epekto, ang network ng distributed system ay inalis mula sa serbisyo.

Data plane

Sa isang service mesh, ang isang proxy server na matatagpuan sa lokal para sa application ay nagsasagawa ng mga sumusunod na gawain:

• Pagtuklas ng serbisyo. Anong mga serbisyo/aplikasyon ang magagamit para sa iyong aplikasyon?
• Pagsusuri ng kalusugan. Ang mga instance ng serbisyo ba na ibinalik ng service discovery ay malusog at handang tanggapin ang trapiko sa network? Maaaring kabilang dito ang parehong aktibo (hal. response/healthcheck) at passive (hal. paggamit ng 3 magkakasunod na 5xx error bilang indikasyon ng isang hindi malusog na estado ng serbisyo) na pagsusuri sa kalusugan.
• Pagruruta. Kapag tumatanggap ng kahilingan sa "/foo" mula sa isang serbisyo ng REST, sa aling cluster ng serbisyo dapat ipadala ang kahilingan?
• Pagbalanse ng load. Sa sandaling napili ang isang cluster ng serbisyo sa panahon ng pagruruta, sa aling instance ng serbisyo dapat ipadala ang kahilingan? Sa anong timeout? Sa anong mga setting ng circuit breaking? Kung nabigo ang kahilingan, dapat ba itong subukang muli?
• Authentication at awtorisasyon. Para sa mga papasok na kahilingan, maaari bang tukuyin/awtorisahan ang serbisyo sa pagtawag gamit ang mTLS o iba pang mekanismo? Kung ito ay kinikilala/pinahintulutan, pinapayagan bang tawagan ang hiniling na operasyon (endpoint) sa serbisyo o dapat bang ibalik ang isang hindi napatotohanang tugon?
• Pagmamasid. Ang mga detalyadong istatistika, log/log, at distributed trace data ay dapat mabuo para sa bawat kahilingan upang maunawaan ng mga operator ang mga isyu sa distributed na daloy ng trapiko at pag-debug kapag lumitaw ang mga ito.

Ang data plane ay may pananagutan para sa lahat ng nakaraang mga punto sa mesh ng serbisyo. Sa katunayan, ang proxy na lokal sa serbisyo (sidecar) ay ang data plane. Sa madaling salita, ang data plane ay responsable para sa kondisyon na pagsasahimpapawid, pagpapasa, at pagsubaybay sa bawat network packet na ipinadala sa o mula sa isang serbisyo.

Ang control plane

Ang abstraction ng network na ibinibigay ng isang lokal na proxy sa data plane ay mahiwagang(?). Gayunpaman, paano talaga alam ng proxy ang tungkol sa rutang "/foo" patungo sa serbisyo B? Paano magagamit ang data ng pagtuklas ng serbisyo na na-populate ng mga kahilingan sa proxy? Paano naka-configure ang mga parameter para sa load balancing, timeout, circuit breaking, atbp.? Paano ka magde-deploy ng application gamit ang blue/green na paraan o ang magandang paraan ng paglipat ng trapiko? Sino ang nagko-configure ng system-wide authentication at mga setting ng awtorisasyon?

Ang lahat ng mga item sa itaas ay nasa ilalim ng kontrol ng control plane ng service mesh. Ang control plane ay kumukuha ng isang set ng mga nakahiwalay na stateless proxy at ginagawa ang mga ito sa isang distributed system.

Sa tingin ko, ang dahilan kung bakit maraming mga technologist ang nakakalito sa magkahiwalay na konsepto ng data plane at control plane ay dahil sa karamihan ng mga tao ang data plane ay pamilyar habang ang control plane ay dayuhan/hindi naiintindihan. Matagal na kaming nagtatrabaho sa mga pisikal na network router at switch. Naiintindihan namin na ang mga packet/kahilingan ay kailangang pumunta mula sa punto A hanggang sa punto B at na maaari naming gamitin ang hardware at software upang gawin ito. Ang bagong henerasyon ng mga software proxy ay simpleng mga magarbong bersyon ng mga tool na matagal na naming ginagamit.

Figure 2: Human control plane

Gayunpaman, matagal na kaming gumagamit ng mga control plane, kahit na karamihan sa mga network operator ay maaaring hindi iugnay ang bahaging ito ng system sa anumang bahagi ng teknolohiya. Ang dahilan ay simple:
Karamihan sa mga control plane na ginagamit ngayon ay... tayo.

Sa figure 2 ay nagpapakita ng tinatawag kong “Human control plane.” Sa ganitong uri ng pag-deploy, na karaniwan pa rin, ang isang malamang na masungit na tao na operator ay lumilikha ng mga static na pagsasaayos - posibleng sa pamamagitan ng mga script - at i-deploy ang mga ito sa pamamagitan ng ilang espesyal na proseso sa lahat ng mga proxy. Magsisimulang gamitin ng mga proxy ang configuration na ito at simulan ang pagproseso ng data plane gamit ang mga na-update na setting.

Figure 3: Advanced na service mesh control plane

Sa figure 3 ipinapakita ang "extended" control plane ng service mesh. Binubuo ito ng mga sumusunod na bahagi:

• Ang tao: Mayroon pa ring isang tao (sana hindi gaanong galit) na gumagawa ng mataas na antas ng mga desisyon tungkol sa buong sistema sa kabuuan.
• Kontrolin ang UI ng eroplano: Nakikipag-ugnayan ang isang tao sa ilang uri ng user interface upang kontrolin ang system. Ito ay maaaring isang web portal, isang command line application (CLI), o iba pang interface. Gamit ang user interface, may access ang operator sa mga parameter ng pagsasaayos ng pandaigdigang system tulad ng:
  • Kontrol sa deployment, asul/berde at/o unti-unting paglipat ng trapiko
  • Mga Opsyon sa Pagpapatunay at Awtorisasyon
  • Mga detalye ng routing table, halimbawa kapag humiling ang application A ng impormasyon tungkol sa "/foo" kung ano ang mangyayari
  • Mga setting ng load balancer, gaya ng mga timeout, rettry, circuit breaking settings, atbp.
• Workload scheduler: Ang mga serbisyo ay pinapatakbo sa imprastraktura sa pamamagitan ng ilang uri ng sistema ng pag-iiskedyul/orkestra, gaya ng Kubernetes o Nomad. Responsable ang scheduler sa pag-load ng serbisyo kasama ng lokal na proxy nito.
• Pagtuklas ng serbisyo. Kapag nagsimula at huminto ang scheduler ng mga instance ng serbisyo, iniuulat nito ang status ng kalusugan sa sistema ng pagtuklas ng serbisyo.
• Mga sidecar proxy configuration API : Ang mga lokal na proxy ay dynamic na kumukuha ng estado mula sa iba't ibang bahagi ng system gamit ang isang pare-parehong modelo sa huli nang walang interbensyon ng operator. Ang buong system, na binubuo ng lahat ng kasalukuyang tumatakbong mga instance ng serbisyo at mga lokal na proxy server, sa huli ay nag-uugnay sa isang ecosystem. Ang unibersal na data plane API ng Envoy ay isang halimbawa kung paano ito gumagana sa pagsasanay.

Sa pangkalahatan, ang layunin ng control plane ay itakda ang patakaran na sa huli ay tatanggapin ng data plane. Ang mga mas advanced na control plane ay mag-aalis ng mas maraming bahagi ng ilang system mula sa operator at mangangailangan ng mas kaunting manu-manong operasyon, basta't gumagana ang mga ito nang tama!...

Data plane at control plane. Buod ng data plane vs. control plane

• Serbisyo ng mesh data plane: Nakakaapekto sa bawat packet/request sa system. Responsable para sa pagtuklas ng aplikasyon/serbisyo, pagsusuri sa kalusugan, pagruruta, pagbabalanse ng load, pagpapatotoo/awtorisasyon, at kakayahang maobserbahan.
• Serbisyo ng mesh control plane: Nagbibigay ng patakaran at pagsasaayos para sa lahat ng tumatakbong data plane sa loob ng network ng serbisyo. Hindi hinahawakan ang anumang mga pakete/kahilingan sa system. Ginagawa ng control plane ang lahat ng data plane sa isang distributed system.

Kasalukuyang landscape ng proyekto

Matapos maunawaan ang paliwanag sa itaas, tingnan natin ang kasalukuyang estado ng proyekto ng mesh ng serbisyo.

• Mga eroplano ng data: Linkerd, NGINX, HAProxy, Envoy, Traefik
• Kontrolin ang mga eroplano: Istio, Nelson, SmartStack

Sa halip na pumunta sa isang malalim na pagsusuri ng bawat isa sa mga solusyon sa itaas, tatalakayin ko sandali ang ilan sa mga puntong pinaniniwalaan kong nagdudulot ng malaking kalituhan sa ecosystem sa ngayon.

Ang Linkerd ay isa sa mga unang data plane proxy server para sa service mesh noong unang bahagi ng 2016 at nakagawa ng isang kamangha-manghang trabaho sa pagpapataas ng kamalayan at atensyon sa modelo ng disenyo ng mesh ng serbisyo. Mga 6 na buwan pagkatapos noon, sumali si Envoy sa Linkerd (bagaman kasama niya si Lyft mula noong huling bahagi ng 2015). Ang Linkerd at Envoy ay ang dalawang proyekto na kadalasang binabanggit kapag tinatalakay ang mga service meshes.

Inanunsyo ang Istio noong Mayo 2017. Ang mga layunin ng proyekto ng Istio ay halos kapareho sa pinalawak na control plane na ipinakita sa figure 3. Ang Envoy para sa Istio ay ang default na proxy. Kaya, ang Istio ay ang control plane, at ang Envoy ay ang data plane. Sa maikling panahon, nakabuo si Istio ng maraming kaguluhan, at nagsimulang magsama ang iba pang data plane bilang kapalit ng Envoy (parehong ipinakita ng Linkerd at NGINX ang pagsasama sa Istio). Ang katotohanan na ang iba't ibang data plane ay maaaring gamitin sa loob ng parehong control plane ay nangangahulugan na ang control plane at ang data plane ay hindi kinakailangang mahigpit na pinagsama. Ang isang API tulad ng generic na data plane API ng Envoy ay maaaring bumuo ng isang tulay sa pagitan ng dalawang bahagi ng system.

Tumutulong sina Nelson at SmartStack na higit na mailarawan ang paghihiwalay ng control plane at ng data plane. Ginagamit ni Nelson ang Envoy bilang proxy nito at bumuo ng maaasahang control plane para sa service mesh batay sa HashiCorp stack, i.e. Nomad, atbp. Ang SmartStack ay marahil ang una sa isang bagong wave ng mga service meshes. Bumubuo ang SmartStack ng control plane sa paligid ng HAProxy o NGINX, na nagpapakita ng kakayahang i-decouple ang control plane mula sa service mesh mula sa data plane.

Ang arkitektura ng microservice na may mesh ng serbisyo ay nakakakuha ng higit at higit na pansin (tama!), at parami nang parami ang mga proyekto at vendor ay nagsisimulang gumana sa direksyong ito. Sa susunod na ilang taon, makikita natin ang maraming pagbabago sa parehong data plane at control plane, pati na rin ang karagdagang paghahalo ng iba't ibang bahagi. Sa huli, ang arkitektura ng microservice ay dapat maging mas transparent at mahiwagang (?) para sa operator.
Sana ay unti-unting nababawasan ang inis.

Mga pangunahing takeaway

• Ang isang service mesh ay binubuo ng dalawang magkaibang bahagi: ang data plane at ang control plane. Ang parehong mga bahagi ay kinakailangan, at kung wala ang mga ito ang sistema ay hindi gagana.
• Pamilyar ang lahat sa control plane, at sa puntong ito, maaaring ikaw ang control plane!
• Ang lahat ng data plane ay nakikipagkumpitensya sa isa't isa sa mga feature, performance, configurability, at extensibility.
• Ang lahat ng control plane ay nakikipagkumpitensya sa isa't isa sa mga feature, configurability, extensibility, at kadalian ng paggamit.
• Maaaring maglaman ang isang control plane ng mga tamang abstraction at API para magamit ang maraming data plane.

Pinagmulan: www.habr.com