عمليات Kubernetes المتقدمة

عمليات etcd ومستوى التحكم

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

عمليات etcd ومستوى التحكم

يُعدّ etcd المصدر الوحيد للحقيقة في أي كلاستر Kubernetes. كل كائن تُنشئه — Pod أو Deployment أو Secret أو ConfigMap — يُخزَّن كإدخال مفتاح/قيمة في etcd قبل أن يتصرف أي مكوّن آخر. إذا أصبح etcd غير صحي، يتوقف مستوى التحكم بأكمله: يرفض API server الكتابة، ولا يستطيع المجدوِل وضع البودات، ولا يستطيع controller manager المزامنة مع الحالة المطلوبة. فهم كيفية مراقبة etcd ونسخه احتياطيًا واستعادته — وكيفية تهيئة API server للتواصل معه — هو ما يُميّز المهندسين الذين يُشغّلون Kubernetes فعليًا في الإنتاج.

كيف يندمج etcd في مستوى التحكم

يتكوّن مستوى التحكم في Kubernetes من أربعة مكونات رئيسية: kube-apiserver وkube-controller-manager وkube-scheduler وetcd. فقط API server يتواصل مباشرةً مع etcd — أما بقية المكونات فتتواصل عبر API server. هذه نقطة تصميمية جوهرية: لا تستعلم etcd مباشرةً للحصول على بيانات تشغيلية؛ استخدم kubectl أو Kubernetes API بدلًا من ذلك.

API server هو العميل الوحيد لـ etcd. جميع مكونات مستوى التحكم الأخرى والعملاء الخارجيون يمرّون عبر API server.

مراقبة صحة etcd

أداة etcdctl هي الأداة المعيارية للاستعلام عن صحة etcd. يجب تحديد نقاط النهاية الصحيحة ومسارات شهادات TLS — تُوجد هذه في ملف manifest الخاص بـ etcd (/etc/kubernetes/manifests/etcd.yaml في كلاسترات kubeadm) أو كمتغيرات بيئة داخل حاوية etcd.

# تصدير متغيرات etcdctl لكلاستر kubeadm
export ETCDCTL_API=3
export ETCDCTL_ENDPOINTS=https://127.0.0.1:2379
export ETCDCTL_CACERT=/etc/kubernetes/pki/etcd/ca.crt
export ETCDCTL_CERT=/etc/kubernetes/pki/etcd/server.crt
export ETCDCTL_KEY=/etc/kubernetes/pki/etcd/server.key

# فحص الصحة الكلية للكلاستر
etcdctl endpoint health --cluster

# فحص حالة كل عضو (يُظهر القائد، raft term، حجم DB)
etcdctl endpoint status --cluster -w table

# قائمة الأعضاء
etcdctl member list -w table

# مراقبة نشاط المفاتيح في الوقت الفعلي (مفيد أثناء التحقيق في الحوادث)
etcdctl watch --prefix /registry/pods/default

يُظهر خرج endpoint status حقلَي حجم DB مهمَّين: DB SIZE (البايتات المخزّنة حاليًا) وDB SIZE IN USE. الفجوة الكبيرة بينهما تدلّ على مراجعات MVCC متراكمة لم تُضغَط بعد — وهو مصدر شائع لبطء الكتابة ونفاد مساحة القرص.

نفّذ الضغط وإلغاء التجزئة بانتظام. لا يضغط Kubernetes etcd تلقائيًا بشكل افتراضي (ما لم يكن --auto-compaction-mode مضبوطًا على etcd). في الإنتاج، اضغط كل ساعة، ونفّذ defrag أسبوعيًا خلال نافذة منخفضة الحركة. الأمر etcdctl defrag ضروري لاسترداد مساحة القرص حتى مع تفعيل الضغط التلقائي.

# الضغط إلى المراجعة الحالية (استرداد تاريخ MVCC)
REV=$(etcdctl endpoint status --cluster -w json \
  | python3 -c "import sys,json; d=json.load(sys.stdin); print(max(s['Status']['header']['revision'] for s in d))")
