{"id":37030,"date":"2019-10-31T22:15:23","date_gmt":"2019-10-31T19:15:23","guid":{"rendered":"https:\/\/prohoster.info\/blog\/servisnaya-set-ploskost-dannyh-i-ploskosti-upravleniya-service-mesh-data-plane-vs-control-plane\/"},"modified":"2019-10-31T22:15:23","modified_gmt":"2019-10-31T19:15:23","slug":"servisnaya-set-ploskost-dannyh-i-ploskosti-upravleniya-service-mesh-data-plane-vs-control-plane","status":"publish","type":"post","link":"https:\/\/prohoster.info\/sk\/blog\/administrirovanie\/servisnaya-set-ploskost-dannyh-i-ploskosti-upravleniya-service-mesh-data-plane-vs-control-plane","title":{"rendered":"Slu\u017eobn\u00e1 sie\u0165, \u201ePlocha \u00fadajov\u201c a \u201ePlocha riadenia\u201c (Service mesh data plane vs. control plane)","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p>Ahoj, Habr! Predstavujem v\u00e1m preklad \u010dl\u00e1nku <noindex><a rel=\"nofollow\" href=\"https:\/\/blog.envoyproxy.io\/service-mesh-data-plane-vs-control-plane-2774e720f7fc\">\u201eService mesh data plane vs control plane\u201c<\/a><\/noindex> autora <b>Matt Klein<\/b>.<\/p>\n<p><img decoding=\"async\" alt=\"Slu\u017eobn\u00e1 sie\u0165, \u201ePlocha \u00fadajov\u201c a \u201ePlocha riadenia\u201c (Service mesh data plane vs. control plane)\" src=\"\/wp-content\/uploads\/2019\/08\/487456689eb832f9e3845966cb0d85d4.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nTentoraz som si \u201ezapotreboval a prelo\u017eil\u201c popis oboch komponentov service mesh, plochy \u00fadajov a plochy riadenia. Tento popis mi pri\u0161iel najzrozumite\u013enej\u0161\u00ed a najzauj\u00edmavej\u0161\u00ed a hlavne priviedol k ot\u00e1zke \u201eJe to v\u00f4bec potrebn\u00e9?\u201c<\/p>\n<p>Ke\u010f\u017ee sa n\u00e1pad \u201eSlu\u017eobnej siete (Service mesh)\u201c st\u00e1va \u010doraz popul\u00e1rnej\u0161\u00edm posledn\u00e9 dva roky (P\u00f4vodn\u00fd \u010dl\u00e1nok z 10. okt\u00f3bra 2017), a po\u010det \u00fa\u010dastn\u00edkov v tomto priestore sa zv\u00fd\u0161il, videl som \u00famern\u00fd rast zm\u00e4tku v celom technickom spolo\u010denstve oh\u013eadom toho, ako porovn\u00e1va\u0165 a kontrastova\u0165 r\u00f4zne rie\u0161enia.<br \/>\n<noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><br \/>\nSitu\u00e1ciu najlep\u0161ie opisuj\u00fa nasleduj\u00face s\u00e9rie tweetov, ktor\u00e9 som nap\u00edsal v j\u00fali:<\/p>\n<blockquote><p>Zamie\u0148anie so slu\u017eobnou sie\u0165ou (service mesh) \u010d. 1: Linkerd ~ = Nginx ~ = Haproxy ~ = Envoy. \u017diadny z nich nie je rovn\u00fd Istio. Istio je \u00faplne nie\u010do in\u00e9. 1 \/<\/p><\/blockquote>\n<blockquote><p>Prv\u00e9 s\u00fa len plochy \u00fadajov (data planes). Sam\u00e9 o sebe ni\u010d nerobia. Musia by\u0165 nastaven\u00e9 na nie\u010do v\u00e4\u010d\u0161ie. 2 \/<\/p><\/blockquote>\n<blockquote><p>Istio je pr\u00edklad plochy riadenia (control plane), ktor\u00e1 sp\u00e1ja \u010dasti dohromady. To je in\u00e1 vrstva. \/koniec<\/p><\/blockquote>\n<p>V predch\u00e1dzaj\u00facich tweetoch sa spom\u00ednaj\u00fa nieko\u013eko r\u00f4znych projektov (Linkerd, NGINX, HAProxy, Envoy a Istio), ale, \u010do je d\u00f4le\u017eitej\u0161ie, zav\u00e1dzaj\u00fa sa spolo\u010dn\u00e9 pojmy plochy \u00fadajov (data plane), slu\u017eobnej siete (service mesh) a plochy riadenia (control plane). V tomto pr\u00edspevku urob\u00edm krok sp\u00e4\u0165 a poviem, \u010do m\u00e1m na mysli pod pojmami \u201eplocha \u00fadajov (data plane)\u201c a \u201eplocha riadenia (control plane)\u201c na ve\u013emi vysokej \u00farovni, a potom poviem, ako sa pojmy t\u00fdkaj\u00fa projektov zmienen\u00fdch v tweetoch.<\/p>\n<h1>\u010co je vlastne slu\u017eobn\u00e1 sie\u0165 (What is a service mesh, really)?<\/h1>\n<p>\n<img decoding=\"async\" alt=\"Slu\u017eobn\u00e1 sie\u0165, \u201ePlocha \u00fadajov\u201c a \u201ePlocha riadenia\u201c (Service mesh data plane vs. control plane)\" src=\"\/wp-content\/uploads\/2019\/08\/63c195aa9bcb7080f6924cecbff0fbc1.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<b>Obr\u00e1zok 1: Preh\u013ead slu\u017eobnej siete (Service mesh overview)<\/b><\/p>\n<p><b>Obr\u00e1zok 1<\/b> ilustruje koncept slu\u017eobnej siete (service mesh) na najz\u00e1kladnej\u0161ej \u00farovni. Existuj\u00fa \u0161tyri slu\u017eobn\u00e9 klastre (A-D). Ka\u017ed\u00fd pr\u00edklad slu\u017eby je spojen\u00fd s lok\u00e1lnym proxy serverom. Cel\u00fd sie\u0165ov\u00fd prenos (HTTP, REST, gRPC, Redis at\u010f.) z jednotliv\u00e9ho pr\u00edkladu aplik\u00e1cie prech\u00e1dza cez lok\u00e1lny proxy server do pr\u00edslu\u0161n\u00fdch extern\u00fdch slu\u017eobn\u00fdch klastrov. Takto pr\u00edklad aplik\u00e1cie nevie o celej sieti a vie len o svojom lok\u00e1lnom proxy. V skuto\u010dnosti bola sie\u0165 distribuovan\u00e9ho syst\u00e9mu odstr\u00e1nen\u00e1 od slu\u017eby.<\/p>\n<h1>Plocha \u00fadajov (Data plane)<\/h1>\n<p>\nV servisnej sieti (service mesh) proxy server, umiestnen\u00fd lok\u00e1lne pre aplik\u00e1ciu, vykon\u00e1va nasleduj\u00face \u00falohy:<\/p>\n<ul>\n<li> <b>Objavovanie slu\u017eieb (Service discovery)<\/b>. Ak\u00e9 slu\u017eby\/aplik\u00e1cie s\u00fa dostupn\u00e9 pre va\u0161u aplik\u00e1ciu?<\/li>\n<li><b>Kontrola zdravotn\u00e9ho stavu (Health checking)<\/b>. S\u00fa in\u0161tancie slu\u017eieb, ktor\u00e9 vr\u00e1tilo objavovanie slu\u017eieb (service discovery), funk\u010dn\u00e9 a pripraven\u00e9 prij\u00edma\u0165 sie\u0165ov\u00fa prev\u00e1dzku? To m\u00f4\u017ee zah\u0155\u0148a\u0165 akt\u00edvne (napr\u00edklad kontrola odpovede \/ healthcheck) aj pas\u00edvne (napr\u00edklad s pou\u017eit\u00edm 3 po sebe id\u00facich 5xx ch\u00fdb ako indik\u00e1cie nezdrav\u00e9ho stavu slu\u017eby) overovanie funk\u010dnosti. <\/li>\n<li><b>Smerovanie (Routing)<\/b>Ke\u010f dostaneme od slu\u017eby REST po\u017eiadavku na &#171;\\\/foo&#187;, do ktor\u00e9ho servisn\u00e9ho klastra by sa mala po\u017eiadavka posla\u0165? <\/li>\n<li> <b>Z\u00e1\u0165a\u017eov\u00e9 vyv\u00e1\u017eenie (Load balancing)<\/b>. Po v\u00fdbere klastru slu\u017eby po\u010das smerovania, do ktorej in\u0161tancie slu\u017eby by mala by\u0165 po\u017eiadavka odoslan\u00e1? S ak\u00fdm timeoutom? S ak\u00fdmi nastaveniami preru\u0161enia obvodu (circuit breaking)? Ak po\u017eiadavka zlyhala, mala by sa opakova\u0165?<\/li>\n<li> <b>Autentifik\u00e1cia a autoriz\u00e1cia (Authentication and authorization)<\/b>. Pre prich\u00e1dzaj\u00face po\u017eiadavky m\u00f4\u017ee by\u0165 volaj\u00faca slu\u017eba kryptograficky identifikovan\u00e1\/autoriza\u010dn\u00e1 pomocou mTLS alebo in\u00e9ho mechanizmu? Ak je identifikovan\u00e1\/autoriza\u010dn\u00e1, je jej povolen\u00e9 vykon\u00e1va\u0165 po\u017eadovan\u00fa oper\u00e1ciu (endpoint) v slu\u017ebe, alebo by mala by\u0165 vr\u00e1ten\u00e1 neautentifikovan\u00e1 odpove\u010f?<\/li>\n<li> <b>Pozorovate\u013enos\u0165 (Observability)<\/b>. Pre ka\u017ed\u00fa po\u017eiadavku musia by\u0165 generovan\u00e9 podrobn\u00e9 \u0161tatistiky, z\u00e1znamy a \u00fadaje distribuovan\u00e9ho trasovania, aby prev\u00e1dzkovatelia mohli porozumie\u0165 distribuovan\u00e9mu toku prev\u00e1dzky a probl\u00e9mom s laden\u00edm, ke\u010f sa vyskytn\u00fa.<\/li>\n<\/ul>\n<p>\nZa v\u0161etky predch\u00e1dzaj\u00face body v servisnej sieti (service mesh) zodpoved\u00e1 d\u00e1tov\u00e1 rovina (data plane). V podstate, lok\u00e1lny pre slu\u017ebu (sidecar) proxy je d\u00e1tov\u00e1 rovina (data plane). In\u00fdmi slovami, d\u00e1tov\u00e1 rovina (data plane) zodpoved\u00e1 za podmienen\u00fa transl\u00e1ciu, prenos a sledovanie ka\u017ed\u00e9ho sie\u0165ov\u00e9ho paketu, ktor\u00fd je poslan\u00fd do slu\u017eby alebo z nej.<\/p>\n<h1>Rovina riadenia (The control plane)<\/h1>\n<p>\nSie\u0165ov\u00e1 abstrakcia poskytovan\u00e1 lok\u00e1lnym proxy v d\u00e1tovej rovine (data plane) je magick\u00e1 (?). Napriek tomu, ako sa proxy server skuto\u010dne dozvie o trase &#171;\\\/foo&#187; k slu\u017ebe B? Ako m\u00f4\u017eu by\u0165 \u00fadaje o objavovan\u00ed slu\u017eieb (service discovery), ktor\u00e9 s\u00fa vyplnen\u00e9 proxy po\u017eiadavkami, vyu\u017eit\u00e9? Ako s\u00fa nastaven\u00e9 parametre vyv\u00e1\u017eenia za\u0165a\u017eenia, \u010dasov\u00e9ho limitu (timeout), preru\u0161ovania obvodu (circuit breaking), a pod.? Ako sa uskuto\u010d\u0148uje nasadenie aplik\u00e1cie pomocou modro\/zelen\u00e9ho (blue\/green) sp\u00f4sobu alebo met\u00f3dy postupn\u00e9ho presmerovania prev\u00e1dzky? Kto nastavuje parametre syst\u00e9movej autentifik\u00e1cie a autoriz\u00e1cie?<\/p>\n<p>V\u0161etky vy\u0161\u0161ie uveden\u00e9 body spadaj\u00fa do p\u00f4sobnosti riadiacej roviny (control plane) servisnej siete (service mesh). <i>Riadiaca rovina prij\u00edma sadu oddelen\u00fdch proxy-<a class=\"wpil_keyword_link\" href=\"https:\/\/prohoster.info\/sk\/server\/\"   title=\"serverov\" data-wpil-keyword-link=\"linked\"  data-wpil-monitor-id=\"1348\">serverov<\/a> bez stavu a premie\u0148a ich na distribuovan\u00fd syst\u00e9m.<\/i>.<\/p>\n<p>Mysl\u00edm, \u017ee d\u00f4vod, pre\u010do mnoh\u00ed technol\u00f3govia pova\u017euj\u00fa rozdelen\u00e9 pojmy d\u00e1tovej roviny a riadiacej roviny za m\u00e4t\u00face, je ten, \u017ee pre v\u00e4\u010d\u0161inu \u013eud\u00ed je d\u00e1tov\u00e1 rovina zn\u00e1ma, zatia\u013e \u010do riadiaca rovina je cudzia\/nezn\u00e1ma. Dlh\u00fa dobu sme pracovali s fyzick\u00fdmi sie\u0165ov\u00fdmi routre a prep\u00edna\u010dmi. Rozumieme, \u017ee pakety\/\u017eiadan\u00e9 musia \u00eds\u0165 z bodu A do bodu B a ak\u00fd hardv\u00e9r a softv\u00e9r m\u00f4\u017eeme na to pou\u017ei\u0165. Nov\u00e1 gener\u00e1cia softv\u00e9rov\u00fdch proxy je len m\u00f3dna verzia n\u00e1strojov, ktor\u00e9 sme pou\u017e\u00edvali u\u017e dlh\u00fa dobu.<\/p>\n<p><img decoding=\"async\" alt=\"Slu\u017eobn\u00e1 sie\u0165, \u201ePlocha \u00fadajov\u201c a \u201ePlocha riadenia\u201c (Service mesh data plane vs. control plane)\" src=\"\/wp-content\/uploads\/2019\/08\/1b512802777cbf1853c5c4f7f2f81d99.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<b>Obr\u00e1zok 2: \u013dudsk\u00e1 riadiaca rovina (Human control plane)<\/b><\/p>\n<p>Av\u0161ak, u\u017e dlh\u00fa dobu pou\u017e\u00edvame riadiace roviny, hoci v\u00e4\u010d\u0161ina sie\u0165ov\u00fdch oper\u00e1torov si nemus\u00ed t\u00fato \u010das\u0165 syst\u00e9mu sp\u00e1ja\u0165 s ak\u00fdmko\u013evek technologick\u00fdm komponentom. D\u00f4vod je jednoduch\u00fd:<br \/>\n<b>V\u00e4\u010d\u0161ina s\u00fa\u010dasn\u00fdch riadiacich rov\u00edn je\u2026 my<\/b>.<\/p>\n<p>Na <b>na obr\u00e1zku 2<\/b> Zobrazen\u00e9 je to, \u010do naz\u00fdvam \u201e\u013dudsk\u00e1 ovl\u00e1dacia rovina (Human control plane)\u201c. V tomto type nasadenia, ktor\u00fd sa st\u00e1le ve\u013emi \u010dasto vyskytuje, \u010dlovek-oper\u00e1tor, pravdepodobne nabru\u010den\u00fd, vytv\u00e1ra statick\u00e9 konfigur\u00e1cie \u2014 potenci\u00e1lne pomocou skriptov \u2014 a nasadzuje ich pomocou nejakej \u0161peci\u00e1lne procesu na v\u0161etk\u00fdch proxy serveroch. N\u00e1sledne proxy za\u010d\u00ednaj\u00fa pou\u017e\u00edva\u0165 t\u00fato konfigur\u00e1ciu a prech\u00e1dzaj\u00fa na spracovanie d\u00e1tovej roviny (data plane) s aktualizovan\u00fdmi nastaveniami.<\/p>\n<p><img decoding=\"async\" alt=\"Slu\u017eobn\u00e1 sie\u0165, \u201ePlocha \u00fadajov\u201c a \u201ePlocha riadenia\u201c (Service mesh data plane vs. control plane)\" src=\"\/wp-content\/uploads\/2019\/08\/6b12429611475e0fc4dfa9f980704e16.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<b>Obr\u00e1zok 3: Roz\u0161\u00edren\u00e1 ovl\u00e1dacia rovina servisnej siete (Advanced service mesh control plane)<\/b><\/p>\n<p>Na <b>obr\u00e1zku 3<\/b> je zobrazen\u00e1 \u201eroz\u0161\u00edren\u00e1\u201c ovl\u00e1dacia rovina (control plane) servisnej siete (service mesh). Sklad\u00e1 sa z nasleduj\u00facich \u010dast\u00ed:<\/p>\n<ul>\n<li> <b>\u010clovek (The human)<\/b>: St\u00e1le je tu \u010dlovek (d\u00fafam, menej nahnevan\u00fd), ktor\u00fd prij\u00edma rozhodnutia na vysokej \u00farovni oh\u013eadom celej s\u00fastavy ako celku.<\/li>\n<li><b>U\u017e\u00edvate\u013esk\u00e9 rozhranie ovl\u00e1dacej roviny (Control plane UI)<\/b>: \u010clovek interaguje s nejak\u00fdm typom u\u017e\u00edvate\u013esk\u00e9ho rozhrania na spr\u00e1vu syst\u00e9mu. M\u00f4\u017ee to by\u0165 webov\u00fd port\u00e1l, pr\u00edkazov\u00fd riadok (CLI) alebo in\u00e9 rozhranie. Pomocou u\u017e\u00edvate\u013esk\u00e9ho rozhrania m\u00e1 oper\u00e1tor pr\u00edstup k tak\u00fdm glob\u00e1lnym parametroch konfigur\u00e1cie syst\u00e9mu, ako s\u00fa:\n<ul>\n<li>Spr\u00e1va nasadenia, modro\/zelen\u00e9 (blue\/green) a\/alebo postupn\u00fd prenos prev\u00e1dzky <\/li>\n<li>Parametre autentifik\u00e1cie a autoriz\u00e1cie <\/li>\n<li>\u0160pecifik\u00e1cie tabu\u013eky trasovania, napr\u00edklad, ke\u010f aplik\u00e1cia A \u017eiada o inform\u00e1cie o &#171;\\\/foo&#187;, \u010do sa deje <\/li>\n<li>Nastavenia vyv\u00e1\u017eenia za\u0165a\u017eenia, napr\u00edklad timeouty (timeouts), opakovan\u00e9 pokusy (retries), parametre preru\u0161enia okruhu (circuit breaking) at\u010f. <\/li>\n<\/ul>\n<\/li>\n<li> <b>Pl\u00e1nova\u010d pracovn\u00e9ho za\u0165a\u017eenia (Workload scheduler)<\/b>: Slu\u017eby s\u00fa sp\u00fa\u0161\u0165an\u00e9 v infra\u0161trukt\u00fare prostredn\u00edctvom syst\u00e9mu pl\u00e1novania\/orkestrovania ur\u010dit\u00e9ho typu, napr\u00edklad Kubernetes alebo Nomad. Pl\u00e1nova\u010d zodpoved\u00e1 za na\u010d\u00edtanie slu\u017eby spolu s jej lok\u00e1lnym proxy serverom.<\/li>\n<li> <b>Objavovanie slu\u017eieb (Service discovery)<\/b>. Ke\u010f pl\u00e1nova\u010d sp\u00fa\u0161\u0165a a zastavuje in\u0161tancie slu\u017eby, reportuje stav dostupnosti do syst\u00e9mu objavovania slu\u017eieb.<\/li>\n<li> <b>API konfigur\u00e1cie lok\u00e1lneho proxy servera (Sidecar proxy configuration APIs) <\/b>: Lok\u00e1lne proxy servery dynamicky extrahuj\u00fa stav z r\u00f4znych komponentov syst\u00e9mu na z\u00e1klade modelu \u201ekone\u010dn\u00e1 konzistencia\u201c (eventually consistent) bez \u00fa\u010dasti oper\u00e1tora. Cel\u00fd syst\u00e9m, pozost\u00e1vaj\u00faci zo v\u0161etk\u00fdch aktu\u00e1lne spusten\u00fdch in\u0161tanci\u00ed slu\u017eieb a lok\u00e1lnych proxy serverov, nakoniec konverguje do jednej ekosyst\u00e9my. API univerz\u00e1lnej d\u00e1tovej roviny (data plane) v Envoy je jedn\u00fdm z pr\u00edkladov, ako to funguje v praxi.<\/li>\n<\/ul>\n<p>\nV podstate cie\u013e kontrolnej roviny (control plane) spo\u010d\u00edva v tom, aby stanovil politiku, ktor\u00e1 bude nakoniec prijat\u00e1 d\u00e1tovou rovinou (data plane). Pokro\u010dilej\u0161ie kontroln\u00e9 roviny (control plane) uvo\u013enia oper\u00e1tora od viacer\u00fdch detailov niektor\u00fdch syst\u00e9mov a vy\u017eaduj\u00fa menej ru\u010dn\u00e9ho z\u00e1sahu, pokia\u013e funguj\u00fa spr\u00e1vne!..<\/p>\n<h1>D\u00e1tov\u00e1 rovina a kontroln\u00e1 rovina. Zhrnutie (Data plane vs. control plane summary)<\/h1>\n<p><\/p>\n<ul>\n<li> <b>D\u00e1tov\u00e1 rovina slu\u017eby siete (Service mesh data plane)<\/b>: zasahuje do ka\u017ed\u00e9ho paketu \/ po\u017eiadavky v syst\u00e9me. Zodpoved\u00e1 za objavovanie aplik\u00e1ci\u00ed \/ slu\u017eieb, kontrolu dostupnosti, smerovanie, vyva\u017eovanie z\u00e1\u0165a\u017ee, autentiz\u00e1ciu \/ autoriz\u00e1ciu a monitorovanie.<\/li>\n<li> <b>Kontroln\u00e1 rovina slu\u017eby siete (Service mesh control plane)<\/b>: poskytuje politiku a konfigur\u00e1ciu pre v\u0161etky funguj\u00face d\u00e1tov\u00e9 roviny v r\u00e1mci slu\u017eby siete. Nezasahuje do \u017eiadnych paketov \/ po\u017eiadaviek v syst\u00e9me. Kontroln\u00e1 rovina transformuje v\u0161etky d\u00e1tov\u00e9 roviny na distribuovan\u00fd syst\u00e9m.<\/li>\n<\/ul>\n<p><\/p>\n<h1>Aktu\u00e1lny stav projektu (Current project landscape)<\/h1>\n<p>\nPo vysvetlen\u00ed vy\u0161\u0161ie sa pozrime na aktu\u00e1lny stav projektu \u201eservisnej siete (service mesh)\u201c.<\/p>\n<ul>\n<li> <b>D\u00e1tov\u00e9 roviny (Data planes)<\/b>: Linkerd, NGINX, HAProxy, Envoy, Traefik<\/li>\n<li><b>Kontroln\u00e9 roviny (Control planes)<\/b>: Istio, Nelson, SmartStack <\/li>\n<\/ul>\n<p>\nNamiesto hlbok\u00e9ho anal\u00fdzy ka\u017ed\u00e9ho z vy\u0161\u0161ie uveden\u00fdch rie\u0161en\u00ed sa stru\u010dne pozriem na niektor\u00e9 aspekty, ktor\u00e9 pod\u013ea m\u00f4jho n\u00e1zoru sp\u00f4sobuj\u00fa v\u00e4\u010d\u0161inu zm\u00e4tku v ekosyst\u00e9me pr\u00e1ve teraz.<\/p>\n<p>Na za\u010diatku roku 2016 bol Linkerd jedn\u00fdm z prv\u00fdch proxy serverov d\u00e1tovej vrstvy (data plane) pre servisn\u00fa sie\u0165 (service mesh) a urobil fantastick\u00fa pr\u00e1cu pri zvy\u0161ovan\u00ed informovanosti a pozornosti k modelu n\u00e1vrhu \u201eservisn\u00e1 sie\u0165\u201c (service mesh). Pribli\u017ene o 6 mesiacov nesk\u00f4r sa k Linkerd pridal Envoy (hoci pracoval v Lyft od konca roku 2015). Linkerd a Envoy s\u00fa dva projekty, ktor\u00e9 sa naj\u010dastej\u0161ie spom\u00ednaj\u00fa pri diskusii o servisn\u00fdch sie\u0165ach (service mesh).<\/p>\n<p>Istio bolo vyhl\u00e1sen\u00e9 v m\u00e1ji 2017. Ciele projektu Istio s\u00fa ve\u013emi podobn\u00e9 roz\u0161\u00edrenej funkcii riadenia (control plane), zobrazen\u00e9 na <b>obr\u00e1zku 3<\/b>. Envoy pre Istio je predvolen\u00fdm proxy serverom. Tak\u017ee Istio je riadiaca vrstva (control plane) a Envoy je d\u00e1tov\u00e1 vrstva (data plane). V kr\u00e1tkom \u010dase Istio vyvolalo ve\u013ek\u00fd rozruch a in\u00e9 d\u00e1tov\u00e9 vrstvy (data plane) za\u010dali integr\u00e1ciu ako n\u00e1hradu za Envoy (Linkerd a NGINX predviedli integr\u00e1ciu s Istio). Skuto\u010dnos\u0165, \u017ee v jednej riadiacej vrstve (control plane) je mo\u017en\u00e9 pou\u017e\u00edva\u0165 r\u00f4zne d\u00e1tov\u00e9 vrstvy (data plane), znamen\u00e1, \u017ee riadiaca vrstva (control plane) a d\u00e1tov\u00e1 vrstva (data plane) nemusia by\u0165 nevyhnutne \u00fazko prepojen\u00e9. API ako univerz\u00e1lne API d\u00e1tovej vrstvy (data plane) Envoy m\u00f4\u017ee tvori\u0165 most medzi oboma \u010das\u0165ami syst\u00e9mu.<\/p>\n<p>Nelson a SmartStack \u010falej ilustruj\u00fa rozdelenie riadiacej vrstvy (control plane) a d\u00e1tovej vrstvy (data plane). Nelson vyu\u017e\u00edva Envoy ako svoj proxy a vytv\u00e1ra robustn\u00fa riadiacu vrstvu (control plane) servisnej siete (service mesh) na z\u00e1klade technol\u00f3gie HashiCorp, t.j. Nomad a pod. SmartStack sa stal pravdepodobne prv\u00fdm zo novej vlny servisn\u00fdch siet\u00ed (service mesh). SmartStack vytv\u00e1ra riadiacu vrstvu (control plane) okolo HAProxy alebo NGINX, demon\u0161truj\u00fac mo\u017enos\u0165 odpojenia riadiacej vrstvy (control plane) servisnej siete (service mesh) a d\u00e1tovej vrstvy (data plane).<\/p>\n<p>Mikroslu\u017ebov\u00e1 architekt\u00fara so slu\u017eobnou sie\u0165ou (service mesh) pri\u0165ahuje \u010doraz v\u00e4\u010d\u0161iu pozornos\u0165 (spr\u00e1vne!), a \u010doraz viac projektov a dod\u00e1vate\u013eov za\u010d\u00edna pracova\u0165 t\u00fdmto smerom. V priebehu nasleduj\u00facich nieko\u013ek\u00fdch rokov uvid\u00edme mno\u017estvo inov\u00e1ci\u00ed ako na \u00farovni d\u00e1t (data plane), tak aj na \u00farovni riadenia (control plane), ako aj \u010fal\u0161ie kombinovanie r\u00f4znych komponentov. Nakoniec by mikroslu\u017ebov\u00e1 architekt\u00fara mala by\u0165 pre oper\u00e1tora transparentnej\u0161ia a z\u00e1zra\u010dnej\u0161ia (?)<br \/>\nD\u00fafam, \u017ee v\u0161etko je \u010doraz menej a menej frustruj\u00face.<\/p>\n<h1>K\u013e\u00fa\u010dov\u00e9 body (Key takeaways)<\/h1>\n<p><\/p>\n<ul>\n<li> Slu\u017eobn\u00e1 sie\u0165 (service mesh) sa sklad\u00e1 z dvoch r\u00f4znych \u010dast\u00ed: \u00farovne d\u00e1t (data plane) a \u00farovne riadenia (control plane). Obe komponenty s\u00fa nevyhnutn\u00e9 a bez nich syst\u00e9m nebude fungova\u0165.<\/li>\n<li>V\u0161etci pozn\u00e1me \u00farove\u0148 riadenia (control plane), a moment\u00e1lne m\u00f4\u017eete by\u0165 vy tou \u00farov\u0148ou riadenia (control plane)! <\/li>\n<li>V\u0161etky \u00farovne d\u00e1t (data plane) medzi sebou s\u00fa\u0165a\u017eia o funkcie, v\u00fdkonnos\u0165, prisp\u00f4sobite\u013enos\u0165 a roz\u0161\u00edrite\u013enos\u0165. <\/li>\n<li> V\u0161etky \u00farovne riadenia (control plane) medzi sebou s\u00fa\u0165a\u017eia o funkcie, prisp\u00f4sobite\u013enos\u0165, roz\u0161\u00edrite\u013enos\u0165 a pou\u017eite\u013enos\u0165.<\/li>\n<li>Jedna \u00farove\u0148 riadenia (control plane) m\u00f4\u017ee obsahova\u0165 spr\u00e1vne abstrakcie a API, aby mohlo by\u0165 pou\u017eit\u00e9 viacero \u00farovn\u00ed d\u00e1t (data plane). <\/li>\n<\/ul>\n<p>Zdroj: <a content=\"nofollow\" rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/post\/462699\/\">habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"<p>\u041f\u0440\u0438\u0432\u0435\u0442, \u0425\u0430\u0431\u0440! \u041f\u0440\u0435\u0434\u0441\u0442\u0430\u0432\u043b\u044f\u044e \u0432\u0430\u0448\u0435\u043c\u0443 \u0432\u043d\u0438\u043c\u0430\u043d\u0438\u044e \u043f\u0435\u0440\u0435\u0432\u043e\u0434 \u0441\u0442\u0430\u0442\u044c\u0438 \u00abService mesh data plane vs control plane\u00bb \u0430\u0432\u0442\u043e\u0440\u0430 Matt Klein. \u0412 \u044d\u0442\u043e\u0442 \u0440\u0430\u0437 \u00ab\u0437\u0430\u0445\u043e\u0442\u0435\u043b\u043e\u0441\u044c \u0438 \u043f\u0435\u0440\u0435\u0432\u0435\u043b\u043e\u0441\u044c\u00bb \u043e\u043f\u0438\u0441\u0430\u043d\u0438\u0435 \u043e\u0431\u043e\u0438\u0445 \u043a\u043e\u043c\u043f\u043e\u043d\u0435\u043d\u0442\u043e\u0432 service mesh, data plane \u0438 control plane. \u042d\u0442\u043e \u043e\u043f\u0438\u0441\u0430\u043d\u0438\u0435 \u043c\u043d\u0435 \u043f\u043e\u043a\u0430\u0437\u0430\u043b\u043e\u0441\u044c \u0441\u0430\u043c\u044b\u043c \u043f\u043e\u043d\u044f\u0442\u043d\u044b\u043c \u0438 \u0438\u043d\u0442\u0435\u0440\u0435\u0441\u043d\u044b\u043c, \u0430 \u0433\u043b\u0430\u0432\u043d\u043e\u0435 \u043f\u043e\u0434\u0432\u043e\u0434\u044f\u0449\u0438\u043c \u043a \u043f\u043e\u043d\u0438\u043c\u0430\u043d\u0438\u044e \u00ab\u0410 \u043d\u0443\u0436\u043d\u043e \u043b\u0438 \u043e\u043d\u043e \u0432\u043e\u043e\u0431\u0449\u0435?\u00bb. \u041f\u043e\u0441\u043a\u043e\u043b\u044c\u043a\u0443 \u0438\u0434\u0435\u044f \u00ab\u0421\u0435\u0440\u0432\u0438\u0441\u043d\u043e\u0439 \u0441\u0435\u0442\u0438 [&hellip;]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":27757,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-37030","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t<!-- All in One SEO 5.0.4 - aioseo.com -->\n\t<meta name=\"description\" content=\"\u041f\u0440\u0438\u0432\u0435\u0442, \u0425\u0430\u0431\u0440!\" \/>\n\t<meta name=\"robots\" content=\"max-image-preview:large\" \/>\n\t<meta name=\"author\" content=\"Yuri Gagarin\"\/>\n\t<link rel=\"canonical\" href=\"https:\/\/prohoster.info\/sk\/blog\/administrirovanie\/servisnaya-set-ploskost-dannyh-i-ploskosti-upravleniya-service-mesh-data-plane-vs-control-plane\" \/>\n\t\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 5.0.4\" \/>\n\t\t<meta property=\"og:locale\" content=\"sk_SK\" \/>\n\t\t<meta property=\"og:site_name\" content=\"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b\" \/>\n\t\t<meta property=\"og:type\" content=\"article\" \/>\n\t\t<meta property=\"og:title\" content=\"\ud83e\udd47\u0421\u0435\u0440\u0432\u0438\u0441\u043d\u0430\u044f \u0441\u0435\u0442\u044c, \u00ab\u041f\u043b\u043e\u0441\u043a\u043e\u0441\u0442\u044c \u0434\u0430\u043d\u043d\u044b\u0445\u00bb \u0438 \u00ab\u041f\u043b\u043e\u0441\u043a\u043e\u0441\u0442\u0438 \u0443\u043f\u0440\u0430\u0432\u043b\u0435\u043d\u0438\u044f\u00bb (Service mesh data plane vs. control plane) | ProHoster\" \/>\n\t\t<meta property=\"og:description\" content=\"\u041f\u0440\u0438\u0432\u0435\u0442, \u0425\u0430\u0431\u0440!\" \/>\n\t\t<meta property=\"og:url\" content=\"https:\/\/prohoster.info\/sk\/blog\/administrirovanie\/servisnaya-set-ploskost-dannyh-i-ploskosti-upravleniya-service-mesh-data-plane-vs-control-plane\" \/>\n\t\t<meta property=\"og:image\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:secure_url\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:width\" content=\"350\" \/>\n\t\t<meta property=\"og:image:height\" content=\"350\" \/>\n\t\t<meta property=\"article:published_time\" content=\"2019-10-31T19:15:23+00:00\" \/>\n\t\t<meta property=\"article:modified_time\" content=\"2019-10-31T19:15:23+00:00\" \/>\n\t\t<meta property=\"article:publisher\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<meta property=\"article:author\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<!-- All in One SEO -->\n\n","aioseo_head_json":{"title":"\ud83e\udd47Slu\u017eobn\u00e1 sie\u0165, \u201e\u00darove\u0148 d\u00e1t\u201c a \u201e\u00darovne riadenia\u201c (Service mesh data plane vs. control plane) | ProHoster","description":"Ahoj, Habr!","canonical_url":"https:\/\/prohoster.info\/sk\/blog\/administrirovanie\/servisnaya-set-ploskost-dannyh-i-ploskosti-upravleniya-service-mesh-data-plane-vs-control-plane","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"sk_SK","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47\u0421\u0435\u0440\u0432\u0438\u0441\u043d\u0430\u044f \u0441\u0435\u0442\u044c, \u00ab\u041f\u043b\u043e\u0441\u043a\u043e\u0441\u0442\u044c \u0434\u0430\u043d\u043d\u044b\u0445\u00bb \u0438 \u00ab\u041f\u043b\u043e\u0441\u043a\u043e\u0441\u0442\u0438 \u0443\u043f\u0440\u0430\u0432\u043b\u0435\u043d\u0438\u044f\u00bb (Service mesh data plane vs. control plane) | ProHoster","og:description":"\u041f\u0440\u0438\u0432\u0435\u0442, \u0425\u0430\u0431\u0440!","og:url":"https:\/\/prohoster.info\/sk\/blog\/administrirovanie\/servisnaya-set-ploskost-dannyh-i-ploskosti-upravleniya-service-mesh-data-plane-vs-control-plane","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2019-10-31T19:15:23+00:00","article:modified_time":"2019-10-31T19:15:23+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"37030","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":"2026-02-09 17:07:03","breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-03-01 01:34:25","updated":"2026-02-09 17:07:03","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/sk\/wp-json\/wp\/v2\/posts\/37030","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/sk\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/sk\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/sk\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/sk\/wp-json\/wp\/v2\/comments?post=37030"}],"version-history":[{"count":1,"href":"https:\/\/prohoster.info\/sk\/wp-json\/wp\/v2\/posts\/37030\/revisions"}],"predecessor-version":[{"id":158592,"href":"https:\/\/prohoster.info\/sk\/wp-json\/wp\/v2\/posts\/37030\/revisions\/158592"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/sk\/wp-json\/wp\/v2\/media\/27757"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/sk\/wp-json\/wp\/v2\/media?parent=37030"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/sk\/wp-json\/wp\/v2\/categories?post=37030"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/sk\/wp-json\/wp\/v2\/tags?post=37030"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}