ProHoster > Блог > басқарма > Yandex.Cloud үшін Kubernetes-те CSI драйверін әзірлеудегі біздің тәжірибеміз

Yandex.Cloud үшін Kubernetes-те CSI драйверін әзірлеудегі біздің тәжірибеміз

Yandex.Cloud үшін Kubernetes-те CSI драйверін әзірлеудегі біздің тәжірибеміз

Біз Flant компаниясының Kubernetes үшін ашық бастапқы құралдарға өз үлесін кеңейтіп жатқанын хабарлауға қуаныштымыз. CSI драйверінің альфа нұсқасы (Container Storage Interface) Yandex.Cloud үшін.

Бірақ іске асыру туралы егжей-тегжейлерге көшпес бұрын, Яндекстің қызметі бар болса, бұл не үшін қажет деген сұраққа жауап берейік Kubernetes үшін басқарылатын қызмет.

Кіріспе

Бұл не үшін?

Біздің компанияда Kubernetes-ті өндірісте қолданудың басынан бастап (яғни бірнеше жыл бойы) біз өз құралымызды (палубалық үй) жасап жатырмыз, айтпақшы, біз жақын арада ашық бастапқы жоба ретінде қол жетімді етуді жоспарлап отырмыз. . Оның көмегімен біз барлық кластерлерімізді біркелкі конфигурациялаймыз және конфигурациялаймыз және қазіргі уақытта олардың 100-ден астамы әртүрлі аппараттық конфигурацияларда және барлық қолжетімді бұлттық қызметтерде бар.

Deckhouse пайдаланатын кластерлерде жұмыс істеу үшін қажетті барлық құрамдас бөліктер бар: теңгерімдер, ыңғайлы диаграммалармен, көрсеткіштермен және ескертулермен бақылау, барлық бақылау тақталарына кіру үшін сыртқы провайдерлер арқылы пайдаланушы аутентификациясы және т.б. Басқарылатын шешімге мұндай «сорғылатын» кластерді орнатудың қажеті жоқ, өйткені бұл көбінесе мүмкін емес немесе компоненттердің жартысын өшіру қажеттілігіне әкеледі.

NB: Бұл біздің тәжірибеміз және ол өте нақты. Біз дайын шешімдерді пайдаланудың орнына барлығына Kubernetes кластерлерін өз бетімен орналастыруды ұсынбаймыз. Айтпақшы, бізде Яндекс-тен Kubernetes-ті пайдалану тәжірибесі жоқ және біз осы мақалада бұл қызметке ешқандай баға бермейміз.

Бұл не және кім үшін?

Сонымен, біз Kubernetes-те сақтаудың заманауи тәсілі туралы айттық: CSI қалай жұмыс істейді? и қоғам қалай келді бұл тәсілге.

Қазіргі уақытта көптеген ірі бұлттық қызмет провайдерлері бұлттық дискілерді Kubernetes-те тұрақты көлем ретінде пайдалану үшін драйверлерді әзірледі. Егер жеткізушіде мұндай драйвер болмаса, бірақ барлық қажетті функциялар API арқылы қамтамасыз етілсе, драйверді өзіңіз енгізуге ештеңе кедергі болмайды. Бұл Yandex.Cloud көмегімен болды.

Біз дамудың негізін алдық DigitalOcean бұлтына арналған CSI драйвері және бірнеше идеялар GCP үшін драйверлер, өйткені бұл бұлттардың API интерфейсімен өзара әрекеттесу (Google және Yandex) бірқатар ұқсастықтарға ие. Атап айтқанда, API және GCP, және y Яндекс нысанды қайтару Operation ұзақ орындалатын операциялардың күйін бақылау үшін (мысалы, жаңа дискіні жасау). Yandex.Cloud API интерфейсімен әрекеттесу үшін пайдаланыңыз Yandex.Cloud Go SDK.

Атқарылған жұмыстың нәтижесі GitHub сайтында жарияланған және қандай да бір себептермен Yandex.Cloud виртуалды машиналарында (бірақ дайын басқарылатын кластер емес) жеке Kubernetes орнатуын пайдаланатын және CSI арқылы дискілерді пайдаланғысы келетін (тапсырыс еткісі келетін) үшін пайдалы болуы мүмкін.

Реализация

Негізгі ерекшеліктері

Қазіргі уақытта драйвер келесі функцияларды қолдайды:

  • Кластердегі түйіндердің топологиясы бойынша кластердің барлық аймақтарында дискілерді ретке келтіру;
  • Бұрын тапсырыс берілген дискілерді алып тастау;
  • Дискілердің офлайн өлшемін өзгерту (Yandex.Cloud қолдамайды виртуалды машинаға орнатылған дискілерді көбейту). Өлшемін өзгертуді мүмкіндігінше ауыртпалықсыз ету үшін драйверді қалай өзгерту керектігі туралы ақпаратты төменде қараңыз.