etcdctl compact $REV

# إلغاء التجزئة (عضو واحد في كل مرة — يسبب توقفًا مؤقتًا لكل عضو)
etcdctl defrag --cluster
# أو استهداف نقطة نهاية واحدة لتفادي الضغط على القائد تحت الحمل:
etcdctl defrag --endpoints=https://192.168.1.11:2379

نسخ etcd الاحتياطي — المهمة التشغيلية الأكثر أهمية

اللقطة (Snapshot) هي نسخة احتياطية لقاعدة بيانات etcd كاملة في لحظة محددة. بدون لقطة حديثة، يعني فقدان بيانات etcd الكامل عدم إمكانية استرداد الكلاستر دون إعادة نشر كل شيء من الصفر. يجب أن تمتلك جميع الكلاسترات الإنتاجية لقطات تلقائية.

خذ اللقطة من عضو غير قائد إن أمكن. أخذ لقطة من القائد تحت حمل كتابة عالٍ قد يسبب ارتفاعًا مؤقتًا في الزمن الاستجابي لطلبات API server. يُفضَّل توجيه etcdctl snapshot save نحو نقطة نهاية أحد الأعضاء التابعين. تبقى اللقطة متسقة تمامًا — etcd يُزامن القراءات عبر الكلاستر قبل تقديمها.

# حفظ لقطة في ملف محلي
etcdctl snapshot save /backup/etcd/etcd-snapshot-$(date +%Y%m%dT%H%M%S).db

# التحقق من اللقطة (يطبع الهاش، المراجعة، إجمالي المفاتيح)
etcdctl snapshot status /backup/etcd/etcd-snapshot-2025-06-11T020000.db -w table

# --- الاستعادة من لقطة (نفّذ على كل عقدة control-plane بشكل منفصل) ---
# أوقف API server و controller-manager أولًا (أزل manifests أو أوقف kubelet)
mv /etc/kubernetes/manifests/kube-apiserver.yaml /tmp/
mv /etc/kubernetes/manifests/kube-controller-manager.yaml /tmp/

etcdctl snapshot restore /backup/etcd/etcd-snapshot-2025-06-11T020000.db \
  --name etcd-0 \
  --initial-cluster "etcd-0=https://192.168.1.10:2380,etcd-1=https://192.168.1.11:2380,etcd-2=https://192.168.1.12:2380" \
  --initial-cluster-token etcd-cluster-prod \
  --initial-advertise-peer-urls https://192.168.1.10:2380 \
  --data-dir /var/lib/etcd-restored

# أشر manifest etcd نحو مجلد البيانات الجديد، ثم أعد manifests مستوى التحكم
sed -i 's|/var/lib/etcd|/var/lib/etcd-restored|g' /etc/kubernetes/manifests/etcd.yaml
mv /tmp/kube-apiserver.yaml /etc/kubernetes/manifests/
mv /tmp/kube-controller-manager.yaml /etc/kubernetes/manifests/

تلقائيًا باستخدام CronJob داخل الكلاستر (للكلاسترات المُدارة) أو سكريبت cron على مضيف control-plane (للكلاسترات المُدارة ذاتيًا). خزّن اللقطات في مخزن كائنات (S3 أو GCS) مع تفعيل الإصدار وسياسة احتفاظ لمدة 30 يومًا. لا تخزّن النسخ الاحتياطية فقط على المضيف نفسه الذي يشغّل etcd.

الأعلام الرئيسية لـ API Server

تتحكم أعلام بدء تشغيل API server في الأمان والأداء والاتصال بـ etcd. في كلاسترات kubeadm توجد في /etc/kubernetes/manifests/kube-apiserver.yaml. في الكلاسترات المُدارة (EKS, GKE) يُدير المزوّد هذه الأعلام ويعرض فقط مجموعة منها للتخصيص.

