Helmin turvallisuus

Tarinan ydin Kubernetesin suosituimmasta paketinhallinnasta voidaan kuvata hymiöllä:

• laatikko on Helm (joka on lähimpänä viimeisintä Emoji-julkaisua);
• lukko - turvallisuus;
• pieni ihminen on ratkaisu ongelmaan.

Itse asiassa kaikki on hieman monimutkaisempaa, ja tarina on täynnä teknisiä yksityiskohtia Kuinka tehdä Helmistä turvallinen.

• Lyhyesti, mikä Helm on, jos et tiennyt tai unohtanut. Mitä ongelmia se ratkaisee ja missä se sijaitsee ekosysteemissä.
• Katsotaanpa Helmin arkkitehtuuria. Keskustelu turvallisuudesta ja työkalun tai ratkaisun turvallisuuden parantamisesta ei ole täydellinen ilman komponentin arkkitehtuuria.
• Keskustellaan Helmin komponenteista.
• Polttavin kysymys on tulevaisuus – Helm 3:n uusi versio. 

Kaikki tämän artikkelin sisältö koskee Helm 2:ta. Tämä versio on tällä hetkellä tuotannossa ja on todennäköisesti tällä hetkellä käyttämäsi versio, joka sisältää tietoturvariskit.

Tietoja kaiuttimesta: Aleksanteri Khajorov (allexx) on kehittänyt 10 vuotta ja auttaa parantamaan sisältöä Moskovan Python Conf++ ja liittyi komiteaan Helmin huippukokous. Nyt hän työskentelee Chainstackissa kehitysjohtajana – tämä on hybridi kehityspäällikön ja lopullisten julkaisujen toimittamisesta vastaavan henkilön välillä. Eli se sijaitsee taistelukentällä, jossa kaikkea tapahtuu tuotteen luomisesta sen toimintaan.

Chainstack on pieni, aktiivisesti kasvava startup, jonka tehtävänä on antaa asiakkaille mahdollisuus unohtaa hajautettujen sovellusten operoinnin infrastruktuuri ja monimutkaisuus; kehitystiimi sijaitsee Singaporessa. Älä pyydä Chainstackia myymään tai ostamaan kryptovaluuttoja, vaan tarjoudu keskustelemaan yrityksen lohkoketjun kehyksistä, niin he vastaavat sinulle mielellään.

Ruori

Tämä on Kubernetesin paketin (kaavion) ​​hallinta. Intuitiivisin ja yleismaailmallisin tapa tuoda sovelluksia Kubernetes-klusteriin.

Puhumme tietysti rakenteellisemmasta ja teollisemmasta lähestymistavasta kuin omien YAML-luetteloiden luomisesta ja pienten apuohjelmien kirjoittamisesta.

Helm on paras tällä hetkellä saatavilla oleva ja suosittu.

Miksi Helm? Ensisijaisesti siksi, että CNCF tukee sitä. Cloud Native on suuri organisaatio ja emoyhtiö projekteille Kubernetes, etcd, Fluentd ja muut.

Toinen tärkeä tosiasia on, että Helm on erittäin suosittu projekti. Kun aloin puhua Helmin turvaamisesta tammikuussa 2019, projektilla oli tuhat tähteä GitHubissa. Toukokuuhun mennessä heitä oli 12 tuhatta.

Monet ihmiset ovat kiinnostuneita Helmistä, joten vaikka et käyttäisi sitä vielä, sinun on hyödyllistä tietää sen turvallisuudesta. Turvallisuus on tärkeää.

Microsoft Azure tukee Helmin ydintiimiä, joten se on melko vakaa projekti, toisin kuin monet muut. Helm 3 Alpha 2:n julkaisu heinäkuun puolivälissä osoittaa, että projektin parissa työskentelee melko paljon ihmisiä ja heillä on halua ja energiaa kehittää ja parantaa Helmiä.

Helm ratkaisee useita Kubernetesin sovellustenhallinnan perusongelmia.

• Sovelluksen pakkaus. Jopa "Hello, World" -sovellus WordPressissä koostuu jo useista palveluista, ja haluat pakata ne yhteen.
• Näiden sovellusten hallinnan monimutkaisuuden hallinta.
• Elinkaari, joka ei pääty sovelluksen asentamisen tai käyttöönoton jälkeen. Se elää edelleen, sitä on päivitettävä, ja Helm auttaa tässä ja yrittää tuoda tähän oikeat toimenpiteet ja linjaukset.

