ProHoster > Blog > Идораи > Таҷрибаи мо дар таҳияи драйвери CSI дар Kubernetes барои Yandex.Cloud

Таҷрибаи мо дар таҳияи драйвери CSI дар Kubernetes барои Yandex.Cloud

Таҷрибаи мо дар таҳияи драйвери CSI дар Kubernetes барои Yandex.Cloud

Мо бо хушнудӣ эълон мекунем, ки Flant саҳми худро ба абзорҳои кушодаасос барои Kubernetes тавассути интишори он васеъ мекунад. версияи алфа ронандаи CSI (Интерфейси нигаҳдории контейнер) барои Yandex.Cloud.

Аммо пеш аз гузаштан ба тафсилоти татбиқ, биёед ба савол ҷавоб диҳем, ки чаро ин умуман лозим аст, вақте ки Яндекс аллакай хидмат дорад Хидмати идорашаванда барои Kubernetes.

Муқаддима

Чаро ин аст?

Дар дохили ширкати мо, аз оғози истифодаи Kubernetes дар истеҳсолот (яъне чанд сол боз) мо асбоби шахсии худро (деckhouse) таҳия карда истодаем, ки дар омади гап, мо инчунин нақша дорем, ки ба зудӣ ҳамчун лоиҳаи кушодаасос дастрас кунем. . Бо кӯмаки он, мо ҳама кластерҳои худро яксон танзим ва танзим мекунем ва дар айни замон зиёда аз 100-тои онҳо дар конфигуратсияҳои гуногуни сахтафзор ва дар ҳама хидматҳои абрии дастрас мавҷуданд.

Кластерҳо, ки аз deckhouse истифода мебаранд, дорои тамоми ҷузъҳои барои фаъолият зарурӣ мебошанд: мувозинатҳо, мониторинг бо диаграммаҳои мувофиқ, метрика ва огоҳиҳо, аутентификатсияи корбар тавассути провайдерҳои беруна барои дастрасӣ ба ҳама панелҳои идоракунӣ ва ғайра. Дар ҳалли идорашаванда насб кардани чунин кластери "насосшуда" ҳеҷ маъно надорад, зеро ин аксар вақт ғайриимкон аст ё ба зарурати хомӯш кардани нисфи ҷузъҳо оварда мерасонад.

NB: Ин тачрибаи мост ва басо конкретй аст. Мо ба ҳеҷ ваҷҳ пешниҳод намекунем, ки ҳама ба ҷои истифодаи қарорҳои тайёр кластерҳои Kubernetes-ро мустақилона ҷойгир кунанд. Дар омади гап, мо таҷрибаи воқеии кор кардани Kubernetes аз Яндекс надорем ва мо дар ин мақола ба ин хидмат баҳо намедиҳем.

Он чӣ аст ва барои кӣ?

Ҳамин тавр, мо аллакай дар бораи равиши муосир ба нигоҳдорӣ дар Кубернетес сӯҳбат кардем: CSI чӣ гуна кор мекунад? и чӣ тавр ҷомеа омад ба ин муносибат.

Дар айни замон, бисёр провайдерҳои бузурги хидматрасонии абрӣ драйверҳоро барои истифодаи дискҳои абрии худ ҳамчун Ҳаҷми доимӣ дар Кубернетес таҳия кардаанд. Агар таъминкунанда чунин драйвер надошта бошад, аммо тамоми функсияҳои зарурӣ тавассути API таъмин карда шаванд, пас ҳеҷ чиз ба шумо барои амалӣ кардани драйвери худ халал намерасонад. Ин бо Yandex.Cloud рӯй дод.

Мо асоси тараккиётро гирифтем Ронандаи CSI барои абри DigitalOcean ва якчанд идеяҳо аз ронандагон барои GCP, зеро ҳамкорӣ бо API-и ин абрҳо (Google ва Яндекс) як қатор монандиҳо дорад. Аз ҷумла, API ва GCPва u Yandex объектро баргардонед Operation барои пайгирии ҳолати амалиёти дарозмуддат (масалан, сохтани диски нав). Барои ҳамкорӣ бо API Yandex.Cloud, истифода баред Yandex.Cloud Go SDK.

Натичаи кори ичрошуда дар GitHub нашр шудааст ва метавонад барои онҳое, ки бо ягон сабаб насбкунии Kubernetes-и худро дар мошинҳои виртуалии Yandex.Cloud истифода мебаранд (вале кластери омодаи идорашаванда) ва мехоҳанд дискҳоро тавассути CSI истифода баранд (фармоиш) муфид бошад.

Реализация

Хусусиятҳои асосӣ

