التعافي من الكوارث وتعدد المناطق

Kubernetes وGitOps في التعافي من الكوارث

18 دقيقة الدرس 7 من 27

Kubernetes وGitOps في التعافي من الكوارث

عندما تنقطع منطقة بالكامل، السؤال ليس ما إذا كانت كتلتك Kubernetes قادرة على الإصلاح الذاتي — فهذا موجود منذ سنوات. السؤال هو ما إذا كنت قادرًا على إعادة بناء مستوى التحكم بالكامل، مع جميع مشغّليه، وجميع أحمال العمل ذات النطاق، وجميع بياناته ذات الحالة، وجميع سياسات الشبكة في منطقة مختلفة ضمن نافذة RTO الخاصة بك، مع الثقة الكاملة بأن النتيجة مطابقة لما فشل للتو. هذا السؤال يُجاب عليه قبل الحادثة لا أثناءها — من خلال جودة ممارسة GitOps واستراتيجية النسخ الاحتياطي لأحمال العمل ذات الحالة.

GitOps ليس اختياريًا في التعافي من الكوارث — بل هو خطة التعافي لطبقة الكتلة. إذا كان تكوين كتلتك موجودًا فقط في سجل kubectl apply أو في حالة إصدار Helm المحفوظة داخل الكتلة، فلا يمكنك إعادة إنشائها بشكل موثوق في مكان آخر. مستودع Git هو مصدر الحقيقة الوحيد؛ والكتلة هي انعكاس وقت التشغيل لتلك الحقيقة. تعامل مع المستودع كبنية تحتية وليس توثيقًا.

إعادة بناء كتلة من Git

يحتوي مستودع GitOps المنظم جيدًا على كل ما هو مطلوب لتشغيل كتلة من الصفر: بيانات bootstrap الخاصة بـ Flux أو ArgoCD، وإصدارات Helm لمكونات المنصة (cert-manager، external-dns، ingress-nginx، Prometheus stack، Velero)، وتراكبات Kustomize لكل بيئة، وجميع أحمال عمل التطبيقات. إجراء الاسترداد حتمي وقابل للاختبار.

في Google وStripe، مستودع GitOps هو تعريف الكتلة الموثوق. أي انحراف مكتشف بين حالة Git والحالة الحية يُعامَل كحادثة إنتاجية من قبل وحدة التحكم في المطابقة. هذا الانضباط هو ما يجعل التعافي من الكوارث قابلًا للتطبيق: يمكنك توفير كتلة فارغة في منطقة التعافي والسماح لوحدة تحكم GitOps بضبطها على الحالة المطلوبة دون أي خطوات يدوية سوى تشغيل وحدة التحكم نفسها.

# Bootstrap Flux v2 على كتلة DR جديدة من مستودع GitOps موجود
# المتطلبات المسبقة: KUBECONFIG يشير إلى الكتلة الجديدة الفارغة

export GITHUB_TOKEN=ghp_...        # PAT دقيق، قراءة+كتابة المستودع
export GITHUB_USER=my-org
export FLUX_REPO=cluster-gitops

# 1. تثبيت وحدات تحكم Flux
flux bootstrap github \
  --owner=${GITHUB_USER} \
  --repository=${FLUX_REPO} \
  --branch=main \
  --path=clusters/prod-us-east-1 \      # إعادة استخدام نفس المسار أو clusters/dr-us-west-2
  --personal

# ينشئ Flux نطاق flux-system، ويثبت source-controller،
# kustomize-controller، helm-controller، notification-controller،
# ويُلزم بياناتهم مرة أخرى في المستودع. من هذه النقطة،
# سيتم تطبيق كل Kustomization وHelmRelease في ذلك المسار تلقائيًا.

# 2. مراقبة المطابقة — مشاهدة تقارب الكتلة
flux get all -A --watch

# 3. التحقق من kustomizations محددة للأخطاء
flux get kustomizations -A
flux get helmreleases -A

