تخطّي إلى المحتوى
السحابة والبنية التحتية
العودة إلى الكتاباتالسحابة والبنية التحتية

شبكات Kubernetes ببساطة

تعلّم شبكات Kubernetes بتشبيه مدينة بسيط: Service و Load Balancer و Ingress و Gateway API و Service Mesh و Istio و OSM — شرح للمبتدئين.

اليوم دار نقاش لطيف بيني وبين بعض الأصدقاء حول شبكات Kubernetes كان أحد الأسئلة: كيف يدير Kubernetes عناوين IP؟ وكيف تعمل الـ Services؟ ولماذا يمتلك الـ Service عنوان IP خاصًا به رغم وجود Load Balancer أمامه؟

عندما تبدأ تعلم Kubernetes ستسمع كثيرًا مصطلحات مثل Service | Load Balancer | Ingress | Gateway API | Service Mesh | Istio

في البداية تبدو هذه المصطلحات معقدة ومربكة.

لذلك سنشرحها بطريقة بسيطة وسهلة الفهم باستخدام مثال المدينة الكبيرة.

تخيل أن Kubernetes مدينة كبيرة

تخيل مدينة مليئة بالمباني. كل مبنى يمثل Pod وكل Pod يحتوي على تطبيق أو جزء من تطبيق.

المشكلة أن هذه المباني قد تُهدم وتُبنى من جديد باستمرار، وبالتالي تتغير عناوينها. إذا تغير عنوان المبنى، كيف سيعرف الناس إلى أين يذهبون؟

هنا تبدأ أهمية مكونات الشبكات في Kubernetes

أولًا: Service — موظف الاستقبال

تخيل أن لديك عشرة موظفين يؤدون نفس المهمة في عشرة مبانٍ مختلفة. بدلًا من أن يحفظ الزوار عنوان كل مبنى، يذهبون إلى مكتب استقبال واحد. موظف الاستقبال يعرف أين يوجد الموظفون ويُوجّه الزائر إلى أحدهم.

  • الـ Pods هم الموظفون.
  • الـ Service هو موظف الاستقبال.

يوفر الـ Service عنوانًا ثابتًا للتطبيق. حتى لو تم حذف الـ Pods وإنشاؤها من جديد، يبقى عنوان الـ Service كما هو.

الفكرة الأساسية ان Service هو عنوان ثابت لمجموعة من الـ Pods المتغيرة.

ثانيًا: Load Balancer — شرطي تنظيم المرور

تخيل أن آلاف السيارات تدخل المدينة في نفس الوقت. إذا دخلت جميعها من طريق واحد سيحدث ازدحام شديد. لذلك يقف شرطي مرور لتنظيم الحركة وتوزيع السيارات على عدة طرق.

في Kubernetes يقوم الـ Load Balancer بالمهمة نفسها. فهو يوزع الطلبات القادمة على عدة Pods بدلًا من إرسالها كلها إلى Pod واحد.

بدون Load Balancer قد يتعرض أحد الـ Pods لضغط شديد ويتوقف عن العمل.

مع Load Balancer يتم توزيع الحمل بالتساوي.

الفكرة هنا هي ان Load Balancer هو شرطي مرور يوزع الزحام على عدة مسارات.

ثالثًا: Ingress — بوابة المدينة (الطريقة التقليدية)

لنفترض أن داخل المدينة عدة خدمات: متجر إلكتروني، مدونة، وواجهة برمجية (API). ولا تريد إنشاء بوابة مستقلة لكل خدمة. بدلًا من ذلك تنشئ بوابة رئيسية واحدة. يقف عندها حارس يقرأ الوجهة المطلوبة ثم يوجه الزائر إلى المكان الصحيح.

في Kubernetes كان Ingress يؤدي هذا الدور.

  • api.ajrly.com → خدمة الـ API
  • blog.ajrly.com → خدمة المدونة
  • shop.ajrly.com → المتجر الإلكتروني

الفكرة هنا هي ان Ingress هو بوابة واحدة تستقبل الجميع ثم توزعهم على الوجهة المناسبة.

لماذا لم يعد Ingress الخيار المفضل؟