Pussittaminen se on järjestetty selkeästi: metatiedot ovat täysin Linuxin, Windowsin tai MacOS:n tavallisen paketinhallinnan mukaisia. Eli arkisto, riippuvuudet erilaisista paketeista, sovellusten metatiedot, asetukset, konfigurointiominaisuudet, tiedon indeksointi jne. Helmin avulla voit hankkia ja käyttää kaikkea tätä sovelluksissa.

Monimutkaisuuden hallinta. Jos sinulla on useita samantyyppisiä sovelluksia, parametrointi on tarpeen. Mallit tulevat tästä, mutta jotta sinun ei tarvitse keksiä omaa tapaasi luoda malleja, voit käyttää Helmin tarjoamia valmiita tuotteita.

Sovelluksen elinkaaren hallinta - Tämä on mielestäni mielenkiintoisin ja ratkaisemattomin kysymys. Tästä syystä tulin Helmiin tuolloin. Meidän piti seurata sovelluksen elinkaarta ja halusimme siirtää CI/CD- ja sovellussyklimme tähän paradigmaan.

Helmin avulla voit:

• hallita käyttöönottoja, esittelee konfiguroinnin ja päivityksen käsitteen;
• suorittaa palautus onnistuneesti;
• käytä koukkuja erilaisiin tapahtumiin;
• lisää sovellustarkistuksia ja vastaa niiden tuloksiin.

Lisäksi Kypärässä on "paristot" - valtava määrä maukkaita asioita, jotka voidaan sisällyttää laajennusten muodossa, mikä yksinkertaistaa elämääsi. Pluginit voidaan kirjoittaa itsenäisesti, ne ovat melko eristettyjä eivätkä vaadi harmonista arkkitehtuuria. Jos haluat toteuttaa jotain, suosittelen tekemään sen liitännäisenä ja sitten mahdollisesti sisällyttämään sen alkuvirtaan.

Helm perustuu kolmeen pääkonseptiin:

• Kaavio Repo — luettelon mahdollisten parametrointien kuvaus ja joukko. 
• Config -eli arvot, joita käytetään (teksti, numeroarvot jne.).
• Vapauta kerää kaksi ylempää komponenttia ja yhdessä niistä tulee Release. Julkaisut voidaan versioida, jolloin saavutetaan organisoitu elinkaari: pieni asennuksen aikana ja suuri päivityksen, alemman version tai palautuksen aikana.

Helm-arkkitehtuuri

Kaavio kuvaa käsitteellisesti Helmin korkean tason arkkitehtuuria.

Haluan muistuttaa, että Helm liittyy Kubernetesiin. Siksi emme voi tehdä ilman Kubernetes-klusteria (suorakulmiota). Kube-apiserver-komponentti sijaitsee pääkoneessa. Ilman Helmiä meillä on Kubeconfig. Helm tuo yhden pienen binaarin, jos sitä niin voi kutsua, Helm CLI -apuohjelman, joka asennetaan tietokoneeseen, kannettavaan tietokoneeseen, keskuskoneeseen - mihin tahansa.

Mutta tämä ei riitä. Helmissä on palvelinkomponentti nimeltä Tiller. Se edustaa Helmin etuja klusterissa; se on Kubernetes-klusterin sovellus, kuten kaikki muutkin.

Chart Repon seuraava komponentti on kaavioiden arkisto. Yrityksellä tai projektilla on virallinen arkisto, ja siellä voi olla yksityinen arkisto.

Vuorovaikutus

Katsotaanpa, kuinka arkkitehtuurin komponentit toimivat vuorovaikutuksessa, kun haluamme asentaa sovelluksen Helmin avulla.

• Me puhumme Helm install, käytä arkistoa (Chart Repo) ja hanki ruorikaavio.

• Helm-apuohjelma (Helm CLI) on vuorovaikutuksessa Kubeconfigin kanssa selvittääkseen, mihin klusteriin ottaa yhteyttä. 
• Saatuaan nämä tiedot apuohjelma viittaa sovelluksena klusterissamme sijaitsevaan Tilleriin. 
• Tiller kutsuu Kube-apiserveria suorittaakseen toimintoja Kubernetesissa, luodakseen joitain objekteja (palveluita, podeja, replikoita, salaisuuksia jne.).

