"Danger is my middle name," sabi ni Austin Powers, isang international man of mystery, dati. Ngunit kung ano ang pinahahalagahan ng mga super agent at mga serbisyo ng katalinuhan ay hindi talaga angkop para sa mga serbisyo ng computer, kung saan ang pagkabagot ay mas mahusay kaysa sa panganib.
At ang Istio, kasama ang OpenShift at Kubernetes, ay ginagawang tunay na boring at predictable ang pagde-deploy ng mga microservice - at maganda iyon. Pag-uusapan natin ito at marami pang iba sa ikaapat at huling post sa seryeng Istio.
Kapag tama na ang pagkabagot
Sa aming kaso, ang pagkabagot ay nangyayari lamang sa huling yugto, kapag ang natitira na lang ay umupo at panoorin ang proseso. Ngunit para dito kailangan mong i-configure muna ang lahat, at maraming mga kagiliw-giliw na bagay ang naghihintay sa iyo dito.
Kapag nagde-deploy ng bagong bersyon ng iyong software, sulit na isaalang-alang ang lahat ng opsyon para sa pagliit ng mga panganib. Ang pagpapatakbo nang magkatulad ay isang napakalakas at napatunayang paraan upang subukan, at pinapayagan ka ng Istio na gumamit ng isang "lihim na serbisyo" (isang nakatagong bersyon ng iyong microservice) upang gawin ito nang hindi nakakasagabal sa sistema ng produksyon. Mayroong kahit isang espesyal na termino para dito - "Madilim na Paglunsad", na kung saan ay isinaaktibo ng isang function na may pantay na pangalan ng espiya na "pag-mirror ng trapiko".
Pakitandaan na ang unang pangungusap ng nakaraang talata ay gumagamit ng terminong "deploy" sa halip na "release". Talagang magagawa mong i-deployβat, siyempre, gamitinβang iyong microservice nang madalas hangga't gusto mo. Ang serbisyong ito ay dapat na makatanggap at makapagproseso ng trapiko, makagawa ng mga resulta, at magsulat din sa mga log at magmonitor. Ngunit sa parehong oras, ang serbisyong ito mismo ay hindi kailangang ilabas sa produksyon. Ang pag-deploy at pagpapalabas ng software ay hindi palaging pareho. Maaari kang mag-deploy kahit kailan mo gusto, ngunit i-release lang kapag handa ka na.
Ang pag-aayos ng pagkabagot ay kawili-wili
Tingnan ang sumusunod na panuntunan sa pagruruta ng Istio, na nagruruta sa lahat ng kahilingan sa HTTP sa rekomendasyon ng microservice v1 (lahat ng mga halimbawang kinuha mula sa ), habang sabay-sabay na sinasalamin ang mga ito sa rekomendasyong v2 microservice:
Bigyang-pansin ang label mirror: sa ibaba ng screen - ito ang nagtatakda ng pag-mirror ng trapiko. Oo, ganoon kasimple!
Ang resulta ng panuntunang ito ay ang iyong production system (v1) ay patuloy na magpoproseso ng mga papasok na kahilingan, ngunit ang mga kahilingan mismo ay asynchronous na isasalamin sa v2, iyon ay, ang kanilang kumpletong mga duplicate ay mapupunta doon. Sa ganitong paraan, maaari mong subukan ang v2 sa totoong mga kundisyon - sa totoong data at trapiko - nang hindi nakikialam sa anumang paraan sa pagpapatakbo ng sistema ng produksyon. Ginagawa ba nitong boring ang pag-aayos ng pagsubok? Oo, tiyak. Ngunit ito ay ginawa sa isang kawili-wiling paraan.
Dagdagan natin ang drama
Pakitandaan na sa v2 code ay kinakailangang magbigay ng mga sitwasyon kung saan ang mga papasok na kahilingan ay maaaring humantong sa mga pagbabago ng data. Ang mga kahilingan mismo ay na-mirror nang madali at malinaw, ngunit ang pagpili ng paraan ng pagproseso sa pagsubok ay nasa iyo - at ito ay medyo nakakabahala.
Ulitin natin ang isang mahalagang punto
Ang lihim na paglulunsad na may pag-mirror ng trapiko (Madilim na Paglulunsad/Paghiling ng Pag-mirror) ay maaaring isagawa nang hindi naaapektuhan ang code sa anumang paraan.
Pagkain para sa pag-iisip
Paano kung ang lugar kung saan naka-mirror ang mga kahilingan ay nagpapadala ng ilan sa mga ito hindi sa v1, ngunit sa v2? Halimbawa, isang porsyento ng lahat ng mga kahilingan o mga kahilingan lamang mula sa isang partikular na pangkat ng mga user. At pagkatapos, tinitingnan kung paano gumagana ang v2, unti-unting ilipat ang lahat ng mga kahilingan sa bagong bersyon. O vice versa, ibalik ang lahat sa v1 kung may mali sa v2. Sa tingin ko ito ay tinatawag na Canary Deployment. , at kung ito ay nagmula sa Ruso, malamang na naglalaman ito ng sanggunian sa ), at ngayon ay titingnan natin ito nang mas detalyado.
Canary Deployment sa Istio: pinapasimple ang pag-commissioning
Maingat at unti-unti
Ang kakanyahan ng modelo ng pag-deploy ng Canary Deployment ay napakasimple: kapag naglunsad ka ng bagong bersyon ng iyong software (sa aming kaso, isang microservice), binibigyan mo muna ito ng access sa isang maliit na grupo ng mga user. Kung magiging maayos ang lahat, dahan-dahan mong dagdagan ang pangkat na ito hanggang sa magsimulang kumilos ang bagong bersyon, o - kung hindi - sa kalaunan ay i-migrate ang lahat ng user dito. Sa pamamagitan ng maingat at unti-unting pagpapakilala ng bagong bersyon at paglipat ng mga user dito sa isang kontroladong paraan, maaari mong bawasan ang mga panganib at i-maximize ang feedback.
Siyempre, pinapasimple ng Istio ang Canary Deployment sa pamamagitan ng pag-aalok ng ilang magagandang opsyon para sa matalinong pagruruta ng kahilingan. At oo, lahat ng ito ay maaaring gawin nang hindi hinahawakan ang iyong source code sa anumang paraan.
Pag-filter ng browser
Ang isa sa pinakasimpleng pamantayan sa pagruruta ay ang pag-redirect na nakabatay sa browser. Sabihin nating gusto mo lang ang mga kahilingan mula sa mga Safari browser na pumunta sa v2. Narito kung paano ito ginagawa:
Ilapat natin ang panuntunang ito sa pagruruta at pagkatapos ay gamitin ang command curl Gagawin namin ang mga tunay na kahilingan sa microservice sa isang loop. Gaya ng nakikita mo sa screenshot, lahat sila ay pumupunta sa v1:
Nasaan ang trapiko sa v2? Dahil sa aming halimbawa ang lahat ng mga kahilingan ay nagmula lamang sa aming sariling command line, ito ay sadyang wala. Ngunit bigyang-pansin ang mga ibabang linya sa screen sa itaas: ito ay isang reaksyon sa katotohanan na nagsagawa kami ng isang kahilingan mula sa Safari browser, na siya namang ginawa ito:
Walang limitasyong kapangyarihan
Naisulat na namin na ang mga regular na expression ay nagbibigay ng napakalakas na kakayahan para sa mga kahilingan sa pagruruta. Tingnan ang sumusunod na halimbawa (sa tingin namin ay mauunawaan mo kung ano ang ginagawa nito):
Sa ngayon, malamang na mayroon ka nang ideya kung ano ang magagawa ng mga regular na expression.
Kumilos Matalino
Ang matalinong pagruruta, sa partikular na pagpoproseso ng mga packet header gamit ang mga regular na expression, ay nagbibigay-daan sa iyo na patnubayan ang trapiko sa paraang gusto mo. At ito ay lubos na pinasimple ang pagpapatupad ng bagong code - ito ay simple, hindi ito nangangailangan ng pagbabago ng code mismo, at kung kinakailangan, ang lahat ay maaaring mabilis na maibalik tulad ng dati.
Interesado?
Sabik ka bang mag-eksperimento sa Istio, Kubernetes at OpenShift sa iyong computer? Koponan naghanda ng isang mahusay sa paksang ito at ginawang available sa publiko ang lahat ng kasamang file. Kaya't magpatuloy at huwag ipagkait sa iyong sarili ang anuman.
β
Istio Egress: lumabas sa souvenir shop
Sa pamamagitan ng paggamit ng Istio kasama ng Red Hat OpenShift at Kubernetes, maaari mong gawing mas madali ang iyong buhay sa mga microservice. Nakatago ang service mesh ni Istio sa loob ng mga Kubernetes pod, at ang iyong code ay tumatakbo (karamihan) nang nakahiwalay. Pagganap, kadalian ng pagbabago, pagsubaybay, atbp. β lahat ng ito ay madaling gamitin salamat sa paggamit ng mga sidecar container. Ngunit paano kung ang iyong microservice ay kailangang makipag-ugnayan sa ibang mga serbisyo na matatagpuan sa labas ng iyong OpenShift-Kubernetes system?
Dito sumagip si Istio Egress. Sa madaling sabi, pinapayagan ka nitong ma-access ang mga mapagkukunan (basahin ang: "mga serbisyo") na hindi bahagi ng iyong system ng mga Kubernetes pod. Kung hindi ka magsagawa ng karagdagang configuration, sa kapaligiran ng Istio Egress, ang trapiko ay iruruta lamang sa loob ng isang kumpol ng mga pod at sa pagitan ng mga naturang cluster batay sa mga panloob na IP table. At ang gayong pupation ay mahusay na gumagana hangga't hindi mo kailangan ng access sa mga serbisyo mula sa labas.
Binibigyang-daan ka ng Egress na i-bypass ang mga IP table sa itaas, batay man sa mga panuntunan ng Egress o sa isang hanay ng mga IP address.
Sabihin nating mayroon kaming Java program na gumagawa ng kahilingan sa GET sa httpbin.org/headers.
(Ang httpbin.org ay isang maginhawang mapagkukunan lamang para sa pagsubok ng mga papalabas na kahilingan sa serbisyo.)
Kung pumasok ka sa command line curl http://httpbin.org/headers, makikita natin ang sumusunod:
O maaari mong buksan ang parehong address sa browser:
Gaya ng nakikita mo, ibinabalik lamang ng serbisyong matatagpuan doon ang mga header na ipinasa dito.
Pinapalitan namin ang mga pag-import nang direkta
Ngayon kunin natin ang Java code ng serbisyong ito, panlabas sa aming system, at patakbuhin ito nang mag-isa, kung saan, tandaan, naka-install ang Istio. (Maaari mong gawin ito sa iyong sarili sa pamamagitan ng pakikipag-ugnayan .) Ang pagkakaroon ng pagbuo ng naaangkop na imahe at inilunsad ito sa OpenShift platform, tatawagin namin ang serbisyong ito gamit ang command curl egresshttpbin-istioegress.$(minishift ip).nip.io, pagkatapos nito ay makikita natin ito sa screen:
Oops, anong nangyari? Nagtrabaho lang ang lahat. Ano ang ibig sabihin ng Not Found? Ginawa lang namin para sa kanya curl.
Pagpapalawak ng mga talahanayan ng IP sa buong Internet
Dapat sisihin (o pasalamatan) si Istio para dito. Pagkatapos ng lahat, ang Istio ay mga sidecar container lamang na responsable para sa pagtuklas at pagruruta (at marami pang ibang bagay na napag-usapan namin kanina). Dahil dito, alam lang ng mga IP table kung ano ang nasa loob ng iyong cluster system. At ang httpbin.org ay matatagpuan sa labas at samakatuwid ay hindi naa-access. At dito sumagip ang Istio Egress - nang walang kaunting pagbabago sa iyong source code.
Pinipilit ng Egress rule sa ibaba si Istio na maghanap (kung kinakailangan, pagkatapos ay sa buong Internet) para sa kinakailangang serbisyo, sa kasong ito, httpbin.org. Tulad ng nakikita mo mula sa file na ito (egress_httpbin.yml), ang pag-andar dito ay medyo simple:
Ang natitira na lang ay ilapat ang panuntunang ito:
istioctl create -f egress_httpbin.yml -n istioegress
Maaari mong tingnan ang mga panuntunan ng Egress gamit ang command istioctl get egressrules:
At sa wakas, pinapatakbo namin muli ang utos kulutan β at nakikita natin na gumagana ang lahat:
Nag-iisip kami nang bukas
Tulad ng nakikita mo, pinapayagan ka ng Istio na ayusin ang pakikipag-ugnayan sa labas ng mundo. Sa madaling salita, maaari ka pa ring lumikha ng mga serbisyo ng OpenShift at pamahalaan ang mga ito sa pamamagitan ng Kubernetes, na pinapanatili ang lahat sa mga pod na pataas at pababa kung kinakailangan. At sa parehong oras, maaari mong ligtas na ma-access ang mga serbisyong panlabas sa iyong kapaligiran. At oo, inuulit namin muli na ang lahat ng ito ay magagawa nang hindi hinahawakan ang iyong code sa anumang paraan.
Ito ang huling post sa serye sa Istio. Manatiling nakatutok - maraming mga kawili-wiling bagay sa hinaharap!
Pinagmulan: www.habr.com