Îro ez plan dikim ku biaxivim ka meriv çawa serîlêdanan dinivîse û çi hewcedariyên serîlêdana we hene ku li Kubernetes baş bixebitin. Ji ber vê yekê ku di serîlêdanê de serêş nebe, da ku hûn ne hewce ne ku li dora wê "qirç" îcad bikin û ava bikin - û her tişt bi awayê ku Kubernetes bixwe dixwest dixebite.
Ev ders beşek ji "" Hûn dikarin dersên teorîk ên vekirî yên Dibistana Êvarê bibînin . Ji bo kesên ku ji vîdyoyê bêtir nivîsê tercîh dikin, me ev gotar amade kiriye.
Navê min Pavel Selivanov e, niha ez endezyarê sereke yê DevOps li Mail.ru Cloud Solutions me, em ewran çêdikin, em kubernetesên rêveberiyê çêdikin û hwd. Karên min naha di pêşkeftinê de arîkariya, derxistina van ewran, derxistina serîlêdanên ku em dinivîsin û rasterast pêşvexistina amûrên ku em ji bikarhênerên xwe re peyda dikin hene.
Ez DevOps dikim, ez ji bo sê salên paşîn difikirim. Lê, di prensîbê de, ez tiştê ku DevOps dike belkî nêzî pênc sal in dikim. Berî wê, ez bi piranî di nav tiştên admin de bûm. Min demek dirêj berê dest bi xebata bi Kubernetes re kir - belkî çar sal derbas bûn ku min bi wê re dest bi xebatê kir.
Bi gelemperî, min dest pê kir dema ku Kubernetes guhertoya 1.3 bû, belkî, û dibe ku 1.2 - dema ku ew hîn di destpêka xwe de bû. Naha ew êdî ne di destpêka xwe de ye - û diyar e ku di sûkê de daxwazek mezin ji bo endezyarên ku dixwazin karibin Kubernetes bikin heye. Û pargîdanî ji bo kesên weha daxwazek pir zêde heye. Ji ber vê yekê, bi rastî, ev ders xuya bû.
Ger em li gorî plana ku ez ê qala wê bikim biaxivin, wiha xuya dike, di nav kevanan de (TL;DR) hatiye nivîsandin - “pir dirêj; nexwîne". Pêşniyara min a îro dê ji navnîşên bêdawî pêk were.
Bi rastî, ez bi xwe ji pêşkêşiyên weha hez nakim dema ku ew têne çêkirin, lê ev mijarek wusa ye ku dema ku min vê pêşkêşiyê amade dikir, min bi tenê fêhm nekir ku meriv çawa vê agahiyê cûda organîze dike.
Ji ber ku, bi gelemperî, ev agahdarî "ctrl+c, ctrl+v" ye, di nav tiştên din de, Wiki-ya me ya di beşa DevOps de, ku ji bo pêşdebiran hewcedariyên me yên nivîskî hene: "Gelîno, da ku em serlêdana we li Kubernetes, divê bi vî rengî be."
Ji ber vê yekê pêşkêşî wekî navnîşek mezin derket holê. Bibore. Ez ê hewl bidim ku bi qasî ku gengaz be vebêjim da ku heke gengaz be ew bêzar nebe.
Ya ku em ê niha lê binêrin:
- ev yekem têketin in (qeydên serîlêdanê?), li Kubernetes bi wan re çi bikin, bi wan re çi bikin, divê ew çi bin;
- Di Kubernetes de bi veavakirinan re çi bikin, awayên çêtirîn û herî xirab ên mîhengkirina serîlêdanek ji bo Kubernetes çi ne;
- Ka em biaxivin ka kontrolên gihîştinê bi gelemperî çi ne, divê ew çawa xuya bikin;
- Ka em bipeyivin ka girtina bi xêr çi ye;
- em dîsa behsa çavkaniyan bikin;
- Ka em careke din dest bidin ser mijara hilanîna daneyan;
- û di dawiyê de ez ê ji we re vebêjim ka têgîna vê serîlêdana nepenî-xwecî ya ewr çi ye. Cloudnativeness, wekî rengdêrek vê têgehê ye.
Logs
Ez pêşniyar dikim ku bi têketinan dest pê bikin - li cihê ku divê ev têketin li Kubernetes werin avêtin. Naha we di Kubernetes de serîlêdanek da destpêkirin. Li gorî klasîkan, berê serlêdanan her gav li cîhek pelek têketin dinivîsandin. Serlêdanên xirab di pelrêça malê ya pêşdebirê ku sepanê da destpêkirin de têketinek li pelek nivîsand. Serlêdanên baş li cîhek pelek têketin nivîsandin /var/log.
Li gorî vê yekê, wekî din, rêveberên baş di binesaziyên xwe de hin tişt hatine mîheng kirin ku van têketin dikarin bizivirin - heman rsyslog, ku li van têketinan dinêre û gava tiştek bi wan tê, gelek ji wan hene, ew kopiyên paşvekişandinê çêdike, têketin li wir datîne. , pelên kevn, ji hefteyekê, şeş mehan û hin bêtir jê dike. Di teorîyê de, pêdivî ye ku şertên me hebin da ku tenê ji ber ku serîlêdan têketin dinivîse, cîhê li ser pêşkêşkerên hilberînê (pêşkêşkerên şer?) neqede. Û, li gorî vê, tevahiya hilberînê ji ber têketinê nesekinî.
Gava ku em diçin cîhana Kubernetes û heman tiştî li wir dimeşînin, yekem tiştê ku hûn dikarin bala xwe bidinê ev e ku mirov, wekî ku di pelê de têketin dinivîsin, nivîsandina wan berdewam dikin.
Derket holê ku heke em li ser Kubernetes biaxivin, cîhê rast ji bo nivîsandina têketin li deverek ji konteynirek dokerê ev e ku meriv wan ji serîlêdanê bi navê Stdout/Stderr binivîsîne, ango, herikên hilberîna standard ên pergala xebitandinê, derketina xeletiya standard. Ev awayê herî rast, hêsan û herî mentiqî ye ku meriv têketin di prensîbê de li Docker û bi taybetî di Kubernetis de bicîh bike. Ji ber ku ger serîlêdana we têketinên Stdout/Stderr dinivîse, wê hingê ew bi Docker û pêveka Kubernetes re ye ku biryarê bide ka bi van têketinan re çi bike. Docker dê bi xwerû pelên xwe yên taybetî di formata JSON de ava bike.
Li vir pirs derdikeve holê, hûn ê paşê bi van logan çi bikin? Riya herî hêsan zelal e, şiyana me heye ku em bikin kubectl logs û li van têketinên van "pod"an binêrin. Lê, dibe ku, ev ne vebijarkek pir baş e - pêdivî ye ku tiştek din bi têketin re were kirin.
Heya nuha, em di heman demê de bipeyivin, ji ber ku me li ser mijara têketinê sekinî, li ser tiştek wekî têketin divê xuya bike. Ango, ev rasterast ji Kubernetes re derbas nabe, lê gava ku em dest pê bikin bifikirin ka emê bi têketinê re çi bikin, dê baş be ku em li ser vê yekê jî bifikirin.
Pêdiviya me bi cûreyek amûrek heye, bi rengek dostane, ku dê van têketinên ku dokera me dixe nav pelên xwe bigire û wan bişîne cîhek. Bi gelemperî, em bi gelemperî di hundurê Kubernetes-ê de celebek nûnerek di forma DaemonSet de dest pê dikin - berhevkarek têketinê, ku bi hêsanî tê gotin ku têketinên ku Docker berhev dike li ku ne. Û ev kargêrê berhevkirinê bi tenê wan digire, dibe ku bi rengek wan di rê de parsek bike, dibe ku wan bi hin meta-agahiyên zêde dewlemend bike û, di dawiyê de, wan ji bo hilanînê dişîne cîhek. Guhertinên li wir jixwe mimkun in. Ya herî gelemperî dibe ku Elasticsearch e, ku hûn dikarin têketin hilînin û hûn dikarin bi hêsanî wan ji wir bistînin. Dûv re, daxwazek bikar bînin, Kibana bikar bînin, mînakî, li ser wan grafîkan ava bikin, li ser bingeha wan hişyariyan ava bikin, û hwd.
Ramana herî girîng, ez dixwazim dîsa dubare bikim, ev e ku di hundurê Docker de, nemaze di hundurê Kubernetes de, hilanîna têketinên we di pelê de ramanek pir xirab e.
Ji ber ku yekem, zehmet e ku têketinên di hundurê konteynerê de di pelê de bigirin. Pêdivî ye ku hûn pêşî herin nav konteynerê, li wir bicîh bikin, û dûv re li têketin binêrin. Xala din ev e ku heke hûn di pelê de têketin hebin, wê hingê konteynir bi gelemperî xwedan hawîrdorek mînîmalîst in û tu karûbarên ku bi gelemperî ji bo xebata normal bi têketin re hewce ne hene. Wan binax bikin, li wan binerin, di edîtorek nivîsê de vekin. Kêliya din ew e ku di pelek di hundurê konteynerê de têketinên me hebin, heke ev konteynir were jêbirin, hûn fam dikin, dê têketin bi wê re bimirin. Li gorî vê yekê, ji nû ve destpêkirina konteynerê tê vê wateyê ku êdî têketin tune ne. Dîsa, vebijarkek xirab.
Û xala paşîn ev e ku hûn di hundurê konteyneran de bi gelemperî serlêdana we heye û ew e - ew bi gelemperî pêvajoyek yekane ye ku dimeşîne. Li ser pêvajoyek ku dê pelan bi têketinên we re bizivirîne qet axaftin tune. Gava ku têketin dest bi nivîsandina pelê bikin, ev tê vê wateyê ku, bibore, em ê dest bi windakirina servera hilberînê bikin. Ji ber ku, yekem, dîtina wan dijwar e, kes wan naşopîne, plus kes wan kontrol nake - li gorî vê yekê, pel bêdawî mezin dibe heya ku cîhê li ser serverê bi tenê xilas bibe. Ji ber vê yekê, ez dîsa dibêjim ku têketina Docker, nemaze li Kubernetes, li pelek ramanek xirab e.
Xala din, li vir ez dixwazim dîsa li ser vê yekê biaxivim - ji ber ku em li ser mijara têketinê disekinin, dê baş be ku em biaxivin ka têketin çawa xuya dikin da ku meriv bi wan re hêsan bixebite. Wekî ku min got, mijar ne rasterast bi Kubernetes re têkildar e, lê ew pir baş bi mijara DevOps re têkildar e. Li ser mijara çanda pêşkeftinê û hevaltiya di navbera van her du beşên cûda - Dev û Ops, da ku her kes rehet be.
Ev tê vê wateyê ku bi îdeal, îro, têketin divê di formata JSON de bêne nivîsandin. Ger we hin serîlêdana weya nefêmkirî hebe, ku têketinên bi formên nefêmkirî dinivîse ji ber ku hûn cûreyek çapkirinê an tiştek wusa têxin nav xwe, wê hingê dem e ku hûn cûreyek çarçoveyek google bikin, cûreyek pêça ku dihêle hûn têketinek normal bicîh bînin; Parametreyên têketinê li JSON li wir çalak bikin, ji ber ku JSON formatek hêsan e, parkirina wê hêsan e.
Ger JSON-ya we li gorî hin pîvanan nexebite, kes nizane çi, wê hingê bi kêmanî têketinên bi rengek ku dikare were pars kirin binivîsin. Li vir, bêtir, hêja ye ku meriv li ser vê rastiyê bifikire ku, mînakî, heke hûn komek konteyneran dimeşînin an tenê bi nginx re pêvajoyê dikin, û her yekê mîhengên têketinê yên xwe hene, wê hingê wusa dixuye ku ew ê ji we re pir nerehet be ku hûn wan pars bikin. Ji ber ku ji bo her mînakek nû ya nginx hûn hewce ne ku parsera xwe binivîsin, ji ber ku ew têketin cûda dinivîsin. Dîsa, belkî hêja bû ku meriv bifikire ku meriv pê bawer bike ku van hemî mînakên nginx xwedan heman veavakirina têketinê ne û hemî têketinên xwe bi tevahî yekreng nivîsandine. Heman tişt bi tevahî hemî serlêdanan re derbas dibe.
Di dawiyê de, ez jî dixwazim sotemeniyê li agirê lê zêde bikim ku, bi îdeal, divê têketinên formata pir-xêz bêne dûr kirin. Tiştek li vir e, heke we çu carî bi berhevkarên têketinê re xebitî, wê hingê bi îhtîmalek we dîtiye ku ew çi soz didin we, ku ew dikarin bi têketinên pir-xêz re bixebitin, zanibin ka wan çawa berhev dikin, û hwd. Bi rastî, bi dîtina min, îro yek berhevkarek nikare têketinên pir-xêz bi normal, bi tevahî û bê xeletî berhev bike. Bi awayekî mirovî, da ku ew hêsan û bê xeletî be.
Lê şopa stack her gav têketinên pir-xêz e û meriv çawa ji wan dûr dikeve. Pirs li vir ev e ku têketin tomarek bûyerek e, û stactrace bi rastî ne têketinek e. Ger em têketin berhev bikin û wan li cîhek Elasticsearch bixin û dûv re grafîkan ji wan xêz bikin, hin raporên çalakiya bikarhêner li ser malpera we ava bikin, wê hingê gava ku hûn şopek stêrk digirin, ev tê vê wateyê ku di serîlêdana we de tiştek neçaverêkirî diqewime. Û wateya ku meriv bixweber şopek stackê li cîhek pergalê ku dikare wan bişopîne bar bike.
Ev nermalava (eynî Sentry) ye ku bi taybetî ji bo xebitandina şopa stackê hatî çêkirin. Ew dikare tavilê peywirên otomatîkî biafirîne, wan ji yekî re veqetîne, gava ku stacttraces diqewimin hişyar bike, van stacttraces li gorî yek celeb kom bike, û hwd. Di prensîbê de, dema ku em li ser têketin diaxivin, pir wate nake ku meriv li ser stactraces biaxive, ji ber ku ev her tişt, bi mebestên cihêreng tiştên cûda ne.
Guhertin
Dûv re em li ser veavakirina Kubernetes diaxivin: bi wê re çi bikin û serlêdanên hundurê Kubernetes çawa bêne mîheng kirin. Bi gelemperî, ez bi gelemperî dibêjim ku Docker ne li ser konteyneran e. Her kes dizane ku Docker di derbarê konteyneran de ye, tewra yên ku pir bi Docker re nexebitin. Ez dubare dikim, Docker ne li ser konteyneran e.
Docker, bi dîtina min, li ser standardan e. Û bi pratîkî ji bo her tiştî standard hene: standardên ji bo avakirina serîlêdana we, standardên ji bo sazkirina serîlêdana we.
Û ev tişt - me berê ew bikar anî, ew tenê bi hatina konteyneran re bi taybetî populer bû - ji vî tiştî re guhêrbarên ENV (hawirdorê) tê gotin, ango guhêrbarên jîngehê yên ku di pergala xebitandina we de ne. Ev bi gelemperî rêgezek îdeal e ku hûn serîlêdana xwe mîheng bikin, ji ber ku heke we serîlêdanên di JAVA, Python, Go, Perl, Xwedê nehêle, û ew hemî dikarin mêvandarê databasê, bikarhênerê databasê, guhêrbarên şîfreya databasê bixwînin, wê hingê ew îdeal e. We bi çar zimanên cûda serîlêdanên ku di plansaziya databasê de bi heman rengî hatine mîheng kirin hene. Bêhtir konfigurasyonên cûda tune.
Her tişt dikare bi karanîna guherbarên ENV ve were mîheng kirin. Dema ku em li ser Kubernetes diaxivin, rêyek girîng heye ku meriv guhêrbarên ENV rast di hundurê Deployment de ragihîne. Li gorî vê yekê, heke em li ser daneyên veşartî dipeyivin, wê hingê em dikarin tavilê daneyên veşartî ji guhêrbarên ENV (şîfreyên databasan, hwd.) bixin nav dizîyekê, komek nepenî biafirînin û di danasîna ENV-ê ya di Deployment de destnîşan bikin ku em rasterast eşkere nakin. nirxa vê guhêrbar, û nirxa vê guhêrbar şîfreya databasê dê ji veşartî were xwendin. Ev tevgera Kubernetes standard e. Û ev vebijarka herî îdeal e ku hûn serîlêdanên xwe mîheng bikin. Tenê di asta kodê de, dîsa ev ji bo pêşdebiran derbas dibe. Heke hûn DevOps in, hûn dikarin bipirsin: "Gelî, ji kerema xwe serîlêdana xwe hîn bikin ku guhêrbarên jîngehê bixwînin. Û em ê hemû kêfxweş bibin.”
Ger di pargîdaniyê de her kes guhêrbarên jîngehê yên bi navê heman rengî dixwîne, wê hingê ew pir baş e. Ji bo ku ew nebe ku hin li benda databasa postgresê ne, yên din li benda navê databasê ne, yên din li benda tiştek din in, yên din li benda dbnek celeb in, da ku, li gorî vê yekê, yekrêzî hebe.
Pirsgirêk dema ku we ew qas guhêrbarên jîngehê hene ku hûn tenê Deployment vedikin - û pênc sed rêzikên guhêrbarên jîngehê hene. Di vê rewşê de, we bi tenê guhêrbarên hawîrdorê derxistiye - û êdî hewce nake ku hûn xwe êşkence bikin. Di vê rewşê de, ew ê maqûl be ku meriv dest bi karanîna mîhengan bike. Ango, serîlêdana xwe perwerde bikin ku mîhengan bikar bînin.
Pirsa tenê ev e ku mîheng ne ya ku hûn difikirin ne. Config.pi ne mîhengek ku karanîna wê hêsan e. An jî hin mîhengan di forma xweya xwe de, wekî din diyarî - ev jî ne veavakirina mebesta min e.
Tiştê ku ez behs dikim veavakirina di formatên pejirandî de ye, ango standarda herî populer standarda .yaml e. Meriv çawa dixwîne, meriv dikare were xwendin, meriv çawa ji serîlêdanê dixwîne diyar e.
Li gorî vê yekê, ji bilî YAML, hûn dikarin, mînakî, JSON-ê jî bikar bînin, parsing bi qasî YAML-ê di warê xwendina veavakirina serîlêdanê de ji wir rehet e. Ji bo xwendinê ji mirovan re bi rengek berbiçav nerehettir e. Tu dikarî format biceribîne, a la ini. Ji hêla mirovî ve xwendin pir hêsan e, lê dibe ku meriv wê bixweber pêvajoyek nerehet be, di vê wateyê de ku heke hûn carî bixwazin mîhengên xwe biafirînin, dibe ku formata ini jixwe ji çêkirina nerehet be.
Lê di her rewşê de, çi formata ku hûn hilbijêrin, xal ev e ku ji nêrînek Kubernetes ve ew pir rehet e. Hûn dikarin tevahiya konfigurasyona xwe têxin hundurê Kubernetes, di ConfigMap de. Û dûv re vê mîhengê hildin û jê bipirsin ku ew di hundurê peldanka we de li hin pelrêça taybetî were danîn, ku serîlêdana we dê veavakirinê ji vê konfigurasyonê wekî ku ew tenê pelek be bixwîne. Ev, bi rastî, gava ku hûn di serîlêdana we de gelek vebijarkên veavakirinê hebin, tiştê ku meriv bikin baş e. An jî ew tenê celebek avahiyek tevlihev e, hêlînek heye.
Ger we konfigurasyonek heye, wê hingê hûn dikarin pir baş serîlêdana xwe hîn bikin, mînakî, ku bixweber guheztinên pelê ku konfigurimmap lê hatî lêkirin bişopîne, û di heman demê de dema ku konfigurasyon diguhezin bixweber serlêdana xwe ji nû ve dakêşin. Ev ê bi gelemperî vebijarkek îdeal be.
Dîsa, min berê li ser vê yekê peyivî - agahdariya veşartî ne di konfigurasyonê de ye, agahdariya veşartî ne di guherbaran de ye, agahdariya veşartî ne di veşartî de ye. Ji wir, vê agahdariya veşartî bi dîplomasiyê ve girêdin. Bi gelemperî em hemî danasînên tiştên Kubernetes, bicihkirin, konfigurasyon, karûbar di git de hilînin. Li gorî vê yekê, danîna şîfreya databasê di git de, her çend ew git-a we be jî, ku we di hundurê pargîdaniyê de heye, ramanek xirab e. Ji ber ku, bi kêmanî, git her tiştî bi bîr tîne û bi tenê rakirina şîfreyan ji wir ne ew qas hêsan e.
Kontrola tenduristiyê
Xala din ev tiştê ku jê re tê gotin Kontrola Tenduristiyê ye. Bi gelemperî, kontrolek tenduristiyê tenê kontrol dike ku serîlêdana we dixebite. Di heman demê de, em bi gelemperî li ser hin serîlêdanên malperê diaxivin, ji bo ku, li gorî vê yekê, ji hêla kontrolkirina tenduristiyê ve (çêtir e ku meriv li vir û pê ve neyê wergerandin) ev ê hin URL-ya taybetî be, ku ew wekî standardek, ew bi gelemperî dikin /health.
Dema ku gihîştina vê URL-ê, li gorî vê yekê, serîlêdana me dibêje "erê, baş e, her tişt bi min re baş e, 200" an "na, her tişt bi min re ne baş e, hin 500." Li gorî vê yekê, heke serîlêdana me ne http, ne serîlêdanek malperê be, em naha li ser celebek daemon diaxivin, em dikarin fêhm bikin ka meriv çawa kontrolên tenduristiyê dikin. Ango, ne hewce ye, heke serîlêdan ne http be, wê hingê her tişt bêyî kontrolek tenduristiyê dixebite û ev bi tu awayî nayê kirin. Hûn dikarin bi periyodîk hin agahdariya di pelê de nûve bikin, hûn dikarin ji bo daemonê xwe hin fermanek taybetî derxînin, mîna, daemon status, ku dê bêje "erê, her tişt baş e, daemon dixebite, ew zindî ye."
Ji bo çi ye? Tişta yekem û ya herî eşkere ev e ku dibe ku çima kontrolek tenduristiyê hewce ye - da ku fêm bikin ku serîlêdan dixebite. Yanî ew tenê ehmeq e, dema ku ew niha radibe, wusa dixuye ku ew dixebite, ji ber vê yekê hûn dikarin piştrast bin ku ew dixebite. Û derket holê ku serîlêdan dimeşîne, konteynir dimeşe, mînak dixebite, her tişt baş e - û dûv re bikarhêneran berê hemî hejmarên têlefonê ji piştgiriya teknîkî qut kirine û dibêjin "tu çi yî..., tu xew ket, tiştek naxebite.”
Kontrolek tenduristiyê tenê rêyek wusa ye ku meriv ji nêrîna bikarhêner bibîne ku ew dixebite. Yek ji rêbazan. Werin em bi vî awayî bînin ziman. Ji nihêrîna Kubernetes, ev di heman demê de rêyek e ku meriv fêm bike kengê serîlêdan dest pê dike, ji ber ku em fam dikin ku ferqek di navbera dema ku konteynir hate destpêkirin, afirandin û dest pê kirin, û dema ku serîlêdan rasterast di vê konteynerê de hate destpêkirin de heye. Ji ber ku heke em hin serîlêdana java-ya navîn bistînin û hewl bidin ku wê di dokê de bidin destpêkirin, wê hingê ji bo çil saniyeyan, an jî deqeyek, an jî deh deh, ew dikare baş dest pê bike. Di vê rewşê de, hûn dikarin bi kêmanî li benderên wê bixin, ew ê li wir bersiv nede, ango ew hîn ne amade ye ku seyrûseferê werbigire.
Dîsa, bi alîkariya kontrolek tenduristiyê û bi alîkariya rastiya ku em li vir vedigerin, em dikarin di Kubernetes de fêm bikin ku ne tenê konteynir di serîlêdanê de rabûye, lê serîlêdan bixwe jî dest pê kiriye, ew jixwe bersivê dide kontrolkirina tenduristiyê, ku tê vê wateyê ku em dikarin trafîkê bişînin wir.
Tiştê ku ez niha behs dikim, di nav Kubernetes de ceribandinên Amadeyî / Zindî ye, li gorî vê yekê, ceribandinên amadebûna me ji hebûna serîlêdanê di hevsengiyê de berpirsiyar in. Ango, ger ceribandinên amadebûnê di serîlêdanê de bêne kirin, wê hingê her tişt baş e, seyrûsefera xerîdar diçe serîlêdanê. Ger ceribandinên amadebûnê neyên kirin, wê hingê serîlêdan bi tenê beşdar nabe, ev mînaka taybetî beşdarî hevsengiyê nabe, ew ji hevsengiyê tê derxistin, û seyrûsefera xerîdar naherike. Li gorî vê yekê, ceribandinên Liveness di hundurê Kubernetes de hewce ne da ku ger serîlêdan asê bibe, ew ji nû ve were destpêkirin. Ger ceribandina zindîtiyê ji bo serîlêdana ku di Kubernetes de hatî ragihandin nexebite, wê hingê serîlêdan ne tenê ji hevsengiyê tê derxistin, ew ji nû ve tê destpêkirin.
Û li vir xalek girîng heye ku ez dixwazim behs bikim: ji hêla pratîkî ve, ceribandina amadebûnê bi gelemperî pir caran tê bikar anîn û ji ceribandina zindîtiyê pirtir hewce ye. Ango, bi tenê bê fikirîn ragihandina ceribandinên amadeyî û zindîtiyê, ji ber ku Kubernetes dikare wiya bike, û em her tiştê ku ew dikare bike bikar bînin, ne ramanek pir baş e. Ez ê rave bikim çima. Ji ber ku xala duduyan di ceribandinê de ev e ku ew ê ramanek baş be ku hûn di kontrolên tenduristiya xwe de karûbarê bingehîn kontrol bikin. Ev tê vê wateyê ku heke we serîlêdanek webê hebe ku hin agahdarî dide, ku di encamê de, bi xwezayî, divê ji deverek bigire. Di databasê de, wek nimûne. Welê, ew agahdariya ku tê vê REST API-ê di heman databasê de hilîne. Dûv re, li gorî vê yekê, heke kontrolkirina tenduristiya we bi tenê mîna slashhealth-ê têkilî bersivê bide, serîlêdan dibêje "200, baş e, her tişt baş e," û di heman demê de databasa serîlêdana we negihîştî ye, û serîlêdana kontrolkirina tenduristiyê dibêje "200, baş e, her tişt baş e. ” - Ev tendurustiyek xirab e. Bi vî awayî divê kar ne.
Ango dema ku daxwazek tê serîlêdana we /health, ew ne tenê bersivê nade, "200, ok", ew pêşî diçe, mînakî, databasê, hewl dide ku pê ve girêbide, li wir tiştek pir bingehîn dike, mîna yek hilbijêrin, tenê kontrol dike ku têkiliyek di nav de heye. database û hûn dikarin databasê bipirsin. Ger ev hemî serketî bû, wê hingê bersiv "200, baş e." Ger ew ne serketî be, dibêje ku xeletiyek heye, databas tune ye.
Ji ber vê yekê, di vî warî de, ez dîsa vegerim ceribandinên Amadebûn / Zindî - çima hûn bi îhtîmalek mezin hewceyê ceribandinek amadebûnê ne, lê ceribandinek zindîbûnê pirsek e. Ji ber ku heke hûn kontrolên tenduristiyê tam wekî ku min got diyar bikin, wê hingê derkeve holê ku ew di beşa nimûneyê de tune yeв или со всех instancedi databasek de, wek nimûne. Gava ku we ceribandinek amadebaşiyê ragihand, kontrolên me yên tenduristiyê dest bi têkçûnê kirin, û li gorî vê yekê hemî serîlêdanên ku databas jê nayên desteser kirin, ew bi hêsanî ji hevsengiyê têne qut kirin û di rastiyê de tenê di rewşek paşguhkirî de "daleqandî" dibin û li benda databasên xwe ne. kar.
Ger me ceribandinek zindîbûnê ragihand, wê hingê bifikire, databasa me şikestiye, û di Kubernetesên we de nîvê her tiştî ji nû ve dest pê dike ji ber ku ceribandina zindîbûnê têk diçe. Ev tê vê wateyê ku hûn hewce ne ku ji nû ve bidin destpêkirin. Tiştê ku hûn dixwazin ne ev e, tewra di pratîkê de ezmûna min a kesane jî hebû. Me serîlêdanek danûstendinê hebû ku di JS-ê de hatibû nivîsandin û di databasek Mongo de hate xwar. Pirsgirêk ev bû ku ew di destpêka xebata min de bi Kubernetes re bû, me amadebûn, zindîbûna ceribandinan li ser prensîba ku Kubernetes dikare wiya bike diyar kir, ji ber vê yekê em ê wê bikar bînin. Li gorî vê yekê, di hin xalan de Mongo piçek "geş" bû û nimûne dest bi têkçûnê kir. Li gorî vê yekê, li gorî ceribandina baranê, pêlavan dest bi "kuştinê" kirin.
Wekî ku hûn fêm dikin, gava ku ew "kuştin", ev sohbetek e, ango, ji xerîdaran ve gelek girêdan li ser wê ne. Ew jî "kuştin" - na, ne xerîdar, tenê girêdan - ne hemî di heman demê de, û ji ber ku ew di heman demê de nayên kuştin, hin berê, hin paşê, ew di heman demê de dest pê nakin. dem. Zêdeyî random standard, em nikarin her carê bi rastbûna mîlîçirkeyan dema destpêkirina serîlêdanê pêşbînî bikin, ji ber vê yekê ew wê yekê yek carî dikin. Yek infospot radibe, li hevsengiyê tê zêdekirin, hemî xerîdar têne wir, ew nikare li ber barek wusa rabe, ji ber ku ew bi tenê ye, û, bi gelemperî, bi dehan ji wan li wir dixebitin, û ew dikeve. Yê din radibe, hemû bar li ser wî ye, ew jî dikeve. Welê, ev ketina hanê tenê berdewam dike. Di dawiyê de, ev çawa hate çareser kirin - em tenê neçar bûn ku bi tundî seyrûsefera bikarhêner a vê serîlêdanê rawestînin, bila hemî mînak rabin û dûv re hemî seyrûsefera bikarhêner bi yekcarî dest pê bikin da ku ew jixwe di nav her deh mînakan de were belav kirin.
Ger ne ji vê ceribandina zindîbûnê bûya, ku dê zorê bide ku hemî ji nû ve dest pê bike, serîlêdanê wê baş bi rê ve bikira. Lê ji hevsengiyê her tişt ji bo me neçalak e, ji ber ku databas nayên gihîştinê û hemî bikarhêner "kêm bûne". Dûv re, gava ku ev databas peyda dibe, her tişt di hevsengiyê de tête navandin, lê ne hewce ye ku serîlêdan ji nû ve dest pê bikin, û ne hewce ye ku dem û çavkaniyan li ser vê yekê winda bikin. Ew hemî berê li vir in, ew ji bo trafîkê amade ne, ji ber vê yekê seyrûsefer tenê vedibe, her tişt baş e - serîlêdan li cîh e, her tişt berdewam dike.
Ji ber vê yekê, ceribandinên amadehî û zindîtiyê cûda ne, ji bilî vê, hûn dikarin bi teorîkî vekolînên tenduristiyê yên cihêreng bikin, mînakî yek celeb radii, yek celeb liv, û tiştên cûda kontrol bikin. Di dema ceribandinên amadebûnê de, paşnavên xwe kontrol bikin. Mînakî, li ser ceribandinek zindîtiyê, hûn ji hêla nêrînê ve kontrol nakin ku ceribandina zindîbûnê bi gelemperî tenê serîlêdanek bersivdayînê ye, heke ew bi tevahî karibe bersivê bide.
Ji ber ku ceribandina zindîtiyê, bi gelemperî, dema ku em "qeliqî" ye. Kêlekek bêdawî dest pê kir an tiştek din - û bêtir daxwaz nayên kirin. Ji ber vê yekê, maqûl e ku meriv wan jî ji hev veqetîne - û di wan de mantiqên cûda bicîh bîne.
Di derbarê tiştê ku hûn hewce ne ku gava ceribandinek we hebe, dema ku hûn kontrolên tenduristiyê dikin bersiv bidin. Ew bi rastî êşek e. Yên ku bi vê yekê dizanin dê belkî bikenin - lê bi ciddî, min di jiyana xwe de karûbar dîtine ku di 200% bûyeran de bersiva "XNUMX" didin. Yanî kî serketî ye. Lê di heman demê de di laşê bersivê de ew dinivîsin "çewtiyek wusa û wusa".
Ango, statûya bersivê ji we re tê - her tişt serketî ye. Lê di heman demê de, divê hûn laş parsek bikin, ji ber ku laş dibêje "bibore, daxwaz bi xeletiyek qediya" û ev tenê rastiyek e. Min ev di jiyana rast de dît.
Û ji bo ku hin kes wê xweş nabînin, û yên din jî wê pir bi êş dibînin, ew hîn jî hêja ye ku meriv qaîdeyek hêsan bişopîne. Di kontrolên tenduristiyê de, û di prensîbê de dema ku bi serîlêdanên malperê re dixebitin.
Ger her tişt baş bû, wê hingê bi bersiva du sedemîn bersiv bidin. Di prensîbê de, her bersivek du sed dê ji we re xweş be. Ger hûn pir baş dixwînin û dizanin ku hin statûyên bersivê ji yên din cûda ne, bi yên guncan bersiv bidin: 204, 5, 10, 15, çi be. Ger ew ne pir baş be, wê hingê tenê "du sifir sifir." Ger her tişt xirab bibe û kontrola tenduristiyê bersiv nede, wê hingê bi pênc sedemîn bersiv bidin. Dîsa, heke hûn fêm bikin ka meriv çawa bersivê dide, çawa statûyên bersivê yên cûda ji hevûdu cûda dibin. Heke hûn fêm nakin, wê hingê 502 vebijarka we ye ku hûn bersivê bidin kontrolên tenduristiyê heke tiştek xelet derkeve.
Ev xalek din e, ez dixwazim li ser kontrolkirina karûbarên bingehîn hinekî vegerim. Ger hûn dest pê bikin, mînakî, kontrolkirina hemî karûbarên bingehîn ên ku li pişt serlêdana we radiwestin - her tişt bi gelemperî. Tiştê ku em ji nêrîna mîmariya mîkro-xizmetê digirin, têgehek me ya wekî "hevgirêdana kêm" heye - ango dema ku karûbarên we bi kêmanî bi hev ve girêdayî ne. Ger yek ji wan têk neçe, hemî yên din bêyî vê fonksiyonê dê bi tenê xebata xwe bidomînin. Hin fonksiyon tenê ne kar dikin. Li gorî vê yekê, heke hûn hemî kontrolên tenduristiyê bi hevûdu ve girêdin, wê hingê hûn ê di binesaziyê de yek tişt têk biçin, û ji ber ku ew ket, hemî kontrolên tenduristiyê yên hemî karûbaran jî dest bi têkçûnê dikin - û bi gelemperî ji bo binesaziyê bêtir binesaziyek heye. tevahiya mîmariya mîkroxizmet No. Li wir her tişt tarî bû.
Ji ber vê yekê, ez dixwazim vê yekê dîsa dubare bikim ku hûn hewce ne ku karûbarên bingehîn kontrol bikin, yên ku bêyî wan serlêdana we di sedî sed de nikare karê xwe bike. Ango, mentiqî ye ku heke we REST API-ya ku bi navgîniya bikarhêner li databasê tomar dike an ji databasê vedigire, wê hingê di nebûna databasê de, hûn nikanin garantiya xebata bi bikarhênerên xwe re bidin.
Lê heke bikarhênerên we, gava ku hûn wan ji databasê derdixin, bi hin metadatayên din re, ji paşverûyek din, ku hûn têkevin berî ku bersivek ji pêşiyê re bişînin, tê de dewlemend bibin - û ev paşverû peyda nabe, ev tê vê wateyê ku hûn xwe didin bersiv bêyî ti beşek metadata.
Dûv re, di dema destpêkirina serlêdanan de yek ji wan pirsgirêkên me jî heye.
Di rastiyê de, ev ne tenê ji bo Kubernetes-ê bi gelemperî derbas dibe, wusa bû ku çanda hin cûre pêşkeftina girseyî û bi taybetî DevOps di heman demê de wekî Kubernetes dest pê kir. Ji ber vê yekê, bi gelemperî, derdikeve holê ku hûn hewce ne ku bêyî Kubernetes serîlêdana xwe bi dilovanî biqedînin. Beriya Kubernetes jî, mirovan ev yek dikir, lê bi hatina Kubernetes re, me bi girseyî dest bi axaftinê kir.
Shutdown Graceful
Bi gelemperî, Graceful Shutdown çi ye û çima hewce ye? Ev di derheqê dema ku serîlêdana we ji ber hin sedeman têk diçe, divê hûn bikin app stop - an hûn, mînakî, îşaretek ji pergala xebitandinê distînin, divê serîlêdana we jê fam bike û li ser wê tiştek bike. Senaryoya herî xirab, bê guman, dema ku serîlêdana we SIGTERM werdigire û wekî "SIGTERM, em bisekinin, bixebitin, tiştek nekin." Ev vebijarkek tam xirab e.
Vebijarkek hema hema bi heman rengî xirab ev e dema ku serîlêdana we SIGTERMek werdigire û mîna "wan got segterm, ev tê vê wateyê ku em diqedin, min nedîtiye, ez ti daxwazên bikarhêneran nizanim, ez nizanim çi celeb daxwazên ku ez niha li ser dixebitim, wan got SIGTERM, ev tê vê wateyê ku em bi dawî dibin " Ev jî vebijarkek xirab e.
Kîjan vebijark baş e? Xala yekem ew e ku meriv qedandina operasyonan li ber çavan bigire. Vebijarkek baş ev e ku servera we hîn jî hesabê ku ew SIGTERM werdigire çi dike.
SIGTERM qutkirinek nerm e, ew bi taybetî hatî sêwirandin, dikare di asta kodê de were girtin, dikare were pêvajo kirin, bêje ku naha, li bendê bin, em ê pêşî karê ku me heye biqedînin, dûv re em ê derkevin.
Ji perspektîfek Kubernetes, ev e ku ew dixuye. Dema ku em ji podek ku di komika Kubernetes de dixebite re dibêjin, "ji kerema xwe re raweste, here," an em ji nû ve têne destpêkirin, an nûvekirinek çêdibe dema Kubernetes pelan ji nû ve diafirîne, Kubernetes tenê heman peyama SIGTERM ji pod re dişîne, li benda hinek dem, û, ev dema ku ew li bendê ye, ew jî tê mîheng kirin, di diploman de pîvanek wusa taybetî heye û jê re dibêjin Graceful ShutdownTimeout. Wekî ku hûn fêm dikin, ew ne ji bo tiştek tê gotin, û ne ji bo tiştek e ku em niha li ser wê dipeyivin.
Li wir em dikarin bi taybetî bibêjin ka em çiqasî hewce ne ku di navbera dema ku em SIGTERM ji serîlêdanê re dişînin û gava ku em fêm dikin ku serîlêdan ji tiştek dîn bûye an jî "zeliqiye" û ne bi dawî dibe de li bendê bin - û divê em jê re bişîne SIGKILL, ango bi zehmetî karê xwe temam bike. Ango, li gorî vê yekê, me celebek daemon heye, ew operasyonan dike. Em fêm dikin ku bi navînî operasyonên me yên ku daemon li ser dixebitîne di carekê de ji 30 saniyeyan zêdetir dom nakin. Li gorî vê yekê, dema ku SIGTERM digihîje, em fam dikin ku daemonê me herî zêde dikare 30 saniyeyan piştî SIGTERM biqedîne. Em wê dinivîsin, bo nimûne, 45 seconds tenê ji bo rewşê û dibêjin ku SIGTERM. Piştî wê em 45 saniyeyan li bendê dimînin. Di teoriyê de, di vê demê de divê cin karê xwe qedandiba û dawî li xwe bikira. Lê heke ji nişka ve nekare, ev tê vê wateyê ku ew bi îhtîmalek mezin asê maye - ew êdî daxwazên me bi asayî pêvajoyê nake. Û di 45 çirkeyan de hûn dikarin bi ewlehî, bi rastî, wî bixin xwarê.
Û li vir, bi rastî, 2 alî jî dikarin bêne hesibandin. Pêşîn, fêm bikin ku heke we daxwazek wergirt, we bi rengekî dest bi xebatê kir û bersivek neda bikarhêner, lê we SIGTERM, mînakî, wergirt. Aqil e ku meriv wê safî bike û bersivek bide bikarhêner. Di vî warî de xala yekem ev e. Li vir xala duduyan ev e ku heke hûn serlêdana xwe binivîsin, bi gelemperî mîmariya xwe bi vî rengî ava bikin ku hûn ji bo serîlêdana xwe daxwazek werbigirin, wê hingê hûn dest bi hin karan dikin, dest bi daxistina pelan ji cîhek dikin, databasek dakêşin, û hwd. Va. Bi gelemperî, bikarhênerê we, daxwaza we nîv saetê disekine û li bendê ye ku hûn bersiva wî bidin - wê hingê, bi îhtîmalek mezin, hûn hewce ne ku li ser mîmariyê bixebitin. Ango, tenê hişmendiya hevpar jî bihesibînin ku heke operasyonên we kurt bin, wê hingê maqûl e ku hûn SIGTERM paşguh bikin û wê biguhezînin. Ger operasyonên we dirêj in, wê hingê ne wate ye ku hûn di vê rewşê de SIGTERM paşguh bikin. Aqil e ku meriv mîmariyê ji nû ve dîzayn bike da ku ji operasyonên weha dirêj dûr bixe. Ji ber ku bikarhêner ne tenê li dora xwe bisekinin û bisekinin. Ez nizanim, li wir cûreyek websocket çêbikin, çengên berevajî ku servera we dê ji xerîdar re bişîne, tiştek din çêkin, lê bikarhêner neçar nekin ku nîv saetê daliqîne û tenê li benda rûniştinekê bimîne heya ku hûn bersiva wî bide. Ji ber ku ew li ku derê dibe ku bişkîne nayê pêşbînîkirin.
Dema ku serîlêdana we qediya, divê hûn kodek derketinê ya guncan peyda bikin. Ango, heke ji serîlêdana we hate xwestin ku were girtin, raweste, û wê karîbû xwe bi normalî rawestîne, wê hingê hûn ne hewce ne ku cûreyek koda derketinê 1,5,255 û hwd vegerînin. Tiştê ku ne koda sifir e, bi kêmanî di pergalên Linux de, ez ji vê yekê piştrast im, neserkeftî tê hesibandin. Ango, tê hesibandin ku serlêdana we di vê rewşê de bi xeletiyek qediya. Li gorî vê yekê, bi rengek dostane, ger serlêdana we bêyî xeletiyek qediya, hûn li ser encamnameyê 0 dibêjin. Ger serlêdana we ji ber hin sedeman têk biçe, hûn di encam de ne-0 dibêjin. Û hûn dikarin bi vê agahdariyê re bixebitin.
Û vebijarka dawî. Xerab e dema ku bikarhênerê we daxwazek dişîne û dema ku hûn wê pêvajoyê dikin nîv saetê daliqîne. Lê bi gelemperî, ez dixwazim li ser tiştê ku bi gelemperî ji hêla xerîdar ve hêja ye jî bibêjim. Ne girîng e ku we serîlêdana mobîl, pêş-end, hwd. Pêdivî ye ku meriv bihesibîne ku rûniştina bikarhêner dikare were qedandin, her tişt dikare bibe. Dibe ku daxwazek were şandin, ji bo nimûne, di bin pêvajoyek de û bersivek neyê vegerandin. Pêşiya we an serîlêdana weya desta - her pêşek bi gelemperî, em bi vî rengî bibêjin - divê vê yekê li ber çavan bigire. Ger hûn bi websocketan re bixebitin, ev bi gelemperî êşa herî xirab a ku min qet dîtiye.
Gava ku pêşdebirên hin sohbetên birêkûpêk nizanin ku, derdikeve holê, ku websocket dikare bişkîne. Ji bo wan, gava ku tiştek li proxy diqewime, em tenê vesazkirinê diguherînin, û ew ji nû ve barkirinek dike. Bi xwezayî, hemî danişînên demdirêj di vê rewşê de têne qut kirin. Pêşdebir têne ba me û dibêjin: "Gelîno, hûn çi dikin, sohbet ji bo hemî xerîdarên me têk çû!" Em ji wan re dibêjin: “Hûn çi dikin? Ma xerîdarên we nikaribin ji nû ve girêbidin? Dibêjin: “Na, pêwîst e em rûniştin neyên xirakirin.” Bi kurtasî, ev bi rastî bêaqil e. Pêwîst e ku aliyê xerîdar li ber çavan bê girtin. Bi taybetî, wekî ku ez dibêjim, bi danişînên demdirêj ên mîna websocketan re, ew dikare bişkîne û, ji hêla bikarhêner ve nehate dîtin, hûn hewce ne ku hûn ji nû ve danişînên weha saz bikin. Û paşê her tişt bêkêmasî ye.
Çavkaniyên
Bi rastî, li vir ez ê tenê çîrokek rasterast ji we re vebêjim. Dîsa ji jiyana rast. Tiştê herî nexweş ku min li ser çavkaniyan bihîstiye.
Di vê rewşê de çavkanî, mebesta min hin daxwazî, tixûbên ku hûn dikarin di komikên xwe yên Kubernetes de li ser podan bixin. Tişta herî xweş a ku min ji pêşdebirek bihîstiye… Yek ji pêşdebirên hevalên min ên li cîhek berê ya xebatê carekê got: "Serlêdana min dê di komê de dest pê neke." Min nêrî ku bibînim ku ew ne dest pê dike, lê an ew di çavkaniyan de cîh nagire, an jî wan sînorên pir piçûk destnîşan kirine. Bi kurtasî, serîlêdan ji ber çavkaniyan nikare dest pê bike. Ez dibêjim: "Ew ê ji ber çavkaniyan dest pê neke, hûn biryar didin ka hûn çiqas hewce ne û nirxek têr destnîşan dikin." Ew dibêje: "Çawa çavkaniyan?" Min dest bi ravekirina wî kir ku Kubernetes, sînorên li ser daxwazan û blah, blah, blah divê bêne danîn. Mêrik pênc deqeyan guhdarî kir, serê xwe hejand û got: "Ez hatim vir da ku wekî pêşdebir bixebitim, ez naxwazim li ser tu çavkaniyan tiştek bizanim. Ez hatim vir da ku kodê binivîsim û ew e. Ew xemgîn e. Ev ji nêrîna pêşdebirek têgehek pir xemgîn e. Bi taybetî di cîhana nûjen de, ku meriv bêje, devopên pêşverû.
Çima çavkanî bi tevahî hewce ne? Di Kubernetes de 2 celeb çavkaniyan hene. Ji hinekan re daxwaz, ji hinekan re jî sînor tê gotin. Ji hêla çavkaniyan ve em ê fêm bikin ku di bingeh de her gav tenê du qedexeyên bingehîn hene. Ango, tixûbên dema CPU û sînorên RAM-ê ji bo konteynirek ku li Kubernetes dimeşîne.
Sînor sînorek jorîn li ser ka çavkaniyek çawa dikare di serîlêdana we de were bikar anîn cîh dike. Ango, li gorî vê yekê, heke hûn di sînoran de bibêjin 1 GB RAM, wê hingê serlêdana we dê nikaribe ji 1 GB RAM-ê zêdetir bikar bîne. Û heke ew ji nişkê ve bixwaze û hewl bide ku wiya bike, wê hingê pêvajoyek ku jê re dibêjin oom killer, ji bîrê ye, ango, dê were û serlêdana we bikuje - ango, ew ê bi tenê ji nû ve dest pê bike. Serlêdan dê li ser bingeha CPU ji nû ve neyên destpêkirin. Di warê CPU-yê de, heke serîlêdanek hewl bide ku pir zêde bikar bîne, ji ya ku di nav sînoran de hatî destnîşan kirin, CPU dê bi hişkî were hilbijartin. Ev nabe sedema ji nû ve destpêkirinê. Ev sînor e - ev sînorê jorîn e.
Û daxwazek heye. Daxwazek ev e ku Kubernetes çawa fam dike ka girêkên di koma weya Kubernetes de çawa bi sepanan têne dagirtin. Ango, daxwazek celebek pabendbûna serlêdana we ye. Tiştê ku ez dixwazim bikar bînim dibêje: "Ez dixwazim ku hûn ji min re evqas CPU û evqas bîranîn veqetînin." Analojiyek wusa hêsan. Ger girêkek me hebe, ez nizanim, bi tevahî 8 CPU hene. Û podek digihîje wir, ku daxwazên wî dibêjin 1 CPU, ku tê vê wateyê ku nodê 7 CPU maye. Ango, li gorî vê yekê, gava ku 8 pod digihîjin vê girêk, ku her yek ji wan di daxwazên xwe de 1 CPU heye, girêk, mîna ku ji nêrîna Kubernetes be, ji CPU xilas bûye û bêtir podên bi daxwazan nikarin bibin. li ser vê nodê hatiye destpêkirin. Ger hemî girêk ji CPU-yê xilas bibin, wê hingê Kubernetes dê dest pê bike ku bêje ku di komê de girêkên minasib nînin ku podên we bimeşînin ji ber ku CPU qediyaye.
Çima daxwazî hewce ne û çima bê daxwaz, ez difikirim ku ne hewce ye ku tiştek li Kubernetes were destpêkirin? Ka em rewşek hîpotetîk bifikirin. Hûn serîlêdana xwe bêyî daxwazî destpê dikin, Kubernetes nizane ka çiqas ji we heye, hûn dikarin li kîjan nokan bişopînin. Welê, ew dişewitîne, dişewitîne, davêje ser girêkan. Di demekê de, hûn ê dest bi seyrûsefera serîlêdana xwe bikin. Û yek ji serîlêdanan ji nişka ve dest bi karanîna çavkaniyan heya sînorên ku li gorî sînoran heye dest pê dike. Derket holê ku li nêzîkê serîlêdanek din heye û jê re çavkaniyan jî hewce dike. Nod bi rastî dest pê dike ku bi fizîkî ji çavkaniyan diqede, mînakî, OP. Node bi rastî dest pê dike ku bi fizîkî çavkaniyan diqede, mînakî, bîranîna gihîştina rasthatî (RAM). Dema ku nodek ji hêza xwe diqede, berî her tiştî dê docker bersivê bide sekinandin, paşê kubelet, paşê OS. Ew ê bi tenê bêhiş bimînin û HER TIŞT bê guman dê ji bo we bixebite. Ango, ev ê bibe sedem ku girêka we asê bimîne û hûn hewce ne ku wê ji nû ve bidin destpêkirin. Bi kurtî, rewş ne pir baş e.
Û gava ku daxwazên we hebin, tixûb ne pir cûda ne, bi kêmanî ne pir caran ji sînor an daxwaziyan pirtir, wê hingê hûn dikarin di nav girêkên komên Kubernetes de serîlêdanên wusa normal, maqûl dagirtin. Di heman demê de, Kubernetes bi qasî ku haya wî jê heye ku ew çi qas li ku derê dixe, çi qas li ku derê tê bikar anîn. Ango ev demek wisa ye. Girîng e ku meriv wê fêm bike. Û girîng e ku meriv kontrol bike ku ev tê destnîşan kirin.
Depokirina daneyan
Xala meya din di derbarê hilanîna daneyan de ye. Bi wan re û bi gelemperî, bi berdewamiya Kubernetes re çi bikin?
Ez dîsa di nav me de difikirim , di Kubernetes de mijarek li ser databasê hebû. Û ji min re dixuye ku ez hema hema dizanim ku hevkarên we ji we re çi gotin dema ku jê pirsîn: "Gelo meriv dikare databasek li Kubernetes bimeşîne?" Ji ber hin sedeman, ji min re dixuye ku divê hevkarên we ji we re bigotana ku heke hûn pirsê dipirsin gelo gengaz e ku databasek li Kubernetes bimeşîne, wê hingê ew ne gengaz e.
Mantiq li vir hêsan e. Tenê di rewşê de, ez ê carek din rave bikim, ger hûn zilamek bi rastî xweş in ku dikare pergalek hilanîna torê ya belavkirî ya bi xeletî ava bike, fêm bikin ka meriv çawa databasek di vê dozê de bi cih dike, divê çawa ewrê xwecî di konteyneran de bixebite. bi gelemperî di databasek de. Bi îhtîmaleke mezin, tu pirsa we tune ku meriv wê çawa bimeşîne. Ger pirsek weya weha hebe, û hûn dixwazin pê ewle bin ku ew hemî di hilberînê de vedibe û heya mirinê rast radiweste û qet nekeve, wê hingê ev nabe. Bi vê nêzîkatiyê re garantî ye ku hûn xwe li lingê xwe biteqînin. Ji ber vê yekê, ne çêtir e.
Mînakî, daneyên ku serlêdana me dixwaze hilîne, hin wêneyên ku bikarhêner bar dikin, hin tiştên ku serlêdana me di dema xebata xwe de çêdike, di destpêkê de, çi bikin? Di Kubernetes de bi wan re çi bikin?
Bi gelemperî, bi îdeal, erê, bê guman, Kubernetes pir xweş hatî sêwirandin û bi gelemperî di destpêkê de ji bo serîlêdanên bêdewlet hate fikirîn. Ango ji bo wan sepanên ku qet agahdarî naparêzin. Ev îdeal e.
Lê, bê guman, vebijarka îdeal her gav nabe. Başe ku çi? Xala yekem û herî hêsan ev e ku meriv cûreyek S3-ê bigire, tenê ne yê ku ji malê hatî çêkirin, ku ew jî ne diyar e ka ew çawa dixebite, lê ji hin peydaker. Pêşkêşkerek baş, normal - û serîlêdana xwe hîn bike ku S3 bikar bîne. Ango, gava ku bikarhênerê we bixwaze pelek bar bike, bêje "li vir, ji kerema xwe, wê li S3 barkirin." Dema ku ew bixwaze wê werbigire, bêje: "Li vir girêdanek ji S3-ê vegere û ji vir bistînin." Ev îdeal e.
Ger ji nişkê ve ji ber hin sedeman ev vebijarka îdeal ne guncaw be, serîlêdanek we heye ku we nenivîsandiye, we pêşnexistiye, an ew celebek mîrateyek tirsnak e, ew nikare protokola S3 bikar bîne, lê divê bi pelrêça herêmî re bixebite. peldankên herêmî. Tiştek kêm-zêde hêsan bistînin, Kubernetes bicîh bikin. Ango, tavilê dorpêçkirina Ceph ji bo hin karên hindiktirîn, ji min re xuya dike, ramanek xirab e. Ji ber ku Ceph, bê guman, baş û moda ye. Lê heke hûn bi rastî fêm nakin ka hûn çi dikin, wê hingê gava ku we tiştek li Ceph danî, hûn dikarin pir bi hêsanî û bi hêsanî careke din wê ji wir dernexînin. Ji ber ku, wekî ku hûn dizanin, Ceph daneyan di koma xwe de di forma binary de, û ne di forma pelên hêsan de hilîne. Ji ber vê yekê, heke ji nişka ve koma Ceph hilweşe, wê hingê îhtîmalek bêkêmasî û mezin heye ku hûn çu carî daneyên xwe ji wir negirin.
Em ê qursek li ser Ceph hebe, hûn dikarin .
Ji ber vê yekê, çêtir e ku meriv tiştek hêsan wekî serverek NFS bike. Kubernetes dikare bi wan re bixebite, hûn dikarin pelrêçek li binê serverek NFS-ê saz bikin - serîlêdana we mîna pelrêçek herêmî ye. Di heman demê de, bi xwezayî, hûn hewce ne ku fêm bikin ku, dîsa, hûn hewce ne ku bi NFS-ya xwe re tiştek bikin, divê hûn fêm bikin ku carinan dibe ku ew negihîştî bibe û li ser pirsa ku hûn ê di vê rewşê de çi bikin bifikirin. Dibe ku divê ew li cîhek li ser makîneyek cûda were piştguh kirin.
Xala din a ku min pê re got ev e ku hûn çi bikin ger serlêdana we di dema xebatê de hin pelan çêbike. Mînakî, gava ku ew dest pê dike, ew hin pelek statîk çêdike, ku li ser hin agahdariya ku serîlêdan tenê di dema destpêkirinê de werdigire bingeh e. Çi demek e. Heke daneyên wusa pir tune, wê hingê hûn ne hewce ne ku hûn qet aciz bibin, tenê vê serîlêdanê ji bo xwe saz bikin û bixebitin. Pirsa tenê li vir ew e ku çi ye, binêre. Pir caran, her cûre pergalên mîras, mîna WordPress û hwd, nemaze bi cûrbecûr pêvekên jêhatî, pêşdebirên PHP-ê yên biaqil ên hatine guheztin, ew bi gelemperî dizanin ka meriv çawa wiya çêbike da ku ew ji xwe re celebek pelê çêbikin. Li gorî vê yekê, yek pelek çêdike, ya duyemîn pelek duyemîn çêdike. Ew cuda ne. Hevsengî di koma Kubernetes ya xerîdar de bi tenê bi şansê pêk tê. Li gorî vê yekê, derdikeve holê ku ew nizanin ka meriv çawa bi hev re kar bikin. Yek agahiyekê dide, yê din agahiyek din dide bikarhêner. Ev tiştek e ku divê hûn dûr bikin. Ango, di Kubernetes de, her tiştê ku hûn dest pê dikin garantî ye ku hûn dikarin di gelek mînakan de bixebitin. Ji ber ku Kubernetes tiştek tevger e. Li gorî vê, bêyî ku ji kesî bipirse, kengî bixwaze dikare her tiştî biguhezîne. Ji ber vê yekê, hûn hewce ne ku li ser vê yekê hesab bikin. Her tiştê ku di yek meselê de hatî destpêkirin zû an dereng dê têk biçe. Zêdetir rezervên we hene, ew çêtir e. Lê dîsa ez dibêjim, heke çend dosyayên we hebin, wê hingê hûn dikarin wan rast bixin bin xwe, giraniya wan hindik e. Ger piçek ji wan hebin, dibe ku hûn wan nexin hundurê konteynerê.
Ez ê şîret bikim ku di Kubernetes de tiştek wusa ecêb heye, hûn dikarin volume bikar bînin. Bi taybetî, cildeke cureyê dir vala heye. Ango, tenê ew e ku Kubernetes dê bixweber pelrêçek di pelrêçên karûbarê xwe de li ser servera ku we lê dest pê kiriye biafirîne. Û ew ê wê bide we, da ku hûn bikar bînin. Tenê xalek girîng heye. Ango, daneyên we dê ne di hundurê konteynerê de, lê li ser mêvandarê ku hûn lê dimeşînin werin hilanîn. Digel vê yekê, Kubernetes dikare di bin veavakirina normal de van dirzên vala kontrol bike û karibe mezinahiya wan ya herî zêde kontrol bike û nehêle ku ew zêde bibe. Tekane xal ev e ku tiştê ku we di dîrê vala de nivîsandiye di dema ji nû ve destpêkirina pod de winda nabe. Ango, heke poda we bi xeletî bikeve û dîsa rabe, agahdariya di dirê vala de dê neçe ti cihî. Ew dikare wê dîsa di destpêkek nû de bikar bîne - û ew baş e. Ger podê we ji cîhek derkeve, wê hingê bi xwezayî ew ê bêyî daneyê derkeve. Ango, gava ku pod ji girêka ku bi dirza vala hatî destpêkirin winda dibe, dirê vala tê jêbirin.
Din vala çi baş e? Mînakî, ew dikare wekî cache were bikar anîn. Werin em bifikirin ku serîlêdana me tiştek di firînê de çêdike, wê dide bikarhêneran û ji bo demek dirêj wiya dike. Ji ber vê yekê, serîlêdan, mînakî, diafirîne û dide bikarhêneran, û di heman demê de wê li cîhek hilîne, da ku gava din ku bikarhêner ji bo heman tiştî were, ew ê bileztir be ku ew tavilê were çêkirin. Diroka vala dikare ji Kubernetes were xwestin ku di bîranînê de biafirîne. Û bi vî awayî, kaşên we bi gelemperî dikarin bi leza birûskê bixebitin - di warê leza gihîştina dîskê de. Ango, di bîra we de direyek vala heye, di OS-ê de ew di bîranînê de tê hilanîn, lê ji bo we, ji bo bikarhênerê di hundurê pod de, ew tenê pelrêçek herêmî xuya dike. Hûn ne hewce ne ku sepanê bi taybetî fêrî sêrbaziyê bike. Hûn tenê rasterast pelê xwe digirin û têxin pelrêçek, lê, bi rastî, di bîranîna OS-ê de. Ev jî di warê Kubernetes de taybetmendiyek pir hêsan e.
Çi pirsgirêkên Minio heye? Pirsgirêka sereke ya Minio ev e ku ji bo ku ev tişt bixebite, pêdivî ye ku ew li cîhek were xebitandin, û pêdivî ye ku celebek pergala pelê, ango hilanînê hebe. Û li vir em bi heman pirsgirêkên Ceph re rû bi rû dimînin. Ango divê Minio pelên xwe li cîhek hilîne. Ew bi tenê navgînek HTTP ji pelên we re ye. Digel vê yekê, fonksiyon ji ya S3 ya Amazon eşkere xizantir e. Berê, nekarî bi rêkûpêk destûr bide bikarhêner. Naha, bi qasî ku ez dizanim, ew jixwe dikare bi destûrnameyên cihêreng kepçeyan biafirîne, lê dîsa, ji min re xuya dike ku pirsgirêka sereke, bi vî rengî, pergala hilanînê ya bingehîn bi kêmanî ye.
Di bîranînê de Empty dir çawa bandorê li ser sînoran dike? Bi ti awayî bandorê li ser sînoran nake. Ew di bîra mêvandar de ye, û ne di bîranîna konteynera we de ye. Ango konteynera we di bîrê de vala wekî beşek ji bîra xwe ya dagirkirî nabîne. Mêvandar vê dibîne. Li gorî vê, erê, ji hêla kubernetes ve, gava ku hûn dest bi karanîna vê yekê bikin, wê baş be ku hûn fêm bikin ku hûn beşek ji bîra xwe vediqetînin dîrê vala. Û li gorî vê yekê, fêm bikin ku bîranîn ne tenê ji ber serîlêdanan, lê di heman demê de ji ber ku kesek li van dirmên vala dinivîse jî dikare biqede.
Cloudnativeness
Û binê mijara dawîn ev e ku Cloudnative çi ye. Çima hewce ye? Cloudnativeness û hwd.
Ango ew sepanên ku jêhatî ne û têne nivîsandin da ku di binesaziyek ewr a nûjen de bixebitin. Lê, bi rastî, Cloudnative aliyekî din ê wusa heye. Ku ev ne tenê serîlêdanek e ku hemî hewcedariyên binesaziyek ewr a nûjen li ber çavan digire, lê di heman demê de dizane ku meriv çawa bi vê binesaziya ewr a nûjen re dixebite, ji awantaj û dezawantajên rastiya ku ew di van ewran de dixebite sûd werbigire. Tenê bi ser nekevin û di ewran de bixebitin, lê ji feydeyên xebata di ewr de sûd werbigirin.
Ka em tenê Kubernetes wekî mînakek bigirin. Serlêdana we di Kubernetes de dixebite. Serlêdana we her gav dikare, an bêtir rêvebirên serîlêdana we, her gav dikarin hesabek karûbarê biafirînin. Ango, hesabek ji bo destûrnameyê li Kubernetes bixwe di servera wê de. Hin mafên ku em hewce ne li wir zêde bikin. Û hûn dikarin ji hundurê serîlêdana xwe bigihîjin Kubernetes. Hûn dikarin bi vî awayî çi bikin? Mînakî, ji serîlêdanê, daneyên li ser cîhê ku serîlêdanên weyên din, mînakên din ên mîna hev lê ne, bistînin û heke hewcedariyek wusa hebe, bi rengekî li ser Kubernetes kom bibin.
Dîsa, di van demên dawî de dozek me hebû. Yek kontrolkerek me heye ku rêzê dişopîne. Û gava ku hin karên nû di vê dorê de xuya dibin, ew diçe Kubernetes - û di hundurê Kubernetes de ew podek nû diafirîne. Hin peywirek nû dide vê podê û di çarçoveya vê pod de, pod peywirê pêk tîne, bersivek ji kontrolkerê re bixwe re dişîne, û paşê kontrolker bi vê agahiyê re tiştek dike. Mînakî, ew databasek zêde dike. Ango, dîsa, ev plusek vê rastiyê ye ku serîlêdana me li Kubernetes dimeşe. Em dikarin fonksiyona Kubernetes-a çêkirî bixwe bikar bînin da ku bi rengekî berfereh bikin û fonksiyona serîlêdana xwe hêsantir bikin. Ango, di derheqê meriv çawa serîlêdanek çawa dest pê dike, meriv çawa xebatkarek dide destpêkirin de cûreyek sêrbaziyê venaşêre. Li Kubernetes, heke serîlêdan bi Python hatî nivîsandin, hûn tenê daxwazek di sepanê de bişînin.
Heman tişt derbas dibe ger em ji Kubernetes wêdetir biçin. Kubernetesên me li cîhek dimeşin - baş e ku ew di nav cûreyek ewr de be. Dîsa, em dikarin bikar bînin, û tewra divê, ez bawer dikim, kapasîteyên ewr bixwe jî li cihê ku em dimeşînin bikar bînin. Ji tiştên seretayî yên ku ewr dide me. Balanskirin, ango em dikarin balansên ewr biafirînin û wan bikar bînin. Ev avantajek rasterast ya ku em dikarin bikar bînin e. Ji ber ku hevsengiya ewr, yekem, bi tenê bi ehmeqî berpirsiyariyê ji me radike ka ew çawa dixebite, çawa tê mîheng kirin. Zêdeyî ew pir rehet e, ji ber ku Kubernetes bi rêkûpêk dikare bi ewran re yek bibe.
Heman tişt ji bo pîvandinê jî derbas dibe. Kubernetesên birêkûpêk dikarin bi pêşkêşkerên ewr re yek bibin. Dizane ka meriv çawa fêm dike ku ger kom ji nokan biqede, ango cîhê girêkê qediya, wê hingê hûn hewce ne ku lê zêde bikin - Kubernetes bixwe dê girêkên nû li koma we zêde bike û dest bi danasîna podan li ser wan bike. Ango dema ku barê we tê, hejmara ocax dest pê dike ku zêde bibe. Dema ku girêkên di komê de ji bo van podan diqedin, Kubernetes girêkên nû dide destpêkirin û, li gorî vê yekê, hêjmara podan hîn jî dikare zêde bibe. Û ew pir hêsan e. Ev fersendek rasterast e ku meriv komê li ser firînê mezin bike. Ne pir zû, bi wateya ku ew ne duyemîn e, ji bo lê zêdekirina girêkên nû bêtir mîna deqeyek e.
Lê ji ezmûna min, dîsa, ew tiştê herî xweş e ku min dîtiye. Dema ku koma Cloudnative li gorî dema rojê hate pîvandin. Ew karûbarek paşerojê bû ku ji hêla mirovên li nivîsgeha paşîn ve dihat bikar anîn. Ango, ew di demjimêr 9ê sibehê de têne ser kar, dest bi têketina pergalê dikin, û li gorî vê yekê, koma Cloudnative, ku ew hemî lê dimeşe, dest bi şînbûnê dike, pêlên nû vedike da ku her kesê ku tê ser kar dikare bi serîlêdanê re bixebite. Dema ku ew di 8ê êvarê an 6ê êvarê de ji kar derdikevin, komên Kubernetes ferq dikin ku êdî kes serîlêdanê bikar nayîne û dest bi piçûkbûnê dikin. Teserûfên heta ji sedî 30 garantî ne. Di wê demê de li Amazonê dixebitî, di wê demê de li Rûsyayê kesek tune bû ku ew qas baş bike.
Ez ê rasterast ji we re bibêjim, teserûf ji sedî 30 ne ji ber ku em Kubernetes bikar tînin û ji kapasîteyên ewr sûd werdigirin. Niha ev dikare li Rûsyayê were kirin. Ez ê ji kesî re reklamê nekim, bê guman, lê em tenê bibêjin ku pêşkêşker hene ku dikarin wiya bikin, bi bişkokek rast ji qutiyê peyda bikin.
Xaleke dawî heye ku ez jî bala we bikişînim ser. Ji bo ku serîlêdana we, binesaziya we Cloudnative be, maqûl e ku hûn di dawiyê de dest bi adaptekirina nêzîkatiya bi navê Binesaziyê wekî Kod bikin, ev tê vê wateyê ku serîlêdana we, an bêtir binesaziya we, bi heman rengî pêdivî ye kod Serîlêdana xwe, mantiqa karsaziya xwe di forma kodê de diyar bikin. Û bi wê re wekî kodê bixebitin, ango, wê biceribînin, bişoxilînin, wê di git de hilînin, CICD-ê jê re bicîh bikin.
Û ev tam ya ku destûrê dide we, yekem, hûn her gav li ser binesaziya xwe kontrol bikin, her gav fêm bikin ka ew di çi rewşê de ye. Ya duyemîn, ji operasyonên bi destan ên ku dibin sedema xeletiyan dûr bisekinin. Ya sêyemîn, gava ku hûn bi berdewamî hewce ne ku hûn heman peywirên destan bikin, bi tenê ji tiştê ku jê re tê gotin vegere dûr bixin. Ya çaremîn, ew dihêle hûn di bûyera têkçûnê de pir zûtir sax bibin. Li Rûsyayê, her gava ku ez li ser vê yekê diaxivim, her gav hejmareke mezin ji mirovan hene ku dibêjin: "Erê, diyar e, lê nêzîkatiyên we hene, bi kurtasî, ne hewce ye ku tiştek rast bikin." Lê rast e. Ger tiştek di binesaziya we de şikestibe, wê hingê ji nihêrîna nêzîkatiya Cloudnative û ji hêla Binesaziyê ve wekî Kodek, li şûna ku wê rast bikin, biçin serverê, fêm bikin ka çi şikestiye û wê rast bikin, ew hêsantir e. ji bo serverê jêbirin û dîsa biafirîne. Û ez ê van hemûyan sererast bikim.
Hemî van mijaran bi berfirehî li vir têne nîqaş kirin . Bi şopandina lînkê hûn dikarin xwe bi bername û şert û mercan nas bikin. Ya hêsan ev e ku hûn dikarin Kubernetes bi xwendina ji malê an jî rojê 1-2 demjimêran bixebitin.
Source: www.habr.com