Seuraavaksi monimutkaistamme kaaviota nähdäksemme hyökkäysvektorin, jolle koko Helm-arkkitehtuuri kokonaisuudessaan voi altistua. Ja sitten yritämme suojella häntä.

Hyökkäysvektori

Ensimmäinen mahdollinen heikko kohta on etuoikeutettu API-käyttäjä. Osana järjestelmää tämä on hakkeri, joka on saanut järjestelmänvalvojan pääsyn Helm CLI:hen.

Etuoikeutettu API-käyttäjä voi myös aiheuttaa vaaraa, jos se on jossain lähellä. Tällaisella käyttäjällä on erilainen konteksti, esimerkiksi hän voidaan kiinnittää yhteen klusterin nimiavaruuteen Kubeconfig-asetuksissa.

Mielenkiintoisin hyökkäysvektori voi olla prosessi, joka sijaitsee klusterin sisällä jossain lähellä Tilleriä ja voi käyttää sitä. Tämä voi olla verkkopalvelin tai mikropalvelu, joka näkee klusterin verkkoympäristön.

Eksoottinen, mutta yhä suositumpi hyökkäysversio sisältää Chart Repo. Häikäilemättömän kirjoittajan luoma kaavio voi sisältää vaarallisia resursseja, ja täydennät sen ottamalla sen uskon varaan. Tai se voi korvata virallisesta arkistosta lataamasi kaavion ja esimerkiksi luoda resurssin käytäntöjen muodossa ja laajentaa sen käyttöä.

Yritetään torjua hyökkäykset kaikilta näiltä neljältä puolelta ja selvittää missä Helm-arkkitehtuurissa on ongelmia ja missä niitä ei ehkä ole.

Suurennetaan kaaviota, lisätään elementtejä, mutta säilytetään kaikki peruskomponentit.

Helm CLI kommunikoi Chart Repon kanssa, on vuorovaikutuksessa Kubeconfigin kanssa ja työ siirretään klusteriin Tiller-komponenttiin.

Tilleriä edustaa kaksi objektia:

• Tiller-deploy svc, joka paljastaa tietyn palvelun;
• Tiller-deploy pod (kaaviossa yhtenä kopiona yhdessä replikassa), jolla suoritetaan koko kuorma, joka käyttää klusteria.

Vuorovaikutukseen käytetään erilaisia ​​protokollia ja järjestelmiä. Turvallisuuden näkökulmasta meitä kiinnostavat eniten:

• Mekanismi, jolla Helm CLI käyttää kaavion repoa: mikä protokolla, onko todennus olemassa ja mitä sillä voidaan tehdä.
• Protokolla, jolla Helm CLI kommunikoi kubectlin avulla Tilleriin. Tämä on RPC-palvelin, joka on asennettu klusterin sisään.
• Tiller itsessään on käytettävissä mikropalveluille, jotka sijaitsevat klusterissa ja ovat vuorovaikutuksessa Kube-apiserverin kanssa.

Keskustellaan kaikista näistä alueista järjestyksessä.

RBAC

Helmin tai muiden klusterin palveluiden turvallisuudesta on turha puhua, ellei RBAC ole käytössä.

Näyttää siltä, ​​​​että tämä ei ole uusin suositus, mutta olen varma, että monet ihmiset eivät ole vieläkään ottaneet RBAC:ia käyttöön edes tuotannossa, koska se on paljon meteliä ja paljon asioita pitää konfiguroida. Kannustan sinua kuitenkin tekemään tämän.

https://rbac.dev/ — RBAC:n verkkosivustolakimies. Se sisältää valtavan määrän mielenkiintoisia materiaaleja, jotka auttavat sinua määrittämään RBAC:n, osoittavat, miksi se on hyvä ja miten sen kanssa periaatteessa elää tuotannossa.

Yritän selittää, kuinka Tiller ja RBAC toimivat. Tiller toimii klusterin sisällä tietyllä palvelutilillä. Yleensä, jos RBAC:tä ei ole määritetty, tämä on pääkäyttäjä. Peruskokoonpanossa Tiller on järjestelmänvalvoja. Tästä syystä usein sanotaan, että Tiller on SSH-tunneli klusteriisi. Itse asiassa tämä on totta, joten voit käyttää erillistä palvelutiliä yllä olevan kaavion oletuspalvelutilin sijaan.

