تنسيق Kubernetes

مقدمة

Docker يحل مشكلة "التعبئة"، Kubernetes يحل مشكلة "الإدارة". عندما يكون لديك عشرات أو مئات الحاويات التي تحتاج إلى نشر وتوسيع وتقليص واستعادة من الأعطال، فإن الإدارة اليدوية غير واقعية. Kubernetes (K8s) هو "نظام التشغيل" للحاويات، يقوم بأتمتة نشر وتوسيع وتشغيل التطبيقات المعبأة في حاويات.

ماذا ستتعلم في هذا المقال؟

بعد إكمال هذا الفصل، ستكتسب:

• فهم البنية: إتقان مكونات مستوى التحكم وعقد العمل في K8s
• الموارد الأساسية: الإلمام بالمفاهيم الأساسية مثل Pod و Deployment و Service
• الإدارة التصريحية: فهم فكرة "إعلان الحالة المرغوبة، والنظام يتقارب تلقائيًا"
• قدرات التشغيل: فهم آليات التحديث المتدرج والتوسع التلقائي والفحص الصحي
• مقدمة عملية: القدرة على نشر تطبيق كامل باستخدام kubectl و YAML

الفصل	المحتوى	المفاهيم الأساسية
الفصل 1	لماذا نحتاج K8s	تحديات تنسيق الحاويات
الفصل 2	بنية K8s	مستوى التحكم، عقد العمل، etcd
الفصل 3	الموارد الأساسية	Pod، Deployment، Service، Ingress
الفصل 4	الإدارة التصريحية	YAML، kubectl، حلقة التحكم
الفصل 5	ممارسات التشغيل	التحديث المتدرج، HPA، الفحص الصحي

---

1. لماذا نحتاج Kubernetes؟

Docker يجعل تعبئة وتشغيل الحاوية الواحدة أمرًا بسيطًا، لكن عندما تواجه السيناريوهات التالية، تصبح الإدارة اليدوية غير كافية:

التحدي	الوصف	حل K8s
نشر متعدد النسخ	خدمة تحتاج إلى تشغيل 10 نسخ	Deployment يدير عدد النسخ تلقائيًا
استعادة الأعطال	حاوية تتعطل وتحتاج إعادة تشغيل تلقائي	المتحكم يكتشف تلقائيًا ويعيد بناء Pod
اكتشاف الخدمة	عنوان IP للحاوية يتغير، كيف نجد بعضنا؟	Service توفر DNS و IP مستقرين
التحديث المتدرج	تحديث الإصدار دون توقف الخدمة	استبدال تدريجي للـ Pod القديمة، دون توقف
التوسع المرن	توسيع تلقائي عند ذروة المرور	HPA يضبط عدد النسخ تلقائيًا حسب CPU/الذاكرة
جدولة الموارد	وضع الحاويات على أنسب الآلات	Scheduler يقوم بجدولة ذكية

الفكرة الأساسية لـ K8s: التصريحية

لست بحاجة لإخبار K8s "شغّل 3 حاويات" (أمرية)، بل تخبرها "أريد 3 نسخ قيد التشغيل" (تصريحية). K8s تراقب باستمرار، وتضمن أن الحالة الفعلية تتطابق مع الحالة المرغوبة التي أعلنتها. إذا تعطل Pod، ستقوم تلقائيًا بإنشاء واحد جديد لتعويضه.

---

2. بنية Kubernetes

تتكون مجموعة K8s من مستوى التحكم (Control Plane) وعقد العمل (Worker Node).

Kubernetes Architecture

Click a component to inspect the details

Control Plane

API Server

etcd

Scheduler

Controller Manager

Worker Node x N

kubelet

kube-proxy

Container runtime

API Server

The front door of Kubernetes. All operations from kubectl, dashboards, and internal components go through the API Server. It handles authentication, authorization, admission control, and acts as the single entry point for the cluster.

Analogy:A company reception desk where every visitor and delivery is checked in

المسار الكامل للطلب

طلب المستخدم → Ingress Controller → Service → kube-proxy → Pod (حاوية)
                                              ↑
                                    قائمة Endpoint (يديرها Service)

---

3. كائنات الموارد الأساسية

K8s تصف الحالة المرغوبة للمجموعة من خلال "كائنات موارد" متنوعة.

K8s Core Resources

Click a resource type to inspect the explanation and YAML example

Pod

Smallest scheduling unit

A Pod is the smallest deployable unit in K8s. It contains one or more tightly related containers. Containers inside the same Pod share networking and storage, so they can communicate through localhost.

YAML example

apiVersion: v1
kind: Pod
metadata:
  name: my-app
spec:
  containers:
    - name: app
      image: my-app:1.0
      ports:
        - containerPort: 3000

Tip:Production workloads rarely create Pods directly; they are usually managed by Deployments.

تصنيف كائنات الموارد

الفئة	المورد	الاستخدام
أعباء العمل	Pod، Deployment، StatefulSet، DaemonSet، Job	تشغيل التطبيقات
الشبكة	Service، Ingress، NetworkPolicy	اكتشاف الخدمة وإدارة المرور
التكوين	ConfigMap، Secret	إدارة التكوين والبيانات الحساسة
التخزين	PersistentVolume، PersistentVolumeClaim	التخزين الدائم
الجدولة	Node، Namespace، ResourceQuota	عزل الموارد وتقييدها

---

4. الإدارة التصريحية و kubectl

