Post ni prezentas lian pli maljunan fraton - . Ĉi tio estas Malfermfonta projekto, kiu estas uzata por instali sistemajn komponantojn en Kubernetes-grupon, kiu povas esti nomata aldonaĵoj.
Kial entute aldonoj?
Ne estas sekreto, ke Kubernetes ne estas preta tute-en-unu produkto, kaj por konstrui "plenkreskan" areton vi bezonos diversajn aldonojn. Addon-operator helpos vin instali, agordi kaj konservi ĉi tiujn aldonaĵojn ĝisdatigitaj.
La bezono de pliaj komponentoj en la areto estas malkaŝita en Kolegoj . Resume, la situacio kun Kubernetes nuntempe estas tia, ke por simpla "ludi ĉirkaŭ" instalado vi povas elteni la komponantojn el la skatolo, por programistoj kaj testado vi povas aldoni Ingress, sed por plena instalado, pri kiu vi povas diri "via produktado estas preta", vi devas aldoni kun dekduo da malsamaj aldonaĵoj: ion por monitorado, ion por registri, ne forgesu eniron kaj cert-manaĝeron, elektu grupojn de nodoj, aldoni retajn politikojn, sezonon. kun sysctl kaj pod aŭtoskaler-agordoj...
Kio estas la specifaĵoj de labori kun ili?
Kiel praktiko montras, la afero ne estas limigita al unu instalado. Por labori komforte kun la areto, aldonaĵoj devos esti ĝisdatigitaj, malŝaltitaj (forigitaj de la areto), kaj vi volos testi iujn antaŭ ol instali ilin en la produktadgrupo.
Do, eble Ansible sufiĉos ĉi tie? Eble. Sed Ĝenerale, plenrajtaj aldonaĵoj ne vivas sen agordoj. Ĉi tiuj agordoj povas malsami depende de la cluster-variaĵo (aws, gce, azure, bare-metal, do, ...). Kelkaj agordoj ne povas esti specifitaj anticipe; ili devas esti akiritaj de la areto. Kaj la areto ne estas senmova: por iuj agordoj vi devos kontroli ŝanĝojn. Kaj ĉi tie Ansible jam mankas: vi bezonas programon, kiu loĝas en areto, t.e. Kubernetes Operatoro.
Tiuj, kiuj provis ĝin en la laboro , ili diros, ke la taskoj instali kaj ĝisdatigi aldonaĵojn kaj kontrolajn agordojn povas esti tute solvitaj uzante por ŝelo-funkciigisto. Vi povas skribi skripton kiu faros kondiĉon kubectl apply kaj monitori, ekzemple, ConfigMap, kie la agordoj estos konservitaj. Ĉi tio estas proksimume kio estas efektivigita en addon-operator.
Kiel ĉi tio estas organizita en addon-operator?
Kreante novan solvon, ni procedis de la sekvaj principoj:
- La aldonaĵa instalilo devas subteni ŝablono kaj deklara agordo. Ni ne faras magiajn skriptojn, kiuj instalas aldonaĵojn. Addon-operatoro uzas Helm por instali aldonaĵojn. Por instali, vi devas krei diagramon kaj elekti la valorojn, kiuj estos uzataj por agordo.
- Agordoj povas esti generi dum instalado, ili povas akiri de aretoaŭ ricevi ĝisdatigojn, monitorante clusterresursojn. Ĉi tiuj operacioj povas esti efektivigitaj per hokoj.
- Agordoj povas esti stoki en areto. Por stoki agordojn en la areto, KonfigMap/aldon-operatoro estas kreita kaj la Addon-funkciigisto kontrolas ŝanĝojn al ĉi tiu ConfigMap. Addon-funkciigisto donas al hokoj aliron al agordoj uzante simplajn konvenciojn.
- Aldono dependas de agordoj. Se la agordoj ŝanĝiĝis, tiam la Addon-funkciigisto ruliĝas la Helm-diagramon kun novaj valoroj. Ni nomis la kombinaĵon de la Helm-diagramo, valoroj por ĝi kaj hokoj modulo (vidu sube por pliaj detaloj).
- Enscenigo. Ne ekzistas magiaj eldonaj skriptoj. La ĝisdatiga mekanismo estas simila al kutima aplikaĵo - kolektu aldonaĵojn kaj aldon-funkciigistojn en bildon, etikedu ilin kaj eliru ilin.
- Kontrolo de rezulto. Addon-funkciigisto povas disponigi metrikojn por Prometheus.
Kio estas kompletigo en addon-operatoro?
Aldono povas esti konsiderata io ajn, kiu aldonas novajn funkciojn al la areto. Ekzemple, instali Ingress estas bonega ekzemplo de aldonaĵo. Ĉi tio povas esti ajna funkciigisto aŭ regilo kun sia propra CRD: prometheus-operator, cert-manager, kube-controller-manager, ktp. Aŭ io malgranda, sed pli facile uzebla - ekzemple sekreta kopiilo, kiu kopias registrajn sekretojn al novaj nomspacoj, aŭ sysctl tuner, kiu agordas sysctl-parametrojn sur novaj nodoj.
Por efektivigi aldonaĵojn, Addon-operator disponigas plurajn konceptojn:
- Helm-diagramo uzata por instali diversajn programojn en la areton - ekzemple Prometheus, Grafana, nginx-ingress. Se la postulata komponanto havas Helm-diagramon, tiam instali ĝin per Addon-operator estos tre simpla.
- Stokado de valoroj. Helm-diagramoj kutime havas multajn malsamajn agordojn, kiuj povas ŝanĝiĝi kun la tempo. Addon-operatoro subtenas stoki ĉi tiujn agordojn kaj povas kontroli iliajn ŝanĝojn por reinstali la Helm-diagramon kun novaj valoroj.
- Hokoj estas ruleblaj dosieroj, kiujn la Addon-funkciigisto funkcias per eventoj kaj kiuj aliras la valor-butikon. La hoko povas monitori ŝanĝojn en la areto kaj ĝisdatigi la valorojn en la valorobutiko. Tiuj. Uzante hokojn, vi povas fari malkovron por kolekti valorojn de la areto ĉe ekfunkciigo aŭ laŭ horaro, aŭ vi povas fari daŭran malkovron, kolektante valorojn de la areto surbaze de ŝanĝoj en la areto.
- Modulo estas kombinaĵo de Helm-diagramo, vendejo de valoroj kaj hokoj. Moduloj povas esti ebligitaj aŭ malŝaltitaj. Malŝalti modulon signifas forigi ĉiujn Helm-diagrameldonojn. Moduloj povas ebligi sin dinamike, ekzemple, se ĉiuj moduloj kiujn ĝi bezonas estas ebligitaj aŭ se malkovro trovis la necesajn parametrojn en la hokoj - tio estas farita per helpa ebligita skripto.
- Tutmondaj hokoj. Ĉi tiuj estas hokoj "suste", ili ne estas inkluzivitaj en moduloj kaj havas aliron al tutmonda valorobutiko, kies valoroj estas disponeblaj por ĉiuj hokoj en moduloj.
Kiel ĉi tiuj partoj funkcias kune? Ni rigardu la bildon el la dokumentaro:
Estas du laborscenaroj:
- La tutmonda hoko estas ekigita de evento - ekzemple, kiam rimedo en la areto ŝanĝiĝas. Ĉi tiu hoko prilaboras la ŝanĝojn kaj skribas la novajn valorojn al la tutmonda valorobutiko. Addon-funkciigisto rimarkas, ke la tutmonda stokado ŝanĝiĝis kaj startas ĉiujn modulojn. Ĉiu modulo, uzante siajn hokojn, determinas ĉu ĝi devas esti ebligita kaj ĝisdatigas sian valor-butikon. Se la modulo estas ebligita, la Addon-funkciigisto komencas la instaladon de la Helm-diagramo. En ĉi tiu kazo, la Helm-diagramo havas aliron al valoroj de la modula stokado kaj de la tutmonda stokado.
- La dua scenaro estas pli simpla: modula hoko estas ekigita de evento kaj ŝanĝas valorojn en la valorobutiko de la modulo. Addon-funkciigisto rimarkas tion kaj lanĉas la Helm-diagramon kun ĝisdatigitaj valoroj.
La aldono povas esti efektivigita kiel unu ununura hoko, aŭ kiel unu Helm-diagramo, aŭ eĉ kiel pluraj dependaj moduloj - tio dependas de la komplekseco de la komponento instalita en la areto kaj de la dezirata nivelo de agorda fleksebleco. Ekzemple, en la deponejo () ekzistas aldonaĵo sysctl-tuner, kiu estas efektivigita kaj kiel simpla modulo kun hoko kaj Helm-diagramo, kaj uzante la valorvendejon, kiu ebligas aldoni agordojn per redaktado de ConfigMap.
Livero de ĝisdatigoj
Kelkajn vortojn pri organizado de komponentaj ĝisdatigoj kiujn Addon-operator instalas.
Por ruli Addon-operator en areto, vi bezonas konstrui bildon kun aldonoj en la formo de hoko kaj Helm-diagramo dosieroj, aldonu binaran dosieron addon-operator kaj ĉio, kion vi bezonas por hokoj: bash, kubectl, jq, python ktp. Tiam ĉi tiu bildo povas esti elvolvita al la areto kiel regula aplikaĵo, kaj plej verŝajne vi volos organizi unu aŭ alian etikedskemon. Se estas malmultaj aretoj, la sama aliro kiel kun aplikaĵoj povas esti taŭga: nova eldono, nova versio, iru al ĉiuj aretoj kaj korektu la bildon de la Pods. Tamen, en la kazo de lanĉo al signifa nombro da aretoj, la koncepto de mem-ĝisdatigo de kanalo estis pli taŭga por ni.
Jen kiel ni faras ĝin:
- Kanalo estas esence identigilo kiu povas esti agordita al io ajn (ekzemple, dev/stage/ea/stable).
- La kanala nomo estas la bilda etikedo. Kiam vi devas eldoni ĝisdatigojn al kanalo, nova bildo estas kunvenita kaj etikedita kun la kanala nomo.
- Kiam nova bildo aperas en la registro, Addon-operator estas rekomencita kaj lanĉita kun la nova bildo.
Ĉi tio ne estas plej bona praktiko, kiel skribite . Ne rekomendas fari ĉi tion, sed ni parolas pri tio regula aplikaĵo kiu loĝas en la sama areto. En la kazo de Addon-operatoro, aplikaĵo estas multaj Deplojoj disigitaj tra aretoj, kaj mem-ĝisdatigo multe helpas kaj faciligas la vivon.
Kanaloj helpas kaj en testado: se ekzistas helpa grapolo, vi povas agordi ĝin al la kanalo stage kaj ruliĝu ĝisdatigojn en ĝi antaŭ ol elŝuti ĝin al kanaloj ea и stable. Se kun areto sur la kanalo ea okazis eraro, vi povas ŝanĝi ĝin al stable, dum la problemo kun ĉi tiu areto estas esplorita. Se la areto estas elprenita el aktiva subteno, ĝi ŝanĝas al sia "frostigita" kanalo - ekzemple, freeze-2019-03-20.
Krom ĝisdatigi hokojn kaj Helm-diagramojn, vi eble bezonos ĝisdatigo kaj triaparta komponanto. Ekzemple, vi rimarkis cimon en la kondiĉa nodo-eksportisto kaj eĉ eltrovis kiel fliki ĝin. Poste, vi malfermis la PR kaj atendas ke la nova eldono trairu ĉiujn aretojn kaj pliigu la version de la bildo. Por ne atendi senfine, vi povas konstrui vian nodo-eksportanton kaj ŝanĝi al ĝi antaŭ ol akcepti la PR.
Ĝenerale, ĉi tio povas esti farita sen Addon-operator, sed kun Addon-operator la modulo por instali node-exporter estos videbla en unu deponejo, la Dockerfile por konstrui vian bildon povas esti konservita ĝuste tie, ĝi fariĝas pli facila por ĉiuj partoprenantoj en la procezo por kompreni kio okazas... Kaj se estas pluraj aretoj, tiam fariĝas pli facile kaj testi vian PR kaj eldoni novan version!
Ĉi tiu organizo de ĝisdatigo de komponantoj funkcias por ni sukcese, sed ajna alia taŭga skemo povas esti efektivigita - finfine ĉi-kaze Addon-operator estas simpla binara dosiero.
konkludo
La principoj efektivigitaj en Addon-operator permesas vin konstrui travideblan procezon por krei, testi, instali kaj ĝisdatigi aldonaĵojn en areto, simile al la evoluprocezoj de regulaj aplikoj.
Aldonaĵoj por Addon-operatoro en modula formato (Helm-diagramo + hokoj) povas esti publike disponeblaj. Ni, la kompanio Flant, planas publikigi niajn evoluojn en la formo de tiaj aldonoj dum la somero. Aliĝu al evoluo en GitHub (, ), provu fari vian propran aldonon bazitan sur и , atendu novaĵojn pri Habré kaj pri nia !
PS
Legu ankaŭ en nia blogo:
- «»;
- «".
fonto: www.habr.com