🥇Helm-laite ja sen sudenkuopat

Typhon-rahtikuljetuskonsepti, Anton Swanepoel

Nimeni on Dmitry Sugrobov, olen Leroy Merlinin kehittäjä. Tässä artikkelissa kerron, miksi Helmiä tarvitaan, kuinka se yksinkertaistaa Kubernetesin kanssa työskentelyä, mikä on muuttunut kolmannessa versiossa ja kuinka sen avulla päivitetään sovelluksia tuotannossa ilman seisokkeja.

Tämä on yhteenveto, joka perustuu konferenssissa pidettyyn puheeseen @Kubernetes-konferenssi by Mail.ru Pilviratkaisut - Jos et halua lukea, katso video.

Miksi käytämme Kubernetesia tuotannossa

Leroy Merlin on johtava tee-se-itse-kaupan markkinoilla Venäjällä ja Euroopassa. Yrityksellämme on yli sata kehittäjää, 33 000 sisäistä työntekijää sekä valtava määrä hypermarketeissa ja verkkosivuilla vierailevia ihmisiä. Jotta he kaikki olisivat onnellisia, päätimme noudattaa alan standardilähestymistapoja. Uusien sovellusten kehittäminen mikropalveluarkkitehtuurilla; käytä säiliöitä ympäristön eristämiseen ja asianmukaisen toimituksen varmistamiseksi; ja käytä Kubernetesia orkestrointiin. Orkesterien käytön hinta halpenee nopeasti: teknologiaan perehtyneiden insinöörien määrä kasvaa markkinoilla, ja Kubernetesia palveluna ilmaantuu tarjoajia.

Kaiken, mitä Kubernetes tekee, voidaan tietysti tehdä muillakin tavoilla, esimerkiksi peittämällä joitain Jenkinsejä ja docker-sävellyksiä skripteillä, mutta miksi monimutkaistaa elämää, jos siihen on valmis ja luotettava ratkaisu? Siksi tulimme Kubernetesiin ja olemme käyttäneet sitä tuotannossa nyt vuoden. Meillä on tällä hetkellä kaksikymmentäneljä Kubernetes-klusteria, joista vanhin on yli vuoden vanha ja niissä on noin kaksisataa palkoa.

Kubernetesin suurten YAML-tiedostojen kirous

Mikropalvelun käynnistämiseksi Kubernetesissa luomme vähintään viisi YAML-tiedostoa: Deployment, Service, Ingress, ConfigMap, Secrets - ja lähetämme ne klusteriin. Seuraavaa sovellusta varten kirjoitamme saman jamb-paketin, kolmannen kanssa kirjoitamme toisen ja niin edelleen. Jos kerromme dokumenttien määrän ympäristöjen määrällä, saamme jo satoja tiedostoja, eikä tässä vielä oteta huomioon dynaamisia ympäristöjä.

Adam Reese, Helmin ydinylläpitäjä, esitteli käsitteen "Kehityssykli Kubernetesissa", joka näyttää tältä:

Kopioi YAML - kopioi YAML-tiedosto.
Liitä YAML - liitä se.
Korjaa sisennykset - korjaa sisennykset.
Toista - toista uudelleen.

Vaihtoehto toimii, mutta sinun on kopioitava YAML-tiedostot monta kertaa. Tämän syklin muuttamiseksi keksittiin Helm.

Mikä on Helm

Ensinnäkin Helm - paketin hallinta, joka auttaa sinua löytämään ja asentamaan tarvitsemasi ohjelmat. Jos haluat asentaa esimerkiksi MongoDB:n, sinun ei tarvitse mennä viralliselle verkkosivustolle ja ladata binaaritiedostoja, vain suorita komento helm install stable/mongodb.

Toiseksi, Helm - mallin moottori, auttaa tiedostojen parametroinnissa. Palataan tilanteeseen Kubernetesin YAML-tiedostojen kanssa. On helpompi kirjoittaa sama YAML-tiedosto, lisätä siihen paikkamerkkejä, joihin Helm korvaa arvot. Eli suuren telinesarjan sijasta tulee joukko malleja, joihin vaaditut arvot korvataan oikeaan aikaan.

Kolmanneksi Helm - käyttöönottomestari. Sen avulla voit asentaa, palauttaa ja päivittää sovelluksia. Selvitetään, miten tämä tehdään.

Kuinka käyttää Helmiä omien sovellusten käyttöönottoon