Kun alustat Helmin ja asennat sen palvelimelle ensimmäistä kertaa, voit määrittää palvelutilin käyttämällä --service-account. Näin voit käyttää käyttäjää, jolla on vähimmäisoikeudet. Totta, sinun on luotava tällainen "seppele": Role ja RoleBinding.

Valitettavasti Helm ei tee tätä puolestasi. Sinun tai Kubernetes-klusterin järjestelmänvalvojasi on valmisteltava joukko rooleja ja roolisidoksia palvelutilille etukäteen, jotta voit läpäistä Helmin.

Herää kysymys - mitä eroa on Rolen ja ClusterRolen välillä? Erona on, että ClusterRole toimii kaikissa nimiavaruuksissa, toisin kuin tavalliset Roles ja RoleBindings, jotka toimivat vain erikoistuneessa nimiavaruudessa. Voit määrittää käytännöt koko klusterille ja kaikille nimiavaruksille tai mukauttaa kullekin nimiavaruudelle erikseen.

On syytä mainita, että RBAC ratkaisee toisen suuren ongelman. Monet ihmiset valittavat, että Helm ei valitettavasti ole monivuokrasopimus (ei tue monivuokrausta). Jos useat tiimit kuluttavat klusterin ja käyttävät Helmiä, on periaatteessa mahdotonta määrittää käytäntöjä ja rajoittaa pääsyä tähän klusteriin, koska Helm toimii tietyn palvelutilin alaisuudessa ja se luo kaikki klusterin resurssit sen alta. , mikä on joskus erittäin epämiellyttävää. Tämä on totta - kuten itse binääritiedosto, kuten prosessi, Helm Tillerillä ei ole käsitettä monivuokrauksesta.

On kuitenkin olemassa loistava tapa, jonka avulla voit ajaa Tilleriä useita kertoja klusterissa. Tässä ei ole ongelmaa, Tiller voidaan käynnistää jokaisessa nimitilassa. Siten voit käyttää RBAC:ta, Kubeconfigia kontekstina ja rajoittaa pääsyä erityiseen Helmiin.

Se näyttää tältä.

Esimerkiksi on olemassa kaksi Kubeconfigia, joissa on konteksti eri ryhmille (kaksi nimiavaruutta): X Team kehitystiimille ja järjestelmänvalvojaklusterille. Admin-klusterilla on oma laaja Tiller, joka sijaitsee Kube-järjestelmän nimiavaruudessa, vastaavasti kehittynyt palvelutili. Ja erillinen nimiavaruus kehitystiimille, he voivat ottaa käyttöön palvelunsa erityiseen nimiavaruuteen.

Tämä on toimiva lähestymistapa, Tiller ei ole niin voimakas, että se vaikuttaisi suuresti budjettiisi. Tämä on yksi nopeista ratkaisuista.

Voit vapaasti määrittää Tillerin erikseen ja tarjota Kubeconfigille kontekstin tiimille, tietylle kehittäjälle tai ympäristölle: Dev, Staging, Production (on epävarmaa, että kaikki on samassa klusterissa, mutta tämä voidaan tehdä).

Jatkamme tarinaamme, siirrytään RBAC:sta ja puhutaan ConfigMapsista.

ConfigMaps

Helm käyttää ConfigMapsia tietovarastonaan. Kun puhuimme arkkitehtuurista, missään ei ollut tietokantaa, johon olisi tallennettu tietoa julkaisuista, kokoonpanoista, palautuksista jne. Tähän käytetään ConfigMapsia.

ConfigMapsin suurin ongelma on tiedossa - ne eivät ole periaatteessa turvallisia; arkaluonteisia tietoja on mahdotonta tallentaa. Puhumme kaikesta, mikä ei saisi mennä palvelun ulkopuolelle, esimerkiksi salasanoista. Helmin luontaisin tapa tällä hetkellä on siirtyä ConfigMapsista salaisuuksiin.

Tämä tehdään hyvin yksinkertaisesti. Ohita Tiller-asetus ja määritä, että tallennustila on salainen. Sitten jokaisesta käyttöönotosta et saa ConfigMapia, vaan salaisuuden.

