Kubernetes-klusterissa toimiville sovelluksille on useita tapoja määrittää tallennustila. Jotkut niistä ovat jo vanhentuneita, toiset ilmestyivät aivan hiljattain. Tässä artikkelissa tarkastellaan kolmen vaihtoehdon käsitettä tallennusjärjestelmien yhdistämiseksi, mukaan lukien viimeisin - yhdistäminen Container Storage Interface -liittymän kautta.
Tapa 1: Määritä PV pod-luettelossa
Tyypillinen manifesti, joka kuvaa koteloa Kubernetes-klusterissa:
Luettelon osat, jotka kuvaavat, mikä taltio on yhdistetty ja mihin, on korostettu värein.
Luokasta volumeMounts osoita liitoskohdat (mountPath) - mihin hakemistoon säiliön sisällä pysyvä taltio liitetään, sekä taltion nimi.
Luokasta x luettelee kaikki podissa käytetyt asemat. Määritä kunkin taltion nimi sekä tyyppi (tapauksessamme awsElasticBlockStore) ja yhteysparametrit. Luettelossa luetellut parametrit riippuvat taltiotyypistä.
Sama tilavuus voidaan asentaa samanaikaisesti useisiin koteloihin. Tällä tavalla eri sovellusprosessit voivat käyttää samoja tietoja.
Tämä yhdistämismenetelmä keksittiin aivan alussa, kun Kubernetes oli vasta lapsenkengissään, ja nykyään menetelmä on vanhentunut.
Sen käytössä on useita ongelmia:
- kaikki taltiot on luotava manuaalisesti; Kubernetes ei voi luoda meille mitään;
- pääsyparametrit jokaiselle taltiolle ovat yksilöllisiä, ja ne on määritettävä kaikkien asemaa käyttävien podien luetteloissa;
- Jos haluat muuttaa tallennusjärjestelmää (esimerkiksi siirtyä AWS:stä Google Cloudiin), sinun on muutettava asetuksia ja asennettujen taltioiden tyyppiä kaikissa luetteloissa.
Kaikki tämä on erittäin hankalaa, joten todellisuudessa tätä menetelmää käytetään vain joidenkin erityistyyppisten taltioiden yhdistämiseen: configMap, secret, emptyDir, hostPath:
-
configMap ja secret ovat palvelutaltioita, joiden avulla voit luoda taltion säilössä olevista Kubernetes-luetteloista olevista tiedostoista.
-
emptyDir on väliaikainen taltio, joka on luotu vain podin käyttöiän ajaksi. Kätevä käyttää tilapäisten tietojen testaamiseen tai tallentamiseen. Kun pod poistetaan, myös tyhjäDir-taltio poistetaan ja kaikki tiedot menetetään.
-
hostPath - mahdollistaa minkä tahansa hakemiston liittämisen sen palvelimen paikalliselle levylle, jolla sovellus toimii, sovelluksen säilön sisällä, mukaan lukien /etc/kubernetes. Tämä on vaarallinen ominaisuus, joten suojauskäytännöt yleensä kieltävät tämän tyyppisten taltioiden käytön. Muussa tapauksessa hyökkääjän sovellus voi liittää HTC Kubernetes -hakemiston säiliöön ja varastaa kaikki klusterivarmenteet. Yleensä hostPath-asioita saavat käyttää vain järjestelmäsovellukset, jotka toimivat kube-system-nimiavaruudessa.
on annettu dokumentaatiossa.
Menetelmä 2. Kytkentä SC/PVC/PV tulisijoihin
Vaihtoehtoinen yhteystapa on Storage class, PersistentVolumeClaim, PersistentVolume käsite.
Varastointiluokka tallentaa yhteysparametrit tiedontallennusjärjestelmään.
Pysyvä tilavuusvaatimus kuvailee vaatimukset sille, mitä sovellus tarvitsee.
Pysyvä tilavuus tallentaa pääsyparametrit ja äänenvoimakkuuden tilan.
Idean ydin: pod-luettelossa ne osoittavat PersistentVolumeClaim-tyyppisen taltion ja osoittavat tämän entiteetin nimen vaatimuksenName-parametrissa.
PersistentVolumeClaim-luettelo kuvaa sovelluksen tarvitseman tietomäärän vaatimukset. Mukaan lukien:
- levyn koko;
- pääsytapa: ReadWriteOnce tai ReadWriteMany;
- linkki tallennusluokkaan - mihin tietotallennusjärjestelmään taltio halutaan luoda.
Tallennusluokan luettelo tallentaa tallennusjärjestelmään yhteyden tyypin ja parametrit. Kuutio tarvitsee niitä asentaakseen aseman solmuun.
PersistentVolume-luettelot osoittavat tietyn taltion tallennusluokan ja käyttöparametrit (taltion tunnus, polku jne.).
PVC:tä luodessaan Kubernetes tarkastelee, minkä kokoinen tilavuus ja mikä tallennusluokka vaaditaan, ja valitsee ilmaisen PersistentVolumen.
Jos tällaisia PV:itä ei ole saatavilla, Kubernetes voi käynnistää erikoisohjelman - Provisioner (sen nimi on ilmoitettu Storage-luokassa). Tämä ohjelma muodostaa yhteyden tallennusjärjestelmään, luo vaaditun kokoisen taltion, vastaanottaa tunnisteen ja luo Kubernetes-klusteriin PersistentVolume-luettelon, joka liittyy PersistentVolumeClaimiin.
Kaikkien näiden abstraktioiden avulla voit poistaa tietoja siitä, minkä tallennusjärjestelmän kanssa sovellus työskentelee, sovelluksen luettelotasolta hallintatasolle.
Kaikki tietojen tallennusjärjestelmään liittymisen parametrit sijaitsevat Storage-luokassa, josta vastaavat klusterin ylläpitäjät. Kun siirryt AWS:stä Google Cloudiin, sinun tarvitsee vain vaihtaa tallennusluokan nimi PVC:ksi sovellusluetteloissa. Tietojen säilytystilavuus luodaan klusteriin automaattisesti Provisioner-ohjelman avulla.
Tapa 3: Säiliön tallennusliitäntä
Kaikki koodi, joka on vuorovaikutuksessa eri tallennusjärjestelmien kanssa, on osa Kubernetesin ydintä. Virheenkorjausten tai uusien toimintojen julkaiseminen on sidottu uusiin julkaisuihin; koodi on vaihdettava kaikissa tuetuissa Kubernetes-versioissa. Kaikki tämä on vaikea ylläpitää ja lisätä uusia toimintoja.
Ongelman ratkaisemiseksi Cloud Foundryn, Kubernetesin, Mesosin ja Dockerin kehittäjät loivat Container Storage Interfacen (CSI) - yksinkertaisen yhtenäisen käyttöliittymän, joka kuvaa kontinhallintajärjestelmän ja erityisen ohjaimen (CSI Driver) vuorovaikutusta, joka toimii tietyn kanssa. varastointijärjestelmä. Kaikki tallennusjärjestelmien kanssa käytettävä koodi siirrettiin Kubernetes-ytimestä erilliseen järjestelmään.
.
Tyypillisesti CSI Driver koostuu kahdesta osasta: Node Plugin ja Controller plugin.
Node Plugin toimii jokaisessa solmussa ja on vastuussa taltioiden asentamisesta ja toimintojen suorittamisesta niille. Controller-laajennus on vuorovaikutuksessa tallennusjärjestelmän kanssa: luo tai poistaa taltioita, antaa käyttöoikeuksia jne.
Toistaiseksi vanhat ajurit jäävät Kubernetes-ytimeen, mutta niitä ei enää suositella käytettäväksi, ja kaikkia kehotetaan asentamaan CSI-ajuri erityisesti sitä järjestelmää varten, jonka kanssa he toimivat.
Innovaatio saattaa pelotella niitä, jotka ovat jo tottuneet asettamaan tallennustilaa Storage-luokan kautta, mutta todellisuudessa mitään kauheaa ei ole tapahtunut. Ohjelmoijille mikään ei oikeastaan muutu - he ovat työskennelleet vain nimellä Storage class, ja tekevät niin jatkossakin. Järjestelmänvalvojille ruorikaavion asennus on lisätty ja asetusten rakennetta on muutettu. Jos aiemmin asetukset syötettiin suoraan Storage-luokkaan, niin nyt ne on asetettava ensin ruorikaavioon ja sitten Storage-luokkaan. Jos katsot sitä, mitään pahaa ei tapahtunut.
Otetaan esimerkkiä tarkastellaksemme etuja, joita voit saada vaihtamalla Ceph-tallennusjärjestelmien yhdistämiseen CSI-ajurin avulla.
Cephin kanssa työskennellessä CSI-laajennus tarjoaa enemmän vaihtoehtoja tallennusjärjestelmien kanssa työskentelyyn kuin sisäänrakennetut ajurit.
- Dynaaminen levyn luominen. Yleensä RBD-levyjä käytetään vain RWO-tilassa, mutta CSI for Ceph sallii niiden käytön RWX-tilassa. Useat eri solmuissa olevat podit voivat asentaa saman RDB-levyn solmuihinsa ja työskennellä niiden kanssa rinnakkain. Ollakseni rehellinen, kaikki ei ole niin kirkasta - tämä levy voidaan liittää vain lohkolaitteena, mikä tarkoittaa, että sinun on mukautettava sovellus toimimaan sen kanssa monikäyttötilassa.
- Tilannekuvien luominen. Kubernetes-klusterissa voit luoda luettelon, jossa on vaatimus luoda tilannekuva. CSI-laajennus näkee sen ja ottaa tilannekuvan levyltä. Sen perusteella voit tehdä PersistentVolumesta joko varmuuskopion tai kopion.
- Levyn koon lisääminen tallennustilasta ja PersistentVolumesta Kubernetes-klusterissa.
- Kiintiöt. Kubernetesiin sisäänrakennetut CephFS-ajurit eivät tue kiintiöitä, mutta tuoreet CSI-laajennukset, joissa on uusin Ceph Nautilus, voivat ottaa käyttöön kiintiöt CephFS-osioissa.
- Mittarit. CSI-laajennus voi tarjota Prometheukselle erilaisia mittareita siitä, mitkä asemat on kytketty, mitä viestintää tapahtuu jne.
- Topologiatietoinen. Voit määrittää luetteloissa, kuinka klusteri jakautuu maantieteellisesti, ja välttää Amsterdamissa sijaitsevan tallennusjärjestelmän yhdistämisen Lontoossa toimiviin podeihin.
Kuinka yhdistää Ceph Kubernetes-klusteriin CSI:n kautta, katso . Voit myös tilata , joka julkaistaan 15. lokakuuta.
Artikkelin kirjoittaja: Sergey Bondarev, työskentelevä arkkitehti Southbridgessä, sertifioitu Kubernetes-järjestelmänvalvoja, yksi kubesprayn kehittäjistä.
Pieni Post Scriptum ei mainontaan, vaan hyödyksi...
PS Sergey Bondarev johtaa kahta intensiivistä kurssia: päivitetty 28.-30. ja eteenpäin lokakuuta 14-16.
Lähde: will.com