Kubernetes ji bo meşandina konteynerên Docker-ê di hawîrdorek hilberîna komkirî de amûrek girîng e. Lêbelê, pirsgirêk hene ku Kubernetes nikare çareser bike. Ji bo birêkûpêkkirina hilberînê ya pir caran, pêdivî ye ku em bi cîhkirina Blue/Kesk bi tevahî otomatîkî ji pêvajoyê dûr bikevin, ku di heman demê de pêdivî ye ku daxwazên HTTP-ê yên derveyî jî bi rê ve bibe û barkirinên SSL-ê pêk bîne. Ev hewce dike ku bi hevsengek barkirinê ya wekî ha-proxy re entegrasyonê bike. Pirsgirêkek din pîvana nîv-otomatîkî ya koma Kubernetes bi xwe ye dema ku di hawîrdora ewr de dimeşe, mînakî bi şev bi qismî piçûkkirina komê ye.
Digel ku Kubernetes van taybetmendiyan ji qutîkê nîne, ew API-yek peyda dike ku hûn dikarin bikar bînin da ku pirsgirêkên wekhev çareser bikin. Amûrên ji bo bicîhkirina otomatîkî ya Şîn/Kesk û pîvandina komek Kubernetes wekî beşek ji projeya Cloud RTI, ku li ser bingeha çavkaniya vekirî hate afirandin, hatin pêşve xistin.
Vê gotarê, transkrîptek vîdyoyê, nîşanî we dide ka meriv çawa Kubernetes digel pêkhateyên din ên çavkaniya vekirî saz dike da ku hawîrdorek amade-hilberînê biafirîne ku kodê ji git commit bêyî dema hilberandinê qebûl dike.
Ji ber vê yekê, gava ku hûn gihîştin serîlêdanên xwe yên ji cîhana derve, hûn dikarin dest bi sazkirina bi tevahî otomasyonê bikin, ango, wê bînin qonaxa ku hûn dikarin git commit pêk bînin û pê ewle bin ku ev git commit di hilberînê de bi dawî dibe. Bi xwezayî, dema pêkanîna van gavan, dema bicîhkirina bicîhkirinê, em naxwazin bi demdirêjiyê re rû bi rû bimînin. Ji ber vê yekê, her otomasyonek li Kubernetes bi API-ê dest pê dike.
Kubernetes ne amûrek e ku meriv dikare bi rengek hilberî ji qutiyê were bikar anîn. Bê guman, hûn dikarin wiya bikin, kubectl û hwd bikar bînin, lê dîsa jî API di vê platformê de tiştê herî balkêş û bikêr e. Bi karanîna API-ê wekî komek fonksiyonan, hûn dikarin hema hema her tiştê ku hûn dixwazin li Kubernetes bikin bigihîjin. kubectl bixwe jî API-ya REST bikar tîne.
Ev REST e, ji ber vê yekê hûn dikarin zimanek an amûrek bikar bînin ku bi vê API-ê re bixebitin, lê jiyana we dê ji hêla pirtûkxaneyên xwerû ve pir hêsantir bibe. Tîma min 2 pirtûkxaneyên weha nivîsandin: yek ji bo Java / OSGi û yek jî ji bo Go. Ya duyemîn pir caran nayê bikar anîn, lê di her rewşê de van tiştên kêrhatî di destê we de ne. Ew projeyek çavkaniya vekirî ya qismî destûrdar in. Ji bo zimanên cihê gelek pirtûkxaneyên weha hene, ji ber vê yekê hûn dikarin yên ku ji we re çêtirîn hilbijêrin hilbijêrin.
Ji ber vê yekê, berî ku hûn dest bi sazkirina xweya otomatîkî bikin, hûn hewce ne ku pê ewle bin ku pêvajo dê nekeve nav demek domdar. Mînakî, tîmê me di nîvê rojê de dema ku mirov herî zêde serîlêdanan bikar tînin de bicîhkirina hilberînê pêk tîne, ji ber vê yekê girîng e ku di vê pêvajoyê de dereng nemînin. Ji bo ku ji demdirêjiyê dûr nekevin, 2 rêbaz têne bikar anîn: şîn/kesk danîn an nûvekirina gerok. Di doza paşîn de, heke we 5 kopiyên serîlêdanê dimeşînin, ew bi rêz li pey hev têne nûve kirin. Ev rêbaz pir baş dixebite, lê heke we guhertoyên cihêreng ên serîlêdanê di dema pêvajoya sazkirinê de bi hevdemî dimeşin ne maqûl e. Di vê rewşê de, hûn dikarin pêwendiya bikarhênerê nûve bikin dema ku paşîn guhertoya kevn dimeşîne, û serîlêdan dê bixebite. Ji ber vê yekê, ji hêla bernamekirinê ve, di şert û mercên weha de xebitîn pir dijwar e.
Ev yek ji wan sedemên ku em tercîh dikin ku karanîna şîn/kesk bikar bînin da ku bicîhkirina serîlêdanên xwe otomatîk bikin. Bi vê rêbazê, divê hûn pê ewle bibin ku tenê yek guhertoya serîlêdanê di demekê de çalak e.
Mekanîzmaya bicihkirina şîn/kesk bi vî rengî xuya dike. Em ji bo serîlêdanên xwe seyrûseferê bi navgîniya ha-proxy distînin, ku wê berbi kopiyên sepana heman guhertoyê dimeşîne.
Dema ku veguheztinek nû tê çêkirin, em Deployer bikar tînin, ku hêmanên nû têne dayîn û guhertoya nû saz dike. Bicihkirina guhertoyek nû ya serîlêdanê tê vê wateyê ku komek nû ya kopiyan "rakir" tê, piştî ku ev kopiyên guhertoya nû di nav pêçekek veqetandî û nû de têne destpêkirin. Lêbelê, ha-proxy di derbarê wan de tiştek nizane û hîna jî bargiraniya xebatê rê nade wan.
Ji ber vê yekê, berî her tiştî, pêdivî ye ku meriv ceribandinek performansê ya guhertoyên nû yên kontrolkirina tenduristiyê bike da ku pê ewle bibe ku kopya ji bo karûbarê barkirinê amade ne.
Pêdivî ye ku hemî pêkhateyên bicîhkirinê hin şêwazek kontrolkirina tenduristiyê piştgirî bikin. Dema ku hûn kodek bi statûya 200-ê, an kontrolek kûrtir werdigirin, ev dikare kontrolek bangek HTTP-ê ya pir hêsan be, ku tê de hûn girêdana kopiyan bi databas û karûbarên din re, aramiya girêdanên hawîrdora dînamîkî kontrol dikin. , û gelo her tişt rast dest pê dike û dixebite. Ev pêvajo dikare pir tevlihev be.
Piştî ku pergal piştrast kir ku hemî kopiyên nûvekirî dixebitin, Deployer dê veavakirinê nûve bike û konfigurasyona rast derbas bike, ku dê ha-proxy ji nû ve saz bike.
Tenê piştî vê yekê dê seyrûsefer bi kopiyên guhertoya nû ber bi podê ve were rêve kirin, û podê kevn dê winda bibe.
Ev mekanîzma ne taybetmendiyek Kubernetes e. Têgîna bicîhkirina şîn / kesk ji demek dirêj ve li dora xwe ye û her gav balansek barkirinê bikar aniye. Pêşîn, hûn hemî seyrûseferê berbi guhertoya kevn a serîlêdanê ve dikin, û piştî nûvekirinê, hûn wê bi tevahî veguhezînin guhertoya nû. Ev prensîb ne tenê di Kubernetes de tê bikaranîn.
Naha ez ê ji we re hêmanek nûvekirinê nas bikim - Deployer, ku kontrolên tenduristiyê pêk tîne, proxiyan ji nû ve saz dike, û hwd. Ev têgehek e ku ji cîhana derve re derbas nabe û di hundurê Kubernetes de heye. Ez ê nîşanî we bidim ka hûn çawa dikarin têgîna Deployer-a xwe bi karanîna amûrên çavkaniya vekirî biafirînin.
Ji ber vê yekê, yekem tiştê ku Deployer dike ev e ku bi karanîna Kubernetes API-ê kontrolkerek dubarekirina RC biafirîne. Ev API ji bo pêşdebirina pêvek pod û karûbaran diafirîne, ango ew ji bo serîlêdanên me komek bi tevahî nû diafirîne. Mîna ku RC pê bawer bû ku kopiyan dest pê kirine, ew ê li ser fonksiyona wan kontrolek tenduristiyê bike. Ji bo vê yekê, Deployer fermana GET / tenduristiyê bikar tîne. Ew hêmanên şopandinê yên guncan dimeşîne û hemî hêmanên ku piştgirî didin xebata komê kontrol dike.
Piştî ku hemî pods tenduristiya xwe rapor kirin, Deployer hêmanek veavakirinê ya nû diafirîne - etcd hilanînê belavkirî, ku ji hêla Kubernetes ve di hundurê de tê bikar anîn, tevî hilanîna veavakirina hevsengiya barkirinê. Em daneyan li etcd dinivîsin, û amûrek piçûk a bi navê confd çavdêrîkirina etcd ji bo daneyên nû.
Ger ew di veavakirina destpêkê de guhertinek bibîne, ew pelek mîhengek nû çêdike û wê vediguheze ha-proxy. Di vê rewşê de, ha-proxy bêyî ku tu pêwendiyan winda bike ji nû ve dest pê dike û barkirina karûbarên nû yên ku dihêle guhertoya nû ya serîlêdanên me bixebite vedigire.
Wekî ku hûn dibînin, tevî pirbûna pêkhateyan, li vir tiştek tevlihev tune. Hûn tenê hewce ne ku hûn bêtir bala xwe bidin API û hwd. Ez dixwazim ji we re li ser vekêşana çavkaniya vekirî ya ku em bixwe bikar tînin - Amdatu Kubernetes Deployer.
Ew amûrek ji bo organîzekirina bicihkirina Kubernetes e û xwedî taybetmendiyên jêrîn e:
- Daxistina şîn/kesk;
- sazkirina balansek barkirinê ya derveyî;
- birêvebirina danasînên belavkirinê;
- birêvebirina belavkirina rastîn;
- kontrolkirina fonksiyona kontrolên tenduristiyê yên di dema bicîhkirinê de;
- pêkanîna guhêrbarên jîngehê di nav potan de.
Ev Deployer li ser API-ya Kubernetes-ê hatî çêkirin û ji bo birêvebirina destan û birêkûpêkkirinê API-ya REST-ê peyda dike, û her weha API-ya Websocket-ê ji bo têketinên weşana di dema pêvajoya bicîhkirinê de peyda dike.
Ew daneyên veavakirina hevsengiya barkirinê dixe nav etcd-ê, ji ber vê yekê hûn ne hewce ne ku hûn ha-proxy-ê bi piştevaniya derveyî-paşvekirî bikar bînin, lê bi hêsanî pelê veavakirina balansa barkirinê ya xweya xwe bikar bînin. Amdatu Deployer di Go de, mîna Kubernetes bixwe, hatî nivîsandin û ji hêla Apache ve hatî destûr kirin.
Berî ku min dest bi karanîna vê guhertoya sazkerê kir, min ravekera dakêşanê ya jêrîn bikar anî, ku pîvanên ku ez hewce dikim diyar dike.
Yek ji pîvanên girîng ên vê kodê çalakkirina ala "useHealthCheck" e. Pêdivî ye ku em diyar bikin ku divê di dema pêvajoya veqetandinê de kontrolek hişmendiyê were kirin. Ev mîheng dikare bête neçalak kirin dema ku veqetandin konteynerên partiya sêyemîn ên ku ne hewce ne bêne verast kirin bikar tîne. Ev raveker di heman demê de hejmara kopiyan û URL-ya pêşîn a ku ha-proxy hewce dike destnîşan dike. Di dawiyê de ala taybetmendiya pod "podspec" heye, ku ji bo agahdariya li ser veavakirina portê, wêne, hwd gazî Kubernetes dike. Ev ravekerek JSON-ê pir hêsan e.
Amûrek din a ku beşek ji projeya Amdatu-çavkaniya vekirî ye Deploymentctl ye. Ew ji bo veavakirina veavakirinan UI heye, dîroka bicîhkirinê hildide, û ji bo vegerandina bangên ji bikarhêner û pêşdebirên partiya sêyemîn re tevnhevokan vedihewîne. Hûn dikarin UI-ê bikar neynin ji ber ku Amdatu Deployer bixwe API-ya REST e, lê ev navbeynkar dikare bêyî tevlêbûna API-ê ji we re pir hêsantir bike. Deploymentctl di OSGi/Vertx de bi karanîna Angular 2 ve hatî nivîsandin.
Ez ê naha bi karanîna tomarek pêş-qeydkirî ya jorîn li ser ekranê destnîşan bikim da ku hûn ne li bendê bin. Em ê serîlêdanek Go ya hêsan bicîh bikin. Xem neke ger we berê Go neceribandiye, ew serîlêdanek pir hêsan e ji ber vê yekê divê hûn karibin wê fêhm bikin.
Li vir em serverek HTTP diafirînin ku tenê bersivê dide /tendurustiyê, ji ber vê yekê ev serîlêdan tenê kontrolkirina tenduristiyê diceribîne û ne tiştek din. Ger kontrol derbas bibe, avahiya JSON ku li jêr tê xuyang kirin tê bikar anîn. Ew guhertoya serîlêdanê ya ku dê ji hêla sazker ve were bicîh kirin, peyama ku hûn li serê pelê dibînin, û celebê daneya boolean vedihewîne - gelo serîlêdana me dixebite an na.
Min bi rêza paşîn re piçek xapandin, ji ber ku min nirxek boolean a sabît li jorê pelê bi cih kir, ku di pêşerojê de dê ji min re bibe alîkar ku tewra serîlêdanek "nexweş" bicîh bikim. Em ê paşê bi vê yekê re mijûl bibin.
Ji ber vê yekê em dest pê bikin. Pêşîn, em bi karanîna fermana ~ kubectl get pods hebûna her podên xebitandinê kontrol dikin û, li ser bingeha nebûna bersivek ji URL-ya pêşîn, em piştrast dikin ku niha tu vekêşan nayên kirin.
Dûv re li ser ekranê hûn navbeynkariya Deploymentctl ya ku min behs kir, dibînin, ku tê de pîvanên bicîhkirinê têne danîn: cîhê nav, navê serîlêdanê, guhertoya bicîhkirinê, hejmara kopiyan, URL-ya pêşîn, navê konteynerê, wêne, sînorên çavkaniyê, jimareya portê ji bo kontrolkirina tenduristiyê, hwd. Sînorên çavkaniyê pir girîng in, ji ber ku ew dihêlin ku hûn herî zêde jimareya hardware bikar bînin. Li vir hûn dikarin têketina Dabeşkirinê jî bibînin.
Ger hûn niha fermana ~ kubectl get pods dubare bikin, hûn dikarin bibînin ku pergal 20 saniyeyan "cemidîne" û di vê demê de ha-proxy ji nû ve tê vesaz kirin. Piştî vê yekê, pod dest pê dike, û kopiya me dikare di têketina sazkirinê de were dîtin.
Min benda 20 duyemîn ji vîdyoyê qut kir, û naha hûn dikarin li ser ekranê bibînin ku guhertoya yekem a serîlêdanê hatiye bicîh kirin. Hemî ev tenê bi karanîna UI-yê hate kirin.
Naha em guhertoya duyemîn biceribînin. Ji bo vê yekê, ez peyama serîlêdanê ji "Silav, Kubernetes!" li ser "Silav, Deployer!", pergal vê wêneyê diafirîne û di qeyda Docker de bi cih dike, piştî ku em bi tenê di pencereya Deploymentctl de dîsa li ser bişkoja "Deploy" bikirtînin. Di vê rewşê de, têketina sazkirinê bixweber bi heman awayê ku dema ku guhertoya yekem a serîlêdanê hate bicîh kirin tê destpêkirin.
Fermana ~ kubectl get pods nîşan dide ku niha 2 guhertoyên serîlêdanê dimeşînin, lê pêşangeh nîşan dide ku em hîn jî guhertoya 1-ê dimeşînin.
Berhevkarê barkirinê li bendê ye ku kontrolkirina tenduristiyê biqede berî ku seyrûseferê berbi guhertoya nû vegerîne. Piştî 20 saniyeyan, em dizivirin curl û dibînin ku me nuha guhertoya 2-ya serîlêdanê hatî bicîh kirin, û ya yekem hate jêbirin.
Ev şandina serîlêdana "tendurist" bû. Ka em bibînin ka çi diqewime heke ji bo guhertoyek nû ya serîlêdanê ez parametreya Tendurist ji rast biguhezînim derewîn, ango ez hewl bidim ku serîlêdanek netendurist a ku di kontrolkirina tenduristiyê de têk çûye bicîh bikim. Heke di qonaxa pêşkeftinê de hin xeletiyên mîhengê di serîlêdanê de hatine çêkirin, û ew di vê formê de di hilberînê de were şandin ev dikare bibe.
Wekî ku hûn dikarin bibînin, bicîhkirin di hemî gavên li jor re derbas dibe û ~kubectl distîne pods destnîşan dike ku her du pod dimeşin. Lê berevajî danasîna berê, têketin statûya wextê nîşan dide. Ango, ji ber ku kontrolkirina tenduristiyê têk çû, guhertoya nû ya serîlêdanê nikare were bicîh kirin. Wekî encamek, hûn dibînin ku pergalê vegerî ye ku guhertoya kevin a serîlêdanê bikar bîne, û guhertoya nû bi tenê hatî rakirin.
Tiştê baş di vê yekê de ev e ku her çend we hejmareke mezin ji daxwazên hevdemî têkevin serîlêdanê jî, ew ê di dema pêkanîna prosedûra danînê de jî guh nedin demajoyê. Ger hûn vê serîlêdanê bi karanîna çarçoweya Gatling-ê ceribînin, ku ew bi qasî ku pêkan daxwazan dişîne, wê hingê yek ji van daxwazan nayê avêtin. Ev tê vê wateyê ku bikarhênerên me dê di wextê rast de nûvekirinên guhertoyê jî nabînin. Ger ew têk neçe, dê kar li ser guhertoya kevn berdewam bike; heke ew serketî be, bikarhêner dê veguherînin guhertoya nû.
Tenê tiştek heye ku dikare têk biçe - heke kontrolkirina tenduristiyê biserkeve, lê serîlêdan bi lez têk diçe gava ku bargiraniya kar jê re tê sepandin, ango, hilweşîn dê tenê piştî ku bicîh kirin pêk were. Di vê rewşê de, hûn ê neçar bibin ku bi destan vegerin guhertoya kevn. Ji ber vê yekê, me nihêrî ka meriv çawa Kubernetes-ê bi amûrên çavkaniya vekirî yên ku ji bo wê hatine çêkirin bikar tîne. Ger hûn van amûran di nav boriyên xweya Avakirin/Damezrandin de ava bikin dê pêvajoya veqetandinê pir hêsantir be. Di heman demê de, ji bo destpêkirina sazkirinê, hûn dikarin navgîniya bikarhêner bikar bînin an jî vê pêvajoyê bi tevahî otomatîk bikin, mînakî, commit to master.
Pêşkêşkara meya Avakirinê dê wêneyek Docker biafirîne, wê bixe nav Docker Hub an çi qeyda ku hûn bikar tînin. Docker Hub webhook-ê piştgirî dike, ji ber vê yekê em dikarin bi awayê ku li jor hatî xuyang kirin bi navgîniya Deployer-ê ji dûr ve veqetînin. Bi vî rengî hûn dikarin bicîhkirina serîlêdana xwe li hilberîna potansiyel bi tevahî otomatîk bikin.
Ka em biçin ser mijara paşîn - pîvandina koma Kubernetes. Bala xwe bidinê ku fermana kubectl fermanek pîvandinê ye. Bi arîkariya bêtir, em dikarin bi hêsanî hejmara kopiyan di koma xweya heyî de zêde bikin. Lêbelê, di pratîkê de, em bi gelemperî dixwazin ku ji bilî podan hejmara nodeyan zêde bikin.
Di heman demê de, di dema demjimêrên xebatê de dibe ku hûn hewce ne ku zêde bikin, û bi şev, ji bo kêmkirina lêçûna karûbarên Amazon, dibe ku hûn hewce ne ku hejmara serîlêdanên xebitandinê kêm bikin. Ev nayê vê wateyê ku pîvandina tenê hejmara podan dê bes be, ji ber ku her çend yek ji girêk bêkar be jî, hûn ê dîsa jî ji bo wê bidin Amazon. Ango, digel pîvandina potan, hûn ê hewce bikin ku hejmara makîneyên ku têne bikar anîn pîvandin.
Ev dikare dijwar be ji ber ku em Amazon an karûbarek din a cloudê bikar bînin, Kubernetes di derheqê hejmara makîneyên ku têne bikar anîn de tiştek nizane. Ew amûrek tune ye ku destûrê dide te ku pergalê di asta nodê de pîvandin.
Ji ber vê yekê em ê neçar bin ku hem girêk û hem jî li ser piyan bigirin. Em dikarin bi hêsanî destpêkirina girêkên nû bi karanîna makîneyên koma AWS API û Scaling mezin bikin da ku hejmara girêkên karker ên Kubernetes mîheng bikin. Her weha hûn dikarin cloud-init an skrîptek wusa bikar bînin da ku girêkên di koma Kubernetes de tomar bikin.
Makîneya nû di koma Scaling de dest pê dike, xwe wekî nodek dest pê dike, di qeyda masterê de tomar dike û dest bi xebatê dike. Piştî vê yekê, hûn dikarin hejmara kopiyan ji bo karanîna li ser girêkên encam zêde bikin. Zêdebûn bêtir hewildan hewce dike, ji ber ku hûn hewce ne ku pê ewle bin ku gavavêtinek wusa piştî ku makîneyên "nepêwist" qut bike rê li ber tunekirina sepanên ku jixwe ve têne xebitandin nebe. Ji bo pêşîgirtina li senaryoyek wusa, hûn hewce ne ku girêkan li ser rewşa "bêplansaz" bicîh bikin. Ev tê vê wateyê ku dema plansazkirina DaemonSet podsên xwerû dê van girêkan paşguh bike. Plansaz dê tiştek ji van serveran jê neke, lê di heman demê de dê konteynerên nû jî li wir nede destpêkirin. Pêngava paşîn derxistina girêka drainê ye, ango guheztina pêlên xebitandinê ji wê veguhezîne makîneyek din, an girêkên din ên ku ji bo vê yekê xwedan kapasîteya têr in. Gava ku we piştrast kir ku êdî li ser van girêkan konteynir tune, hûn dikarin wan ji Kubernetes derxînin. Piştî vê yekê, ew ê tenê ji bo Kubernetes hebûna xwe rawestînin. Dûv re, hûn hewce ne ku API-ya AWS bikar bînin da ku girêk an makîneyên nepêwist neçalak bikin.
Hûn dikarin Amdatu Scalerd, amûrek din a pîvandina çavkaniyek vekirî ya mîna AWS API-ê bikar bînin. Ew CLI-yek peyda dike ku girêkên di komekê de zêde bike an jê rake. Taybetmendiya wê ya balkêş şiyana mîhengkirina plansazker bi karanîna pelê json jêrîn e.
Koda ku hatî destnîşan kirin di heyama şevê de kapasîteya komê nîvî kêm dike. Ew hem hejmara kopiyên berdest û hem jî kapasîteya xwestî ya koma Amazonê mîheng dike. Bikaranîna vê plansazkerê dê bixweber bi şev hejmara girêkan kêm bike û serê sibê wan zêde bike, lêçûna karanîna girêkan ji karûbarek ewr a mîna Amazonê xilas bike. Ev taybetmendî di Kubernetes de nehatiye çêkirin, lê karanîna Scalerd dê bihêle ku hûn vê platformê wekî ku hûn bixwazin mezin bikin.
Ez dixwazim destnîşan bikim ku gelek kes ji min re dibêjin, "Ev hemî baş û baş e, lê databasa min, ku bi gelemperî statîk e?" Hûn çawa dikarin di hawîrdorek dînamîkî ya mîna Kubernetes de tiştek wusa bimeşînin? Li gorî min, divê hûn vê yekê nekin, divê hûn hewl nekin ku li Kubernetes depoyek daneyê bimeşînin. Ev ji hêla teknîkî ve gengaz e, û li ser Înternetê li ser vê mijarê hînker hene, lê ew ê jiyana we bi giranî tevlihev bike.
Erê, li Kubernetes têgehek firotgehên domdar heye, û hûn dikarin hewl bidin ku firotgehên daneyê yên mîna Mongo an MySQL bimeşînin, lê ev karekî pir kedkar e. Ev ji ber vê yekê ye ku depoyên daneyê bi tevahî pêwendiya bi hawîrdorek dînamîkî re piştgirî nakin. Pir databasan pêdivî bi veavakirina girîng heye, di nav de veavakirina destan a komê, ji pîvandina otomatîkî û tiştên din ên mîna wan hez nakin.
Ji ber vê yekê, divê hûn jiyana xwe tevlihev nekin û hewl bidin ku li Kubernetes depoyek daneyê bimeşînin. Karûbarên xwe bi awayê kevneşopî bi karanîna karûbarên nas organîze bikin û bi tenê şiyana karanîna Kubernetes peyda bikin.
Ji bo qedandina mijarê, ez dixwazim we bi platforma Cloud RTI ya ku li ser Kubernetes-ê ye, ku tîmê min li ser dixebitî, nas bikim. Ew têketina navendî, çavdêriya serîlêdanê û komê, û gelek taybetmendiyên din ên bikêr ên ku dê bikêr werin peyda dike. Ew amûrên cihêreng-çavkaniya vekirî yên wekî Grafana bikar tîne da ku çavdêriyê nîşan bide.
Pirsek hebû ku çima bi Kubernetes re balansa barkirina ha-proxy bikar bînin. Pirsa baş e ji ber ku niha 2 astên hevsengiya barkirinê hene. Karûbarên Kubernetes hîn jî li ser navnîşanên IP-ya virtual dimînin. Hûn nekarin wan ji bo portên li ser makîneyên mêvandarê derveyî bikar bînin ji ber ku ger Amazon mêvandarê xweya ewr zêde bar bike, dê navnîşan biguhere. Ji ber vê yekê em ha-proxy li ber karûbaran bi cîh dikin - ji bo ku seyrûseferek bi Kubernetes re bêkêmasî ragihîne avahiyek statîktir biafirînin.
Pirseke din a baş ev e ku hûn çawa dikarin gava ku bicîhkirina şîn / kesk dikin guheztinên şemaya databasê bigirin? Rastî ev e ku bêyî karanîna Kubernetes-ê, guhartina şema databasê karekî dijwar e. Pêdivî ye ku hûn pê ewle bibin ku şema kevn û nû lihevhatî ne, piştî ku hûn dikarin databasê nûve bikin û dûv re serîlêdanan bixwe nûve bikin. Hûn dikarin databasê germ biguhezînin û dûv re serîlêdanan nûve bikin. Ez kesên ku bi nexşeyek nû ve komek databasek bi tevahî nû saz kirine nas dikim, heke we databasek bê pileyek mîna Mongo hebe ev vebijarkek e, lê her weha ew ne karekî hêsan e. Ger pirsên we yên din tune bin, spas ji bo baldariya we!
Hin reklam 🙂
Spas ji bo ku hûn bi me re bimînin. Ma hûn ji gotarên me hez dikin? Ma hûn dixwazin naveroka balkêştir bibînin? Piştgiriya me bikin bi danîna fermanek an pêşniyarkirina hevalan, , analogek bêhempa ya pêşkêşkerên asta têketinê, ku ji hêla me ve ji bo we hatî vedîtin: (bi RAID1 û RAID10, heta 24 core û heya 40 GB DDR4 peyda dibe).
Dell R730xd 2x erzantir li navenda daneya Equinix Tier IV li Amsterdam? Tenê li vir li Hollanda! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - ji $99! Li ser bixwînin
Source: www.habr.com