ProHoster > Blog > Administrasi > Pangalaman urang dina ngamekarkeun supir CSI di Kubernetes pikeun Yandex.Cloud

Pangalaman urang dina ngamekarkeun supir CSI di Kubernetes pikeun Yandex.Cloud

Pangalaman urang dina ngamekarkeun supir CSI di Kubernetes pikeun Yandex.Cloud

Kami resep ngumumkeun yén Flant ngalegaan kontribusina kana alat Open Source pikeun Kubernetes ku ngaleupaskeun Vérsi alfa supir CSI (Panyimpenan Wadah Interface) pikeun Yandex.Cloud.

Tapi sateuacan ngaléngkah ka detil palaksanaan, hayu urang ngajawab patarosan naha ieu diperyogikeun pisan nalika Yandex parantos ngagaduhan jasa. Diurus Service pikeun Kubernetes.

perkenalan

Naha ieu?

Dina perusahaan kami, ti mimiti ngagunakeun Kubernetes dina produksi (nyaéta pikeun sababaraha taun ayeuna), kami parantos ngembangkeun alat kami sorangan (deckhouse), anu, ku jalan kitu, kami ogé ngarencanakeun pikeun enggal janten sayogi salaku proyék Open Source. . Kalayan bantosanana, kami seragam ngonpigurasikeun sareng ngonpigurasikeun sadaya klaster kami, sareng ayeuna parantos aya langkung ti 100 di antarana, dina rupa-rupa konfigurasi hardware sareng dina sadaya jasa awan anu sayogi.

Kluster anu nganggo deckhouse gaduh sadayana komponén anu dipikabutuh pikeun operasi: pangimbang, ngawaskeun kalayan grafik anu saé, métrik sareng panggeuing, auténtikasi pangguna ngalangkungan panyadia éksternal pikeun aksés ka sadaya dasbor, sareng saterasna. Teu aya gunana pikeun masang klaster "ngompa" sapertos dina solusi anu diurus, sabab ieu sering teu mungkin atanapi bakal nyababkeun kabutuhan pikeun nganonaktipkeun satengah komponén.

NB: Ieu pangalaman urang, tur éta rada husus. Kami henteu nyarankeun yén sadayana kedah nyebarkeun klaster Kubernetes nyalira tinimbang nganggo solusi anu siap-siap. Ku jalan kitu, urang teu boga pangalaman nyata dina operasi Kubernetes ti Yandex sarta kami moal masihan sagala assessment jasa ieu dina artikel ieu.

Naon éta sareng pikeun saha?

Janten, urang parantos nyarios ngeunaan pendekatan modéren pikeun neundeun di Kubernetes: kumaha CSI jalan? и kumaha datangna masarakat kana pendekatan ieu.

Ayeuna, seueur panyadia ladenan awan ageung parantos ngembangkeun supir pikeun ngagunakeun disk awanna salaku Volume Persisten di Kubernetes. Upami panyadia henteu gaduh supir sapertos kitu, tapi sadaya fungsi anu diperyogikeun disayogikeun ku API, maka teu aya anu ngahalangan anjeun ngalaksanakeun supir sorangan. Ieu naon anu lumangsung kalawan Yandex.Cloud.

Kami nyandak salaku dasar pikeun pangwangunan Supir CSI pikeun awan DigitalOcean jeung sababaraha gagasan ti drivers pikeun GCP, saprak interaksi jeung API awan ieu (Google jeung Yandex) ngabogaan sajumlah kamiripan. Khususna, API sareng GCP, jeung Yandex balikkeun hiji obyék Operation pikeun ngalacak status operasi anu parantos lami (contona, nyiptakeun disk énggal). Pikeun berinteraksi sareng Yandex.Cloud API, paké Yandex.Cloud Go SDK.

Hasil pagawéan anu dilakukeun diterbitkeun dina GitHub sarta bisa jadi mangpaat pikeun jalma anu, pikeun sababaraha alesan, ngagunakeun instalasi Kubernetes sorangan dina mesin virtual Yandex.Cloud (tapi lain klaster junun siap-dijieun) jeung hoyong ngagunakeun (urutan) disk ngaliwatan CSI.

