Nyimpen data dina klaster Kubernetes

Aya sababaraha cara pikeun ngonpigurasikeun panyimpenan data pikeun aplikasi anu dijalankeun dina klaster Kubernetes. Sababaraha di antarana geus tinggaleun jaman, batur mucunghul rada anyar. Dina tulisan ieu, urang bakal ningali konsép tilu pilihan pikeun nyambungkeun sistem panyimpen, kalebet anu paling anyar - nyambungkeun via Interface Panyimpenan Wadahna.

Métode 1: Sebutkeun PV dina manifest pod

Manifes khas anu ngajelaskeun pod dina klaster Kubernetes:

Bagian tina manifes anu ngajelaskeun volume mana anu disambungkeun sareng dimana disorot dina warna.

bagean volumeMounts nunjukkeun titik gunung (mountPath) - dimana diréktori di jero wadahna bakal dipasang volume permanén, ogé nami polumeu.

bagean x daptar sadaya jilid nu dipaké dina pod nu. Sebutkeun nami unggal volume, ogé jinisna (dina hal urang: awsElasticBlockStore) sareng parameter sambungan. Parameter anu didaptarkeun dina manifes gumantung kana jinis volume.

Volume sarua bisa dipasang sakaligus dina sababaraha wadah pod. Ku cara ieu, prosés aplikasi anu béda tiasa ngaksés data anu sami.

Metoda sambungan ieu nimukeun di pisan awal, nalika Kubernetes éta ngan di infancy na, sarta kiwari metoda geus luntur.

Aya sababaraha masalah nalika ngagunakeunana:

1. sadaya jilid kudu dijieun sacara manual; Kubernetes teu bisa nyieun nanaon keur urang;
2. parameter aksés pikeun tiap volume anu unik, sarta maranéhanana kudu dieusian dina manifests sadaya pods nu make volume;
3. Pikeun ngarobah sistem panyimpen (contona, mindahkeun tina AWS ka Google Cloud), anjeun kedah ngarobih setélan sareng jinis jilid anu dipasang dina sadaya manifestasi.

Sadaya ieu teu merenah, jadi kanyataanana metoda ieu dipaké pikeun nyambungkeun ngan sababaraha tipe husus tina jilid: configMap, rusiah, emptyDir, hostPath:

• configMap sareng rahasia mangrupikeun jilid jasa anu ngamungkinkeun anjeun nyiptakeun volume sareng file tina Kubernetes anu diwujudkeun dina wadahna.

• emptyDir mangrupakeun volume samentara, dijieun ngan pikeun hirupna pod. Gampang dianggo pikeun nguji atanapi nyimpen data samentawis. Nalika pod a dihapus, volume emptyDir ogé dihapus sarta sakabeh data leungit.

• hostPath - ngamungkinkeun anjeun masang diréktori naon waé dina disk lokal pangladén dimana aplikasina dijalankeun di jero wadah sareng aplikasi, kalebet /etc/kubernetes. Ieu mangrupikeun fitur anu teu aman, janten kawijakan kaamanan biasana ngalarang panggunaan volume jinis ieu. Upami teu kitu, aplikasi panyerang bakal tiasa masang diréktori HTC Kubernetes di jero wadahna sareng maok sadaya sertipikat klaster. Biasana, volume hostPath ngan ukur diidinan dianggo ku aplikasi sistem anu dijalankeun dina rohangan ngaran kube-sistem.

Sistem panyimpenan anu dianggo ku Kubernetes di luar kotak dirumuskeun dina dokuméntasi.

Métode 2. Sambungan ka SC / PVC / PV hearths

Metodeu sambungan alternatif nyaéta konsép kelas Panyimpenan, PersistentVolumeClaim, PersistentVolume.

kelas gudang nyimpen parameter sambungan kana sistem panyimpen data.

PersistentVolumeClaim ngajelaskeun sarat pikeun kaperluan aplikasi.
PersistentVolume nyimpen parameter aksés jeung status volume.

Intina ide: dina pod manifest aranjeunna nunjukkeun volume tipe PersistentVolumeClaim sareng nunjukkeun nami éntitas ieu dina parameter claimName.

Manifes PersistentVolumeClaim ngajelaskeun sarat pikeun volume data anu diperyogikeun ku aplikasi. Kaasup:

• ukuran disk;
• métode aksés: ReadWriteOnce atanapi ReadWriteMany;
• link ka kelas Panyimpenan - dimana sistem panyimpen data urang hoyong nyiptakeun volume.

Manifes kelas Panyimpenan nyimpen jinis sareng parameter sambungan kana sistem panyimpen. Cubelet peryogi aranjeunna pikeun masang volume dina titik na.

PersistentVolume manifests nunjukkeun kelas Panyimpenan sarta aksés parameter pikeun volume husus (volume ID, jalur, jsb).

Nalika nyieun PVC a, Kubernetes kasampak dina naon volume ukuran na naon kelas Panyimpenan diperlukeun, tur pilih hiji bebas PersistentVolume.

Upami PV sapertos kitu henteu sayogi, Kubernetes tiasa ngaluncurkeun program khusus - Provisioner (ngaranna dituduhkeun dina kelas Panyimpenan). Program ieu nyambung ka sistem panyimpen, nyiptakeun volume ukuran anu diperyogikeun, nampi identifier sareng nyiptakeun PersistentVolume manifest dina klaster Kubernetes, anu pakait sareng PersistentVolumeClaim.

Sadaya set abstraksi ieu ngamungkinkeun anjeun mupus inpormasi ngeunaan sistem panyimpen anu dianggo ku aplikasi tina tingkat nyata aplikasi ka tingkat administrasi.

