Pengalaman kita ngembangake driver CSI ing Kubernetes kanggo Yandex.Cloud

We are pleased kanggo ngumumake yen Flant ngembangake kontribusi kanggo alat Open Source kanggo Kubernetes kanthi ngeculake versi alpha driver CSI (Antarmuka Panyimpenan Wadah) kanggo Yandex.Cloud.

Nanging sadurunge pindhah menyang rincian implementasine, ayo mangsuli pitakon kenapa iki dibutuhake nalika Yandex wis duwe layanan. Layanan Ngatur kanggo Kubernetes.

Pambuka

Kenapa iki?

Ing perusahaan kita, wiwit wiwitan nggunakake Kubernetes ing produksi (yaiku nganti pirang-pirang taun saiki), kita wis ngembangake alat dhewe (deckhouse), sing, kanthi cara, kita uga rencana bakal kasedhiya minangka proyek Open Source. . Kanthi bantuan, kita seragam ngatur lan ngatur kabeh kluster, lan saiki wis ana luwih saka 100, ing macem-macem konfigurasi hardware lan ing kabeh layanan maya kasedhiya.

Kluster sing nggunakake deckhouse duwe kabeh komponen sing dibutuhake kanggo operasi: balancers, ngawasi kanthi grafik sing trep, metrik lan tandha, otentikasi pangguna liwat panyedhiya eksternal kanggo akses menyang kabeh dashboard, lan liya-liyane. Ora ana gunane nginstal kluster "pompa" kasebut ing solusi sing dikelola, amarga iki asring ora mungkin utawa bakal mbutuhake mateni setengah komponen.

NB: Iki pengalaman kita, lan cukup spesifik. Kita ora menehi saran manawa kabeh wong kudu masang klompok Kubernetes dhewe tinimbang nggunakake solusi sing wis siap. Miturut cara, kita ora duwe pengalaman nyata ing operasi Kubernetes saka Yandex lan kita ora bakal menehi evaluasi layanan iki ing artikel iki.

Apa iku lan kanggo sapa?

Dadi, kita wis ngomong babagan pendekatan modern kanggo panyimpenan ing Kubernetes: carane CSI bisa? и carane masyarakat teka kanggo pendekatan iki.

Saiki, akeh panyedhiya layanan maya gedhe wis ngembangake driver kanggo nggunakake disk awan minangka Volume Persistent ing Kubernetes. Yen panyedhiya ora duwe pembalap, nanging kabeh fungsi sing dibutuhake diwenehake liwat API, mula ora ana sing ngalang-alangi sampeyan nindakake driver dhewe. Iki kedadeyan karo Yandex.Cloud.

We njupuk minangka basis kanggo pembangunan Driver CSI kanggo DigitalOcean cloud lan saperangan saka gagasan saka driver kanggo GCP, amarga interaksi karo API awan kasebut (Google lan Yandex) nduweni sawetara persamaan. Ing tartamtu, API lan GCP, lan ing Yandex bali obyek Operation kanggo nglacak status operasi sing wis suwe (contone, nggawe disk anyar). Kanggo sesambungan karo Yandex.Cloud API, gunakake Yandex.Cloud Go SDK.

Asil saka karya rampung diterbitake ing GitHub lan bisa uga migunani kanggo wong-wong sing, sakperangan alesan, nggunakake instalasi Kubernetes dhewe ing mesin virtual Yandex.Cloud (nanging ora kluster ngatur siap-digawe) lan pengin nggunakake (order) disk liwat CSI.

Реализация

Fitur utama

Saiki driver ndhukung fungsi ing ngisor iki:

• Mesen disk ing kabeh zona kluster miturut topologi simpul ing kluster;
• Mbusak disk sing wis diprentahake sadurunge;
• Ngowahi ukuran offline kanggo disk (Yandex.Cloud ora ndhukung nambah disk sing dipasang ing mesin virtual). Kanggo informasi babagan carane driver kudu diowahi kanggo ngowahi ukuran dadi ora krasa lara, deleng ing ngisor iki.

Ing mangsa ngarep, kita arep ngleksanakake dhukungan kanggo nggawe lan mbusak snapshots disk.

Kesulitan utama lan carane ngatasi

Kekurangan kemampuan kanggo nambah disk ing wektu nyata ing Yandex.Cloud API minangka watesan sing nyebabake operasi ganti ukuran kanggo PV (Volume Persisten): ing kasus iki, polong aplikasi sing nggunakake disk kudu mandheg, lan iki bisa nyebabake aplikasi downtime.

Miturut Spesifikasi CSI, yen pengontrol CSI nyatakake yen bisa ngowahi ukuran disk mung "offline" (VolumeExpansion.OFFLINE), banjur proses nambah disk kudu kaya iki:

Yen plugin wis mung VolumeExpansion.OFFLINE kemampuan expansion lan volume saiki diterbitake utawa kasedhiya ing simpul banjur ControllerExpandVolume WAJIB ditelpon mung sawise:

• Plugin kasebut duwe pengontrol PUBLISH_UNPUBLISH_VOLUME kemampuan lan ControllerUnpublishVolume wis diundang kanthi sukses.

UTAWA LIYA

• Plugin ora duwe pengontrol PUBLISH_UNPUBLISH_VOLUME kemampuan, plugin duwe simpul STAGE_UNSTAGE_VOLUME kapabilitas, lan NodeUnstageVolume wis rampung kasil.

UTAWA LIYA

• Plugin ora duwe pengontrol PUBLISH_UNPUBLISH_VOLUME kemampuan, utawa node STAGE_UNSTAGE_VOLUME kapabilitas, lan NodeUnpublishVolume wis rampung kanthi sukses.