Asennamme Helm-asiakasohjelman tietokoneellesi virallisten ohjeiden mukaan ohjeet. Seuraavaksi luomme joukon YAML-tiedostoja. Tiettyjen arvojen määrittämisen sijaan jätämme paikkamerkit, jotka Helm täyttää tiedoilla tulevaisuudessa. Joukkoa tällaisia tiedostoja kutsutaan Helm chartiksi. Se voidaan lähettää Helm-konsoliasiakkaalle kolmella tavalla:

osoita kansio, jossa on malleja;
pakkaa arkisto .tar-tiedostoon ja osoita sitä;
laita malli etävarastoon ja lisää linkki arkistoon Helm-asiakassovelluksessa.

Tarvitset myös tiedoston arvoilla - Values.yaml. Sieltä saadut tiedot lisätään malliin. Luodaan sekin.

Helmin toisessa versiossa on ylimääräinen palvelinsovellus - Tiller. Se roikkuu Kubernetesin ulkopuolella ja odottaa pyyntöjä Helm-asiakkaalta, ja kun sitä kutsutaan, se korvaa vaaditut arvot malliin ja lähettää sen Kubernetesiin.

Helm 3 on yksinkertaisempi: palvelimella olevien mallien käsittelyn sijaan tiedot käsitellään nyt kokonaan Helm-asiakaspuolella ja lähetetään suoraan Kubernetes API:lle. Tämä yksinkertaistaminen parantaa klusterin turvallisuutta ja helpottaa käyttöönottoa.

Miten se kaikki toimii

Suorita komento helm install. Ilmoitetaan sovelluksen julkaisun nimi ja annetaan polku arvoihin.yaml. Lopussa ilmoitamme arkiston, jossa kaavio sijaitsee, ja kaavion nimen. Esimerkissä nämä ovat "lmru" ja "bestchart".

helm install --name bestapp --values values.yaml lmru/bestchart

Komento voidaan suorittaa vain kerran, kun se suoritetaan uudelleen install tarvitse käyttää upgrade. Yksinkertaisuuden vuoksi voit suorittaa komennon kahden komennon sijasta upgrade lisäavaimella --install. Kun Helm suoritetaan ensimmäisen kerran, se lähettää komennon julkaisun asentamiseksi ja päivittää sen tulevaisuudessa.

helm upgrade --install bestapp --values values.yaml lmru/bestchart

Sovelluksen uusien versioiden käyttöönoton sudenkuopat Helmin kanssa

Tarinan tässä vaiheessa pelaan yleisön kanssa Who Wants to Be a Millionaire -peliä, ja mietimme, kuinka saada Helm päivittämään sovelluksen version. Katso video.

Kun opin Helmin toimintaa, yllätyin oudosta käytöksestä, kun yritin päivittää käynnissä olevien sovellusten versioita. Päivitin sovelluskoodin, lähetin uuden kuvan Docker-rekisteriin, lähetin käyttöönottokomennon - eikä mitään tapahtunut. Alla on joitain ei täysin onnistuneita tapoja päivittää sovelluksia. Tutkimalla kutakin niistä yksityiskohtaisemmin alat ymmärtää instrumentin sisäistä rakennetta ja syitä tähän ei ilmeiseen käyttäytymiseen.

Tapa 1. Älä muuta tietoja edellisen käynnistyksen jälkeen

Kuten se sanoo viralliset kotisivut Helm: "Kubernetes-kaaviot voivat olla suuria ja monimutkaisia, joten Helm yrittää olla koskematta mihinkään liikaa." Siksi, jos päivität sovelluskuvan uusimman version Docker-rekisterissä ja suoritat komennon helm upgrade, silloin ei tapahdu mitään. Helm ajattelee, että mikään ei ole muuttunut, eikä Kubernetesille tarvitse lähettää komentoa sovelluksen päivittämiseksi.

Tässä ja alla uusin tunniste näytetään vain esimerkkinä. Kun määrität tämän tunnisteen, Kubernetes lataa kuvan Docker-rekisteristä joka kerta riippumatta imagePullPolicy-parametrista. Uusimman tuotannon käyttäminen ei ole toivottavaa ja aiheuttaa sivuvaikutuksia.

Tapa 2. Päivitä kuvan LABEL

