لدى Kubernetes مشكلة في السمعة: نصف القطاع يتخذه وسامًا، والنصف الآخر يراه عبئًا إضافيًا. أما أنا فأراه أداة لها نقطة استخدام واضحة. يعمل موقع تسويقي أو منتج أولي MVP جيدًا على خادم واحد مع مدير عمليات ومهمة CI — وهذه هي طريقة نشر هذا الموقع نفسه. ويبدأ Kubernetes في استحقاق مكانه عندما تتعدد الخدمات، ويتقلب الحمل، ويعمل أكثر من فريق على البنية التحتية ذاتها.
يبدأ كل شيء بالحاوية. ملفات Docker متعددة المراحل، وصورة تشغيل صغيرة بلا اعتماديات تطوير، ومستخدم غير root، وعملية واحدة في كل حاوية. يُبنى تطبيق Next.js في وضع standalone؛ ولا تتضمن API الخاصة بـNestJS سوى dist واعتماديات node_modules الخاصة بالإنتاج. تنتقل الصورة نفسها من CI إلى بيئة الاختبار ثم الإنتاج؛ الذي يتغير هو الإعداد فقط، عبر متغيرات البيئة وConfigMaps وSecrets، من دون إعادة بناء لكل بيئة.
الأشياء التي أستخدمها يوميًا قليلة: Deployment لكل خدمة، وService أمامها، وIngress مع TLS للمرور العام، وHorizontalPodAutoscaler للأجزاء التي يتذبذب حملها فعلًا. لكل حاوية طلبات موارد وحدودها؛ من دونها يخمّن المجدول. نفصل readiness probe عن liveness probe عمدًا: الأولى تقول «لا ترسل إليّ حركة المرور بعد»، والثانية «أعد تشغيل الحاوية». الخلط بينهما يحوّل قاعدة بيانات بطيئة إلى موجة متكررة من إعادة التشغيل. وتعالج كل خدمة Node.js الإشارة SIGTERM وتنهي الطلبات الجارية، كي لا يقطع التحديث التدريجي عملية دفع في منتصفها.
ليس كل شيء خادم ويب. تعمل عمال الطوابير في Deployments مستقلة وتتوسع حسب تراكم المهام، لا حسب CPU. أما الأعمال المجدولة — التقارير والتنظيف والتسوية مع مزود دفع — فتعمل كـCronJobs مع concurrencyPolicy: Forbid، كيلا يتداخل تشغيل بطيء مع التشغيل التالي. تُجرى ترحيلات قاعدة البيانات في Job قبل الإطلاق، لا عند بدء التطبيق؛ فلا ينبغي لخمس نسخ متماثلة تبدأ معًا أن تحاول ترحيل المخطط كلها. أفضل PostgreSQL مُدارًا مثل RDS بدل StatefulSet؛ فالعنقود للخدمات عديمة الحالة.
تعيش ملفات البيان في Git وتخضع للمراجعة مثل الشيفرة. يجري النشر عبر خط CI باستخدام Helm أو Kustomize، أو عبر GitOps باستخدام Argo CD؛ وعندها يصبح التراجع revert بدل جلسة kubectl ليلية. يفيد kubectl apply من الحاسوب المحمول في التعلم، لا في الإنتاج. تذهب السجلات إلى stdout ثم إلى مخزن مركزي، والمقاييس إلى Prometheus وGrafana، وأتابع النشر عبر kubectl rollout status بدل الاكتفاء بالأمل. وعلى AWS يعني ذلك عادة EKS مع مجموعات عقد مُدارة، كي يركز الفريق على المنتج لا على control plane.
أرفض Kubernetes لموقع من صفحتين، وservice mesh قبل وجود عدة خدمات، وأسرارًا مكشوفة بصيغة YAML داخل المستودع، وحاويات بلا حدود لمجرد أنها «عملت في staging». إن لم تعرفوا هل تحتاجون إلى عنقود، فأرسلوا الخدمات وحجم الحركة وحجم الفريق. سأخبركم بصراحة هل الأنسب Kubernetes، أم بضع حاويات على خادم واحد، أم منصة مثل Vercel، وما التكلفة الشهرية التقريبية لكل خيار.
امنح المنتج القادم شخصاً يبقى معه.
هل أنت مستعد للبدء؟ أرسل لي رسالة؛ أنا متاح للبدء الآن والبقاء. عقود طويلة الأمد، لا تسليم خلال أسبوعين. لنتحدث عن مشروعك ومتطلباته وأفضل طريقة للمضي قدماً.