Nagsisimula kami ng serye ng mga post na nagpapakita ng ilan sa maraming kakayahan ng Istio Service Mesh kapag pinagsama sa Red Hat OpenShift at Kubernetes.
Unang bahagi, ngayon:
- Ipaliwanag natin ang konsepto ng mga sidecar container ng Kubernetes at bumalangkas sa leitmotif ng seryeng ito ng mga post: "hindi mo kailangang baguhin ang anuman sa iyong code".
- Ipakilala natin ang pangunahing bagay ng Istio - mga panuntunan sa pagruruta. Ang lahat ng iba pang mga tampok ng Istio ay binuo sa kanila, dahil ito ang mga patakaran na nagbibigay-daan sa iyo upang idirekta ang trapiko sa mga microservice, gamit ang mga file ng YAML na panlabas sa code ng serbisyo. Isinasaalang-alang din namin ang deployment scheme ng Canary Deployment. Bonus ng Bagong Taon β 10 interactive na aralin sa Istio
Ang ikalawang bahagi, na paparating, ay magsasabi sa iyo:
- Paano ipinapatupad ni Istio ang Pool Ejection kasama ng Circuit Breaker at ipapakita kung paano ka pinapayagan ng Istio na mag-alis ng patay o hindi maganda ang performance na pod mula sa balancing circuit.
- Titingnan din natin ang paksa ng Circuit Breaker mula sa unang post upang makita kung paano magagamit ang Istio dito. Ipapakita namin sa iyo kung paano iruta ang trapiko at pangasiwaan ang mga error sa network gamit ang YAML configuration file at terminal command nang walang kaunting pagbabago sa service code.
Ikatlong bahagi:
- Isang kuwento tungkol sa pagsubaybay at pagsubaybay, na naka-built-in na o madaling idagdag sa Istio. Ipapakita namin sa iyo kung paano gumamit ng mga tool tulad ng Prometheus, Jaeger, at Grafana kasama ng OpenShift scaling upang walang kahirap-hirap na pamahalaan ang mga arkitektura ng microservice.
- Lumipat kami mula sa pagsubaybay at paghawak ng mga error hanggang sa sinasadyang ipasok ang mga ito sa system. Sa madaling salita, natutunan namin kung paano gumawa ng fault injection nang hindi binabago ang source code, na napakahalaga mula sa isang pagsubok na punto ng view - dahil kung babaguhin mo ang code mismo para dito, may panganib na magpasok ng mga karagdagang error.
Sa wakas, sa huling post sa Istio Service Mesh:
- Punta tayo sa Dark Side. Mas tiyak, matututunan nating gamitin ang scheme ng Dark Launch, kapag ang code ay na-deploy at nasubok nang direkta sa data ng produksyon, ngunit hindi nakakaapekto sa pagpapatakbo ng system sa anumang paraan. Dito magagamit ang kakayahan ni Istio na hatiin ang trapiko. At ang kakayahang sumubok sa live na data ng produksyon nang hindi naaapektuhan ang pagpapatakbo ng sistema ng labanan sa anumang paraan ay ang pinaka-nakakumbinsi na paraan ng pag-verify.
- Sa pamamagitan ng Dark Launch, ipapakita namin sa iyo kung paano gamitin ang modelo ng Canary Deployment upang mabawasan ang panganib at gawing mas madali ang pagkuha ng bagong code sa produksyon. Ang Canary Deployment mismo ay malayo sa bago, ngunit pinapayagan ka ng Istio na ipatupad ang scheme na ito gamit lamang ang mga simpleng YAML file.
- Sa wakas, ipapakita namin sa iyo kung paano gamitin ang Istio Egress para magbigay ng access sa mga serbisyo sa mga nasa labas ng iyong mga cluster upang magamit ang mga kakayahan ng Istio kapag nagtatrabaho sa Internet.
So, eto na...
Mga tool sa pagsubaybay at pamamahala ng Istio - lahat ng kailangan mo upang ayusin ang mga microservice sa isang service mesh .
Ano ang Istio Service Mesh
Ang isang service mesh ay nagpapatupad ng mga function tulad ng traffic monitoring, access control, pagtuklas, seguridad, fault tolerance at iba pang kapaki-pakinabang na bagay para sa isang pangkat ng mga serbisyo. Pinapayagan ka ng Istio na gawin ang lahat ng ito nang walang kaunting pagbabago sa code ng mga serbisyo mismo. Ano ang sikreto ng mahika? Inilalagay ng Istio ang sarili nitong proxy sa bawat serbisyo sa anyo ng sidecar container (sidecar ay sidecar ng motorsiklo), pagkatapos nito ang lahat ng trapiko sa serbisyong ito ay dumaan sa proxy, na, ginagabayan ng mga tinukoy na patakaran, ay magpapasya kung paano, kailan at kung ang trapikong ito dapat maabot ang serbisyo sa lahat. Ginagawa ring posible ng Istio na ipatupad ang mga advanced na diskarte sa DevOps tulad ng mga pag-deploy ng canary, mga circuit breaker, fault injection at marami pang iba.
Paano gumagana ang Istio sa mga container at Kubernetes
Ang Istio service mesh ay isang sidecar na pagpapatupad ng lahat ng kailangan para gumawa at mamahala ng mga microservice: pagsubaybay, pagsubaybay, mga circuit breaker, pagruruta, pagbalanse ng load, fault injection, rettry, timeout, mirroring, access control, rate limiting at marami pang iba. At bagama't ngayon ay may isang tonelada ng mga aklatan upang ipatupad ang mga function na ito nang direkta sa code, sa Istio maaari mong makuha ang lahat ng parehong bagay nang hindi binabago ang anuman sa iyong code.
Ayon sa modelo ng sidecar, ang Istio ay tumatakbo sa isang lalagyan ng Linux, na matatagpuan sa isa -pod na may kontroladong serbisyo at nag-inject at kumukuha ng functionality at impormasyon ayon sa isang ibinigay na configuration. Binibigyang-diin namin na ito ang sarili mong configuration, at nabubuhay ito sa labas ng iyong code. Samakatuwid, ang code ay nagiging mas simple at mas maikli.
Ang mahalaga rin ay ang bahagi ng pagpapatakbo ng mga microservice ay lumalabas na hindi konektado sa mismong code, na nangangahulugang ang kanilang operasyon ay maaaring ligtas na mailipat sa mga espesyalista sa IT. Sa katunayan, bakit dapat maging responsable ang developer para sa mga circuit breaker at fault injection? Mag-react, oo, ngunit iproseso ang mga ito at gawin ang mga ito? Kung aalisin mo ang lahat ng ito mula sa code, magagawa ng mga programmer na ganap na tumuon sa paggana ng application. At ang code mismo ay magiging mas maikli at mas simple.
mesh ng serbisyo
Ang Istio, na nagpapatupad ng mga function para sa pamamahala ng mga microservice sa labas ng kanilang code, ay ang konsepto ng isang Service Mesh. Sa madaling salita, ito ay isang coordinated na grupo ng isa o higit pang mga binary na bumubuo ng isang mesh ng mga function ng network.
Paano gumagana ang Istio sa mga microservice
Ito ang hitsura ng trabaho ng mga sidecar container kasama ng ΠΈ bird's eye view: maglunsad ng isang instance ng Minishift, gumawa ng proyekto para sa Istio (tawagin natin itong "istio-system"), i-install at patakbuhin ang lahat ng bahaging nauugnay sa Istio. Pagkatapos, habang gumagawa ka ng mga proyekto at pod, nagdaragdag ka ng impormasyon ng configuration sa iyong mga deployment, at ang iyong mga pod ay magsisimulang gumamit ng Istio. Ang isang pinasimple na diagram ay ganito ang hitsura:
Ngayon ay maaari mong baguhin ang mga setting ng Istio sa pagkakasunud-sunod, halimbawa, upang ayusin ang fault injection, suporta o iba pang mga tampok ng Istio - at lahat ng ito nang hindi hinahawakan ang code ng mga application mismo. Sabihin nating gusto mong i-redirect ang lahat ng trapiko sa web mula sa mga user ng iyong pinakamalaking kliyente (Foo Corporation) sa isang bagong bersyon ng site. Para magawa ito, gumawa lang ng Istio routing rule na hahanapin ang @foocorporation.com sa user ID at magre-redirect nang naaayon. Para sa lahat ng iba pang user, walang magbabago. Pansamantala, mahinahon mong susubukan ang bagong bersyon ng site. At tandaan na hindi mo kailangang isali ang mga developer para dito.
At kailangan mong magbayad ng mahal para dito?
Hindi talaga. Istio ay medyo mabilis at nakasulat sa at lumilikha ng napakaliit na overhead. Bilang karagdagan, ang posibleng pagkawala sa online na produktibidad ay binabayaran ng pagtaas ng produktibidad ng developer. Hindi bababa sa teorya: huwag kalimutan na ang oras ng mga developer ay mahalaga. Para sa mga gastos sa software, ang Istio ay open source software, kaya maaari mong makuha at magamit ito nang libre.
Master ito sa iyong sarili
Ang Red Hat Developer Experience Team ay bumuo ng isang malalim na hands-on ni Istio (sa Ingles). Gumagana ito sa Linux, MacOS at Windows, at available ang code sa Java at Node.js.
10 interactive na aralin sa Istio
Block 1 - Para sa Mga Nagsisimula
Panimula kay Istio
30 minuto
Kilalanin natin ang Service Mesh, alamin kung paano i-install ang Istio sa isang OpenShift Kubernetes cluster.
Naglalagay ng mga microservice sa Istio
30 minuto
Ginagamit namin ang Istio para mag-deploy ng tatlong microservice na may Spring Boot at Vert.x.
Block 2 β intermediate level
Pagsubaybay at pagsubaybay sa Istio
60 minuto
I-explore namin ang mga built-in na tool sa pagsubaybay, custom na sukatan, at OpenTracing ng Istio sa pamamagitan ng Prometheus at Grafana.
Simpleng pagruruta sa Istio
60 minuto
Matutunan kung paano pamahalaan ang pagruruta sa Istio gamit ang mga simpleng panuntunan.
Mga advanced na panuntunan sa pagruruta
60 minuto
Tingnan natin ang matalinong pagruruta, kontrol sa pag-access, pagbabalanse ng load, at paglilimita sa rate ng Istio.
Block 3 β advanced na user
Fault Injection sa Istio
60 minuto
Pinag-aaralan namin ang mga sitwasyon sa paghawak ng pagkabigo sa mga distributed na application, paggawa ng mga error sa HTTP at pagkaantala sa network, at natututo kaming gumamit ng chaos engineering para ibalik ang kapaligiran.
Circuit Breaker sa Istio
30 minuto
Nag-i-install kami ng Siege para sa mga site ng pagsubok sa stress at natutunan kung paano tiyakin ang pagpapahintulot sa backend fault gamit ang mga replay, circuit breaker at pool ejection.
Egress at Istio
10 minuto
Gumagamit kami ng mga ruta ng Egress upang lumikha ng mga panuntunan para sa pakikipag-ugnayan ng mga panloob na serbisyo sa mga panlabas na API at serbisyo.
Istio at Kiali
15 minuto
Matutunang gamitin ang Kiali para makakuha ng pangkalahatang-ideya ng mesh ng serbisyo at galugarin ang kahilingan at daloy ng data.
Mutual TLS sa Istio
15 minuto
Gumagawa kami ng Istio Gateway at VirtualService, pagkatapos ay pinag-aaralan namin ang mutual TLS (mTLS) at ang mga setting nito nang detalyado.
Block 3.1 - Deep Dive: Istio Service Mesh para sa Microservices
Tungkol Saan ang libro:
- Ano ang service mesh?
- Ang Istio system at ang papel nito sa microservice architecture.
- Paggamit ng Istio upang malutas ang mga sumusunod na problema:
- Fault tolerance;
- Pagruruta;
- Pagsubok ng kaguluhan;
- Seguridad;
- Pagkolekta ng telemetry gamit ang mga bakas, sukatan at Grafana.
Serye ng mga artikulo sa mga service meshes at Istio
Subukan ito sa iyong sarili
Ang serye ng mga post na ito ay hindi nilayon na magbigay ng malalim na pagsisid sa mundo ng Istio. Gusto lang naming ipakilala sa iyo ang konsepto at baka ma-inspire ka na subukan ang Istio para sa iyong sarili. Libre itong gawin, at ibinibigay ng Red Hat ang lahat ng tool na kailangan mo para makapagsimula sa OpenShift, Kubernetes, Linux container, at Istio, kasama ang: , at iba pang mapagkukunan sa aming . Huwag mag-antala, magsimula ngayon!
Mga panuntunan sa pagruruta ng Istio: pagdidirekta ng mga kahilingan sa serbisyo kung saan sila dapat pumunta
ΠΈ gumawa ng isang mahusay na trabaho ng pagtugon idinala sa mga kinakailangang pod. Isa ito sa mga dahilan ng pagkakaroon ng Kubernetes - pagruruta at pagbabalanse ng load. Ngunit paano kung kailangan mo ng mas banayad at sopistikadong pagruruta? Halimbawa, upang sabay na gumamit ng dalawang bersyon ng isang microservice. Paano makakatulong ang Istio Route Rules dito?
Ang mga panuntunan sa pagruruta ay ang mga panuntunang aktwal na tumutukoy sa pagpili ng ruta. Anuman ang antas ng pagiging kumplikado ng system, ang pangkalahatang prinsipyo ng pagpapatakbo ng mga panuntunang ito ay nananatiling simple: ang mga kahilingan ay niruruta batay sa ilang mga parameter at mga halaga ng header ng HTTP.
Tingnan natin ang mga halimbawa:
Default ng Kubernetes: walang kuwenta "50/50"
Sa aming halimbawa, ipapakita namin kung paano sabay na gumamit ng dalawang bersyon ng isang microservice sa OpenShift, tawagin natin silang v1 at v2. Ang bawat bersyon ay tumatakbo sa sarili nitong Kubernetes pod, at bilang default ay nagpapatakbo ito ng pantay na balanseng round robin routing. Natatanggap ng bawat pod ang bahagi nito sa mga kahilingan batay sa bilang ng mga instance ng microservice nito, sa madaling salita, mga replika. Binibigyang-daan ka ng Istio na manual na baguhin ang balanseng ito.
Sabihin nating nag-deploy kami ng dalawang bersyon ng aming serbisyo sa rekomendasyon sa OpenShift, rekomendasyon-v1 at rekomendasyon-v2.
Sa Fig. Ipinapakita ng Figure 1 na kapag ang bawat serbisyo ay kinakatawan sa isang pagkakataon, ang mga kahilingan ay nagpapalit-palit sa pagitan nila: 1-2-1-2-... Ganito gumagana ang pagruruta ng Kubernetes bilang default:
Timbang na pamamahagi sa pagitan ng mga bersyon
Sa Fig. Ipinapakita ng Figure 2 kung ano ang mangyayari kung dagdagan mo ang bilang ng v2 service replicas mula isa hanggang dalawa (ito ay ginagawa gamit ang oc scale βreplicas=2 deployment/recommendation-v2 command). Tulad ng nakikita mo, ang mga kahilingan sa pagitan ng v1 at v2 ay nahahati na ngayon sa isang one-to-three ratio: 1-2-2-1-2-2-β¦:
Huwag pansinin ang bersyon gamit ang Istio
Pinapadali ng Istio na baguhin ang pamamahagi ng mga kahilingan sa paraang kailangan namin. Halimbawa, ipadala lamang ang lahat ng trapiko sa rekomendasyon-v1 gamit ang sumusunod na Istio yaml file:
Dito kailangan mong bigyang pansin ito: ang mga pod ay pinili ayon sa mga label. Ang aming halimbawa ay gumagamit ng label na v1. Ang parameter na "timbang: 100" ay nangangahulugan na ang 100% ng trapiko ay iruruta sa lahat ng mga pod ng serbisyo na may label na v1.
Directive distribution sa pagitan ng mga bersyon (Canary Deployment)
Susunod, gamit ang parameter ng timbang, maaari mong idirekta ang trapiko sa parehong mga pod, na binabalewala ang bilang ng mga instance ng microservice na tumatakbo sa bawat isa sa kanila. Halimbawa, dito idinidirekta namin ang 90% ng trapiko sa v1 at 10% sa v2:
Hiwalay na pagruruta para sa mga mobile user
Bilang konklusyon, ipapakita namin kung paano pilitin ang trapiko ng mobile na user na iruta sa serbisyo v2, at lahat ng iba pa sa v1. Upang gawin ito, gumagamit kami ng mga regular na expression upang suriin ang halaga ng user-agent sa header ng kahilingan:
Ngayon ay iyong turn
Ang halimbawang may mga regular na expression para sa pag-parse ng mga header ay dapat mag-udyok sa iyo na hanapin ang sarili mong paggamit ng mga panuntunan sa pagruruta ng Istio. Bukod dito, ang mga posibilidad dito ay medyo malawak, dahil ang mga halaga ng header ay maaaring mabuo sa source code ng application.
At tandaan na Ops, hindi Dev
Lahat ng ipinakita namin sa mga halimbawa sa itaas ay ginagawa nang walang kaunting pagbabago sa source code, mabuti, maliban sa mga kasong iyon kung kailan kinakailangan na bumuo ng mga header ng espesyal na kahilingan. Magiging kapaki-pakinabang ang Istio kapwa sa mga developer, na, halimbawa, ay magagamit ito sa yugto ng pagsubok, at sa mga espesyalista sa pagpapatakbo ng mga IT system, kung saan ito ay lubos na makakatulong sa produksyon.
Kaya ulitin natin ang leitmotif ng serye ng mga post na ito: hindi mo kailangang baguhin ang anuman sa iyong code. Hindi na kailangang bumuo ng mga bagong larawan o maglunsad ng mga bagong lalagyan. Ang lahat ng ito ay ipinatupad sa labas ng code.
Gamitin ang iyong imahinasyon
Isipin lamang ang mga posibilidad ng pagsusuri ng header gamit ang mga regular na expression. Gustong i-redirect ang iyong pinakamalaking customer sa isang espesyal na bersyon ng iyong ? Madali lang! Kailangan ng hiwalay na bersyon para sa Chrome browser? Walang problema! Maaari mong ruta ang trapiko ayon sa halos anumang katangian.
Subukan ito sa iyong sarili
Ang pagbabasa tungkol sa Istio, Kubernetes at OpenShift ay isang bagay, ngunit bakit hindi mo hawakan ang lahat? Koponan ay naghanda ng detalyadong gabay (sa Ingles) na tutulong sa iyong makabisado ang mga teknolohiyang ito sa lalong madaling panahon. Ang manual ay 100% open source din, kaya ito ay nai-post sa pampublikong domain. Gumagana ang file sa macOS, Linux at Windows, at available ang source code sa mga bersyon ng Java at node.js (paparating na ang mga bersyon sa iba pang mga wika). Buksan lamang ang kaukulang git repository sa iyong browser .
Sa susunod na post: maayos naming inaayos ang mga problema
Ngayon nakita mo kung ano ang magagawa ng mga panuntunan sa pagruruta ng Istio. Ngayon isipin ang parehong bagay, ngunit may kaugnayan lamang sa paghawak ng error. Ito mismo ang pag-uusapan natin sa susunod na post.
Pinagmulan: www.habr.com