Voit väittää, että salaisuudet itsessään ovat outo käsite eivätkä kovin turvallisia. On kuitenkin syytä ymmärtää, että Kubernetes-kehittäjät itse tekevät tämän. Versiosta 1.10 alkaen, ts. Jo jonkin aikaa on ollut mahdollista ainakin julkisissa pilvissä yhdistää oikea tallennustila salaisuuksien tallentamiseen. Tiimi etsii parhaillaan tapoja jakaa paremmin pääsyä salaisuuksiin, yksittäisiin koteloihin tai muihin kokonaisuuksiin.

Storage Helm on parempi siirtää salaisuuksiin, ja ne puolestaan ​​​​turvataan keskitetysti.

Tottakai se jää tiedon tallennusraja 1 Mt. Helm käyttää etcd:tä ConfigMapsin hajautettuna tallennustilana. Ja siellä he katsoivat, että tämä oli sopiva datapala replikointiin jne. Tästä on mielenkiintoinen keskustelu Redditissä, suosittelen etsimään tätä hauskaa luettavaa viikonlopuksi tai lukemaan otteen täällä.

Kaavio repot

Kaaviot ovat sosiaalisesti haavoittuvimpia ja niistä voi tulla "mies keskellä", varsinkin jos käytät osakeratkaisua. Ensinnäkin puhumme arkistoista, jotka paljastetaan HTTP:n kautta.

Sinun on ehdottomasti esitettävä Helm Repo HTTPS:n kautta - tämä on paras vaihtoehto ja edullinen.

Kiinnitä huomiota kaavion allekirjoitusmekanismi. Tekniikka on helvetin yksinkertainen. Tämä on sama asia, jota käytät GitHubissa, tavallisessa PGP-koneessa julkisilla ja yksityisillä avaimilla. Määritä ja varmista, että sinulla on tarvittavat avaimet ja allekirjoitat kaikki, että tämä on todella sinun kaaviosi.

Lisäksi, Helm-asiakas tukee TLS:ää (ei palvelinpuolen HTTP:n mielessä, vaan keskinäinen TLS). Voit käyttää palvelin- ja asiakasavaimia viestimiseen. Rehellisesti sanottuna en käytä tällaista mekanismia, koska en pidä keskinäisistä varmenteista. Pohjimmiltaan, karttamuseo - päätyökalu Helm Repon määrittämiseen Helm 2:lle - tukee myös perustodennusta. Voit käyttää perustodennusta, jos se on kätevämpää ja hiljaisempaa.

Siellä on myös plugin helm-gcs, jonka avulla voit isännöidä Chart Repoja Google Cloud Storagessa. Tämä on varsin kätevää, toimii hyvin ja on melko turvallinen, koska kaikki kuvatut mekanismit kierrätetään.

Jos otat HTTPS:n tai TLS:n käyttöön, käytät mTLS:ää ja otat käyttöön perustodennusta riskien vähentämiseksi entisestään, saat suojatun viestintäkanavan Helm CLI:n ja Chart Repon avulla.

gRPC API

Seuraava askel on erittäin tärkeä - suojata Tiller, joka sijaitsee klusterissa ja on toisaalta palvelin, toisaalta se pääsee itse muihin komponentteihin ja yrittää teeskennellä olevansa joku.

Kuten jo sanoin, Tiller on palvelu, joka paljastaa gRPC:n, Helm-asiakas tulee siihen gRPC:n kautta. Oletuksena tietysti TLS on poissa käytöstä. Miksi tämä tehtiin, on kyseenalainen kysymys, minusta tuntuu, että se yksinkertaistaa asennusta alussa.

Tuotannossa ja jopa lavastusta varten suosittelen TLS:n ottamista käyttöön gRPC:ssä.

Mielestäni, toisin kuin mTLS kaavioille, tämä sopii tähän ja tehdään hyvin yksinkertaisesti - luo PQI-infrastruktuuri, luo sertifikaatti, käynnistä Tiller, siirrä varmenne alustuksen aikana. Tämän jälkeen voit suorittaa kaikki Helm-komennot esittäen itsellesi luodun varmenteen ja yksityisen avaimen.

Näin suojaudut kaikilta klusterin ulkopuolelta tulevilta Tillerille tulevilta pyynnöiltä.

