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
