DEVOXX UK. Kubernetes ražoÅ”anā: zilā/zaļā izvietoÅ”ana, automātiskā mērogoÅ”ana un izvietoÅ”anas automatizācija. 2. daļa

Kubernetes ir lielisks rÄ«ks Docker konteineru darbināŔanai klasteru ražoÅ”anas vidē. Tomēr ir problēmas, kuras Kubernetes nevar atrisināt. Biežām ražoÅ”anas izvietoÅ”anām mums ir nepiecieÅ”ama pilnÄ«bā automatizēta zilā/zaļā izvietoÅ”ana, lai izvairÄ«tos no dÄ«kstāves procesā, kam arÄ« jāapstrādā ārējie HTTP pieprasÄ«jumi un jāveic SSL izkrauÅ”ana. Tam nepiecieÅ”ama integrācija ar slodzes balansētāju, piemēram, ha-proxy. Vēl viens izaicinājums ir paÅ”a Kubernetes klastera pusautomātiskā mērogoÅ”ana, darbojoties mākoņa vidē, piemēram, daļēji samazinot klasteru naktÄ«.

Lai gan Kubernetes Ŕīs funkcijas nav pieejamas, tā nodroÅ”ina API, ko varat izmantot lÄ«dzÄ«gu problēmu risināŔanai. RÄ«ki automatizētai Kubernetes klastera Blue/Green izvietoÅ”anai un mērogoÅ”anai tika izstrādāti kā daļa no Cloud RTI projekta, kas tika izveidots, pamatojoties uz atvērtā pirmkoda pamata.

Å ajā rakstā ā€” video atÅ”ifrējumā ā€” ir parādÄ«ts, kā iestatÄ«t Kubernetes kopā ar citiem atvērtā pirmkoda komponentiem, lai izveidotu ražoÅ”anai gatavu vidi, kas pieņem kodu no git commit bez ražoÅ”anas dÄ«kstāves.

DEVOXX UK. Kubernetes ražoÅ”anā: zilā/zaļā izvietoÅ”ana, automātiskā mērogoÅ”ana un izvietoÅ”anas automatizācija. 2. daļa

DEVOXX UK. Kubernetes ražoÅ”anā: zilā/zaļā izvietoÅ”ana, automātiskā mērogoÅ”ana un izvietoÅ”anas automatizācija. 1. daļa

Tātad, tiklÄ«dz jums ir piekļuve savām lietojumprogrammām no ārpasaules, varat sākt pilnÄ«bā iestatÄ«t automatizāciju, tas ir, nogādāt to tādā stadijā, kurā varat veikt git commit un nodroÅ”ināt, lai Ŕī git commit nonāktu ražoÅ”anā. Protams, Ä«stenojot Ŕīs darbÄ«bas, ievieÅ”ot izvietoÅ”anu, mēs nevēlamies saskarties ar dÄ«kstāvi. Tātad jebkura Kubernetes automatizācija sākas ar API.

DEVOXX UK. Kubernetes ražoÅ”anā: zilā/zaļā izvietoÅ”ana, automātiskā mērogoÅ”ana un izvietoÅ”anas automatizācija. 2. daļa

Kubernetes nav rÄ«ks, ko var produktÄ«vi izmantot no kastes. Protams, jÅ«s varat to darÄ«t, izmantot kubectl un tā tālāk, bet tomēr API ir visinteresantākā un noderÄ«gākā lieta Å”ajā platformā. Izmantojot API kā funkciju kopu, varat piekļūt gandrÄ«z visam, ko vēlaties darÄ«t pakalpojumā Kubernetes. Pats kubectl izmanto arÄ« REST API.

Tas ir REST, tāpēc varat izmantot jebkuru valodu vai rÄ«ku, lai strādātu ar Å”o API, taču pielāgotās bibliotēkas padarÄ«s jÅ«su dzÄ«vi daudz vieglāku. Mana komanda uzrakstÄ«ja 2 Ŕādas bibliotēkas: vienu Java/OSGi un vienu Go. Otrais netiek izmantots bieži, bet jebkurā gadÄ«jumā Ŕīs noderÄ«gas lietas ir jÅ«su rÄ«cÄ«bā. Tie ir daļēji licencēts atvērtā pirmkoda projekts. Ir daudz Ŕādu bibliotēku dažādām valodām, tāpēc varat izvēlēties sev vispiemērotākās.

DEVOXX UK. Kubernetes ražoÅ”anā: zilā/zaļā izvietoÅ”ana, automātiskā mērogoÅ”ana un izvietoÅ”anas automatizācija. 2. daļa

