Ang Kubernetes ay isang mahusay na tool para sa pagpapatakbo ng mga container ng Docker sa isang clustered production environment. Gayunpaman, may mga problemang hindi kayang lutasin ng Kubernetes. Para sa mga madalas na deployment ng produksyon, kailangan namin ng ganap na automated na Blue/Green deployment para maiwasan ang downtime sa proseso, na kailangan ding pangasiwaan ang mga external na kahilingan sa HTTP at magsagawa ng mga SSL offload. Nangangailangan ito ng pagsasama sa isang load balancer gaya ng ha-proxy. Ang isa pang hamon ay ang semi-awtomatikong pag-scale ng Kubernetes cluster mismo kapag tumatakbo sa cloud environment, halimbawa bahagyang pinababa ang cluster sa gabi.
Bagama't walang mga feature na ito ang Kubernetes, nagbibigay ito ng API na magagamit mo upang malutas ang mga katulad na problema. Ang mga tool para sa automated na Blue/Green deployment at scaling ng isang Kubernetes cluster ay binuo bilang bahagi ng Cloud RTI project, na ginawa batay sa open-source.
Ang artikulong ito, isang transcript ng video, ay nagpapakita sa iyo kung paano i-set up ang Kubernetes kasama ng iba pang bahagi ng open source upang lumikha ng isang production-ready na environment na tumatanggap ng code mula sa isang git commit nang walang downtime sa produksyon.
Kaya, sa sandaling magkaroon ka ng access sa iyong mga application mula sa labas ng mundo, maaari mong simulan ang ganap na pag-set up ng automation, iyon ay, dalhin ito sa yugto kung saan maaari kang magsagawa ng git commit at siguraduhin na ang git commit na ito ay mapupunta sa produksyon. Naturally, kapag ipinatupad ang mga hakbang na ito, kapag nagpapatupad ng deployment, hindi namin gustong makatagpo ng downtime. Kaya, ang anumang automation sa Kubernetes ay nagsisimula sa API.
Ang Kubernetes ay hindi isang tool na maaaring magamit nang produktibo sa labas ng kahon. Siyempre, magagawa mo iyon, gumamit ng kubectl at iba pa, ngunit ang API pa rin ang pinakakawili-wili at kapaki-pakinabang na bagay tungkol sa platform na ito. Sa pamamagitan ng paggamit ng API bilang isang hanay ng mga function, maa-access mo ang halos anumang bagay na gusto mong gawin sa Kubernetes. Ang kubectl mismo ay gumagamit din ng REST API.
Ito ay REST, kaya maaari kang gumamit ng anumang wika o tool upang gumana sa API na ito, ngunit ang iyong buhay ay gagawing mas madali sa pamamagitan ng mga custom na library. Sumulat ang aking koponan ng 2 ganoong mga aklatan: isa para sa Java/OSGi at isa para sa Go. Ang pangalawa ay hindi madalas na ginagamit, ngunit sa anumang kaso mayroon kang mga kapaki-pakinabang na bagay sa iyong pagtatapon. Ang mga ito ay isang bahagyang lisensyadong open-source na proyekto. Maraming ganoong mga aklatan para sa iba't ibang wika, kaya maaari mong piliin ang mga pinakaangkop sa iyo.
Kaya, bago mo simulan ang pag-automate ng iyong deployment, kailangan mong tiyakin na ang proseso ay hindi sasailalim sa anumang downtime. Halimbawa, ang aming team ay nagsasagawa ng mga deployment ng produksyon sa kalagitnaan ng araw kung kailan ginagamit ng mga tao ang mga application nang pinakamaraming, kaya mahalagang maiwasan ang mga pagkaantala sa prosesong ito. Para maiwasan ang downtime, 2 paraan ang ginagamit: blue/green deployment o rolling update. Sa huling kaso, kung mayroon kang 5 replika ng application na tumatakbo, ang mga ito ay ina-update nang sunud-sunod. Ang pamamaraang ito ay mahusay na gumagana, ngunit ito ay hindi angkop kung mayroon kang iba't ibang mga bersyon ng application na tumatakbo nang sabay-sabay sa panahon ng proseso ng pag-deploy. Sa kasong ito, maaari mong i-update ang user interface habang pinapatakbo ng backend ang lumang bersyon, at hihinto sa paggana ang application. Samakatuwid, mula sa isang punto ng programming, ang pagtatrabaho sa gayong mga kondisyon ay medyo mahirap.
Ito ang isa sa mga dahilan kung bakit mas gusto naming gumamit ng asul/berdeng deployment para i-automate ang deployment ng aming mga application. Sa pamamaraang ito, dapat mong tiyakin na isang bersyon lamang ng application ang aktibo sa bawat pagkakataon.
Ang asul/berde na mekanismo ng pag-deploy ay ganito ang hitsura. Tumatanggap kami ng trapiko para sa aming mga application sa pamamagitan ng ha-proxy, na nagpapasa nito sa pagpapatakbo ng mga replika ng application ng parehong bersyon.
Kapag may ginawang bagong deployment, ginagamit namin ang Deployer, na binibigyan ng mga bagong bahagi at nagde-deploy ng bagong bersyon. Ang pag-deploy ng bagong bersyon ng isang application ay nangangahulugan na ang isang bagong hanay ng mga replika ay "itinaas", pagkatapos nito ang mga replika ng bagong bersyon ay inilunsad sa isang hiwalay, bagong pod. Gayunpaman, walang alam ang ha-proxy tungkol sa kanila at hindi pa rin nagruruta ng anumang workload sa kanila.
Samakatuwid, una sa lahat, kinakailangan na magsagawa ng pagsusuri sa pagganap ng mga bagong bersyon ng pagsusuri sa kalusugan upang matiyak na ang mga replika ay handa na sa serbisyo sa pagkarga.
Dapat suportahan ng lahat ng bahagi ng deployment ang ilang uri ng pagsusuri sa kalusugan. Ito ay maaaring isang napakasimpleng HTTP call check, kapag nakatanggap ka ng code na may status 200, o isang mas malalim na pagsusuri, kung saan sinusuri mo ang koneksyon ng mga replika sa database at iba pang mga serbisyo, ang katatagan ng mga dynamic na koneksyon sa kapaligiran , at kung ang lahat ay nagsisimula at gumagana nang tama. Ang prosesong ito ay maaaring maging kumplikado.
Pagkatapos ma-verify ng system na gumagana ang lahat ng na-update na replika, ia-update ng Deployer ang configuration at ipapasa ang tamang confd, na magre-reconfigure ng ha-proxy.
Pagkatapos lamang nito ididirekta ang trapiko sa pod na may mga replika ng bagong bersyon, at mawawala ang lumang pod.
Ang mekanismong ito ay hindi isang tampok ng Kubernetes. Ang konsepto ng Blue/green deployment ay medyo matagal na at ito ay palaging gumagamit ng load balancer. Una, ididirekta mo ang lahat ng trapiko sa lumang bersyon ng application, at pagkatapos ng pag-update, ganap mong ilipat ito sa bagong bersyon. Ang prinsipyong ito ay ginagamit hindi lamang sa Kubernetes.
Ngayon ay ipakikilala ko sa iyo ang isang bagong bahagi ng deployment - Deployer, na nagsasagawa ng mga pagsusuri sa kalusugan, muling nagko-configure ng mga proxy, at iba pa. Ito ay isang konsepto na hindi naaangkop sa labas ng mundo at umiiral sa loob ng Kubernetes. Ipapakita ko sa iyo kung paano ka makakagawa ng sarili mong konsepto ng Deployer gamit ang mga open-source na tool.
Kaya, ang unang bagay na ginagawa ng Deployer ay lumikha ng RC replication controller gamit ang Kubernetes API. Gumagawa ang API na ito ng mga pod at serbisyo para sa karagdagang deployment, ibig sabihin, lumilikha ito ng ganap na bagong cluster para sa aming mga application. Sa sandaling kumbinsido ang RC na nagsimula na ang mga replika, magsasagawa ito ng pagsusuri sa Kalusugan sa kanilang paggana. Para gawin ito, ginagamit ng Deployer ang GET /health command. Pinapatakbo nito ang naaangkop na mga bahagi ng pag-scan at sinusuri ang lahat ng elemento na sumusuporta sa pagpapatakbo ng cluster.
Matapos maiulat ng lahat ng pod ang kanilang kalusugan, gagawa ang Deployer ng bagong elemento ng configuration - etcd na ibinahagi na storage, na internal na ginagamit ng Kubernetes, kabilang ang pag-iimbak ng configuration ng load balancer. Nagsusulat kami ng data sa etcd, at isang maliit na tool na tinatawag na confd monitor etcd para sa bagong data.
Kung makakita ito ng anumang pagbabago sa paunang configuration, bubuo ito ng bagong file ng mga setting at ililipat ito sa ha-proxy. Sa kasong ito, nagre-reboot ang ha-proxy nang hindi nawawala ang anumang mga koneksyon at inia-address ang pag-load sa mga bagong serbisyo na nagpapagana sa bagong bersyon ng aming mga application na gumana.
Tulad ng nakikita mo, sa kabila ng kasaganaan ng mga sangkap, walang kumplikado dito. Kailangan mo lang bigyang pansin ang API at etcd. Gusto kong sabihin sa iyo ang tungkol sa open-source deployer na ginagamit namin mismo - Amdatu Kubernetes Deployer.
Ito ay isang tool para sa pagsasaayos ng mga pag-deploy ng Kubernetes at may mga sumusunod na tampok:
- Asul/Berde deployment;
- pag-set up ng external load balancer;
- pamamahala ng deskriptor ng deployment;
- pamamahala ng aktwal na pag-deploy;
- pagsuri sa functionality ng Health checks sa panahon ng deployment;
- pagpapatupad ng mga variable ng kapaligiran sa mga pod.
Ang Deployer na ito ay binuo sa ibabaw ng Kubernetes API at nagbibigay ng REST API para sa pamamahala ng mga handle at deployment, pati na rin ang Websocket API para sa mga streaming log sa panahon ng proseso ng deployment.
Inilalagay nito ang data ng pagsasaayos ng load balancer sa etcd, kaya hindi mo na kailangang gumamit ng ha-proxy na may out-of-the-box na suporta, ngunit madaling gamitin ang iyong sariling load balancer configuration file. Ang Amdatu Deployer ay nakasulat sa Go, tulad ng Kubernetes mismo, at lisensyado ng Apache.
Bago ko simulan ang paggamit ng bersyong ito ng deployer, ginamit ko ang sumusunod na descriptor ng deployment, na tumutukoy sa mga parameter na kailangan ko.
Isa sa mahahalagang parameter ng code na ito ay ang paganahin ang flag na βuseHealthCheckβ. Kailangan naming tukuyin na dapat magsagawa ng sanity check sa panahon ng proseso ng deployment. Maaaring i-disable ang setting na ito kapag gumagamit ang deployment ng mga third-party na container na hindi kailangang i-verify. Isinasaad din ng descriptor na ito ang bilang ng mga replika at ang frontend URL na kailangan ng ha-proxy. Sa dulo ay ang flag ng detalye ng pod na "podspec", na tumatawag sa Kubernetes para sa impormasyon sa configuration ng port, imahe, atbp. Ito ay isang medyo simpleng JSON descriptor.
Ang isa pang tool na bahagi ng open-source na proyekto ng Amdatu ay Deploymentctl. Mayroon itong UI para sa pag-configure ng mga deployment, pag-iimbak ng history ng deployment, at naglalaman ng mga webhook para sa mga callback mula sa mga user at developer ng third-party. Maaaring hindi mo gamitin ang UI dahil ang Amdatu Deployer mismo ay isang REST API, ngunit ang interface na ito ay maaaring gawing mas madali ang deployment para sa iyo nang hindi nagsasangkot ng anumang API. Ang Deploymentctl ay nakasulat sa OSGi/Vertx gamit ang Angular 2.
Ipapakita ko na ngayon ang nasa itaas sa screen gamit ang isang pre-record na recording para hindi mo na kailangang maghintay. Magde-deploy kami ng simpleng Go application. Huwag mag-alala kung hindi mo pa nasusubukan ang Go dati, ito ay isang napaka-simpleng application kaya dapat mong malaman ito.
Narito kami ay lumilikha ng isang HTTP server na tumutugon lamang sa /health, kaya ang application na ito ay sumusubok lamang sa pagsusuri sa kalusugan at wala nang iba pa. Kung pumasa ang tseke, gagamitin ang istruktura ng JSON na ipinapakita sa ibaba. Naglalaman ito ng bersyon ng application na ide-deploy ng deployer, ang mensaheng makikita mo sa itaas ng file, at ang boolean data type - kung gumagana ang aming application o hindi.
Medyo dinaya ko ang huling linya, dahil naglagay ako ng nakapirming boolean na halaga sa tuktok ng file, na sa hinaharap ay makakatulong sa akin na mag-deploy ng kahit isang "hindi malusog" na application. Haharapin natin ito mamaya.
Kaya simulan na natin. Una, sinusuri namin ang pagkakaroon ng anumang tumatakbong pods gamit ang command ~ kubectl get pods at, batay sa kawalan ng tugon mula sa frontend URL, tinitiyak namin na walang kasalukuyang ginagawa.
Susunod sa screen makikita mo ang Deploymentctl interface na binanggit ko, kung saan nakatakda ang mga parameter ng deployment: namespace, pangalan ng application, bersyon ng deployment, bilang ng mga replika, front-end URL, pangalan ng container, larawan, mga limitasyon sa mapagkukunan, numero ng port para sa pagsusuri sa kalusugan, atbp. Napakahalaga ng mga limitasyon sa mapagkukunan, dahil pinapayagan ka nitong gamitin ang maximum na posibleng dami ng hardware. Dito maaari mo ring tingnan ang Deployment log.
Kung uulitin mo ngayon ang utos ~ kubectl get pods, makikita mo na ang system ay "nag-freeze" sa loob ng 20 segundo, kung saan ang ha-proxy ay muling na-configure. Pagkatapos nito, magsisimula ang pod, at makikita ang aming replica sa deployment log.
Pinutol ko ang 20 segundong paghihintay mula sa video, at ngayon ay makikita mo sa screen na ang unang bersyon ng application ay na-deploy na. Ang lahat ng ito ay ginawa gamit lamang ang UI.
Ngayon subukan natin ang pangalawang bersyon. Para magawa ito, binago ko ang mensahe ng application mula sa "Hello, Kubernetes!" sa "Hello, Deployer!", nililikha ng system ang imaheng ito at inilalagay ito sa registry ng Docker, pagkatapos ay i-click lang namin ang button na "Deploy" muli sa window ng Deploymentctl. Sa kasong ito, ang deployment log ay awtomatikong inilulunsad sa parehong paraan tulad ng nangyari noong i-deploy ang unang bersyon ng application.
Ang command na ~ kubectl get pods ay nagpapakita na may kasalukuyang 2 bersyon ng application na tumatakbo, ngunit ipinapakita ng frontend na tumatakbo pa rin kami sa bersyon 1.
Hinihintay ng load balancer na makumpleto ang pagsusuri sa kalusugan bago i-redirect ang trapiko sa bagong bersyon. Pagkatapos ng 20 segundo, lumipat kami sa curl at makita na mayroon na kaming bersyon 2 ng application na na-deploy, at ang una ay tinanggal na.
Ito ang deployment ng isang "malusog" na application. Tingnan natin kung ano ang mangyayari kung para sa isang bagong bersyon ng application ay binago ko ang Healthy parameter mula sa true tungo sa false, iyon ay, sinusubukan kong mag-deploy ng hindi malusog na application na nabigo sa pagsusuri sa kalusugan. Ito ay maaaring mangyari kung ang ilang mga error sa pagsasaayos ay ginawa sa application sa yugto ng pagbuo, at ito ay ipinadala sa produksyon sa form na ito.
Tulad ng nakikita mo, ang deployment ay dumaan sa lahat ng mga hakbang sa itaas at ~kubectl get pods ay nagpapakita na ang parehong pods ay tumatakbo. Ngunit hindi tulad ng nakaraang deployment, ipinapakita ng log ang status ng timeout. Iyon ay, dahil sa ang katunayan na ang pagsusuri sa kalusugan ay nabigo, ang bagong bersyon ng application ay hindi maaaring i-deploy. Bilang resulta, makikita mo na ang system ay bumalik sa paggamit ng lumang bersyon ng application, at ang bagong bersyon ay na-uninstall lang.
Ang magandang bagay tungkol dito ay kahit na mayroon kang isang malaking bilang ng mga sabay-sabay na kahilingan na dumarating sa application, hindi nila mapapansin ang downtime habang ipinapatupad ang pamamaraan ng pag-deploy. Kung susubukan mo ang application na ito gamit ang Gatling framework, na nagpapadala dito ng maraming kahilingan hangga't maaari, wala sa mga kahilingang ito ang aalisin. Nangangahulugan ito na hindi mapapansin ng aming mga user ang mga update sa bersyon sa real time. Kung nabigo ito, magpapatuloy ang trabaho sa lumang bersyon; kung matagumpay ito, lilipat ang mga user sa bagong bersyon.
Mayroon lamang isang bagay na maaaring mabigo - kung ang pagsusuri sa kalusugan ay magtagumpay, ngunit ang aplikasyon ay nabigo sa sandaling mailapat ang workload dito, iyon ay, ang pagbagsak ay magaganap lamang pagkatapos makumpleto ang pag-deploy. Sa kasong ito, kakailanganin mong manu-manong i-roll pabalik sa lumang bersyon. Kaya, tiningnan namin kung paano gamitin ang Kubernetes gamit ang mga open-source na tool na idinisenyo para dito. Magiging mas madali ang proseso ng pag-deploy kung gagawin mo ang mga tool na ito sa iyong mga pipeline ng Build/Deploy. Kasabay nito, upang simulan ang deployment, maaari mong gamitin ang alinman sa user interface o ganap na i-automate ang prosesong ito sa pamamagitan ng paggamit, halimbawa, commit to master.
Ang aming Build Server ay lilikha ng isang imahe ng Docker, itulak ito sa Docker Hub o anumang registry na iyong ginagamit. Sinusuportahan ng Docker Hub ang webhook, upang ma-trigger namin ang malayuang pag-deploy sa pamamagitan ng Deployer sa paraang ipinapakita sa itaas. Sa ganitong paraan maaari mong ganap na i-automate ang deployment ng iyong application sa potensyal na produksyon.
Lumipat tayo sa susunod na paksa - pag-scale sa cluster ng Kubernetes. Tandaan na ang kubectl command ay isang scaling command. Sa higit pang tulong, madali nating madadagdagan ang bilang ng mga replika sa ating kasalukuyang cluster. Gayunpaman, sa pagsasagawa, karaniwang gusto naming dagdagan ang bilang ng mga node kaysa sa mga pod.
Kasabay nito, sa mga oras ng pagtatrabaho ay maaaring kailanganin mong tumaas, at sa gabi, upang mabawasan ang gastos ng mga serbisyo ng Amazon, maaaring kailanganin mong bawasan ang bilang ng mga tumatakbong pagkakataon ng aplikasyon. Hindi ito nangangahulugan na ang pag-scale lamang ng bilang ng mga pod ay sapat na, dahil kahit na ang isa sa mga node ay idle, kailangan mo pa ring bayaran ang Amazon para dito. Iyon ay, kasama ang pag-scale ng mga pod, kakailanganin mong sukatin ang bilang ng mga machine na ginamit.
Maaari itong maging mapaghamong dahil gumagamit man tayo ng Amazon o ibang serbisyo sa cloud, walang alam ang Kubernetes tungkol sa bilang ng mga machine na ginagamit. Wala itong tool na nagbibigay-daan sa iyo na sukatin ang system sa antas ng node.
Kaya kailangan nating pangalagaan ang parehong mga node at pod. Madali nating masusukat ang paglulunsad ng mga bagong node gamit ang AWS API at Scaling group machine para i-configure ang bilang ng mga node ng manggagawa sa Kubernetes. Maaari mo ring gamitin ang cloud-init o isang katulad na script upang magrehistro ng mga node sa cluster ng Kubernetes.
Nagsisimula ang bagong makina sa pangkat ng Scaling, nagsisimula ang sarili bilang isang node, nagrerehistro sa master's registry at nagsimulang magtrabaho. Pagkatapos nito, maaari mong dagdagan ang bilang ng mga replika para magamit sa mga resultang node. Ang pag-scale pababa ay nangangailangan ng higit na pagsisikap, dahil kailangan mong tiyakin na ang ganitong hakbang ay hindi hahantong sa pagkasira ng tumatakbo nang mga application pagkatapos i-off ang "hindi kailangan" na mga makina. Upang maiwasan ang gayong senaryo, kailangan mong itakda ang mga node sa katayuang "hindi maiiskedyul". Nangangahulugan ito na babalewalain ng default na scheduler ang mga node na ito kapag nag-iiskedyul ng mga DaemonSet pod. Ang scheduler ay hindi magtatanggal ng anuman mula sa mga server na ito, ngunit hindi rin maglulunsad ng mga bagong container doon. Ang susunod na hakbang ay ang paalisin ang drain node, iyon ay, upang ilipat ang mga tumatakbong pod mula dito patungo sa isa pang makina, o iba pang mga node na may sapat na kapasidad para dito. Kapag natiyak mo na na wala nang anumang container sa mga node na ito, maaari mong alisin ang mga ito sa Kubernetes. Pagkatapos nito, sila ay titigil na sa pag-iral para sa Kubernetes. Susunod, kailangan mong gamitin ang AWS API para i-disable ang mga hindi kinakailangang node o machine.
Maaari mong gamitin ang Amdatu Scalerd, isa pang open-source scaling tool na katulad ng AWS API. Nagbibigay ito ng CLI para magdagdag o mag-alis ng mga node sa isang cluster. Ang kawili-wiling tampok nito ay ang kakayahang i-configure ang scheduler gamit ang sumusunod na json file.
Binabawasan ng ipinapakitang code ang kapasidad ng cluster ng kalahati sa panahon ng gabi. Kino-configure nito ang parehong bilang ng mga replika na magagamit at ang nais na kapasidad ng Amazon cluster. Ang paggamit ng scheduler na ito ay awtomatikong babawasan ang bilang ng mga node sa gabi at tataas ang mga ito sa umaga, na nakakatipid sa gastos ng paggamit ng mga node mula sa isang cloud service tulad ng Amazon. Ang tampok na ito ay hindi binuo sa Kubernetes, ngunit ang paggamit ng Scalerd ay magbibigay-daan sa iyo na sukatin ang platform na ito gayunpaman ang gusto mo.
Gusto kong ituro na maraming tao ang nagsasabi sa akin, "Mabuti at mabuti iyan, ngunit paano ang aking database, na karaniwang static?" Paano mo mapapatakbo ang isang bagay na tulad nito sa isang dynamic na kapaligiran tulad ng Kubernetes? Sa aking opinyon, hindi mo dapat gawin ito, hindi mo dapat subukang magpatakbo ng isang data warehouse sa Kubernetes. Posible ito sa teknikal, at may mga tutorial sa Internet sa paksang ito, ngunit seryoso itong magpapalubha sa iyong buhay.
Oo, mayroong isang konsepto ng mga paulit-ulit na tindahan sa Kubernetes, at maaari mong subukang magpatakbo ng mga data store tulad ng Mongo o MySQL, ngunit ito ay medyo isang labor-intensive na gawain. Ito ay dahil sa ang katunayan na ang mga warehouse ng data ay hindi ganap na sumusuporta sa pakikipag-ugnayan sa isang dynamic na kapaligiran. Karamihan sa mga database ay nangangailangan ng makabuluhang pagsasaayos, kabilang ang manu-manong pagsasaayos ng kumpol, ay hindi gusto ang autoscaling at iba pang katulad na bagay.
Samakatuwid, hindi mo dapat gawing kumplikado ang iyong buhay sa pamamagitan ng pagsubok na magpatakbo ng isang data warehouse sa Kubernetes. Ayusin ang kanilang trabaho sa tradisyunal na paraan gamit ang mga pamilyar na serbisyo at bigyan lang ang Kubernetes ng kakayahang gamitin ang mga ito.
Upang tapusin ang paksa, gusto kong ipakilala sa iyo ang Cloud RTI platform batay sa Kubernetes, na pinagtatrabahuhan ng aking team. Nagbibigay ito ng sentralisadong pag-log, aplikasyon at pagsubaybay sa kumpol, at marami pang ibang kapaki-pakinabang na tampok na magagamit. Gumagamit ito ng iba't ibang mga open-source na tool tulad ng Grafana upang ipakita ang pagsubaybay.
May tanong tungkol sa kung bakit gagamitin ang ha-proxy load balancer sa Kubernetes. Magandang tanong dahil kasalukuyang may 2 level ng load balancing. Ang mga serbisyo ng Kubernetes ay nananatili pa rin sa mga virtual na IP address. Hindi mo magagamit ang mga ito para sa mga port sa mga external na host machine dahil kung ma-overload ng Amazon ang cloud host nito, magbabago ang address. Ito ang dahilan kung bakit naglalagay kami ng ha-proxy sa harap ng mga serbisyo - upang lumikha ng mas static na istraktura para sa trapiko upang makipag-usap nang walang putol sa Kubernetes.
Ang isa pang magandang tanong ay kung paano mo mapangangalagaan ang mga pagbabago sa schema ng database kapag gumagawa ng blue/green deployment? Ang katotohanan ay anuman ang paggamit ng Kubernetes, ang pagbabago ng database schema ay isang mahirap na gawain. Kailangan mong tiyakin na ang luma at bagong schema ay magkatugma, pagkatapos nito maaari mong i-update ang database at pagkatapos ay i-update ang mga application mismo. Maaari mong hot swap ang database at pagkatapos ay i-update ang mga application. May kilala akong mga tao na nag-boot ng isang ganap na bagong database cluster na may bagong schema, ito ay isang opsyon kung mayroon kang isang schemeless database tulad ng Mongo, ngunit hindi ito isang madaling gawain pa rin. Kung wala kang karagdagang katanungan, salamat sa iyong pansin!
Ilang ad π
Salamat sa pananatili sa amin. Gusto mo ba ang aming mga artikulo? Gustong makakita ng mas kawili-wiling nilalaman? Suportahan kami sa pamamagitan ng pag-order o pagrekomenda sa mga kaibigan, , isang natatanging analogue ng mga entry-level na server, na inimbento namin para sa iyo: (magagamit sa RAID1 at RAID10, hanggang 24 na core at hanggang 40GB DDR4).
Dell R730xd 2x na mas mura sa Equinix Tier IV data center sa Amsterdam? Dito lang sa Netherlands! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - mula $99! Basahin ang tungkol sa
Pinagmulan: www.habr.com