ProHoster > Blog > башкаруу > Yandex.Cloud үчүн Kubernetesте CSI драйверин иштеп чыгуу боюнча биздин тажрыйбабыз

Yandex.Cloud үчүн Kubernetesте CSI драйверин иштеп чыгуу боюнча биздин тажрыйбабыз

Yandex.Cloud үчүн Kubernetesте CSI драйверин иштеп чыгуу боюнча биздин тажрыйбабыз

Flant Кубернетес үчүн ачык булак куралдарына салымын кеңейтип жатканын жарыялоого кубанычтабыз. 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, жана Яндекс объектти кайтаруу 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 ийгиликтүү аяктады.

Бул дискти кеңейтүүдөн мурун аны виртуалдык машинадан ажыратышыңыз керек дегенди билдирет.

Бирок, тилекке каршы ишке ашыруу Sidecars аркылуу CSI спецификациясы бул талаптарга жооп бербейт:

  • Капталдагы контейнерде csi-attacher, монтаждын ортосунда талап кылынган боштуктун болушу үчүн жооптуу болушу керек, бул функция оффлайн өлчөмүн өзгөртүүдө жөн гана ишке ашырылган эмес. Бул боюнча талкуу башталды бул жерде.
  • Бул контекстте каптал контейнер деген эмне? CSI плагининин өзү Kubernetes API менен иштешпейт, бирок ага каптал контейнерлери аркылуу жөнөтүлгөн gRPC чалууларына гана жооп берет. Акыркы иштеп жатышат Kubernetes коомчулугу тарабынан.

Биздин учурда (CSI плагини), дискти көбөйтүү операциясы төмөнкүдөй көрүнөт:

  1. Биз gRPC чалуусун алабыз ControllerExpandVolume;
  2. Биз API'де дискти көбөйтүүгө аракет кылып жатабыз, бирок диск орнотулгандыктан операцияны аткаруу мүмкүн эместиги жөнүндө ката алабыз;
  3. Биз дисктин идентификаторун картада сактайбыз, анда көбөйтүү операциясы аткарылышы керек болгон дисктер бар. Төмөндө, биз бул картаны кыскача деп атайбыз volumeResizeRequired;
  4. Дискти колдонуп жаткан капчыгайды кол менен алып салыңыз. Kubernetes аны кайра иштетет. Дискти орнотууга убакыт жок болушу үчүн (ControllerPublishVolume) орнотууга аракет кылып жатканда көбөйтүү операциясын аяктоодон мурун, биз берилген диск дагы эле ичинде экенин текшеребиз volumeResizeRequired жана ката кайтаруу;
  5. CSI драйвери өлчөмүн өзгөртүү операциясын кайра аткарууга аракет кылат. Эгер операция ийгиликтүү болсо, анда дискти алып салыңыз volumeResizeRequired;
  6. Анткени Диск ID жок 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 үчүн;
  • Тоонун таралышы (жайылтуу) кластерде иштетилиши керек. Докерди колдонгондо, демон бөлүшүлгөн орнотууларга уруксат берүү үчүн конфигурацияланышы керек.

орнотуу үчүн бардык зарыл болгон кадамдар READMEде сүрөттөлгөн. Орнотуу манифесттерден Kubernetesте объекттерди түзүүнү камтыйт.

Айдоочу иштеши үчүн сизге төмөнкүлөр керек болот:

  • Манифестте каталог идентификаторун көрсөтүңүз (folder-id) Yandex.Cloud (документтерди кара);
  • Yandex.Cloud API менен иштешүү үчүн CSI драйвери кызмат эсебин колдонот. Манифестте, Secret өтүшү керек ыйгарым укуктуу ачкычтар кызмат эсебинен. Документте сүрөттөлгөн, кантип кызмат эсебин түзүү жана ачкычтарды алуу.

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

Андан ары колдоо

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

Мындан тышкары, Яндекс, кыязы, анын башкарылган Kubernetes кластеринде CSI драйверин өзүнүн ишке ашырууга ээ, аны Open Sourceде чыгарууга болот. Биз ошондой эле өнүгүүнүн бул вариантын жагымдуу деп эсептейбиз - коомчулук үчүнчү тараптын компаниясынын эмес, кызмат көрсөтүүчү провайдердин далилденген драйверин колдоно алат.

PS

Биздин блогдон дагы окуңуз:

Source: www.habr.com

Комментарий кошуу