المقدمة

في المقال السابق، اتكلمنا عن إزاي Docker ساعدنا نوحد بيئة التشغيل، بحيث التطبيق يشتغل بنفس الطريقة في التطوير، والاختبار، والإنتاج.

لكن مع نجاح الـ Containers، ظهرت مشكلة جديدة.

تخيل إن شركتك بقى عندها:

  • عشرات الخدمات (Microservices).
  • مئات الـ Containers.
  • آلاف المستخدمين.

السؤال مبقاش:

"إزاي أشغل Container؟"

السؤال بقى:

  • لو Container وقف فجأة... مين هيشغله تاني؟
  • لو عدد المستخدمين زاد... إزاي أزود عدد الـ Containers تلقائيًا؟
  • إزاي أعمل تحديث للتطبيق بدون توقف الخدمة؟
  • إزاي أوزع الطلبات بين النسخ المختلفة؟
  • وإزاي أتأكد إن التطبيق هيشتغل حتى لو Server كامل خرج من الخدمة؟

كل ده ممكن تعمله يدويًا...

لكن مستحيل يكون عملي على مئات أو آلاف الـ Containers.

هنا ظهر دور Kubernetes.

Kubernetes مش مجرد أداة لتشغيل Containers.

هو منصة لإدارة التطبيقات المعتمدة على الحاويات (Container Orchestration).

بدل ما تدير كل Container بنفسك...

أنت بتوصف الحالة المطلوبة (Desired State).

على سبيل المثال:

  • عايز 3 نسخ من التطبيق تكون شغالة دائمًا.
  • لو واحدة وقفت، تتشغل تلقائيًا.
  • لو الضغط زاد، زود عدد النسخ.
  • لو نزل إصدار جديد، اعمل تحديث تدريجي بدون إيقاف الخدمة.

ويكون Kubernetes هو المسؤول عن تحقيق الحالة دي والحفاظ عليها.

وده من أهم الأفكار في Kubernetes.

أنت لا تدير الحاويات مباشرة...

أنت تصف النتيجة التي تريدها، و Kubernetes يعمل باستمرار للوصول إليها والحفاظ عليها.

💡 الخلاصة

Docker جعل تشغيل التطبيقات أسهل.

أما Kubernetes...

فجعل إدارة التطبيقات على نطاق واسع ممكنة.

وده السبب إن Kubernetes لم يأتِ ليحل محل Docker.

بل جاء ليحل مشكلة مختلفة تمامًا:

إدارة وتشغيل التطبيقات الموزعة بشكل موثوق وقابل للتوسع.

🚀 في المقال القادم...

إذا كان Kubernetes يدير التطبيقات...

ليه احتجنا Infrastructure as Code وأدوات زي Terraform؟

#Kubernetes #Containers #Docker #Cloud #DevOps #PlatformEngineering #