Olemme siis turvanneet yhteyskanavan Tillerille, olemme jo keskustelleet RBAC:stä ja säätäneet Kubernetes apiserverin oikeuksia vähentäen verkkotunnusta, jonka kanssa se voi olla vuorovaikutuksessa.

Suojattu ruori

Katsotaanpa lopullista kaaviota. Se on sama arkkitehtuuri samoilla nuolilla.

Kaikki liitännät voidaan nyt piirtää turvallisesti vihreällä:

• Chart Repossa käytämme TLS:ää tai mTLS:ää ja perustodennusta;
• mTLS for Tiller, ja se on esillä gRPC-palveluna TLS:n kanssa, käytämme varmenteita;
• klusteri käyttää erityistä palvelutiliä Roleilla ja RoleBindingillä. 

Olemme turvanneet klusterin merkittävästi, mutta joku viisas sanoi:

"Täysin turvallinen ratkaisu voi olla vain yksi - sammutettu tietokone, joka sijaitsee betonilaatikossa ja jota sotilaat vartioivat."

On olemassa erilaisia ​​tapoja käsitellä tietoja ja löytää uusia hyökkäysvektoreita. Olen kuitenkin varma, että näillä suosituksilla saavutetaan turvallisuuden perusstandardi.

Bonus

Tämä osa ei liity suoraan turvallisuuteen, mutta se on myös hyödyllinen. Näytän sinulle mielenkiintoisia asioita, joista harvat tietävät. Esimerkiksi kuinka etsiä kaavioita - virallisia ja epävirallisia.

Arkistossa github.com/helm/charts Nyt on noin 300 kaaviota ja kaksi streamia: vakaa ja inkubaattori. Jokainen, joka osallistuu, tietää erittäin hyvin, kuinka vaikeaa on päästä hautomoon talliin ja kuinka helppoa on lentää tallilta. Tämä ei kuitenkaan ole paras työkalu etsiä kaavioita Prometheukselle ja muulle, josta haluat, yhdestä yksinkertaisesta syystä - se ei ole portaali, josta voit kätevästi etsiä paketteja.

Mutta palvelu on olemassa hub.helm.sh, mikä tekee kaavioiden löytämisestä paljon helpompaa. Mikä tärkeintä, saatavilla on paljon enemmän ulkoisia tietovarastoja ja lähes 800 hurmaa. Lisäksi voit yhdistää arkistosi, jos et jostain syystä halua lähettää kaavioitasi talliin.

Kokeile hub.helm.sh:ta ja kehitetään sitä yhdessä. Tämä palvelu on Helm-projektin alainen, ja voit jopa osallistua sen käyttöliittymään, jos olet etupään kehittäjä ja haluat vain parantaa ulkonäköä.

Haluaisin myös kiinnittää huomionne Avaa Service Broker API -integraatio. Se kuulostaa hankalalta ja epäselvältä, mutta se ratkaisee kaikkien kohtaamia ongelmia. Selitän yksinkertaisella esimerkillä.

Siellä on Kubernetes-klusteri, jossa haluamme käyttää klassista sovellusta - WordPress. Yleensä tarvitaan tietokanta täydellistä toimintaa varten. Ratkaisuja on monia erilaisia, voit esimerkiksi käynnistää oman statefull-palvelun. Tämä ei ole kovin kätevää, mutta monet ihmiset tekevät niin.

Toiset, kuten me Chainstackissa, käyttävät palvelimilleen hallittuja tietokantoja, kuten MySQL tai PostgreSQL. Siksi tietokantamme sijaitsevat jossain pilvessä.

Mutta ongelma syntyy: meidän on yhdistettävä palvelumme tietokantaan, luotava tietokannan maku, siirrettävä tunnistetiedot ja jotenkin hallittava sitä. Yleensä järjestelmänvalvoja tai kehittäjä tekee kaiken tämän manuaalisesti. Eikä ongelmaa ole, kun sovelluksia on vähän. Kun niitä on paljon, tarvitset yhdistelmän. On sellainen harvesteri - se on Service Broker. Sen avulla voit käyttää erityistä laajennusta julkiseen pilviklusteriin ja tilata resursseja palveluntarjoajalta Brokerin kautta ikään kuin se olisi API. Voit tehdä tämän käyttämällä alkuperäisiä Kubernetes-työkaluja.

