ProHoster > Блог > Захиргаа > Yandex.Cloud-д зориулсан Kubernetes-д CSI драйвер хөгжүүлэх бидний туршлага

Yandex.Cloud-д зориулсан Kubernetes-д CSI драйвер хөгжүүлэх бидний туршлага

Yandex.Cloud-д зориулсан Kubernetes-д CSI драйвер хөгжүүлэх бидний туршлага

Flant нь Kubernetes-д зориулсан Нээлттэй эхийн хэрэгслүүдэд оруулах хувь нэмрээ өргөжүүлж байгааг дуулгахад таатай байна. CSI драйверын альфа хувилбар Yandex.Cloud-д зориулсан (Container Storage Interface).

Гэхдээ хэрэгжилтийн дэлгэрэнгүй мэдээлэл рүү шилжихээсээ өмнө Yandex аль хэдийн үйлчилгээтэй байхад яагаад энэ хэрэгтэй вэ гэсэн асуултанд хариулъя Kubernetes-д зориулсан удирдлагатай үйлчилгээ.

Танилцуулга

Яагаад энэ вэ?

Манай компани дотроо Kubernetes-ийг үйлдвэрлэлд ашиглаж эхэлснээс хойш (жишээ нь хэдэн жилийн турш) бид өөрсдийн хэрэгслийг (давцангийн байшин) боловсруулж байгаа бөгөөд дашрамд хэлэхэд бид удахгүй Нээлттэй эхийн төсөл болгон ашиглахаар төлөвлөж байна. . Үүний тусламжтайгаар бид бүх кластеруудаа жигд тохируулж, тохируулж байгаа бөгөөд одоогоор тэдгээрийн 100 гаруй нь олон төрлийн техник хангамжийн тохиргоо болон бүх боломжтой үүлэн үйлчилгээнд байгаа.

Тавцангийн байшинг ашигладаг кластерууд нь үйл ажиллагаанд шаардлагатай бүх бүрэлдэхүүн хэсгүүдтэй байдаг: тэнцвэржүүлэгч, тохиромжтой график, хэмжүүр, дохиолол бүхий хяналт, бүх хяналтын самбарт нэвтрэх гадны үйлчилгээ үзүүлэгчээр дамжуулан хэрэглэгчийн баталгаажуулалт гэх мэт. Удирдлагын шийдэлд ийм "шахсан" кластер суулгах нь утгагүй юм, учир нь энэ нь ихэвчлэн боломжгүй эсвэл бүрэлдэхүүн хэсгүүдийн талыг идэвхгүй болгоход хүргэдэг.

NB: Энэ бол бидний туршлага бөгөөд маш тодорхой юм. Бид бэлэн шийдлүүдийг ашиглахын оронд хүн бүр Кубернетес кластеруудыг бие даан байрлуулахыг санал болгохгүй байна. Дашрамд хэлэхэд, бид Yandex-ээс Kubernetes-ийг ажиллуулах бодит туршлагагүй бөгөөд бид энэ нийтлэлд энэ үйлчилгээний талаар ямар ч үнэлгээ өгөхгүй.

Энэ юу вэ, хэнд зориулагдсан бэ?

Тиймээс бид Кубернетес дэх хадгалах орчин үеийн аргын талаар аль хэдийн ярьсан. CSI хэрхэн ажилладаг вэ? и нийгэмлэг хэрхэн ирсэн энэ хандлагад.

Одоогийн байдлаар олон томоохон үүлэн үйлчилгээ үзүүлэгчид үүлэн дискээ Kubernetes-д Persistent Volume болгон ашиглах драйверуудыг боловсруулсан. Хэрэв ханган нийлүүлэгч нь ийм драйвергүй боловч шаардлагатай бүх функцийг API-ээр хангадаг бол драйверийг өөрөө хэрэгжүүлэхэд юу ч саад болохгүй. Yandex.Cloud-д ийм зүйл тохиолдсон.

Бид хөгжлийн үндэс болгон авсан DigitalOcean үүлэнд зориулсан CSI драйвер болон хэд хэдэн санаа GCP-д зориулсан драйверууд, учир нь эдгээр үүлсийн API-тай (Google болон Yandex) харилцан үйлчлэлцэх нь хэд хэдэн ижил төстэй шинж чанартай байдаг. Ялангуяа API болон GCP, мөн Yandex объект буцаана Operation урт хугацааны үйл ажиллагааны статусыг хянах (жишээлбэл, шинэ диск үүсгэх). Yandex.Cloud API-тай харилцахын тулд ашиглана уу Yandex.Cloud Go SDK.

Хийсэн ажлын үр дүн GitHub дээр нийтлэгдсэн Энэ нь ямар нэг шалтгааны улмаас Yandex.Cloud виртуал машин дээр Кубернетес суулгацыг ашигладаг (гэхдээ бэлэн удирддаг кластер биш) болон CSI-ээр дамжуулан диск ашиглахыг (захиалах) хүмүүст хэрэгтэй байж болох юм.

