Kubernetes يجيد إدارة التطبيقات القياسية، لكن ماذا عن تطبيق معقّد كقاعدة بيانات تحتاج خطوات تشغيل خاصّة (نسخ احتياطي، ترقية، تعافٍ)؟ هنا يأتي الـ Operator. درس متقدّم يبني على الـ Deployment.
الفكرة: أتمتة خبرة التشغيل
عادةً، يعرف مسؤول بشريّ كيف يشغّل قاعدة بيانات معيّنة: كيف ينسخها احتياطيًا، ويرقّيها، ويتعافى من عطل. الـ Operator يحوّل هذه المعرفة التشغيلية إلى كود يعمل داخل العنقود ويؤتمتها.
كيف يعمل؟
يجمع الـ Operator بين عنصرين:
- مورد مخصّص (Custom Resource — CRD): يوسّع Kubernetes بنوع كائن جديد خاصّ بتطبيقك (مثلًا كائن
Database)، فتصفه إعلانيًا كما تصف أي مورد. - متحكّم مخصّص (Custom Controller): يراقب هذا المورد باستمرار، ويطبّق حلقة المطابقة نفسها التي رأيناها في Kubernetes: يقارن الحالة المطلوبة بالفعليّة، ويتّخذ الإجراءات الخاصّة بتطبيقك للوصول إليها (إنشاء نسخة احتياطية، ترقية، إلخ).
باختصار: الـ Operator يمدّ منطق Kubernetes الأصيل («صف ما تريد، ودع العنقود يحقّقه») ليشمل تطبيقات معقّدة لا يفهمها Kubernetes افتراضيًا.
متى تحتاج Operator؟
- مناسب حين: تدير تطبيقات ذات حالة معقّدة (قواعد بيانات، أنظمة رسائل موزّعة) تتطلّب منطق تشغيل خاصًّا ومتكرّرًا.
- مبالغة حين: تطبيقات بسيطة بلا حالة؛ الـ Deployment والـ StatefulSet يكفيان، ولا داعي لتعقيد الـ Operator.
كثير من الأنظمة الشائعة توفّر Operators جاهزة، فقد تستخدم واحدًا دون كتابته من الصفر.
الخطوات التالية
الـ Operator مفهوم متقدّم يُبنى على كل ما تعلّمته. راجع الـ StatefulSet للتطبيقات ذات الحالة، والـ Deployment للأساس.