Kubernetes is 'n wonderlike hulpmiddel om Docker-houers in 'n gegroepeerde produksie-omgewing te laat loop. Daar is egter take wat Kubernetes nie kan oplos nie. Met gereelde produksie-ontplooiings het ons 'n ten volle outomatiese Blou/Groen-ontplooiing nodig om stilstand in hierdie proses te vermy, wat ook eksterne HTTP-versoeke moet verwerk en SSL-aflaai moet uitvoer. Dit vereis integrasie met 'n lasbalanseerder soos ha-proxy. Nog 'n uitdaging is semi-outomatiese skaal van die Kubernetes-groepering self wanneer dit in die wolk hardloop, soos om die groepering snags gedeeltelik af te skaal.
Alhoewel Kubernetes nie hierdie kenmerke uit die boks verskaf nie, bied dit wel 'n API wat gebruik kan word om hierdie take uit te voer. Gereedskap vir outomatiese Blou/Groen-ontplooiing en skaal van 'n Kubernetes-kluster is ontwikkel as deel van die Wolk RTI-projek, wat op die basis van oopbron geskep is.
Hierdie artikel, video-transkripsie, verduidelik hoe om Kubernetes saam met ander oopbronkomponente op te stel om 'n produksiegereed omgewing te kry wat kode van 'n git-commit aanvaar met geen stilstand in produksie nie.
So, nadat jy toegang tot jou toepassings van die buitewêreld verkry het, kan jy begin om outomatisering volledig op te stel, dit wil sê, dit tot op die stadium te bring waar jy 'n git-commit kan uitvoer en seker maak dat hierdie git-commit in produksie eindig. Natuurlik wil ons nie stilstand in die gesig staar wanneer ons hierdie stappe implementeer, wanneer 'n ontplooiing geïmplementeer word nie. Dus, enige outomatisering in Kubernetes begin met 'n API.
Kubernetes is nie 'n instrument wat produktief uit die boks gebruik kan word nie. Natuurlik kan jy dit doen, kubectl ensovoorts gebruik, maar steeds is die API die interessantste en nuttigste ding van hierdie platform. Deur die API as 'n stel funksies te gebruik, kan jy toegang kry tot byna alles wat jy in Kubernetes wil doen. kubectl self gebruik ook 'n REST API.
Dit is RUS, so jy kan enige tale en gereedskap gebruik om met hierdie API te werk, maar pasgemaakte biblioteke sal jou lewe baie makliker maak. My span het 2 sulke biblioteke geskryf: een vir Java/OSGi en een vir Go. Die tweede word nie gereeld gebruik nie, maar in elk geval is hierdie nuttige dinge tot jou beskikking. Dit is 'n gedeeltelik gelisensieerde oopbronprojek. Daar is baie sulke biblioteke vir verskeie tale, so jy kan die mees geskikte kies.
Dus, voordat u ontplooiing begin outomatiseer, moet u seker maak dat hierdie proses nie aan enige stilstand onderhewig sal wees nie. Ons span doen byvoorbeeld produksie-ontplooiings in die middel van die dag wanneer mense die meeste van hul toepassings maak, so dit is belangrik om vertragings in die proses te vermy. Om stilstand te vermy, word 2 metodes gebruik: blou / groen ontplooiing of deurlopende opdatering. In laasgenoemde geval, as jy 5 toepassingsreplikas het wat loop, word hulle opeenvolgend een na die ander opgegradeer. Hierdie metode werk uitstekend, maar dit sal nie werk as jy verskillende weergawes van die toepassing het wat op dieselfde tyd loop tydens die ontplooiingsproses nie. In so 'n geval kan u die gebruikerskoppelvlak opdateer terwyl die agterkant met die ou weergawe werk en die toepassing sal beëindig word. Daarom, vanuit die oogpunt van programmering, is werk in sulke omstandighede taamlik moeilik.
Dit is een van die redes waarom ons verkies om blou/groen ontplooiing te gebruik om die ontplooiing van ons toepassings te outomatiseer. Met hierdie metode moet u verseker dat slegs een weergawe van die toepassing op enige gegewe tydstip aktief is.
Die blou/groen ontplooiingsmeganisme is soos volg. Ons ontvang verkeer vir ons toepassings deur ha-proxy, wat dit lei na lopende toepassingsreplikas van dieselfde weergawe.
Wanneer 'n nuwe ontplooiing gemaak word, gebruik ons 'n ontplooier wat van die nuwe komponente voorsien word en die nuwe weergawe ontplooi. Die ontplooiing van 'n nuwe weergawe van die toepassing beteken dat 'n nuwe stel replikas "opgehef" word, waarna hierdie replikas van die nuwe weergawe in 'n aparte, nuwe pod bekendgestel word. Ha-proxy weet egter niks van hulle af nie en stuur nog geen werklading aan hulle nie.
Daarom is dit eerstens nodig om 'n gesondheidsondersoek van nuwe weergawes van gesondheidskontrole uit te voer om seker te maak dat die replikas gereed is om die vrag te bedien.
Alle ontplooiingskomponente moet een of ander vorm van gesondheidsondersoek ondersteun. Dit kan 'n baie eenvoudige HTTP-oproepkontrole wees wanneer jy 'n 200-statuskode kry, of 'n dieper kontrole waar jy die verbinding van die replikas aan die databasis en ander dienste, die stabiliteit van die dinamiese omgewingskakels, of alles reg begin en werk, nagaan. . Hierdie proses kan redelik ingewikkeld wees.
Nadat die stelsel seker gemaak het dat alle opgedateerde replikas werk, sal Deployer die konfigurasie opdateer en die korrekte confd deurgee, wat ha-proxy sal herkonfigureer.
Eers daarna sal die verkeer na die peul met replikas van die nuwe weergawe gelei word, en die ou peul sal verdwyn.
Hierdie meganisme is nie 'n kenmerk van Kubernetes nie. Die blou/groen-ontplooiingskonsep bestaan al 'n geruime tyd en het nog altyd 'n lasbalanseerder gebruik. Eerstens stuur jy alle verkeer na die ou weergawe van die toepassing, en na die opdatering dra jy dit heeltemal oor na die nuwe weergawe. Hierdie beginsel word nie net in Kubernetes gebruik nie.
Nou sal ek jou bekendstel aan 'n nuwe ontplooiingskomponent - Ontplooier, wat gesondheidsondersoeke uitvoer, gevolmagtigdes herkonfigureer, ensovoorts. Dit is 'n konsep wat nie aan die buitewêreld behoort nie en binne Kubernetes bestaan. Ek sal jou wys hoe jy jou eie Deployer-konsep kan skep deur oopbronnutsgoed te gebruik.
Dus, die eerste ding wat Deployer doen, is om 'n RC-replikasiebeheerder te skep met behulp van die Kubernetes API. Hierdie API skep peule en dienste vir verdere ontplooiing, dit wil sê, dit skep 'n heeltemal nuwe groepering vir ons toepassings. Sodra die RK oortuig is dat die replikas begin het, sal dit 'n Gesondheidsondersoek daarop uitvoer. Om dit te doen, gebruik Deployer die GET /health-opdrag. Dit begin die toepaslike toetskomponente en kontroleer al die elemente wat die werking van die groepie verseker.
Nadat alle peule hul "gesondheid" aangemeld het, skep Deployer 'n nuwe konfigurasie-element - ens verspreide berging, wat intern deur Kubernetes gebruik word, insluitend vir die stoor van lasbalanseerder-konfigurasie. Ons skryf data na etcd, en 'n bietjie confd-instrument monitor ens vir nuwe data.
As dit enige veranderinge aan die oorspronklike konfigurasie bespeur, genereer dit 'n nuwe instellingslêer en stuur dit aan ha-proxy. In hierdie geval herbegin ha-proxy sonder om enige verbindings te verloor en lei die las na die nuwe dienste wat die nuwe weergawe van ons toepassings verskaf.
Soos u kan sien, ten spyte van die oorvloed van komponente, is daar niks ingewikkeld hier nie. U moet net meer aandag gee aan die API en ens. Ek wil jou vertel van die oopbronontplooier wat ons self gebruik - dit is Amdatu Kubernetes Deployer.
Dit is 'n instrument om Kubernetes-ontplooiings te orkestreer met die volgende kenmerke:
- Blou/Groen ontplooiing;
- die opstel van 'n eksterne lasbalanseerder;
- die bestuur van ontplooiingsbeskrywers;
- bestuur van die werklike ontplooiing;
- gesondheidsondersoeke gesondheidsondersoeke tydens ontplooiing;
- die inspuiting van omgewingsveranderlikes in peule.
Hierdie ontplooier is gebou bo-op die Kubernetes API en bied 'n REST API vir die bestuur van handvatsels en ontplooiings, sowel as 'n Websocket API vir stroomaantekening tydens ontplooiing.
Dit plaas die lasbalanseerder-konfigurasiedata in etcd, so jy hoef nie ha-proxy met out-of-the-box-ondersteuning te gebruik nie, maar kan maklik jou eie lasbalanseerder-konfigurasielêer gebruik. Amdatu Deployer is in Go geskryf, soos Kubernetes self, en gelisensieer deur Apache.
Voordat ek hierdie weergawe van die ontplooier begin gebruik het, het ek die volgende ontplooiingsbeskrywing gebruik, wat die opsies spesifiseer wat ek benodig.
Een van die belangrike parameters van hierdie kode is die insluiting van die "useHealthCheck" vlag. Ons moet spesifiseer dat 'n gesondheidsondersoek tydens die ontplooiingsproses uitgevoer moet word. Hierdie instelling kan gedeaktiveer word wanneer die ontplooiing derdepartyhouers gebruik wat nie gevalideer hoef te word nie. Hierdie beskrywer spesifiseer ook die aantal replikas en die frontend-URL wat ha-proxy benodig. Aan die einde is 'n "podspec" peulspesifikasievlag wat Kubernetes roep vir inligting oor poortinstellings, beeld, ens. Dit is 'n redelik eenvoudige JSON-beskrywing.
Nog 'n instrument wat deel is van die Amdatu oopbronprojek is Deploymentctl. Dit het 'n UI vir die opstel van die ontplooiing, stoor die geskiedenis van die ontplooiing, en bevat webhooks vir terugbeloproepe van derdeparty-gebruikers en -ontwikkelaars. Jy hoef dalk nie die UI te gebruik nie aangesien Amdatu Deployer self 'n REST API is, maar hierdie koppelvlak kan dit vir jou baie makliker maak om te ontplooi sonder om enige API te betrek. Deploymentctl is geskryf in OSGi/Vertx met behulp van Angular 2.
Nou sal ek die bogenoemde op die skerm demonstreer deur 'n voorafopgeneemde opname te gebruik sodat jy nie hoef te wag nie. Ons sal 'n eenvoudige Go-toepassing ontplooi. Moenie bekommerd wees as jy Go nog nie voorheen gebruik het nie, dit is 'n baie eenvoudige toepassing, so jy behoort alles te kan verstaan.
Hier skep ons 'n HTTP-bediener wat net reageer op /health, so hierdie toepassing kontroleer slegs die gesondheidskontrole en niks anders nie. As die validering slaag, word die JSON-struktuur wat hieronder gewys word, gebruik. Dit bevat die weergawe van die toepassing wat deur die ontplooier ontplooi sal word, die boodskap wat u bo-aan die lêer sien, en die Boolese datatipe of ons toepassing in werking is of nie.
Met die laaste reël het ek 'n bietjie gekul, want ek het 'n vaste booleaanse waarde boaan die lêer geplaas, wat my later sal help om selfs 'n "ongesonde" toepassing te ontplooi. Ons sal dit later hanteer.
So kom ons begin. Eerstens kyk ons vir enige lopende peule met die opdrag ~ kubectl get pods , en deur die afwesigheid van 'n frontend URL-antwoord, verifieer ons dat geen ontplooiings tans aan die gang is nie.
Volgende op die skerm sien jy die Deploymentctl-koppelvlak wat ek genoem het, wat die ontplooiingsparameters stel: naamruimte, toepassingnaam, ontplooiingsweergawe, aantal replikas, frontend-URL, houernaam, prent, hulpbronlimiete, poortnommer vir gesondheidskontrole, ens. Hulpbronlimiete is baie belangrik, aangesien dit jou toelaat om die maksimum moontlike hoeveelheid hardeware te gebruik. U kan ook die ontplooiingslogboek hier sien.
As jy nou die ~ kubectl get pods-opdrag uitvoer, kan jy sien dat die stelsel vir 20 sekondes “vries”, waartydens die ha-proxy herkonfigureer word. Daarna begin die peul, en ons replika kan in die ontplooiingslogboek gesien word.
Ek sny die 20 sekondes wag uit die video uit, en nou kan jy op die skerm sien dat die eerste weergawe van die toepassing ontplooi is. Dit alles is slegs met die hulp van die UI gedoen.
Kom ons probeer nou die tweede weergawe. Om dit te doen, verander ek die toepassing se boodskap van "Hallo, Kubernetes!" na "Hallo, Deployer!", skep die stelsel hierdie prent en plaas dit in die Docker-register, waarna ons eenvoudig weer op die "Deploy"-knoppie in die Deploymentctl-venster klik. Dit begin outomaties die ontplooiingslogboek op dieselfde manier as wat dit gedoen het toe die eerste weergawe van die toepassing ontplooi is.
Die ~ kubectl get pods-opdrag wys dat 2 weergawes van die toepassing tans loop, maar die frontend wys dat ons nog weergawe 1 aan die gang het.
Die lasbalanseerder wag vir die gesondheidsondersoek om uitgevoer te word voordat verkeer na die nuwe weergawe herlei word. Na 20 sekondes skakel ons oor na krul en sien dat ons nou weergawe 2 van die toepassing ontplooi het, en die eerste een is verwyder.
Dit was die ontplooiing van 'n "gesonde" - gesonde - toepassing. Kom ons kyk wat gebeur as ek die waarde van die Healthy-parameter verander van waar na onwaar vir 'n nuwe weergawe van die toepassing, d.w.s. ek probeer om 'n ongesonde toepassing te ontplooi wat die gesondheidstoets misluk het. Dit kan gebeur as sommige konfigurasiefoute in die toepassing in die ontwikkelingstadium gemaak is en dit in hierdie vorm na produksie gegaan het.
Soos u kan sien, gaan die ontplooiing deur al die bogenoemde stappe, en ~ kubectl get peule wys dat beide peule aan die gang is. Maar anders as die vorige ontplooiing, wys die logboek die uittelstatus. Dit wil sê, omdat die gesondheidskontrole misluk het, kan die nuwe weergawe van die toepassing nie ontplooi word nie. As gevolg hiervan, sien jy dat die stelsel teruggekeer het na die gebruik van die ou weergawe van die toepassing, en die nuwe weergawe is eenvoudig uitgevee.
Die goeie ding hiervan is dat selfs al het jy 'n groot aantal gelyktydige versoeke wat in jou aansoek kom, hulle nie eers enige stilstand sal opmerk tydens die implementering van die ontplooiingsprosedure nie. As jy hierdie toepassing met die Gatling-raamwerk toets, wat die maksimum moontlike aantal versoeke aan hom stuur, sal nie een van hierdie versoeke laat vaar word nie. Dit beteken dat ons gebruikers nie eens intydse weergawe-opdaterings sal opmerk nie. As dit misluk, sal daar aan die ou weergawe gewerk word, indien suksesvol, sal gebruikers na die nuwe weergawe oorskakel.
Daar is net een ding wat tot mislukking kan lei - as die gesondheidsondersoek slaag en die toepassing misluk sodra die werklading daarop kom, dit wil sê, die ineenstorting sal eers plaasvind nadat die ontplooiing voltooi is. In hierdie geval sal u handmatig moet terugrol na die ou weergawe. Dus, ons het gekyk hoe om Kubernetes te gebruik met oopbronnutsgoed wat daarvoor ontwerp is. Die ontplooiingsproses sal baie makliker wees as jy hierdie gereedskap in jou Bou/Ontplooi pyplyne insluit. Terselfdertyd kan jy beide die gebruikerskoppelvlak gebruik om die ontplooiing te begin, en hierdie proses heeltemal outomatiseer, met byvoorbeeld commit to master.
Ons Build Server sal 'n Docker-beeld skep, dit in Docker Hub plaas of watter register jy ook al gebruik. Docker Hub ondersteun webhook, sodat ons afstandontplooiing via Deployer kan uitvoer soos hierbo getoon. Op hierdie manier kan jy die ontplooiing van die toepassing na potensiële produksie ten volle outomatiseer.
Kom ons gaan aan na die volgende onderwerp – skaal van 'n Kubernetes-kluster. Let daarop dat die kubectl-opdrag 'n skaalopdrag is. Met meer hulp kan jy maklik die aantal replikas in ons bestaande groepering vermeerder. In die praktyk wil ons egter gewoonlik die aantal nodusse vermeerder, nie peule nie.
Terselfdertyd, gedurende werksure, moet jy dalk verhoog, en snags, om die koste van Amazon-dienste te verminder, moet jy dalk die aantal lopende gevalle van die toepassing verminder. Dit beteken nie dat dit voldoende sal wees om net die aantal peule te skaal nie, want selfs al is een van die nodusse ledig, moet jy steeds Amazon daarvoor betaal. Dit wil sê, saam met skaalpeule moet jy ook die aantal masjiene wat gebruik word, skaal.
Dit kan moeilik wees, want of ons Amazon of 'n ander wolkdiens gebruik, Kubernetes weet niks van die aantal masjiene wat gebruik word nie. Dit het nie 'n instrument waarmee u die stelsel op die nodusvlak kan skaal nie.
Ons moet dus sorg vir beide nodusse en peule. Ons kan maklik nuwe nodusbekendstellings skaal deur die AWS API en Skaalgroepmasjiene te gebruik om die aantal Kubernetes-werkernodusse aan te pas. Jy kan ook cloud-init of 'n soortgelyke skrif gebruik om nodusse in 'n Kubernetes-kluster te registreer.
Die nuwe masjien begin in die Scaling-groep, begin homself as 'n nodus, registreer homself in die meester se register en begin werk. Daarna kan u die aantal replikas wat op die gevolglike nodusse gebruik word, verhoog. Afskaling verg meer moeite om seker te maak dat so 'n stap nie lei tot die vernietiging van toepassings wat reeds loop nadat "onnodige" masjiene afgeskakel is nie. Om so 'n scenario te voorkom, moet jy die nodusse na die status van "onskeduleerbaar" bring. Dit beteken dat die verstekskeduleerder hierdie nodusse sal ignoreer wanneer DaemonSet-peule geskeduleer word. Die skeduleerder sal niks van hierdie bedieners uitvee nie, maar dit sal ook geen nuwe houers daar begin nie. Die volgende stap is om die dreineerknoop uit te sit, dit wil sê om die lopende peule daarvan oor te dra na 'n ander masjien, of ander nodusse wat voldoende kapasiteit hiervoor het. Nadat u seker gemaak het dat daar nie meer houers op hierdie nodusse is nie, kan hulle uit Kubernetes verwyder word. Daarna hou hulle vir Kubernetes eenvoudig op om te bestaan. Vervolgens moet u die AWS API gebruik om onnodige nodusse of masjiene uit te skakel.
U kan Amdatu Scalerd gebruik, nog 'n oopbron-skaalinstrument soortgelyk aan die AWS API. Dit bied 'n CLI om nodusse in 'n groep by te voeg of te verwyder. Die interessante kenmerk daarvan is die vermoë om die skeduleerder aan te pas deur die volgende json-lêer te gebruik.
Die kode wat gewys word, halveer die kapasiteit van die groep gedurende die nag. Dit is gekonfigureer met beide die aantal replikas beskikbaar en die verlangde Amazon-klusterkapasiteit. Die gebruik van hierdie skeduleerder sal outomaties die aantal nodusse in die nag verminder en dit in die oggend vermeerder, wat jou die koste bespaar om nodusse in 'n wolkdiens soos Amazon te gebruik. Hierdie kenmerk is nie in Kubernetes ingebou nie, maar die gebruik van Scalerd sal jou toelaat om die platform te skaal soos jy wil.
Ek wil jou aandag daarop vestig dat baie mense vir my sê: "Dit is alles goed, maar wat van my databasis, wat gewoonlik in 'n statiese toestand is?" Hoe kan jy so iets in 'n dinamiese omgewing soos Kubernetes bestuur? Na my mening behoort jy dit nie te doen nie, jy moet nie probeer om 'n datawinkel op Kubernetes te bestuur nie. Dit is tegnies moontlik en daar is gidse op die internet hieroor, maar dit sal jou lewe ernstig bemoeilik.
Ja, Kubernetes het die konsep van aanhoudende winkels, en jy kan probeer om datawinkels soos Mongo of MySQL te bestuur, maar dit is baie werk. Dit is te wyte aan die feit dat datawinkels nie interaksie met 'n dinamiese omgewing ten volle ondersteun nie. Die meeste databasisse vereis baie tuning, insluitend die handmatige konfigurasie van die cluster, hou nie van outoskaling nie, en sulke dinge.
Daarom moet u nie u lewe bemoeilik deur 'n datapakhuis in Kubernetes te probeer bestuur nie. Organiseer hulle op die tradisionele manier met behulp van bekende dienste en laat Kubernetes dit net gebruik.
Aan die einde van die onderwerp wil ek jou voorstel aan die Cloud RTI-platform gebaseer op Kubernetes, waaraan my span werk. Dit bied gesentraliseerde aantekening, toepassings- en groepmonitering, en baie ander nuttige kenmerke wat handig te pas sal kom. Dit gebruik verskeie oopbronnutsmiddels soos Grafana om monitering te vertoon.
Daar was 'n vraag, hoekom 'n ha-instaanbediener lasbalanseerder met Kubernetes gebruik. Goeie vraag, want daar is tans 2 vlakke van lasbalansering. Kubernetes-dienste is steeds op virtuele IP-adresse. Jy kan dit nie vir eksterne gasheermasjienpoorte gebruik nie, want as Amazon hul wolkgasheer herlaai, sal die adres verander. Dit is hoekom ons ha-proxy voor die dienste plaas - om 'n meer statiese struktuur te skep vir naatlose interaksie van verkeer met Kubernetes.
Nog 'n goeie vraag is hoe kan jy sorg vir die verandering van die databasisskema in 'n blou/groen ontplooiing? Die feit is dat ongeag die gebruik van Kubernetes, die verandering van die databasisskema 'n moeilike taak is. Jy moet verseker dat die ou en nuwe skemas versoenbaar is, waarna jy die databasis kan opdateer en dan die toepassings self opdateer. Jy kan databasisse uitruil en dan toepassings opgradeer. Ek ken mense wat 'n splinternuwe databasisgroepering met 'n nuwe skema begin het, dit is 'n opsie as jy 'n skemalose databasis soos Mongo het, maar dit is in elk geval nie 'n maklike taak nie. As daar nie meer vrae is nie, dankie vir jou aandag!
Sommige advertensies 🙂
Dankie dat jy by ons gebly het. Hou jy van ons artikels? Wil jy meer interessante inhoud sien? Ondersteun ons deur 'n bestelling te plaas of by vriende aan te beveel, , 'n unieke analoog van intreevlakbedieners, wat deur ons vir jou uitgevind is: (beskikbaar met RAID1 en RAID10, tot 24 kerne en tot 40 GB DDR4).
Dell R730xd 2x goedkoper in Equinix Tier IV-datasentrum in Amsterdam? Net hier in Nederland! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - vanaf $99! Lees van
Bron: will.com