Iki tegese sampeyan kudu nyopot disk saka mesin virtual sadurunge nggedhekake.

Nanging, sayangé implementasine Spesifikasi CSI liwat sidecars ora nyukupi syarat kasebut:

• Ing wadhah sidecar csi-attacher, kang kudu tanggung jawab kanggo ngarsane longkangan dibutuhake antarane gunung, fungsi iki mung ora dipun ginakaken ing ukuran offline. Diskusi babagan iki diwiwiti kene.
• Apa sejatine wadhah sidecar ing konteks iki? Plugin CSI dhewe ora sesambungan karo API Kubernetes, nanging mung nanggapi telpon gRPC sing dikirim menyang wadhah sidecar. Paling anyar lagi dikembangake dening komunitas Kubernetes.

Ing kasus kita (plugin CSI), operasi nambah disk katon kaya iki:

1. Kita nampa telpon gRPC ControllerExpandVolume;
2. Kita nyoba nambah disk ing API, nanging kita nampa kesalahan babagan impossibility nindakake operasi amarga disk wis dipasang;
3. Kita nyimpen pengenal disk ing peta, sing ngemot disk sing kudu ditindakake operasi tambah. Ing ngisor iki, kanggo ringkesan, kita bakal nelpon peta iki minangka volumeResizeRequired;
4. Copot pod sing nggunakake disk kanthi manual. Kubernetes bakal miwiti maneh. Supaya disk ora duwe wektu kanggo dipasang (ControllerPublishVolume) sadurunge ngrampungake operasi nambah nalika nyoba kanggo Gunung, kita mriksa sing disk diwenehi isih ing volumeResizeRequired lan bali kesalahan;
5. Pembalap CSI nyoba nglakokake maneh operasi ganti ukuran. Yen operasi kasebut sukses, banjur copot disk saka volumeResizeRequired;
6. Amarga Disk ID ilang saka volumeResizeRequired, ControllerPublishVolume liwat kasil, disk wis dipasang, pod diwiwiti.

Kabeh katon cukup prasaja, nanging kaya biasane ana pitfalls. Nggedhekake disk eksternal-resizer, sing yen ana kesalahan sajrone operasi nggunakake antrian kanthi paningkatan eksponensial ing wektu entek nganti 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)},
  )
}

Iki bisa nyebabake operasi ekspansi disk kanthi periodik nganti 15+ menit lan, kanthi mangkono, pod sing cocog ora kasedhiya.

Siji-sijine pilihan sing cukup gampang lan tanpa lara ngidini kita nyuda potensial downtime yaiku nggunakake versi eksternal-resizer kanthi watesan wektu entek maksimal. ing 5 detik:

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

Kita ora nganggep perlu kanggo miwiti diskusi kanthi cepet lan nambal resizer eksternal, amarga ukuran disk offline minangka kemunduran sing bakal ilang saka kabeh panyedhiya maya.

Carane miwiti nggunakake?

Pembalap didhukung ing Kubernetes versi 1.15 lan luwih dhuwur. Supaya driver bisa kerja, syarat ing ngisor iki kudu dipenuhi:

• Bendera --allow-privileged disetel kanggo nilai true kanggo server API lan kubelet;
• Klebu --feature-gates=VolumeSnapshotDataSource=true,KubeletPluginsWatcher=true,CSINodeInfo=true,CSIDriverRegistry=true kanggo server API lan kubelet;
• Panyebaran gunung (panyebaran gunung) kudu diaktifake ing kluster. Nalika nggunakake Docker, daemon kudu dikonfigurasi supaya bisa dienggo bareng.

Kabeh langkah sing perlu kanggo instalasi dhewe diterangake ing README. Instalasi kalebu nggawe obyek ing Kubernetes saka manifests.

Supaya driver bisa digunakake, sampeyan kudu ing ngisor iki:

• Nemtokake pengenal direktori ing manifest (folder-id) Yandex.Cloud (ndeleng dokumentasi);
• Kanggo sesambungan karo Yandex.Cloud API, driver CSI nggunakake akun layanan. Ing manifest, Rahasia kudu dilewati tombol sah saka akun layanan. Ing dokumentasi diterangake, carane nggawe akun layanan lan entuk kunci.

Kabeh- nyoba, lan kita bakal seneng nampa saran lan masalah anyaryen sampeyan nemoni masalah!

Dhukungan luwih

Akibaté, kita pengin Wigati sing kita ngleksanakake driver CSI iki ora metu saka kepinginan gedhe kanggo seneng-seneng nulis aplikasi ing Go, nanging amarga saka kabutuhan urgent ing perusahaan. Kayane ora praktis kanggo kita njaga implementasine dhewe, dadi yen Yandex nuduhake minat lan mutusake kanggo terus ndhukung driver, kita bakal seneng nransfer repositori kasebut.

Kajaba iku, Yandex bisa uga duwe implementasine driver CSI dhewe ing kluster Kubernetes sing dikelola, sing bisa dirilis ing Open Source. Kita uga ndeleng opsi pangembangan iki minangka sarujuk - masyarakat bakal bisa nggunakake driver sing wis kabukten saka panyedhiya layanan, lan ora saka perusahaan pihak katelu.

PS

Waca uga ing blog kita:

• «Plugin volume kanggo panyimpenan Kubernetes: saka Flexvolume nganti CSI";
• «Kita ngerti Antarmuka Panyimpenan Kontainer (ing Kubernetes lan ora mung)";
• «Apa gampang lan trep kanggo nyiyapake kluster Kubernetes? Ngumumake addon-operator";
• «Ngembangake lan nambahi Kubernetes (ringkesan lan laporan video)".

Source: www.habr.com