دورة حياة الوحدة وحالاتها

لا تبقى Pods ثابتة؛ بل تمر بمراحل مختلفة، أشبه برحلة. ويُعد فهم «دورة الحياة» هذه أساسيًا لإدارة تطبيقاتكم بفاعلية في Kubernetes.

فهو يساعدكم على معرفة ما إذا كان تطبيقكم سليمًا أو قيد البدء أو قد واجه مشكلة.

يصنّف Kubernetes Pods إلى خمس مراحل رئيسية. وتمنحنا هذه المراحل نظرة عامة عالية المستوى على الحالة الحالية لـ Pod:

• Pending: قبل Kubernetes الـ Pod، لكن حاوياتها لم تبدأ بعد.
• Running: حاوية واحدة على الأقل في Pod قيد التشغيل أو في طور البدء.
• Succeeded: أكملت جميع الحاويات في Pod عملها بنجاح، ولن يعاد تشغيلها.
• Failed: توقفت جميع الحاويات، وفشلت واحدة منها على الأقل (مثلًا، خرجت برمز غير صفري).
• Unknown: تعذر تحديد حالة Pod، وغالبًا ما يكون ذلك بسبب مشكلات في الاتصال.

تكون Pod في مرحلة Pending عندما يقبلها خادم Kubernetes API، لكن لم تُنشأ حاوية واحدة أو أكثر منها أو لم تُهيّأ بعد.

تشمل الأسباب الشائعة ما يلي:

• لا تزال صورة الحاوية قيد التنزيل.
• لا يملك العنقود موارد كافية (CPU/الذاكرة) لجدولة Pod.
• لا تزال وحدات التخزين قيد التجهيز أو التركيب.

لنلقِ نظرة على مثال. إذا حاولتم نشر Pod باستخدام صورة غير موجودة، فقد تظل عالقة في حالة 'Pending' أو تعرض خطأ في سحب الصورة.

إليكم تعريفًا نموذجيًا لـ Pod:

apiVersion: v1
kind: Pod
metadata:
  name: pending-pod-demo
spec:
  containers:
  - name: my-container
    image: non-existent-image:latest
    ports:
    - containerPort: 80

للتحقق من حالتها، ستستخدمون kubectl get pod. وقد تظهر لكم نتيجة مشابهة لما يلي:

$ kubectl get pod pending-pod-demo
NAME               READY   STATUS         RESTARTS   AGE
pending-pod-demo   0/1     ErrImagePull   0          5s

يشير ErrImagePull إلى تعذر جلب الصورة، ما يؤدي إلى عدم وصول Pod إلى حالة Running.

تعني مرحلة Running أن الـ Pod قد ارتبط بعقدة، وأن جميع الحاويات الخاصة به قد أُنشئت بنجاح. تكون حاوية واحدة على الأقل قيد التشغيل، أو في طور البدء أو إعادة التشغيل.

من المهم ملاحظة أن وجود Pod في حالة Running لا يعني تلقائيًا أن التطبيق الموجود داخله سليم أو يعمل بكامل وظائفه؛ فهذا يعني فقط أن الحاويات نشطة.

إليك تعريفًا قياسيًا لـ Pod يشغّل خادم الويب Nginx. بعد تطبيق هذا التعريف، من المفترض أن ينتقل الـ Pod سريعًا إلى حالة 'Running'.

apiVersion: v1
kind: Pod
metadata:
  name: nginx-pod
spec:
  containers:
  - name: nginx
    image: nginx:latest
    ports:
    - containerPort: 80

بعد النشر، سيعرض الأمر kubectl get pod ما يلي:

$ kubectl get pod nginx-pod
NAME        READY   STATUS    RESTARTS   AGE
nginx-pod   1/1     Running   0          10s

تؤكد القيمة 1/1 في READY أن حاوية واحدة جاهزة من أصل حاوية واحدة معرّفة.

تمثل هاتان المرحلتان حالات إنهاء الـ Pod:

• Succeeded: يدخل الـ Pod هذه المرحلة عندما تنتهي جميع الحاويات الموجودة فيه بنجاح، ولا يُعاد تشغيلها. ويشيع ذلك في الـ Pods التي تنفذ مهام لمرة واحدة أو مهام دفعية.
• Failed: يكون الـ Pod في مرحلة Failed عندما تنتهي جميع الحاويات الموجودة فيه، وتكون حاوية واحدة على الأقل قد انتهت بفشل، مثل الخروج برمز حالة غير صفري.

يساعدكم فهم هذه الحالات على تشخيص اكتمال المهام أو أخطاء التطبيق.

تعني مرحلة Unknown تعذّر تحديد حالة الـ Pod. وهذه مرحلة نادرة، لكنها بالغة الأهمية.

تحدث عادةً عندما يتوقف Kubelet، أي الوكيل الموجود على العقدة التي يعمل عليها الـ Pod، عن التواصل مع خادم Kubernetes API. وقد يرجع ذلك إلى مشكلة في الشبكة، أو تعطل Kubelet، أو مشكلة في العقدة نفسها.

رغم أن للـ Pods مراحل عامة، فإن للحاويات الفردية داخل الـ Pod حالات أكثر تفصيلًا أيضًا. وتؤثر هذه الحالات مباشرةً في مرحلة الـ Pod العامة:

• Waiting: تنتظر الحاوية حاليًا بدء تشغيلها. ومن أسباب ذلك سحب الصورة، أو تخصيص الموارد، أو انتظار اكتمال حاويات التهيئة.
• Running: تنفذ الحاوية عملها بنشاط ومن دون مشكلات.
• Terminated: أكملت الحاوية تنفيذها، وقد تكون قد نجحت أو فشلت.

تخيلوا أنكم نشرتم Pod جديدًا للتو. شغّلتم kubectl get pod my-app وظهر لكم الناتج التالي:

NAME      READY   STATUS     RESTARTS   AGE
my-app    0/1     Pending    0          12s

ما السبب الأكثر احتمالًا لبقاء Pod‏ my-app في حالة Pending مع وجود 0/1 من الحاويات الجاهزة؟

لقد تعلمتم أن Pods في Kubernetes تمر بمراحل محددة: Pending وRunning وSucceeded وFailed وUnknown. وتوفر هذه المراحل معلومات عالية المستوى عن الحالة التشغيلية للـ Pod.

كما تعرفتم على حالات الحاويات الفردية، وهي Waiting وRunning وTerminated، والتي تسهم في تحديد مرحلة الـ Pod العامة. وتُعد مراقبة هذه الحالات باستخدام kubectl get pod وkubectl describe pod، اللذين ستتعرفون إليهما بمزيد من التفصيل لاحقًا، أمرًا ضروريًا لفهم سلامة تطبيقكم.

بعد ذلك، سنتناول أنماط Pods المتقدمة، ونستكشف كيفية تشغيل حاويات متعددة متجاورة داخل Pod واحد باستخدام نمط sidecar!