Дар айни замон, драйвер вазифаҳои зеринро дастгирӣ мекунад:

  • Тартиб додани дискҳо дар ҳама минтақаҳои кластер мувофиқи топологияи гиреҳҳои кластер;
  • Хориҷ кардани дискҳои қаблан фармоишшуда;
  • Тағйир додани андозаи офлайнӣ барои дискҳо (Yandex.Cloud дастгирй намекунанд зиёд кардани дискҳое, ки ба мошини виртуалӣ насб карда шудаанд). Барои маълумот дар бораи он, ки чӣ гуна ронанда бояд тағир дода шавад, то андозааш то ҳадди имкон бедард бошад, ба поён нигаред.

Дар оянда мо нақша дорем, ки дастгирии эҷод ва нест кардани аксҳои дискро амалӣ созем.

Мушкилоти асосӣ ва чӣ гуна бартараф кардани он

Набудани қобилияти зиёд кардани дискҳо дар вақти воқеӣ дар API-и Yandex.Cloud маҳдудиятест, ки амалиёти тағир додани андозаро барои PV (Persistent Volume) мушкил мекунад: дар ин ҳолат зарур аст, ки паҳлӯи барномае, ки дискро истифода мебарад, қатъ карда шавад, ва ин метавонад боиси бекористии барномаҳо гардад.

Мувофиқи маълумот Мушаххасоти CSI, агар контролери CSI гузориш диҳад, ки он метавонад андозаи дискҳоро танҳо "офлайн" тағир диҳад (VolumeExpansion.OFFLINE), пас раванди зиёд кардани диск бояд чунин сурат гирад:

Агар плагин танҳо дошта бошад VolumeExpansion.OFFLINE иқтидори тавсеа ва ҳаҷм дар айни замон дар гиреҳ нашр ё дастрас аст ControllerExpandVolume БОЯД ТАНҲО пас аз яке даъват карда шавад:

  • Плагин дорои контроллер мебошад PUBLISH_UNPUBLISH_VOLUME қобилият ва ControllerUnpublishVolume бомуваффакият даъват карда шудааст.

Ё ДИГАР

  • Васлкунак контроллер надорад PUBLISH_UNPUBLISH_VOLUME қобилияти, плагин дорои гиреҳ STAGE_UNSTAGE_VOLUME қобилият ва NodeUnstageVolume бомуваффакият анчом ёфт.

Ё ДИГАР

  • Васлкунак контроллер надорад PUBLISH_UNPUBLISH_VOLUME қобилият, на гиреҳ STAGE_UNSTAGE_VOLUME қобилият ва NodeUnpublishVolume бомуваффакият анчом дод.

Ин аслан маънои онро дорад, ки шумо бояд пеш аз васеъ кардани он дискро аз мошини виртуалӣ ҷудо кунед.

Аммо, мутаассифона татбиқ Мушаххасоти CSI тавассути мошинҳои канорӣ ба ин талабот ҷавобгӯ нест:

  • Дар як контейнери паҳлӯ csi-attacher, ки бояд барои мавҷудияти фосилаи зарурӣ дар байни васлҳо масъул бошад, ин функсия танҳо дар тағир додани андозаи офлайн амалӣ карда намешавад. Дар ин бора сӯҳбат оғоз шуд дар ин ҷо.
  • Дар ин замина як контейнери паҳлӯӣ чӣ гуна аст? Худи плагини CSI бо API Kubernetes ҳамкорӣ намекунад, балки танҳо ба зангҳои gRPC, ки тавассути контейнерҳои паҳлӯ ба он фиристода мешаванд, ҷавоб медиҳад. Охирин инкишоф дода мешаванд аз ҷониби ҷомеаи Кубернетес.

Дар ҳолати мо (плагини CSI), амалиёти зиёд кардани диск чунин аст:

  1. Мо занги gRPC мегирем ControllerExpandVolume;
  2. Мо кӯшиш мекунем, ки дискро дар API афзоиш диҳем, аммо мо хатогиро дар бораи имконнопазирии иҷрои амалиёт мегирем, зеро диск васл шудааст;
  3. Мо идентификатори дискро дар харита нигоҳ медорем, ки дар он дискҳое мавҷуданд, ки барои онҳо амалиёти афзоиш бояд иҷро карда шавад. Дар зер, барои мухтасар, мо ин харитаро ҳамчун номида хоҳем кард volumeResizeRequired;
  4. Подчаеро, ки дискро истифода мебарад, дастӣ хориҷ кунед. Кубернетес онро аз нав оғоз мекунад. Барои он ки диск вақти насб кардан надошта бошад (ControllerPublishVolume) пеш аз ба итмом расонидани амалиёти афзоиш ҳангоми кӯшиши васлкунӣ, мо тафтиш мекунем, ки диски додашуда ҳанӯз дар дохили он аст volumeResizeRequired ва хато баргардонед;
  5. Ронандаи CSI кӯшиш мекунад, ки амалиёти тағир додани андозаро дубора иҷро кунад. Агар амалиёт муваффақ бошад, пас дискро аз он хориҷ кунед volumeResizeRequired;
  6. Зеро ID-диск аз volumeResizeRequired, ControllerPublishVolume бомуваффакият мегузарад, диск васл карда мешавад, подшох ба кор медарояд.