Болашақта біз дискінің суреттерін жасау және жою үшін қолдауды енгізуді жоспарлап отырмыз.

Негізгі қиындық және оны жеңу жолы

Yandex.Cloud API-де нақты уақыт режимінде дискілерді ұлғайту мүмкіндігінің жоқтығы PV (тұрақты көлем) өлшемін өзгерту әрекетін қиындататын шектеу болып табылады: бұл жағдайда дискіні пайдаланатын қолданбалар бөлімін тоқтату керек, және бұл қолданбалардың тоқтап қалуына себеп болуы мүмкін.

бойынша 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 плагинінің өзі Kubernetes API интерфейсімен өзара әрекеттеспейді, бірақ оған қосалқы контейнерлер арқылы жіберілген gRPC қоңырауларына ғана жауап береді. Соңғы әзірленуде Кубернетес қауымдастығы.

Біздің жағдайда (CSI плагині) дискіні ұлғайту операциясы келесідей көрінеді:

  1. Біз gRPC қоңырауын аламыз ControllerExpandVolume;
  2. Біз API-де дискіні ұлғайтуға тырысамыз, бірақ операцияны орындау мүмкін еместігі туралы қатені аламыз, себебі диск орнатылған;
  3. Біз диск идентификаторын картада сақтаймыз, онда көбейту операциясын орындау қажет дискілер бар. Төменде, қысқаша айтқанда, біз бұл картаны деп атаймыз volumeResizeRequired;
  4. Дискіні пайдаланып жатқан подкастты қолмен алып тастаңыз. Кубернетес оны қайта іске қосады. Дискіні орнатуға уақыт болмас үшін (ControllerPublishVolume) монтаждау әрекетін орындау кезінде ұлғайту операциясын аяқтамас бұрын, біз берілген дискінің әлі ішінде екенін тексереміз volumeResizeRequired және қатені қайтарады;
  5. CSI драйвері өлшемді өзгерту әрекетін қайта орындауға тырысады. Егер операция сәтті болса, дискіні алып тастаңыз volumeResizeRequired;
  6. Өйткені Диск идентификаторы жоқ volumeResizeRequired, ControllerPublishVolume сәтті өтті, диск орнатылды, подвод іске қосылады.

Барлығы жеткілікті қарапайым көрінеді, бірақ әдеттегідей тұзақтар бар. Дискілерді үлкейтеді сыртқы размер, ол операция кезінде қате болған жағдайда кезекті пайдаланады күту уақытының экспоненциалды ұлғаюымен 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+ минутқа ұзартылуына және сәйкес подкасттың қолжетімсіз болуына әкелуі мүмкін.

Ықтимал үзіліс уақытын азайтуға оңай және ауыртпалықсыз мүмкіндік беретін жалғыз нұсқа - максималды күту шегі бар сыртқы размердің нұсқасын пайдалану. 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 (құжаттаманы қараңыз);
  • Yandex.Cloud API интерфейсімен әрекеттесу үшін CSI драйвері қызметтік тіркелгіні пайдаланады. Манифестте Құпия өтуі керек рұқсат етілген кілттер қызмет есептік жазбасынан. Құжаттамада сипатталған, қызмет тіркелгісін жасау және кілттерді алу жолы.

Жалпы - сынап көріңіз, және біз кері байланыс алуға қуаныштымыз және жаңа мәселелерқандай да бір қиындықтарға тап болсаңыз!

Қосымша қолдау

Нәтижесінде, біз бұл CSI драйверін Go қолданбасында көңілді қосымшалар жазуға деген үлкен ықыласпен емес, компаниядағы шұғыл қажеттіліктен енгізгенімізді атап өткіміз келеді. Бізге өз енгізуімізді сақтау практикалық емес болып көрінеді, сондықтан егер Яндекс қызығушылық танытып, драйверді қолдауды жалғастыруды шешсе, біз репозиторийді оларға беруге қуаныштымыз.

Сонымен қатар, Яндекстің басқарылатын Kubernetes кластерінде CSI драйверін іске асыру бар, оны Open Source түрінде шығаруға болады. Біз сондай-ақ бұл әзірлеу нұсқасын қолайлы деп санаймыз - қауымдастық үшінші тарап компаниясының емес, қызмет провайдерінің дәлелденген драйверін пайдалана алады.

PS

Біздің блогта да оқыңыз:

Ақпарат көзі: www.habr.com

пікір қалдыру