Ang aming karanasan sa pagbuo ng isang CSI driver sa Kubernetes para sa Yandex.Cloud

Ikinalulugod naming ipahayag na pinalawak ng Flant ang kontribusyon nito sa mga tool na Open Source para sa Kubernetes sa pamamagitan ng pagpapalabas alpha na bersyon ng CSI driver (Container Storage Interface) para sa Yandex.Cloud.

Ngunit bago magpatuloy sa mga detalye ng pagpapatupad, sagutin natin ang tanong kung bakit kailangan ito kapag mayroon nang serbisyo ang Yandex Pinamamahalaang Serbisyo para sa Kubernetes.

Pagpapakilala

Bakit ito?

Sa loob ng aming kumpanya, mula sa simula ng paggamit ng Kubernetes sa produksyon (ibig sabihin, sa loob ng ilang taon na ngayon), kami ay gumagawa ng aming sariling tool (deckhouse), na, sa pamamagitan ng paraan, plano rin naming gawing available sa lalong madaling panahon bilang isang Open Source na proyekto. . Sa tulong nito, pare-pareho naming kino-configure at kino-configure ang lahat ng aming mga cluster, at sa kasalukuyan ay mayroon nang higit sa 100 sa kanila, sa isang malawak na iba't ibang mga configuration ng hardware at sa lahat ng magagamit na mga serbisyo sa cloud.

Nasa mga cluster na gumagamit ng deckhouse ang lahat ng sangkap na kinakailangan para sa operasyon: mga balancer, pagsubaybay na may mga maginhawang chart, sukatan at alerto, pagpapatunay ng user sa pamamagitan ng mga external na provider para sa access sa lahat ng dashboard, at iba pa. Walang punto sa pag-install ng tulad ng isang "pumped up" na kumpol sa isang pinamamahalaang solusyon, dahil ito ay madalas na imposible o hahantong sa pangangailangan na huwag paganahin ang kalahati ng mga bahagi.

NB: Ito ang aming karanasan, at ito ay medyo tiyak. Hindi namin iminumungkahi na ang lahat ay dapat mag-deploy ng mga Kubernetes cluster sa kanilang sarili sa halip na gumamit ng mga handa na solusyon. Sa pamamagitan ng paraan, wala kaming tunay na karanasan sa pagpapatakbo ng Kubernetes mula sa Yandex at hindi kami magbibigay ng anumang pagtatasa sa serbisyong ito sa artikulong ito.

Ano ito at para kanino?

Kaya, napag-usapan na natin ang tungkol sa modernong diskarte sa pag-iimbak sa Kubernetes: paano gumagana ang CSI? и kung paano dumating ang komunidad sa ganitong paraan.

Sa kasalukuyan, maraming malalaking cloud service provider ang bumuo ng mga driver para sa paggamit ng kanilang mga cloud disk bilang Persistent Volume sa Kubernetes. Kung ang tagapagtustos ay walang ganoong driver, ngunit ang lahat ng mga kinakailangang pag-andar ay ibinibigay sa pamamagitan ng API, kung gayon walang pumipigil sa iyo na ipatupad ang driver mismo. Ito ang nangyari sa Yandex.Cloud.

Kinuha namin bilang batayan para sa pag-unlad CSI driver para sa DigitalOcean cloud at ilang ideya mula sa mga driver para sa GCP, dahil ang pakikipag-ugnayan sa API ng mga ulap na ito (Google at Yandex) ay may ilang pagkakatulad. Sa partikular, ang API at GCP, at Yandex ibalik ang isang bagay Operation upang subaybayan ang katayuan ng mga matagal nang pagpapatakbo (halimbawa, paglikha ng bagong disk). Upang makipag-ugnayan sa Yandex.Cloud API, gamitin Yandex.Cloud Go SDK.

Ang resulta ng gawaing ginawa na-publish sa GitHub at maaaring maging kapaki-pakinabang para sa mga taong, sa ilang kadahilanan, ay gumagamit ng kanilang sariling pag-install ng Kubernetes sa Yandex.Cloud virtual machine (ngunit hindi isang handa na pinamamahalaang cluster) at gustong gumamit ng (mag-order) ng mga disk sa pamamagitan ng CSI.

Pagpapatupad

Pangunahing mga tampok

Sa kasalukuyan, sinusuportahan ng driver ang mga sumusunod na function:

• Pag-order ng mga disk sa lahat ng mga zone ng cluster ayon sa topology ng mga node sa cluster;
• Pag-alis ng mga naunang iniutos na disc;
• Offline na pagbabago ng laki para sa mga disk (Yandex.Cloud huwag sumuporta pagtaas ng mga disk na naka-mount sa virtual machine). Para sa impormasyon kung paano kailangang baguhin ang driver upang gawing hindi masakit ang pagbabago ng laki hangga't maaari, tingnan sa ibaba.

Sa hinaharap, plano naming magpatupad ng suporta para sa paggawa at pagtanggal ng mga snapshot ng disk.

Ang pangunahing kahirapan at kung paano ito malalampasan

Ang kakulangan ng kakayahang dagdagan ang mga disk sa real time sa Yandex.Cloud API ay isang limitasyon na nagpapalubha sa pagpapalit ng laki ng operasyon para sa PV (Persistent Volume): sa kasong ito, kinakailangan na ang application pod na gumagamit ng disk ay ihinto, at ito ay maaaring magdulot ng mga downtime na application.

Ayon sa Mga pagtutukoy ng CSI, kung ang CSI controller ay nag-uulat na maaari nitong baguhin ang laki ng mga disk "offline" lamang (VolumeExpansion.OFFLINE), kung gayon ang proseso ng pagtaas ng disk ay dapat na ganito:

Kung ang plugin ay mayroon lamang VolumeExpansion.OFFLINE Kasalukuyang na-publish o available sa isang node noon ang kakayahan at volume ng pagpapalawak ControllerExpandVolume DAPAT tawagan LAMANG pagkatapos ng alinman sa:

• Ang plugin ay may controller PUBLISH_UNPUBLISH_VOLUME kakayahan at ControllerUnpublishVolume ay matagumpay na na-invoke.

KUNG HINDI

• Ang plugin ay WALANG controller PUBLISH_UNPUBLISH_VOLUME kakayahan, ang plugin ay may node STAGE_UNSTAGE_VOLUME kakayahan, at NodeUnstageVolume ay matagumpay na nakumpleto.

KUNG HINDI

• Ang plugin ay WALANG controller PUBLISH_UNPUBLISH_VOLUME kakayahan, o node STAGE_UNSTAGE_VOLUME kakayahan, at NodeUnpublishVolume ay matagumpay na natapos.

Nangangahulugan ito na kailangan mong tanggalin ang disk mula sa virtual machine bago palawakin ito.

Gayunpaman, sa kasamaang palad pagpapatupad Ang detalye ng CSI sa pamamagitan ng mga sidecar ay hindi nakakatugon sa mga kinakailangang ito:

• Sa isang lalagyan ng sidecar csi-attacher, na dapat na maging responsable para sa pagkakaroon ng kinakailangang agwat sa pagitan ng mga mount, ang functionality na ito ay hindi ipinapatupad sa offline na pagbabago ng laki. Sinimulan ang isang talakayan tungkol dito dito.
• Ano nga ba ang lalagyan ng sidecar sa kontekstong ito? Ang CSI plugin mismo ay hindi nakikipag-ugnayan sa Kubernetes API, ngunit tumutugon lamang sa mga tawag sa gRPC na ipinadala dito ng mga sidecar container. Pinakabago ay binuo ng komunidad ng Kubernetes.

Sa aming kaso (CSI plugin), ang pagpapatakbo ng pagtaas ng disk ay ganito:

1. Nakatanggap kami ng tawag sa gRPC ControllerExpandVolume;
2. Sinusubukan naming dagdagan ang disk sa API, ngunit nakatanggap kami ng isang error tungkol sa imposibilidad ng pagsasagawa ng operasyon dahil ang disk ay naka-mount;
3. Ise-save namin ang disk identifier sa isang mapa na naglalaman ng mga disk kung saan kailangang isagawa ang pagpapatakbo ng pagtaas. Sa ibaba, para sa maikli, tatawagin natin ang mapa na ito bilang volumeResizeRequired;
4. Manu-manong alisin ang pod na gumagamit ng disk. Ire-restart ito ng Kubernetes. Upang ang disk ay walang oras upang i-mount (ControllerPublishVolume) bago kumpletuhin ang pagpapatakbo ng pagtaas kapag sinusubukang i-mount, tinitingnan namin na ang ibinigay na disk ay nasa loob pa rin volumeResizeRequired at ibalik ang isang error;
5. Sinusubukan ng driver ng CSI na muling isagawa ang pagpapalit ng laki ng operasyon. Kung matagumpay ang operasyon, pagkatapos ay alisin ang disk mula sa volumeResizeRequired;
6. kasi Nawawala ang Disk ID mula sa volumeResizeRequired, ControllerPublishVolume matagumpay na pumasa, ang disk ay naka-mount, ang pod ay nagsisimula.

