Pas ne paraqesin vëllain e tij më të madh — . Ky është një projekt Open Source, i cili përdoret për të instaluar në klasterin Kubernetes komponentët sistemorë, të cilët mund të quhen me fjalën e përgjithshme — shtesa.
Pse në të vërtetë ndonjë shtesë?
Nuk është sekret që Kubernetes nuk është një produkt i gatshëm gjithçka-në-një, dhe për ndërtimin e një klasteri 'të rritur' do të nevojiten shtesa të ndryshme. Addon-operator do të ndihmojë në instalimin, konfigurimin dhe mbajtjen e këtyre shtesave në gjendje të përditësuar.
Nevoja për komponentë shtesë në klaster është zbuluar në koleget . Në përmbledhje, situata me Kubernetes në këtë moment është e tillë që për një instalim të thjeshtë 'për të luajtur' mund të mjaftohen me komponentët nga kutia, për zhvilluesit dhe testimin mund të shtohet Ingress, por për një instalim të plotë, për të cilin mund të thuhet 'prodhimi juaj është gati', nevojitet të shtohen rreth dhjetë shtesa të ndryshme: diçka për monitorimin, diçka për logjet, mos harroni ingress dhe cert-manager, ndarja e grupeve të nyjeve, shtimi i politikave rrjeti, përgatitja me cilësimet sysctl dhe pod autoscaler…
Cila është specifika e punës me to?
Siç e tregon praktika, një instalim nuk mjafton. Për një punë të këndshme me klasterin, shtesat do të duhet të përditësohen, të çaktivizohen (të hiqen nga klasteri), dhe ndoshta disa do të dëshirohet të testohen para instalimit në klasterin e prodhimit.
Pra, ndoshta do të mjaftonte dhe Ansible? Mundet. Por shtesat e plota në përgjithësi nuk jetojnë pa konfigurime. Këto konfigurime mund të ndryshojnë në varësi të llojit të klasterit (aws, gce, azure, bare-metal, do, ...). Disa konfigurime nuk mund të parashikohen paraprakisht — ato duhet të merren nga klasteri. Dhe klasteri nuk është statik: për disa konfigurime duhet të ndiqni ndryshimet. Këtu Ansible nuk mjafton: nevojitet një program që jeton në klaster, dmth. Kubernetes Operator.
Ata që e provuan në punë , do të thonë se detyrat e instalimit dhe përditësimit të shtesave dhe ndjekjes së konfigurimeve mund të zgjidhen plotësisht me për shell-operator. Mund të shkruhet një skript që do të bëjë një kubectl apply dhe do të ndjekë, për shembull, ConfigMap, ku do të ruhen konfigurimet. Kjo është e realizuar në addon-operator.
Si është organizuar në addon-operator?
Duke krijuar një zgjidhje të re, ne u bazuam në principet e mëposhtme:
- Instaluesi i shtesave duhet të mbështesë shabllonizimin dhe konfigurimin deklarativ.. Nuk nuk bëjmë skripte magjike që instalojnë shtesa. Addon-operator përdor Helm për të instaluar shtesa. Për instalim, duhet të krijoni një chart dhe të përcaktoni values, që do të përdoren për konfigurim.
- Konfigurimet mund të gjenerohen gjatë instalimit, mund të merren nga klasteri, ose të marrin përditësime, duke ndjekur burimet e klasterit. Këto operacione mund të realizohen me anë të hook-ëve.
- Konfigurimet mund të ruhet në klaster. Për ruajtjen e konfigurimeve në klaster krijohet një ConfigMap/addon-operator dhe Addon-operatori ndjek ndryshimet e këtij ConfigMap. Addon-operatori i jep hook-ëve akses në konfigurimet përmes marrëveshjeve të thjeshta.
- Shtesa varet nga konfigurimet. Nëse konfigurimet ndryshojnë, atëherë Addon-operatori nxjerr Helm-chart me values të reja. Bashkimi i Helm-chart, values për të dhe hook-ëve e kemi quajtur modul (shih më poshtë për më shumë).
- Staging. Nuk ka skripte të magjishme për lëshimin. Mekanizmi i përditësimeve është i ngjashëm me një aplikacion të zakonshëm—ngjitni shtesat dhe addon-operatorin në imazh, etiketoni dhe nxirrni.
- Kontrolli i rezultateve. Addon-operatori ka aftësinë të japë metrikat për Prometheus.
Çfarë është një shtesë në addon-operator?
Një shtesë mund të konsiderohet gjithçka që shton funksionalitete të reja në klaster. Për shembull, instalimi i Ingress-it është një shembull i shkëlqyer i një shtese. Kjo mund të jetë çdo operator ose kontrollues me CRD-në e tij: prometheus-operator, cert-manager, kube-controller-manager, etj. Ose diçka e vogël, por që lehtëson funksionimin—për shembull, një kopjues sekret që kopjon sekretet e regjistrit në hapësirat e reja të emrave, ose një rregullues sysctl që konfiguron parametrat sysctl në nyje të reja.
Për realizimin e shtesave, Addon-operatori ofron disa koncepte:
- Helm-chart përdoret për të instaluar softuer të ndryshëm në klaster—për shembull, Prometheus, Grafana, nginx-ingress. Nëse komponenti që ju nevojitet ka një Helm-chart, atëherë ta instaloni atë me anë të Addon-operatorit do të jetë shumë e thjeshtë.
- Ruajtja e values. Helm-chart-ët zakonisht kanë shumë konfigurime të ndryshme, të cilat mund të ndryshojnë me kalimin e kohës. Addon-operatori mbështet ruajtjen e këtyre konfigurimeve dhe ka aftësinë të ndiqet për ndryshimet e tyre, për të rinovuar Helm-chart-in me vlera të reja.
- Hukodat — janë skedarë ekzekutivë që Addon-operator i ekzekuton në ngjarje dhe që kanë qasje në magazinën e values. Hak-u mund të ndjekë ndryshimet në klaster dhe të përditësojë vlerat në magazinën e values. Kjo do të thotë se me ndihmën e hak-ëve mund të bëhet discovery për të mbledhur vlera nga klasteri gjatë fillimit ose sipas një orari, ose mund të bëhet discovery vazhdueshëm, duke mbledhur vlera nga klasteri përmes ndryshimeve në klaster.
- Moduli — është bashkimi i Helm-chart-it, magazinës së values dhe hak-ëve. Modulët mund të aktivizohen dhe çaktivizohen. Çaktivizimi i një moduli është heqja e të gjithë lëshimeve të Helm-chart-it. Modulët mund të përfshijnë veten dinamike, për shembull, nëse të gjithë modulët e nevojshëm janë aktivizuar ose nëse discovery në hak-e ka gjetur parametrat e nevojshëm — kjo bëhet me ndihmën e një skripti të ndihmës enabled.
- Hakët Globale. Këto janë hakë "vetvetiu", ata nuk janë të përfshirë në modulë dhe kanë qasje në magazinën globale të values, vlerat nga e cila janë të aksesueshme për të gjithë hak-ët në module.
Si funksionojnë këto pjesë bashkë? Le të shikojmë një figurë nga dokumentacioni:
Ka dy skenarë operimi:
- Hak-u global aktivizohet nga një ngjarje — për shembull, kur ndryshon një burim në klaster. Ky hak trajton ndryshimet dhe regjistron vlerat e reja në magazinën globale të values. Addon-operatori vëren se magazina globale është ndryshuar dhe aktivizon të gjithë modulët. Çdo modul, përmes hak-eve të tij, përcakton nëse duhet të aktivizohet dhe përditëson magazinën e tij të values. Nëse moduli është aktivizuar, Addon-operatori nis instalimin e Helm-chart-it. Helm-chart-it i janë të aksesueshme vlerat nga magazina e modulit dhe nga magazina globale.
- Skenari i dytë është më i thjeshtë: hak-u modular aktivizohet nga një ngjarje, ndryshon vlerat në magazinën e values të modulit. Addon-operatori e vëren këtë dhe aktivizon Helm-chart-in me vlerat e përditësuara.
Shtesa mund të jetë e realizuar në formën e një hak-u të vetëm ose si një Helm-chart, ose madje si disa module të varura — kjo varet nga kompleksiteti i komponentit që po instaloni në klaster dhe nga niveli i nevojshëm i fleksibilitetit të parametrit. Për shembull, në depo () ka një shtesë sysctl-tuner, e cila është realizuar si një modul i thjeshtë me një hak dhe Helm-chart, si dhe me përdorimin e magazinës së values, që ofron mundësinë për të shtuar parametra përmes redaktimit të ConfigMap.
Dërgimi i përditësimeve
Disa disa fjalë mbi organizimin e përditësimeve të komponenteve që instalon Addon-operator.
Për të nisur Addon-operator në klasër, nevojitet të mbledhim një imazh me shtesa si skedarë hook dhe chart-e Helm, të shtojmë skedarin binar addon-operator dhe gjithçka tjetër që nevojitet për hook: bash, kubectl, jq, python etj. Më pas, ky imazh mund të zbatohet në klasër si një aplikacion i zakonshëm dhe shumë mundësi do të dëshironit të organizonit një skemë etiketimi. Nëse ka disa klasër, mund të zbatohet i njëjti qasje si me aplikacionet: lëshimi i ri, version i ri, të kalosh nëpër të gjitha klasrat dhe të ndryshosh imazhin te Pod-ët. Megjithatë, në rastin e lëshimit në një numër të dukshëm klasrash, koncepti i vetë-përditësimit nga kanali do të ishte më i përshtatshëm.
Këtu është si është organizuar:
- Kanal është në thelb një identifikues, që mund të caktohet në çdo mënyrë (p.sh., dev/stage/ea/stable).
- Emri i kanalit është etiketa e imazhit. Kur nevojitet të lëshosh përditësime në kanal, një imazh i ri krijohet dhe etiketizohet me emrin e kanalit.
- Kur një imazh i ri shfaqet në registry, Addon-operator restartohet dhe nis me imazhin e ri.
Kjo nuk është praktika më e mirë, siç është përmendur në . Kjo nuk rekomandohet, por bëhet fjalë për një aplikacion të zakonshëm, që jeton në një klasër. Në rastin e Addon-operator, aplikacioni është një numër Deployments, të shpërndara nëpër klasra, dhe vetë-përditësimi ndihmon shumë dhe thjeshton jetën.
Kanale ndihmojnë gjithashtu në testim: nëse ka një klasër ndihmës, mund ta konfigurosh në kanal ) — një njësi organizimi e pipeline-it, përmban 1+ detyrë, dhe të testosh përditësimet në të para se të lëshosh në kanale ea dhe stabil. Nëse me klasrin në kanal ea ndodh një gabim, mund ta kalosh atë në stabil, derisa të hetosh problemin me këtë klasër. Nëse klasi është hequr nga mbështetje aktive, ai kalon në kanalin e tij "të ngurtë" — për shembull, freeze-2019-03-20.
Përveç përditësimeve të hooks dhe chart-eve Helm, mund të nevojitet të përditësohet gjithashtu një komponent të jashtëm. Për shembull, ke vërejtur një gabim në node-exporter të caktuar dhe madje ke menduar se si ta patch-osh. Më pas hap PR dhe pret një lëshim të ri për të kaluar nëpër të gjitha klasrat dhe për të rritur versionin e imazhit. Për të mos pritur për një kohë të pacaktuar, mund të mbledhësh node-exporter-in tënd dhe të kalosh në të deri sa PR të miratohet.
Në përgjithësi, është e mundur ta bësh këtë edhe pa Addon-operator, por me Addon-operator moduli për instalimin e node-exporter do të jetë i dukshëm në një depo, Dockerfile për ndërtimin e imazhit tënd mund të mbahet këtu, të gjithë pjesëmarrësve iu bëhet më e lehtë të kuptojnë se çfarë po ndodh... Dhe nëse ka disa klasterë, bëhet më e lehtë edhe si testimi i PR-it tënd, ashtu edhe instalimi i një versioni të ri!
Kjo organizatë e përditësimit të komponenteve punon me sukses për ne, por mund të realizohet edhe çdo skemë tjetër e përshtatshme — sepse në këtë rast Addon-operator është një skedar i thjeshtë binar.
Përfundim
Principet e realizuara në Addon-operator lejojnë ndërtimin e një procesi të qartë për krijimin, testimin, instalimin dhe përditësimin e plotësimeve në klaster, të ngjashëm me proceset e zhvillimit të aplikacioneve të zakonshme.
Plotësimet për Addon-operator në formatin e moduleve (Helm-chart + hooks) mund të publikohen në akses të gjerë. Ne, kompania Flant, planifikojmë të publikojmë gjatë verës zhvillimet tona në formën e këtyre plotësimeve. Bashkohuni në zhvillim në GitHub (, ), provoni të bëni plotësimin tuaj mbi dhe , prisni lajme në Habra dhe në !
P.S.
Lexoni gjithashtu në blogun tonë:
- «»;
- «».
Burimi: habr.com