Se on hyvin yksinkertaista. Voit tehdä kyselyn esimerkiksi Managed MySQL:stä Azuressa perustasolla (tämä voidaan määrittää). Tietokanta luodaan ja valmistetaan käytettäväksi Azure API:n avulla. Sinun ei tarvitse puuttua tähän, laajennus on vastuussa tästä. Esimerkiksi OSBA (Azure-laajennus) palauttaa valtuustiedot palveluun ja välittää ne Helmille. Pystyt käyttämään WordPressiä pilvi MySQL:n kanssa, et käsittele hallittuja tietokantoja ollenkaan etkä murehdi sisällä olevista tilatäydellisistä palveluista.

Voimme sanoa, että Helm toimii liimana, joka toisaalta mahdollistaa palveluiden käyttöönoton ja toisaalta kuluttaa pilvipalveluntarjoajien resursseja.

Voit kirjoittaa oman laajennuksen ja käyttää koko tätä tarinaa paikan päällä. Sitten sinulla on vain oma laajennus yrityksen pilvipalveluntarjoajalle. Suosittelen kokeilemaan tätä lähestymistapaa, varsinkin jos sinulla on laaja mittakaava ja haluat ottaa nopeasti käyttöön dev-, lavastus- tai koko infrastruktuurin ominaisuudelle. Tämä helpottaa toimintaasi tai DevOpsia.

Toinen löytö, jonka jo mainitsin on helm-gcs-laajennus, jonka avulla voit käyttää Google-bucketsia (objektien tallennustilaa) Helm-kaavioiden tallentamiseen.

Tarvitset vain neljä komentoa aloittaaksesi sen käytön:

1. asenna laajennus;
2. aloittaa sen;
3. aseta polku ämpäriin, joka sijaitsee gcp:ssä;
4. julkaista kaavioita tavallisella tavalla.

Hienointa on, että valtuutukseen käytetään alkuperäistä gcp-menetelmää. Voit käyttää palvelutiliä, kehittäjätiliä, mitä haluat. Se on erittäin kätevä eikä maksa mitään. Jos sinä, kuten minä, edistät opsless-filosofiaa, tämä on erittäin kätevää, etenkin pienille joukkueille.

vaihtoehtoja

Helm ei ole ainoa palvelunhallintaratkaisu. Siitä on paljon kysymyksiä, mikä on luultavasti syy, miksi kolmas versio ilmestyi niin nopeasti. Toki vaihtoehtoja on.

Nämä voivat olla erikoisratkaisuja, esimerkiksi Ksonnet tai Metaparticle. Voit käyttää klassisia infrastruktuurin hallintatyökalujasi (Ansible, Terraform, Chef jne.) samoihin tarkoituksiin, joista puhuin.

Lopulta löytyy ratkaisu Operator Framework, jonka suosio on kasvussa.

Operator Framework on paras harkittava Helm-vaihtoehto.

Se on kotoisin CNCF:stä ja Kubernetesista, mutta pääsyn este on paljon korkeampi, sinun täytyy ohjelmoida enemmän ja kuvata manifesteja vähemmän.

On olemassa erilaisia ​​lisäosia, kuten Draft, Scaffold. Ne helpottavat elämää paljon, esimerkiksi yksinkertaistavat Helmin lähettämistä ja käynnistämistä kehittäjille testiympäristön käyttöönottoa varten. Kutsuisin heitä voimaannuttajiksi.

Tässä on visuaalinen kaavio siitä, missä kaikki on.

X-akselilla on henkilökohtaisen hallinnan taso tapahtuvaan, y-akselilla on Kubernetesin alkuperäisyyden taso. Helmin versio 2 putoaa jonnekin puoliväliin. Versiossa 3 ei valtavasti, mutta sekä ohjausta että alkuperäisyyden tasoa on parannettu. Ksonnet-tason ratkaisut ovat edelleen jopa Helm 2:ta huonompia. Kannattaa kuitenkin katsoa, ​​mitä muuta tässä maailmassa on. Tietenkin kokoonpanonhallinta on sinun hallinnassasi, mutta se ei todellakaan ole Kubernetesin alkuperäinen.