Реализация

Fitur utama

Ayeuna supir ngadukung fungsi ieu:

  • Mesen disk dina sadaya zona kluster dumasar kana topologi titik dina kluster;
  • Nyoplokkeun piringan anu dipesen sateuacana;
  • Ukuran offline pikeun disk (Yandex.Cloud teu ngarojong ningkatkeun disk anu dipasang kana mesin virtual). Kanggo inpo tentang kumaha supir kedah dirobih supados pangaturan ukuran janten henteu aya rasa nyeri, tingali di handap.

Dina mangsa nu bakal datang, urang rencanana pikeun nerapkeun rojongan pikeun nyieun jeung mupus snapshots disk.

Kasusah utama jeung kumaha carana nungkulan eta

Kurangna kamampuan pikeun ningkatkeun disk sacara real waktos dina Yandex.Cloud API mangrupikeun watesan anu nyusahkeun operasi ukuran pikeun PV (Volume Persisten): dina hal ieu, perlu yén pod aplikasi anu nganggo disk dihentikan. sarta ieu bisa ngabalukarkeun aplikasi downtime.

nurutkeun spésifikasi CSI, lamun CSI controller ngalaporkeun yén éta bisa ngarobah ukuran disk ngan "offline" (VolumeExpansion.OFFLINE), teras prosés ningkatkeun disk kedah sapertos kieu:

Lamun plugin ngabogaan ngan VolumeExpansion.OFFLINE kamampuhan ékspansi jeung volume ayeuna diterbitkeun atawa sadia dina titik lajeng ControllerExpandVolume WAJIB disebut ngan sanggeus:

  • plugin ngabogaan controller PUBLISH_UNPUBLISH_VOLUME kamampuhan jeung ControllerUnpublishVolume parantos suksés diajak.

ATAWA LAIN

  • plugin nu NOT boga controller PUBLISH_UNPUBLISH_VOLUME kamampuhan, plugin ngabogaan titik STAGE_UNSTAGE_VOLUME kamampuhan, jeung NodeUnstageVolume geus réngsé junun.

ATAWA LAIN

  • plugin nu NOT boga controller PUBLISH_UNPUBLISH_VOLUME kamampuan, atanapi node STAGE_UNSTAGE_VOLUME kamampuhan, jeung NodeUnpublishVolume parantos suksés.

Ieu dasarna hartosna anjeun kedah ngaleupaskeun disk tina mesin virtual sateuacan ngalegaanna.

Sanajan kitu, hanjakalna palaksanaan Spésifikasi CSI via sidecars teu minuhan sarat ieu:

  • Dina wadah sidecar csi-attacher, nu kedah nanggungjawaban kanggo ayana gap diperlukeun antara mounts, fungsionalitas ieu ngan saukur teu dilaksanakeun dina ukuran offline. Sawala ngeunaan ieu dimimitian di dieu.
  • Naon kahayang téh wadah sidecar dina konteks ieu? Plugin CSI sorangan henteu berinteraksi sareng API Kubernetes, tapi ngan ukur ngabales sauran gRPC anu dikirim ku wadah sidecar. Panganyarna keur dimekarkeun ku komunitas Kubernetes.

Dina kasus urang (plugin CSI), operasi ningkatkeun disk sapertos kieu:

  1. Kami nampi telepon gRPC ControllerExpandVolume;
  2. Kami nyobian ningkatkeun disk dina API, tapi kami nampi kasalahan ngeunaan impossibility ngalaksanakeun operasi sabab disk dipasang;
  3. Urang nyimpen identifier disk dina peta nu ngandung disk nu operasi nambahan perlu dipigawé. Di handap, pikeun brevity, urang bakal nelepon peta ieu salaku volumeResizeRequired;
  4. Cabut pod anu nganggo disk sacara manual. Kubernetes bakal ngamimitian deui. Janten disk teu gaduh waktos kanggo dipasang (ControllerPublishVolume) sateuacan ngabéréskeun operasi paningkatan nalika nyobian dipasang, kami pariksa yén disk anu dipasihkeun masih aya volumeResizeRequired jeung mulangkeun kasalahan;
  5. Supir CSI nyobian ngajalankeun deui operasi ukuranana. Upami operasi éta suksés, teras cabut disk tina volumeResizeRequired;
  6. Sabab Disk ID leungit tina volumeResizeRequired, ControllerPublishVolume pas suksés, disk dipasang, pod dimimitian.

