ProHoster > Blogi > antaminen > Kokemuksemme CSI-ohjaimen kehittämisestä Kubernetesissa Yandex.Cloudille

Kokemuksemme CSI-ohjaimen kehittämisestä Kubernetesissa Yandex.Cloudille

Kokemuksemme CSI-ohjaimen kehittämisestä Kubernetesissa Yandex.Cloudille

Meillä on ilo ilmoittaa, että Flant laajentaa panostaan ​​avoimen lähdekoodin työkaluihin Kubernetesille julkaisemalla CSI-ohjaimen alfaversio (Container Storage Interface) Yandex.Cloudille.

Mutta ennen kuin siirrymme täytäntöönpanon yksityiskohtiin, vastataan kysymykseen, miksi tätä ylipäänsä tarvitaan, kun Yandexillä on jo palvelu Hallittu palvelu Kubernetesille.

Esittely

Miksi tämä on?

Yrityksemme sisällä olemme Kubernetesin tuotannossa käytön alusta lähtien (eli jo usean vuoden ajan) kehittäneet omaa työkaluamme (deckhouse), jonka aiomme muuten myös saattaa pian saataville Open Source -projektina. . Sen avulla konfiguroimme ja konfiguroimme yhtenäisesti kaikki klusterimme, ja tällä hetkellä niitä on jo yli 100, monenlaisissa laitteistokokoonpanoissa ja kaikissa käytettävissä olevissa pilvipalveluissa.

Deckhousea käyttävissä klustereissa on kaikki toimintaan tarvittavat komponentit: tasapainottimet, seuranta kätevillä kaavioilla, mittareilla ja hälytyksellä, käyttäjien todennus ulkoisten palveluntarjoajien kautta kaikkien kojelaudoiden pääsyä varten ja niin edelleen. Ei ole mitään järkeä asentaa tällaista "pumpattua" klusteria hallittuun ratkaisuun, koska se on usein joko mahdotonta tai johtaa siihen, että puolet komponenteista on poistettava käytöstä.

NB: Tämä on meidän kokemuksemme, ja se on melko tarkka. Emme missään tapauksessa ehdota, että kaikkien tulisi ottaa Kubernetes-klustereita käyttöön itse valmiiden ratkaisujen sijaan. Muuten, meillä ei ole todellista kokemusta Yandexin Kubernetesin käyttämisestä, emmekä anna tässä artikkelissa mitään arviota tästä palvelusta.

Mitä se on ja kenelle?

Joten, olemme jo puhuneet nykyaikaisesta lähestymistavasta varastointiin Kubernetesissa: miten CSI toimii? и miten yhteisö syntyi tähän lähestymistapaan.

Tällä hetkellä monet suuret pilvipalveluntarjoajat ovat kehittäneet ajureita pilvilevyjensä käyttämiseen Kubernetesin pysyvänä talteena. Jos toimittajalla ei ole tällaista ohjainta, mutta kaikki tarvittavat toiminnot tarjotaan API:n kautta, mikään ei estä sinua toteuttamasta ohjainta itse. Näin kävi Yandex.Cloudille.

Otimme kehityksen perustaksi CSI-ohjain DigitalOcean-pilveen ja pari ideaa sieltä GCP-ajurit, koska vuorovaikutuksessa näiden pilvien API:n (Google ja Yandex) kanssa on useita yhtäläisyyksiä. Erityisesti API ja GCPja Yandex palauttaa esineen Operation seurata pitkään käynnissä olevien toimintojen tilaa (esimerkiksi uuden levyn luominen). Jos haluat olla vuorovaikutuksessa Yandex.Cloud API:n kanssa, käytä Yandex.Cloud Go SDK.

Tehdyn työn tulos julkaistu GitHubissa ja voi olla hyödyllistä niille, jotka jostain syystä käyttävät omaa Kubernetes-asennustaan ​​Yandex.Cloud-virtuaalikoneissa (mutta ei valmiita hallittuja klustereita) ja haluavat käyttää (tilata) levyjä CSI:n kautta.

Реализация

Tärkeimmät ominaisuudet

