ProHoster > Blog > Adminisztráció > CSI-illesztőprogram fejlesztésében szerzett tapasztalatunk Kubernetesben a Yandex.Cloud számára

CSI-illesztőprogram fejlesztésében szerzett tapasztalatunk Kubernetesben a Yandex.Cloud számára

CSI-illesztőprogram fejlesztésében szerzett tapasztalatunk Kubernetesben a Yandex.Cloud számára

Örömmel jelentjük be, hogy a Flant kibővíti hozzájárulását a Kubernetes nyílt forráskódú eszközeihez a kiadással a CSI illesztőprogram alfa verziója (Container Storage Interface) a Yandex.Cloud számára.

Mielőtt azonban rátérnénk a megvalósítás részleteire, válaszoljunk arra a kérdésre, hogy miért van erre egyáltalán szükség, amikor a Yandexnek már van szolgáltatása Felügyelt szolgáltatás a Kubernetes számára.

Bevezetés

Miért ez?

Cégünkön belül a Kubernetes termelésben való használatának kezdetétől (azaz már több éve) fejlesztjük saját eszközünket (deckhouse), amelyet egyébként hamarosan nyílt forráskódú projektként is tervezünk elérhetővé tenni. . Segítségével egységesen konfiguráljuk és konfiguráljuk az összes klaszterünket, jelenleg már több mint 100 van belőlük, sokféle hardverkonfiguráción és az összes elérhető felhőszolgáltatásban.

A deckhouse-t használó fürtök rendelkeznek a működéshez szükséges összes komponenssel: egyensúlyozók, kényelmes diagramokkal, mérőszámokkal és riasztásokkal történő monitorozás, külső szolgáltatókon keresztül történő felhasználói hitelesítés az összes műszerfalhoz való hozzáféréshez stb. Nincs értelme ilyen „felpumpált” klasztert telepíteni egy felügyelt megoldásba, mivel ez gyakran lehetetlen, vagy az összetevők felét le kell tiltani.

NB: Ez a mi tapasztalatunk, és elég konkrét. Semmiképpen sem javasoljuk, hogy mindenki saját maga telepítse a Kubernetes-fürtöket, ahelyett, hogy kész megoldásokat használna. Mellesleg nincs valódi tapasztalatunk a Kubernetes Yandex üzemeltetésében, és ebben a cikkben nem adunk értékelést erről a szolgáltatásról.

Mi ez és kinek?

Tehát már beszéltünk a Kubernetes tárolásának modern megközelítéséről: hogyan működik a CSI? и hogyan jött a közösség ehhez a megközelítéshez.

Jelenleg sok nagy felhőszolgáltató kifejlesztett illesztőprogramokat felhőlemezeinek állandó kötetként való használatához a Kubernetesben. Ha a szállító nem rendelkezik ilyen illesztőprogrammal, de az összes szükséges funkciót az API-n keresztül biztosítják, akkor semmi sem akadályozza meg, hogy saját maga implementálja az illesztőprogramot. Ez történt a Yandex.Cloud esetében.

A fejlesztés alapjául vettük CSI-illesztőprogram a DigitalOcean felhőhöz és pár ötlet innen illesztőprogramok a GCP-hez, mivel e felhők API-jával (Google és Yandex) való interakció számos hasonlóságot mutat. Különösen az API és GCP, és itt Yandex visszaad egy tárgyat Operation a régóta futó műveletek állapotának nyomon követésére (például új lemez létrehozása). A Yandex.Cloud API-val való interakcióhoz használja a Yandex.Cloud Go SDK.

Az elvégzett munka eredménye megjelent a GitHubon és hasznos lehet azoknak, akik valamilyen oknál fogva saját Kubernetes-telepítést használnak Yandex.Cloud virtuális gépeken (de nem kész menedzselt fürtöt), és CSI-n keresztül szeretnének lemezeket használni (rendelni).

Реализация