Tāpēc, pirms sākat automatizēt izvietoÅ”anu, jums jāpārliecinās, ka process netiks pakļauts dÄ«kstāvei. Piemēram, mÅ«su komanda veic ražoÅ”anas izvietoÅ”anu dienas vidÅ«, kad cilvēki visvairāk izmanto lietojumprogrammas, tāpēc ir svarÄ«gi izvairÄ«ties no procesa aizkavÄ“Å”anās. Lai izvairÄ«tos no dÄ«kstāves, tiek izmantotas 2 metodes: zilā/zaļā izvietoÅ”ana vai ritoŔā atjaunināŔana. Pēdējā gadÄ«jumā, ja darbojas 5 lietojumprogrammas kopijas, tās tiek atjauninātas secÄ«gi viena pēc otras. Å Ä« metode darbojas lieliski, taču tā nav piemērota, ja izvietoÅ”anas procesa laikā vienlaikus darbojas dažādas lietojumprogrammas versijas. Šādā gadÄ«jumā varat atjaunināt lietotāja interfeisu, kamēr aizmugursistēma darbojas vecajā versijā, un lietojumprogramma pārtrauks darboties. Tāpēc no programmÄ“Å”anas viedokļa strādāt Ŕādos apstākļos ir diezgan sarežģīti.

Tas ir viens no iemesliem, kāpēc mēs dodam priekÅ”roku zilā/zaļā izvietoÅ”anai, lai automatizētu mÅ«su lietojumprogrammu izvietoÅ”anu. Izmantojot Å”o metodi, jums ir jānodroÅ”ina, lai vienlaikus bÅ«tu aktÄ«va tikai viena lietojumprogrammas versija.

Zilā/zaļā izvietoÅ”anas mehānisms izskatās Ŕādi. Mēs saņemam datplÅ«smu mÅ«su lietojumprogrammām, izmantojot ha-proxy, kas to pārsÅ«ta uz tās paÅ”as versijas lietojumprogrammas replikām.

Kad tiek veikta jauna izvietoÅ”ana, mēs izmantojam Deployer, kuram tiek pieŔķirti jaunie komponenti un tiek izvietota jaunā versija. Lietojumprogrammas jaunas versijas izvietoÅ”ana nozÄ«mē, ka tiek ā€œizceltaā€ jauna kopiju kopa, pēc kuras Ŕīs jaunās versijas kopijas tiek palaistas atseviŔķā, jaunā podā. Tomēr ha-proxy par tiem neko nezina un pagaidām nenovirza tiem nekādu darba slodzi.

Tāpēc, pirmkārt, ir jāveic jauno veselÄ«bas pārbaudes versiju veiktspējas pārbaude, lai pārliecinātos, ka replikas ir gatavas slodzes apkalpoÅ”anai.

DEVOXX UK. Kubernetes ražoÅ”anā: zilā/zaļā izvietoÅ”ana, automātiskā mērogoÅ”ana un izvietoÅ”anas automatizācija. 2. daļa

Visiem izvietoÅ”anas komponentiem ir jāatbalsta kāda veida veselÄ«bas pārbaude. Tā var bÅ«t pavisam vienkārÅ”a HTTP izsaukuma pārbaude, saņemot kodu ar statusu 200, vai arÄ« padziļinātāka pārbaude, kurā pārbauda repliku savienojumu ar datu bāzi un citiem pakalpojumiem, dinamiskās vides savienojumu stabilitāti. , un vai viss sākas un darbojas pareizi. Å is process var bÅ«t diezgan sarežģīts.

DEVOXX UK. Kubernetes ražoÅ”anā: zilā/zaļā izvietoÅ”ana, automātiskā mērogoÅ”ana un izvietoÅ”anas automatizācija. 2. daļa

Kad sistēma pārbaudīs, vai visas atjauninātās kopijas darbojas, Deployer atjauninās konfigurāciju un nodos pareizo confd, kas pārkonfigurēs ha-starpniekserveri.

DEVOXX UK. Kubernetes ražoÅ”anā: zilā/zaļā izvietoÅ”ana, automātiskā mērogoÅ”ana un izvietoÅ”anas automatizācija. 2. daļa

Tikai pēc tam datplūsma tiks novirzīta uz podziņu ar jaunās versijas kopijām, un vecais pods pazudīs.

DEVOXX UK. Kubernetes ražoÅ”anā: zilā/zaļā izvietoÅ”ana, automātiskā mērogoÅ”ana un izvietoÅ”anas automatizācija. 2. daļa