Tällä hetkellä ohjain tukee seuraavia toimintoja:

  • Levyjen järjestäminen klusterin kaikilla vyöhykkeillä klusterin solmujen topologian mukaan;
  • Aiemmin tilattujen levyjen poistaminen;
  • Levyjen koon muuttaminen offline-tilassa (Yandex.Cloud älä tue virtuaalikoneeseen asennettujen levyjen lisääminen). Lisätietoja siitä, kuinka ohjainta piti muokata, jotta koon muuttaminen olisi mahdollisimman kivutonta, on alla.

Tulevaisuudessa aiomme ottaa käyttöön tuen levyvedosten luomiseen ja poistamiseen.

Suurin vaikeus ja kuinka voittaa se

Kyky lisätä levyjä reaaliajassa Yandex.Cloud API:ssa on rajoitus, joka vaikeuttaa PV:n (Persistent Volume) koonmuutostoimintoa: tässä tapauksessa levyä käyttävä sovelluskotelo on pysäytettävä, ja tämä voi aiheuttaa käyttökatkoksia.

Mukaan CSI:n tekniset tiedot, jos CSI-ohjain ilmoittaa, että se voi muuttaa levyjen kokoa vain "offline" (VolumeExpansion.OFFLINE), levyn kasvattamisprosessin pitäisi mennä seuraavasti:

Jos laajennuksessa on vain VolumeExpansion.OFFLINE laajennusmahdollisuus ja volyymi on tällä hetkellä julkaistu tai saatavilla solmussa ControllerExpandVolume TÄYTYY kutsua VAIN jommankumman jälkeen:

  • Pluginilla on ohjain PUBLISH_UNPUBLISH_VOLUME kyky ja ControllerUnpublishVolume on kutsuttu onnistuneesti.

TAI MUUTEN

  • Pluginissa EI ole ohjainta PUBLISH_UNPUBLISH_VOLUME ominaisuus, laajennuksessa on solmu STAGE_UNSTAGE_VOLUME kyky ja NodeUnstageVolume on suoritettu onnistuneesti.

TAI MUUTEN

  • Pluginissa EI ole ohjainta PUBLISH_UNPUBLISH_VOLUME kyky, eikä solmu STAGE_UNSTAGE_VOLUME kyky ja NodeUnpublishVolume on suoritettu onnistuneesti.

Tämä tarkoittaa käytännössä sitä, että sinun on irrotettava levy virtuaalikoneesta ennen sen laajentamista.

Valitettavasti kuitenkin toteutus CSI-spesifikaatio sivuvaunujen kautta ei täytä näitä vaatimuksia:

  • Sivuvaunukontissa csi-attacher, jonka pitäisi olla vastuussa tarvittavan raon olemassaolosta kiinnikkeiden välillä, tätä toimintoa ei yksinkertaisesti ole toteutettu offline-koon muutoksessa. Tästä käynnistettiin keskustelu täällä.
  • Mikä on sivuvaunukontti tässä yhteydessä? CSI-laajennus itsessään ei ole vuorovaikutuksessa Kubernetes API:n kanssa, vaan se vastaa vain sivuvaunusäiliöiden sille lähettämiin gRPC-kutsuihin. Uusin kehitetään Kubernetes-yhteisön toimesta.

Meidän tapauksessamme (CSI-laajennus) levyn kasvattaminen näyttää tältä:

  1. Saamme gRPC-puhelun ControllerExpandVolume;
  2. Yritämme kasvattaa levyn määrää API:ssa, mutta saamme virheilmoituksen siitä, että toimintoa ei voida suorittaa, koska levy on asennettu;
  3. Tallennamme levytunnisteen karttaan, joka sisältää levyt, joille lisäys on suoritettava. Alla kutsumme tätä karttaa lyhyyden vuoksi nimellä volumeResizeRequired;
  4. Poista levyä käyttävä kotelo manuaalisesti. Kubernetes käynnistää sen uudelleen. Jotta levyllä ei ole aikaa asentaa (ControllerPublishVolume) ennen kuin suoritamme lisäystoiminnon, kun yritämme asentaa, tarkistamme, että annettu levy on edelleen sisällä volumeResizeRequired ja palauttaa virheen;
  5. CSI-ohjain yrittää suorittaa koonmuutostoiminnon uudelleen. Jos toiminto onnistui, poista levy volumeResizeRequired;
  6. Koska Levytunnus puuttuu kohteesta volumeResizeRequired, ControllerPublishVolume läpäisee onnistuneesti, levy on asennettu, pod käynnistyy.