# المتوقع: في غضون 5-10 دقائق تكون جميع إصدارات Helm "Ready True"
# وجميع pods التطبيقات في حالة Running.
# إذا فشل HelmRelease، قم بالتفتيش:
flux logs --kind=HelmRelease --name=my-app --namespace=default

تفصيلان مهمان على نطاق الإنتاج. أولًا، يجب أن يُشفّر مسارك في المستودع هوية الكتلة (clusters/prod-us-east-1) حتى يتفرع نفس المستودع إلى تعريفات متعددة للكتلة دون تعارض. ثانيًا، لا يجب أن تكون الأسرار في Git بنص عادي — استخدم Sealed Secrets أو SOPS مع age/GPG. في سيناريو التعافي، يجب أن يكون مفتاح وحدة التحكم sealed-secrets أو مفتاح SOPS متاحًا في الكتلة الجديدة قبل أن يتمكن Flux من فك تشفير أسرار التطبيق. خزّن ذلك المفتاح في KMS السحابي (AWS KMS، GCP KMS) واجعل عملية التشغيل تسترده عبر دور IAM — وليس في رأس شخص أو جدول بيانات.

اختبر إجراء التشغيل شهريًا في كتلة مؤقتة. kind أو كتلة سحابية حقيقية يوفرها Terraform، يتم تشغيلها بـ Flux، والتحقق من تقاربها، ثم إتلافها. السكريبت الذي يفعل هذا هو دليل التعافي لطبقة الكتلة. إذا استغرق التقارب أكثر من 15 دقيقة، حدد الاختناق — عادةً ما يكون سحب Helm chart بطيئًا أو سحب صورة من سجل يتطلب بيانات اعتماد غير موجودة بعد.

Velero: النسخ الاحتياطي والاستعادة لموارد Kubernetes والأحجام

Velero (المعروف سابقًا بـ Heptio Ark) هو المعيار الفعلي للنسخ الاحتياطي والاستعادة في Kubernetes. يُسلسل كائنات الكتلة — Deployments، Services، ConfigMaps، PVCs، CRDs، RBAC — إلى تخزين الكائنات (S3، GCS، Azure Blob)، ويلتقط اختياريًا لقطات للأحجام الدائمة عبر CSI snapshot hooks أو مكونات إضافية لأحجام الموفر. في الكتل التي تحتوي على مئات من النطاقات، فلاتر الجدول والتضمين/الاستبعاد في Velero هي ما يُبقي حجم النسخ الاحتياطي ووقت الاستعادة قابلًا للإدارة.

# تثبيت Velero مع AWS S3 backend (plugin v1.9+ مع دعم CSI snapshot)
# استبدل الدلو والمنطقة وARN دور IAM لبيئتك

velero install \
  --provider aws \
  --plugins velero/velero-plugin-for-aws:v1.9.0 \
  --bucket my-velero-backups \
  --backup-location-config region=us-east-1 \
  --snapshot-location-config region=us-east-1 \
  --use-node-agent \
  --default-volumes-to-fs-backup \
  --secret-file ./credentials-velero   # بيانات اعتماد AWS لـ Velero SA

# إنشاء جدول نسخ احتياطي لكل شيء (يومي، احتفاظ 30 يومًا)
velero schedule create full-cluster \
  --schedule="0 2 * * *" \
  --ttl 720h \
  --include-namespaces "*"

# جدول لكل نطاق للأحمال الحرجة (كل ساعة، احتفاظ 48 ساعة)
velero schedule create payments-hourly \
  --schedule="0 * * * *" \
  --ttl 48h \
  --include-namespaces payments,fraud-detection

# نسخ احتياطي فوري قبل هجرة محفوفة بالمخاطر
velero backup create pre-migration-$(date +%Y%m%d-%H%M) \
  --include-namespaces payments \
  --wait

# الاستعادة في كتلة جديدة (DR عبر المناطق)
velero restore create --from-backup pre-migration-20250610-1400 \
  --namespace-mappings payments:payments-restored \
  --wait

# التحقق من حالة الاستعادة
velero restore describe pre-migration-20250610-1400-restore-1 --details