Kabéh parameter pikeun nyambungkeun ka sistem gudang data lokasina di kelas Panyimpenan, nu pangurus klaster jawab. Sadaya anu anjeun kedah laksanakeun nalika ngalih ti AWS ka Google Cloud nyaéta ngarobih nami kelas Panyimpen ka PVC dina manifests aplikasi. Jilid kegigihan pikeun neundeun data bakal didamel dina kluster sacara otomatis nganggo program Provisioner.

Métode 3: Interface Panyimpenan Wadahna

Sadaya kode anu berinteraksi sareng sababaraha sistem panyimpen mangrupikeun bagian tina inti Kubernetes. Pelepasan perbaikan bug atanapi fungsionalitas anyar dikaitkeun sareng rilis énggal; kodeu kedah dirobih kanggo sadaya vérsi Kubernetes anu dirojong. Sadaya ieu sesah pikeun ngajaga sareng nambihan fungsionalitas énggal.

Pikeun ngabéréskeun masalah, pamekar ti Cloud Foundry, Kubernetes, Mesos sareng Docker nyiptakeun Container Storage Interface (CSI) - antarbeungeut anu ngahijikeun saderhana anu ngajelaskeun interaksi sistem manajemen wadah sareng supir khusus (CSI Driver) anu tiasa dianggo sareng spésifik. Sistim neundeun. Sadaya kode pikeun interaksi sareng sistem panyimpenan dipindahkeun tina inti Kubernetes ka sistem anu misah.

Wadah Panyimpenan Interface Dokuméntasi.

Biasana, Supir CSI diwangun ku dua komponén: Plugin Node sareng plugin Controller.

Plugin Node dijalankeun dina unggal node sareng tanggung jawab pikeun ningkatna volume sareng ngalaksanakeun operasi dina éta. Plugin Controller berinteraksi sareng sistem panyimpen: nyiptakeun atanapi ngahapus volume, masihan hak aksés, jsb.

Pikeun ayeuna, supir lami tetep aya dina kernel Kubernetes, tapi aranjeunna henteu disarankeun deui dianggo sareng sadayana disarankan pikeun masang Supir CSI khusus pikeun sistem anu bakal dianggo.

Inovasi tiasa nyingsieunan jalma anu parantos biasa nyetél panyimpen data ngalangkungan kelas Panyimpenan, tapi nyatana teu aya anu dahsyat anu kajantenan. Pikeun programer, teu aya anu bener-bener robih - aranjeunna ngan ukur damel sareng nami kelas Panyimpen, sareng bakal teras-terasan. Pikeun pangurus, pamasangan bagan kemudi parantos ditambah sareng struktur setélan parantos robih. Upami sateuacana setélan diasupkeun langsung kana kelas Panyimpenan, ayeuna kedah disetél heula dina bagan Helm, teras di kelas Panyimpenan. Lamun ditilik deui, euweuh kajadian goréng.

Hayu urang nyandak conto pikeun ningali kauntungan anu anjeun tiasa kéngingkeun ku ngalih ka nyambungkeun sistem panyimpenan Ceph nganggo supir CSI.

Nalika damel sareng Ceph, plugin CSI nyayogikeun langkung seueur pilihan pikeun damel sareng sistem panyimpen tibatan supir anu diwangun.

1. Nyiptakeun disk dinamis. Ilaharna RBD disk dipaké ukur dina modeu RWO, tapi CSI pikeun Ceph ngamungkinkeun aranjeunna dipaké dina modeu RWX. Sababaraha pods dina titik béda bisa masang disk RDB sarua dina titik maranéhanana sarta dianggo kalayan aranjeunna dina paralel. Janten adil, henteu sadayana terang pisan - disk ieu ngan ukur tiasa dihubungkeun salaku alat blok, anu hartosna anjeun kedah adaptasi aplikasi pikeun dianggo dina sababaraha modeu aksés.
2. Nyieun snapshots. Dina klaster Kubernetes, anjeun tiasa ngadamel manifest kalayan sarat pikeun nyieun snapshot. Plugin CSI bakal ningali éta sareng nyandak snapshot tina disk. Dumasar kana éta, anjeun tiasa ngadamel cadangan atanapi salinan PersistentVolume.
3. Ngaronjatkeun ukuran disk on neundeun jeung PersistentVolume dina klaster Kubernetes.
4. Kuota. Supir CephFS diwangun kana Kubernetes henteu ngadukung kuota, tapi plugins CSI seger sareng Ceph Nautilus panganyarna tiasa ngaktipkeun kuota dina partisi CephFS.
5. Métrik. Plugin CSI tiasa nyayogikeun Prometheus ku rupa-rupa métrik ngeunaan jilid mana anu disambungkeun, komunikasi naon anu lumangsung, jsb.
6. Topologi sadar. Ngidinan Anjeun pikeun nangtukeun dina manifests kumaha kluster ieu disebarkeun geografi, sarta ulah aya nyambungkeun sistem gudang lokasina di Amsterdam ka pods ngajalankeun di London.

Kumaha nyambungkeun Ceph ka klaster Kubernetes via CSI, tingali dina bagian praktis tina kuliah malem Slurm sakola. Anjeun oge bisa ngalanggan Kursus video Ceph, anu bakal diluncurkeun dina 15 Oktober.

Panulis artikel: Sergey Bondarev, practicing arsiték di Southbridge, Certified Kubernetes Administrator, salah sahiji pamekar kubespray.

Saeutik Post Scriptum sanes pikeun pariwara, tapi pikeun kauntungan...

PS Sergey Bondarev mingpin dua kursus intensif: diropéa Pangkalan Kubernetes 28-30 September tur maju Kubernetes Mega 14–16 Oktober.

sumber: www.habr.com