--etcd-servers — قائمة نقاط نهاية etcd مفصولة بفاصلة. أبقِ الأعضاء الثلاثة مدرجين حتى يتمكن API server من إعادة الاتصال عند انتخاب قائد جديد.
--etcd-cafile و--etcd-certfile و--etcd-keyfile — شهادات TLS لهوية API server تجاه etcd. جدّدها قبل انتهاء صلاحيتها.
--etcd-compaction-interval — كم مرة يُشغّل API server الضغط (الافتراضي 5 دقائق). أبقِه مفعّلًا.
--request-timeout — مهلة الطلبات العامة لغير عمليات المراقبة (الافتراضي 96 ثانية). قد تحتاج لزيادته لطلبات LIST الكبيرة في كلاسترات ضخمة.
--max-requests-inflight / --max-mutating-requests-inflight — تحديد التزامن لحماية etcd. القيم الافتراضية (400 / 200) مناسبة لكلاسترات أقل من ~1000 عقدة؛ وسّعها تناسبيًا فوق ذلك.
--audit-log-path / --audit-policy-file — تسجيل التدقيق المهيكل؛ مطلوب لامتثال SOC 2 / PCI. سجّل في ملف وشحنه بـ Fluentd أو sidecar.
--feature-gates — تفعيل ميزات alpha/beta. عامِلها كميزات غير مستقرة؛ لا تُفعّلها في الإنتاج قبل اختبارها في staging دورة إصدار كاملة.

الكلاسترات المُدارة مقابل المُدارة ذاتيًا. في EKS وGKE وAKS، تُشغّل AWS/Google/Azure كلًا من API server وetcd — لا يوجد لديك وصول SSH إلى عقد مستوى التحكم ولا يمكنك تحرير manifests مباشرةً. يتولى المزوّد HA والنسخ الاحتياطية والتصحيحات. في الكلاسترات المُدارة ذاتيًا (kubeadm، Talos، RKE2) أنت مسؤول عن كل علم وكل نسخة احتياطية. هذا فرق تشغيلي جوهري: تُقايض الكلاسترات المُدارة التحكم مقابل البساطة التشغيلية، بينما تمنح الكلاسترات المُدارة ذاتيًا القدرة الكاملة بتكلفة المسؤولية الكاملة.

طوبولوجيا etcd في الإنتاج

يجب أن يحتوي كلاستر etcd الإنتاجي دائمًا على عدد فردي من الأعضاء — 3 لمعظم الكلاسترات، 5 للكلاسترات الكبيرة جدًا أو عالية الحركة. يتحمّل الكلاستر المكوّن من 3 أعضاء فشل عضو واحد؛ أما المكوّن من 5 أعضاء فيتحمّل فشل اثنين. الانتقال إلى 7 أعضاء لا يوفر فائدة عملية ويزيد زمن الاستجابة للكتابة لأن القائد يجب أن ينتظر إقرار الأغلبية.

ضع أعضاء etcd على عقد مخصصة مزوّدة بـ أقراص NVMe SSD سريعة — etcd شديد الحساسية لزمن الاستجابة في كتابة القرص. وقت fsync عند النسبة المئوية التاسعة والتسعين يزيد عن 10 مللي ثانية سيُسبّب انتخابات القائد، وفوق 100 مللي ثانية سيُسبّب أخطاء واسعة في API server. راقب مقياس Prometheus etcd_disk_wal_fsync_duration_seconds وأنشئ تنبيهًا عند تجاوز النسبة المئوية التاسعة والتسعين لـ 10 مللي ثانية.

افصل قرص etcd عن قرص نظام التشغيل. عملية صاخبة تملأ قرص نظام التشغيل ستُجوّع كتابات WAL لـ etcd وتُطلق انتخابات. في الأجهزة الافتراضية السحابية، أرفق مجلدًا EBS مخصصًا من نوع gp3 (3000 IOPS على الأقل كخط أساس، مع burst حتى 16000 IOPS) مُركَّبًا على /var/lib/etcd. على الخوادم المادية استخدم قسم NVMe مخصص.