الدرس 8: Service — شبكة مستقرة لـ Pods
تعلّمنا حتى الآن أن Kubernetes يُبقي عدة نسخ (Pods) من تطبيقك حيّة ويعيد إنشاءها عند فشلها. لكن هناك مشكلة خفية: كل Pod له عنوان شبكة خاص به (IP)، وهذا العنوان مؤقت — فهو يتغيّر كلما مات Pod أو أُعيد إنشاؤه أو انتقل إلى node آخر. إذا تحدّث أحد المكوّنات مباشرةً إلى IP الخاص بـ Pod، فبمجرد استبدال ذل
الـ Service مثل رقم هاتف مكتب الاستقبال في شركة. الموظفون يتغيّرون باستمرار، لكن من يتّصل يطلب دائمًا الرقم نفسه — وتصل المكالمة إلى أي شخص متاح.
- Service
- كائن في Kubernetes يمنح مجموعة من الـ Pods اسمًا وعنوان شبكة ثابتَين، ويوزّع الطلبات عليها (load-balancing). يبقى العنوان ثابتًا حتى عندما تتغيّر الـ Pods.
- ClusterIP
- نوع الـ Service الافتراضي: عنوان افتراضي داخلي يمكن الوصول إليه فقط من داخل الـ cluster، بحيث تستطيع المكوّنات الداخلية الوصول إليه لكن العالم الخارجي لا يستطيع.
- الـ selector والتسميات (labels)
- التسمية (label) هي وسم من نوع مفتاح-قيمة يُلصق بـ Pod (على سبيل المثال app: web). يحدّد الـ selector في الـ Service أي التسميات يبحث عنها، فيعرف الـ Service إلى أي Pods يرسل حركة المرور.
- IP الـ Pod المؤقت
- كل Pod يحصل على IP خاص به، لكن هذا الـ IP غير مستقر: يتغيّر عند إعادة إنشاء الـ Pod أو نقله إلى node آخر. لذلك يجب ألا تعتمد عليه مباشرةً.
- موازنة الأحمال
- توزيع الطلبات الواردة على عدة Pods متطابقة، بحيث لا تُحمَّل أي نسخة وحدها وتبقى الخدمة متاحة.
- targetPort
- الـ port الذي يستمع عليه التطبيق داخل الـ Pod فعليًا. يستقبل الـ Service حركة المرور على الـ port الخاص به ويمرّرها إلى الـ targetPort الخاص بالـ Pod.
