🥇Ang among kasinatian sa pagpalambo sa usa ka drayber sa CSI sa Kubernetes para sa Yandex.Cloud

Nalipay kami nga ipahibalo nga ang Flant nagpalapad sa kontribusyon niini sa mga tool sa Open Source para sa Kubernetes pinaagi sa pagpagawas alpha nga bersyon sa CSI driver (Container Storage Interface) para sa Yandex.Cloud.

Apan sa wala pa mopadayon sa mga detalye sa pagpatuman, atong tubagon ang pangutana ngano nga gikinahanglan kini kung ang Yandex naa nay serbisyo Gidumala nga Serbisyo para sa Kubernetes.

Pasiuna

Ngano man ni?

Sulod sa among kompanya, gikan sa sinugdanan sa paggamit sa Kubernetes sa produksiyon (ie sa daghang mga tuig na karon), nagpalambo kami sa among kaugalingon nga himan (deckhouse), nga, sa tinuud, nagplano usab kami nga magamit sa dili madugay ingon usa ka proyekto sa Open Source. . Uban sa tabang niini, kami parehas nga nag-configure ug nag-configure sa tanan namon nga mga pungpong, ug sa pagkakaron adunay labaw pa sa 100 niini, sa usa ka halapad nga lainlaing mga pag-configure sa hardware ug sa tanan nga magamit nga serbisyo sa panganod.

Ang mga pundok nga naggamit sa deckhouse adunay tanan nga mga sangkap nga gikinahanglan alang sa operasyon: mga balanse, pag-monitor nga adunay kombenyente nga mga tsart, sukatan ug mga alerto, pag-authenticate sa gumagamit pinaagi sa mga eksternal nga tighatag alang sa pag-access sa tanan nga mga dashboard, ug uban pa. Walay kapuslanan ang pag-instalar sa ingon nga "pumped up" nga cluster sa usa ka pagdumala nga solusyon, tungod kay kini kasagaran imposible o mosangpot sa panginahanglan sa pag-disable sa katunga sa mga sangkap.

NB: Kini ang among kasinatian, ug kini espesipiko kaayo. Wala kami nagsugyot nga ang tanan kinahanglan nga mag-deploy sa mga kumpol sa Kubernetes sa ilang kaugalingon imbis nga mogamit mga andam nga solusyon. Pinaagi sa dalan, wala kami tinuud nga kasinatian sa pag-operate sa Kubernetes gikan sa Yandex ug dili kami maghatag bisan unsang pagtasa sa kini nga serbisyo sa kini nga artikulo.

Unsa kini ug para kang kinsa?

Mao nga, naghisgot na kami bahin sa modernong pamaagi sa pagtipig sa Kubernetes: sa unsa nga paagi sa CSI nagtrabaho? и giunsa pag-abot sa komunidad niini nga pamaagi.

Sa pagkakaron, daghang dagkong cloud service providers ang nakaugmad ug mga drayber alang sa paggamit sa ilang mga cloud disks isip Persistent Volume sa Kubernetes. Kung ang supplier walay ingon nga drayber, apan ang tanan nga gikinahanglan nga mga gimbuhaton gihatag pinaagi sa API, nan walay makapugong kanimo sa pagpatuman sa drayber sa imong kaugalingon. Mao kini ang nahitabo sa Yandex.Cloud.

Gikuha namo isip basehan sa kalamboan CSI driver alang sa DigitalOcean cloud ug usa ka magtiayon nga mga ideya gikan sa mga drayber alang sa GCP, tungod kay ang interaksyon sa API niini nga mga panganod (Google ug Yandex) adunay daghang mga kaamgiran. Sa partikular, ang API ug Ang GCP, ug sa Yandex ibalik ang usa ka butang Operation aron masubay ang kahimtang sa dugay nang mga operasyon (pananglitan, paghimo og bag-ong disk). Aron makig-uban sa Yandex.Cloud API, gamita Yandex.Cloud Go SDK.

Ang resulta sa trabaho nga nahimo gipatik sa GitHub ug mahimong mapuslanon alang niadtong kinsa, sa pipila ka rason, naggamit sa ilang kaugalingong Kubernetes nga pag-instalar sa Yandex.Cloud virtual machines (apan dili usa ka andam nga gihimo nga gidumala nga cluster) ug gusto nga mogamit (order) mga disk pinaagi sa CSI.

Pagpatuman

Yawe nga mga bahin

