Kubernetes estas bonega ilo por ruli Docker-ujojn en amasigita produktadmedio. Tamen estas problemoj, kiujn Kubernetes ne povas solvi. Por oftaj produktaddeplojoj, ni bezonas plene aŭtomatigitan Bluan/Verdan deplojon por eviti malfunkcion en la procezo, kiu ankaŭ bezonas trakti eksterajn HTTP-petojn kaj plenumi SSL-malŝarĝojn. Ĉi tio postulas integriĝon kun ŝarĝbalancilo kiel ha-proxy. Alia defio estas duonaŭtomata skalo de la Kubernetes-areto mem dum kurado en nuba medio, ekzemple parte skalo de la areto nokte.
Kvankam Kubernetes ne havas ĉi tiujn funkciojn el la skatolo, ĝi provizas API, kiun vi povas uzi por solvi similajn problemojn. Iloj por aŭtomatigita Blua/Verda deplojo kaj skalo de Kubernetes-areto estis evoluigitaj kiel parto de la Cloud RTI-projekto, kiu estis kreita surbaze de malfermfonteco.
Ĉi tiu artikolo, video-transskribo, montras al vi kiel agordi Kubernetes kune kun aliaj malfermfontaj komponantoj por krei produktadpretan medion, kiu akceptas kodon de git-komisio sen malfunkcio en produktado.
Do, post kiam vi havas aliron al viaj aplikoj de la ekstera mondo, vi povas komenci plene agordi aŭtomatigon, tio estas, alporti ĝin al la stadio, kie vi povas plenumi git-kommit kaj certigi, ke ĉi tiu git-kommit finiĝas en produktado. Kompreneble, dum efektivigado de ĉi tiuj paŝoj, dum efektivigo de deplojo, ni ne volas renkonti malfunkcion. Do, ajna aŭtomatigo en Kubernetes komenciĝas per la API.
Kubernetes ne estas ilo, kiu povas esti uzata produktive el la skatolo. Kompreneble, vi povas fari tion, uzi kubectl kaj tiel plu, sed tamen la API estas la plej interesa kaj utila afero pri ĉi tiu platformo. Uzante la API kiel aron da funkcioj, vi povas aliri preskaŭ ĉion, kion vi volas fari en Kubernetes. kubectl mem ankaŭ uzas la REST API.
Ĉi tio estas REST, do vi povas uzi ajnan lingvon aŭ ilon por labori kun ĉi tiu API, sed via vivo estos multe pli facila per kutimaj bibliotekoj. Mia teamo skribis 2 tiajn bibliotekojn: unu por Java/OSGi kaj unu por Go. La dua ne estas uzata ofte, sed ĉiukaze vi havas ĉi tiujn utilajn aferojn je via dispono. Ili estas parte licencita malfermfonta projekto. Estas multaj tiaj bibliotekoj por diversaj lingvoj, do vi povas elekti tiujn, kiuj plej taŭgas por vi.
Do, antaŭ ol vi komencas aŭtomatigi vian deplojon, vi devas certigi, ke la procezo ne estos submetita al ajna malfunkcio. Ekzemple, nia teamo faras produktajn deplojojn dum la mezo de la tago, kiam homoj pleje uzas la aplikojn, do gravas eviti prokrastojn en ĉi tiu procezo. Por eviti malfunkcion, 2 metodoj estas uzataj: blua/verda deplojo aŭ ruliĝanta ĝisdatigo. En ĉi-lasta kazo, se vi havas 5 kopiojn de la aplikaĵo funkcianta, ili estas ĝisdatigitaj sinsekve unu post la alia. Ĉi tiu metodo funkcias bonege, sed ĝi ne taŭgas se vi havas malsamajn versiojn de la aplikaĵo funkcianta samtempe dum la deplojprocezo. En ĉi tiu kazo, vi povas ĝisdatigi la uzantinterfacon dum la backend funkcias la malnovan version, kaj la aplikaĵo ĉesos funkcii. Tial, el programa vidpunkto, labori en tiaj kondiĉoj estas sufiĉe malfacila.
Ĉi tio estas unu el la kialoj, kial ni preferas uzi bluan/verdan deplojon por aŭtomatigi la deplojon de niaj aplikoj. Kun ĉi tiu metodo, vi devas certigi, ke nur unu versio de la aplikaĵo estas aktiva samtempe.
La blua/verda disfalda mekanismo aspektas tiel. Ni ricevas trafikon por niaj aplikoj per ha-proxy, kiu plusendas ĝin al kurantaj kopioj de la aplikaĵo de la sama versio.
Kiam nova deplojo estas farita, ni uzas Deployer, kiu ricevas la novajn komponentojn kaj deplojas la novan version. Deploji novan version de aplikaĵo signifas, ke nova aro de kopioj estas "levita", post kio ĉi tiuj kopioj de la nova versio estas lanĉitaj en aparta, nova pod. Tamen, ha-proxy scias nenion pri ili kaj ankoraŭ ne sendas ajnan laborŝarĝon al ili.
Sekve, antaŭ ĉio, necesas fari rendimentan kontrolon de novaj versioj de sankontrolado por certigi, ke la kopioj pretas servi la ŝarĝon.
Ĉiuj deplojkomponentoj devas subteni iun formon de sankontrolo. Ĉi tio povas esti tre simpla HTTP-voka kontrolo, kiam vi ricevas kodon kun statuso 200, aŭ pli profunda kontrolo, en kiu vi kontrolas la konekton de la kopioj kun la datumbazo kaj aliaj servoj, la stabilecon de la dinamikaj medio-konektoj. , kaj ĉu ĉio komenciĝas kaj funkcias ĝuste. Ĉi tiu procezo povas esti sufiĉe kompleksa.
Post kiam la sistemo kontrolas, ke ĉiuj ĝisdatigitaj kopioj funkcias, Deployer ĝisdatigos la agordon kaj transdonos la ĝustan konfd, kiu reagogos ha-proxy.
Nur post tio trafiko estos direktita al la pod kun kopioj de la nova versio, kaj la malnova pod malaperos.
Ĉi tiu mekanismo ne estas trajto de Kubernetes. La koncepto de Blua/verda deplojo ekzistas de sufiĉe longa tempo kaj ĝi ĉiam uzis ŝarĝbalancilon. Unue, vi direktas la tutan trafikon al la malnova versio de la aplikaĵo, kaj post la ĝisdatigo, vi tute translokigas ĝin al la nova versio. Ĉi tiu principo estas uzata ne nur en Kubernetes.
Nun mi prezentos al vi novan deplojan komponanton - Deployer, kiu faras sankontrolojn, reagordas prokurojn ktp. Ĉi tio estas koncepto, kiu ne validas por la ekstera mondo kaj ekzistas ene de Kubernetes. Mi montros al vi kiel vi povas krei vian propran Deployer-koncepton uzante malfermfontajn ilojn.
Do, la unua afero, kiun Deployer faras, estas krei RC-reproduktan regilon per la Kubernetes API. Ĉi tiu API kreas podojn kaj servojn por plia disfaldiĝo, tio estas, ĝi kreas tute novan areton por niaj aplikoj. Tuj kiam RC estas konvinkita, ke la kopioj komenciĝis, ĝi faros Sankontrolon pri ilia funkcieco. Por fari tion, Deployer uzas la komandon GET /health. Ĝi prizorgas la taŭgajn skanajn komponantojn kaj kontrolas ĉiujn elementojn, kiuj subtenas la funkciadon de la areto.
Post kiam ĉiuj balgoj raportis sian sanon, Deployer kreas novan agordan elementon - etcd distribuita stokado, kiu estas uzata interne de Kubernetes, inkluzive de stokado de la agordo de ŝarĝbalancilo. Ni skribas datumojn al etcd, kaj malgranda ilo nomita confd monitoras etcd por novaj datumoj.
Se ĝi detektas ajnajn ŝanĝojn al la komenca agordo, ĝi generas novan agordan dosieron kaj transdonas ĝin al ha-proxy. En ĉi tiu kazo, ha-proxy rekomencas sen perdi iujn ajn konektojn kaj direktas la ŝarĝon al novaj servoj, kiuj ebligas funkcii la novan version de niaj aplikaĵoj.
Kiel vi povas vidi, malgraŭ la abundo de komponantoj, ĉi tie estas nenio komplika. Vi nur bezonas pli da atento al la API kaj ktp. Mi volas rakonti al vi pri la malfermfonta deplojilo, kiun ni mem uzas - Amdatu Kubernetes Deployer.
Ĝi estas ilo por reĝisori Kubernetes-deplojojn kaj havas la jenajn funkciojn:
- Blua/Verda deplojo;
- starigi eksteran ŝarĝbalancilon;
- deplojo priskribilo administrado;
- administri la realan deplojon;
- kontrolante la funkciecon de Sanaj kontroloj dum deplojo;
- efektivigo de mediovariabloj en podojn.
Ĉi tiu Deplojilo estas konstruita sur la Kubernetes API kaj provizas REST-API por administri tenilojn kaj deplojojn, same kiel Websocket API por fluaj protokoloj dum la deplojprocezo.
Ĝi metas la agordajn datumojn de ŝarĝbalancilo en etcd, do vi ne devas uzi ha-proxy kun senfina subteno, sed facile uzi vian propran agordan dosieron de ŝarĝbalancilo. Amdatu Deployer estas skribita en Go, kiel Kubernetes mem, kaj estas licencita de Apache.
Antaŭ ol mi ekuzis ĉi tiun version de la deplojilo, mi uzis la sekvan deplojan priskribilon, kiu specifas la parametrojn, kiujn mi bezonas.
Unu el la gravaj parametroj de ĉi tiu kodo estas ebligi la flagon "useHealthCheck". Ni devas specifi, ke prudenta kontrolo devas esti farita dum la deploja procezo. Ĉi tiu agordo povas esti malŝaltita kiam la deplojo uzas triajn ujojn, kiuj ne bezonas esti kontrolitaj. Ĉi tiu priskribilo ankaŭ indikas la nombron da kopioj kaj la fasanta URL kiun ha-proxy bezonas. Ĉe la fino estas la podspecifa flago "podspec", kiu vokas Kubernetes por informoj pri havena agordo, bildo, ktp. Ĉi tio estas sufiĉe simpla JSON-priskribilo.
Alia ilo, kiu estas parto de la malfermfonta projekto Amdatu, estas Deploymentctl. Ĝi havas UI por agordi deplojojn, stokas deplojhistorion, kaj enhavas rethokojn por revokoj de triapartaj uzantoj kaj programistoj. Vi eble ne uzas la UI, ĉar Amdatu Deployer mem estas REST-API, sed ĉi tiu interfaco povas multe plifaciligi la disfaldiĝon por vi sen impliki ajnan API. Deploymentctl estas skribita en OSGi/Vertx uzante Angular 2.
Mi nun montros la supre sur ekrano uzante antaŭregistritan registradon por ke vi ne devu atendi. Ni deplojos simplan Go-aplikaĵon. Ne maltrankviliĝu se vi ne provis Go antaŭe, ĝi estas tre simpla aplikaĵo do vi devus povi eltrovi ĝin.
Ĉi tie ni kreas HTTP-servilon, kiu nur respondas al /health, do ĉi tiu aplikaĵo nur testas la sankontrolon kaj nenion alian. Se la kontrolo trapasas, la JSON-strukturo montrita sube estas uzata. Ĝi enhavas la version de la aplikaĵo, kiu estos deplojita de la deplojisto, la mesaĝon, kiun vi vidas ĉe la supro de la dosiero, kaj la bulean datumtipo - ĉu nia aplikaĵo funkcias aŭ ne.
Mi iomete trompis per la lasta linio, ĉar mi metis fiksan bulean valoron ĉe la supro de la dosiero, kiu estonte helpos min disfaldi eĉ "malsanan" aplikaĵon. Ni traktos ĉi tion poste.
Do ni komencu. Unue, ni kontrolas la ĉeeston de iuj kurantaj podoj uzante la komandon ~ kubectl get pods kaj, surbaze de la foresto de respondo de la fasanta URL, ni certigas, ke neniu deplojoj estas nuntempe faritaj.
Tuj poste sur la ekrano vi vidas la interfacon Deploymentctl, kiun mi menciis, en kiu estas fiksitaj parametroj de deplojado: nomspaco, nomo de aplikaĵo, versio de deplojo, nombro da kopioj, front-end URL, ujo nomo, bildo, limoj de rimedoj, haveno-numero por sankontrolo, ktp. Limoj de rimedoj estas tre gravaj, ĉar ili permesas vin uzi la maksimuman eblan kvanton da aparataro. Ĉi tie vi ankaŭ povas vidi la Protokolon de Deplojo.
Se vi nun ripetas la komandon ~ kubectl get pods, vi povas vidi ke la sistemo "frostas" dum 20 sekundoj, dum kiuj ha-proxy estas reagordita. Post ĉi tio, la pod komenciĝas, kaj nia kopio povas esti vidita en la disfalda protokolo.
Mi eltranĉis la 20-sekundan atendon de la video, kaj nun vi povas vidi sur la ekrano, ke la unua versio de la aplikaĵo estis deplojita. Ĉio ĉi estis farita uzante nur la UI.
Nun ni provu la duan version. Por fari tion, mi ŝanĝas la mesaĝon de la aplikaĵo de "Saluton, Kubernetes!" sur "Saluton, Deployer!", la sistemo kreas ĉi tiun bildon kaj metas ĝin en la Docker-registron, post kio ni simple alklakas la butonon "Deployer" denove en la Deploymentctl fenestro. En ĉi tiu kazo, la disfalda protokolo estas aŭtomate lanĉita en la sama maniero kiel ĝi okazis dum deplojado de la unua versio de la aplikaĵo.
La komando ~ kubectl get pods montras, ke nuntempe funkcias 2 versioj de la aplikaĵo, sed la fasado montras, ke ni ankoraŭ funkcias la version 1.
La ŝarĝbalancilo atendas ke la sankontrolo finiĝos antaŭ ol redirekti trafikon al la nova versio. Post 20 sekundoj, ni ŝanĝas al buklo kaj vidas, ke ni nun havas version 2 de la aplikaĵo deplojita, kaj la unua estis forigita.
Ĉi tio estis la deplojo de "sana" aplikaĵo. Ni vidu, kio okazas, se por nova versio de la aplikaĵo mi ŝanĝas la Sanan parametron de vera al falsa, tio estas, mi provas disfaldi nesanan aplikaĵon, kiu malsukcesis la sankontrolon. Ĉi tio povas okazi se iuj agordaj eraroj estis faritaj en la aplikaĵo en la disvolva etapo, kaj ĝi estis sendita en produktadon en ĉi tiu formo.
Kiel vi povas vidi, la deplojo trairas ĉiujn paŝojn supre kaj ~kubectl get pods montras, ke ambaŭ pods funkcias. Sed male al la antaŭa deplojo, la protokolo montras la staton de tempodaŭro. Tio estas, pro la fakto, ke la sankontrolo malsukcesis, la nova versio de la aplikaĵo ne povas esti deplojita. Kiel rezulto, vi vidas, ke la sistemo revenis al uzado de la malnova versio de la aplikaĵo, kaj la nova versio simple estis malinstalita.
La bona afero pri ĉi tio estas, ke eĉ se vi havas grandan nombron da samtempaj petoj venantaj en la aplikaĵon, ili eĉ ne rimarkos la malfunkcion dum efektivigado de la deploja proceduro. Se vi provas ĉi tiun aplikaĵon uzante la kadron Gatling, kiu sendas al ĝi kiel eble plej multajn petojn, tiam neniu el ĉi tiuj petoj estos forigita. Ĉi tio signifas, ke niaj uzantoj eĉ ne rimarkos versio-ĝisdatigojn en reala tempo. Se ĝi malsukcesas, la laboro daŭros pri la malnova versio; se ĝi sukcesos, uzantoj ŝanĝos al la nova versio.
Estas nur unu afero, kiu povas malsukcesi - se la sankontrolo sukcesas, sed la aplikaĵo malsukcesas tuj kiam la laborŝarĝo estas aplikata al ĝi, tio estas, la kolapso okazos nur post kiam la deplojo estas finita. En ĉi tiu kazo, vi devos permane reveni al la malnova versio. Do, ni rigardis kiel uzi Kubernetes kun la malfermfontaj iloj desegnitaj por ĝi. La deploja procezo estos multe pli facila se vi konstruos ĉi tiujn ilojn en viajn Konstrui/Deploji duktoj. Samtempe, por komenci deplojon, vi povas uzi aŭ la uzantinterfacon aŭ plene aŭtomatigi ĉi tiun procezon uzante, ekzemple, devoti al majstro.
Nia Konstrua Servilo kreos Docker-bildon, puŝos ĝin en Docker Hub aŭ kian ajn registron vi uzas. Docker Hub subtenas rethokon, do ni povas ekigi foran deplojon per Deployer laŭ la maniero montrita supre. Tiel vi povas plene aŭtomatigi la deplojon de via aplikaĵo al ebla produktado.
Ni transiru al la sekva temo - grimpi la Kubernetes-grupon. Notu, ke la komando kubectl estas skala komando. Kun pli da helpo, ni povas facile pliigi la nombron da kopioj en nia ekzistanta areto. Tamen, en la praktiko, ni kutime volas pliigi la nombron da nodoj prefere ol balgoj.
Samtempe, dum laborhoroj vi eble bezonos pliigi, kaj nokte, por redukti la koston de Amazon-servoj, vi eble bezonos redukti la nombron da kurantaj aplikaĵaj petskriboj. Ĉi tio ne signifas, ke grimpi nur la nombron da podoj sufiĉos, ĉar eĉ se unu el la nodoj estas neaktiva, vi ankoraŭ devos pagi al Amazon por ĝi. Tio estas, kune kun skalado de la guŝoj, vi devos skali la nombron da uzitaj maŝinoj.
Ĉi tio povas esti malfacila ĉar ĉu ni uzas Amazon aŭ alian nuban servon, Kubernetes scias nenion pri la nombro da maŝinoj uzataj. Al ĝi mankas ilo, kiu ebligas al vi grimpi la sistemon ĉe la noda nivelo.
Do ni devos prizorgi kaj nodojn kaj podojn. Ni povas facile grimpi la lanĉon de novaj nodoj uzante la AWS API kaj Scaling-grupo-maŝinojn por agordi la nombron da labornodoj de Kubernetes. Vi ankaŭ povas uzi cloud-init aŭ similan skripton por registri nodojn en la Kubernetes-grupo.
La nova maŝino komenciĝas en la Skala grupo, komenciĝas kiel nodo, registras en la registro de la majstro kaj ekfunkcias. Post ĉi tio, vi povas pliigi la nombron da kopioj por uzo sur la rezultaj nodoj. Malgrandiĝo postulas pli da penado, ĉar vi devas certigi, ke tia paŝo ne kondukas al detruo de jam rulantaj aplikaĵoj post malŝalto de "nenecesaj" maŝinoj. Por malhelpi tian scenaron, vi devas agordi la nodojn al la "neplanebla" statuso. Ĉi tio signifas, ke la defaŭlta planilo ignoros ĉi tiujn nodojn dum planado de DaemonSet pods. La planilo forigos nenion de ĉi tiuj serviloj, sed ankaŭ lanĉos neniujn novajn ujojn tie. La sekva paŝo estas forigi la drenan nodon, tio estas, translokigi kurantajn podojn de ĝi al alia maŝino, aŭ aliajn nodojn, kiuj havas sufiĉan kapablon por tio. Post kiam vi certigis, ke ne plu estas ujoj sur ĉi tiuj nodoj, vi povas forigi ilin de Kubernetes. Post ĉi tio, ili simple ĉesos ekzisti por Kubernetes. Poste, vi devas uzi la AWS API por malŝalti nenecesajn nodojn aŭ maŝinojn.
Vi povas uzi Amdatu Scalerd, alian malfermfontan skalan ilon similan al la AWS API. Ĝi disponigas CLI por aldoni aŭ forigi nodojn en areto. Ĝia interesa trajto estas la kapablo agordi la planilon uzante la sekvan json-dosieron.
La kodo montrita reduktas la aretkapaciton je duono dum la nokta periodo. Ĝi agordas kaj la nombron da disponeblaj kopioj kaj la deziratan kapaciton de la Amazon-areo. Uzado de ĉi tiu planilo aŭtomate reduktos la nombron da nodoj nokte kaj pliigos ilin matene, ŝparante la koston uzi nodojn de nuba servo kiel Amazon. Ĉi tiu funkcio ne estas enkonstruita en Kubernetes, sed uzi Scalerd permesos al vi grimpi ĉi tiun platformon kiel vi volas.
Mi ŝatus atentigi, ke multaj homoj diras al mi: "Tio estas bone, sed kio pri mia datumbazo, kiu kutime estas senmova?" Kiel vi povas ruli ion tian en dinamika medio kiel Kubernetes? Miaopinie, vi ne faru ĉi tion, vi ne provu ruli datuman stokejon en Kubernetes. Ĉi tio estas teknike ebla, kaj estas lerniloj en la Interreto pri ĉi tiu temo, sed ĝi serioze komplikos vian vivon.
Jes, ekzistas koncepto de konstantaj vendejoj en Kubernetes, kaj vi povas provi funkciigi datumvendejojn kiel Mongo aŭ MySQL, sed ĉi tio estas sufiĉe labor-intensa tasko. Ĉi tio estas pro la fakto, ke datumaj stokejoj ne plene subtenas interagadon kun dinamika medio. Plej multaj datumbazoj postulas gravan agordon, inkluzive de manlibro de la areto, ne ŝatas aŭtoskalon kaj aliajn similajn aferojn.
Sekve, vi ne devus kompliki vian vivon provante funkciigi datuman stokejon en Kubernetes. Organizu ilian laboron laŭ la tradicia maniero uzante konatajn servojn kaj simple donu al Kubernetes la kapablon uzi ilin.
Por fini la temon, mi ŝatus prezenti al vi la platformon Cloud RTI bazitan sur Kubernetes, pri kiu mia teamo laboras. Ĝi disponigas centralizitan registradon, aplikaĵon kaj aretmonitoradon, kaj multajn aliajn utilajn funkciojn, kiuj estos utilaj. Ĝi uzas diversajn malfermfontajn ilojn kiel Grafana por montri monitoradon.
Estis demando pri kial uzi la ha-proxy-ŝarĝbalancilon kun Kubernetes. Bona demando ĉar nuntempe ekzistas 2 niveloj de ŝarĝoekvilibro. Kubernetes-servoj ankoraŭ loĝas sur virtualaj IP-adresoj. Vi ne povas uzi ilin por havenoj sur eksteraj gastigaj maŝinoj ĉar se Amazon superŝarĝas sian nuban gastiganton, la adreso ŝanĝiĝos. Jen kial ni metas ha-proxy antaŭ la servoj - por krei pli senmovan strukturon por ke trafiko komunikiĝu perfekte kun Kubernetes.
Alia bona demando estas kiel vi povas zorgi pri datumbazaj skemaj ŝanĝoj kiam vi faras bluan/verdan deplojon? La fakto estas, ke sendepende de la uzo de Kubernetes, ŝanĝi la datumbazan skemon estas malfacila tasko. Vi devas certigi, ke la malnova kaj nova skemo estas kongrua, post kio vi povas ĝisdatigi la datumbazon kaj poste ĝisdatigi la aplikaĵojn mem. Vi povas varme interŝanĝi la datumbazon kaj poste ĝisdatigi la aplikojn. Mi konas homojn, kiuj ekfunkciigis tute novan datumbazon kun nova skemo, ĉi tio estas opcio se vi havas senskeman datumbazon kiel Mongo, sed ĝi ne estas facila tasko ĉiukaze. Se vi ne havas pliajn demandojn, dankon pro via atento!
Kelkaj reklamoj 🙂
Dankon pro restado ĉe ni. Ĉu vi ŝatas niajn artikolojn? Ĉu vi volas vidi pli interesan enhavon? Subtenu nin farante mendon aŭ rekomendante al amikoj, , unika analogo de enirnivelaj serviloj, kiu estis inventita de ni por vi: (havebla kun RAID1 kaj RAID10, ĝis 24 kernoj kaj ĝis 40GB DDR4).
Dell R730xd 2 fojojn pli malmultekosta en Equinix Tier IV datumcentro en Amsterdamo? Nur ĉi tie en Nederlando! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - ekde $99! Legu pri
fonto: www.habr.com