Å is mehānisms nav Kubernetes iezÄ«me. Zilā/zaļās izvietoÅ”anas koncepcija pastāv jau diezgan ilgu laiku, un tajā vienmēr ir izmantots slodzes lÄ«dzsvarotājs. Pirmkārt, jÅ«s novirzāt visu trafiku uz lietojumprogrammas veco versiju, un pēc atjaunināŔanas jÅ«s to pilnÄ«bā pārsÅ«tāt uz jauno versiju. Å is princips tiek izmantots ne tikai Kubernetes.

Tagad es jÅ«s iepazÄ«stināŔu ar jaunu izvietoÅ”anas komponentu - Deployer, kas veic veselÄ«bas pārbaudes, pārkonfigurē starpniekserverus utt. Å is ir jēdziens, kas neattiecas uz ārpasauli un pastāv Kubernetes iekÅ”ienē. Es jums parādÄ«Å”u, kā jÅ«s varat izveidot savu Deployer koncepciju, izmantojot atvērtā pirmkoda rÄ«kus.

Tātad, pirmā lieta, ko Deployer dara, ir izveidot RC replikācijas kontrolieri, izmantojot Kubernetes API. Å Ä« API izveido aplikumus un pakalpojumus turpmākai izvietoÅ”anai, tas ir, mÅ«su lietojumprogrammām izveido pilnÄ«gi jaunu klasteru. TiklÄ«dz RC bÅ«s pārliecināts, ka replikas ir sākuŔās, tā veiks to funkcionalitātes veselÄ«bas pārbaudi. Lai to izdarÄ«tu, Deployer izmanto komandu GET /health. Tas palaiž atbilstoÅ”os skenÄ“Å”anas komponentus un pārbauda visus elementus, kas atbalsta klastera darbÄ«bu.

DEVOXX UK. Kubernetes ražoÅ”anā: zilā/zaļā izvietoÅ”ana, automātiskā mērogoÅ”ana un izvietoÅ”anas automatizācija. 2. daļa

Kad visi podi ir ziņojuÅ”i par savu stāvokli, Deployer izveido jaunu konfigurācijas elementu ā€” etcd sadalÄ«to krātuvi, ko Kubernetes izmanto iekŔēji, tostarp saglabā slodzes lÄ«dzsvara konfigurācijas konfigurāciju. Mēs rakstām datus uz etcd un nelielu rÄ«ku, ko sauc par confd monitors etcd, lai iegÅ«tu jaunus datus.

Ja tas konstatē izmaiņas sākotnējā konfigurācijā, tas Ä£enerē jaunu iestatÄ«jumu failu un pārsÅ«ta to uz ha-starpniekserveri. Šādā gadÄ«jumā ha-starpniekserveris tiek atsāknēts, nezaudējot savienojumus, un adresē slodzi jauniem pakalpojumiem, kas nodroÅ”ina mÅ«su lietojumprogrammu jaunās versijas darbÄ«bu.

DEVOXX UK. Kubernetes ražoÅ”anā: zilā/zaļā izvietoÅ”ana, automātiskā mērogoÅ”ana un izvietoÅ”anas automatizācija. 2. daļa

Kā redzat, neskatoties uz komponentu pārpilnÄ«bu, Å”eit nav nekā sarežģīta. Jums vienkārÅ”i jāpievērÅ” lielāka uzmanÄ«ba API un utt. Es vēlos jums pastāstÄ«t par atvērtā pirmkoda izvietotāju, ko mēs paÅ”i izmantojam - Amdatu Kubernetes Deployer.

DEVOXX UK. Kubernetes ražoÅ”anā: zilā/zaļā izvietoÅ”ana, automātiskā mērogoÅ”ana un izvietoÅ”anas automatizācija. 2. daļa

Tas ir rÄ«ks Kubernetes izvietoÅ”anas organizÄ“Å”anai, un tam ir Ŕādas funkcijas:

  • Zilā/zaļā izvietoÅ”ana;
  • ārējā slodzes lÄ«dzsvara iestatÄ«Å”ana;
  • izvietoÅ”anas deskriptora pārvaldÄ«ba;
  • vadÄ«t faktisko izvietoÅ”anu;
  • VeselÄ«bas pārbaužu funkcionalitātes pārbaude izvietoÅ”anas laikā;
  • vides mainÄ«go ievieÅ”ana podiņos.

Å is izvietotājs ir izveidots, izmantojot Kubernetes API, un nodroÅ”ina REST API, lai pārvaldÄ«tu rokturus un izvietoÅ”anu, kā arÄ« Websocket API žurnālu straumÄ“Å”anai izvietoÅ”anas procesa laikā.

Tas ievieto slodzes lÄ«dzsvara konfigurācijas datus programmā etcd, tāpēc jums nav jāizmanto ha-starpniekserveris ar tÅ«lÄ«tēju atbalstu, bet vienkārÅ”i jāizmanto savs slodzes lÄ«dzsvara konfigurācijas fails. Amdatu Deployer ir rakstÄ«ts Go, tāpat kā pati Kubernetes, un to ir licencējis Apache.

