A është e lehtë dhe e përshtatshme për të përgatitur një grup Kubernetes? Njoftimi i operatorit shtesë

A është e lehtë dhe e përshtatshme për të përgatitur një grup Kubernetes? Njoftimi i operatorit shtesë

Pas shell-operator ne prezantojmë vëllain e tij më të madh - shtesë-operator. Ky është një projekt me burim të hapur që përdoret për të instaluar komponentët e sistemit në një grup Kubernetes, i cili mund të quhet shtesa.

Pse fare shtesa?

Nuk është sekret që Kubernetes nuk është një produkt i gatshëm gjithëpërfshirës dhe për të ndërtuar një grup "të rritur" do t'ju duhen shtesa të ndryshme. Operatori shtesë do t'ju ndihmojë të instaloni, konfiguroni dhe mbani të përditësuara këto shtesa.

Nevoja për komponentë shtesë në grup është shpalosur në raport Kolegë driusha. Shkurtimisht, situata me Kubernetes për momentin është e tillë që për një instalim të thjeshtë "play around" mund t'ia dilni mbanë me komponentët jashtë kutisë, për zhvilluesit dhe testimin mund të shtoni Ingress, por për një instalim të plotë, rreth të cilit ju mund të thoni "prodhimi juaj është gati", ju duhet të shtoni me një duzinë shtesash të ndryshme: diçka për monitorim, diçka për regjistrim, mos harroni hyrjen dhe menaxherin e certifikatës, zgjidhni grupe nyjesh, shtoni politikat e rrjetit, sezonin me cilësimet e shkallëzimit automatik të sysctl dhe pod...

A është e lehtë dhe e përshtatshme për të përgatitur një grup Kubernetes? Njoftimi i operatorit shtesë

Cilat janë specifikat e punës me ta?

Siç tregon praktika, çështja nuk kufizohet në një instalim. Për të punuar rehat me grupin, shtesat do të duhet të përditësohen, çaktivizohen (të hiqen nga grupi) dhe do të dëshironi të testoni disa përpara se t'i instaloni në grupin e prodhimit.

Pra, ndoshta Ansible do të jetë e mjaftueshme këtu? Ndoshta. Por Në përgjithësi, shtesat e plota nuk jetojnë pa cilësime. Këto cilësime mund të ndryshojnë në varësi të variantit të grupit (aws, gce, azure, bare-metal, do, ...). Disa cilësime nuk mund të specifikohen paraprakisht; ato duhet të merren nga grupi. Dhe grupi nuk është statik: për disa cilësime do t'ju duhet të monitoroni ndryshimet. Dhe këtu Ansible tashmë mungon: ju duhet një program që jeton në një grup, d.m.th. Operatori Kubernetes.

Ata që e kanë provuar në punë shell-operator, ata do të thonë se detyrat e instalimit dhe përditësimit të shtesave dhe cilësimeve të monitorimit mund të zgjidhen plotësisht duke përdorur grepa për operatorin e guaskës. Ju mund të shkruani një skenar që do të bëjë një kusht kubectl apply dhe monitoroni, për shembull, ConfigMap, ku do të ruhen cilësimet. Kjo është afërsisht ajo që zbatohet në operatorin shtesë.

Si organizohet kjo në operator shtesë?

Kur krijuam një zgjidhje të re, ne vazhduam nga parimet e mëposhtme:

  • Instaluesi i shtesës duhet të mbështesë shabllon dhe konfigurim deklarativ. Ne nuk bëjmë skriptet magjike që instalojnë shtesa. Operatori shtesë përdor Helm për të instaluar shtesa. Për të instaluar, duhet të krijoni një grafik dhe të zgjidhni vlerat që do të përdoren për konfigurim.
  • Cilësimet mund të jenë gjenerojnë gjatë instalimit, ata munden merrni nga grupiOse merrni përditësime, monitorimi i burimeve të grupimit. Këto operacione mund të zbatohen duke përdorur grepa.
  • Cilësimet mund të jenë ruani në një grup. Për të ruajtur cilësimet në grup, krijohet një ConfigMap/addon-operator dhe Operatori Addon monitoron ndryshimet në këtë ConfigMap. Operatori shtesë u jep grepave akses te cilësimet duke përdorur konventa të thjeshta.
  • Shtimi varet nga cilësimet. Nëse cilësimet kanë ndryshuar, atëherë Operatori Addon nxjerr grafikun Helm me vlera të reja. Ne e quajtëm kombinimin e grafikut të Helm, vlerat për të dhe grepa një modul (shih më poshtë për më shumë detaje).
  • Inskenimi. Nuk ka skenare të lëshimit magjik. Mekanizmi i përditësimit është i ngjashëm me një aplikacion të rregullt - mblidhni shtesa dhe operatorë shtesë në një imazh, etiketoni dhe shpërndani ato.
  • Kontrolli i rezultatit. Operatori shtesë mund të sigurojë metrikë për Prometheus.