Ҳама чиз ба қадри кофӣ оддӣ ба назар мерасад, аммо чун ҳамеша домҳо вуҷуд доранд. Дискҳоро васеъ мекунад берунӣ-reizer, ки дар сурати руй додани хатой хангоми амалиёт навбатро истифода мебарад бо афзоиши экспоненсиалии вақт то 1000 сония:

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

Ин метавонад давра ба давра ба он оварда расонад, ки амалиёти тавсеаи диск барои 15+ дақиқа дароз карда шавад ва аз ин рӯ, поди мувофиқ дастнорас мешавад.

Ягона вариант, ки ба осонӣ ва бедард ба мо имкон дод, ки вақти бекористии эҳтимолиро кам кунем, ин истифодаи версияи мо аз resizer-и беруна бо маҳдудияти ҳадди аксар буд. дар 5 сония:

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

Мо зарур надонистем, ки ба таври фаврӣ оғоз кардани муҳокима ва часпак кардани тағирёбандаи беруна, зеро тағир додани андозаи офлайнии дискҳо як бозгаштест, ки ба зудӣ аз ҳама провайдерҳои абрӣ нест мешавад.

Чӣ тавр истифода бурданро оғоз кардан лозим аст?

Драйвер дар версияи Kubernetes 1.15 ва навтар дастгирӣ карда мешавад. Барои кори ронанда талаботи зерин бояд риоя карда шаванд:

  • Флаг --allow-privileged ба арзиш таъин кунед true барои API сервер ва kubelet;
  • Дохил карда шудааст --feature-gates=VolumeSnapshotDataSource=true,KubeletPluginsWatcher=true,CSINodeInfo=true,CSIDriverRegistry=true барои API сервер ва kubelet;
  • Паҳншавии кӯҳ (паҳншавии кӯҳӣ) бояд дар кластер фаъол карда шавад. Ҳангоми истифодаи Docker, демон бояд барои иҷозат додани васлҳои муштарак танзим карда шавад.

Ҳамаи қадамҳои зарурӣ барои худи насб дар README тавсиф шудааст. Насб сохтани объектҳоро дар Kubernetes аз манифестҳо дар бар мегирад.

Барои кор кардани ронанда ба шумо инҳо лозиманд:

  • Муайянкунандаи директорияро дар манифест (folder-id) Yandex.Cloud (ҳуҷҷатҳоро бубинед);
  • Барои ҳамкорӣ бо API Yandex.Cloud, ронандаи CSI ҳисоби хидматиро истифода мебарад. Дар манифест, Сир бояд гузашт калидҳои ваколатдор аз ҳисоби хидмат. Дар хуччатхо тавсиф карда шудааст, чӣ тавр эҷод кардани ҳисоби хидматӣ ва гирифтани калидҳо.

Умуман - кӯшиш кунед, ва мо аз гирифтани фикру мулоҳизаҳо ва масъалахои навагар шумо бо ягон мушкилот рӯ ба рӯ шавед!

Дастгирии минбаъда

Дар натиҷа, мо мехоҳем қайд кунем, ки мо ин драйвери CSI-ро на бо хоҳиши ҷолиб барои навиштани замимаҳо дар Go, балки аз сабаби зарурати фаврӣ дар дохили ширкат татбиқ кардем. Нигоҳ доштани татбиқи худ ба назари мо амалӣ нест, бинобар ин, агар Яндекс таваҷҷуҳ зоҳир кунад ва тасмим гирад, ки дастгирии ронандаро идома диҳад, мо бо хушнудӣ анборро ба онҳо интиқол медиҳем.

Илова бар ин, Яндекс эҳтимолан дар кластери идорашавандаи Kubernetes драйвери CSI-и худро дорад, ки онро дар Сарчашмаи Open баровардан мумкин аст. Мо инчунин ин варианти рушдро мусоид мешуморем - ҷомеа метавонад ронандаи собитшударо аз провайдери хидматрасон истифода барад, на аз ширкати сеюм.

PS

Инчунин дар блоги мо хонед:

Манбаъ: will.com

Илова Эзоҳ