Pirms sāku lietot Ŕo izvietotāja versiju, es izmantoju Ŕādu izvietoŔanas deskriptoru, kas norāda man nepiecieŔamos parametrus.

DEVOXX UK. Kubernetes ražoÅ”anā: zilā/zaļā izvietoÅ”ana, automātiskā mērogoÅ”ana un izvietoÅ”anas automatizācija. 2. daļa

Viens no svarÄ«gajiem Ŕī koda parametriem ir karoga ā€œuseHealthCheckā€ iespējoÅ”ana. Mums ir jānorāda, ka izvietoÅ”anas procesa laikā ir jāveic saprāta pārbaude. Å o iestatÄ«jumu var atspējot, ja izvietoÅ”anā tiek izmantoti treŔās puses konteineri, kas nav jāverificē. Å is deskriptors norāda arÄ« repliku skaitu un priekÅ”gala URL, kas nepiecieÅ”ams ha starpniekserverim. Beigās ir pod specifikācijas karodziņŔ "podspec", kas izsauc Kubernetes informāciju par porta konfigurāciju, attēlu utt. Å is ir diezgan vienkārÅ”s JSON deskriptors.

Vēl viens rÄ«ks, kas ir daļa no atvērtā pirmkoda Amdatu projekta, ir Deploymentctl. Tam ir lietotāja saskarne izvietoÅ”anas konfigurÄ“Å”anai, tiek saglabāta izvietoÅ”anas vēsture, un tajā ir tÄ«mekļa aizÄ·eres treÅ”o puÅ”u lietotāju un izstrādātāju atzvanÄ«Å”anai. JÅ«s nedrÄ«kstat izmantot lietotāja interfeisu, jo pats Amdatu Deployer ir REST API, taču Ŕī saskarne var ievērojami atvieglot izvietoÅ”anu, neiesaistot API. Deploymentctl ir rakstÄ«ts OSGi/Vertx, izmantojot Angular 2.

Tagad es parādÄ«Å”u iepriekÅ” minēto uz ekrāna, izmantojot iepriekÅ” ierakstÄ«tu ierakstu, lai jums nebÅ«tu jāgaida. Mēs izvietosim vienkārÅ”u Go lietojumprogrammu. Neuztraucieties, ja iepriekÅ” neesat izmēģinājis Go, tā ir ļoti vienkārÅ”a lietojumprogramma, tāpēc jums vajadzētu to izdomāt.

DEVOXX UK. Kubernetes ražoÅ”anā: zilā/zaļā izvietoÅ”ana, automātiskā mērogoÅ”ana un izvietoÅ”anas automatizācija. 2. daļa

Å eit mēs izveidojam HTTP serveri, kas reaģē tikai uz /health, tāpēc Ŕī lietojumprogramma pārbauda tikai veselÄ«bas pārbaudi un neko citu. Ja pārbaude iztur, tiek izmantota tālāk norādÄ«tā JSON struktÅ«ra. Tajā ir ietverta lietojumprogrammas versija, kuru izvietos izvietotājs, ziņojums, ko redzat faila augÅ”daļā, un BÅ«la datu tips ā€” neatkarÄ«gi no tā, vai mÅ«su lietojumprogramma darbojas vai ne.

Nedaudz krāpjos ar pēdējo rindiņu, jo faila augÅ”pusē ievietoju fiksētu BÅ«la vērtÄ«bu, kas man turpmāk palÄ«dzēs izvietot pat ā€œneveselÄ«guā€ aplikāciju. Ar to mēs nodarbosimies vēlāk.

Tātad sāksim. Vispirms mēs pārbaudām, vai nav nevienas darbÄ«bas, izmantojot komandu ~ kubectl get pods, un, pamatojoties uz to, ka no priekÅ”gala URL nav atbildes, mēs pārliecināmies, ka paÅ”laik netiek veikta neviena izvietoÅ”ana.

DEVOXX UK. Kubernetes ražoÅ”anā: zilā/zaļā izvietoÅ”ana, automātiskā mērogoÅ”ana un izvietoÅ”anas automatizācija. 2. daļa

Nākamajā ekrānā tiek parādÄ«ta manis pieminētā Deploymentctl saskarne, kurā ir iestatÄ«ti izvietoÅ”anas parametri: nosaukumvieta, lietojumprogrammas nosaukums, izvietoÅ”anas versija, reprodukciju skaits, priekÅ”gala URL, konteinera nosaukums, attēls, resursu ierobežojumi, porta numurs stāvokļa pārbaudei, utt. Resursu ierobežojumi ir ļoti svarÄ«gi, jo tie ļauj izmantot maksimāli iespējamo aparatÅ«ras daudzumu. Å eit varat skatÄ«t arÄ« izvietoÅ”anas žurnālu.

