Na ons bied sy ouer broer aan - . Dit is 'n oopbronprojek wat gebruik word om stelselkomponente in 'n Kubernetes-kluster te installeer, wat byvoegings genoem kan word.
Hoekom enigsins enige toevoegings?
Dit is geen geheim dat Kubernetes nie 'n klaargemaakte alles-in-een-produk is nie, en om 'n "volwasse" groepie te bou sal jy verskeie toevoegings nodig hê. Addon-operateur sal jou help om hierdie byvoegings te installeer, op te stel en op datum te hou.
Die behoefte aan bykomende komponente in die groepering word geopenbaar in Kollegas . Kortom, die situasie met Kubernetes op die oomblik is so dat jy vir 'n eenvoudige "speel rond" installasie kan klaarkom met die komponente uit die boks, vir ontwikkelaars en toetsing kan jy Ingress byvoeg, maar vir 'n volledige installasie, waaroor jy kan sê "jou produksie is gereed", jy moet met 'n dosyn verskillende byvoegings byvoeg: iets vir monitering, iets vir aanteken, moenie ingang en sertifikaatbestuurder vergeet nie, groepe nodusse kies, netwerkbeleide byvoeg, seisoen met sysctl en pod autoscaler instellings...
Wat is die besonderhede van die werk met hulle?
Soos die praktyk toon, is die saak nie beperk tot een installasie nie. Om gemaklik met die groepering te werk, sal byvoegings opgedateer, gedeaktiveer (uit die groep verwyder) moet word, en jy sal sommige wil toets voordat jy dit in die produksiekluster installeer.
So, miskien sal Ansible hier genoeg wees? Kan wees. Maar Oor die algemeen leef volwaardige byvoegings nie sonder instellings nie. Hierdie instellings kan verskil afhangende van die groepvariant (aws, gce, azure, bare-metal, do, ...). Sommige instellings kan nie vooraf gespesifiseer word nie; hulle moet van die groep verkry word. En die groep is nie staties nie: vir sommige instellings sal jy veranderinge moet monitor. En hier ontbreek Ansible reeds: jy het 'n program nodig wat in 'n cluster woon, m.a.w. Kubernetes-operateur.
Diegene wat dit by die werk probeer het , sal hulle sê dat die take van die installering en opdatering van byvoegings en moniteringinstellings heeltemal opgelos kan word deur vir dop-operateur. Jy kan 'n skrif skryf wat 'n voorwaarde sal doen kubectl apply en monitor, byvoorbeeld, ConfigMap, waar die instellings gestoor sal word. Dit is ongeveer wat in addon-operateur geïmplementeer word.
Hoe word dit in addon-operateur georganiseer?
Toe ons 'n nuwe oplossing geskep het, het ons van die volgende beginsels uitgegaan:
- Die byvoeging installeerder moet ondersteun sjabloon en verklarende konfigurasie. Ons maak nie towerskrifte wat byvoegings installeer nie. Addon-operateur gebruik Helm om byvoegings te installeer. Om te installeer, moet jy 'n grafiek skep en die waardes kies wat vir konfigurasie gebruik sal word.
- Instellings kan wees genereer tydens installasie, hulle kan kry uit clusterOf opdaterings ontvang, monitering van groeperingshulpbronne. Hierdie bewerkings kan geïmplementeer word met behulp van hake.
- Instellings kan wees stoor in 'n groep. Om instellings in die groep te stoor, word 'n ConfigMap/addon-operateur geskep en die Addon-operateur monitor veranderinge aan hierdie ConfigMap. Addon-operateur gee hake toegang tot instellings deur eenvoudige konvensies te gebruik.
- Byvoeging hang af van instellings. As die instellings verander het, rol die Addon-operateur die Helm-grafiek met nuwe waardes uit. Ons het die kombinasie van die Helm-kaart, waardes daarvoor en hake 'n module genoem (sien hieronder vir meer besonderhede).
- Opvoering. Daar is geen towervrystellingskrifte nie. Die opdateringsmeganisme is soortgelyk aan 'n gewone toepassing - versamel byvoegings en addon-operateurs in 'n prent, merk hulle en rol dit uit.
- Resultaatbeheer. Addon-operateur kan statistieke vir Prometheus verskaf.
Wat is padding in addon-operateur?
'n Byvoeging kan as enigiets beskou word wat nuwe funksies by die groep voeg. Byvoorbeeld, die installering van Ingress is 'n goeie voorbeeld van 'n byvoeging. Dit kan enige operateur of kontroleerder met sy eie CRD wees: prometheus-operateur, cert-bestuurder, kube-beheerder-bestuurder, ens. Of iets klein, maar makliker om te gebruik - byvoorbeeld geheime kopieerder, wat registergeheime na nuwe naamruimtes kopieer, of sysctl-ontvanger, wat sysctl-parameters op nuwe nodusse konfigureer.
Om byvoegings te implementeer, bied Addon-operateur verskeie konsepte:
- Roerkaart gebruik om verskeie sagteware in die groepie te installeer - byvoorbeeld Prometheus, Grafana, nginx-ingress. As die vereiste komponent 'n Helm-kaart het, sal dit baie eenvoudig wees om dit met Addon-operateur te installeer.
- Waardes berging. Roerkaarte het gewoonlik baie verskillende instellings wat met verloop van tyd kan verander. Addon-operateur ondersteun die stoor van hierdie instellings en kan hul veranderinge monitor om die Helm-kaart met nuwe waardes weer te installeer.
- Hakies is uitvoerbare lêers wat die Addon-operateur op gebeurtenisse laat loop en wat toegang tot die waardestoor het. Die haak kan veranderinge in die groepie monitor en die waardes in die waardestoor opdateer. Dié. Deur hake te gebruik, kan jy ontdekking maak om waardes van die groepering in te samel by opstart of volgens 'n skedule, of jy kan deurlopende ontdekking doen, waardes van die groep versamel op grond van veranderinge in die groepering.
- Module is 'n kombinasie van 'n Helm-kaart, 'n waardewinkel en hake. Modules kan geaktiveer of gedeaktiveer word. Deaktiveer 'n module beteken die verwydering van alle Helm grafiek vrystellings. Modules kan hulself dinamies aktiveer, byvoorbeeld as al die modules wat dit benodig geaktiveer is of as ontdekking die nodige parameters in die hake gevind het - dit word gedoen met behulp van 'n hulp-geaktiveerde skrif.
- Globale hake. Hierdie is hake "op hul eie", hulle is nie by modules ingesluit nie en het toegang tot 'n globale waardestoor, waarvan die waardes beskikbaar is vir alle hake in modules.
Hoe werk hierdie dele saam? Kom ons kyk na die prentjie uit die dokumentasie:
Daar is twee werkscenario's:
- Die globale haak word veroorsaak deur 'n gebeurtenis - byvoorbeeld wanneer 'n hulpbron in die groep verander. Hierdie haak verwerk die veranderinge en skryf die nuwe waardes na die globale waardewinkel. Addon-operateur merk op dat die globale berging verander het en begin alle modules. Elke module, met behulp van sy hake, bepaal of dit geaktiveer moet word en dateer sy waardestoor op. As die module geaktiveer is, begin die Addon-operateur die installering van die Helm-kaart. In hierdie geval het die Helm-kaart toegang tot waardes vanaf die moduleberging en vanaf die globale berging.
- Die tweede scenario is eenvoudiger: 'n modulehaak word deur 'n gebeurtenis veroorsaak en verander waardes in die module se waardestoor. Addon-operateur merk dit op en stel die Helm-grafiek met opgedateerde waardes bekend.
Die byvoeging kan geïmplementeer word as een enkele haak, of as een Roerkaart, of selfs as verskeie afhanklike modules - dit hang af van die kompleksiteit van die komponent wat in die groep geïnstalleer word en van die verlangde vlak van konfigurasie buigsaamheid. Byvoorbeeld, in die bewaarplek () daar is 'n sysctl-tuner-byvoeging, wat geïmplementeer word as 'n eenvoudige module met 'n haak en 'n Helm-grafiek, en met behulp van die waardestoor, wat dit moontlik maak om instellings by te voeg deur ConfigMap te wysig.
Lewering van opdaterings
'n Paar woorde oor die organisering van komponentopdaterings wat Addon-operateur installeer.
Om Addon-operateur in 'n groep te laat loop, benodig jy bou 'n beeld met toevoegings in die vorm van haak- en Helm-kaartlêers, voeg 'n binêre lêer by addon-operator en alles wat jy nodig het vir hake: bash, kubectl, jq, python ens. Dan kan hierdie prent na die groep uitgerol word as 'n gewone toepassing, en heel waarskynlik sal jy een of ander merkerskema wil organiseer. As daar min clusters is, kan dieselfde benadering as met toepassings geskik wees: nuwe vrystelling, nuwe weergawe, gaan na alle clusters en korrigeer die beeld van die Pods. In die geval van 'n ontplooiing na 'n aansienlike aantal groepe, was die konsep van selfopdatering vanaf 'n kanaal egter meer geskik vir ons.
Hier is hoe ons dit doen:
- 'n Kanaal is in wese 'n identifiseerder wat op enigiets gestel kan word (byvoorbeeld dev/stage/ea/stable).
- Die kanaalnaam is die beeldmerker. Wanneer jy opdaterings na 'n kanaal moet uitrol, word 'n nuwe prent saamgestel en met die kanaalnaam gemerk.
- Wanneer 'n nuwe prent in die register verskyn, word Addon-operateur herbegin en begin met die nuwe prent.
Dit is nie die beste praktyk, soos geskryf in . Dit word nie aanbeveel om dit te doen nie, maar ons praat oor 'n gereelde toepassing wat in dieselfde groep woon. In die geval van Addon-operateur, is 'n toepassing baie Ontplooiings wat oor groepe versprei is, en selfopdatering help baie en maak die lewe makliker.
Kanale help en in toetsing: as daar 'n hulpkluster is, kan jy dit op die kanaal instel stage en rol opdaterings daarin voordat dit na kanale uitgerol word ea и stable. As met 'n cluster op die kanaal ea 'n fout voorgekom het, kan jy dit oorskakel na stable, terwyl die probleem met hierdie cluster ondersoek word. As die groep uit aktiewe ondersteuning gehaal word, skakel dit oor na sy "bevrore" kanaal - bv. freeze-2019-03-20.
Benewens die opdatering van hake en Helm-kaarte, sal jy dalk nodig hê opdatering en derdeparty-komponent. Byvoorbeeld, jy het 'n fout in die voorwaardelike node-uitvoerder opgemerk en selfs uitgevind hoe om dit reg te maak. Vervolgens het jy die PR oopgemaak en wag vir die nuwe weergawe om deur al die groepe te gaan en die weergawe van die beeld te vergroot. Om nie onbepaald te wag nie, kan jy jou node-uitvoerder bou en daarna oorskakel voordat jy die PR aanvaar.
Oor die algemeen kan dit sonder Addon-operateur gedoen word, maar met Addon-operateur sal die module vir die installering van node-exporter in een bewaarplek sigbaar wees, die Dockerfile vir die bou van jou prent kan net daar gehou word, dit word makliker vir alle deelnemers in die proses om te verstaan wat gebeur ... En as daar verskeie clusters is, dan word dit makliker om jou PR te toets en 'n nuwe weergawe te ontplooi!
Hierdie organisasie van komponent-opdatering werk suksesvol vir ons, maar enige ander geskikte skema kan geïmplementeer word - immers in hierdie geval is Addon-operateur 'n eenvoudige binêre lêer.
Gevolgtrekking
Die beginsels wat in Addon-operateur geïmplementeer is, laat jou toe om 'n deursigtige proses te bou vir die skep, toets, installering en opdatering van byvoegings in 'n groepering, soortgelyk aan die ontwikkelingsprosesse van gereelde toepassings.
Byvoegings vir Addon-operateur in module-formaat (Helmkaart + hake) kan publiek beskikbaar gestel word. Ons, die Flant-maatskappy, beplan om ons ontwikkelings in die vorm van sulke toevoegings gedurende die somer te publiseer. Sluit aan by ontwikkeling op GitHub (, ), probeer om jou eie toevoeging te maak gebaseer op и , wag vir nuus oor Habré en op ons !
PS
Lees ook op ons blog:
- «»;
- «".
Bron: will.com