Sagalana Sigana cukup basajan, tapi sakumaha salawasna aya pitfalls. Ngagedékeun disk éksternal-resizer, nu bisi aya kasalahan salila operasi ngagunakeun antrian kalayan paningkatan éksponénsial dina waktos seep dugi ka 1000 detik:

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

Ieu périodik tiasa nyababkeun operasi ékspansi disk diperpanjang salami 15+ menit sareng, ku kituna, pod anu cocog henteu sayogi.

Hiji-hijina pilihan anu cukup gampang sareng henteu aya rasa nyeri ngamungkinkeun urang pikeun ngirangan poténsial downtime nyaéta ngagunakeun versi éksternal-resizer kami kalayan wates seep maksimum. dina 5 detik:

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

Urang teu nganggap perlu urgently initiate hiji sawala jeung patch éksternal-resizer, sabab offline ukuran disk mangrupakeun throwback nu baris geura-giru ngaleungit tina sagala panyadia awan.

Kumaha ngamimitian ngagunakeun?

Supir dirojong ku Kubernetes versi 1.15 sareng anu langkung luhur. Pikeun supir tiasa dianggo, sarat di handap ieu kedah nyumponan:

  • bandera --allow-privileged disetel ka nilai true pikeun server API tur kubelet;
  • Kaasup --feature-gates=VolumeSnapshotDataSource=true,KubeletPluginsWatcher=true,CSINodeInfo=true,CSIDriverRegistry=true pikeun server API tur kubelet;
  • rambatan gunung (rambatan gunung) kudu diaktipkeun dina klaster. Nalika nganggo Docker, daemon kedah dikonpigurasikeun pikeun ngijinkeun gunung anu dibagikeun.

Sadaya léngkah anu dipikabutuh pikeun instalasi sorangan dijelaskeun dina README. Pamasangan ngalibatkeun nyiptakeun objék dina Kubernetes tina manifes.

Pikeun supir tiasa dianggo anjeun peryogi ieu:

  • Sebutkeun identifier diréktori dina manifest (folder-id) Yandex.Cloud (tingali dokuméntasi);
  • Pikeun berinteraksi sareng Yandex.Cloud API, supir CSI nganggo akun jasa. Dina Rahasia manifest, Anjeun kudu lulus kenop otorisasi ti akun jasa. Dina dokuméntasi digambarkeun, kumaha carana nyieun hiji akun jasa tur meunangkeun konci.

Sadayana - nyobaan, sarta kami bakal bungah pikeun nampa eupan balik na isu anyarupami anjeun mendakan masalah!

rojongan salajengna

Hasilna, urang hoyong dicatet yén kami ngalaksanakeun supir CSI ieu teu kaluar tina kahayang gede pikeun senang nulis aplikasi di Go, tapi kusabab hiji kabutuhan urgent dina parusahaan. Éta sigana henteu praktis pikeun urang pikeun ngajaga palaksanaan urang sorangan, janten upami Yandex nunjukkeun minat sareng mutuskeun pikeun terus ngadukung supir, urang bakal resep nransperkeun gudang ka aranjeunna.

Salaku tambahan, Yandex sigana gaduh palaksanaan supir CSI sorangan dina klaster Kubernetes anu diurus, anu tiasa dileupaskeun dina Open Source. Kami ogé ningali pilihan pamekaran ieu salaku nguntungkeun - masarakat bakal tiasa nganggo supir anu kabuktian ti panyadia jasa, sanés ti perusahaan pihak katilu.

PS

Baca ogé dina blog urang:

sumber: www.habr.com

Tambahkeun komentar