Çfarë është mbushja në operatorin shtesë?

Një shtesë mund të konsiderohet çdo gjë që shton funksione të reja në grup. Për shembull, instalimi i Ingress është një shembull i shkëlqyer i një shtesë. Ky mund të jetë çdo operator ose kontrollues me CRD-në e vet: prometheus-operator, cert-manager, kube-controller-manager, etj. Ose diçka e vogël, por thjeshton funksionimin - për shembull, kopjues sekret, i cili kopjon sekretet e regjistrit në hapësira të reja emrash, ose sintonizues sysctl, i cili konfiguron parametrat sysctl në nyjet e reja.

Për të zbatuar shtesat, Operatori Addon ofron disa koncepte:

  • Tabela e helmetit përdoret për të instaluar softuer të ndryshëm në grup - për shembull, Prometheus, Grafana, nginx-ingress. Nëse komponenti i kërkuar ka një tabelë Helm, atëherë instalimi i tij duke përdorur Addon-operator do të jetë shumë i thjeshtë.
  • Ruajtja e vlerave. Grafikët e timonit zakonisht kanë shumë cilësime të ndryshme që mund të ndryshojnë me kalimin e kohës. Operatori shtesë mbështet ruajtjen e këtyre cilësimeve dhe mund të monitorojë ndryshimet e tyre në mënyrë që të riinstalojë grafikun Helm me vlera të reja.
  • Grepa janë skedarë të ekzekutueshëm që Operatori i Addon-it i ekzekuton në ngjarje dhe që hyjnë në dyqanin e vlerave. Hook mund të monitorojë ndryshimet në grup dhe të përditësojë vlerat në dyqanin e vlerave. Ato. Duke përdorur grepa, mund të bëni zbulime për të mbledhur vlera nga grupi në fillim ose sipas një plani, ose mund të bëni zbulime të vazhdueshme, duke mbledhur vlera nga grupi bazuar në ndryshimet në grup.
  • Modul është një kombinim i një grafiku Helm, një magazinë vlerash dhe grepa. Modulet mund të aktivizohen ose çaktivizohen. Çaktivizimi i një moduli nënkupton fshirjen e të gjitha lëshimeve të grafikut Helm. Modulet mund të aktivizohen në mënyrë dinamike, për shembull, nëse të gjitha modulet që i nevojiten janë të aktivizuara ose nëse zbulimi ka gjetur parametrat e nevojshëm në grepa - kjo bëhet duke përdorur një skript të aktivizuar ndihmës.
  • Grepa globale. Këto janë grepa "më vete", ato nuk përfshihen në module dhe kanë akses në një dyqan vlerash globale, vlerat e të cilave janë të disponueshme për të gjitha grepa në module.

Si funksionojnë këto pjesë së bashku? Le të shohim foton nga dokumentacioni:

A është e lehtë dhe e përshtatshme për të përgatitur një grup Kubernetes? Njoftimi i operatorit shtesë

Ekzistojnë dy skenarë pune:

  1. Lidhja globale aktivizohet nga një ngjarje - për shembull, kur një burim në grup ndryshon. Ky grep përpunon ndryshimet dhe shkruan vlerat e reja në dyqanin e vlerave globale. Operatori shtesë vëren se ruajtja globale ka ndryshuar dhe nis të gjitha modulet. Çdo modul, duke përdorur grepat e tij, përcakton nëse duhet të aktivizohet dhe përditëson ruajtjen e vlerave të tij. Nëse moduli është i aktivizuar, operatori Addon fillon instalimin e diagramit Helm. Në këtë rast, grafiku Helm ka akses në vlerat nga ruajtja e modulit dhe nga ruajtja globale.
  2. Skenari i dytë është më i thjeshtë: një goditje e modulit aktivizohet nga një ngjarje dhe ndryshon vlerat në ruajtjen e vlerave të modulit. Operatori shtesë e vëren këtë dhe lëshon grafikun e Helm-it me vlera të përditësuara.

Shtesa mund të zbatohet si një grep i vetëm, ose si një diagram i Helm-it, ose edhe si disa module të varura - kjo varet nga kompleksiteti i komponentit që instalohet në grup dhe nga niveli i dëshiruar i fleksibilitetit të konfigurimit. Për shembull, në depo (/shembuj) ekziston një shtesë sysctl-tuner, e cila zbatohet si një modul i thjeshtë me një grep dhe një tabelë Helm, dhe duke përdorur dyqanin e vlerave, i cili bën të mundur shtimin e cilësimeve duke redaktuar ConfigMap.