Kaikki näyttää riittävän yksinkertaiselta, mutta kuten aina, on sudenkuoppia. Suurentaa levyjä ulkoinen koon muuttaja, joka toiminnan aikana tapahtuneen virheen sattuessa käyttää jonoa aikakatkaisuajan eksponentiaalisella kasvulla jopa 1000 sekuntiin:

func DefaultControllerRateLimiter() RateLimiter {
  return NewMaxOfRateLimiter(
  NewItemExponentialFailureRateLimiter(5*time.Millisecond, 1000*time.Second),
  // 10 qps, 100 bucket size.  This is only for retry speed and its only the overall factor (not per item)
  &BucketRateLimiter{Limiter: rate.NewLimiter(rate.Limit(10), 100)},
  )
}

Tämä voi ajoittain johtaa siihen, että levyn laajennustoimintoa pidennetään yli 15 minuutiksi, jolloin vastaava pod ei ole käytettävissä.

Ainoa vaihtoehto, jonka avulla pystyimme lyhentämään mahdollisia seisokkeja melko helposti ja kivuttomasti, oli ulkoisen resizer-versiomme käyttö enimmäisaikarajoituksella. 5 sekunnissa:

workqueue.NewItemExponentialFailureRateLimiter(5*time.Millisecond, 5*time.Second)

Emme pitäneet tarpeellisena käynnistää kiireesti keskustelua ja korjata ulkoista koonmuuttajaa, koska levyjen offline-koon muuttaminen on takaisku, joka katoaa pian kaikilta pilvipalveluntarjoajilta.

Kuinka aloittaa sen käyttö?

Ohjainta tuetaan Kubernetes-versiossa 1.15 ja uudemmissa. Jotta kuljettaja voisi työskennellä, seuraavat vaatimukset on täytettävä:

  • lippu --allow-privileged asetettu arvoon true API-palvelimelle ja kubeletille;
  • Mukana --feature-gates=VolumeSnapshotDataSource=true,KubeletPluginsWatcher=true,CSINodeInfo=true,CSIDriverRegistry=true API-palvelimelle ja kubeletille;
  • Mount eteneminen (mount leviäminen) on otettava käyttöön klusterissa. Dockeria käytettäessä demoni on määritettävä sallimaan jaetut liitännät.

Kaikki tarvittavat vaiheet itse asennukseen kuvattu README:ssä. Asennus sisältää objektien luomisen Kubernetesiin luetteloista.

Kuljettajan työskentelyyn tarvitset seuraavat:

  • Määritä hakemiston tunniste luettelossa (folder-id) Yandex.Cloud (katso dokumentaatio);
  • CSI-ohjain käyttää palvelutiliä ollakseen vuorovaikutuksessa Yandex.Cloud API:n kanssa. Salaisessa luettelossa sinun on läpäistävä valtuutetut avaimet palvelutililtä. Dokumentaatiossa kuvattu, kuinka luodaan palvelutili ja hankitaan avaimet.

Kaikki kaikessa - kokeile sitä, ja otamme mielellämme palautetta vastaan uusia kysymyksiäjos kohtaat ongelmia!

Lisätuki

Tämän seurauksena haluamme huomauttaa, että otimme tämän CSI-ajurin käyttöön ei suuresta halusta pitää hauskaa sovellusten kirjoittamisessa Gossa, vaan yrityksen sisäisen kiireellisen tarpeen vuoksi. Meistä ei vaikuta käytännölliseltä ylläpitää omaa toteutustamme, joten jos Yandex osoittaa kiinnostusta ja päättää jatkaa kuljettajan tukemista, siirrämme arkiston mielellämme heille.

Lisäksi Yandexillä on todennäköisesti oma CSI-ajurin toteutus hallitussa Kubernetes-klusterissaan, joka voidaan julkaista avoimessa lähdekoodissa. Näemme myös tämän kehitysvaihtoehdon edullisena - yhteisö voi käyttää hyväksi todettua ajuria palveluntarjoajalta, ei kolmannelta osapuolelta.

PS.

Lue myös blogistamme:

Lähde: will.com

Lisää kommentti