DEVOXX UK. Kubernetes ražoÅ”anā: zilā/zaļā izvietoÅ”ana, automātiskā mērogoÅ”ana un izvietoÅ”anas automatizācija. 2. daļa

Ja tagad atkārtojat komandu ~ kubectl get pods, jÅ«s varat redzēt, ka sistēma ā€œsasalstā€ uz 20 sekundēm, kuru laikā tiek pārkonfigurēts ha-proxy. Pēc tam tiek palaists pods, un mÅ«su repliku var redzēt izvietoÅ”anas žurnālā.

DEVOXX UK. Kubernetes ražoÅ”anā: zilā/zaļā izvietoÅ”ana, automātiskā mērogoÅ”ana un izvietoÅ”anas automatizācija. 2. daļa

Es no video izgriezu 20 sekunžu gaidÄ«Å”anu, un tagad ekrānā var redzēt, ka ir izvietota lietojumprogrammas pirmā versija. Tas viss tika darÄ«ts, izmantojot tikai lietotāja interfeisu.

DEVOXX UK. Kubernetes ražoÅ”anā: zilā/zaļā izvietoÅ”ana, automātiskā mērogoÅ”ana un izvietoÅ”anas automatizācija. 2. daļa

Tagad izmēģināsim otro versiju. Lai to izdarÄ«tu, nomainu lietojumprogrammas ziņojumu no "Sveika, Kubernetes!" ā€œSveiki, izvietotājs!ā€, sistēma izveido Å”o attēlu un ievieto to Docker reÄ£istrā, pēc tam mēs vienkārÅ”i vēlreiz noklikŔķiniet uz pogas ā€œIzvietotā€ logā Deploymentctl. Å ajā gadÄ«jumā izvietoÅ”anas žurnāls tiek automātiski palaists tādā paŔā veidā, kā tas notika, izvietojot pirmo lietojumprogrammas versiju.

DEVOXX UK. Kubernetes ražoÅ”anā: zilā/zaļā izvietoÅ”ana, automātiskā mērogoÅ”ana un izvietoÅ”anas automatizācija. 2. daļa

Komanda ~ kubectl get pods parāda, ka paŔlaik darbojas 2 lietojumprogrammas versijas, bet priekŔgals parāda, ka joprojām darbojas 1. versija.

DEVOXX UK. Kubernetes ražoÅ”anā: zilā/zaļā izvietoÅ”ana, automātiskā mērogoÅ”ana un izvietoÅ”anas automatizācija. 2. daļa

Slodzes lÄ«dzsvarotājs gaida, lÄ«dz tiks pabeigta stāvokļa pārbaude, pirms novirza trafiku uz jauno versiju. Pēc 20 sekundēm mēs pārslēdzamies uz curl un redzam, ka tagad ir izvietota lietojumprogrammas 2. versija, un pirmā ir izdzēsta.

DEVOXX UK. Kubernetes ražoÅ”anā: zilā/zaļā izvietoÅ”ana, automātiskā mērogoÅ”ana un izvietoÅ”anas automatizācija. 2. daļa

Tā bija ā€œveselÄ«gasā€ lietojumprogrammas izvietoÅ”ana. ApskatÄ«sim, kas notiks, ja jaunai lietojumprogrammas versijai es nomainÄ«Å”u parametru VeselÄ«gs no patiess uz nepatiesu, tas ir, mēģinu izvietot neveselÄ«gu lietojumprogrammu, kas nav izturējusi veselÄ«bas pārbaudi. Tas var notikt, ja lietojumprogrammā izstrādes stadijā tika pieļautas dažas konfigurācijas kļūdas un tā tika nosÅ«tÄ«ta ražoÅ”anā Ŕādā formā.

Kā redzat, izvietoÅ”ana notiek, izmantojot visas iepriekÅ” minētās darbÄ«bas, un ~kubectl get pods parāda, ka abi podi darbojas. Bet atŔķirÄ«bā no iepriekŔējās izvietoÅ”anas žurnālā tiek parādÄ«ts taimauta statuss. Tas ir, sakarā ar to, ka veselÄ«bas pārbaude neizdevās, jauno lietojumprogrammas versiju nevar izvietot. Rezultātā redzat, ka sistēma ir atgriezusies pie lietojumprogrammas vecās versijas izmantoÅ”anas un jaunā versija vienkārÅ”i ir atinstalēta.