في الكتل الإنتاجية الكبيرة في شركات مثل Shopify أو Cloudflare، تعمل نسخ Velero الاحتياطية على نطاقات مجمعة حسب مستوى الأولوية. نطاقات الفئة الأولى (المدفوعات، المصادقة، APIs الأساسية) تأخذ نسخًا احتياطية كل ساعة؛ الفئة الثانية (التحليلات، مهام الدُفعات) تأخذ نسخًا يومية. يُتحقق من SLO الاستعادة ربع سنوي عبر تدريبات استعادة فعلية في كتلة تجهيز — وليس بالاعتماد على وجود ملف النسخ الاحتياطي.

بنية التعافي من الكوارث مع GitOps وVelero: Git يقود تقارب تكوين الكتلة؛ Velero يستعيد البيانات ذات الحالة من S3 عبر المناطق. كلا المسارين يجب أن ينجحا ضمن نافذة RTO.

استعادة الحالة: الجزء الصعب

أحمال العمل عديمة الحالة في Kubernetes قابلة للاسترداد بسهولة عبر GitOps — pod spec وConfigMap وService وHPA: كلها في Git. التحدي يكمن في أحمال العمل ذات الحالة: قواعد البيانات وقوائم انتظار الرسائل وأي حجم يحتوي على بيانات غير مُكررة بالفعل إلى منطقة التعافي بواسطة مستوى البيانات نفسه.

تتبع الصناعة ثلاثة أنماط، واختيارها يعتمد على RPO الخاص بك:

فعّال-سلبي مع نسخ Velero للحجم. يلتقط Velero لقطات PVCs بشكل ساعي إلى S3 مع نسخ عبر المناطق. عند التعطل، يستعيد Velero أحدث لقطة في كتلة التعافي. RPO مرتبط بتكرار اللقطات — عادةً ساعة واحدة. يناسب الأحمال التي ساعة من فقدان البيانات مقبولة فيها (معالجة الدُفعات، التحليلات). وقت الاستعادة لحجم 500 جيجابايت عبر النسخ الاحتياطي على مستوى نظام الملفات (restic/kopia) هو 20-40 دقيقة.
النسخ على مستوى التطبيق مع Velero لاستعادة التكوين فقط. Postgres Logical Replication أو MySQL GTID replication أو Kafka MirrorMaker 2 يحافظ على مزامنة مستمرة للبيانات مع منطقة التعافي. Velero يأخذ نسخًا احتياطية فقط لكائنات Kubernetes (Deployment، Service، Secret، ConfigMap)، وليس الحجم. عند التعطل، استعد كائنات Kubernetes من Velero، ثم ارفع مستوى الاستنساخ الجاهز. RPO يقترب من الصفر؛ وقت الاستعادة بالدقائق. هذا ما تفعله Stripe وما شابهها للبيانات المالية.
HA بإدارة المشغّل (Patroni، Vitess، CockroachDB). يدير مشغّل قاعدة البيانات النسخ والنصاب وانتخاب القائد عبر المناطق بشكل أصلي. لا يلزم نسخ Velero الاحتياطي للحجم — يرفع المشغّل مستوى أقرب استنساخ سليم. Velero لا يزال يأخذ نسخًا للـ CRDs وحالة المشغّل حتى يمكن إعادة إنشاء تكوين المشغّل نفسه في سيناريو التشغيل البارد.

النسخ الاحتياطي على مستوى نظام الملفات في Velero (restic/kopia) لا يضمن الاتساق لقواعد البيانات الجارية. إذا التقطت لقطة لـ PVC خاص بـ Postgres بينما يكتب Postgres، قد تحصل على صفحة ممزقة. للبيانات، استخدم دائمًا خطاف ما قبل النسخ الاحتياطي لتهدئة الكتابات أولًا، أو اعتمد على النسخ على مستوى التطبيق واستخدم Velero فقط لطبقة كائنات Kubernetes. يدعم Velero backup.velero.io/backup-volumes-excludes والخطافات قبل/بعد عبر تعليقات توضيحية للـ pod — استخدمها.

