Mayroong ilang mga paraan upang i-configure ang storage ng data para sa mga application na tumatakbo sa isang Kubernetes cluster. Ang ilan sa kanila ay luma na, ang iba ay lumitaw kamakailan. Sa artikulong ito, titingnan natin ang konsepto ng tatlong mga opsyon para sa pagkonekta ng mga system ng imbakan, kabilang ang pinakabago - pagkonekta sa pamamagitan ng Container Storage Interface.
Paraan 1: Tukuyin ang PV sa pod manifest
Isang tipikal na manifest na naglalarawan sa isang pod sa isang Kubernetes cluster:
Ang mga bahagi ng manifest na naglalarawan kung aling volume ang konektado at kung saan naka-highlight sa kulay.
Sa seksyon volumeMounts ipahiwatig ang mga mount point (mountPath) - kung saan ang direktoryo sa loob ng lalagyan ay mai-mount ang permanenteng volume, pati na rin ang pangalan ng volume.
Sa seksyon x naglilista ng lahat ng volume na ginagamit sa pod. Tukuyin ang pangalan ng bawat volume, pati na rin ang uri (sa aming kaso: awsElasticBlockStore) at mga parameter ng koneksyon. Aling mga parameter ang nakalista sa manifest ay depende sa uri ng volume.
Ang parehong volume ay maaaring i-mount nang sabay-sabay sa maraming mga lalagyan ng pod. Sa ganitong paraan, maa-access ng iba't ibang proseso ng application ang parehong data.
Ang paraan ng koneksyon ay naimbento sa pinakadulo simula, noong ang Kubernetes ay nasa pagkabata pa lamang, at ngayon ang pamamaraan ay luma na.
Mayroong ilang mga problema kapag ginagamit ito:
- lahat ng volume ay dapat gawin nang manu-mano; ang Kubernetes ay hindi makakagawa ng anuman para sa amin;
- ang mga parameter ng pag-access para sa bawat volume ay natatangi, at dapat na tinukoy ang mga ito sa mga manifest ng lahat ng pod na gumagamit ng volume;
- para baguhin ang storage system (halimbawa, lumipat mula sa AWS patungo sa Google Cloud), kailangan mong baguhin ang mga setting at uri ng mga naka-mount na volume sa lahat ng mga manifest.
Ang lahat ng ito ay napaka-abala, kaya sa katotohanan ang pamamaraang ito ay ginagamit upang ikonekta lamang ang ilang mga espesyal na uri ng mga volume: configMap, lihim, emptyDir, hostPath:
-
Ang configMap at secret ay mga volume ng serbisyo na nagbibigay-daan sa iyong gumawa ng volume na may mga file mula sa Kubernetes manifests sa container.
-
Ang emptyDir ay isang pansamantalang volume, na nilikha lamang para sa habang-buhay ng pod. Maginhawang gamitin para sa pagsubok o pag-iimbak ng pansamantalang data. Kapag ang isang pod ay tinanggal, ang emptyDir volume ay tatanggalin din at ang lahat ng data ay mawawala.
-
hostPath - nagbibigay-daan sa iyo na i-mount ang anumang direktoryo sa lokal na disk ng server kung saan tumatakbo ang application sa loob ng lalagyan na may application, kasama ang /etc/kubernetes. Isa itong hindi ligtas na feature, kaya karaniwang ipinagbabawal ng mga patakaran sa seguridad ang paggamit ng mga volume ng ganitong uri. Kung hindi, magagawa ng application ng attacker na i-mount ang direktoryo ng HTC Kubernetes sa loob ng container nito at nakawin ang lahat ng cluster certificate. Kadalasan, pinapayagan lang ang mga volume ng hostPath na gamitin ng mga application ng system na tumatakbo sa namespace ng kube-system.
ay ibinigay sa dokumentasyon.
Paraan 2. Koneksyon sa SC/PVC/PV hearths
Ang isang alternatibong paraan ng koneksyon ay ang konsepto ng Storage class, PersistentVolumeClaim, PersistentVolume.
Imbakan klase nag-iimbak ng mga parameter ng koneksyon sa data storage system.
PersistentVolumeClaim inilalarawan ang mga kinakailangan para sa kung ano ang kailangan ng aplikasyon.
PersistentVolume nag-iimbak ng mga parameter ng access at katayuan ng volume.
Ang kakanyahan ng ideya: sa pod manifest ay nagpapahiwatig sila ng dami ng uri ng PersistentVolumeClaim at ipinapahiwatig ang pangalan ng entity na ito sa parameter ng claimName.
Inilalarawan ng manifest ng PersistentVolumeClaim ang mga kinakailangan para sa dami ng data na kinakailangan ng application. Kasama ang:
- laki ng disk;
- paraan ng pag-access: ReadWriteOnce o ReadWriteMany;
- link sa Storage class - kung saan ang data storage system ay gusto naming gawin ang volume.
Ang Storage class manifest ay nag-iimbak ng uri at mga parameter ng koneksyon sa storage system. Kailangan ng cubelet ang mga ito upang i-mount ang volume sa node nito.
Ang mga manifest ng PersistentVolume ay nagpapahiwatig ng klase ng Storage at mga parameter ng access para sa isang partikular na volume (volume ID, path, atbp.).
Kapag gumagawa ng PVC, tinitingnan ng Kubernetes kung anong laki ng volume at kung anong klase ng Storage ang kailangan, at pumipili ng libreng PersistentVolume.
Kung hindi available ang mga naturang PV, maaaring maglunsad ang Kubernetes ng isang espesyal na programa - Provisioner (nakasaad ang pangalan nito sa klase ng Storage). Ang program na ito ay kumokonekta sa storage system, gumagawa ng volume ng kinakailangang laki, tumatanggap ng identifier at gumagawa ng PersistentVolume manifest sa Kubernetes cluster, na nauugnay sa PersistentVolumeClaim.
Ang lahat ng maraming abstraction na ito ay nagbibigay-daan sa iyo na mag-alis ng impormasyon tungkol sa kung aling storage system ang ginagamit ng application mula sa antas ng manifest ng application hanggang sa antas ng pangangasiwa.
Ang lahat ng mga parameter para sa pagkonekta sa data storage system ay matatagpuan sa Storage class, kung saan ang mga cluster administrator ay may pananagutan. Ang kailangan mo lang gawin kapag lumipat mula sa AWS patungo sa Google Cloud ay baguhin ang pangalan ng klase ng Storage sa PVC sa mga manifest ng application. Ang Persistance Volume para sa pag-iimbak ng data ay awtomatikong gagawin sa cluster gamit ang Provisioner program.
Paraan 3: Container Storage Interface
Ang lahat ng code na nakikipag-ugnayan sa iba't ibang storage system ay bahagi ng Kubernetes core. Ang paglabas ng mga pag-aayos ng bug o bagong functionality ay nauugnay sa mga bagong release; dapat baguhin ang code para sa lahat ng sinusuportahang bersyon ng Kubernetes. Ang lahat ng ito ay mahirap mapanatili at magdagdag ng bagong pag-andar.
Upang malutas ang problema, nilikha ng mga developer mula sa Cloud Foundry, Kubernetes, Mesos at Docker ang Container Storage Interface (CSI) - isang simpleng pinag-isang interface na naglalarawan sa pakikipag-ugnayan ng container management system at isang espesyal na driver (CSI Driver) na gumagana sa isang partikular na sistema ng imbakan. Ang lahat ng code para sa pakikipag-ugnayan sa mga storage system ay inilipat mula sa Kubernetes core patungo sa isang hiwalay na system.
.
Karaniwan, ang CSI Driver ay binubuo ng dalawang bahagi: Node Plugin at Controller plugin.
Ang Node Plugin ay tumatakbo sa bawat node at responsable para sa pag-mount ng mga volume at pagsasagawa ng mga operasyon sa mga ito. Nakikipag-ugnayan ang Controller plugin sa storage system: gumagawa o nagtatanggal ng mga volume, nagtatalaga ng mga karapatan sa pag-access, atbp.
Sa ngayon, ang mga lumang driver ay nananatili sa kernel ng Kubernetes, ngunit hindi na ito inirerekomenda na gamitin at pinapayuhan ang lahat na i-install ang CSI Driver partikular para sa system kung saan sila gagana.
Maaaring takutin ng inobasyon ang mga nakasanayan nang mag-set up ng imbakan ng data sa pamamagitan ng klase ng Storage, ngunit sa katunayan ay walang nangyaring kakila-kilabot. Para sa mga programmer, wala talagang nagbabago - nagtrabaho lang sila sa pangalang Storage class, at patuloy na gagawin ito. Para sa mga administrator, ang pag-install ng helm chart ay naidagdag at ang istraktura ng mga setting ay nagbago. Kung dati ay direktang ipinasok ang mga setting sa klase ng Storage, ngayon ay dapat munang itakda ang mga ito sa chart ng timon, at pagkatapos ay sa klase ng Storage. Kung titingnan mo, walang masamang nangyari.
Kumuha tayo ng isang halimbawa upang tingnan ang mga benepisyong makukuha mo sa pamamagitan ng paglipat sa pagkonekta ng mga sistema ng imbakan ng Ceph gamit ang driver ng CSI.
Kapag nagtatrabaho sa Ceph, ang CSI plugin ay nagbibigay ng higit pang mga opsyon para sa pagtatrabaho sa mga storage system kaysa sa mga built-in na driver.
- Paglikha ng dynamic na disk. Karaniwan ang mga RBD disk ay ginagamit lamang sa RWO mode, ngunit pinapayagan ng CSI para sa Ceph na gamitin ang mga ito sa RWX mode. Ang ilang mga pod sa iba't ibang mga node ay maaaring mag-mount ng parehong RDB disk sa kanilang mga node at gumana sa kanila nang magkatulad. Upang maging patas, hindi lahat ay napakaliwanag - ang disk na ito ay maaari lamang ikonekta bilang isang block device, na nangangahulugang kailangan mong iakma ang application upang gumana dito sa maraming access mode.
- Paglikha ng mga snapshot. Sa isang cluster ng Kubernetes, maaari kang gumawa ng manifest na may pangangailangang gumawa ng snapshot. Makikita ito ng CSI plugin at kukuha ng snapshot mula sa disk. Batay dito, maaari kang gumawa ng alinman sa isang backup o isang kopya ng PersistentVolume.
- Pagtaas ng laki ng disk sa storage at PersistentVolume sa isang Kubernetes cluster.
- Mga quota. Ang mga driver ng CephFS na binuo sa Kubernetes ay hindi sumusuporta sa mga quota, ngunit ang mga sariwang CSI plugin na may pinakabagong Ceph Nautilus ay maaaring paganahin ang mga quota sa mga partisyon ng CephFS.
- Mga sukatan. Ang CSI plugin ay maaaring magbigay sa Prometheus ng iba't ibang sukatan tungkol sa kung aling mga volume ang konektado, kung anong mga komunikasyon ang nagaganap, atbp.
- Alam ng topology. Binibigyang-daan kang tukuyin sa mga manifest kung paano nahahati sa heograpiya ang cluster, at iwasang ikonekta ang isang storage system na matatagpuan sa Amsterdam sa mga pod na tumatakbo sa London.
Paano ikonekta si Ceph sa isang kumpol ng Kubernetes sa pamamagitan ng CSI, tingnan . Maaari ka ring mag-subscribe sa , na ilulunsad sa ika-15 ng Oktubre.
May-akda ng artikulo: Sergey Bondarev, nagsasanay na arkitekto sa Southbridge, Certified Kubernetes Administrator, isa sa mga developer ng kubespray.
Isang maliit na Post Scriptum hindi para sa advertising, ngunit para sa kapakinabangan...
Pinangunahan ni PS Sergey Bondarev ang dalawang masinsinang kurso: na-update Setyembre 28-30 at advanced Oktubre 14β16.
Pinagmulan: www.habr.com