DEVOXX UK. Kubernetes ražoÅ”anā: zilā/zaļā izvietoÅ”ana, automātiskā mērogoÅ”ana un izvietoÅ”anas automatizācija. 2. daļa

Labā lieta ir tāda, ka pat tad, ja lietojumprogrammā tiek saņemts liels skaits vienlaicÄ«gu pieprasÄ«jumu, tie pat nepamanÄ«s dÄ«kstāves laiku, Ä«stenojot izvietoÅ”anas procedÅ«ru. Ja testējat Å”o lietojumprogrammu, izmantojot Gatling sistēmu, kas tai nosÅ«ta pēc iespējas vairāk pieprasÄ«jumu, neviens no Å”iem pieprasÄ«jumiem netiks atmests. Tas nozÄ«mē, ka mÅ«su lietotāji pat nepamanÄ«s versiju atjauninājumus reāllaikā. Ja tas neizdodas, darbs tiks turpināts ar veco versiju; ja tas bÅ«s veiksmÄ«gs, lietotāji pārslēgsies uz jauno versiju.

Ir tikai viena lieta, kas var neizdoties - ja veselÄ«bas pārbaude izdodas, bet lietojumprogramma neizdodas, tiklÄ«dz tai tiek piemērota darba slodze, tas ir, sabrukums notiks tikai pēc izvietoÅ”anas pabeigÅ”anas. Å ajā gadÄ«jumā jums bÅ«s manuāli jāatgriežas pie vecās versijas. Tātad, mēs apskatÄ«jām, kā izmantot Kubernetes ar tam paredzētajiem atvērtā pirmkoda rÄ«kiem. IzvietoÅ”anas process bÅ«s daudz vienkārŔāks, ja Å”os rÄ«kus iebÅ«vēsit savos Build/Deploy cauruļvados. Tajā paŔā laikā, lai sāktu izvietoÅ”anu, varat izmantot vai nu lietotāja saskarni, vai pilnÄ«bā automatizēt Å”o procesu, izmantojot, piemēram, apņemÅ”anos apgÅ«t.

DEVOXX UK. Kubernetes ražoÅ”anā: zilā/zaļā izvietoÅ”ana, automātiskā mērogoÅ”ana un izvietoÅ”anas automatizācija. 2. daļa

MÅ«su Build Server izveidos Docker attēlu, ievietos to Docker Hub vai jebkurā jÅ«su izmantotajā reÄ£istrā. Docker Hub atbalsta tÄ«mekļa aizÄ·eri, tāpēc mēs varam aktivizēt attālo izvietoÅ”anu, izmantojot Deployer, kā parādÄ«ts iepriekÅ”. Tādā veidā jÅ«s varat pilnÄ«bā automatizēt lietojumprogrammas izvietoÅ”anu potenciālajā ražoÅ”anā.

Pārejam pie nākamās tēmas - Kubernetes klastera mērogoÅ”ana. Ņemiet vērā, ka kubectl komanda ir mērogoÅ”anas komanda. Ar lielāku palÄ«dzÄ«bu mēs varam viegli palielināt kopiju skaitu mÅ«su esoÅ”ajā klasterÄ«. Tomēr praksē mēs parasti vēlamies palielināt mezglu, nevis pākstu skaitu.

DEVOXX UK. Kubernetes ražoÅ”anā: zilā/zaļā izvietoÅ”ana, automātiskā mērogoÅ”ana un izvietoÅ”anas automatizācija. 2. daļa

Tajā paŔā laikā darba laikā, iespējams, bÅ«s jāpalielina, bet naktÄ«, lai samazinātu Amazon pakalpojumu izmaksas, jums, iespējams, bÅ«s jāsamazina darbojoÅ”os lietojumprogrammu gadÄ«jumu skaits. Tas nenozÄ«mē, ka pietiks ar mērogoÅ”anu tikai ar podiņu skaitu, jo pat tad, ja kāds no mezgliem ir dÄ«kstāvē, jums par to joprojām bÅ«s jāmaksā Amazon. Tas nozÄ«mē, ka kopā ar pākstÄ«m ir nepiecieÅ”ams mērogot izmantoto iekārtu skaitu.

Tas var bÅ«t sarežģīti, jo neatkarÄ«gi no tā, vai mēs izmantojam Amazon vai citu mākoņpakalpojumu, Kubernetes neko nezina par izmantoto maŔīnu skaitu. Tam trÅ«kst rÄ«ka, kas ļauj mērogot sistēmu mezgla lÄ«menÄ«.

DEVOXX UK. Kubernetes ražoÅ”anā: zilā/zaļā izvietoÅ”ana, automātiskā mērogoÅ”ana un izvietoÅ”anas automatizācija. 2. daļa