تم تصميم Ingress منذ سنوات طويلة عندما كانت احتياجات Kubernetes أبسط. ومع توسع الأنظمة أصبحت هناك حاجة إلى إمكانيات أكثر مرونة وتنظيمًا. لذلك ظهر Gateway API كبديل حديث.

رابعًا: Gateway API — البوابة الذكية الحديثة

تخيل أن المدينة استبدلت البوابة القديمة بمطار حديث ومتطور. أصبح بالإمكان إنشاء عدة بوابات، وضع قواعد أكثر تعقيدًا، فصل مسؤوليات الفرق المختلفة، وإدارة الحركة بشكل أفضل.

Gateway API هو الجيل الجديد من إدارة حركة المرور الداخلة إلى Kubernetes.

Ingress يشبه بوابة مدينة قديمة.

Gateway API يشبه مطارًا حديثًا يحتوي على أنظمة متقدمة لإدارة الحركة.

الفكرة هنا هي ان Gateway API هو نسخة أكثر تطورًا ومرونة من Ingress.

خامسًا: Service Mesh — شبكة الطرق الذكية داخل المدينة

حتى الآن تحدثنا عن الزوار القادمين من خارج المدينة. لكن ماذا يحدث داخل المدينة نفسها؟

تخيل أن المبنى الأول يتواصل مع الثاني، الثاني يتواصل مع الثالث، والثالث يتواصل مع الرابع. ومع زيادة عدد المباني تصبح إدارة هذه الاتصالات صعبة.

قد تحتاج إلى تشفير الاتصالات، مراقبة الحركة، تسجيل الأحداث، التحكم في الصلاحيات، وإعادة المحاولة عند حدوث أخطاء. يمكنك برمجة كل هذه الوظائف داخل كل تطبيق — لكن هذا سيجعل التطبيقات أكثر تعقيدًا.

لذلك يتم إنشاء شبكة طرق ذكية تتولى هذه المهام تلقائيًا. هذه هي فكرة Service Mesh.

الفكرة من Service Mesh هي انها طبقة تدير الاتصالات بين الخدمات داخل Kubernetes

سادسًا: Istio — أشهر Service Mesh

Istio هو أحد أشهر حلول Service Mesh في عالم Kubernetes يوفر مزايا متقدمة مثل تشفير الاتصال بين الخدمات (mTLS)، مراقبة حركة المرور، إدارة التوجيه بين الإصدارات المختلفة، تتبع الطلبات بين الخدمات، وفرض سياسات الأمان.

مثال: يمكن إرسال 90٪ من المستخدمين إلى الإصدار القديم و10٪ إلى الإصدار الجديد دون تعديل التطبيق نفسه.

هنا نفهم ان Istio هو نظام متقدم لإدارة وتأمين الاتصالات داخل Kubernetes

سابعًا: Open Service Mesh (OSM)

OSM هو مشروع Service Mesh آخر. تم تصميمه ليكون أبسط وأخف من Istio. عادةً ما يفضله من يبحث عن سهولة التعلم، سهولة التشغيل، واستهلاك أقل للموارد. بينما يفضل كثير من المؤسسات الكبيرة Istio بسبب إمكانياته الأوسع.

OSM يشبه نظام مرور لمدينة صغيرة.

Istio يشبه مركز التحكم في حركة مطار دولي ضخم.

ملخص سريع

مبنى (Pod)

موظف استقبال (Service)

شرطي مرور (Load Balancer)

بوابة المدينة التقليدية (Ingress)

بوابة ذكية حديثة (Gateway API)

شبكة الطرق الذكية داخل المدينة (Service Mesh)

نظام متقدم لإدارة الحركة والاتصالات (Istio)

نظام مبسط لإدارة الحركة والاتصالات (OSM)

الخلاصة

لفهم الصورة الكاملة تذكر هذا التسلسل:

  • الـ Pods تشغل التطبيقات.
  • الـ Services تمنح التطبيقات عنوانًا ثابتًا.
  • الـ Load Balancer يوزع الطلبات القادمة.
  • الـ Ingress أو Gateway API يديران حركة المرور القادمة من خارج النظام.
  • الـ Service Mesh يدير الاتصالات داخل النظام.
  • Istio و OSM هما من أشهر تطبيقات Service Mesh.

إذا فهمت مثال المدينة، فقد فهمت الأساس الذي تقوم عليه شبكات Kubernetes.