إتاحة التطبيقات باستخدام Services

تُعدّ Pods أصغر الوحدات القابلة للنشر في Kubernetes. وقد صُممت لتكون مؤقتة، ويمكن لـ Kubernetes إنشاؤها أو إتلافها أو نقلها في أي وقت.

تُعدّ هذه المرونة رائعة لتعزيز المرونة، لكنها تخلق تحديًا: كيف يمكن للتطبيقات الأخرى العثور على Pods المتغيرة باستمرار والتواصل معها بشكل موثوق؟

تحصل كل Pod على عنوان IP خاص بها. وعند إعادة تشغيل Pod أو توسيع نطاقها، غالبًا ما تحصل على عنوان IP جديد. إن الاتصال مباشرةً بعنوان IP الخاص بـ Pod يشبه محاولة إصابة هدف متحرك!

تخيلوا تطبيق ويب يضم عدة Pods. إذا أُعيد تشغيل إحدى Pods، فسيتغير عنوان IP الخاص بها، مما يؤدي إلى قطع الاتصالات من الخدمات أو المستخدمين الآخرين.

هنا يأتي دور Kubernetes Services! توفر Service نقطة نهاية شبكية ثابتة ومستقرة لمجموعة من Pods.

يمكنكم اعتبارها عنوانًا دائمًا لتطبيقكم، حتى إذا كانت Pods الموجودة خلفها تغيّر عناوينها الفردية باستمرار.

تعمل Service كـ طبقة تجريد فوق مجموعة من Pods. فهي تمنحها عنوان IP واحدًا ثابتًا واسم DNS موحدًا.

• تستخدم التطبيقات الأخرى عنوان IP أو اسم Service المستقر.
• ثم توجّه Service حركة المرور إلى Pods السليمة التي تديرها.
• وهذا يفصل العملاء عن عناوين IP الفردية الخاصة بـ Pods.

كيف تعرف Service إلى أي Pods توجّه حركة المرور؟ تستخدم labels وselectors!

عند تعريف Service، تحددون selector. وستصبح أي Pod تطابق هذه labels جزءًا من مجموعة Service تلقائيًا.

يعني هذا الارتباط الديناميكي إضافة Pods الجديدة تلقائيًا وإزالة Pods غير السليمة.

تدير Services كيفية تدفق حركة مرور الشبكة. فهي تحدد المنافذ لربط الطلبات الواردة بالمنافذ الصحيحة على Pods الخاصة بكم.

مفاهيم المنافذ الأساسية:

• port: المنفذ الذي تستمع إليه Service نفسها.
• targetPort: المنفذ الموجود على Pod الذي توجّه Service حركة المرور إليه.

مثل معظم موارد Kubernetes، تُعرَّف Services باستخدام ملفات YAML. لنلقِ نظرة على بنيتها الأساسية:

• apiVersion: v1
• kind: Service
• metadata: الاسم وlabels
• spec: يحتوي على التعريف الأساسي، بما في ذلك selector وports.

يُعدّ نوع Service الأكثر شيوعًا للاتصال الداخلي هو ClusterIP. فهو يعرّض Service على عنوان IP داخلي ضمن العنقود.

فيما يلي مثال على تطبيق ويب بسيط:

بعد إعداد YAML الخاص بـ Service، يمكنكم نشرها في عنقودكم باستخدام kubectl، تمامًا كما تفعلون مع Pods أو Deployments.

يخبر هذا الأمر Kubernetes بإنشاء Service استنادًا إلى تعريفكم:

بعد النشر، تحصل Service الخاصة بكم على عنوان IP ثابت واسم DNS داخل العنقود. ويمكن لـ Pods الأخرى الآن الوصول إلى تطبيقكم باستخدام هذا الاسم.

على سبيل المثال، يمكن لـ Pod أخرى الاتصال بـ my-web-service:80، وستتولى Service توجيه الطلب إلى Pods الصحيحة من my-webapp.

لقد تعلمتم كيف توفر Kubernetes Services وصولًا شبكيًا مستقرًا إلى Pods الديناميكية.

أيّ من الخيارات التالية يصف الدور الأساسي لـ Kubernetes Service على أفضل وجه؟

أحسنتم! استكشفنا في هذا الدرس Kubernetes Services.

• Pods مؤقتة ولها عناوين IP ديناميكية.
• توفر Services نقاط نهاية شبكية مستقرة لـ Pods.
• تستخدم selectors للعثور على Pods المستهدفة.
• تربط Services بين port الخارجي وtargetPort الداخلي.
• يُعدّ ClusterIP نوعًا شائعًا للاتصال الداخلي.

سنتعمق بعد ذلك في أنواع Services المختلفة واستخداماتها!