Velero للمحترف: Backup كامل لـ Kubernetes Cluster واسترجاع في 18 دقيقة
مستوى القارئ: محترف (Professional) — يفترض إنك مرتاح مع Kubernetes CRDs، IAM/IRSA، وعندك خبرة سابقة مع snapshot drivers على EBS أو GCE PD.
لو الـ cluster الإنتاجي بتاعك انهار دلوقتي بسبب terraform apply غلط على VPC، إيه الـ RTO الحقيقي اللي هتقدر تضمنه للإدارة؟ الإجابة الصادقة لمعظم الفرق العربية: مش عارف. Velero v1.14 بيخلّي الإجابة دي رقم محدد: 18 دقيقة لاسترجاع cluster فيه 96 microservice و 240GB Persistent Volumes، بدون الحاجة لـ disaster-recovery team متخصص.
المشكلة باختصار
etcd snapshot لوحده مش backup. لو فقدت الـ cluster بالكامل، الـ snapshot ده محتاج cluster جديد بنفس الإصدار وبنفس CNI وبنفس الـ storage class — وحتى لو نجحت في كل ده، الـ Persistent Volumes نفسها مش في الـ snapshot. بياناتك الفعلية على EBS volumes منفصلة، ولو حد عمل terraform destroy غلط على الـ VPC، الـ volumes دي مش بترجع.
الفرق اللي بتعتمد على kubectl apply -f من Git repo بتفترض إن الـ Git هو الـ source of truth. ده صحيح لـ manifests، بس مش صحيح لـ Secrets المنشأة بواسطة External Secrets Operator، ولا cert-manager certificates، ولا Persistent Volume Claims اللي اتعملت بواسطة Helm charts بـ generated names.
المفهوم بمثال بسيط (للمراجعة السريعة)
تخيّل إن عندك بنك سبائك ذهب. لو بقالك سجل ورقي بأسماء العملاء بس (manifests في Git)، ومحدش حافظ على السبائك نفسها (Persistent Volumes)، يبقى السجل ده لا قيمة له بعد السرقة. Velero بيعمل حاجتين في وقت واحد: بياخد نسخة من السجل الورقي (Kubernetes objects كـ JSON في S3)، وفي نفس اللحظة بيعمل volume snapshots على مستوى الـ cloud provider للسبائك نفسها. لمّا تيجي ترجّع، Velero بيقرأ السجل ويعيد بناء الـ vault كاملاً، وفي نفس الوقت يربط الـ snapshots كـ volumes جديدة على الكلاستر الجديد. النتيجة: cluster مماثل بنفس البيانات بالظبط.
الشرح العلمي: إزاي Velero بيشتغل تحت الغطا
Velero بيتركّب كـ Deployment داخل namespace اسمه velero، وبيستخدم Custom Resource Definitions زي Backup, Restore, Schedule, BackupStorageLocation, VolumeSnapshotLocation. لمّا تعمل velero backup create، الـ controller بيمرّ على كل الـ API resources في الكلاستر، بيـ serialize كل object كـ JSON، ويـ tar/gzip النتيجة، ويرفعها لـ object storage محدد (S3, GCS, Azure Blob). متوازياً مع ده، بيستدعي CSI VolumeSnapshot API لكل PVC بيطابق الفلتر — وده بياخد snapshot على مستوى الـ cloud (EBS snapshot أو GCE PD snapshot)، اللي بيتسجّل كـ reference جوّا الـ backup metadata.
الـ restore بيشتغل عكس ده تماماً: بيقرأ الـ tarball من S3، يبني Kubernetes objects من JSON عبر apply server-side، ولكل PVC هو محتاج يـ restore، بيخلق VolumeSnapshotContent جديد من snapshot reference القديم، اللي بيوفّر للـ CSI driver بيانات كافية يربط volume جديد بنفس الـ data بدون نسخ فعلي. ده اللي بيخلّي الـ restore سريع رغم حجم البيانات: snapshots على EBS مش بتنسخ بايتس، بتنسخ pointers.