# خطافات Velero قبل/بعد النسخ الاحتياطي لتهدئة Postgres قبل لقطة PVC
# أضف هذه التعليقات التوضيحية إلى قالب pod في Deployment/StatefulSet الخاص بـ Postgres

# تعليق توضيحي للـ Pod لخطاف ما قبل النسخ الاحتياطي (تجميد الكتابات، نقطة تفتيش WAL)
metadata:
  annotations:
    pre.hook.backup.velero.io/command: '["/bin/bash", "-c", "psql -U postgres -c \"CHECKPOINT;\""]'
    pre.hook.backup.velero.io/timeout: "60s"
    post.hook.backup.velero.io/command: '["/bin/bash", "-c", "echo backup done"]'
    post.hook.backup.velero.io/timeout: "30s"
    # استبعاد حجم WAL إذا كنت تستخدم نسخ التدفق (احتفظ فقط بحجم البيانات)
    backup.velero.io/backup-volumes-excludes: pg-wal

---
# لـ StatefulSet يستخدم CSI snapshots (أسرع وأكثر اتساقًا، على مستوى التخزين):
# 1. تفعيل CSI snapshots في كتلتك
kubectl apply -f https://raw.githubusercontent.com/kubernetes-csi/external-snapshotter/v7.0.2/client/config/crd/snapshot.storage.k8s.io_volumesnapshotclasses.yaml
kubectl apply -f https://raw.githubusercontent.com/kubernetes-csi/external-snapshotter/v7.0.2/client/config/crd/snapshot.storage.k8s.io_volumesnapshots.yaml

# 2. إنشاء VolumeSnapshotClass مطابق لمشغّل CSI الخاص بك
apiVersion: snapshot.storage.k8s.io/v1
kind: VolumeSnapshotClass
metadata:
  name: csi-aws-ebs-snapclass
  labels:
    velero.io/csi-volumesnapshot-class: "true"
driver: ebs.csi.aws.com
deletionPolicy: Retain

# 3. سيستخدم Velero تلقائيًا CSI snapshots للـ PVCs التي تستخدم تلك StorageClass
# لقطات CSI ذرية ومتسقة — مفضلة على restic للبيانات

التحقق من جاهزية التعافي

مستودع GitOps وجداول Velero ضرورية لكنها غير كافية. الشيء الوحيد الذي يتحقق من جاهزية التعافي هو استعادة ناجحة. تُجري Netflix تمارين "Chaos Kong" ربع سنوية تُخلي فيها منطقة توافر AWS بأكملها. في Google، تغطي اختبارات DiRT حالات الفشل على مستوى المنطقة الكاملة. لمعظم المؤسسات، تدريب استعادة شهري في كتلة مؤقتة — للتحقق من تقارب جميع Deployments، وإعادة جميع PVCs، واجتياز فحوصات صحة التطبيق — هو الحد الأدنى المقبول. أتمتته بسكريبت يُشغّل velero restore create، ويستطلع حتى الاكتمال، ويُشغّل اختبارات دخان، ثم يتلف الكتلة. خزّن النجاح/الفشل في نظام إدارة الحوادث كدليل على جاهزية التعافي.

وقت تقارب GitOps هو مساهمتك في RTO على مستوى طبقة الكتلة. قِسه. بعد تشغيل Flux على كتلة فارغة، شغّل flux get all -A ولاحظ متى ينتقل آخر HelmRelease إلى Ready=True. إذا تجاوز ذلك الوقت 15 دقيقة، فمخططات Helm الخاصة بمنصتك ثقيلة جدًا أو سحب الصورة بطيء جدًا. اسحب الصور الحرجة مسبقًا إلى ذاكرة تخزين مؤقت إقليمية في ECR/Artifact Registry — تحافظ كثير من الفرق على "كتلة DR دافئة" في مجموعة عقدة في وضع السبات لإزالة عقوبة التشغيل البارد كليًا.