حلقة التحكم (Reconciliation Loop)

آلية العمل الأساسية لـ K8s هي حلقة التحكم:

مراقبة (Observe) → مقارنة (Diff) → إجراء (Act) → مراقبة...
     ↓                ↓              ↓
  قراءة الحالة    المقارنة مع     تنفيذ الإجراء
  الفعلية         الحالة المرغوبة    التصحيحي

تعلن replicas: 3، يكتشف المتحكم أن هناك Pod واحدة فقط قيد التشغيل، فيقوم بإنشاء واحدة جديدة. تتكرر هذه الحلقة كل بضع ثوانٍ، لضمان تقارب النظام دائمًا نحو الحالة المرغوبة.

أوامر kubectl الشائعة

الأمر	الوظيفة	مثال
kubectl apply -f	تطبيق تكوين YAML	kubectl apply -f deployment.yaml
kubectl get	عرض قائمة الموارد	kubectl get pods -o wide
kubectl describe	عرض تفاصيل المورد	kubectl describe pod my-app-xxx
kubectl logs	عرض سجلات Pod	kubectl logs -f my-app-xxx
kubectl exec	الدخول إلى طرفية Pod	kubectl exec -it my-app-xxx -- sh
kubectl delete	حذف مورد	kubectl delete -f deployment.yaml
kubectl scale	توسيع/تقليص يدوي	kubectl scale deploy my-app --replicas=5

apply مقابل create

kubectl create أمري - "أنشئ هذا المورد"، إذا كان موجودًا مسبقًا سيُبلغ عن خطأ. kubectl apply تصريحي - "تأكد أن المورد بهذه الحالة"، إذا لم يكن موجودًا ينشئه، وإذا كان موجودًا يحدثه. في بيئة الإنتاج يجب دائمًا استخدام apply.

---

5. ممارسات التشغيل

5.1 التحديث المتدرج والتراجع

Deployment يستخدم استراتيجية التحديث المتدرج افتراضيًا: إنشاء Pod جديدة تدريجيًا، وإنهاء Pod القديمة تدريجيًا في نفس الوقت.

spec:
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1        # الحد الأقصى لإنشاء Pod إضافية واحدة
      maxUnavailable: 0   # عدم السماح بعدم توفر أي Pod

العملية	الأمر
تحديث الصورة	kubectl set image deploy/my-app app=my-app:2.0
عرض حالة التحديث	kubectl rollout status deploy/my-app
عرض سجل الإصدارات	kubectl rollout history deploy/my-app
التراجع للإصدار السابق	kubectl rollout undo deploy/my-app

5.2 التوسع التلقائي (HPA)

HPA (Horizontal Pod Autoscaler) يضبط عدد نسخ Pod تلقائيًا بناءً على CPU أو الذاكرة أو مؤشرات مخصصة.

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: my-app-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: my-app
  minReplicas: 2
  maxReplicas: 10
  metrics:
    - type: Resource
      resource:
        name: cpu
        target:
          type: Utilization
          averageUtilization: 70

5.3 الفحص الصحي (Probe)

K8s تراقب الحالة الصحية للـ Pod من خلال ثلاثة أنواع من المجسات:

المجس	الوظيفة	نتيجة الفشل
livenessProbe	الكشف عن ما إذا كانت الحاوية حية	إعادة تشغيل الحاوية
readinessProbe	الكشف عن ما إذا كانت الحاوية جاهزة	إزالتها من Service، لا تستقبل حركة مرور
startupProbe	الكشف عن اكتمال بدء تشغيل الحاوية	عدم تنفيذ المجسات الأخرى خلال فترة البدء

أهمية المجسات

بدون تكوين الفحص الصحي، يمكن لـ K8s فقط الحكم على الحالة الصحية من خلال وجود العملية. لكن في كثير من الأحيان تكون العملية موجودة لكن الخدمة لا تستجيب (مثل الجمود، حافة OOM). تكوين livenessProbe يسمح لـ K8s بإعادة تشغيل هذه الحاويات "الميتة ظاهريًا" تلقائيًا.

---

الخلاصة

Kubernetes هو المعيار الفعلي لتنسيق الحاويات، وفهم مفاهيمه الأساسية هو أساس تطوير السحابة الأصلية.

مراجعة النقاط الرئيسية لهذا الفصل:

1. الإدارة التصريحية: أخبر K8s "ماذا أريد"، وليس "كيف أفعل"، حلقة التحكم تتقارب تلقائيًا
2. طبقات البنية: مستوى التحكم مسؤول عن القرارات، عقد العمل مسؤولة عن التنفيذ، etcd يخزن الحالة
3. الموارد الأساسية: Pod (أصغر وحدة)، Deployment (إدارة النسخ)، Service (اكتشاف الخدمة)، Ingress (مدخل خارجي)
4. أتمتة التشغيل: تحديث متدرج دون توقف، HPA توسع مرن، مجسات استعادة تلقائية من الأعطال
5. فصل التكوين: ConfigMap و Secret يفصلان التكوين عن الصورة

قراءة إضافية

• توثيق Kubernetes الرسمي - المرجع الصيني الأكثر موثوقية
• Kubernetes the Hard Way - بناء مجموعة K8s يدويًا من الصفر
• The Illustrated Children's Guide to Kubernetes - مقدمة ممتعة من CNCF
• Kubernetes Patterns - أنماط تصميم K8s