Kuten samassa kirjoitettuna dokumentointi, "Helm päivittää sovelluksen vain, jos se on muuttunut edellisen julkaisun jälkeen." Looginen vaihtoehto tälle näyttäisi olevan LABEL:n päivittäminen itse Docker-kuvassa. Helm ei kuitenkaan tutki sovelluskuvia, eikä hänellä ole aavistustakaan niihin tehdyistä muutoksista. Näin ollen, kun päivität kuvan tarroja, Helm ei tiedä niistä, eikä sovelluksen päivityskomentoa lähetetä Kubernetesille.

Tapa 3: Käytä avainta --force

Käännytään käsikirjoihin ja etsitään tarvittava avain. Avain on järkevin --force. Ilmeisestä nimestä huolimatta käyttäytyminen on erilaista kuin odotettiin. Sovelluksen päivityksen pakottamisen sijaan sen todellinen tarkoitus on palauttaa julkaisu, joka on FAILED-tilassa. Jos et käytä tätä näppäintä, sinun on suoritettava komennot peräkkäin helm delete && helm install --replace. Sen sijaan on suositeltavaa käyttää avainta --force, joka automatisoi näiden komentojen peräkkäisen suorittamisen. Lisätietoja tästä vedä pyyntö. Tämä avain ei valitettavasti toimi, jotta Helmiä pyydetään päivittämään sovellusversio.

Tapa 4. Muuta tunnisteita suoraan Kubernetesissa

Tarran päivittäminen suoraan klusteriin komennolla kubectl edit - huono idea. Tämä toiminto johtaa epäjohdonmukaisuuteen käynnissä olevan sovelluksen ja alunperin käyttöönotettavan sovelluksen välillä. Helmin käyttäytyminen käyttöönoton aikana tässä tapauksessa eroaa sen versiosta: Helm 2 ei tee mitään, ja Helm 3 ottaa käyttöön sovelluksen uuden version. Ymmärtääksesi miksi, sinun on ymmärrettävä, kuinka Helm toimii.

Miten Helm toimii?

Selvittääkseen, onko sovellus muuttunut edellisen julkaisunsa jälkeen, Helm voi käyttää:

käynnissä oleva sovellus Kubernetesissa;
uudet arvot.yaml ja nykyinen kaavio;
Helmin sisäiset julkaisutiedot.

Uteliaisille: missä Helm säilyttää sisäiset tiedot julkaisuista?Suorittamalla komennon helm history, saamme kaikki tiedot Helmin avulla asennetuista versioista.

Siellä on myös yksityiskohtaista tietoa lähetetyistä malleista ja arvoista. Voimme pyytää sitä:

Helmin toisessa versiossa nämä tiedot sijaitsevat samassa nimiavaruudessa, jossa Tiller toimii (oletuksena kube-järjestelmä), ConfigMapissa, joka on merkitty tunnisteella "OWNER=TILLER":

Kun Helmin kolmas versio ilmestyi, tiedot siirtyivät salaisuuksiin ja samaan nimiavaruuteen, jossa sovellus oli käynnissä. Tämän ansiosta tuli mahdolliseksi ajaa useita sovelluksia samanaikaisesti eri nimiavaroissa samalla julkaisunimellä. Toisessa versiossa oli vakava päänsärky, kun nimiavaruudet ovat eristettyjä, mutta voivat vaikuttaa toisiinsa.

Toinen Helm, joka yrittää ymmärtää, tarvitaanko päivitystä, käyttää vain kahta tietolähdettä: sille nyt tarjottua tietoa ja sisäisiä julkaisuja koskevia tietoja, jotka ovat ConfigMapissa.

Kolmas Helm käyttää kolmisuuntaista yhdistämisstrategiaa: se ottaa näiden tietojen lisäksi huomioon myös Kubernetesissa tällä hetkellä käynnissä olevan sovelluksen.

Tästä syystä Helmin vanha versio ei tee mitään, koska se ei ota huomioon klusterin sovellustietoja, mutta Helm 3 vastaanottaa muutokset ja lähettää uuden sovelluksen käyttöön.

Tapa 5. Käytä --recreate-pods-kytkintä

Avaimella --recreate-pods voit saavuttaa sen, mitä alun perin suunnittelit saavuttavasi avaimella --force. Säilöt käynnistyvät uudelleen ja Kubernetes lataa ja käynnistää kuvan uuden version imagePullPolicy: Always -käytännön mukaisesti uusimman tagin (lisätietoja yllä olevassa alaviitteessä). Tämä ei tapahdu parhaalla tavalla: ottamatta huomioon StrategyType käyttöönottoa, se sammuttaa äkillisesti kaikki vanhat sovellusesiintymät ja alkaa käynnistää uusia. Uudelleenkäynnistyksen aikana järjestelmä ei toimi, käyttäjät kärsivät.