Sa pagkakaron ang drayber nagsuporta sa mosunod nga mga gimbuhaton:

Pag-order sa mga disk sa tanan nga mga zone sa cluster sumala sa topology sa mga node sa cluster;
Pagtangtang sa nauna nga gi-order nga mga disc;
Offline resize para sa mga disk (Yandex.Cloud ayaw pagsuporta pagdugang sa mga disk nga gi-mount sa virtual machine). Alang sa kasayuran kung giunsa pagbag-o ang drayber aron mahimo’g dili masakit ang pagbag-o, tan-awa sa ubos.

Sa umaabot, nagplano kami nga ipatuman ang suporta alang sa paghimo ug pagtangtang sa mga snapshot sa disk.

Ang nag-unang kalisud ug unsaon pagbuntog niini

Ang kakulang sa abilidad sa pagdugang sa mga disk sa tinuod nga panahon sa Yandex.Cloud API mao ang usa ka limitasyon nga complicates sa resize nga operasyon alang sa PV (Persistent Volume): sa niini nga kaso, kini mao ang gikinahanglan nga ang aplikasyon pod nga naggamit sa disk nga hunongon, ug kini mahimong hinungdan sa mga aplikasyon sa downtime.

Sumala sa Mga detalye sa CSI, kung ang CSI controller nagtaho nga kini makahimo sa pag-resize sa mga disk "offline" lamang (VolumeExpansion.OFFLINE), unya ang proseso sa pagdugang sa disk kinahanglan nga ingon niini:

Kung ang plugin adunay lamang VolumeExpansion.OFFLINE Ang kapabilidad ug gidaghanon sa pagpalapad sa pagkakaron gimantala o anaa sa usa ka node unya ControllerExpandVolume KINAHANGLANG tawgon LAMANG pagkahuman sa:

Ang plugin adunay controller PUBLISH_UNPUBLISH_VOLUME kapabilidad ug ControllerUnpublishVolume malampuson nga gisangpit.

O LAIN

Ang plugin WALA adunay controller PUBLISH_UNPUBLISH_VOLUME kapabilidad, ang plugin adunay node STAGE_UNSTAGE_VOLUME kapabilidad, ug NodeUnstageVolume malampuson nga nahuman.

O LAIN

Ang plugin WALA adunay controller PUBLISH_UNPUBLISH_VOLUME kapabilidad, ni node STAGE_UNSTAGE_VOLUME kapabilidad, ug NodeUnpublishVolume malampuson nga nahuman.

Kini nagpasabut nga kinahanglan nimo nga tangtangon ang disk gikan sa virtual machine sa dili pa kini palapdan.

Apan, sa kasubo pagpatuman Ang espesipikasyon sa CSI pinaagi sa mga sidecar wala makaabot niini nga mga kinahanglanon:

Sa usa ka sudlanan sa sidecar csi-attacher, nga kinahanglan nga responsable sa presensya sa gikinahanglan nga gintang tali sa mga mounts, kini nga pag-andar wala lang gipatuman sa offline nga pagbag-o. Usa ka diskusyon bahin niini ang gisugdan dinhi.
Unsa man gyud ang sudlanan sa sidecar niini nga konteksto? Ang CSI plugin mismo dili makig-uban sa Kubernetes API, apan motubag lamang sa mga tawag sa gRPC nga gipadala niini pinaagi sa mga sudlanan sa sidecar. Pinakabag-o ginadevelop sa komunidad sa Kubernetes.

Sa among kaso (CSI plugin), ang operasyon sa pagdugang sa disk ingon niini:

Nakadawat mi og tawag sa gRPC ControllerExpandVolume;
Gisulayan namon nga madugangan ang disk sa API, apan nakadawat kami usa ka sayup bahin sa imposibilidad sa paghimo sa operasyon tungod kay ang disk gi-mount;
Gitipigan namon ang disk identifier sa mapa, nga adunay sulud nga mga disk diin kinahanglan himuon ang pagdugang nga operasyon. Sa ubos, sa mubo, tawgon nato kini nga mapa nga volumeResizeRequired;
Pagtangtang sa kamut sa pod nga naggamit sa disk. I-restart kini sa mga Kubernetes. Aron ang disk wala’y oras sa pag-mount (ControllerPublishVolume) sa dili pa makompleto ang operasyon sa pagdugang kung mosulay sa pag-mount, among susihon nga ang gihatag nga disk naa pa volumeResizeRequired ug ibalik ang usa ka sayup;
Gisulayan sa drayber sa CSI nga ipatuman pag-usab ang operasyon sa pag-resize. Kung ang operasyon malampuson, unya kuhaa ang disk gikan sa volumeResizeRequired;
Kay Nawala ang Disk ID gikan sa volumeResizeRequired, ControllerPublishVolume malampuson nga milabay, ang disk gi-mount, nagsugod ang pod.