Operator Framework on täysin alkuperäinen Kubernetes, ja sen avulla voit hallita sitä paljon tyylikkäämmin ja täsmällisemmin (mutta muista lähtötaso). Pikemminkin tämä sopii erikoissovellukseen ja sen hallinnan luomiseen, eikä massaharvesteriin, jolla pakkaataan valtava määrä sovelluksia Helmin avulla.

Extenderit yksinkertaisesti parantavat ohjausta hieman, täydentävät työnkulkua tai leikkaavat kulmia CI/CD-putkista.

Helmin tulevaisuus

Hyvä uutinen on, että Helm 3 on tulossa. Helm 3.0.0-alpha.2:n alfaversio on jo julkaistu, voit kokeilla sitä. Se on melko vakaa, mutta toiminnallisuus on edelleen rajallinen.

Miksi tarvitset Helm 3:n? Ensinnäkin tämä on tarina Tillerin katoaminen, komponenttina. Tämä, kuten jo ymmärrät, on valtava askel eteenpäin, koska arkkitehtuurin turvallisuuden kannalta kaikki on yksinkertaistettua.

Kun Helm 2 luotiin, mikä oli suunnilleen Kubernetes 1.8:n tai jopa aikaisemmin, monet konseptit olivat epäkypsiä. Esimerkiksi CRD-konseptia ollaan nyt aktiivisesti toteuttamassa, ja Helm aikoo tehdä sen käytä CRD:tärakenteiden varastointiin. On mahdollista käyttää vain asiakasta, ei ylläpitää palvelinosaa. Käytä siis Kubernetesin alkuperäisiä komentoja rakenteiden ja resurssien käsittelyyn. Tämä on valtava askel eteenpäin.

Ilmestyy tuki alkuperäisille OCI-tietovarastoille (Open Container Initiative). Tämä on valtava aloite, ja Helm on kiinnostunut ensisijaisesti listansa julkaisemisesta. Asia tulee siihen pisteeseen, että esimerkiksi Docker Hub tukee monia OCI-standardeja. En arvaa, mutta ehkä klassiset Docker-arkiston tarjoajat alkavat antaa sinulle mahdollisuuden isännöidä Helm-kaavioitaan.

Minulle kiistanalainen tarina on Lua tuki, mallimoottorina skriptien kirjoittamiseen. En ole suuri Lua-fani, mutta tämä olisi täysin valinnainen ominaisuus. Tarkistin tämän 3 kertaa - Luan käyttö ei ole välttämätöntä. Siksi ne, jotka haluavat käyttää Luaa, ne, jotka pitävät Gosta, liittykää valtavaan leiriimme ja käyttävät go-tmpl:ää tähän.

Lopuksi se, mikä minulta ehdottomasti puuttui, oli skeeman syntyminen ja tietotyypin validointi. Int:n tai merkkijonon kanssa ei enää ole ongelmia, nollaa ei tarvitse kääriä lainausmerkkeihin. Näkyviin tulee JSONS-skeema, jonka avulla voit kuvata tämän tarkasti arvoille.

Uudistetaan voimakkaasti tapahtumalähtöinen malli. Se on jo käsitteellisesti kuvattu. Katso Helm 3 -haara, niin näet kuinka monta tapahtumaa ja koukkua ja muuta on lisätty, mikä yksinkertaistaa ja toisaalta lisää hallintaa käyttöönottoprosesseihin ja niihin kohdistuviin reaktioihin.

Helm 3 tulee olemaan yksinkertaisempi, turvallisempi ja hauskempi, ei siksi, että emme pidä Helm 2:sta, vaan koska Kubernetes on kehittymässä. Näin ollen Helm voi hyödyntää Kubernetesin kehitystä ja luoda Kubernetesiin erinomaisia ​​johtajia.

Toinen hyvä uutinen on se DevOpsConf Alexander Khayorov kertoo sinulle, voivatko säiliöt olla turvallisia? Muistutettakoon, että kehitys-, testaus- ja käyttöprosessien integrointikonferenssi pidetään Moskovassa 30. syyskuuta ja 1. lokakuuta. Voit tehdä sen vielä elokuun 20. päivään asti Lähetä raportti ja kerro meille kokemuksestasi ratkaisusta yksi monista DevOps-lähestymistavan tehtävät.

Seuraa konferenssin tarkistuspisteitä ja uutisia osoitteessa postitus lista и sähkekanava.

Lähde: will.com