Tāpēc mums bÅ«s jārÅ«pējas gan par mezgliem, gan par pākstÄ«m. Mēs varam viegli mērogot jaunu mezglu palaiÅ”anu, izmantojot AWS API un mērogoÅ”anas grupas maŔīnas, lai konfigurētu Kubernetes darbinieku mezglu skaitu. Varat arÄ« izmantot mākoņa iniciatoru vai lÄ«dzÄ«gu skriptu, lai reÄ£istrētu mezglus Kubernetes klasterÄ«.

Jaunā maŔīna sākas mērogoÅ”anas grupā, sāk darboties kā mezgls, reÄ£istrējas galvenā reÄ£istrā un sāk darboties. Pēc tam varat palielināt reprodukciju skaitu, ko izmantot iegÅ«tajos mezglos. SamazināŔana prasa vairāk pūļu, jo jums ir jāpārliecinās, ka Ŕāds solis neizraisa jau darbojoÅ”os lietojumprogrammu iznÄ«cināŔanu pēc ā€œnevajadzÄ«goā€ maŔīnu izslēgÅ”anas. Lai novērstu Ŕādu scenāriju, mezgliem ir jāiestata statuss ā€œneplānojamsā€. Tas nozÄ«mē, ka noklusējuma plānotājs ignorēs Å”os mezglus, plānojot DaemonSet podi. Plānotājs neko neizdzēsÄ«s no Å”iem serveriem, bet arÄ« nepalaidÄ«s tajos jaunus konteinerus. Nākamais solis ir iztukÅ”ot iztukÅ”oÅ”anas mezglu, tas ir, pārslēgt no tā darbÄ«gos blokus uz citu maŔīnu vai citiem mezgliem, kuriem ir pietiekama jauda. Kad esat pārliecinājies, ka Å”ajos mezglos vairs nav konteineru, varat tos noņemt no Kubernetes. Pēc tam Kubernetes tie vienkārÅ”i pārstās pastāvēt. Tālāk jums ir jāizmanto AWS API, lai atspējotu nevajadzÄ«gos mezglus vai maŔīnas.
Varat izmantot Amdatu Scalerd, citu atvērtā koda mērogoÅ”anas rÄ«ku, kas ir lÄ«dzÄ«gs AWS API. Tas nodroÅ”ina CLI, lai pievienotu vai noņemtu mezglus klasterÄ«. Tās interesantā funkcija ir iespēja konfigurēt plānotāju, izmantojot Ŕādu json failu.

DEVOXX UK. Kubernetes ražoÅ”anā: zilā/zaļā izvietoÅ”ana, automātiskā mērogoÅ”ana un izvietoÅ”anas automatizācija. 2. daļa

ParādÄ«tais kods samazina klastera jaudu uz pusi nakts periodā. Tas konfigurē gan pieejamo kopiju skaitu, gan vēlamo Amazon klastera jaudu. Izmantojot Å”o plānotāju, tiks automātiski samazināts mezglu skaits naktÄ« un palielināts no rÄ«ta, tādējādi ietaupot izmaksas par mezglu izmantoÅ”anu no mākoņpakalpojuma, piemēram, Amazon. Å Ä« funkcija nav iebÅ«vēta Kubernetes, taču, izmantojot Scalerd, varēsit mērogot Å”o platformu, kā vien vēlaties.

Es vēlos norādÄ«t, ka daudzi cilvēki man saka: "Tas viss ir labi, bet kā ar manu datubāzi, kas parasti ir statiska?" Kā jÅ«s varat palaist kaut ko lÄ«dzÄ«gu dinamiskā vidē, piemēram, Kubernetes? Manuprāt, to nevajadzētu darÄ«t, nevajag mēģināt palaist datu noliktavu Kubernetes. Tas ir tehniski iespējams, un internetā ir pamācÄ«bas par Å”o tēmu, taču tas nopietni sarežģīs jÅ«su dzÄ«vi.

Jā, Kubernetes pastāv pastāvÄ«gu veikalu koncepcija, un jÅ«s varat mēģināt palaist tādus datu veikalus kā Mongo vai MySQL, taču tas ir diezgan darbietilpÄ«gs uzdevums. Tas ir saistÄ«ts ar faktu, ka datu noliktavas pilnÄ«bā neatbalsta mijiedarbÄ«bu ar dinamisku vidi. Lielākajai daļai datu bāzu ir nepiecieÅ”ama ievērojama konfigurācija, ieskaitot klastera manuālu konfigurÄ“Å”anu, nepatÄ«k automātiskā mērogoÅ”ana un citas lÄ«dzÄ«gas lietas.
Tāpēc jums nevajadzētu sarežģīt savu dzÄ«vi, mēģinot vadÄ«t datu noliktavu Kubernetes. Organizējiet savu darbu tradicionālā veidā, izmantojot pazÄ«stamos pakalpojumus, un vienkārÅ”i nodroÅ”iniet Kubernetes iespēju tos izmantot.

