{"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\/et\/blog\/administrirovanie\/servisnaya-set-ploskost-dannyh-i-ploskosti-upravleniya-service-mesh-data-plane-vs-control-plane","title":{"rendered":"Teenuste v\u00f5rk, \"Andmete tasand\" ja \"Juhtimis tasand\" (Service mesh data plane vs. control plane)","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Tere, Habr! Esitlen teile t\u00f5lget artiklist \u201eTeenuste v\u00f5rkude andmeplaan vs juhtimiplaneer\u201c<\/a><\/noindex> autor Matt Klein<\/b>.<\/p>\n

\"Teenuste
\n
\nSeekord \u201esoovisin ja t\u00f5lkisin\u201c m\u00f5lema teenuste v\u00f5rgu komponente, andmeplaani ja juhtimiplaneerimist. See kirjeldus tundus mulle k\u00f5ige arusaadavam ja huvitavam, ning mis k\u00f5ige t\u00e4htsam, viib arusaamiseni \u201eKas see on \u00fcldse vajalik?\u201c<\/p>\n

Kuna idee \u201eteenuste v\u00f5rgust (service mesh)\u201c on viimase kahe aasta jooksul \u00fcha populaarsemaks muutunud (originaalartikkel 10. oktoobrist 2017), ja osalejate arv selles valdkonnas on kasvanud, olen m\u00e4rganud, et kogu tehnilises kogukonnas on tekkinud rohkem segadust selle \u00fcle, kuidas erinevaid lahendusi v\u00f5rrelda ja vastandada.
\n<\/a><\/noindex>
\nOma olukorda on k\u00f5ige parem kirjeldada j\u00e4rgmiste tweetide seeriaga, mille kirjutasin juulis:<\/p>\n

Teenuste v\u00f5rgu (service mesh) segadus nr 1: Linkerd ~ = Nginx ~ = Haproxy ~ = Envoy. \u00dckski neist ei ole v\u00f5rdne Istio'ga. Istio on midagi hoopis muud. 1 \/<\/p><\/blockquote>\n

Esimesed on lihtsalt andmeplaanid (data planes). \u00dcksinda ei tee nad midagi. Need peavad olema konfigureeritud millekski enamaks. 2 \/<\/p><\/blockquote>\n

Istio on n\u00e4ide juhtimiplaneerist (control plane), mis seob osad omavahel. See on erinev kiht. \/l\u00f5pp<\/p><\/blockquote>\n

Varasemates tweetides mainitakse mitmeid erinevaid projekte (Linkerd, NGINX, HAProxy, Envoy ja Istio), kuid mis on veel olulisem, tutvustatakse \u00fcldisi m\u00f5isteid andmeplaani (data plane), teenuste v\u00f5rgu (service mesh) ja juhtimiplaneerimise (control plane) kohta. Selles postituses astun sammu tagasi ja r\u00e4\u00e4gin, mida m\u00f5tlen terminite \u201eandmeplaan (data plane)\u201c ja \u201ejuhtimiplaneer (control plane)\u201c all v\u00e4ga k\u00f5rgel tasemel, ning seej\u00e4rel r\u00e4\u00e4gin, kuidas need terminid seonduvad tweetides mainitud projektidega.<\/p>\n

Mis on teenuste v\u00f5rk (What is a service mesh, really)?<\/h1>\n

\n\"Teenuste
\nJoonis 1: Teenuste v\u00f5rgu \u00fclevaade (Service mesh overview)<\/b><\/p>\n

Joonis 1<\/b> illustreerib teenuste v\u00f5rgu (service mesh) kontseptsiooni k\u00f5ige p\u00f5hialustel. On neli teenuste klastrit (A-D). Iga teenuse eksemplar on seotud kohaliku proksiserveriga. Kogu v\u00f5rgu liiklus (HTTP, REST, gRPC, Redis jne) eraldi rakenduse eksemplarist suunatakse kohaliku proksiserveri kaudu vastavatesse v\u00e4listesse teenuste klastritesse. Seega ei tea rakenduse eksemplar v\u00f5rgustiku \u00fcldisest toimimisest, vaid ainult oma kohalikust proksist. Tegelikult on jaotatud s\u00fcsteemi v\u00f5rk teenusest eemaldatud.<\/p>\n

Andmeplaan (Data plane)<\/h1>\n

\nTeenuste v\u00f5rgus (service mesh) t\u00e4idab kohaliku proksiserveri rakenduse jaoks j\u00e4rgmisi \u00fclesandeid:<\/p>\n