الدرس 13: التخزين والتغليف — PVC و Helm و GitOps
حتى الآن كانت الـ Pods لدينا «قابلة للتخلص منها»: عند حذفها أو إعادة تشغيلها، تختفي أي ملفات كُتبت بداخلها. هذا مقبول لتطبيق لا يخزّن شيئًا، لكنه مشكلة لقاعدة بيانات. في هذا الدرس نتعرّف على ثلاث أدوات تكمّل الصورة. أولًا — PersistentVolumeClaim (اختصارًا PVC): طلب لتخزين دائم «يبقى بعد» الـ Pod، تم
الـ Pod مثل لوح أبيض يُمحى بالكامل في كل مرة يُطفأ فيها؛ أما الـ PVC فهو محرك USB يظل ممتلئًا. Helm صندوق أثاث للتركيب الذاتي، و GitOps يقول: «ما هو مكتوب في الدفتر — هذه هي الحقيقة».
- PersistentVolumeClaim
- كائن يطلب تخزينًا دائمًا بحجم معيّن. يتصل به الـ Pod، وتبقى البيانات حتى بعد حذف الـ Pod أو إعادة تشغيله — مثل قرص صلب خارجي.
- Helm
- مدير حزم Kubernetes. يحزم مجموعة من ملفات YAML في قالب واحد («chart») مع ملف قيم (values) يمكنك ضبطه، بحيث تثبّت الحزمة نفسها التطبيق عبر عدة بيئات.
- GitOps
- أسلوب عمل يكون فيه مستودع Git هو مصدر الحقيقة الوحيد لحالة الـ cluster. يقارن متحكّم (مثل ArgoCD أو Flux) الـ cluster بالمستودع باستمرار ويوائمه ليطابقه تلقائيًا.
- وضع الوصول
- إعداد في الـ PVC يحدّد كيف يمكن ربط وحدة التخزين. تعني ReadWriteOnce أن node واحدًا فقط يمكنه الكتابة إليها في كل مرة — الوضع الأكثر شيوعًا لقرص تطبيق واحد.
- قيم الـ chart
- ملف (values.yaml) يوفّر القيم المتغيّرة إلى Helm chart — مثل اسم الـ image أو عدد الـ replicas أو حجم التخزين — بحيث يُخصَّص القالب نفسه لكل بيئة دون تكرار YAML.
