عرفنا أنّ الـ pods مؤقّتة: إن اختفى pod، اختفت بياناته المحلّية. فكيف نحفظ بيانات تبقى بعد الـ pod؟ عبر الأحجام الدائمة. درس متوسّط.
المشكلة: التخزين يجب أن يتجاوز الـ Pod
قاعدة بيانات داخل pod تفقد بياناتها إن حُذف الـ pod أو أُعيدت جدولته على عقدة أخرى. نحتاج تخزينًا مستقلًّا عن دورة حياة الـ pod، يبقى ويلتحق بالـ pod الجديد.
الفكرة: فصل التخزين عن الطلب
يفصل Kubernetes بين مورد التخزين وطلب استخدامه عبر كائنين:
- الحجم الدائم (Persistent Volume — PV): قطعة تخزين فعليّة في العنقود (قرص سحابي، NFS...)، يوفّرها المسؤول أو تُنشأ تلقائيًا. إنها المورد.
- مطالبة الحجم الدائم (Persistent Volume Claim — PVC): طلب يقدّمه المطوّر للحصول على تخزين بمواصفات معيّنة (الحجم، نمط الوصول). Kubernetes يربط الطلب بحجم مناسب.
هذا الفصل يشبه فصل «المورد» عن «الطلب»: المطوّر يطلب تخزينًا دون أن يهتمّ بتفاصيل توفيره.
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: data
spec:
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 10Gi
يطلب هذا المثال 10 جيجابايت بنمط وصول «قراءة/كتابة من عقدة واحدة». يربط الـ pod هذه المطالبة فيحصل على تخزينه الدائم.
StorageClass: التوفير التلقائي
بدل أن ينشئ المسؤول الأحجام يدويًا مسبقًا، تتيح فئة التخزين (StorageClass) توفير التخزين ديناميكيًا عند تقديم المطالبة — فيُنشأ القرص تلقائيًا بالمواصفات المطلوبة. هذا النمط هو الشائع في السحابة.
أنماط الوصول
تحدّد المطالبة كيف يُوصَل إلى التخزين، مثل: القراءة/الكتابة من عقدة واحدة، أو القراءة فقط من عدّة عقد. اختر النمط بحسب حاجة تطبيقك.
الخطوات التالية
يستخدم الـ StatefulSet هذه الأحجام ليمنح كل نسخة تخزينها المستقرّ. راجع طبيعة الـ Pods المؤقّتة التي دفعتنا إلى هذا الحلّ.