Kubernetes кластер дээр ажиллаж байгаа програмуудад зориулсан мэдээллийн санг тохируулах хэд хэдэн арга байдаг. Тэдний зарим нь аль хэдийн хуучирсан, бусад нь саяхан гарч ирсэн. Энэ нийтлэлд бид хадгалах системийг холбох гурван сонголтын тухай ойлголтыг авч үзэх болно, үүнд хамгийн сүүлийнх нь - Контейнер хадгалах интерфейсээр дамжуулан холбогдох болно.
Арга 1: Под манифестэд PV-г зааж өгнө үү
Kubernetes кластер дахь хонхорцог дүрсэлсэн ердийн манифест:
Манифестын аль хэмжээ холбогдсон, хаана байгааг тодорхойлсон хэсгүүдийг өнгөөр тодруулсан.
хэсэг эзлэхүүнийг холбох холбох цэгүүдийг (mountPath) зааж өгнө - савны доторх байнгын эзэлхүүнийг аль директорт байрлуулах, түүнчлэн эзлэхүүний нэрийг зааж өгнө.
хэсэг x pod-д ашиглагдаж буй бүх ботийг жагсаав. Боть бүрийн нэр, төрөл (бидний тохиолдолд: awsElasticBlockStore) болон холболтын параметрүүдийг зааж өгнө үү. Манифестэд аль параметрүүдийг жагсаах нь эзлэхүүний төрлөөс хамаарна.
Ижил эзэлхүүнийг олон тооны савны саванд нэгэн зэрэг суулгаж болно. Ингэснээр өөр өөр програмын процессууд ижил өгөгдөлд хандах боломжтой болно.
Энэхүү холболтын аргыг Кубернетес дөнгөж дөнгөж эхэлж байх үед анх зохион бүтээсэн бөгөөд өнөөдөр энэ арга хуучирсан байна.
Үүнийг ашиглахад хэд хэдэн асуудал гардаг:
- бүх боть гараар бүтээгдсэн байх ёстой; Kubernetes бидэнд юу ч үүсгэж чадахгүй;
- эзлэхүүн бүрийн хандалтын параметрүүд нь өвөрмөц бөгөөд тэдгээр нь эзлэхүүнийг ашигладаг бүх pods-ийн манифестуудад тодорхойлогдсон байх ёстой;
- хадгалах системийг өөрчлөхийн тулд (жишээ нь, AWS-ээс Google Cloud руу шилжих) та бүх манифест дахь суулгасан эзлэхүүний тохиргоо болон төрлийг өөрчлөх хэрэгтэй.
Энэ бүхэн маш тохиромжгүй тул бодит байдал дээр энэ аргыг зөвхөн зарим төрлийн эзлэхүүнийг холбоход ашигладаг: configMap, secret, emptyDir, hostPath:
-
configMap болон secret нь Кубернетес манифестийн файлуудыг багтаасан файлуудыг үүсгэх боломжийг олгодог үйлчилгээний хэмжээ юм.
-
emptyDir нь түр зуурын хэмжээ бөгөөд зөвхөн pod-н ашиглалтын хугацаанд бүтээгдсэн. Түр зуурын өгөгдлийг турших эсвэл хадгалахад ашиглахад тохиромжтой. Под устгагдсан үед хоосонDir эзлэхүүн мөн устаж, бүх өгөгдөл устах болно.
-
hostPath - /etc/kubernetes зэрэг програмтай контейнер дотор програм ажиллаж байгаа серверийн локал диск дээр дурын санг холбох боломжийг танд олгоно. Энэ нь аюултай шинж чанартай тул аюулгүй байдлын бодлогод энэ төрлийн боть ашиглахыг хориглодог. Үгүй бол халдагчийн програм HTC Kubernetes лавлахыг чингэлэгтээ суулгаж, кластерын бүх гэрчилгээг хулгайлах боломжтой болно. Ерөнхийдөө hostPath эзлэхүүнийг зөвхөн kube-системийн нэрийн талбарт ажилладаг системийн програмуудад ашиглахыг зөвшөөрдөг.
баримт бичигт өгсөн болно.
Арга 2. SC/PVC/PV зууханд холбох
Холболтын өөр арга бол Storage class, PersistentVolumeClaim, PersistentVolume гэсэн ойлголт юм.
Хадгалах анги өгөгдөл хадгалах системд холболтын параметрүүдийг хадгалдаг.
Байнгын Боть нэхэмжлэл програмд юу хэрэгтэй байгааг тодорхойлсон.
Байнгын эзлэхүүн хандалтын параметрүүд болон эзлэхүүний төлөвийг хадгалдаг.
Санаагийн мөн чанар: pod manifest-д тэд PersistentVolumeClaim төрлийн эзлэхүүнийг зааж, claimName параметрт энэ аж ахуйн нэгжийн нэрийг зааж өгнө.
PersistentVolumeClaim манифест нь програмд шаардагдах өгөгдлийн эзлэхүүнд тавигдах шаардлагыг тодорхойлдог. Үүнд:
- дискний хэмжээ;
- хандалтын арга: ReadWriteOnce эсвэл ReadWriteMany;
- Хадгалах анги руу холбох - ямар өгөгдөл хадгалах системд бид эзлэхүүнийг үүсгэхийг хүсч байна.
Хадгалах ангийн манифест нь хадгалах системд холбогдох холболтын төрөл, параметрүүдийг хадгалдаг. Кубелет нь зангилаа дээрээ эзлэхүүнийг холбоход хэрэгтэй.
PersistentVolume манифест нь тодорхой эзлэхүүний (эзлэхүүний ID, зам гэх мэт) Хадгалах анги болон хандалтын параметрүүдийг заадаг.
PVC бүтээхдээ Kubernetes ямар хэмжээтэй хэмжээ, ямар Хадгалах анги шаардлагатайг харж, үнэ төлбөргүй PersistentVolume-г сонгоно.
Хэрэв ийм PV байхгүй бол Kubernetes тусгай програмыг ажиллуулж болно - Provisioner (түүний нэрийг Хадгалах ангид заасан). Энэ програм нь хадгалах системд холбогдож, шаардлагатай хэмжээний эзлэхүүнийг үүсгэж, танигч хүлээн авч, PersistentVolumeClaim-тай холбоотой Kubernetes кластерт PersistentVolume манифест үүсгэдэг.
Энэ бүх хийсвэр багц нь програмын манифестын түвшнээс удирдлагын түвшинд ямар хадгалалтын системтэй ажиллаж байгаа талаарх мэдээллийг устгах боломжийг танд олгоно.
Мэдээллийн хадгалалтын системд холбогдох бүх параметрүүд нь кластерын администраторууд хариуцдаг Хадгалах ангид байрладаг. AWS-ээс Google Cloud руу шилжихдээ хийх ёстой зүйл бол програмын манифест дахь Хадгалах ангийн нэрийг PVC болгон өөрчлөх явдал юм. Өгөгдөл хадгалах Тогтвортой эзлэхүүнийг Provisioner програмыг ашиглан кластерт автоматаар үүсгэнэ.
Арга 3: Контейнер хадгалах интерфейс
Төрөл бүрийн хадгалалтын системтэй харьцдаг бүх код нь Кубернетесийн үндсэн хэсэг юм. Алдаа засах эсвэл шинэ функцийг гаргах нь шинэ хувилбаруудтай холбоотой бөгөөд Kubernetes-ийн дэмжигдсэн бүх хувилбарын кодыг өөрчлөх шаардлагатай. Энэ бүгдийг хадгалах, шинэ функц нэмэхэд хэцүү байдаг.
Асуудлыг шийдэхийн тулд Cloud Foundry, Kubernetes, Mesos болон Docker-ийн хөгжүүлэгчид контейнер хадгалах интерфэйсийг (CSI) бүтээсэн бөгөөд энэ нь чингэлэгийн удирдлагын системийн харилцан үйлчлэлийг дүрсэлсэн энгийн нэгдсэн интерфейс ба тусгай драйвер (CSI драйвер) -тай ажилладаг. хадгалах систем. Хадгалах системтэй харилцах бүх кодыг Kubernetes-ийн цөмөөс тусдаа систем рүү шилжүүлсэн.
.
Ерөнхийдөө CSI Driver нь Node Plugin ба Controller plugin гэсэн хоёр бүрэлдэхүүн хэсгээс бүрдэнэ.
Node Plugin нь зангилаа бүр дээр ажилладаг бөгөөд эзлэхүүнийг холбох, тэдгээрт үйлдлүүдийг гүйцэтгэх үүрэгтэй. Controller залгаас нь хадгалах системтэй харилцдаг: эзлэхүүн үүсгэх эсвэл устгах, хандалтын эрхийг хуваарилах гэх мэт.
Одоогийн байдлаар хуучин драйверууд Kubernetes цөмд хэвээр байгаа боловч тэдгээрийг ашиглахыг зөвлөдөггүй бөгөөд хүн бүр CSI драйверийг ажиллах системдээ тусгайлан суулгахыг зөвлөж байна.
Энэхүү шинэлэг зүйл нь Хадгалах ангиар дамжуулан өгөгдөл хадгалах байгууламжийг суулгаж дассан хүмүүсийг айлгаж магадгүй ч үнэндээ аймшигтай зүйл болоогүй юм. Програмистуудын хувьд үнэндээ юу ч өөрчлөгдөөгүй - тэд зөвхөн Хадгалах ангийн нэрээр ажилласан бөгөөд цаашид ч ажиллах болно. Администраторуудын хувьд жолооны график суулгацыг нэмж, тохиргооны бүтэц өөрчлөгдсөн. Хэрэв өмнө нь тохиргоог шууд Хадгалах ангид оруулсан бол одоо тэдгээрийг эхлээд жолооны диаграммд, дараа нь Хадгалах ангид тохируулах ёстой. Хэрэв та үүнийг ажиглавал ямар ч муу зүйл болоогүй.
CSI драйвер ашиглан Ceph хадгалах системд шилжихэд ямар ашиг тустай болохыг жишээгээр авч үзье.
Ceph-тэй ажиллахдаа CSI залгаас нь суулгасан драйверуудаас илүү хадгалах системтэй ажиллах боломжийг олгодог.
- Динамик диск үүсгэх. Ихэвчлэн RBD дискийг зөвхөн RWO горимд ашигладаг боловч CSI for Ceph нь тэдгээрийг RWX горимд ашиглах боломжийг олгодог. Өөр өөр зангилаанууд дээрх хэд хэдэн pods нь ижил RDB дискийг зангилаа дээрээ холбож, тэдэнтэй зэрэгцэн ажиллах боломжтой. Шударга байхын тулд бүх зүйл тийм ч тод биш байна - энэ дискийг зөвхөн блок төхөөрөмж хэлбэрээр холбох боломжтой бөгөөд энэ нь та олон хандалтын горимд ажиллахын тулд програмыг тохируулах хэрэгтэй болно гэсэн үг юм.
- Хормын хувилбаруудыг үүсгэж байна. Kubernetes кластерт та хормын хувилбар үүсгэх шаардлага бүхий манифест үүсгэж болно. CSI залгаас үүнийг харж, дискнээс агшин зуурын зургийг авна. Үүний үндсэн дээр та PersistentVolume-ийн нөөц болон хуулбарыг хийж болно.
- Дискний хэмжээг нэмэгдүүлэх Kubernetes кластер дахь хадгалах болон PersistentVolume дээр.
- Квот. Kubernetes-д суурилуулсан CephFS драйверууд квотыг дэмждэггүй боловч хамгийн сүүлийн үеийн Ceph Nautilus-тай CSI шинэ залгаасууд CephFS хуваалтууд дээр квотыг идэвхжүүлж чадна.
- Хэмжигдэхүүн. CSI залгаас нь Prometheus-д ямар боть холбогдсон, ямар харилцаа холбоо байгаа гэх мэт олон төрлийн хэмжигдэхүүнийг өгөх боломжтой.
- Топологийг мэддэг. Кластер нь газарзүйн хувьд хэрхэн тархсаныг манифестуудад зааж өгөх, Амстердам дахь хадгалах системийг Лондонд ажиллаж буй подкуудтай холбохоос зайлсхийх боломжийг танд олгоно.
Ceph-ийг CSI-ээр дамжуулан Kubernetes кластерт хэрхэн холбох талаар үзнэ үү . Та мөн бүртгүүлэх боломжтой , 15-р сарын XNUMX-нд нээлтээ хийнэ.
Өгүүллийн зохиогч: Сергей Бондарев, Southbridge-ийн архитекторч, Kubernetes-ийн гэрчилгээжсэн администратор, kubespray-ийг хөгжүүлэгчдийн нэг.
Бяцхан Post Scriptum нь сурталчилгааны зорилгоор биш, харин ашиг тусын тулд...
PS Сергей Бондарев хоёр эрчимжүүлсэн курс удирддаг: шинэчлэгдсэн 28-р сарын 30-XNUMX болон ахисан 14-р сарын 16-XNUMX.
Эх сурвалж: www.habr.com