02 أكتوبر 2025·8 دقيقة
بريندان بيرنز وKubernetes: الأفكار التي شكّلت التنسيق
نظرة عملية على أفكار بريندان بيرنز في عصر Kubernetes—الحالة المرغوبة التصريحية، المتحكمات، التحجيم، وعمليات الخدمة—ولماذا أصبحت هذه الأفكار معيارية.
نظرة عملية على أفكار بريندان بيرنز في عصر Kubernetes—الحالة المرغوبة التصريحية، المتحكمات، التحجيم، وعمليات الخدمة—ولماذا أصبحت هذه الأفكار معيارية.
لم يقدم Kubernetes أداة جديدة فحسب—بل غيّر شكل "العمليات اليومية" عندما تدير عشرات (أو مئات) الخدمات. قبل ظهور نظم التنسيق، كانت الفرق غالبًا تجمع بين سكربتات، كتيبات تشغيل يدوية، ومعرفة قبلية لحل نفس الأسئلة المتكررة: أين يجب أن يعمل هذا الخدمة؟ كيف نطرح تغييرًا بأمان؟ ماذا يحدث عندما تموت عقدة في الساعة الثانية صباحًا؟
في جوهره، التنسيق هو طبقة التنسيق بين نيتك («شغّل هذه الخدمة هكذا») والواقع الفوضوي للماكينات التي تفشل، وتحركات حركة المرور، والنشرات المستمرة. بدلًا من اعتبار كل سيرفر على أنه حالة فريدة، يعامل التنسيق الحوسبة كحوض والأحمال كوحدات ممكن جدولتها يمكن تحريكها.
شاع نموذج في Kubernetes حيث تصف الفرق ما تريد، ويعمل النظام باستمرار لجعل الواقع يطابق ذلك الوصف. هذه النقلة مهمة لأنها تجعل العمليات أقل اعتمادًا على بطولات فردية وأكثر اعتمادًا على عمليات قابلة للتكرار.
Kubernetes معيار نتائج تشغيلية تحتاجها معظم فرق الخدمات:
تركز هذه المقالة على الأفكار والأنماط المرتبطة بـ Kubernetes (وقادة مثل بريندان بيرنز)، لا على سيرة شخصية. وعند الحديث عن "كيف بدأ الأمر" أو "لماذا صُمم بهذه الطريقة"، يجب أن ترتكز المطالبات على مصادر عامة—محاضرات مؤتمرات، مستندات تصميم، ووثائق المشروع—حتى تبقى القصة قابلة للتحقق بدلًا من أن تكون أسطورة.
يُعترف ببريندان بيرنز على نطاق واسع كأحد الثلاثة المؤسسين الأصليين لـ Kubernetes، إلى جانب جو بيدا وكريغ ماكلكي. في الأعمال المبكرة لـ Kubernetes داخل Google، ساهم بيرنز في تشكيل الاتجاه الفني وطريقة شرح المشروع للمستخدمين—وخاصة حول "كيفية تشغيل البرامج" بدلًا من مجرد "كيفية تشغيل الحاويات". (مصادر: Kubernetes: Up & Running, O’Reilly؛ قوائم المؤلفين/المحافظين في مستودع مشروع Kubernetes)
لم يُطلَق Kubernetes كنظام داخلي مكتمل؛ بل بُني في العلن مع مجموعة متزايدة من المساهمين وحالات الاستخدام والقيود. هذا الانفتاح دفع المشروع نحو واجهات يمكنها الصمود في بيئات مختلفة:
هذا الضغط التعاوني مهم لأنه أثر في ما أمثلته Kubernetes: بنيات أولية مشتركة وأنماط قابلة للتكرار يمكن للعديد من الفرق الاتفاق عليها، حتى إن اختلفت الأدوات.
عندما يقول الناس إن Kubernetes "وحد" النشر والعمليات، فهم عادة لا يقصدون أنه جعل كل نظام متماثلًا. يعني أنه وفر مفردات مشتركة ومجموعة من سير العمل التي يمكن تكرارها عبر الفرق:
جعل هذا النموذج المشترك من السهل على الوثائق والأدوات وممارسات الفرق الانتقال من شركة إلى أخرى.
من المفيد فصل Kubernetes (المشروع مفتوح المصدر) عن نظام Kubernetes البيئي.
المشروع هو واجهة API الأساسية ومكونات لوحة التحكم التي تنفذ المنصة. النظام البيئي هو كل ما نما حوله—التوزيعات، الخدمات المُدارة، الإضافات، ومشروعات CNCF المجاورة. العديد من "ميزات Kubernetes" التي يعتمد عليها الناس في العالم الحقيقي (مكدسات الملاحظة، محركات السياسات، أدوات GitOps) تعيش في ذلك النظام البيئي، لا في المشروع النواة نفسه.
التكوين التصريحي هو تحول بسيط في كيفية وصف الأنظمة: بدلًا من سرد الخطوات الواجب تنفيذها، تصف ما تريد أن تكون النتيجة النهائية.
بمصطلحات Kubernetes، لا تقول للمنصة "شغّل حاوية، ثم افتح منفذًا، ثم أعد تشغيلها إذا تعطلّت". تصرح "يجب أن تكون هنالك ثلاث نسخ من هذا التطبيق تعمل، متاحة على هذا المنفذ، مستخدمة صورة الحاوية هذه." يتولى Kubernetes مسؤولية جعل الواقع يطابق ذلك الوصف.
العمليات الإجرائية تشبه كتيب تشغيل: سلسلة أوامر نجحت في المرة السابقة، تُنفذ مرة أخرى عند حدوث تغيير.
الحالة المرغوبة أقرب إلى عقد. تُسجَّل النتيجة المقصودة في ملف التكوين، ويعمل النظام باستمرار للوصول إليها. إذا انحرف شيء—تعطلت نسخة، اختفت عقدة، أو دخل تغيير يدوي—يكتشف النظام التفاوت ويصححه.
قبل (تفكير كتيب تشغيل إجرائي):
هذا النهج عملي، لكنه سهل أن يؤدي إلى سيرفرات "فريدة" وقائمة تحقق طويلة يثق بها عدد قليل فقط.
بعد (الحالة المرغوبة التصريحية):
apiVersion: apps/v1
kind: Deployment
metadata:
name: checkout
spec:
replicas: 3
selector:
matchLabels:
app: checkout
template:
metadata:
labels:
app: checkout
spec:
containers:
- name: app
image: example/checkout:1.2.3
ports:
- containerPort: 8080
تغيّر الملف (مثلاً، حدّث image أو replicas)، طبقه، وتعمل متحكمات Kubernetes على مصالحة ما يعمل مع ما هو معلَن.
تخفض الحالة المرغوبة التصريحية الإجهاد التشغيلي بتحويل "نفذ هذه 17 خطوة" إلى "حافظ عليه هكذا." كما تقلل انحراف التكوين لأن مصدر الحقيقة صريح وقابل للمراجعة—غالبًا في نظام التحكم بالإصدارات—إذ تصبح المفاجآت أسهل الاكتشاف، التدقيق، والرجوع عنها بثبات.
يبدو Kubernetes "يدير نفسه" لأنه مبني على نمط بسيط: تصف ما تريد، ويعمل النظام باستمرار لجعل الواقع يطابق ذلك الوصف. محرك هذا النمط هو المتحكم.
المتحكم هو حلقة تراقب الحالة الحالية للمجموعة وتقارنها بالحالة المرغوبة التي أعلنتها في YAML (أو عبر استدعاء API). عندما يلاحظ فجوة، يتخذ إجراءً لتقليص تلك الفجوة.
ليس سكربت مرة واحدة ولا ينتظر تدخلاً بشريًا. يعمل مرارًا وتكرارًا—راقب، قرر، نفّذ—حتى يستجيب للتغيير في أي لحظة.
سلوك المقارنة والتصحيح المتكرر هذا يُسمى المصالحة. إنها الآلية وراء الوعد الشائع بـ "الشفاء الذاتي." النظام لا يمنع الفشل سحريًا؛ بل يلاحظ الانحراف ويصححه.
يمكن أن يحدث الانحراف لأسباب يومية:
المصالحة تعني أن Kubernetes يتعامل مع هذه الأحداث كإشارات لإعادة التحقق من نيتك واستعادتها.
تترجم المتحكمات إلى نتائج تشغيلية مألوفة:
المفتاح هو أنك لا تطارد الأعراض يدويًا. أنت تُعلن الهدف، وحلقات التحكم تقوم بعمل "الحفاظ عليه" المستمر.
هذا النهج لا يقتصر على نوع واحد من الموارد. يستخدم Kubernetes نفس فكرة المتحكم والمصالحة عبر أشياء كثيرة—Deployments، ReplicaSets، Jobs، Nodes، Endpoints، وأكثر. تلك الاتساق سبب كبير في تحول Kubernetes إلى منصة: بمجرد أن تفهم النمط، يمكنك توقع كيفية تصرف النظام عندما تضيف قدرات جديدة (بما في ذلك الموارد المخصصة التي تتبع نفس الحلقة).
لو أن Kubernetes كان يفعل فقط "تشغيل الحاويات"، لبقَى أمام الفرق الجزء الأصعب: تحديد أين يجب أن يعمل كل عبء عمل. الجدولة هي النظام المدمج الذي يضع Pods على العقد المناسبة تلقائيًا، استنادًا إلى احتياجات الموارد والقواعد التي تعرفها.
هذا مهم لأن قرارات الموضع تؤثر مباشرة في الجهوزية والتكلفة. API ويب معلق على عقدة مكتظّة قد يصبح بطيئًا أو ينهار. مهمة على مقربة من خدمات حساسة للكمون يمكن أن تخلق مشكلة جار مزعج. يحول Kubernetes هذا إلى قدرة منتج قابلة للتكرار بدلًا من روتين جدول بيانات وSSH.
على مستوى أساسي، يبحث المجدول عن عقد يمكنها تلبية طلبات الـ Pod.
هذه العادة الوحيدة—تحديد طلبات واقعية—غالبًا ما تقلل عدم الاستقرار "العشوائي" لأن الخدمات الحرجة تتوقف عن التنافس مع الكل.
بخلاف الموارد، تعتمد معظم المجموعات الإنتاجية على بعض القواعد العملية:
تساعد ميزات الجدولة الفرق على ترميز النية التشغيلية:
الخلاصة العملية: عامل قواعد الجدولة كمواصفات منتج—دوّنها، راجعها، وطبقها باستمرار—حتى لا تعتمد الجهوزية على ذاكرة شخص ما في الساعة الثانية صباحًا.
إحدى أفكار Kubernetes الأكثر عملية هي أن التحجيم لا يجب أن يتطلب تغيير رمز التطبيق أو اختراع نهج نشر جديد. إذا كان التطبيق يستطيع العمل كحاوية واحدة، فعادة ما يمكن أن ينمو نفس تعريف العبء إلى مئات أو آلاف النسخ.
يفصل Kubernetes التحجيم إلى قرارين مرتبطين:
هذا الانقسام مهم: يمكنك طلب 200 Pod، لكن إذا كان العنقود يحتوي على مكان لـ 50 فقط، يصبح "التحجيم" قائمة انتظار من الأعمال المعلقة.
يستخدم Kubernetes عادة ثلاثة محركات تحجيم، كل واحد يركز على رافعة مختلفة:
استخدامها معًا يحول التحجيم إلى سياسة: «حافظ على الكمون ثابتًا» أو «حافظ على CPU حول X%»، بدلًا من روتين منبه يدوي.
التحجيم يعمل فقط بقدر جودة المدخلات:
تظهر خطتان مرارًا: التحجيم على مقياس خاطئ (CPU منخفض بينما الطلبات تتأخر) وغياب طلبات الموارد (لا تستطيع المحركات التخطيط للسعة، تُحشر الـ Pods معًا، وتصبح الأداء غير متسق).
نقلة كبيرة شاعت بفضل Kubernetes أن تعامل "النشر" كمشكلة تحكم مستمرة، لا سكربت مرة واحدة تشغله يوم الجمعة الساعة الخامسة. النشرات والتراجعات سلوكيات أساسية: تصرح بالإصدار الذي تريده، ويتحرك Kubernetes نحو ذلك بينما يتحقق باستمرار ما إذا كان التغيير آمنًا بالفعل.
مع Deployment، تكون النشرة استبدالًا تدريجيًا لـ Pods القديمة بأخرى جديدة. بدلاً من إيقاف كل شيء وإعادة التشغيل، يمكن لـ Kubernetes التحديث على مراحل—مُحافظًا على القدرة أثناء إثبات قدرة النسخة الجديدة على التعامل مع الحركة الحقيقية.
إذا بدأت النسخة الجديدة بالفشل، فالتراجع ليس إجراء طارئًا. إنه عملية عادية: يمكنك العودة إلى ReplicaSet سابق (آخر نسخة جيدة معروفة) والسماح للمتحكم باستعادة الحالة القديمة.
فحوصات الصحة تحول النشرات من «أمل» إلى شيء يمكن قياسه.
استخدام الفحوصات بشكل جيد يقلل النجاحات الكاذبة—نشرات تبدو سليمة لأن Pods بدأت، لكنها في الواقع تفشل أمام الطلبات.
يدعم Kubernetes التحديث التدريجي افتراضيًا، لكن الفرق غالبًا ما تضيف أنماطًا إضافية فوقه:
تعتمد النشرات الآمنة على إشارات: معدل الأخطاء، الكمون، التشبع، وتأثير المستخدم. كثير من الفرق تربط قرارات الترقية بـ SLOs وميزانيات الأخطاء—إذا أحرق الكاناري الكثير من الميزانية، يتوقف الترقية.
الغاية هي محركات تراجع تلقائية مبنية على مؤشرات حقيقية (فشل readiness، ارتفاع 5xx، قفزات الكمون)، بحيث يصبح "التراجع" استجابة نظام منتظمة—لا لحظة بطل في منتصف الليل.
تبدو منصة الحاويات "تلقائية" فقط إذا استطاعت بقية أجزاء النظام العثور على تطبيقك بعد انتقاله. في مجموعات الإنتاج الحقيقية، تُنشأ Pods وتحذف وتُعاد جدولتها وتتحجّم طوال الوقت. إذا تطلب كل تغيير تحديث عناوين IP في التكوينات، ستتحول العمليات إلى عبء مستمر—والانقطاعات ستصبح روتينية.
اكتشاف الخدمة هو ممارسة إعطاء العملاء طريقة موثوقة للوصول إلى مجموعة خلفيات متغيرة. في Kubernetes، التحول الرئيسي هو أنك تتوقف عن استهداف نسخ فردية ("اتصل بـ 10.2.3.4") وتبدأ باستهداف اسم خدمة ("اتصل بـ checkout"). المنصة تهتم بالـ Pods التي تخدم ذلك الاسم الآن.
Service هو باب ثابت لمجموعة من Pods. له اسم ثابت وعنوان افتراضي داخل العنقود، حتى عندما تتغير Pods الأساسية.
Selector هو كيف يقرر Kubernetes أي Pods تقف "خلف" هذا الباب. عادةً يطابق التسميات، مثل app=checkout.
Endpoints (أو EndpointSlices) هي القائمة الحية لعناوين IP الفعلية للـ Pods المطابقة للـ selector. عند توسعة Pods أو نشر جديد أو إعادة جدولتها، تتحدّث هذه القائمة تلقائيًا—ويستمر العملاء في استخدام نفس اسم Service.
تشغيلًا، يوفر هذا:
بالنسبة لحركة الشمال–جنوب (من خارج العنقود)، يستخدم Kubernetes عادة Ingress أو النهج الأحدث Gateway. كلاهما يوفر نقطة دخول مُتحكمًا بها حيث يمكنك توجيه الطلبات حسب اسم المضيف أو المسار، وغالبًا توحيد قضايا مثل إنهاء TLS. الفكرة المهمة ثابتة: حافظ على وصول خارجي مستقر بينما تتغير الخلفيات تحتها.
"الشفاء الذاتي" في Kubernetes ليس سحرًا. إنه مجموعة ردود آلية على الفشل: إعادة تشغيل، إعادة جدولة، واستبدال. تراقب المنصة ما قلت أنك تريده (الحالة المرغوبة) وتدفع الواقع نحوها.
إذا خرجت العملية أو أصبحت الحاوية غير صحية، يمكن لـ Kubernetes إعادة تشغيلها على نفس العقدة. غالبًا ما يحرك ذلك:
نمط شائع في الإنتاج: حاوية تنهار → Kubernetes يعيد تشغيلها → يستمر Service في توجيه الحركة فقط إلى Pods الصحية.
إذا انهارت عقدة كاملة (مشكلة أجهزة، فشل نواة، فقدان الشبكة)، يكتشف Kubernetes أن العقدة غير متاحة ويبدأ في نقل العمل إلى أماكن أخرى. على مستوى عالٍ:
هذا هو "الشفاء الذاتي" على مستوى العنقود: يستبدل النظام السعة بدلًا من انتظار تدخل بشري.
الشفاء الذاتي مهم فقط إذا استطعت التحقق منه. عادة تراقب الفرق:
حتى مع Kubernetes، قد يفشل "الشفاء" إذا كانت الضوابط خاطئة:
عندما يُعد الشفاء الذاتي بشكل جيد، تصبح الانقطاعات أصغر وأقصر—والأهم، يمكن قياسها.
لم يفز Kubernetes لأنه فقط يستطيع تشغيل الحاويات. فاز لأنه قدم واجهات API معيارية لاحتياجات التشغيل الشائعة—النشر، التحجيم، الشبكات، والمراقبة. عندما تتفق الفرق على نفس "شكل" الكائنات (مثل Deployments، Services، Jobs)، يمكن مشاركة الأدوات عبر المؤسسات، يصبح التدريب أبسط، وتتوقف تسليمات بين التطوير والتشغيل عن الاعتماد على المعرفة القبلية.
تسمح واجهة API المتسقة لأنبوب النشر الخاص بك بعدم معرفة تفاصيل كل تطبيق. يمكنه تنفيذ نفس الأفعال—إنشاء، تحديث، تراجع، والتحقق من الصحة—باستخدام مفاهيم Kubernetes نفسها.
كما تحسّن المحاذاة: يمكن لفرق الأمان التعبير عن الضوابط كسياسات؛ يمكن لـ SREs توحيد كتيبات التشغيل حول إشارات الصحة الشائعة؛ ويمكن للمطوّرين التفكير في الإصدارات بمفردات مشتركة.
يصبح تحول "المنصة" واضحًا مع Custom Resource Definitions (CRDs). تُمكّنك CRD من إضافة نوع كائن جديد إلى العنقود (مثلاً Database، Cache، أو Queue) وإدارته بنفس أنماط واجهة API الخاصة بالموارد المدمجة.
يربط Operator تلك الموارد المخصصة بمتحكم يصالح الواقع مع الحالة المرغوبة—معالجات كانت تُجرى يدويًا سابقًا مثل النسخ الاحتياطي، التحويلات، أو الترقية. الفائدة الأساسية ليست أتمتة سحرية؛ بل إعادة استخدام نفس حلقة التحكم التي يطبقها Kubernetes على كل شيء آخر.
بما أن Kubernetes مدفوع بواسطة API، فإنه يتكامل بسهولة مع سير العمل الحديث:
إذا أردت أدلة عملية أكثر على النشر والعمليات مبنية على هذه الأفكار، تصفح /blog.
أكبر أفكار Kubernetes—العديد مرتبطة بصياغة بريندان بيرنز المبكرة—تترجم بشكل جيد حتى لو كنت تشغّل على VMs أو بيئة سيرفرليس أو إعداد حاويات أصغر.
اكتب "الحالة المرغوبة" ودع الأتمتة تفرضها. سواء Terraform أو Ansible أو خط أنابيب CI، عامل التكوين كمصدر للحقيقة. النتيجة: خطوات نشر يدوية أقل وبالكثير أقل من مفاجآت "عمل على جهازي".
استخدم المصالحة، لا السكربتات لمرة واحدة. بدلًا من سكربتات تُنفَّذ مرة وتأمل النجاح، ابنِ حلقات تتحقق باستمرار من خصائص رئيسية (الإصدار، التكوين، عدد النسخ، الصحة). هذا ما يمنحك عمليات قابلة للتكرار واسترداد متوقع بعد الفشل.
اجعل الجدولة والتحجيم ميزات منتج واضحة. عرّف متى ولماذا تضيف سعة (CPU، عمق الصف، SLO الكمون). حتى بدون تحجيم Kubernetes الآلي، يمكن للفرق توحيد قواعد التحجيم بحيث لا يتطلب النمو إعادة كتابة التطبيق أو إيقاظ شخص ما.
وَحِّد عمليات النشر. التحديثات التدريجية، فحوصات الصحة، وإجراءات التراجع السريعة تقلل مخاطر التغييرات. يمكنك تنفيذ ذلك باستخدام موازنات تحميل، أعلام الميزات، وخطوط نشر تقفل الإصدارات بناءً على إشارات حقيقية.
هذه الأنماط لن تصحح تصميم تطبيق سيئ، ترحيل بيانات غير آمن، أو ضبط التكاليف. ما زلت بحاجة إلى واجهات API موقّعة، خطط ترحيل، ميزانيات/حدود، وملاحظة تربط النشرات بتأثير العملاء.
اختر خدمة تواجه العميل وطبق قائمة التحقق من طرف إلى طرف، ثم وسّع.
إذا كنت تبني خدمات جديدة وتريد الوصول إلى "شيء قابل للنشر" أسرع، يمكن لـ Koder.ai مساعدتك في توليد تطبيق ويب/خلفية/محمول كامل من مواصفات مدفوعة دردشة—عادة React في الواجهة، Go مع PostgreSQL في الخلفية، وFlutter للمحمول—ثم تصدير الشيفرة المصدرية لتطبيق نفس أنماط Kubernetes الموضحة هنا (تكوينات تصريحية، نشرات قابلة للتكرار، وعمليات رجوع صديقة للتشغيل). للمجموعات التي تقيم التكلفة والحكم، يمكنك أيضًا مراجعة /pricing.
التنسيق ينسق نيتك (ما الذي يجب أن يعمل) مع التغيّر الفعلي في العالم (فشل عقد، نشرات تدريجية، أحداث تحجيم). بدلاً من إدارة خوادم فردية، تدير الأحمال وتترك للمنصة مهمة وضعها وإعادة تشغيلها واستبدالها تلقائيًا.
عمليًا، يقلل هذا من:
التكوين التصريحي يحدد النتيجة النهائية التي تريدها (مثلاً: «3 نسخ من هذه الصورة، متاحة على هذا المنفذ») بدلاً من إجراءات خطوة بخطوة.
فوائد مباشرة يمكن الاستفادة منها:
المتحكمات هي حلقات تحكم تعمل باستمرار تقارن الحالة الحالية مقابل الحالة المرغوبة وتتصرف لسد الفجوة.
لهذا السبب يمكن أن يتصرف Kubernetes كمنصة "تدير نفسها" لنتائج مألوفة:
المجدول يقرر أين يعمل كل Pod بناءً على القيود والسعة المتاحة. إذا لم ترشده، قد ينتهي بك الأمر بجيران مزعجين، أو نقاط ازدحام، أو نسخ متجاورة على نفس العقدة.
قواعد عملية شائعة لترميز النية التشغيلية:
الطلبات تخبر المجدول بما يحتاجه الـ Pod؛ والحدود تقيد ما يمكنه استخدامه. بدون طلبات واقعية، تصبح عملية وضع الحِمل تخمينًا وغالبًا ما تتأثر الاستقرارية.
نقطة انطلاق عملية:
عملية نشر Deployment تستبدل Pods القديمة بأخرى جديدة تدريجيًا مع محاولة الحفاظ على التوافر.
لحفظ أمان النشر:
Kubernetes يوفر اسمًا وعنوانًا افتراضيًا ثابتًا لمجموعة Pods متغيرة عبر مفهوم Service. التسمية/selectors تحدد أي Pods وراء هذا المدخل، وEndpointSlices تتتبع عناوين IP الحية.
تشغيلًا، هذا يعني:
service-name بدلًا من مطاردة عناوين IPالتحجيم يعمل أفضل عندما يكون لدى كل طبقة إشارات واضحة:
الأخطاء الشائعة:
CRDs تتيح لك تعريف كائنات API جديدة (مثل Database أو Cache) حتى تتمكن من إدارة أنظمة أعلى مستوى عبر نفس واجهة Kubernetes.
المشغلون (Operators) يقرنون CRDs بمتحكمات تُصالح الحالة المرغوبة مع الواقع، وعادةً ما يؤتمتون:
عاملهم كبرمجيات إنتاجية: قيّم النضج، الرصانة المرصودة، وأنماط الفشل قبل الاعتماد عليها.