Főbb jellemzők

Jelenleg az illesztőprogram a következő funkciókat támogatja:

  • Lemezek rendezése a fürt összes zónájában a fürt csomópontjainak topológiája szerint;
  • Korábban megrendelt lemezek eltávolítása;
  • Offline átméretezés lemezekhez (Yandex.Cloud ne támogassa a virtuális gépre csatlakoztatott lemezek számának növelése). Az alábbiakban olvashat arról, hogyan kellett módosítani az illesztőprogramot, hogy az átméretezés a lehető legfájdalmasabb legyen.

A jövőben tervezzük a lemezpillanatképek létrehozásának és törlésének támogatását.

A fő nehézség és a leküzdés módja

A Yandex.Cloud API-ban a lemezek valós idejű növelésének hiánya olyan korlát, amely megnehezíti a PV (Persistent Volume) átméretezési műveletét: ebben az esetben le kell állítani a lemezt használó alkalmazáscsomagot, és ez leállási alkalmazásokat okozhat.

Szerint CSI specifikációk, ha a CSI vezérlő azt jelenti, hogy csak „offline” módban tudja átméretezni a lemezeket (VolumeExpansion.OFFLINE), akkor a lemez növelésének a következőképpen kell történnie:

Ha a plugin csak VolumeExpansion.OFFLINE a bővítési képesség és kötet jelenleg közzé van téve vagy elérhető egy csomóponton ControllerExpandVolume CSAK bármelyik után KELL hívni:

  • A plugin rendelkezik vezérlővel PUBLISH_UNPUBLISH_VOLUME képesség és ControllerUnpublishVolume sikeresen meg lett hívva.

KÜLÖNBEN

  • A bővítmény NINCS vezérlővel PUBLISH_UNPUBLISH_VOLUME képesség, a bővítménynek van csomópontja STAGE_UNSTAGE_VOLUME képesség, és NodeUnstageVolume sikeresen befejeződött.

KÜLÖNBEN

  • A bővítmény NINCS vezérlővel PUBLISH_UNPUBLISH_VOLUME képesség, sem csomópont STAGE_UNSTAGE_VOLUME képesség, és NodeUnpublishVolume sikeresen befejezte.

Ez lényegében azt jelenti, hogy le kell választani a lemezt a virtuális gépről, mielőtt bővítené.

Azonban sajnos végrehajtás Az oldalkocsikon keresztüli CSI specifikáció nem felel meg a következő követelményeknek:

  • Oldalkocsis konténerben csi-attacher, amelynek felelősnek kell lennie a rögzítések közötti szükséges rés meglétéért, ez a funkció egyszerűen nincs megvalósítva az offline átméretezésben. Erről vita indult itt.
  • Mi is pontosan ebben az összefüggésben az oldalkocsis konténer? Maga a CSI beépülő modul nem lép interakcióba a Kubernetes API-val, csak az oldalkocsis tárolók által neki küldött gRPC-hívásokra válaszol. Legújabb fejlesztés alatt állnak a Kubernetes közösség által.

Esetünkben (CSI plugin) a lemez növelésének művelete így néz ki:

  1. GRPC hívást kapunk ControllerExpandVolume;
  2. Megpróbáljuk növelni a lemezt az API-ban, de hibaüzenetet kapunk a művelet végrehajtásának lehetetlenségéről, mert a lemez fel van szerelve;
  3. A lemezazonosítót térképen tároljuk, amely azokat a lemezeket tartalmazza, amelyeknél a növelési műveletet el kell végezni. Az alábbiakban a rövidség kedvéért ezt a térképet a következőnek nevezzük volumeResizeRequired;
  4. Kézzel távolítsa el a lemezt használó tokot. A Kubernetes újraindítja. Hogy a lemeznek ne legyen ideje felcsatolni (ControllerPublishVolume) mielőtt a felcsatolás megkísérlésekor befejeznénk a növelési műveletet, ellenőrizzük, hogy az adott lemez még benne van-e volumeResizeRequired és hibát ad vissza;
  5. A CSI-illesztőprogram megpróbálja újra végrehajtani az átméretezési műveletet. Ha a művelet sikeres volt, távolítsa el a lemezt volumeResizeRequired;
  6. Mert A lemezazonosító hiányzik innen volumeResizeRequired, ControllerPublishVolume sikeresen halad, a lemez fel van szerelve, a pod elindul.

