Persistent volume (PV) — Kubernetes klasterida saqlash resursini ifodalovchi API obyekti. U Pod ichidagi container fayl tizimidan mustaqil hayot davriga ega. PV administrator tomonidan oldindan yaratilishi yoki StorageClass orqali dinamik provision qilinishi mumkin; workload esa undan PersistentVolumeClaim (PVC) orqali joy so‘raydi.
PV va PVC munosabati
PVC foydalanuvchining talabini bildiradi: sig‘im, access mode va kerak bo‘lsa StorageClass. Control plane mos PV topib claim bilan bind qiladi. Pod manifesti bevosita backend disk identifikatorini emas, PVC nomini volume sifatida ko‘rsatadi. Bu workload deklaratsiyasini storage vendor tafsilotlaridan ajratadi.
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: database-data
spec:
accessModes: [ReadWriteOnce]
resources:
requests:
storage: 20Gi
storageClassName: fast-block
PVC Bound holatiga kelgach Pod uni mount qilishi mumkin. Claim o‘chirilmaguncha unga bog‘langan PV boshqa claimga berilmaydi.
Provisioning va CSI
Dynamic provisioning’da StorageClass provisioner, parametr va reclaim policy’ni belgilaydi. CSI driver cloud disk, SAN, distributed file system yoki boshqa backend bilan gaplashadi. Scheduler volume topology’sini hisobga oladi: ma’lum availability zone’dagi diskni boshqa zonadagi node’ga ulab bo‘lmasligi mumkin. WaitForFirstConsumer binding rejimi storage’ni Pod qayerga joylashgani ma’lum bo‘lgach yaratadi.
Static provisioning’da administrator mavjud storage resursiga mos PV manifestini yaratadi. Bu oldindan tayyorlangan yoki maxsus boshqariladigan storage uchun ishlatiladi.
Access mode va mount
ReadWriteOnce volume bir vaqtda bitta node tomonidan read-write ulanishini, ReadOnlyMany ko‘p node’dan faqat o‘qishni, ReadWriteMany esa ko‘p node’dan yozishni ifodalaydi. Bu capability backend va CSI driverga bog‘liq. Access mode file system darajasidagi user permission emas va barcha yozuvchilar orasida application lockingni avtomatik bermaydi.
volumeMode: Filesystem bo‘lsa kubelet qurilmani formatlab, Podga mount qiladi. Block rejimida raw block device containerga beriladi; dastur uning format va consistency’sini boshqaradi.
Reclaim va himoya
PVC o‘chirilganda Delete siyosati backend volume’ni ham o‘chirishi, Retain esa PVni qo‘lda tekshirish uchun saqlashi mumkin. Muhim ma’lumot uchun bu tanlov backup va compliance talabiga mos bo‘ladi. Kubernetes finalizerlari foydalanilayotgan storage obyektining muddatidan oldin o‘chishini cheklaydi, ammo noto‘g‘ri administrator amali yoki backend halokatidan backup bermaydi.
Volume expansion StorageClass ruxsat bersa PVC hajmini oshiradi. Block device kengayganidan keyin file system ham resize qilinadi. Hajmni kichraytirish odatda qo‘llanmaydi va yangi kichik volume’ga nazoratli ko‘chirishni talab qiladi.
Snapshot va operatsiyalar
CSI VolumeSnapshot point-in-time nusxa yaratish interfeysini beradi. Ishlayotgan database oldindan flush qilinmasa snapshot faqat crash-consistent bo‘lishi mumkin. Restore yangi PVC yaratishi mumkin; recovery jarayoni muntazam sinovdan o‘tkaziladi.
Muammolarni tahlil qilishda PVC/PV holati, Pod eventlari, CSI controller va node plugin loglari, attachment obyektlari hamda backend holati birga ko‘riladi. Pending claim mos StorageClass yo‘qligi, topology cheklovi yoki provisioner xatosini anglatishi mumkin.
Identity va ruxsatlar
Podning PVdan foydalanishi Kubernetes namespace va service account nazoratidan boshlanadi, lekin mount qilingan fayllarga kirish container user ID, group va file permissionlarga bog‘liq. fsGroup ayrim volume turlarida group egaligini moslashtiradi. Juda katta file systemda recursive ownership o‘zgarishi Pod startini sezilarli kechiktirishi mumkin.
Secretga o‘xshash ma’lumot uchun backend encryption, transport himoyasi va CSI credentiallari ham ko‘rib chiqiladi. PV manifestidagi volumeHandle odatda secret emas, ammo uni attach qilish huquqi yuqori darajada cheklanadi.
Bog‘liq tushunchalar
PersistentVolumeClaim, StorageClass, CSI, Storage volume, Access mode, VolumeSnapshot, StatefulSet, Reclaim policy