Esasê çîroka li ser rêveberê pakêtê yê herî populer ji bo Kubernetes dikare bi karanîna emoji were xuyang kirin:
- qutik Helm e (ku tiştê herî nêzîk ji serbestberdana Emoji ya herî dawî re ye);
- lock - ewlekarî;
- mirovê biçûk çareseriya pirsgirêkê ye.
Bi rastî, dê her tişt hinekî tevlihevtir be, û çîrok bi hûrguliyên teknîkî tije ye Meriv çawa Helm ewledar dike.
- Bi kurtasî Helm çi ye heke we nizanibû an ji bîr kir. Çi pirsgirêkan çareser dike û li ku derê ekosîstemê ye.
- Ka em li mîmariya Helmê binêrin. Tu danûstendinek di derbarê ewlehiyê de û meriv çawa amûrek an çareseriyek ewledartir dike bêyî têgihîştina mîmariya pêkhateyê temam nabe.
- Ka em li ser pêkhateyên Helm nîqaş bikin.
- Pirsa herî şewitî pêşeroj e - guhertoya nû ya Helm 3.
Her tişt di vê gotarê de ji Helm 2 re derbas dibe. Ev guherto niha di hilberînê de ye û bi îhtîmaleke mezin ya ku hûn niha bikar tînin e, û ew guhertoya ku xetereyên ewlehiyê dihewîne ye.
Li ser axaftvan: Alexander Khayorov () 10 sal in pêşve diçe, ji bo baştirkirina naverokê dibe alîkar û tevlî komîteyê bû . Naha ew li Chainstack-ê wekî pêşengek pêşkeftinê dixebite - ev hîbrîdek e di navbera rêveberek pêşkeftinê û kesek ku berpirsiyarê radestkirina weşanên paşîn de ye. Ango, li qada şer e, ku ji afirandina berhemekê heya xebata wê her tişt diqewime.
Chainstack destpêkek piçûk, bi aktîf mezin dibe, mîsyona wê ev e ku xerîdar bihêle ku binesaz û tevliheviyên xebitandina serîlêdanên nenavendî ji bîr bikin; tîmê pêşkeftinê li Sîngapurê ye. Ji Chainstack nepirsin ku pereyê krîptoyê bifroşe an bikire, lê pêşniyar bikin ku li ser çarçoveyên bloka pargîdaniyê biaxivin, û ew ê bi kêfxweşî bersiva we bidin.
Bêr
Ev ji bo Kubernetes rêveberek pakêtê (chart) ye. Awayê herî xwerû û gerdûnî ye ku meriv serîlêdanan bîne komek Kubernetes.
Em, bê guman, li ser nêzîkatiyek avahî û pîşesazîtir ji çêkirina diyardeyên YAML-a xwe û nivîsandina karûbarên piçûktir diaxivin.
Helm çêtirîn e ku niha heye û populer e.
Çima Helm? Di serî de ji ber ku ew ji hêla CNCF ve tê piştgirî kirin. Cloud Native rêxistinek mezin e û pargîdaniya dêûbav e ji bo projeyên Kubernetes, etcd, Fluentd û yên din.
Rastiyek din a girîng ev e ku Helm projeyek pir populer e. Gava ku min dest bi axaftinê kir ka meriv çawa Helm di Çileyê 2019-an de ewledar dike, proje hezar stêrk li ser GitHub bû. Heta meha Gulanê 12 hezar kes bûn.
Pir kes bi Helm re eleqedar dibin, ji ber vê yekê heke hûn hîna wê bikar neynin jî, hûn ê ji agahdariya ewlehiya wê sûd werbigirin. Ewlehî girîng e.
Tîma bingehîn a Helm ji hêla Microsoft Azure ve tê piştgirî kirin û ji ber vê yekê projeyek berbiçav e, berevajî gelekên din. Serbestberdana Helm 3 Alpha 2 di nîvê Tîrmehê de destnîşan dike ku gelek kes li ser projeyê dixebitin, û wan xwestek û enerjî heye ku Helm pêşve bixin û baştir bikin.
Helm gelek pirsgirêkên bingehîn ên rêveberiya serîlêdanê li Kubernetes çareser dike.
- Pakêkirina sepanê. Tewra serîlêdanek mîna "Silav, Cîhan" li ser WordPress jixwe ji gelek karûbaran pêk tê, û hûn dixwazin wan bi hev re pak bikin.
- Birêvebirina tevliheviya ku bi rêvebirina van sepanan re tê.
- Çêleka jiyanê ya ku piştî ku serîlêdan hate saz kirin an bi cih kirin bi dawî nabe. Jiyana xwe didomîne, pêdivî ye ku were nûve kirin, û Helm bi vê yekê re dibe alîkar û hewl dide ji bo vê yekê tedbîr û polîtîkayên rast bîne.
Bagging ew bi rengek zelal hatî organîze kirin: Metadata bi tevahî li gorî xebata rêveberek pakêtê ya birêkûpêk ji bo Linux, Windows an MacOS heye. Ango depoyek, girêdayîbûna bi pakêtên cihêreng, meta-agahiyên ji bo sepanan, mîhengan, taybetmendiyên veavakirinê, îndekskirina agahdarî û hwd. Helm dihêle hûn van hemîyan ji bo sepanan bistînin û bikar bînin.
Rêvebiriya Tevliheviyê. Heke gelek serîlêdanên we yên heman celeb hene, wê hingê pêdivî ye ku parametrekirin. Şablon ji vê yekê têne, lê ji bo ku hûn nekarin riya xwe ya afirandina şablonan peyda bikin, hûn dikarin tiştê ku Helm ji qutiyê pêşkêşî dike bikar bînin.
Application Lifecycle Management - Bi dîtina min, ev pirsa herî balkêş û bêçareser e. Ji ber vê yekê ez di rojê de hatim Helmê. Pêwîst bû ku me çavê xwe li çerxa jiyanê ya serîlêdanê bigirta û xwest em çerxên CI/CD û serîlêdana xwe berbi vê paradîgmayê ve bibin.
Helm destûrê dide te ku:
- rêvebirina bicihkirinê, têgeha veavakirin û verastkirinê destnîşan dike;
- bi serfirazî vegerandin;
- ji bo bûyerên cûda çengelan bikar bînin;
- kontrolên serîlêdanê yên din zêde bikin û bersivê bidin encamên wan.
Her wiha Helm xwedan "batterî" ye - hejmareke mezin ji tiştên tamxweş ên ku dikarin di forma pêvekan de werin nav kirin, jiyana we hêsan dikin. Plugin dikarin serbixwe bêne nivîsandin, ew bi tevahî veqetandî ne û hewceyê mîmariyek ahengdar nakin. Heke hûn dixwazin tiştek bicîh bikin, ez pêşniyar dikim ku wê wekî pêvekek bikin, û dûv re jî dibe ku wê di jorîn de têxin nav xwe.
Helm li ser sê têgehên sereke ye:
- Chart Repo - Danasîn û rêza parametreyên ku ji bo manîfestoya we mimkun e.
- config - ango, nirxên ku dê werin sepandin (nivîs, nirxên hejmarî, hwd.).
- Berdan du hêmanên jorîn berhev dike, û bi hev re vediguhere Release. Bersiv dikarin werin guhertokirin, bi vî rengî çerxa jiyanek rêxistinkirî bi dest bixin: di dema sazkirinê de piçûk û di dema nûvekirin, dakêşandin an paşvexistinê de mezin.
mîmarî Helm
Diagram bi têgînî mîmariya asta bilind a Helm nîşan dide.
Bila ez ji we re bi bîr bînim ku Helm tiştek bi Kubernetes ve girêdayî ye. Ji ber vê yekê, em nikarin bêyî komek Kubernetes (çargoşe) bikin. Parçeya kube-apiserver li ser masterê dimîne. Bê Helm me Kubeconfig heye. Helm yek binaryek piçûk tîne, heke hûn dikarin jê re bibêjin, amûra Helm CLI, ku li ser komputer, laptop, sereke - li ser her tiştî tête saz kirin.
Lê ev têrê nake. Helm pêkhateyek serverê ya bi navê Tiller heye. Ew berjewendîyên Helm di nav komê de temsîl dike; ew serîlêdanek di nav koma Kubernetes de ye, mîna her yekê.
Beşa din a Chart Repo depoyek bi nexşeyan e. Depoyek fermî heye, û dibe ku depoyek taybet a pargîdaniyek an projeyek hebe.
Têkilî
Werin em binihêrin ka hêmanên mîmarî çawa bi hev re tevdigerin dema ku em dixwazin serîlêdanek bi karanîna Helm saz bikin.
- Em dibêjin
Helm install, xwe bigihînin depoyê (Chart Repo) û nexşeyek Helm bistînin.
- Karsaziya Helm (Helm CLI) bi Kubeconfig re têkilî dike da ku fêr bibe ku bi kîjan komê re têkilî daynin.
- Piştî wergirtina vê agahiyê, karûbar Tiller, ku di koma me de ye, wekî serîlêdanê binav dike.
- Tiller gazî Kube-apiserver dike ku di Kubernetes de çalakiyan pêk bîne, hin tiştan (xizmet, pods, replicas, razdar, hwd.) biafirîne.
Dûv re, em ê diagramê tevlihev bikin da ku vektora êrîşê ya ku tevahiya mîmariya Helm bi tevahî dikare jê re were xuyang kirin bibînin. Û paşê em ê hewl bidin ku wê biparêzin.
Vektora êrîşê
Yekemîn xala qels a potansiyel e API îmtiyaz-bikarhêner. Wekî beşek ji pilanê, ev hackerek e ku gihîştina rêveberiyê ya Helm CLI bi dest xistiye.
Bikarhênerê API-yê bêdestûr di heman demê de heke li cîhek nêzîk be jî dikare bibe xetereyek. Bikarhênerek wusa dê xwedan çarçoveyek cûda be, mînakî, ew dikare di nav cîhek navekî komê de di mîhengên Kubeconfig de were rast kirin.
Vektora êrîşê ya herî balkêş dibe ku pêvajoyek be ku di nav komekê de li deverek nêzî Tiller dimîne û dikare bigihîje wê. Ev dikare bibe serverek malperê an mîkroxizmetek ku hawîrdora torê ya komê dibîne.
Guhertoyek êrîşê ya biyanî, lê her ku diçe populer dibe Chart Repo. Nexşeya ku ji hêla nivîskarek nepak ve hatî çêkirin dibe ku çavkaniyên ne ewledar hebe, û hûn ê bi girtina wê li ser baweriyê temam bikin. An jî ew dikare nexşeya ku hûn ji depoya fermî dakêşin biguhezîne û, mînakî, çavkaniyek di forma polîtîkayan de biafirîne û gihîştina wê zêde bike.
Ka em hewl bidin ku ji van her çar aliyan ve êrişan dûr bixin û fêm bikin ka di mîmariya Helmê de li ku derê pirsgirêk hene, û dibe ku li ku derê tune ne.
Werin em diagramê mezin bikin, hêmanan zêde bikin, lê hemî hêmanên bingehîn biparêzin.
Helm CLI bi Chart Repo re têkilî daynin, bi Kubeconfig re têkilî daynin, û kar di komê de ji pêkhateya Tiller re tê veguheztin.
Tiller bi du tiştan tê temsîl kirin:
- Tiller-deploy svc, ku karûbarek diyar dike;
- Tiller-deploy pod (di diagramê de di kopiyek yekane de di yek kopiyek de), ku li ser wê tevahiya barkirinê dimeşîne, ku digihîje komê.
Protokol û nexşeyên cûda ji bo danûstendinê têne bikar anîn. Ji hêla ewlehiyê ve, em herî zêde meraq dikin:
- Mekanîzmaya ku Helm CLI xwe digihîne repoya nexşeyê: çi protokol, erêkirin heye û bi wê re çi dikare were kirin.
- Protokola ku Helm CLI, kubectl bikar tîne, bi Tiller re têkilî dike. Ev serverek RPC ye ku di hundurê komê de hatî saz kirin.
- Tiller bixwe xwe bigihîne mîkroxizmetên ku di komê de dimînin û bi Kube-apiserver re têkildar e.
Werin em van hemû qadan bi rêz nîqaş bikin.
RBAC
Ti xala axaftinê li ser ewlehiya Helm an karûbarek din a di nav komê de tune ye heya ku RBAC neyê çalak kirin.
Wusa dixuye ku ev ne pêşniyara herî dawî ye, lê ez pê bawer im ku gelek kesan hîna jî di hilberînê de RBAC çalak nekiriye, ji ber ku ew pir şepirze ye û gelek tişt hewce ne ku bêne mîheng kirin. Lêbelê, ez we teşwîq dikim ku hûn vê yekê bikin.
- parêzerê malperê ji bo RBAC. Ew gelek materyalên balkêş dihewîne ku dê ji we re bibe alîkar ku hûn RBAC saz bikin, nîşan bidin ka çima ew baş e û meriv çawa bi bingehîn di hilberînê de bi wê re bijî.
Ez ê hewl bidim ku rave bikim ka Tiller û RBAC çawa dixebitin. Tiller di hundurê komê de di bin hesabek karûbarek diyarkirî de dixebite. Bi gelemperî, heke RBAC neyê mîheng kirin, ev ê bibe superbikarhêner. Di veavakirina bingehîn de, Tiller dê rêveberek be. Ji ber vê yekê pir caran tê gotin ku Tiller ji koma we re tunelek SSH ye. Bi rastî, ev rast e, ji ber vê yekê hûn dikarin li şûna Hesabê Karûbarê Pêşniyarê ya di diagrama jorîn de hesabek karûbarê veqetandî bikar bînin.
Gava ku hûn Helm-ê dest pê bikin û yekem car li ser serverê saz bikin, hûn dikarin hesabê karûbarê bikar bînin --service-account. Ev ê bihêle ku hûn bikarhênerek xwedan mafên herî kêm hewce bikar bînin. Rast e, hûn neçar in ku "garland"ek wusa biafirînin: Role û RoleBinding.
Mixabin, Helm dê vê yekê ji we re neke. Hûn an rêveberê koma Kubernetes-ê hewce ne ku ji bo ku hûn Helm derbas bikin komek Rol û RoleBindings ji bo hesabê karûbarê pêşwext amade bikin.
Pirs derdikeve holê - ferqa Role û ClusterRole çi ye? Cûdahî ev e ku ClusterRole ji bo hemî cîhên navan dixebite, berevajî Rolên birêkûpêk û RoleBindings, ku tenê ji bo cîhek navek pispor dixebitin. Hûn dikarin polîtîkayên ji bo tevahiya komê û hemî navan mîheng bikin, an jî ji bo her navekî bi rengek kesane kesane bikin.
Hêjayî gotinê ye ku RBAC pirsgirêkek din a mezin çareser dike. Gelek kes gazinan dikin ku Helm, mixabin, ne pirzimanî ye (piştgiriya pirzimanî nake). Ger çend tîm komek bixwin û Helm bikar bînin, di bingeh de ne gengaz e ku meriv polîtîkayan saz bike û gihîştina wan di hundurê vê komê de sînordar bike, ji ber ku hesabek karûbarek heye ku di binê wê de Helm dimeşe, û ew hemî çavkaniyên di komê de ji binê wê diafirîne. , ku carinan pir nerehet e. Ev rast e - mîna pelê binary bixwe, mîna pêvajoyê, Helm Tiller xwedan têgîna pirzimanî nîne.
Lêbelê, rêgezek hêja heye ku dihêle hûn Tiller-ê gelek caran di komekê de bimeşînin. Di vê yekê de pirsgirêk tune, Tiller dikare di her navekî de were destpêkirin. Bi vî rengî, hûn dikarin RBAC, Kubeconfig wekî çarçoveyek bikar bînin, û gihîştina Helmek taybetî sînordar bikin.
Wê wisa xuya bike.
Mînakî, du Kubeconfigên bi çarçoweya tîmên cihêreng hene (du cîhên navan): Tîma X ji bo tîmê pêşkeftinê û koma rêveberiyê. Koma rêveberê xwedan Tiller-a xweya fireh e, ku di nav qada nav-pergala Kube-yê de ye, hesabek karûbarê pêşkeftî ya têkildar. Û navek cihêreng ji bo tîmê pêşkeftinê, ew ê karibin karûbarên xwe li cîhek navek taybetî bicîh bikin.
Ev nêzîkatiyek bikêr e, Tiller ne ew qas birçî hêz e ku ew ê pir bandorê li ser budceya we bike. Ev yek ji çareseriyên bilez e.
Bi dilxwazî hûn Tiller-ê veqetandî mîheng bikin û Kubeconfig ji bo tîmê, ji bo pêşdebirek taybetî an jî ji bo hawîrdorê çarçoveyek peyda bikin: Dev, Staging, Hilberîn (guman e ku her tişt dê li ser heman komê be, lêbelê, ev dikare were kirin).
Berdewamkirina çîroka me, em ji RBAC veguherînin û li ser ConfigMaps biaxivin.
ConfigMaps
Helm wekî dikana daneya xwe ConfigMaps bikar tîne. Dema ku me qala mîmarî kir, li tu deverek databasek tune bû ku agahdariya der barê serbestberdan, veavakirin, vegerandin û hwd de hilîne. Ji bo vê yekê ConfigMaps tê bikar anîn.
Pirsgirêka sereke ya ConfigMaps tê zanîn - ew di prensîbê de ne ewle ne; ne mimkun e ku daneyên hesas hilîne. Em li ser her tiştî dipeyivin ku divê ji karûbarê wêdetir neçin, mînakî şîfre. Awayê herî xwemalî ji bo Helm naha ev e ku meriv ji karanîna ConfigMaps-ê berbi razan veguhezîne.
Ev pir bi hêsanî tê kirin. Mîhenga Tiller bişopînin û diyar bikin ku hilanîn dê nehênî bin. Dûv re ji bo her bicîhkirinê hûn ê ne ConfigMap, lê siriyek bistînin.
Hûn dikarin arguman bikin ku sir bixwe têgehek xerîb in û ne pir ewledar in. Lêbelê, hêjayî têgihiştinê ye ku pêşdebirên Kubernetes bixwe vê yekê dikin. Ji guhertoya 1.10 dest pê dike, yanî. Ev demek dirêj e, bi kêmanî di ewrên gelemperî de, gengaz e ku meriv hilanîna rast ji bo hilanîna razan ve girêbide. Tîm naha li ser awayên çêtir belavkirina gihîştina razan, potên kesane, an saziyên din dixebite.
Çêtir e ku Storage Helm veguhezînin razan, û ew, di encamê de, navendî têne ewle kirin.
Helbet wê bimîne sînorê hilanînê daneyan 1 MB. Helm li vir etcd wekî hilanînê belavkirî ji bo ConfigMaps bikar tîne. Û li wir wan fikirîn ku ev perçeyek daneya guncan e ji bo dubarekirinê, hwd. Li ser vê yekê li ser Reddit nîqaşek balkêş heye, ez pêşniyar dikim ku ji bo dawiya hefteyê vê xwendina xweş bibînin an jî jêgirtinê bixwînin. .
Chart Repos
Charts ji hêla civakî ve herî xeternak in û dikarin bibin çavkaniyek "Mêr di navîn", nemaze heke hûn çareseriyek stok bikar bînin. Berî her tiştî, em li ser depoyên ku bi HTTP-ê têne eşkere kirin diaxivin.
Hûn bê guman hewce ne ku Helm Repo li ser HTTPS eşkere bikin - ev vebijarka çêtirîn e û erzan e.
Tê payîn mekanîzmaya îmzeya chart. Teknolojî wekî dojehê hêsan e. Ev heman tiştê ku hûn li ser GitHub, makîneyek PGP-ya birêkûpêk bi bişkojkên gelemperî û taybet bikar tînin, bikar tînin. Saz bikin û pê ewle bin, ku mifteyên pêwîst hebin û her tiştî îmze bikin, ku ev bi rastî nexşeya we ye.
Herweha, Muwekîlê Helm TLS piştgirî dike (ne di wateya HTTP-ya server-ê de, lê TLS-ya hevbeş). Ji bo danûstandinê hûn dikarin bişkojkên server û xerîdar bikar bînin. Bi rastî, ez mekanîzmayek wusa bikar naynim ji ber ku ez ji sertîfîkayên hevdu hez nakim. Bingehî, - Amûra sereke ji bo sazkirina Helm Repo ji bo Helm 2 - di heman demê de destûrnameya bingehîn jî piştgirî dike. Heke ew hêsantir û bêdengtir e, hûn dikarin otorîteya bingehîn bikar bînin.
Pêvekek jî heye , ku destûrê dide te ku hûn li ser Google Cloud Storage mêvandariya Chart Repos bikin. Ev pir hêsan e, pir baş dixebite û pir ewledar e, ji ber ku hemî mekanîzmayên diyarkirî têne veguheztin.
Ger hûn HTTPS an TLS çalak bikin, mTLS bikar bînin, û auth bingehîn çalak bikin da ku xetereyan bêtir kêm bikin, hûn ê bi Helm CLI û Chart Repo re kanalek pêwendiyek ewledar bistînin.
gRPC API
Pêngava paşîn pir girîng e - ewlekirina Tiller, ku di nav komê de ye û, ji aliyekî ve serverek e, ji hêla din ve, ew bixwe digihîje pêkhateyên din û hewl dide ku xwe wekî kesek nîşan bide.
Wekî ku min berê jî got, Tiller karûbarek e ku gRPC eşkere dike, xerîdar Helm bi gRPC ve tê. Bi xwerû, bê guman, TLS neçalak e. Çima ev hate kirin pirsek nîqaş e, ji min re xuya dike ku di destpêkê de sazkirinê hêsan bikim.
Ji bo hilberandin û tewra qonax, ez pêşniyar dikim ku TLS li ser gRPC çalak bikin.
Bi dîtina min, berevajî mTLS ji bo nexşeyan, ev li vir guncan e û pir bi hêsanî tête kirin - binesaziyek PQI çêbikin, sertîfîkayek biafirînin, Tiller bidin destpêkirin, sertîfîkayê di dema destpêkirinê de veguhezînin. Piştî vê yekê, hûn dikarin hemî fermanên Helm bicîh bînin, xwe bi sertîfîkaya çêkirî û mifteya taybet re pêşkêş bikin.
Bi vî rengî hûn ê xwe ji hemî daxwazên Tiller yên ji derveyî komê biparêzin.
Ji ber vê yekê, me kanala girêdanê bi Tiller re ewle kiriye, me berê li ser RBAC nîqaş kiriye û mafên apiservera Kubernetes sererast kiriye, domaina ku ew dikare pê re têkilî daynin kêm bike.
Helm parastin
Ka em li diyagrama dawîn binêrin. Bi heman tîran re heman mîmarî ye.
Naha hemî girêdan dikarin bi rengek kesk bi ewlehî werin kişandin:
- ji bo Chart Repo em TLS an mTLS û nasnameya bingehîn bikar tînin;
- mTLS ji bo Tiller, û ew wekî karûbarek gRPC bi TLS re tê xuyang kirin, em sertîfîkayan bikar tînin;
- komê bi Role û RoleBinding re hesabek karûbarê taybetî bikar tîne.
Me kom bi girîngî ewle kiriye, lê yekî jîr got:
"Tenê çareseriyek bê guman ewledar dikare hebe - komputerek vegirtî, ku di qutiyek betonê de ye û ji hêla leşkeran ve tê parastin."
Ji bo manîpulekirina daneyan û dîtina vektorên êrîşê yên nû awayên cûda hene. Lêbelê, ez pê bawer im ku ev pêşniyar dê ji bo ewlehiyê standardek pîşesaziyê ya bingehîn bi dest bixin.
Xelat
Ev beş ne rasterast bi ewlehiyê ve girêdayî ye, lê di heman demê de dê kêrhatî be. Ez ê hin tiştên balkêş nîşanî we bidim ku hindik kes pê dizanin. Mînakî, meriv çawa li nexşeyan digere - fermî û nefermî.
Di depoyê de Naha nêzîkê 300 nexşe û du çem hene: stabîl û inkubator. Her kesê ku tevkariyê dike baş dizane ku çûna ji înkubatorê berbi îstiqrarê çiqas dijwar e, û bifire ji îstiqrarê çiqas hêsan e. Lêbelê, ev ne amûra çêtirîn e ku meriv li nexşeyan ji bo Prometheus û her tiştê ku hûn jê hez dikin bigerin, ji ber sedemek hêsan - ew ne portalek e ku hûn bi hêsanî li pakêtan bigerin.
Lê xizmetek heye , ku dîtina nexşeyan pir hêsantir dike. Ya herî girîng, gelek depoyên derveyî yên din û hema hema 800 xemlên berdest hene. Zêdetir, heke ji ber hin sedeman hûn nexwazin nexşeyên xwe bişînin stabîl, hûn dikarin depoya xwe girêdin.
Hub.helm.sh biceribînin û werin em bi hev re wê pêşve bibin. Ev karûbar di binê projeya Helm de ye, û heke hûn pêşdebirek pêşîn in û tenê dixwazin xuyangê çêtir bikin hûn dikarin beşdarî UI-ya wê jî bibin.
Ez jî bala we bikişînim ser Yekbûna API-ya Broker ya Karûbarê vekin. Ew tevlihev û nezelal xuya dike, lê ew pirsgirêkên ku her kes pê re rû bi rû dimîne çareser dike. Bila ez bi mînakek hêsan vebêjim.
Komek Kubernetes heye ku tê de em dixwazin serîlêdanek klasîk bimeşînin - WordPress. Bi gelemperî, databasek ji bo fonksiyona tevahî hewce ye. Gelek çareseriyên cihêreng hene, mînakî, hûn dikarin karûbarê xweya dewletparêz dest pê bikin. Ev ne pir hêsan e, lê gelek kes wê dikin.
Yên din, mîna me li Chainstack, ji bo serverên xwe databasên birêvebir ên mîna MySQL an PostgreSQL bikar tînin. Ji ber vê yekê databasên me li cîhek ewr in.
Lê pirsgirêkek derdikeve: pêdivî ye ku em karûbarê xwe bi databasekê ve girêbidin, tama databasê biafirînin, pêbaweriyê veguhezînin û bi rengekî wê îdare bikin. Hemî ev bi gelemperî ji hêla rêveberê pergalê an pêşdebir ve bi destan têne kirin. Û gava ku çend serîlêdan hene pirsgirêk tune. Gava ku gelek ji wan hebin, hûn hewceyê berhevokê ne. Dirûnek wusa heye - ew Brokera Karûbar e. Ew dihêle hûn ji bo komikek ewrek gelemperî pêvekek taybetî bikar bînin û çavkaniyan ji pêşkêşkerê bi navgîniya Broker ferman bikin, mîna ku ew API be. Ji bo vê yekê, hûn dikarin amûrên xwemalî yên Kubernetes bikar bînin.
Pir hêsan e. Mînakî, hûn dikarin MySQL-ya Birêvebir a li Azure bi rêzek bingehîn bipirsin (ev dikare were mîheng kirin). Bi karanîna Azure API-ê, databas dê ji bo karanîna were afirandin û amade kirin. Hûn ne hewce ne ku hûn destwerdana vê yekê bikin, pêvek ji vê yekê berpirsiyar e. Mînakî, OSBA (pêveka Azure) dê pêbaweriyê vegerîne karûbarê û wê ji Helm re derbas bike. Hûn ê bikaribin WordPress-ê bi cloud MySQL-ê re bikar bînin, qet bi databasên birêvebir re mijûl nebin û ji karûbarên dewletparêz ên hundur xem nekin.
Em dikarin bibêjin ku Helm wekî zencîreyek tevdigere ku, ji aliyekî ve, dihêle hûn karûbaran bicîh bikin, û ji hêla din ve, çavkaniyên pêşkêşkerên ewr bikar bînin.
Hûn dikarin pêveka xweya xwe binivîsin û vê çîrokê li ser bingehê bikar bînin. Dûv re hûn ê tenê pêveka xwe ya ji bo peydakiroxa Cloud-ê ya pargîdanî hebe. Ez pêşniyar dikim ku vê nêzîkatiyê biceribînin, nemaze heke we pîvanek mezin hebe û hûn dixwazin zû dev, stasyon, an tevahiya binesaziyê ji bo taybetmendiyekê bicîh bikin. Ev ê jiyanê ji bo operasyonên we an DevOps hêsantir bike.
Vedîtinek din a ku min berê behs kir ev e pêveka helm-gcs, ku destûrê dide te ku hûn Google-buckets (depokirina tiştan) bikar bînin da ku nexşeyên Helm hilînin.
Hûn tenê çar fermanan hewce ne ku hûn dest bi karanîna wê bikin:
- pêvekê saz bike;
- destpêkirina wê;
- rê li ber kekê, ku di gcp-ê de ye, saz bike;
- nexşeyan bi awayê standard biweşînin.
Bedew ev e ku rêbaza gcp ya xwecihî dê ji bo destûrnameyê were bikar anîn. Hûn dikarin hesabek karûbarê, hesabek pêşdebir, her tiştê ku hûn dixwazin bikar bînin. Ew pir hêsan e û ji bo xebitandinê tiştek nade. Ger hûn, mîna min, felsefeya opsless pêşve bibin, wê hingê ev ê pir rehet be, nemaze ji bo tîmên piçûk.
Alternatîfên
Helm ne tenê çareseriya rêveberiya karûbarê ye. Di derbarê wê de gelek pirs hene, dibe ku ji ber vê yekê guhertoya sêyemîn ewqas zû xuya bû. Helbet alternatîf hene.
Ev dikarin çareseriyên pispor bin, wek nimûne, Ksonnet an Metaparticle. Hûn dikarin amûrên rêveberiya binesaziya xweya klasîk (Ansible, Terraform, Chef, hwd.) ji bo heman mebestên ku min behs kirin bikar bînin.
Di dawiyê de çareseriyek heye , ku populerbûna wê zêde dibe.
Çarçoveya Operator alternatîfa Helm ya herî bilind e ku meriv li ber çavan digire.
Ew ji CNCF û Kubernetes bêtir xwecî ye, lê astengiya têketinê gelek zêdetir e, pêdivî ye ku hûn bêtir bername bikin û kêm diyardeyan diyar bikin.
Pêvekên cihêreng hene, wek Draft, Scaffold. Ew jiyanê pir hêsantir dikin, mînakî, ew çerxa şandin û destpêkirina Helm ji bo pêşdebiran hêsan dikin da ku hawîrdorek ceribandinê bicîh bikin. Ez ê ji wan re bibêjim hêzdar.
Li vir nexşeyek dîtbar heye ku her tişt li ku ye.
Li ser eksê x asta kontrola weya kesane ya li ser tiştê ku diqewime ye, li ser y-ax asta xwemaliya Kubernetes heye. Guhertoya Helm 2 li cîhek navîn dikeve. Di guhertoya 3-ê de, ne pir zêde, lê hem kontrol û hem jî asta xwemaliyê çêtir bûye. Çareseriyên di asta Ksonnet de hîn jî ji Helm 2 kêmtir in. Lêbelê, ew hêja ne ku li wan binêrin da ku hûn bizanin ka li vê dinyayê çi ye. Bê guman, rêveberê veavakirina we dê di bin kontrola we de be, lê ew bê guman ne xwecî Kubernetes e.
Çarçoveya Operatorê bêkêmasî ji Kubernetes re xwemalî ye û dihêle hûn wê pir xweşiktir û bi hûrgulî îdare bikin (lê di asta têketinê de bîr bînin). Di şûna wê de, ev ji bo serîlêdanek pispor û afirandina rêveberiyê ji bo wê maqûl e, ne ji berhevkarek girseyî ji bo pakkirina hejmareke mezin a serîlêdanan bi karanîna Helm.
Berfireh bi hêsanî kontrolê piçek çêtir dikin, xebata xebatê temam dikin, an quncikên li ser boriyên CI/CD qut dikin.
Pêşeroja Helm
Mizgîn ev e ku Helm 3 tê. Guhertoya alpha ya Helm 3.0.0-alpha.2 jixwe derketiye, hûn dikarin biceribînin. Ew pir bi îstîqrar e, lê fonksiyon hîn jî sînorkirî ye.
Çima hûn Helm 3 hewce ne? Berî her tiştî, ev çîrokek e windabûna Tiller, wekî pêkhateyek. Ev, wekî ku hûn jixwe fêm dikin, gavek mezin e, ji ber ku ji hêla ewlehiya mîmariyê ve, her tişt hêsan e.
Dema ku Helm 2 hate afirandin, ku di dema Kubernetes 1.8 an jî berê de bû, gelek têgeh negihîştî bûn. Mînakî, konsepta CRD naha bi rengekî çalak tê sepandin, û Helm dê CRD bikar bîninji bo hilanîna strukturên. Dê gengaz be ku meriv tenê xerîdar bikar bîne û beşa serverê neparêze. Li gorî vê yekê, emrên xwecî Kubernetes bikar bînin da ku bi avahî û çavkaniyan re bixebitin. Ev gaveke mezin e.
Dê xuya bibe piştgirî ji bo depoyên OCI yên xwecihî (Însiyatîfa Konteynirê Vekirî). Ev destpêşxeriyek mezin e, û Helm di serî de ji bo şandina nexşeyên xwe eleqedar e. Ew tê wê astê ku, mînakî, Docker Hub gelek standardên OCI piştgirî dike. Ez texmîn nakim, lê dibe ku pêşkêşkerên depoya Docker-a klasîk dest pê bikin ku fersendê bidin we ku hûn nexşeyên Helm-a xwe mêvandar bikin.
Çîroka nakokî ji bo min ev e Lua piştgirî, wekî motora şablonê ji bo nivîsandina senaryoyan. Ez ne heyranokek mezin a Lua me, lê ev ê taybetmendiyek bi tevahî vebijarkî be. Min ev 3 caran kontrol kir - karanîna Lua dê ne hewce be. Ji ber vê yekê, yên ku dixwazin bikarin Lua bikar bînin, yên ku Go hez dikin, beşdarî kampa me ya mezin dibin û ji bo vê go-tmpl bikar tînin.
Di dawiyê de, ya ku min bê guman winda bû derketina schema û pejirandina celebê daneyê. Dê bi int û stringê re êdî ti pirsgirêk tunebin, ne hewce ye ku sifir di nav lêkerên ducar de were pêçandin. Dê şemayek JSONS xuya bibe ku dê bihêle hûn vê yekê ji bo nirxan bi eşkere diyar bikin.
Dê bi giranî ji nû ve were xebitandin modela bûyer-rêveberî. Jixwe bi têgînî hatiye vegotin. Li şaxê Helm 3 binihêrin, û hûn ê bibînin ku çend bûyer û çeng û tiştên din hatine zêdekirin, ku dê pir hêsan bike û, ji aliyek din ve, kontrolê li ser pêvajoyên bicîhkirinê û reaksiyonên li ser wan zêde bike.
Helm 3 dê hêsantir, ewledar û kêfxweştir be, ne ji ber ku em ji Helm 2 hez nakin, lê ji ber ku Kubernetes pêşkeftîtir dibe. Li gorî vê yekê, Helm dikare pêşkeftinên Kubernetes bikar bîne û li ser wê ji bo Kubernetes rêveberên hêja biafirîne.
Mizgîniyek din a baş ew e Alexander Khayorov dê ji we re bêje, Em bînin bîra xwe ku konferansa li ser yekbûna pêvajoyên pêşveçûn, ceribandin û operasyonê dê li Moskowê were lidarxistin 30ê Îlonê û 1ê Cotmehê. Hûn dikarin hîn jî heta 20ê Tebaxê bikin û ji me re serpêhatiya xwe ya bi çareseriyê re bêje peywirên nêzîkatiya DevOps.
Li nuqteyên kontrolê û nûçeyên konferansê bişopînin и .
Source: www.habr.com