Minden elég egyszerűnek tűnik, de mint mindig, vannak buktatók. Nagyítja a lemezeket külső átméretező, amely a művelet során fellépő hiba esetén sort használ az időtúllépési idő exponenciális növekedésével 1000 másodpercig:

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)},
  )
}

Ez időnként azt eredményezheti, hogy a lemezbővítési művelet 15+ percre meghosszabbodik, és így a megfelelő pod nem érhető el.

Az egyetlen lehetőség, amellyel könnyedén és fájdalommentesen csökkenthettük az esetleges állásidőt, a külső átméretező maximális időkorláttal rendelkező verziójának használata volt. 5 másodperc alatt:

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

Nem tartottuk szükségesnek sürgősen vitát kezdeményezni és a külső átméretező foltozását, mert a lemezek offline átméretezése egy olyan visszatérés, amely hamarosan minden felhőszolgáltatótól eltűnik.

Hogyan kell elkezdeni használni?

Az illesztőprogramot a Kubernetes 1.15 és újabb verziója támogatja. A sofőr munkához a következő követelményeknek kell megfelelniük:

  • zászló --allow-privileged értékre állítva true API szerverhez és kubelethez;
  • Beleértve --feature-gates=VolumeSnapshotDataSource=true,KubeletPluginsWatcher=true,CSINodeInfo=true,CSIDriverRegistry=true API szerverhez és kubelethez;
  • Szerelési terjedés (mount terjedése) engedélyezni kell a fürtön. A Docker használatakor a démont úgy kell konfigurálni, hogy engedélyezze a megosztott csatolásokat.

Magához a telepítéshez szükséges összes lépés a README-ben leírtak. A telepítés magában foglalja az objektumok létrehozását a Kubernetesben a jegyzékekből.

A sofőr munkájához a következőkre lesz szüksége:

  • Adja meg a könyvtárazonosítót a jegyzékben (folder-id) Yandex.Cloud (lásd a dokumentációt);
  • A Yandex.Cloud API-val való interakcióhoz a CSI-illesztőprogram szolgáltatásfiókot használ. A manifesztben át kell adni a Titkot engedélyezett kulcsok a szolgáltatási fiókból. A dokumentációban leírta, hogyan lehet szolgáltatásfiókot létrehozni és kulcsokat szerezni.

Összességében - megpróbál, és szívesen fogadunk visszajelzést és új kérdéseketha bármilyen problémába ütközik!

További támogatás

Ennek eredményeként szeretnénk megjegyezni, hogy ezt a CSI-illesztőprogramot nem azért hoztuk létre, mert a Go-ban jól szórakoztunk, hanem a vállalaton belüli sürgető igény miatt. Számunkra nem tűnik praktikusnak a saját megvalósításunk fenntartása, ezért ha a Yandex érdeklődést mutat, és úgy dönt, hogy továbbra is támogatja az illesztőprogramot, szívesen átadjuk nekik az adattárat.

Ezenkívül a Yandex valószínűleg rendelkezik saját CSI-illesztőprogram-megvalósítással a felügyelt Kubernetes-fürtben, amely nyílt forráskódú formában is kiadható. Ezt a fejlesztési lehetőséget is kedvezőnek látjuk – a közösség nem külső cégtől, hanem szolgáltatótól bevált drivert használhat majd.

PS

Olvassa el blogunkon is:

Forrás: will.com

Hozzászólás