Pas shfaqjes ne prezantojmĂ« vĂ«llanĂ« e tij mĂ« tĂ« madh â . Ky Ă«shtĂ« njĂ« projekt Open Source qĂ« pĂ«rdoret pĂ«r tĂ« instaluar nĂ« njĂ« kluster Kubernetes komponentĂ«t sistemorĂ«, tĂ« cilat mund tĂ« quhen me njĂ« fjalĂ« tĂ« pĂ«rbashkĂ«t â plotĂ«suese.
Përse na nevojiten plotësuese?
Nuk është sekret që Kubernetes nuk është një produkt përfundimtar gjith-in-një, dhe për të ndërtuar një kluster 'të rritur' do të nevojiten plotësuese të ndryshme. Adaptor-operator do të ndihmojë në instalimin, konfigurimin dhe mbajtjen përditësuar të këtyre plotësueseve.
Nevoja pĂ«r komponente shtesĂ« nĂ« kluster Ă«shtĂ« e zbuluar nĂ« kolegu . NĂ« pĂ«rmbledhje, situata me Kubernetes aktualisht Ă«shtĂ« e tillĂ« qĂ« pĂ«r njĂ« instalim tĂ« thjeshtĂ« 'pĂ«r tĂ« provuar' mund tĂ« mjaftohesh me komponentĂ«t e kutisĂ«, pĂ«r zhvilluesit dhe testimin mund tĂ« shtosh Ingress, por pĂ«r njĂ« instalim tĂ« plotĂ«, pĂ«r tĂ« cilin mund tĂ« thuash 'produkti yt Ă«shtĂ« gati', Ă«shtĂ« e nevojshme tĂ« shtosh rreth dhjetĂ« plotĂ«suese tĂ« ndryshme: diçka pĂ«r monitorimin, diçka pĂ«r log-et, mos harro ingress dhe cert-manager, ndaje grupe nodalesh, shto politikat e rrjetit, pĂ«rfundo me konfigurime sysctl dhe autoscaler pĂ«r podâŠ
Cila është specifika e punës me to?
Si në tregojnë praktikat, një instalim nuk mjafton. Për një funksionim komod me klasterin, do të nevojitet që shtesat të përditësohen, të çaktivizohen (të hiqen nga klasteri), dhe ndoshta do të dëshirohet të testohen para vendosjes në klasterin production.
Ndoshta, mjafton kĂ«tu edhe Ansible? Mund tĂ« jetĂ«. Por shtesat funksionale 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Ă« vendosen paraprakisht â ato duhet tĂ« merren nga klasteri. Dhe klasteri nuk Ă«shtĂ« statik: pĂ«r disa konfigurime, do tĂ« duhet tĂ« ndjekim ndryshimet. Dhe kĂ«tu Ansible nuk Ă«shtĂ« e mjaftueshme: na nevojitet njĂ« program qĂ« jeton brenda klasterit, domethĂ«nĂ« njĂ« Kubernetes Operator.
Ata që e kanë provuar në praktikë , do të thonë se detyrat e instalimit dhe përditësimit të shtesave dhe monitorimi i konfigurimeve mund të zgjidhen fare mirë me për shell-operator. Mund të shkruhet një skript, i cili do të bëjë një kusht kubectl aplikoni dhe do të monitorojë, për shembull, ConfigMap, ku do të ruhen konfigurimet. Ajo, në të vërtetë, është realizuar në addon-operator.
Si është organizuar në addon-operator?
Kur krijuam një zgjidhje të re, u bazuam në parimet e mëposhtme:
- Instaluesi i shtesave duhet të mbështesë shabllonizimin dhe konfigurimin deklarativ. Nuk bëjmë skripte magjike që instalojnë shtesa. Addon-operator përdor Helm për të instalur shtesa. Për instalimin, duhet të krijoni një chart dhe të përzgjidhni vlerat që do të përdoren për konfigurinë.
- Cilësimet mund të gjenerohen gjatë instalimit, ato mund të merren nga klasteri, ose të marrin përditësime, duke ndjekur burimet e klasterit. Këto operacione mund të realizohen nëpërmjet hooks.
- Cilësimet mund të të ruhen në klaster. Për ruajtjen e cilësimeve në klaster krijohet ConfigMap/addon-operator dhe Addon-operator ndjek ndryshimet e këtij ConfigMap. Addon-operator ofron qasje në cilësime për hooks nëpërmjet marrëveshjeve të thjeshta.
- Shtesa varet nga cilësimet. Nëse cilësimet ndryshojnë, Addon-operator lëshon Helm-chart me vlerat e reja. Bashkimi i Helm-chart, vlerat për të dhe hooks ne e kemi quajtur modul (shih më poshtë).
- Stage-ing. Nuk ka skripte magjike pĂ«r lĂ«shimin. Mekanizmi i pĂ«rditĂ«simeve Ă«shtĂ« i ngjashĂ«m me njĂ« aplikacion normal â mbledhjen e shtesave dhe addon-operator nĂ« njĂ« imazh, etiketimin dhe lĂ«shimin.
- Kontrolli i rezultatit. Addon-operator ka aftësinë të japë metrika për Prometheus.
ĂfarĂ« Ă«shtĂ« njĂ« shtesĂ« nĂ« addon-operator?
NjĂ« shtesĂ« mund tĂ« quhet gjithçka qĂ« sjell funksionalitete tĂ« reja nĂ« grumbull. PĂ«r shembull, instalimi i Ingress-it Ă«shtĂ« njĂ« shembull i shkĂ«lqyer i njĂ« shtese. Mund tĂ« jetĂ« çdo operator ose kontrollues me CRD-tĂ« e tij: prometheus-operator, cert-manager, kube-controller-manager, etj. Ose diçka e vogĂ«l, por qĂ« lehtĂ«son operimin â pĂ«r shembull, njĂ« kopjues sekret, qĂ« kopjon sekretet e regjistrit nĂ« hapĂ«sira tĂ« reja emrash, ose njĂ« rregullues sysctl, qĂ« konfiguron parametrat sysctl nĂ« nyje tĂ« reja.
PĂ«r realizimin e shtesave, Addon-operator ofron disa koncepte:
- Helm-chart pĂ«rdoret pĂ«r tĂ« instaluar software tĂ« ndryshĂ«m nĂ« grumbull â pĂ«r shembull, Prometheus, Grafana, nginx-ingress. NĂ«se komponenti i nevojshĂ«m ka njĂ« Helm-chart, atĂ«herĂ« ta instaloje atĂ« me Addon-operator do tĂ« jetĂ« shumĂ« e thjeshtĂ«.
- Depoja e vlerave. Helm-chart-at zakonisht kanë shumë cilësime të ndryshme, të cilat mund të ndryshojnë me kalimin e kohës. Addon-operator mbështet ruajtjen e këtyre cilësimeve dhe di të ndjekë ndryshimet e tyre, për të riparë Helm-chart-in me vlera të reja.
- Hukut â janĂ« skedarĂ« ekzekutivĂ« qĂ« Addon-operator i ekzekuton nĂ« ngjarje dhe qĂ« kanĂ« qasje nĂ« depon e values. Huku mund tĂ« ndjekĂ« ndryshimet nĂ« grup dhe tĂ« pĂ«rditĂ«sojĂ« vlerat nĂ« depon e values. KĂ«shtu, me ndihmĂ«n e hukeve mund tĂ« bĂ«het discovery pĂ«r mbledhjen e vlerave nga grupi nĂ« fillim ose sipas njĂ« programi, madje edhe discovery tĂ« vazhdueshĂ«m, duke mbledhur vlera nga grupi nĂ« pĂ«rputhje me ndryshimet nĂ« grup.
- Moduli â Ă«shtĂ« njĂ« bashkim i Helm-chart, depo tĂ« values dhe hukeve. Modulet mund tĂ« aktivizohen dhe çaktivizohen. Ăaktivizimi i modulit do tĂ« thotĂ« tĂ« fshihen tĂ« gjitha publikimet e Helm-chart. Modulet mund tĂ« pĂ«rfshijnĂ« veten dinamikisht, pĂ«r shembull, nĂ«se tĂ« gjithĂ« modulĂ«t e nevojshĂ«m janĂ« aktivizuar ose nĂ«se discovery nĂ« huke ka gjetur parametrat e nevojshĂ«m â kjo bĂ«het me ndihmĂ«n e njĂ« skripti tĂ« ndihmĂ«s enabled.
- Huket globale. Këto janë huke "vetë"; ato nuk përfshihen në module dhe kanë qasje në depo globale të values, vlerat e të cilave janë të disponueshme për të gjithë huke në module.
Si funksionojnë këto pjesë së bashku? Le të shohim imazhin nga dokumentacioni:
Ka dy skenarë të funksionimit:
- Hoku global aktivizohet nga njĂ« ngjarje â pĂ«r shembull, kur ndryshohet burimi nĂ« klasĂ«r. Ky hoku trajton ndryshimet dhe ruan vlerat e reja nĂ« magazinĂ«n globale tĂ« values. Addon-operator vĂ«ren se magazina globale Ă«shtĂ« ndryshuar dhe aktivizon tĂ« gjithĂ« modulĂ«t. Ădo modul, duke pĂ«rdorur hoku e tij, pĂ«rcakton nĂ«se duhet tĂ« aktivizohet dhe pĂ«rditĂ«son magazinĂ«n e tij tĂ« values. NĂ«se moduli Ă«shtĂ« aktivizuar, atĂ«herĂ« Addon-operatori fillon instalimin e Helm-chart. Helm-chart ka qasje nĂ« vlerat nga magazina e modulit dhe nga magazina globale.
- Skema e dytë është më e thjeshtë: hoku modular aktivizohet nga një ngjarje, ndryshon vlerat në magazinën e values të modulit. Addon-operator e vëren këtë dhe aktivizon Helm-chart me vlerat e përditësuara.
Shtesat mund tĂ« realizohen si njĂ« hoku i vetĂ«m ose si njĂ« Helm-chart, ose madje edhe si disa module tĂ« varura â kjo varet nga kompleksiteti i komponentit qĂ« instalohet nĂ« klasĂ«r dhe niveli i nevojshĂ«m i fleksibilitetit tĂ« konfigurimeve. PĂ«r shembull, nĂ« repozitor) ka njĂ« shtesĂ« sysctl-tuner, e cila Ă«shtĂ« e implementuar si njĂ« modul i thjesht me njĂ« hook dhe Helm-chart, si dhe me pĂ«rdorimin e ruajtes sĂ« values, duke mundĂ«suar shtimin e konfigurimeve pĂ«rmes redaktimit tĂ« ConfigMap.
DĂ«rgesa e azhurnimeve
Disa fjalë rreth organizimit të azhurnimeve të komponentëve, të cilat instalon Addon-operator.
Për të nisur Addon-operator në klaster, është e nevojshme të ndërtosh një imazh me shtesat në formë skedari hook dhe Helm-chart, të shtosh skedarin binar addon-operator dhe gjithçka tjetër që nevojitet për hooks: bash, kubectl, jq, python etj. Më pas, ky imazh mund të shpërndahet në klaster si një aplikacion i zakonshëm dhe me siguri do të dëshironit të organizoni një skemë të tillë të etiketimit. Nëse ka pak klasterë, mund të përshtatet të njëjtin qasje si me aplikacionet: lëshimi i ri, versioni i ri, të shkohet në të gjitha klasterët dhe të rregullohet imazhi në Pod'et. Megjithatë, në rastin e shpërndarjes në një numër të konsiderueshëm klasterësh, koncepti i vetë-azhurimit nga kanali është më i përshtatshëm për ne.
Këtu është si është organizuar:
- Kanali â Ă«shtĂ« nĂ« thelb njĂ« identifikues qĂ« mund tĂ« caktosh çfarĂ«do (pĂ«r shembull, dev/stage/ea/stable).
- Emri i kanalit është etiketa e imazhit. Kur është e nevojshme të zhvillohen përditësime në kanal, krijohet një imazh i ri dhe etiketuar me emrin e kanalit.
- Kur në registry shfaqet një imazh i ri, Addon-operatori rinis dhe aktivizohet me imazhin e ri.
Kjo nuk është praktika më e mirë, për të cilën është shkruar në . Kjo nuk rekomandohet, por bëhet fjalë për një aplikacion të zakonshëm që jeton në një kllaster. Në rastin e Addon-operatorit, aplikacioni është një grup Deployments, të shpërndara nëpër kllastere, dhe vetë-rinovimi ndihmon shumë dhe thjeshton jetën.
Kanalet ndihmojnĂ« gjithashtu nĂ« testim: nĂ«se ka njĂ« kllaster ndihmĂ«s, mund ta konfiguroni atĂ« nĂ« kanal stage dhe tĂ« zhvilloni pĂ«rditĂ«sime nĂ« tĂ« pĂ«rpara se tĂ« lindin nĂ« kanalet ea dhe stable. NĂ«se me kllasterin nĂ« kanal ea ndodh njĂ« gabim, mund ta kaloni atĂ« nĂ« stable, derisa tĂ« hetohet problemi me kĂ«tĂ« kllaster. NĂ«se kllasteri Ă«shtĂ« nxjerrĂ« nga mbĂ«shtetja aktive, ai kalon nĂ« kanalin e tij "tĂ« ngrirĂ«" â pĂ«r shembull, freeze-2019-03-20.
. Përveç përditësimeve të hook-ëve dhe Helm-chart-ëve, mund të jetë e nevojshme të përditësohet edhe një komponent i jashtëm. Për shembull, ju keni vënë re një gabim në node-exporter dhe madje keni menduar se si ta rregulloni atë. Më pas hapni një PR dhe prisni një version të ri për të kaluar nëpër të gjitha klasterët dhe për të rritur versionin e imazhit. Për të mos pritur një kohë të pacaktuar, mund të ndërtosh node-exporter-in tuaj dhe të kalosh te ai derisa PR të miratohet.
Në përgjithësi, kjo mund të bëhet 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 tuaj mund të ruhet atje, është më e lehtë për të gjithë pjesëmarrësit që të kuptojnë se çfarë po ndodh... Dhe nëse ka disa klasterë, bëhet më e lehtë si për të testuar PR tuaj, ashtu edhe për të instaluar versionin e ri!
Kjo organizatĂ« e azhurnimeve tĂ« komponentĂ«ve funksionon me sukses pĂ«r ne, por gjithashtu mund tĂ« realizohet çdo skemĂ« tjetĂ«r e pĂ«rshtatshme â sepse nĂ« kĂ«tĂ« rast, Addon-operator Ă«shtĂ« njĂ« skedar i thjeshtĂ« binar.
PĂ«rfundimi
Parimet e realizuara në Addon-operator lejojnë që të ndërtohet një proces i qartë për krijimin, testimin, instalimin dhe azhurnimin e plotësimeve në klaster, i ngjashëm me proceset e zhvillimit të aplikacioneve të zakonshme.
Shtesat për Addon-operator në format module (Helm-chart + hooks) mund të publikohen për përdorim të gjerë. Ne, kompania Flant, planifikojmë të publikojmë gjatë verës arritjet tona në formën e këtyre shtesave. Bashkohuni me zhvillimin në GitHub (, ), provoni të krijoni shtesën tuaj mbi dhe , prisni lajme në Habrë dhe në kanalin tonë !
P.S.
Lexoni gjithashtu në blogun tonë:
- «»;
- «».
Burimi: habr.com