Myös itse Kubernetesissa samanlainen ongelma oli olemassa pitkään. Ja nyt, 4 vuotta avaamisen jälkeen Kysymys, ongelma on korjattu, ja Kubernetesin versiosta 1.15 alkaen näyttöön tulee mahdollisuus käynnistää podit rullalla uudelleen.

Helm yksinkertaisesti sammuttaa kaikki sovellukset ja käynnistää uudet kontit lähellä. Et voi tehdä tätä tuotannossa, jotta se ei aiheuta sovellusten seisokkeja. Tätä tarvitaan vain kehitystarpeisiin ja se voidaan suorittaa vain näyttämöympäristöissä.

Kuinka päivittää sovellusversio Helmin avulla?

Muutamme Helmille lähetettyjä arvoja. Tyypillisesti nämä ovat arvoja, jotka korvataan kuvatunnisteen tilalla. Usein tuottamattomissa ympäristöissä käytetyn uusimman tapauksessa muuttuva tieto on merkintä, joka on Kubernetesille itselle hyödytön ja Helmille se toimii signaalina sovelluksen päivittämisen tarpeesta. Annotaatioarvon täyttövaihtoehdot:

Satunnainen arvo käyttämällä vakiotoimintoa - {{ randAlphaNum 6 }}.
On varoitus: jokaisen käyttöönoton jälkeen, kun käytetään kaaviota, jossa on tällainen muuttuja, huomautuksen arvo on yksilöllinen, ja Helm olettaa, että muutoksia on tapahtunut. Osoittautuu, että käynnistämme sovelluksen aina uudelleen, vaikka emme olisi muuttaneet sen versiota. Tämä ei ole kriittinen, koska seisokkeja ei tule, mutta se on silti epämiellyttävää.
Liitä virta päivämäärä ja aika - {{ .Release.Date }}.
Variantti on samanlainen kuin satunnaisarvo, jossa on pysyvästi yksilöllinen muuttuja.
Oikeampi tapa on käyttää tarkistussummat. Tämä on kuvan SHA tai gitin viimeisen sitoumuksen SHA - {{ .Values.sha }}.
Ne on laskettava ja lähetettävä kutsuvan puolen Helm-asiakkaalle, esimerkiksi Jenkinsiin. Jos sovellus on muuttunut, tarkistussumma muuttuu. Siksi Helm päivittää sovelluksen vain tarvittaessa.

Tehdään yhteenveto yrityksistämme

Helm tekee muutoksia vähiten invasiivisella tavalla, joten Docker-rekisterin sovelluksen kuvatason muutokset eivät johda päivitykseen: mitään ei tapahdu komennon suorittamisen jälkeen.
avain --force käytetään ongelmallisten julkaisujen palauttamiseen, eikä sitä liitetä pakkopäivityksiin.
avain --recreate-pods päivittää sovelluksia väkisin, mutta tekee sen ilkivallalla: se sammuttaa äkillisesti kaikki säiliöt. Käyttäjät kärsivät tästä; sinun ei pitäisi tehdä tätä tuotannossa.
Tee muutokset suoraan Kubernetes-klusteriin komennolla kubectl edit älä: rikomme johdonmukaisuuden, ja käyttäytyminen vaihtelee Helmin versiosta riippuen.
Helmin uuden version julkaisun myötä on ilmestynyt monia vivahteita. Helm-arkiston ongelmat on kuvattu selkeällä kielellä, ne auttavat sinua ymmärtämään yksityiskohtia.
Muokattavan huomautuksen lisääminen kaavioon tekee siitä joustavamman. Näin voit ottaa sovelluksen käyttöön oikein ilman seisokkeja.

"Maailmanrauhan" ajatus, joka toimii kaikilla elämän alueilla: lue ohjeet ennen käyttöä, älä sen jälkeen. Vain täydellisillä tiedoilla on mahdollista rakentaa luotettavia järjestelmiä ja ilahduttaa käyttäjiä.

Muita aiheeseen liittyviä linkkejä:

Tämä raportti esiteltiin ensimmäisen kerran klo @Kubernetes-konferenssi kirjoittanut Mail.ru Cloud Solutions. Katso video muita esityksiä ja tilaa tapahtumatiedotteet Telegramissa Kubernetesin ympärillä Mail.ru Groupissa.

Lähde: will.com

Helm-laite ja sen sudenkuopat