Ang Kubernetes usa ka maayo nga himan alang sa pagpadagan sa mga sudlanan sa Docker sa usa ka clustered production environment. Bisan pa, adunay mga problema nga dili masulbad sa Kubernetes. Alang sa kanunay nga pag-deploy sa produksiyon, nanginahanglan kami usa ka hingpit nga awtomatiko nga pag-deploy sa Blue/Green aron malikayan ang downtime sa proseso, nga kinahanglan usab nga magdumala sa mga hangyo sa gawas nga HTTP ug maghimo mga pag-offload sa SSL. Nagkinahanglan kini og integrasyon sa usa ka load balancer sama sa ha-proxy. Ang laing hagit mao ang semi-awtomatikong pag-scale sa Kubernetes cluster mismo kung nagdagan sa cloud environment, pananglitan ang partially scaling sa cluster down sa gabii.
Samtang ang Kubernetes walay kini nga mga bahin sa gawas sa kahon, kini naghatag og API nga imong magamit sa pagsulbad sa susamang mga problema. Ang mga himan alang sa automated nga Blue/Green deployment ug scaling sa usa ka Kubernetes cluster gimugna isip kabahin sa Cloud RTI project, nga gimugna base sa open-source.
Kini nga artikulo, usa ka transcript sa video, nagpakita kanimo kung giunsa ang pag-set up sa Kubernetes kauban ang uban pang mga open source nga sangkap aron makahimo usa ka palibot nga andam sa produksiyon nga modawat sa code gikan sa usa ka git commit nga walaβy downtime sa produksiyon.
Mao nga, kung adunay ka access sa imong mga aplikasyon gikan sa gawas sa kalibutan, mahimo ka magsugod sa hingpit nga pag-set up sa automation, nga mao, dad-on kini sa entablado diin mahimo nimo ang usa ka git commit ug siguruha nga kini nga git commit matapos sa produksiyon. Natural, kung ipatuman kini nga mga lakang, kung ipatuman ang pag-deploy, dili namon gusto nga makasugat sa downtime. Busa, ang bisan unsang automation sa Kubernetes magsugod sa API.
Ang Kubernetes dili usa ka himan nga mahimong magamit nga produktibo sa gawas sa kahon. Siyempre, mahimo nimo kana, gamit ang kubectl ug uban pa, apan sa gihapon ang API mao ang labing makapaikag ug mapuslanon nga butang bahin sa kini nga plataporma. Pinaagi sa paggamit sa API isip usa ka hugpong sa mga gimbuhaton, mahimo nimong ma-access ang halos bisan unsa nga gusto nimong buhaton sa Kubernetes. Ang kubectl mismo naggamit usab sa REST API.
Kini mao ang REST, aron makagamit ka sa bisan unsang pinulongan o himan sa pagtrabaho uban niini nga API, apan ang imong kinabuhi mahimong mas sayon ββpinaagi sa naandan nga mga librarya. Gisulat sa akong team ang 2 sa ingon nga mga librarya: usa alang sa Java / OSGi ug usa alang sa Go. Ang ikaduha dili kanunay nga gigamit, apan sa bisan unsang kaso naa nimo kini nga mapuslanon nga mga butang nga imong magamit. Sila usa ka partially lisensyado nga open-source nga proyekto. Adunay daghang ingon nga mga librarya alang sa lainlaing mga lengguwahe, aron mapili nimo ang labing angay kanimo.
Mao nga, sa dili ka pa magsugod sa pag-automate sa imong pag-deploy, kinahanglan nimo nga sigurohon nga ang proseso dili mapailalom sa bisan unsang downtime. Pananglitan, ang among team nagpahigayon sa mga pag-deploy sa produksiyon sa tunga-tunga sa adlaw kung ang mga tawo naggamit sa mga aplikasyon sa labing kadaghan, busa hinungdanon nga malikayan ang mga paglangan sa kini nga proseso. Aron malikayan ang downtime, 2 ka pamaagi ang gigamit: blue/green deployment o rolling update. Sa ulahi nga kaso, kung ikaw adunay 5 nga mga kopya sa aplikasyon nga nagdagan, sila gi-update nga sunud-sunod sa usag usa. Kini nga pamaagi maayo kaayo, apan dili kini angay kung adunay ka lainlaing mga bersyon sa aplikasyon nga dungan nga nagdagan sa panahon sa proseso sa pag-deploy. Sa kini nga kaso, mahimo nimong i-update ang user interface samtang ang backend nagpadagan sa daan nga bersyon, ug ang aplikasyon mohunong sa pagtrabaho. Busa, gikan sa punto sa pagprograma, ang pagtrabaho sa ingon nga mga kahimtang lisud kaayo.
Kini ang usa sa mga hinungdan ngano nga gusto namon nga gamiton ang asul / berde nga pag-deploy aron ma-automate ang pag-deploy sa among mga aplikasyon. Uban niini nga pamaagi, kinahanglan nimong sigurohon nga usa ra ka bersyon sa aplikasyon ang aktibo matag higayon.
Ang asul / berde nga mekanismo sa pag-deploy ingon niini. Nakadawat kami og trapiko alang sa among mga aplikasyon pinaagi sa ha-proxy, nga nagpasa niini sa pagpadagan sa mga replika sa aplikasyon sa parehas nga bersyon.
Kung ang usa ka bag-ong deployment gihimo, among gigamit ang Deployer, nga gihatagan sa bag-ong mga sangkap ug nag-deploy sa bag-ong bersyon. Ang pag-deploy ug bag-ong bersyon sa usa ka aplikasyon nagpasabot nga ang usa ka bag-ong set sa mga replika ang "gipataas", pagkahuman niini nga mga kopya sa bag-ong bersyon gilusad sa usa ka bulag, bag-ong pod. Bisan pa, ang ha-proxy walaβy nahibal-an bahin kanila ug wala pa mag-ruta sa bisan unsang buluhaton sa kanila.
Busa, una sa tanan, kinahanglan nga maghimo usa ka pagsusi sa pasundayag sa mga bag-ong bersyon sa pagsusi sa kahimsog aron masiguro nga ang mga replika andam sa pag-alagad sa karga.
Ang tanan nga mga sangkap sa pag-deploy kinahanglan nga mosuporta sa usa ka porma sa pagsusi sa kahimsog. Mahimo kini nga usa ka yano kaayo nga pagsusi sa tawag sa HTTP, kung makadawat ka usa ka code nga adunay status 200, o usa ka labi ka lawom nga pagsusi, diin imong susihon ang koneksyon sa mga replika sa database ug uban pang mga serbisyo, ang kalig-on sa mga dinamikong koneksyon sa palibot. , ug kung ang tanan nagsugod ug nagtrabaho sa husto. Kini nga proseso mahimong komplikado kaayo.
Human mapamatud-an sa sistema nga ang tanan nga gi-update nga mga replika nagtrabaho, ang Deployer mag-update sa configuration ug mopasa sa husto nga confd, nga mag-reconfigure sa ha-proxy.
Pagkahuman lamang niini ang trapiko idirekta sa pod nga adunay mga replika sa bag-ong bersyon, ug ang daan nga pod mawala.
Kini nga mekanismo dili usa ka bahin sa Kubernetes. Ang konsepto sa Blue/green deployment dugay na ug kini kanunay nga naggamit ug load balancer. Una, idirekta nimo ang tanan nga trapiko sa daan nga bersyon sa aplikasyon, ug pagkahuman sa pag-update, hingpit nimo nga ibalhin kini sa bag-ong bersyon. Kini nga prinsipyo gigamit dili lamang sa Kubernetes.
Karon ipaila ko kanimo ang usa ka bag-ong bahin sa pag-deploy - Deployer, nga nagpahigayon mga pagsusi sa kahimsog, pag-reconfigure sa mga proxy, ug uban pa. Kini usa ka konsepto nga wala magamit sa gawas nga kalibutan ug anaa sa sulod sa Kubernetes. Ipakita ko kanimo kung giunsa nimo paghimo ang imong kaugalingon nga konsepto sa Deployer gamit ang mga himan nga bukas nga gigikanan.
Busa, ang unang butang nga gihimo sa Deployer mao ang paghimo og RC replication controller gamit ang Kubernetes API. Kini nga API nagmugna og mga pod ug mga serbisyo alang sa dugang nga pag-deploy, nga mao, kini nagmugna og usa ka hingpit nga bag-ong cluster para sa among mga aplikasyon. Sa diha nga ang RC kombinsido nga ang mga replika nagsugod na, kini mopahigayon sa usa ka Health check sa ilang mga gamit. Aron mahimo kini, ang Deployer naggamit sa GET / health command. Gipadagan niini ang angay nga mga sangkap sa pag-scan ug gisusi ang tanan nga mga elemento nga nagsuporta sa operasyon sa cluster.
Human ma-report sa tanan nga pod ang ilang kahimsog, ang Deployer nagmugna usa ka bag-ong elemento sa pag-configure - etcd giapod-apod nga pagtipig, nga gigamit sa sulod sa mga Kubernetes, lakip ang pagtipig sa pag-configure sa load balancer. Nagsulat kami og data sa etcd, ug usa ka gamay nga himan nga gitawag og confd monitors etcd para sa bag-ong datos.
Kung nakamatikod kini sa bisan unsang mga pagbag-o sa inisyal nga pag-configure, nagmugna kini usa ka bag-ong file sa setting ug gibalhin kini sa ha-proxy. Sa kini nga kaso, ang ha-proxy mag-reboot nga dili mawad-an sa bisan unsang koneksyon ug gitubag ang load sa mga bag-ong serbisyo nga makapaarang sa bag-ong bersyon sa among mga aplikasyon nga molihok.
Sama sa imong nakita, bisan pa sa kadaghan sa mga sangkap, walaβy komplikado dinhi. Kinahanglan lang nimo nga hatagan og dugang nga pagtagad ang API ug uban pa. Gusto nako isulti kanimo ang bahin sa open-source deployer nga among gigamit mismo - Amdatu Kubernetes Deployer.
Kini usa ka himan alang sa pag-orkestra sa mga pag-deploy sa Kubernetes ug adunay mga mosunod nga bahin:
- Asul/Berde nga pagdeploy;
- paghimo og external load balancer;
- pagdumala sa deskriptor sa deployment;
- pagdumala sa aktuwal nga deployment;
- pagsusi sa gamit sa Health checks sa panahon sa deployment;
- pagpatuman sa environment variables ngadto sa pods.
Kini nga Deployer gitukod sa ibabaw sa Kubernetes API ug naghatag usa ka REST API alang sa pagdumala sa mga gunitanan ug pag-deploy, ingon man usa ka Websocket API alang sa streaming nga mga log sa panahon sa proseso sa pag-deploy.
Kini nagbutang sa load balancer configuration data ngadto sa etcd, mao nga dili ka kinahanglan nga mogamit sa ha-proxy nga adunay out-of-the-box nga suporta, apan dali gamiton ang imong kaugalingong load balancer configuration file. Ang Amdatu Deployer gisulat sa Go, sama sa Kubernetes mismo, ug lisensyado sa Apache.
Sa wala pa ko magsugod sa paggamit niini nga bersyon sa deployer, gigamit nako ang mosunod nga deployment descriptor, nga nagtino sa mga parameter nga akong gikinahanglan.
Usa sa importante nga mga parametro niini nga code mao ang pagpagana sa bandila nga "useHealthCheck". Kinahanglan natong ipiho nga ang usa ka sanity check kinahanglan nga himuon sa panahon sa proseso sa pag-deploy. Kini nga setting mahimong ma-disable kung ang deployment naggamit sa mga sudlanan sa ikatulo nga partido nga dili kinahanglan nga mapamatud-an. Gipakita usab niini nga deskriptor ang gidaghanon sa mga replika ug ang frontend URL nga gikinahanglan sa ha-proxy. Sa katapusan mao ang pod specification flag "podspec", nga nagtawag sa Kubernetes alang sa impormasyon sa port configuration, image, etc. Kini usa ka yano nga JSON descriptor.
Ang laing himan nga kabahin sa open-source Amdatu nga proyekto mao ang Deploymentctl. Kini adunay UI alang sa pag-configure sa mga pag-deploy, mga tindahan sa kasaysayan sa pag-deploy, ug adunay mga webhook alang sa mga callback gikan sa mga tiggamit ug developer sa ikatulo nga partido. Mahimong dili nimo gamiton ang UI tungod kay ang Amdatu Deployer mismo usa ka REST API, apan kini nga interface makahimo sa pag-deploy nga labi ka dali alang kanimo nga wala mag-apil sa bisan unsang API. Ang Deploymentctl gisulat sa OSGi/Vertx gamit ang Angular 2.
Akong ipakita karon ang naa sa ibabaw sa screen gamit ang pre-record nga recording para dili na ka maghulat. Mag-deploy kami usa ka yano nga aplikasyon sa Go. Ayaw kabalaka kung wala pa nimo nasulayan ang Go kaniadto, kini usa ka yano nga aplikasyon aron mahimo nimo kini mahibal-an.
Dinhi naghimo kami usa ka HTTP server nga motubag lamang sa / kahimsog, mao nga kini nga aplikasyon nagsulay lamang sa pagsusi sa kahimsog ug wala nay lain. Kung ang tseke moagi, ang istruktura sa JSON nga gipakita sa ubos gigamit. Naglangkob kini sa bersyon sa aplikasyon nga i-deploy sa nag-deploy, ang mensahe nga imong makita sa ibabaw sa file, ug ang boolean data type - kung ang among aplikasyon nagtrabaho o wala.
Gilimbongan ko ang usa ka gamay sa katapusang linya, tungod kay gibutang ko ang usa ka piho nga boolean nga kantidad sa ibabaw sa file, nga sa umaabot makatabang kanako sa pag-deploy bisan usa ka "dili maayo" nga aplikasyon. Ato kining atubangon unya.
So sugdan na nato. Una, gisusi namo ang presensya sa bisan unsang running pod gamit ang command ~ kubectl get pods ug, base sa pagkawala sa tubag gikan sa frontend URL, among gisiguro nga walay deployment nga gihimo karon.
Sunod sa screen imong makita ang Deploymentctl interface nga akong gihisgutan, diin ang deployment parameters gitakda: namespace, application name, deployment version, number of replicas, front-end URL, container name, image, resource limits, port number for health check, ug uban pa. Ang mga limitasyon sa kahinguhaan importante kaayo, tungod kay kini nagtugot kanimo sa paggamit sa pinakataas nga posible nga gidaghanon sa hardware. Dinhi mahimo usab nimo tan-awon ang Deployment log.
Kung gisubli nimo karon ang command ~ kubectl get pods, imong makita nga ang sistema "nag-freeze" sulod sa 20 segundos, diin ang ha-proxy gi-reconfigure. Pagkahuman niini, magsugod ang pod, ug ang among replika makita sa deployment log.
Giputol nako ang 20 segundos nga paghulat gikan sa video, ug karon imong makita sa screen nga ang unang bersyon sa aplikasyon na-deploy na. Kining tanan gihimo gamit lamang ang UI.
Karon atong sulayan ang ikaduhang bersyon. Aron mahimo kini, akong usbon ang mensahe sa aplikasyon gikan sa "Hello, Kubernetes!" sa "Hello, Deployer!", Ang sistema nagmugna niini nga imahe ug gibutang kini sa Docker registry, pagkahuman gi-klik lang namon ang "Deploy" nga buton pag-usab sa Deploymentctl window. Niini nga kaso, ang deployment log awtomatik nga gilunsad sa samang paagi sama sa nahitabo sa dihang nag-deploy sa unang bersyon sa aplikasyon.
Ang command ~ kubectl get pods nagpakita nga adunay karon nga 2 nga bersyon sa aplikasyon nga nagdagan, apan ang frontend nagpakita nga kita nagdagan gihapon nga bersyon 1.
Ang load balancer naghulat nga makompleto ang pagsusi sa kahimsog sa dili pa i-redirect ang trapiko sa bag-ong bersyon. Human sa 20 segundos, mobalhin mi sa curl ug tan-awa nga aduna na kami bersyon 2 sa aplikasyon nga gipakatap, ug ang una natangtang na.
Kini ang pag-deploy sa usa ka "himsog" nga aplikasyon. Atong tan-awon kung unsa ang mahitabo kung alang sa usa ka bag-ong bersyon sa aplikasyon akong usbon ang Healthy parameter gikan sa tinuod ngadto sa bakak, nga mao, gisulayan nako ang pag-deploy sa usa ka dili maayo nga aplikasyon nga napakyas sa pagsusi sa kahimsog. Mahimo kini mahitabo kung ang pipila ka mga sayup sa pag-configure nahimo sa aplikasyon sa yugto sa pag-uswag, ug kini gipadala sa produksiyon sa kini nga porma.
Sama sa imong makita, ang deployment moagi sa tanan nga mga lakang sa ibabaw ug ~kubectl get pods nagpakita nga ang duha pods nagdagan. Apan dili sama sa miaging deployment, ang log nagpakita sa timeout status. Kana mao, tungod sa kamatuoran nga napakyas ang pagsusi sa kahimsog, ang bag-ong bersyon sa aplikasyon dili ma-deploy. Ingon usa ka sangputanan, imong nakita nga ang sistema mibalik sa paggamit sa daan nga bersyon sa aplikasyon, ug ang bag-ong bersyon na-uninstall na.
Ang maayo nga butang bahin niini mao nga bisan kung adunay ka daghang dungan nga mga hangyo nga moabut sa aplikasyon, dili nila mamatikdan ang downtime samtang gipatuman ang pamaagi sa pag-deploy. Kung imong sulayan kini nga aplikasyon gamit ang Gatling framework, nga nagpadala niini sa daghang mga hangyo kutob sa mahimo, nan walay bisan usa niini nga mga hangyo ang ihulog. Kini nagpasabot nga ang among mga tiggamit dili gani makamatikod sa mga update sa bersyon sa tinuod nga panahon. Kung kini mapakyas, ang trabaho magpadayon sa daan nga bersyon; kung kini malampuson, ang mga tiggamit mobalhin sa bag-ong bersyon.
Adunay usa lamang ka butang nga mapakyas - kung ang pagsusi sa kahimsog molampos, apan ang aplikasyon mapakyas sa diha nga ang workload magamit niini, nga mao, ang pagkahugno mahitabo lamang pagkahuman sa pag-deploy. Sa kini nga kaso, kinahanglan nimo nga mano-mano nga ibalik ang daan nga bersyon. Mao nga, gitan-aw namon kung giunsa ang paggamit sa Kubernetes gamit ang bukas nga gigikanan nga mga himan nga gidisenyo alang niini. Ang proseso sa pag-deploy mahimong labi ka dali kung imong tukuron kini nga mga himan sa imong Build/Deploy pipelines. Sa samang higayon, aron masugdan ang pag-deploy, mahimo nimong gamiton ang user interface o hingpit nga i-automate kini nga proseso pinaagi sa paggamit, pananglitan, commit sa master.
Ang among Build Server maghimo usa ka imahe sa Docker, iduso kini sa Docker Hub o bisan unsang rehistro nga imong gigamit. Gisuportahan sa Docker Hub ang webhook, aron ma-trigger namon ang hilit nga pag-deploy pinaagi sa Deployer sa paagi nga gipakita sa ibabaw. Niining paagiha mahimo nimong hingpit nga ma-automate ang pag-deploy sa imong aplikasyon sa potensyal nga produksiyon.
Mopadayon kita sa sunod nga hilisgutan - ang pag-scale sa cluster sa Kubernetes. Timan-i nga ang kubectl command kay usa ka scaling command. Uban sa dugang nga tabang, dali natong madugangan ang gidaghanon sa mga replika sa atong kasamtangan nga cluster. Bisan pa, sa praktis, kasagaran gusto namon nga madugangan ang gidaghanon sa mga node kaysa mga pod.
Sa samang higayon, sa mga oras sa pagtrabaho tingali kinahanglan nimo nga dugangan, ug sa gabii, aron makunhuran ang gasto sa mga serbisyo sa Amazon, kinahanglan nimo nga pakunhuran ang gidaghanon sa nagdagan nga mga higayon sa aplikasyon. Wala kini magpasabut nga igo na ang pag-scale sa gidaghanon sa mga pod, tungod kay bisan kung ang usa sa mga node walaβy mahimo, kinahanglan nimo nga bayran ang Amazon alang niini. Kana mao, uban sa pag-scale sa mga pod, kinahanglan nimo nga sukdon ang gidaghanon sa mga makina nga gigamit.
Mahimong mahagit kini tungod kay kung mogamit kami sa Amazon o lain nga serbisyo sa panganod, walaβy nahibal-an ang Kubernetes bahin sa gidaghanon sa mga makina nga gigamit. Wala kini usa ka himan nga nagtugot kanimo sa pag-scale sa sistema sa lebel sa node.
Busa kinahanglan natong atimanon ang mga node ug pods. Dali namong ma-scale ang paglansad sa mga bag-ong node gamit ang AWS API ug Scaling group machines aron ma-configure ang gidaghanon sa mga Kubernetes worker node. Mahimo usab nimong gamiton ang cloud-init o susama nga script aron marehistro ang mga node sa cluster sa Kubernetes.
Ang bag-ong makina nagsugod sa grupo sa Scaling, nagsugod sa kaugalingon isip usa ka node, nagparehistro sa master's registry ug nagsugod sa pagtrabaho. Pagkahuman niini, mahimo nimong madugangan ang gidaghanon sa mga replika para magamit sa mga sangputanan nga node. Ang pag-scale sa ubos nanginahanglan dugang nga paningkamot, tungod kay kinahanglan nimo nga sigurohon nga ang ingon nga lakang dili mosangpot sa pagkaguba sa nagdagan na nga mga aplikasyon pagkahuman gipalong ang "dili kinahanglan" nga mga makina. Aron mapugngan ang ingon nga senaryo, kinahanglan nimo nga ibutang ang mga node sa "dili ma-iskedyul" nga kahimtang. Kini nagpasabot nga ang default scheduler dili magtagad niini nga mga node sa diha nga ang pag-iskedyul sa DaemonSet pods. Ang scheduler dili magtangtang sa bisan unsa gikan niini nga mga server, apan dili usab maglunsad og bag-ong mga sudlanan didto. Ang sunod nga lakang mao ang pagtangtang sa drain node, nga mao, ang pagbalhin sa nagdagan nga mga pod gikan niini ngadto sa laing makina, o ubang mga node nga adunay igong kapasidad alang niini. Kung nakasiguro ka nga wala nay bisan unsang mga sulud sa kini nga mga node, mahimo nimong tangtangon kini gikan sa Kubernetes. Human niini, sila mohunong na sa paglungtad alang sa Kubernetes. Sunod, kinahanglan nimong gamiton ang AWS API aron ma-disable ang dili kinahanglan nga mga node o makina.
Mahimo nimong gamiton ang Amdatu Scalerd, laing open-source scaling tool nga susama sa AWS API. Naghatag kini og CLI aron idugang o kuhaon ang mga node sa usa ka cluster. Ang makapainteres nga bahin niini mao ang abilidad sa pag-configure sa scheduler gamit ang mosunod nga json file.
Ang gipakita nga code nagpamenos sa kapasidad sa cluster sa katunga sa panahon sa kagabhion. Gi-configure niini ang gidaghanon sa mga replika nga magamit ug ang gitinguha nga kapasidad sa Amazon cluster. Ang paggamit niini nga scheduler awtomatik nga makunhuran ang gidaghanon sa mga node sa gabii ug madugangan kini sa buntag, makaluwas sa gasto sa paggamit sa mga node gikan sa cloud service sama sa Amazon. Kini nga bahin wala gitukod sa Kubernetes, apan ang paggamit sa Scalerd magtugot kanimo sa pag-scale niini nga plataporma bisan unsa ang imong gusto.
Gusto nakong ipunting nga daghang mga tawo ang nagsulti kanako, "Kana tanan maayo ug maayo, apan unsa ang bahin sa akong database, nga kasagaran static?" Giunsa nimo pagpadagan ang usa ka butang nga sama niini sa usa ka dinamikong palibot sama sa Kubernetes? Sa akong opinyon, dili nimo kini buhaton, dili nimo kinahanglan nga sulayan ang pagpadagan sa usa ka bodega sa datos sa Kubernetes. Posible kini sa teknikal, ug adunay mga panudlo sa Internet bahin niini nga hilisgutan, apan kini seryoso nga komplikado ang imong kinabuhi.
Oo, adunay usa ka konsepto sa makanunayon nga mga tindahan sa Kubernetes, ug mahimo nimong sulayan ang pagpadagan sa mga tindahan sa datos sama sa Mongo o MySQL, apan kini usa ka buluhaton nga kusog sa pagtrabaho. Kini tungod sa kamatuoran nga ang mga bodega sa datos dili hingpit nga nagsuporta sa interaksyon sa usa ka dinamikong palibot. Kadaghanan sa mga database nanginahanglan hinungdanon nga pag-configure, lakip ang manual nga pag-configure sa cluster, dili gusto ang autoscaling ug uban pang parehas nga mga butang.
Busa, dili nimo kinahanglan nga komplikado ang imong kinabuhi pinaagi sa pagsulay sa pagpadagan sa usa ka bodega sa datos sa Kubernetes. I-organisar ang ilang trabaho sa tradisyonal nga paagi gamit ang pamilyar nga mga serbisyo ug hatagan lang ang Kubernetes og abilidad sa paggamit niini.
Aron tapuson ang hilisgutan, gusto nako nga ipaila kanimo ang platform sa Cloud RTI nga gibase sa Kubernetes, nga gitrabaho sa akong team. Naghatag kini og sentralisadong pag-log, aplikasyon ug pag-monitor sa cluster, ug daghang uban pang mapuslanon nga mga bahin nga magamit. Gigamit niini ang lainlaing mga himan nga bukas nga gigikanan sama sa Grafana aron ipakita ang pag-monitor.
Adunay pangutana kung nganong gigamit ang ha-proxy load balancer sa Kubernetes. Maayo nga pangutana tungod kay sa pagkakaron adunay 2 nga lebel sa pagbalanse sa load. Ang mga serbisyo sa Kubernetes anaa gihapon sa mga virtual IP address. Dili nimo kini magamit alang sa mga pantalan sa mga eksternal nga host machine tungod kay kung ang Amazon mag-overload sa cloud host niini, ang adres mausab. Mao kini ang hinungdan nga nagbutang kami og ha-proxy sa atubangan sa mga serbisyo - aron makahimo og mas static nga istruktura para sa trapiko nga makigkomunikar sa mga Kubernetes.
Ang laing maayo nga pangutana mao kung giunsa nimo pag-atiman ang mga pagbag-o sa database schema kung maghimo asul / berde nga pag-deploy? Ang kamatuoran mao nga bisan unsa pa ang paggamit sa Kubernetes, ang pagbag-o sa database schema usa ka lisud nga buluhaton. Kinahanglan nimo nga sigurohon nga ang daan ug bag-ong schema magkatugma, pagkahuman mahimo nimong i-update ang database ug dayon i-update ang mga aplikasyon mismo. Mahimo nimo nga hot swap ang database ug dayon i-update ang mga aplikasyon. Nakaila ko sa mga tawo nga nag-boot sa usa ka hingpit nga bag-ong database cluster nga adunay bag-ong schema, kini usa ka kapilian kung ikaw adunay usa ka walay laraw nga database sama sa Mongo, apan dili kini usa ka sayon ββnga buluhaton. Kung wala ka'y ββdugang nga mga pangutana, salamat sa imong pagtagad!
Pipila ka mga ad π
Salamat sa pagpabilin kanamo. Ganahan ka ba sa among mga artikulo? Gusto nga makakita og mas makapaikag nga sulod? Suportahi kami pinaagi sa pag-order o pagrekomenda sa mga higala, , usa ka talagsaon nga analogue sa mga entry-level server, nga giimbento namo alang kanimo: (anaa sa RAID1 ug RAID10, hangtod sa 24 ka mga core ug hangtod sa 40GB DDR4).
Dell R730xd 2 ka beses nga mas barato sa Equinix Tier IV data center sa Amsterdam? Dinhi lang sa Netherlands! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - gikan sa $99! Basaha ang mahitungod sa
Source: www.habr.com