Dorëzimi i përditësimeve

Disa fjalë për organizimin e përditësimeve të komponentëve që instalon Operatori Addon.

Për të ekzekutuar Operatorin Addon në një grup, ju duhet ndërtoni një imazh me shtesa në formën e skedarëve të grafikut me grep dhe Helm, shtoni një skedar binar addon-operator dhe gjithçka që ju nevojitet për grepa: bash, kubectl, jq, python etj. Pastaj ky imazh mund të shpërndahet në grup si një aplikacion i rregullt, dhe ka shumë të ngjarë që ju të dëshironi të organizoni një ose një skemë tjetër etiketimi. Nëse ka pak grupime, e njëjta qasje si me aplikacionet mund të jetë e përshtatshme: version i ri, version i ri, shkoni te të gjitha grupimet dhe korrigjoni imazhin e Pods. Megjithatë, në rastin e një prezantimi në një numër të konsiderueshëm grupesh, koncepti i vetë-përditësimit nga një kanal ishte më i përshtatshëm për ne.

Ja si e bëjmë:

  • Një kanal është në thelb një identifikues që mund të vendoset në çdo gjë (për shembull, dev/stage/ea/stable).
  • Emri i kanalit është etiketa e imazhit. Kur ju duhet të hapni përditësime në një kanal, një imazh i ri mblidhet dhe etiketohet me emrin e kanalit.
  • Kur një imazh i ri shfaqet në regjistër, Operatori shtesë riniset dhe niset me imazhin e ri.

Kjo nuk është praktika më e mirë, siç shkruhet në Dokumentacioni Kubernetes. Nuk rekomandohet ta bëni këtë, por ne po flasim një aplikacion i rregullt që jeton në të njëjtin grup. Në rastin e Operatorit Addon, një aplikacion ka shumë vendosje të shpërndara nëpër grupe, dhe vetë-azhurnimi ndihmon shumë dhe e bën jetën më të lehtë.

Kanalet ndihmojnë dhe në testim: nëse ka një grup ndihmës, mund ta konfiguroni atë në kanal stage dhe futni përditësimet në të përpara se ta shpërndani në kanale ea и stable. Nëse me një grup në kanal ea ka ndodhur një gabim, mund ta kaloni në stable, ndërkohë që po hetohet problemi me këtë grupim. Nëse grupi hiqet nga mbështetja aktive, ai kalon në kanalin e tij "të ngrirë" - për shembull, freeze-2019-03-20.

Përveç përditësimit të grepave dhe grafikëve të Helm, mund t'ju duhet përditësimi dhe komponenti i palës së tretë. Për shembull, keni vënë re një gabim në eksportuesin e nyjeve të kushtëzuara dhe madje keni kuptuar se si ta rregulloni atë. Më pas, keni hapur PR dhe jeni duke pritur që publikimi i ri të kalojë nëpër të gjitha grupimet dhe të rrisë versionin e imazhit. Për të mos pritur pafundësisht, mund të ndërtoni eksportuesin tuaj të nyjeve dhe të kaloni tek ai përpara se të pranoni PR.

Në përgjithësi, kjo mund të bëhet pa Operator Addon, por me Addon-operator moduli për instalimin e eksportuesit të nyjeve do të jetë i dukshëm në një depo, Dockerfile për ndërtimin e imazhit tuaj mund të mbahet pikërisht atje, bëhet më e lehtë për të gjithë pjesëmarrësit në procesi për të kuptuar se çfarë ndodh... Dhe nëse ka disa grupime, atëherë bëhet më e lehtë të testoni PR tuaj dhe të nxirrni një version të ri!

Ky organizim i përditësimit të komponentëve funksionon me sukses për ne, por çdo skemë tjetër e përshtatshme mund të zbatohet - në fund të fundit në këtë rast Addon-operator është një skedar i thjeshtë binar.

Përfundim

Parimet e zbatuara në Operatorin Addon ju lejojnë të ndërtoni një proces transparent për krijimin, testimin, instalimin dhe përditësimin e shtesave në një grup, të ngjashëm me proceset e zhvillimit të aplikacioneve të rregullta.

Shtesat për operatorin shtesë në formatin e modulit (Trafiku i timonit + grepa) mund të vihen në dispozicion të publikut. Ne, kompania Flant, planifikojmë të publikojmë zhvillimet tona në formën e shtesave të tilla gjatë verës. Bashkohuni me zhvillimin në GitHub (shell-operator, shtesë-operator), përpiquni të bëni shtesën tuaj bazuar në shembuj и dokumentacionin, prisni lajme në Habré dhe në tonë Kanali në YouTube!

PS

Lexoni edhe në blogun tonë:

Burimi: www.habr.com

Shto një koment