DEVOXX UK. Kubernetes ražoÅ”anā: zilā/zaļā izvietoÅ”ana, automātiskā mērogoÅ”ana un izvietoÅ”anas automatizācija. 2. daļa

Noslēdzot tēmu, vēlos jÅ«s iepazÄ«stināt ar Cloud RTI platformu, kuras pamatā ir Kubernetes un pie kuras strādā mana komanda. Tas nodroÅ”ina centralizētu reÄ£istrÄ“Å”anu, lietojumprogrammu un klasteru uzraudzÄ«bu un daudzas citas noderÄ«gas funkcijas, kas noderēs. Tas izmanto dažādus atvērtā pirmkoda rÄ«kus, piemēram, Grafana, lai parādÄ«tu uzraudzÄ«bu.

DEVOXX UK. Kubernetes ražoÅ”anā: zilā/zaļā izvietoÅ”ana, automātiskā mērogoÅ”ana un izvietoÅ”anas automatizācija. 2. daļa

DEVOXX UK. Kubernetes ražoÅ”anā: zilā/zaļā izvietoÅ”ana, automātiskā mērogoÅ”ana un izvietoÅ”anas automatizācija. 2. daļa

Bija jautājums, kāpēc ar Kubernetes izmantot ha-proxy slodzes balansētāju. Labs jautājums, jo paÅ”laik ir 2 slodzes lÄ«dzsvaroÅ”anas lÄ«meņi. Kubernetes pakalpojumi joprojām atrodas virtuālajās IP adresēs. JÅ«s nevarat tos izmantot ārējo saimniekdatoru portiem, jo, ja Amazon pārslogos savu mākoņa resursdatoru, adrese mainÄ«sies. Tāpēc mēs ievietojam ha-proxy pakalpojumu priekŔā - lai izveidotu statiskāku trafika struktÅ«ru, lai netraucēti sazinātos ar Kubernetes.

Vēl viens labs jautājums ir, kā jÅ«s varat parÅ«pēties par datu bāzes shēmas izmaiņām, veicot zilo/zaļo izvietoÅ”anu? Fakts ir tāds, ka neatkarÄ«gi no Kubernetes izmantoÅ”anas datu bāzes shēmas maiņa ir sarežģīts uzdevums. Jums jāpārliecinās, ka vecā un jaunā shēma ir saderÄ«ga, pēc tam varat atjaunināt datu bāzi un pēc tam atjaunināt paÅ”as lietojumprogrammas. Varat nomainÄ«t datu bāzi un pēc tam atjaunināt lietojumprogrammas. Es zinu cilvēkus, kuri ir sāknējuÅ”i pilnÄ«gi jaunu datu bāzes klasteru ar jaunu shēmu. Å Ä« ir iespēja, ja jums ir datu bāze bez shēmām, piemēram, Mongo, taču tas jebkurā gadÄ«jumā nav viegls uzdevums. Ja jums nav papildu jautājumu, paldies par uzmanÄ«bu!

Dažas reklāmas šŸ™‚

Paldies, ka palikāt kopā ar mums. Vai jums patīk mūsu raksti? Vai vēlaties redzēt interesantāku saturu? Atbalsti mūs, pasūtot vai iesakot draugiem, mākoņa VPS izstrādātājiem no 4.99 USD, unikāls sākuma līmeņa serveru analogs, ko mēs jums izgudrojām: Visa patiesība par VPS (KVM) E5-2697 v3 (6 kodoli) 10GB DDR4 480GB SSD 1Gbps no 19$ vai kā koplietot serveri? (pieejams ar RAID1 un RAID10, līdz 24 kodoliem un līdz 40 GB DDR4).

Dell R730xd 2x lētāk Equinix Tier IV datu centrā Amsterdamā? Tikai Å”eit 2x Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 TV no 199$ NÄ«derlandē! Dell R420 ā€” 2x E5-2430 2.2 GHz 6C 128 GB DDR3 2x960 GB SSD 1 Gbps 100 TB ā€” no 99 USD! LasÄ«t par Kā izveidot infrastruktÅ«ras uzņēmumu klase ar Dell R730xd E5-2650 v4 serveru izmantoÅ”anu 9000 eiro par santÄ«mu?

Avots: www.habr.com

Pievieno komentāru