Ang lahat ay mukhang sapat na simple, ngunit gaya ng lagi ay may mga pitfalls. Pinalaki ang mga disk panlabas na resizer, na kung sakaling magkaroon ng error sa panahon ng operasyon gumagamit ng pila na may exponential na pagtaas sa oras ng timeout hanggang 1000 segundo:

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

Ito ay maaaring pana-panahong magresulta sa pagpapalawak ng pagpapalawak ng disk nang 15+ minuto at, sa gayon, ang kaukulang pod ay hindi magagamit.

Ang tanging opsyon na medyo madali at walang sakit na nagbigay-daan sa amin na bawasan ang potensyal na downtime ay ang paggamit ng aming bersyon ng external-resizer na may maximum na limitasyon sa timeout. sa loob ng 5 segundo:

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

Hindi namin itinuring na kinakailangan na agarang simulan ang isang talakayan at i-patch ang external-resizer, dahil ang offline na pagbabago ng laki ng mga disk ay isang throwback na malapit nang mawala sa lahat ng cloud provider.

Paano simulan ang paggamit nito?

Ang driver ay suportado sa Kubernetes bersyon 1.15 at mas mataas. Para gumana ang driver, dapat matugunan ang mga sumusunod na kinakailangan:

• I-flag --allow-privileged nakatakda sa halaga true para sa API server at kubelet;
• Kasama --feature-gates=VolumeSnapshotDataSource=true,KubeletPluginsWatcher=true,CSINodeInfo=true,CSIDriverRegistry=true para sa API server at kubelet;
• pagpapalaganap ng bundok (pagpapalaganap ng bundok) ay dapat na pinagana sa cluster. Kapag gumagamit ng Docker, ang daemon ay dapat na i-configure upang payagan ang mga shared mount.

Ang lahat ng mga kinakailangang hakbang para sa pag-install mismo inilarawan sa README. Kasama sa pag-install ang paggawa ng mga bagay sa Kubernetes mula sa mga manifest.

Para gumana ang driver kakailanganin mo ang sumusunod:

• Tukuyin ang directory identifier sa manifest (folder-id) Yandex.Cloud (tingnan ang dokumentasyon);
• Upang makipag-ugnayan sa Yandex.Cloud API, gumagamit ang driver ng CSI ng account ng serbisyo. Sa Secret manifest, kailangan mong pumasa mga awtorisadong susi mula sa account ng serbisyo. Sa dokumentasyon inilarawan, kung paano gumawa ng account ng serbisyo at kumuha ng mga susi.

Sa lahat lahat - subukan ito, at ikalulugod naming makatanggap ng feedback at mga bagong isyukung nakatagpo ka ng anumang mga problema!

Karagdagang suporta

Bilang resulta, nais naming tandaan na ipinatupad namin ang driver ng CSI na ito hindi dahil sa labis na pagnanais na magsaya sa pagsusulat ng mga aplikasyon sa Go, ngunit dahil sa isang agarang pangangailangan sa loob ng kumpanya. Mukhang hindi praktikal sa amin na mapanatili ang aming sariling pagpapatupad, kaya kung ang Yandex ay nagpapakita ng interes at nagpasya na patuloy na suportahan ang driver, ikalulugod naming ilipat ang repositoryo sa kanila.

Bilang karagdagan, malamang na ang Yandex ay may sariling pagpapatupad ng driver ng CSI sa pinamamahalaang Kubernetes cluster nito, na maaaring ilabas sa Open Source. Nakikita rin namin ang pagpipiliang ito sa pagpapaunlad bilang paborable - ang komunidad ay makakagamit ng isang napatunayang driver mula sa isang service provider, at hindi mula sa isang third-party na kumpanya.

PS

Basahin din sa aming blog:

• «Mga plugin ng volume para sa storage ng Kubernetes: mula Flexvolume hanggang CSI";
• «Naiintindihan namin ang Container Storage Interface (sa Kubernetes at hindi lamang)";
• «Madali ba at maginhawang maghanda ng Kubernetes cluster? Inanunsyo ang addon-operator";
• «Pagpapalawak at pagpupuno sa Kubernetes (pagsusuri at ulat ng video)'.

Pinagmulan: www.habr.com