Kubernetes is in geweldich ark foar it útfieren fan Docker-konteners yn in klustere produksjeomjouwing. D'r binne lykwols problemen dy't Kubernetes net kinne oplosse. Foar faak produksje-ynset hawwe wy in folslein automatisearre Blue / Green-ynset nedich om downtime yn it proses te foarkommen, dat ek eksterne HTTP-oanfragen moat behannelje en SSL-offloads útfiere. Dit fereasket yntegraasje mei in load balancer lykas ha-proxy. In oare útdaging is semy-automatyske skaalfergrutting fan it Kubernetes-kluster sels by it rinnen yn in wolkomjouwing, bygelyks it foar in part skaaljen fan it kluster nachts.
Wylst Kubernetes dizze funksjes net bûten it fak hat, leveret it in API dy't jo kinne brûke om ferlykbere problemen op te lossen. Tools foar automatisearre Blau / Grien ynset en skaalfergrutting fan in Kubernetes-kluster waarden ûntwikkele as ûnderdiel fan it Cloud RTI-projekt, dat waard makke op basis fan iepen boarne.
Dit artikel, in fideo-transkripsje, lit jo sjen hoe't jo Kubernetes kinne ynstelle tegearre mei oare iepen boarne-komponinten om in produksje-klear omjouwing te meitsjen dy't koade akseptearret fan in git-commit sûnder downtime yn produksje.
Dat, as jo ienris tagong hawwe ta jo applikaasjes fan 'e bûtenwrâld, kinne jo begjinne om automatisearring folslein yn te stellen, dat is, bring it nei it poadium wêr't jo in git-commit kinne útfiere en derfoar soargje dat dizze git-commit yn produksje einiget. Fansels wolle wy by it útfieren fan dizze stappen, by it ymplementearjen fan ynset, gjin downtime tsjinkomme. Dat, elke automatisearring yn Kubernetes begjint mei de API.
Kubernetes is gjin ark dat produktyf kin wurde brûkt bûten it fak. Fansels kinne jo dat dwaan, kubectl brûke en sa fierder, mar dochs is de API it meast nijsgjirrige en brûkbere ding oer dit platfoarm. Troch de API te brûken as in set fan funksjes, kinne jo tagong krije ta hast alles wat jo wolle dwaan yn Kubernetes. kubectl sels brûkt ek de REST API.
Dit is REST, dus jo kinne elke taal of ark brûke om mei dizze API te wurkjen, mar jo libben sil folle makliker wurde makke troch oanpaste bibleteken. Myn team skreau 2 sokke bibleteken: ien foar Java/OSGi en ien foar Go. De twadde wurdt net faak brûkt, mar jo hawwe yn alle gefallen dizze nuttige dingen ta jo beskikking. Se binne in foar in part lisinsearre iepen-boarne-projekt. D'r binne in protte sokke biblioteken foar ferskate talen, dus jo kinne dejinge kieze dy't it bêste by jo past.
Dat, foardat jo begjinne mei it automatisearjen fan jo ynset, moatte jo der wis fan wêze dat it proses net ûnderwurpen wêze sil oan downtime. Bygelyks, ús team fiert produksje-ynset yn 'e midden fan' e dei as minsken de applikaasjes op har meast brûke, dus it is wichtich om fertragingen yn dit proses te foarkommen. Om downtime te foarkommen, wurde 2 metoaden brûkt: blau / grien ynset as rolling update. Yn it lêste gefal, as jo 5 replika's fan 'e applikaasje hawwe rinnen, wurde se opienfolgjend de iene nei de oare bywurke. Dizze metoade wurket geweldich, mar it is net geskikt as jo ferskate ferzjes fan 'e applikaasje hawwe dy't tagelyk rinne tidens it ynsetproses. Yn dit gefal kinne jo de brûkersynterface bywurkje wylst de backend de âlde ferzje rint, en de applikaasje sil ophâlde mei wurkjen. Dêrom, út in programmearring eachpunt, wurkjen yn sokke omstannichheden is frij lestich.
Dit is ien fan 'e redenen wêrom't wy leaver blauwe / griene ynset brûke om de ynset fan ús applikaasjes te automatisearjen. Mei dizze metoade moatte jo derfoar soargje dat mar ien ferzje fan 'e applikaasje tagelyk aktyf is.
It blau / griene ynsetmeganisme sjocht der sa út. Wy ûntfange ferkear foar ús applikaasjes fia ha-proxy, dy't it trochstjoert nei replika's fan 'e applikaasje fan deselde ferzje.
As in nije ynset wurdt makke, wy brûke Deployer, dat wurdt jûn de nije komponinten en ynsette de nije ferzje. It ynsetten fan in nije ferzje fan in applikaasje betsjut dat in nije set replika's "ferhege" wurdt, wêrnei't dizze replika's fan 'e nije ferzje wurde lansearre yn in aparte, nije pod. Ha-proxy wit lykwols neat oer har en bringt noch gjin wurkdruk nei har ta.
Dêrom is it earst fan alles nedich om in prestaasjekontrôle út te fieren fan nije ferzjes fan sûnenskontrôle om te soargjen dat de replika's klear binne om de lading te tsjinjen.
Alle ynsetkomponinten moatte ien of oare foarm fan sûnenskontrôle stypje. Dit kin in heul ienfâldige HTTP-opropkontrôle wêze, as jo in koade krije mei status 200, of in mear yngeande kontrôle, wêryn jo de ferbining fan 'e replika's kontrolearje mei de databank en oare tsjinsten, de stabiliteit fan' e dynamyske omjouwingsferbiningen , en oft alles begjint en wurket goed. Dit proses kin frij kompleks wêze.
Neidat it systeem kontrolearret dat alle bywurke replika's wurkje, sil Deployer de konfiguraasje bywurkje en de juste confd trochjaan, dy't ha-proxy opnij konfigurearje.
Pas nei dit sil ferkear wurde rjochte nei de pod mei replika's fan 'e nije ferzje, en de âlde pod sil ferdwine.
Dit meganisme is gjin skaaimerk fan Kubernetes. It konsept fan Blau / grien ynset bestiet al in lange tiid en it hat altyd in load balancer brûkt. Earst rjochtsje jo alle ferkear nei de âlde ferzje fan 'e applikaasje, en nei de fernijing ferpleatse jo it folslein nei de nije ferzje. Dit prinsipe wurdt brûkt net allinnich yn Kubernetes.
No sil ik jo in nije ynsetkomponint yntrodusearje - Deployer, dy't sûnenskontrôles útfiert, proxy's opnij konfigurearret, ensfh. Dit is in konsept dat net jildt foar de bûtenwrâld en bestiet binnen Kubernetes. Ik sil jo sjen litte hoe't jo jo eigen Deployer-konsept kinne oanmeitsje mei help fan iepen boarne-ark.
Dat, it earste ding dat Deployer docht is in RC-replikaasjecontroller te meitsjen mei de Kubernetes API. Dizze API makket pods en tsjinsten foar fierdere ynset, dat is, it makket in folslein nij kluster foar ús applikaasjes. Sadree't RC oertsjûge is dat de replika's binne begon, sil it in sûnenskontrôle útfiere op har funksjonaliteit. Om dit te dwaan, brûkt Deployer it kommando GET / sûnens. It rint de passende scan-komponinten en kontrolearret alle eleminten dy't de wurking fan it kluster stypje.
Neidat alle pods hawwe rapportearre harren sûnens, Deployer makket in nij konfiguraasje elemint - etcd ferspraat opslach, dat wurdt brûkt yntern troch Kubernetes, ynklusyf it bewarjen fan de load balancer konfiguraasje. Wy skriuwe gegevens oan etcd, en in lyts ark neamd confd monitors etcd foar nije gegevens.
As it alle feroarings oan 'e earste konfiguraasje ûntdekt, genereart it in nij ynstellingsbestân en bringt it oer nei ha-proxy. Yn dit gefal herstart ha-proxy sûnder ferbinings te ferliezen en rjochtet de lading op nije tsjinsten dy't de nije ferzje fan ús applikaasjes ynskeakelje kinne wurkje.
Sa't jo sjen kinne, nettsjinsteande de oerfloed fan komponinten, d'r is hjir neat yngewikkeld. Jo moatte gewoan mear omtinken jaan oan de API en ensfh. Ik wol jo fertelle oer de iepenboarne-deployer dy't wy sels brûke - Amdatu Kubernetes Deployer.
It is in ark foar it orkestrearjen fan Kubernetes-ynset en hat de folgjende funksjes:
- Blau / Grien ynset;
- it ynstellen fan in eksterne load balancer;
- ynset descriptor behear;
- behear fan de eigentlike ynset;
- kontrolearje de funksjonaliteit fan sûnenskontrôles tidens ynset;
- ymplemintaasje fan omjouwingsfariabelen yn pods.
Dizze Deployer is boud boppe op 'e Kubernetes API en leveret in REST API foar it behearen fan hannelingen en ynset, lykas ek in Websocket API foar streaming logs tidens it ynsetproses.
It set de load balancer konfiguraasje gegevens yn etcd, dus jo hoege net in gebrûk ha-proxy mei out-of-the-box stipe, mar maklik brûk dyn eigen load balancer konfiguraasje triem. Amdatu Deployer is skreaun yn Go, lykas Kubernetes sels, en is lisinsje fan Apache.
Foardat ik dizze ferzje fan 'e ynset begon te brûken, brûkte ik de folgjende ynsetbeskriuwing, dy't de parameters spesifisearret dy't ik nedich is.
Ien fan 'e wichtige parameters fan dizze koade is om de flagge "useHealthCheck" yn te skeakeljen. Wy moatte spesifisearje dat in sûnenskontrôle moat wurde útfierd tidens it ynsetproses. Dizze ynstelling kin útskeakele wurde as de ynset konteners fan tredden brûkt dy't net ferifiearre hoege te wurden. Dizze deskriptor jout ek it oantal replika's en de frontend-URL oan dy't ha-proxy nedich is. Oan 'e ein is de flagge fan' e podspesifikaasje "podspec", dy't Kubernetes neamt foar ynformaasje oer havenkonfiguraasje, ôfbylding, ensfh. Dit is in frij ienfâldige JSON-beskriuwing.
In oar ark dat diel útmakket fan it iepen boarne Amdatu-projekt is Deploymentctl. It hat in UI foar it konfigurearjen fan ynset, bewarret ynsetskiednis, en befettet webhooks foar callbacks fan brûkers en ûntwikkelders fan tredden. Jo meie de UI net brûke, om't Amdatu Deployer sels in REST API is, mar dizze ynterface kin de ynset folle makliker meitsje foar jo sûnder API te belûken. Deploymentctl is skreaun yn OSGi/Vertx mei Angular 2.
Ik sil no it boppesteande op it skerm demonstrearje mei in foarôf opnommen opname, sadat jo net hoege te wachtsjen. Wy sille in ienfâldige Go-applikaasje ynsette. Meitsje jo gjin soargen as jo Go noch net earder hawwe besocht, it is in heul ienfâldige applikaasje, sadat jo it moatte kinne útfine.
Hjir meitsje wy in HTTP-tsjinner dy't allinich reagearret op / sûnens, sadat dizze applikaasje allinich de sûnenskontrôle test en neat oars. As de kontrôle trochgiet, wurdt de hjirûnder werjûn JSON-struktuer brûkt. It befettet de ferzje fan 'e applikaasje dy't sil wurde ynset troch de ynstallator, it berjocht dat jo oan 'e boppekant fan it bestân sjogge, en it Booleaanske gegevenstype - of ús applikaasje wurket of net.
Ik bedrog in bytsje mei de lêste rigel, om't ik in fêste booleanwearde boppe oan it bestân pleatste, wat my yn 'e takomst sil helpe om sels in "ûnsûne" applikaasje yn te setten. Wy sille hjir letter mei omgean.
Dus litte wy begjinne. Earst kontrolearje wy op de oanwêzigens fan rinnende pods mei it kommando ~ kubectl get pods en, basearre op it ûntbrekken fan in antwurd fan 'e frontend URL, soargje wy derfoar dat der op it stuit gjin ynset wurde makke.
Folgjende op it skerm sjogge jo de Deploymentctl-ynterface dy't ik neamde, wêryn ynsetparameters binne ynsteld: nammeromte, applikaasjenamme, ynsetferzje, oantal replika's, front-end URL, containernamme, ôfbylding, boarnegrinzen, poartenûmer foar sûnenskontrôle, ensfh. Boarnegrinzen binne heul wichtich, om't se jo it maksimale mooglike bedrach fan hardware kinne brûke. Hjir kinne jo ek it Deployment log besjen.
As jo no it kommando ~ kubectl get pods werhelje, kinne jo sjen dat it systeem 20 sekonden "befriest", wêrby't ha-proxy opnij konfigureare wurdt. Hjirnei begjint de pod, en ús replika is te sjen yn it ynsetlogboek.
Ik snij de 20 sekonden wachtsjen út 'e fideo, en no kinne jo op it skerm sjen dat de earste ferzje fan' e applikaasje is ynset. Dit alles waard dien mei allinich de UI.
Litte wy no de twadde ferzje besykje. Om dit te dwaan, feroarje ik it berjocht fan 'e applikaasje fan "Hallo, Kubernetes!" op "Hallo, Deployer!", makket it systeem dizze ôfbylding en pleatst it yn it Docker-register, wêrnei't wy gewoan op 'e knop "Deploy" klikke yn it finster Deploymentctl. Yn dit gefal wurdt it ynsetlogboek automatysk lansearre op deselde manier as it barde by it ynsetten fan de earste ferzje fan 'e applikaasje.
It kommando ~ kubectl get pods lit sjen dat d'r op it stuit 2 ferzjes fan 'e applikaasje rinne, mar it frontend lit sjen dat wy noch ferzje 1 útfiere.
De load balancer wachtet op 'e sûnenskontrôle om te foltôgjen foardat it ferkear nei de nije ferzje omlaat. Nei 20 sekonden wikselje wy nei curl en sjogge dat wy no ferzje 2 fan 'e applikaasje hawwe ynset, en de earste is wiske.
Dit wie de ynset fan in "sûne" applikaasje. Litte wy sjen wat der bart as ik foar in nije ferzje fan 'e applikaasje de parameter Healthy feroarje fan wier nei falsk, dat wol sizze, ik besykje in net sûne applikaasje yn te setten dy't de sûnenskontrôle mislearre. Dit kin barre as guon konfiguraasjeflaters waarden makke yn 'e applikaasje yn' e ûntwikkelingsstadium, en it waard yn produksje yn dizze foarm stjoerd.
Sa't jo sjen kinne, giet de ynset troch alle boppesteande stappen en ~kubectl get pods lit sjen dat beide pods rinne. Mar oars as de foarige ynset, toant it log de time-outstatus. Dat is, troch it feit dat de sûnenskontrôle mislearre, kin de nije ferzje fan 'e applikaasje net ynset wurde. As resultaat sjogge jo dat it systeem werom is nei it brûken fan de âlde ferzje fan 'e applikaasje, en de nije ferzje is gewoan ûntslein.
It goede ding hjirfan is dat sels as jo in enoarm oantal simultane oanfragen hawwe dy't yn 'e applikaasje komme, sille se de downtime net iens fernimme by it útfieren fan de ynsetproseduere. As jo dizze applikaasje testen mei it Gatling-ramt, dat it safolle mooglik oanfragen stjoert, dan sil gjin fan dizze oanfragen falle. Dit betsjut dat ús brûkers ferzje-updates net iens yn realtime sille fernimme. As it mislearret, sil it wurk trochgean oan 'e âlde ferzje; as it suksesfol is, sille brûkers oerstappe nei de nije ferzje.
D'r is mar ien ding dat kin mislearje - as de sûnenskontrôle slagget, mar de applikaasje mislearret sa gau as de wurkdruk derop wurdt tapast, dat is, it ynstoarten sil pas plakfine nei't de ynset is foltôge. Yn dit gefal moatte jo manuell weromdraaie nei de âlde ferzje. Dat, wy seagen nei hoe't jo Kubernetes kinne brûke mei de iepen boarne-ark dêrfoar ûntworpen. It ynsetproses sil folle makliker wêze as jo dizze ark bouwe yn jo Build / Deploy pipelines. Tagelyk, om de ynset te begjinnen, kinne jo de brûkersynterface brûke of dit proses folslein automatisearje troch te brûken, bygelyks, ynsette foar master.
Us Build Server sil in Docker-ôfbylding oanmeitsje, triuwe it yn Docker Hub of hokker register jo ek brûke. Docker Hub stipet webhook, sadat wy ynset op ôfstân kinne triggerje fia Deployer op 'e manier hjirboppe werjûn. Op dizze manier kinne jo de ynset fan jo applikaasje nei potinsjele produksje folslein automatisearje.
Litte wy trochgean nei it folgjende ûnderwerp - skaalfergrutting fan it Kubernetes-kluster. Tink derom dat it kommando kubectl in skaalfergrutting is. Mei mear help kinne wy it oantal replika's yn ús besteande kluster maklik ferheegje. Yn 'e praktyk wolle wy lykwols gewoanlik it oantal knooppunten ferheegje ynstee fan pods.
Tagelyk, yn 'e wurktiden moatte jo miskien ferheegje, en nachts, om de kosten fan Amazon-tsjinsten te ferminderjen, moatte jo miskien it oantal rinnende applikaasje-eksimplaren ferminderje. Dit betsjut net dat it skaalfergrutting fan allinich it oantal pods genôch is, want sels as ien fan 'e knooppunten idle is, sille jo Amazon der noch foar betelje moatte. Dat is, tegearre mei it skaalfergrutting fan de pods, moatte jo it oantal brûkte masines skaalje.
Dit kin útdaagjend wêze, want oft wy Amazon brûke as in oare wolktsjinst, Kubernetes wit neat oer it oantal masines dat wurdt brûkt. It mist in ark wêrmei jo it systeem op it knooppuntnivo kinne skaalje.
Dat wy sille moatte soargje foar sawol knopen as pods. Wy kinne de lansearring fan nije knooppunten maklik skaalje mei de AWS API en skaalgroepmasines om it oantal Kubernetes-wurkerknooppunten te konfigurearjen. Jo kinne ek cloud-init of in ferlykber skript brûke om knopen te registrearjen yn it Kubernetes-kluster.
De nije masine begjint yn 'e Scaling-groep, inisjearret himsels as in knooppunt, registrearret yn' e master's register en begjint te wurkjen. Hjirnei kinne jo it oantal replika's ferheegje foar gebrûk op 'e resultearjende knopen. Skaalfergrutting fereasket mear ynspanning, om't jo moatte soargje dat sa'n stap net liedt ta de ferneatiging fan al rinnende applikaasjes nei it útsetten fan "ûnnedige" masines. Om sa'n senario te foarkommen, moatte jo de knooppunten ynstelle op 'e "ûnplanbere" status. Dit betsjut dat de standertplanner dizze knopen negearje sil by it plannen fan DaemonSet-pods. De planner sil neat fan dizze servers wiskje, mar sil dêr ek gjin nije konteners starte. De folgjende stap is om it drainknooppunt te ferwiderjen, dat is, om rinnende pods derfan oer te bringen nei in oare masine, of oare knopen dy't genôch kapasiteit hawwe foar dit. Sadree't jo der wis fan hawwe dat d'r gjin konteners mear binne op dizze knopen, kinne jo se fuortsmite fan Kubernetes. Hjirnei sille se gewoan ophâlde te bestean foar Kubernetes. Folgjende moatte jo de AWS API brûke om ûnnedige knopen of masines út te skeakeljen.
Jo kinne Amdatu Scalerd brûke, in oar iepenboarne-skaalark dat fergelykber is mei de AWS API. It leveret in CLI om knopen yn in kluster ta te foegjen of te ferwiderjen. De nijsgjirrige funksje is de mooglikheid om de planner te konfigurearjen mei it folgjende json-bestân.
De werjûn koade ferminderet de klusterkapasiteit mei de helte yn 'e nachtperioade. It konfigurearret sawol it oantal beskikbere replika's as de winske kapasiteit fan it Amazon-kluster. It brûken fan dizze planner sil it oantal knooppunten nachts automatysk ferminderje en se moarns ferheegje, en besparret de kosten fan it brûken fan knooppunten fan in wolktsjinst lykas Amazon. Dizze funksje is net ynboud yn Kubernetes, mar mei Scalerd kinne jo dit platfoarm skaalje lykas jo wolle.
Ik wol der op wize dat in protte minsken my sizze: "Dat is allegear goed en goed, mar hoe sit it mei myn database, dy't normaal statysk is?" Hoe kinne jo sa'n ding útfiere yn in dynamyske omjouwing lykas Kubernetes? Yn myn miening moatte jo dit net dwaan, jo moatte net besykje in gegevenspakhûs yn Kubernetes út te fieren. Dit is technysk mooglik, en d'r binne tutorials op it ynternet oer dit ûnderwerp, mar it sil jo libben serieus komplisearje.
Ja, d'r is in konsept fan persistente winkels yn Kubernetes, en jo kinne besykje gegevenswinkels lykas Mongo of MySQL út te fieren, mar dit is nochal in arbeidsintensive taak. Dit komt troch it feit dat data warehouses net folslein stypje ynteraksje mei in dynamyske omjouwing. De measte databases fereaskje wichtige konfiguraasje, ynklusyf hânmjittich konfiguraasje fan it kluster, net leuk autoscaling en oare ferlykbere dingen.
Dêrom moatte jo jo libben net komplisearje troch te besykjen in gegevenspakhús yn Kubernetes út te fieren. Organisearje har wurk op 'e tradisjonele manier mei fertroude tsjinsten en jouwe Kubernetes gewoan de mooglikheid om se te brûken.
Om it ûnderwerp te sluten, wol ik jo graach yntrodusearje oan it Cloud RTI-platfoarm basearre op Kubernetes, dêr't myn team oan wurket. It biedt sintralisearre logging, tapassing en klustermonitoring, en in protte oare nuttige funksjes dy't fan pas komme sille. It brûkt ferskate iepen boarne-ark lykas Grafana om tafersjoch te werjaan.
D'r wie in fraach oer wêrom't de ha-proxy load balancer brûke mei Kubernetes. Goede fraach, om't d'r op it stuit 2 nivo's fan load balancing binne. Kubernetes-tsjinsten wenje noch op firtuele IP-adressen. Jo kinne se net brûke foar havens op eksterne hostmasines, om't as Amazon syn wolkhost oerladen, sil it adres feroarje. Dit is wêrom wy ha-proxy pleatse foar de tsjinsten - om in mear statyske struktuer te meitsjen foar ferkear om naadloos te kommunisearjen mei Kubernetes.
In oare goede fraach is hoe kinne jo soargje foar wizigingen fan databaseskema by it dwaan fan blau / griene ynset? It feit is dat nettsjinsteande it gebrûk fan Kubernetes, it feroarjen fan it databankskema in drege taak is. Jo moatte derfoar soargje dat it âlde en nije skema kompatibel binne, wêrnei't jo de databank bywurkje kinne en dan de applikaasjes sels bywurkje. Jo kinne de databank hot ruilje en dan de applikaasjes bywurkje. Ik wit fan minsken dy't hawwe boot up in folslein nij databank kluster mei in nij skema, dit is in opsje as jo in schemeless databank lykas Mongo, mar it is net in maklike taak dochs. As jo gjin fierdere fragen hawwe, tank foar jo oandacht!
Guon advertinsjes 🙂
Tankewol foar it bliuwen by ús. Hâld jo fan ús artikels? Wolle jo mear ynteressante ynhâld sjen? Stypje ús troch in bestelling te pleatsen of oan te befeljen oan freonen, , in unike analoog fan servers op yngongsnivo, dy't troch ús foar jo útfûn is: (beskikber mei RAID1 en RAID10, oant 24 kearnen en oant 40GB DDR4).
Dell R730xd 2 kear goedkeaper yn Equinix Tier IV data sintrum yn Amsterdam? Allinne hjir yn Nederlân! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - fan $99! Lêze oer
Boarne: www.habr.com