Реализация

Гол онцлог

Одоогийн байдлаар драйвер нь дараах функцуудыг дэмждэг.

  • Кластер дахь зангилааны топологийн дагуу кластерын бүх бүсэд дискийг захиалах;
  • Өмнө нь захиалсан дискийг арилгах;
  • Дискний офлайн хэмжээг өөрчлөх (Yandex.Cloud дэмжихгүй байна виртуал машинд суурилуулсан дискийг нэмэгдүүлэх). Хэмжээг нь аль болох өвдөлтгүй өөрчлөхийн тулд жолоочийг хэрхэн өөрчлөх шаардлагатай байсан талаарх мэдээллийг доороос үзнэ үү.

Цаашид бид дискний хормын хувилбарыг үүсгэх, устгахад дэмжлэг үзүүлэхээр төлөвлөж байна.

Гол бэрхшээл, түүнийг хэрхэн даван туулах вэ

Yandex.Cloud API-д дискийг бодит цаг хугацаанд нэмэгдүүлэх чадваргүй байгаа нь PV (Тогтвортой хэмжээ)-ийн хэмжээг өөрчлөх үйлдлийг хүндрүүлдэг хязгаарлалт юм: энэ тохиолдолд дискийг ашигладаг програмын хэсгийг зогсоох шаардлагатай. мөн энэ нь програмуудыг сул зогсолт үүсгэж болзошгүй.

Дагуу CSI үзүүлэлтүүд, хэрэв CSI хянагч зөвхөн "офлайн" дискний хэмжээг өөрчлөх боломжтой гэж мэдээлсэн бол (VolumeExpansion.OFFLINE), дараа нь дискийг нэмэгдүүлэх үйл явц дараах байдлаар явагдах ёстой.

Хэрэв залгаас зөвхөн байгаа бол VolumeExpansion.OFFLINE өргөтгөх чадвар, хэмжээ нь одоогоор хэвлэгдсэн эсвэл зангилаа дээр ашиглах боломжтой ControllerExpandVolume ЗӨВХӨН аль нэгний дараа залгах ёстой:

  • Plugin нь хянагчтай PUBLISH_UNPUBLISH_VOLUME чадвар ба ControllerUnpublishVolume амжилттай дуудагдсан.

ЭСВЭЛ ӨӨР

  • Plugin нь хянагчгүй PUBLISH_UNPUBLISH_VOLUME чадвар, залгаас нь зангилаатай STAGE_UNSTAGE_VOLUME чадвар, ба NodeUnstageVolume амжилттай дууслаа.

ЭСВЭЛ ӨӨР

  • Plugin нь хянагчгүй 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. Учир нь Дискний ID байхгүй байна volumeResizeRequired, ControllerPublishVolume амжилттай дамжуулж, дискийг суулгаж, pod ажиллаж эхэлнэ.

Бүх зүйл хангалттай энгийн харагддаг, гэхдээ үргэлж тулгардаг бэрхшээлүүд байдаг. Дискүүдийг томруулдаг гадаад дахин тохируулагч, энэ нь үйл ажиллагааны явцад алдаа гарсан тохиолдолд дараалал ашигладаг 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 ба түүнээс дээш хувилбар дээр дэмжигддэг. Жолооч ажиллахын тулд дараахь шаардлагыг хангасан байх ёстой.

  • Flag --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 дээр програм бичихдээ хөгжилтэй байх гэсэн хүсэлдээ биш, харин компани доторх яаралтай хэрэгцээ шаардлагаас үүдэн хэрэгжүүлсэн гэдгийг тэмдэглэхийг хүсч байна. Өөрсдийн хэрэгжүүлэлтээ үргэлжлүүлэх нь бидний хувьд практик биш юм шиг санагдаж байгаа тул хэрэв Yandex сонирхож байгаа бөгөөд жолоочийг үргэлжлүүлэн дэмжихээр шийдсэн бол бид хадгалах газрыг тэдэнд шилжүүлэхэд таатай байх болно.

Нэмж дурдахад Yandex нь өөрийн удирддаг Kubernetes кластерт CSI драйверын өөрийн хэрэгжүүлэлттэй байж магадгүй бөгөөд үүнийг Нээлттэй эх сурвалж дээр гаргах боломжтой. Мөн бид энэхүү хөгжүүлэлтийн сонголтыг таатай гэж үзэж байна - олон нийт гуравдагч талын компаниас биш үйлчилгээ үзүүлэгчийн батлагдсан драйверийг ашиглах боломжтой болно.

PS

Мөн манай блог дээрээс уншина уу:

Эх сурвалж: www.habr.com

сэтгэгдэл нэмэх