Ang tanan morag yano nga igo, apan sama sa kanunay adunay mga lit-ag. Nagpadako sa mga disk external-resizer, nga sa kaso sa usa ka sayop sa panahon sa operasyon naggamit ug pila uban sa usa ka exponential nga pagtaas sa timeout nga oras hangtod sa 1000 segundos:

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

Mahimo kini matag karon ug unya nga moresulta sa pagpalapad sa disk nga operasyon nga gipalugway sa 15+ ka minuto ug, sa ingon, ang katugbang nga pod dili magamit.

Ang bugtong kapilian nga dali ug walay sakit nga nagtugot kanamo sa pagpakunhod sa potensyal nga downtime mao ang paggamit sa among bersyon sa external-resizer nga adunay labing taas nga limitasyon sa oras. sa 5 segundos:

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

Wala namo isipa nga gikinahanglan ang dinalian nga pagsugod sa usa ka diskusyon ug pag-patch sa external-resizer, tungod kay ang offline nga pagbag-o sa mga disk usa ka throwback nga sa dili madugay mawala gikan sa tanan nga cloud providers.

Giunsa magsugod ang paggamit?

Ang drayber gisuportahan sa Kubernetes nga bersyon 1.15 ug mas taas pa. Aron makatrabaho ang drayber, ang mosunod nga mga kinahanglanon kinahanglan matuman:

Flag --allow-privileged gibutang sa bili true para sa API server ug kubelet;
Apil na --feature-gates=VolumeSnapshotDataSource=true,KubeletPluginsWatcher=true,CSINodeInfo=true,CSIDriverRegistry=true para sa API server ug kubelet;
Pagpakaylap sa bukid (pagpadaghan sa bukid) kinahanglang ma-enable sa cluster. Kung gigamit ang Docker, ang daemon kinahanglan nga ma-configure aron tugutan ang gipaambit nga mga mount.

Ang tanan nga gikinahanglan nga mga lakang alang sa pag-instalar mismo gihulagway sa README. Ang pag-instalar naglakip sa paghimo og mga butang sa Kubernetes gikan sa mga manifest.

Aron magtrabaho ang drayber kinahanglan nimo ang mosunod:

Ipiho ang directory identifier sa manifest (folder-id) Yandex.Cloud (tan-awa ang dokumentasyon);
Aron makig-uban sa Yandex.Cloud API, ang drayber sa CSI naggamit ug account sa serbisyo. Sa pagpakita, ang Sekreto kinahanglan ipasa awtorisado nga mga yawe gikan sa account sa serbisyo. Sa dokumentasyon gihulagway, unsaon paghimo og service account ug pagkuha og mga yawe.

Sa tanan- pagsulay, ug malipay kami nga makadawat og feedback ug bag-ong mga isyukung makasugat kag problema!

Dugang nga suporta

Ingon usa ka sangputanan, gusto namon nga matikdan nga among gipatuman kini nga drayber sa CSI dili tungod sa usa ka dako nga tinguha nga malingaw sa pagsulat sa mga aplikasyon sa Go, apan tungod sa usa ka dinalian nga panginahanglanon sa sulod sa kompanya. Morag dili praktikal alang kanamo ang pagpadayon sa among kaugalingon nga pagpatuman, busa kung ang Yandex magpakita og interes ug modesisyon nga magpadayon sa pagsuporta sa drayber, malipay kami nga ibalhin ang repository sa kanila.

Dugang pa, ang Yandex lagmit adunay kaugalingon nga pagpatuman sa drayber sa CSI sa gidumala nga Kubernetes cluster, nga mahimong ipagawas sa Open Source. Nakita usab namo kini nga opsyon sa pag-uswag nga paborable - ang komunidad makahimo sa paggamit sa usa ka napamatud-an nga drayber gikan sa usa ka service provider, ug dili gikan sa usa ka third-party nga kompanya.

PS

Basaha usab sa among blog:

Source: www.habr.com

Ang among kasinatian sa pagpalambo sa usa ka drayber sa CSI sa Kubernetes para sa Yandex.Cloud