Kubernetes klasterində işləyən tətbiqlər üçün məlumat yaddaşını konfiqurasiya etməyin bir neçə yolu var. Onlardan bəziləri artıq köhnəlib, digərləri çox yaxınlarda ortaya çıxdı. Bu yazıda biz saxlama sistemlərini birləşdirmək üçün üç variant, o cümlədən ən sonuncu - Konteyner Saxlama İnterfeysi vasitəsilə əlaqəni nəzərdən keçirəcəyik.
Metod 1: Pod manifestində PV-ni göstərin
Kubernetes klasterində podu təsvir edən tipik manifest:
Manifestin hansı həcmin bağlı olduğunu və harada olduğunu təsvir edən hissələri rənglə vurğulanır.
Bölmədə həcmli montajlar quraşdırma nöqtələrini (mountPath) göstərin - daimi həcmin konteyner daxilində hansı kataloqda quraşdırılacağı, həmçinin həcmin adı.
Bölmədə x podda istifadə olunan bütün cildləri sadalayır. Hər bir həcmin adını, həmçinin növünü (bizim halda: awsElasticBlockStore) və əlaqə parametrlərini göstərin. Manifestdə hansı parametrlərin sadalanması həcm növündən asılıdır.
Eyni həcm eyni vaxtda bir neçə pod qabda quraşdırıla bilər. Bu yolla, müxtəlif proqram prosesləri eyni məlumatlara daxil ola bilər.
Bu əlaqə metodu Kubernetes yenicə körpəlik dövründə olanda icad edilmişdir və bu gün metod köhnəlmişdir.
Onu istifadə edərkən bir neçə problem var:
- bütün cildlər əl ilə yaradılmalıdır; Kubernetes bizim üçün heç nə yarada bilməz;
- hər bir cild üçün giriş parametrləri unikaldır və onlar həcmi istifadə edən bütün podların manifestlərində göstərilməlidir;
- yaddaş sistemini dəyişdirmək üçün (məsələn, AWS-dən Google Cloud-a keçmək) bütün manifestlərdə quraşdırılmış həcmlərin parametrlərini və növünü dəyişdirməlisiniz.
Bütün bunlar çox əlverişsizdir, buna görə də əslində bu üsul yalnız bəzi xüsusi həcm növlərini birləşdirmək üçün istifadə olunur: configMap, gizli, emptyDir, hostPath:
-
configMap və secret, konteynerdə Kubernetes manifestlərindən olan fayllarla həcm yaratmağa imkan verən xidmət həcmləridir.
-
emptyDir müvəqqəti həcmdir, yalnız podun ömrü boyu yaradılmışdır. Müvəqqəti məlumatların sınaqdan keçirilməsi və ya saxlanması üçün istifadə etmək rahatdır. Pod silindikdə, boşDir həcmi də silinir və bütün məlumatlar itirilir.
-
hostPath - /etc/kubernetes daxil olmaqla, proqramla konteynerin daxilində proqramın işlədiyi serverin yerli diskinə istənilən kataloqu quraşdırmaq imkanı verir. Bu təhlükəli xüsusiyyətdir, ona görə də təhlükəsizlik siyasətləri adətən bu tip həcmlərin istifadəsini qadağan edir. Əks halda, təcavüzkarın tətbiqi HTC Kubernetes kataloqunu öz konteynerinə quraşdıra və bütün klaster sertifikatlarını oğurlaya biləcək. Tipik olaraq, hostPath həcmlərinin yalnız kube-sistem ad məkanında işləyən sistem tətbiqləri tərəfindən istifadə edilməsinə icazə verilir.
sənədlərdə verilir.
Metod 2. SC/PVC/PV ocaqlarına qoşulma
Alternativ əlaqə metodu Storage sinfi, PersistentVolumeClaim, PersistentVolume anlayışıdır.
Saxlama sinfi məlumat saxlama sisteminə qoşulma parametrlərini saxlayır.
Davamlı Həcmi İddia tətbiqin ehtiyac duyduğu tələbləri təsvir edir.
Davamlı Həcm giriş parametrlərini və həcm statusunu saxlayır.
İdeyanın mahiyyəti: pod manifestində onlar PersistentVolumeClaim tipli həcmi göstərir və claimName parametrində bu obyektin adını göstərirlər.
PersistentVolumeClaim manifest proqramın tələb etdiyi məlumatların həcminə dair tələbləri təsvir edir. O cümlədən:
- disk ölçüsü;
- giriş metodu: ReadWriteOnce və ya ReadWriteMany;
- Storage sinfinə keçid - hansı məlumat saxlama sistemində həcmi yaratmaq istəyirik.
Saxlama sinifi manifestində saxlama sisteminə qoşulma növü və parametrləri saxlanılır. Həcmi öz qovşağına quraşdırmaq üçün kubelet onlara lazımdır.
PersistentVolume manifestləri Yaddaş sinifini və xüsusi həcm üçün giriş parametrlərini göstərir (həcm identifikatoru, yol və s.).
PVC yaradarkən, Kubernetes hansı həcm həcminə və hansı Yaddaş sinifinin tələb olunduğuna baxır və pulsuz PersistentVolume seçir.
Əgər belə PV-lər mövcud deyilsə, Kubernetes xüsusi proqramı işə sala bilər - Provayder (onun adı Saxlama sinifində göstərilmişdir). Bu proqram yaddaş sisteminə qoşulur, tələb olunan ölçüdə həcm yaradır, identifikator alır və PersistentVolumeClaim ilə əlaqəli Kubernetes klasterində PersistentVolume manifestini yaradır.
Bütün bu abstraksiyalar dəsti proqramın hansı saxlama sistemi ilə işlədiyi barədə məlumatları proqram manifest səviyyəsindən idarəetmə səviyyəsinə çıxarmağa imkan verir.
Məlumat saxlama sisteminə qoşulmaq üçün bütün parametrlər klaster inzibatçılarının cavabdeh olduğu Storage sinifində yerləşir. AWS-dən Google Cloud-a keçərkən etməli olduğunuz tək şey tətbiq manifestlərində Yaddaş sinifinin adını PVC-yə dəyişməkdir. Məlumatların saxlanması üçün Davamlılıq Həcmi Provisioner proqramından istifadə etməklə avtomatik olaraq klasterdə yaradılacaq.
Metod 3. Konteyner Saxlama İnterfeysi
Müxtəlif saxlama sistemləri ilə qarşılıqlı əlaqədə olan bütün kodlar Kubernetes nüvəsinin bir hissəsidir. Baq həllərinin buraxılması və ya yeni funksionallıq yeni buraxılışlarla əlaqələndirilir; Kubernetes-in bütün dəstəklənən versiyaları üçün kod dəyişdirilməlidir. Bütün bunları saxlamaq və yeni funksionallıq əlavə etmək çətindir.
Problemi həll etmək üçün Cloud Foundry, Kubernetes, Mesos və Docker-in tərtibatçıları Konteyner Saxlama İnterfeysini (CSI) - konteyner idarəetmə sisteminin qarşılıqlı əlaqəsini təsvir edən sadə vahid interfeys və xüsusi ilə işləyən xüsusi sürücü (CSI Driver) yaratdılar. saxlama sistemi. Saxlama sistemləri ilə qarşılıqlı əlaqə üçün bütün kodlar Kubernetes nüvəsindən ayrı bir sistemə köçürüldü.
.
Tipik olaraq, CSI Driver iki komponentdən ibarətdir: Node Plugin və Controller plugin.
Node Plugin hər bir node üzərində işləyir və həcmlərin quraşdırılmasına və onlarda əməliyyatların yerinə yetirilməsinə cavabdehdir. Controller plagini yaddaş sistemi ilə qarşılıqlı əlaqədə olur: həcmləri yaradır və ya silir, giriş hüquqlarını təyin edir və s.
Hələlik köhnə drayverlər Kubernetes nüvəsində qalır, lakin onların artıq istifadəsi tövsiyə edilmir və hər kəsə işləyəcəkləri sistem üçün xüsusi olaraq CSI Sürücüsünü quraşdırmaları tövsiyə olunur.
Yenilik Storage sinfi vasitəsilə məlumatların saxlanmasını qurmağa artıq öyrəşmiş insanları qorxuda bilər, lakin əslində heç bir qorxulu heç nə baş verməyib. Proqramçılar üçün əslində heç nə dəyişmir - onlar yalnız Storage sinfi adı ilə işləyiblər və bundan sonra da edəcəklər. Administratorlar üçün sükan diaqramının quraşdırılması əlavə edildi və parametrlərin strukturu dəyişdirildi. Əgər əvvəllər parametrlər bilavasitə Storage sinfinə daxil edilmişdisə, indi onlar əvvəlcə sükan cədvəlində, sonra isə Storage sinfində təyin edilməlidir. Baxırsan, pis heç nə olmayıb.
CSI drayverindən istifadə edərək Ceph yaddaş sistemlərinə qoşulmaqla əldə edə biləcəyiniz üstünlüklərə baxmaq üçün bir nümunə götürək.
Ceph ilə işləyərkən, CSI plagini yaddaş sistemləri ilə işləmək üçün daxili sürücülərdən daha çox seçim təmin edir.
- Dinamik diskin yaradılması. Tipik olaraq RBD diskləri yalnız RWO rejimində istifadə olunur, lakin Ceph üçün CSI onları RWX rejimində istifadə etməyə imkan verir. Müxtəlif qovşaqlardakı bir neçə pods eyni RDB diskini öz qovşaqlarına quraşdıra və onlarla paralel işləyə bilər. Ədalətli olmaq üçün, hər şey o qədər də parlaq deyil - bu disk yalnız blok cihazı kimi birləşdirilə bilər, yəni proqramı onunla çoxlu giriş rejimində işləmək üçün uyğunlaşdırmalı olacaqsınız.
- Snapshotların yaradılması. Kubernetes klasterində snapshot yaratmaq tələbi ilə manifest yarada bilərsiniz. CSI plagini onu görəcək və diskdən şəkil çəkəcək. Bunun əsasında PersistentVolume-un ya ehtiyat nüsxəsini, ya da surətini çıxara bilərsiniz.
- Disk ölçüsünün artırılması Kubernetes klasterində saxlama və PersistentVolume haqqında.
- Kvotalar. Kubernetes-də quraşdırılmış CephFS sürücüləri kvotaları dəstəkləmir, lakin ən son Ceph Nautilus ilə təzə CSI plaginləri CephFS bölmələrində kvotaları aktivləşdirə bilər.
- Metriklər. CSI plagini Prometheus-a hansı həcmlərin qoşulduğu, hansı kommunikasiyaların baş verdiyi və s. haqqında müxtəlif göstəricilərlə təmin edə bilər.
- Topologiyadan xəbərdardır. Manifestlərdə klasterin coğrafi olaraq necə paylandığını dəqiqləşdirməyə və Amsterdamda yerləşən yaddaş sistemini Londonda işləyən podlara qoşmaqdan çəkinməyə imkan verir.
Ceph-i CSI vasitəsilə Kubernetes klasterinə necə bağlamaq olar, baxın . Siz də abunə ola bilərsiniz 15 oktyabrda başlayacaq.
Məqalənin müəllifi: Sergey Bondarev, Southbridge-də təcrübə keçən memar, Sertifikatlı Kubernetes Administratoru, kubespray-ın tərtibatçılarından biridir.
Bir az Post Scriptum reklam üçün deyil, fayda üçün...
PS Sergey Bondarev iki intensiv kursa rəhbərlik edir: yeniləndi 28-30 sentyabr və qabaqcıl 14-16 oktyabr.
Mənbə: www.habr.com