Jälkeen esittelemme hänen vanhemman veljensä - . Tämä on avoimen lähdekoodin projekti, jota käytetään järjestelmäkomponenttien asentamiseen Kubernetes-klusteriin, joita voidaan kutsua lisäosiksi.
Miksi ylipäätään lisäyksiä?
Ei ole mikään salaisuus, että Kubernetes ei ole valmis all-in-one-tuote, ja "aikuisten" klusterin rakentamiseen tarvitset erilaisia lisäyksiä. Addon-operator auttaa sinua asentamaan, määrittämään ja pitämään nämä lisäosat ajan tasalla.
Lisäkomponenttien tarve klusterissa on kuvattu kohdassa työtovereiden . Lyhyesti sanottuna Kubernetesin tilanne on tällä hetkellä sellainen, että yksinkertaiseen ”pelaamiseen” asennukseen pärjää komponenteilla pois paketista, kehittäjille ja testaukselle voi lisätä Ingressin, mutta täysasennukseen, josta noin voit sanoa "tuotantosi on valmis", sinun on lisättävä kymmenillä eri lisäosilla: jotain seurantaa varten, jotain lokiin, älä unohda sisääntuloa ja varmenteiden hallintaa, valitse solmuryhmät, lisää verkkokäytäntöjä, kausi sysctl ja pod autoscaler -asetuksissa...
Mitkä ovat heidän kanssaan työskentelyn erityispiirteet?
Kuten käytäntö osoittaa, asia ei rajoitu yhteen asennukseen. Jotta voit työskennellä mukavasti klusterin kanssa, lisäosat on päivitettävä, poistettava käytöstä (poistettava klusterista), ja niitä on testattava ennen niiden asentamista tuotantoklusteriin.
Joten ehkä Ansible riittää tähän? Voi olla. Mutta Yleensä täysimittaiset lisäosat eivät elä ilman asetuksia. Nämä asetukset voivat vaihdella klusteriversion mukaan (aws, gce, azure, bare-metal, do, ...). Joitakin asetuksia ei voi määrittää etukäteen, vaan ne on hankittava klusterista. Ja klusteri ei ole staattinen: joidenkin asetusten muutoksia on seurattava. Ja tästä Ansible puuttuu jo: tarvitset ohjelman, joka elää klusterissa, ts. Kubernetes-operaattori.
Ne, jotka kokeilivat sitä töissä , he sanovat, että lisäosien asennus- ja päivitystehtävät sekä valvonta-asetukset voidaan ratkaista täysin käyttämällä shell-operaattorille. Voit kirjoittaa skriptin, joka tekee ehdollisen kubectl apply ja valvoa esimerkiksi ConfigMapia, johon asetukset tallennetaan. Tämä on suunnilleen sama, joka on toteutettu addon-operatorissa.
Miten tämä on järjestetty addon-operaattorissa?
Uutta ratkaisua luodessaan noudatimme seuraavia periaatteita:
- Lisäosien asennusohjelman on tuettava malli ja deklaratiivinen kokoonpano. Emme tee taikaskriptejä, jotka asentavat lisäosia. Addon-operator käyttää Helmiä lisäosien asentamiseen. Asentaaksesi sinun on luotava kaavio ja valittava arvot, joita käytetään määritykseen.
- Asetukset voivat olla luoda asennuksen yhteydessä, ne voivat olla saada klusteristaTai saada päivityksiä, seuraa klusterin resursseja. Nämä toiminnot voidaan toteuttaa koukkujen avulla.
- Asetukset voivat olla varastoida klusteriin. Asetusten tallentamiseksi klusteriin luodaan ConfigMap/addon-operaattori ja Addon-operaattori tarkkailee tämän ConfigMapin muutoksia. Addon-operaattori antaa koukkuille pääsyn asetuksiin yksinkertaisten käytäntöjen avulla.
- Lisäys riippuu asetuksista. Jos asetukset ovat muuttuneet, Addon-operaattori rullaa ruorikaavion uusilla arvoilla. Kutsuimme Helm-kaavion, sen arvojen ja koukkujen yhdistelmää moduuliksi (katso lisätietoja alta).
- Lavastus. Taikajulkaisuskriptejä ei ole. Päivitysmekanismi on samanlainen kuin tavallinen sovellus - kerää lisäosat ja lisäosien operaattorit kuvaksi, merkitse ne ja julkaise ne.
- Tulosten valvonta. Addon-operaattori voi tarjota mittareita Prometheukselle.
Mitä on täyttö addon-operaattorissa?
Lisäyksenä voidaan pitää mitä tahansa, mikä lisää klusteriin uusia toimintoja. Esimerkiksi Ingressin asentaminen on loistava esimerkki lisäosasta. Tämä voi olla mikä tahansa operaattori tai ohjain, jolla on oma CRD:nsä: prometheus-operaattori, varmenteiden hallinta, kube-ohjain-manager jne. Tai jotain pientä, mutta helpompi käyttää - esimerkiksi salainen kopiokone, joka kopioi rekisterisalaisuudet uusiin nimiavaruuksiin, tai sysctl-viritin, joka määrittää sysctl-parametrit uusiin solmuihin.
Lisäosien toteuttamiseksi Addon-operator tarjoaa useita konsepteja:
- Ruorikaavio käytetään erilaisten ohjelmistojen asentamiseen klusteriin - esimerkiksi Prometheus, Grafana, nginx-ingress. Jos tarvittavalla komponentilla on ruorikaavio, sen asentaminen Addon-operaattorilla on hyvin yksinkertaista.
- Arvojen tallennus. Ruorikaavioissa on yleensä monia erilaisia asetuksia, jotka voivat muuttua ajan myötä. Addon-operator tukee näiden asetusten tallentamista ja voi seurata niiden muutoksia asentaakseen Helm-kaavion uudelleen uusilla arvoilla.
- Koukut ovat suoritettavia tiedostoja, joita Addon-operaattori suorittaa tapahtumissa ja jotka pääsevät arvovarastoihin. Koukku voi seurata muutoksia klusterissa ja päivittää arvoja arvovarastossa. Nuo. Koukkujen avulla voit tehdä löydön kerätäksesi arvoja klusterista käynnistyksen yhteydessä tai aikataulun mukaan, tai voit tehdä jatkuvan etsinnän, joka kerää arvoja klusterista klusterin muutosten perusteella.
- Moduuli on yhdistelmä Helm-kaaviosta, arvovarastosta ja koukuista. Moduulit voidaan ottaa käyttöön tai poistaa käytöstä. Moduulin poistaminen käytöstä tarkoittaa kaikkien Helm-kaavion julkaisujen poistamista. Moduulit voivat ottaa itsensä käyttöön dynaamisesti, jos esimerkiksi kaikki tarvitsemansa moduulit ovat käytössä tai jos Discovery on löytänyt tarvittavat parametrit koukuista - tämä tehdään apukäyttöisellä komentosarjalla.
- Globaalit koukut. Nämä ovat koukkuja "itsekseen", ne eivät sisälly moduuleihin ja niillä on pääsy globaaliin arvosäilöön, jonka arvot ovat kaikkien moduulien koukkujen käytettävissä.
Miten nämä osat toimivat yhdessä? Katsotaanpa kuvaa dokumentaatiosta:
Työskenaarioita on kaksi:
- Globaali koukku laukaisee tapahtuma - esimerkiksi kun klusterin resurssi muuttuu. Tämä koukku käsittelee muutokset ja kirjoittaa uudet arvot globaaliin arvosäilöön. Addon-operator huomaa, että globaali tallennustila on muuttunut ja käynnistää kaikki moduulit. Jokainen moduuli määrittää koukkujensa avulla, onko se otettava käyttöön, ja päivittää arvovarastonsa. Jos moduuli on käytössä, Addon-operaattori aloittaa ruorikaavion asennuksen. Tässä tapauksessa Helm-kaaviolla on pääsy arvoihin moduulin tallennustilasta ja globaalista tallennustilasta.
- Toinen skenaario on yksinkertaisempi: moduulin koukku laukeaa tapahtumasta ja muuttaa arvoja moduulin arvovarastossa. Addon-operaattori huomaa tämän ja käynnistää ruorikaavion päivitetyillä arvoilla.
Lisäys voidaan toteuttaa yhtenä koukuna tai yhtenä Helm-kaaviona tai jopa useana riippuvaisena moduulina - Tämä riippuu klusteriin asennettavan komponentin monimutkaisuudesta ja halutusta konfiguroinnin joustavuuden tasosta. Esimerkiksi arkistossa () on sysctl-tuner-lisäosa, joka on toteutettu sekä yksinkertaisena moduulina, jossa on koukku ja Helm-kaavio, että käyttämällä arvovarastoa, joka mahdollistaa asetusten lisäämisen ConfigMapia muokkaamalla.
Päivitysten toimitus
Muutama sana Addon-operatorin asentamien komponenttipäivitysten järjestämisestä.
Tarvitset Addon-operaattorin suorittamiseen klusterissa rakentaa kuva lisäyksellä koukku- ja Helm-kaaviotiedostojen muodossa, lisää binääritiedosto addon-operator ja kaikki mitä tarvitset koukkuihin: bash, kubectl, jq, python jne. Sitten tämä kuva voidaan levittää klusteriin tavallisena sovelluksena, ja todennäköisesti haluat järjestää yhden tai toisen merkintäjärjestelmän. Jos klustereita on vähän, sama lähestymistapa kuin sovelluksissa voi olla sopiva: uusi julkaisu, uusi versio, siirry kaikkiin klustereihin ja korjaa Pods-kuva. Kuitenkin, kun kyseessä oli käyttöönotto merkittävään määrään klustereita, itsepäivityksen konsepti kanavasta oli meille sopivampi.
Teemme sen seuraavasti:
- Kanava on pohjimmiltaan tunniste, joka voidaan asettaa mihin tahansa (esimerkiksi dev/stage/ea/stable).
- Kanavan nimi on kuvan tunniste. Kun sinun on julkaistava päivitykset kanavalle, uusi kuva kootaan ja merkitään kanavan nimellä.
- Kun uusi kuva ilmestyy rekisteriin, Addon-operator käynnistetään uudelleen ja käynnistetään uudella kuvalla.
Tämä ei ole paras käytäntö, kuten on kirjoitettu . Tätä ei suositella, mutta puhumme siitä tavallinen sovellus, joka asuu samassa klusterissa. Addon-operatorin tapauksessa sovellus on paljon käyttöönottoja hajallaan klustereille, ja itsepäivitys auttaa paljon ja helpottaa elämää.
Kanavat auttavat ja testauksessa: jos apuklusteri on olemassa, voit määrittää sen kanavalle stage ja julkaise siihen päivitykset ennen sen julkaisemista kanaville ea и stable. Jos kanavalla on klusteri ea tapahtui virhe, voit vaihtaa siihen stable, kun tämän klusterin ongelmaa tutkitaan. Jos klusteri poistetaan aktiivisesta tuesta, se vaihtaa "jäädytettyyn" kanavaansa - esim. freeze-2019-03-20.
Koukkujen ja Helm-kaavioiden päivittämisen lisäksi saatat tarvita päivitys ja kolmannen osapuolen komponentti. Esimerkiksi, olet huomannut vian ehdollisen solmun viejässä ja jopa keksinyt kuinka korjata se. Seuraavaksi avasit PR:n ja odotat, että uusi julkaisu käy läpi kaikki klusterit ja lisää kuvan versiota. Jotta et joutuisi odottamaan loputtomasti, voit rakentaa solmuviejäsi ja vaihtaa siihen ennen PR:n hyväksymistä.
Yleensä tämä voidaan tehdä ilman Addon-operaattoria, mutta Addon-operatorilla node-exporterin asennusmoduuli näkyy yhdessä arkistossa, kuvan rakentamiseen tarkoitettu Docker-tiedosto voidaan säilyttää siellä, se helpottuu kaikille osallistujille. prosessi ymmärtää, mitä tapahtuu... Ja jos klustereita on useita, niin PR:n testaaminen ja uuden version julkaiseminen on helpompaa!
Tämä komponenttien päivityksen organisointi toimii meillä onnistuneesti, mutta mikä tahansa muu sopiva suunnitelma voidaan toteuttaa - loppujen lopuksi tässä tapauksessa Addon-operaattori on yksinkertainen binääritiedosto.
Johtopäätös
Addon-operatorissa toteutettujen periaatteiden avulla voit rakentaa läpinäkyvän prosessin lisäosien luomiseen, testaamiseen, asentamiseen ja päivittämiseen klusterissa, kuten tavallisten sovellusten kehitysprosessit.
Addon-operaattorin lisäosat moduulimuodossa (Helm chart + koukut) voidaan asettaa julkisesti saataville. Me Flant-yhtiö aiomme julkaista kehitystyömme tällaisten lisäysten muodossa kesän aikana. Liity kehittämiseen GitHubissa (, ), yritä tehdä oma lisäyksesi perusteella и , odota uutisia Habresta ja meidän !
PS.
Lue myös blogistamme:
- «";
- «'.
Lähde: will.com