ينسّق Kubernetes الحاويات عبر أجهزة كثيرة — جدولةً وتوسيعًا وإعادة تشغيل وربطًا شبكيًا. وهو قوي فعلًا وثقيل فعلًا، ومعظم المشاريع التي تتبناه كان شيء أبسط سيخدمها أفضل.
ما هي Kubernetes؟
يأخذ Kubernetes أسطولًا من الأجهزة ويعاملها كتجمّع سعة واحد. فتصف الحالة التي تريدها — هذا العدد من نسخ هذه الخدمة، بهذا القدر من الذاكرة — ويعمل على إبقاء الواقع مطابقًا لذلك الوصف، فيعيد تشغيل ما يفشل ويعيد الجدولة حول جهاز ميت.
وعند المقياس الحقيقي تلك قيمة هائلة. ودونه، تكون قد تحمّلت نظامًا موزعًا لتشغيل موقع.
والنمط الذي نراه أكثر هو عميل قيل له إنه يحتاجه، عادةً من عرض لا من قياس. والسؤال الصادق ليس أهو جيد — فهو كذلك — بل أهي المشاكل التي يحلها مشاكل تملكها حاليًا.
متى نختار Kubernetes
حين توجد خدمات كثيرة وفريق لتشغيلها. فدون نحو عشر خدمات وشخص منصات متفرغ، تؤدي أدوات أبسط المهمة بجزء يسير من العبء.
وحين يشغّله العميل أصلًا. فإضافة خدمة إلى عنقود قائم مباشرة والكلفة التشغيلية مدفوعة أصلًا.
متى لا نستخدم Kubernetes
لكل ما نبنيه تقريبًا. فموقع، أو تطبيق ويب، بل ونظام بثلاث أو أربع خدمات يعمل جيدًا تمامًا على منصة حاويات مُدارة أو خادمين افتراضيين، بجزء يسير من السطح التشغيلي.
وسنقول هذا صراحةً حين يأتي عميل طالبًا Kubernetes لأنه ظهر في عرض. فتبنّيه بلا المقياس ولا الفريق اللازم لتشغيله أغلى خطأ معماري متاح في هذه الفئة.
ما الذي نبنيه بـ Kubernetes
نشر داخل عنقود قائم
حيث يشغّل العميل Kubernetes أصلًا، نحزّم التطبيق ليلائم أعرافهم القائمة بدل إدخال طريقة ثانية للعمل.
ترحيل إلى منصة العميل
أخذ تطبيق بنيناه وملاءمته لأعراف عنقود المؤسسة القائمة — دخولها، وإدارة أسرارها، ومراقبتها — فيستطيع فريق منصتها تشغيله كأي شيء آخر يشغّلونه.
ضبط حجم عنقود قائم
حيث تُبنّي عنقود مبكرًا وصار الآن يكلّف أكثر مما تبرره الحركة. وأحيانًا تكون التوصية بالإبقاء عليه وضبطه؛ وأحيانًا بالانتقال عنه، وسنقول أيهما.
مراجعات كلفة وسعة
تدقيق ما يشغّله عنقود فعلًا مقابل ما يحتاجه فعلًا. فأحمال العمل المفرطة التزويد والخدمات المنسية شائعة، والتوفير عادةً كبير بما يغطي كلفة المراجعة عدة مرات.
كيف نطلق مشاريع Kubernetes
على خدمة مُدارة لا عنقود مبنيّ ذاتيًا. فتشغيل مستوى التحكم بنفسك وظيفة، وليست وظيفة تفيد العميل.
ومع ضبط حدود موارد لكل حمل عمل، لأن أشيع فشل عنقود هو خدمة تستهلك كل شيء وتأخذ البقية معها.
مع ضبط فحوص الصحة والإيقاف اللطيف بشكل سليم. فعنقود يعيد تشغيل جراب في منتصف طلب لأن فحصًا أُسيء ضبطه ينتج إخفاقات متقطعة يصعب جدًا تتبعها إلى سببها.
ما تكلّفك Kubernetes
منحنى التعلم شديد والعبء التشغيلي دائم. فلا بد لأحد أن يفهمه في الثالثة فجرًا، ولا بد أن يوجد ذلك الشخص قبل أن تتبناه.
وهو أغلى تشغيلًا من السعة المكافئة في غيره، لأن مستوى التحكم والتكرار ليسا مجانيين.
الكلفة التي تفاجئ الناس ليست الخوادم بل الانتباه. فالشهادات تنتهي، والمتحكمات تحتاج ترقية، وعقدة تنفد مساحتها. ولا شيء من ذلك صعب وكله يحتاج شخصًا وظيفته ذلك، ولهذا نسأل عن الفريق قبل أن نسأل عن حمل العمل.
أسئلة تُطرح علينا عن Kubernetes
على الأرجح لا، إلا إن كنت تشغّله أصلًا أو لديك أكثر من نحو عشر خدمات وشخص وظيفته المنصة. ولكل ما هو أصغر، تؤدي خدمة حاويات مُدارة أو خادمان المهمة نفسها بأقل بكثير مما قد يعطب.
خدمة حاويات مُدارة، أو خادم أو خادمان يشغّلان Docker بسكربت نشر بسيط. فكلاهما يمنحك نشرًا قابلًا لإعادة الإنتاج وتراجعًا سهلًا، وهذا ما أرادته معظم الفرق فعلًا من Kubernetes، بلا عنقود تشغّله.
تقريبًا حين تصبح خدماتك أكثر من الأشخاص الذين يفهمونها، ويوجد شخص وظيفته الفعلية المنصة. وقبل ذلك يقع العبء التشغيلي على مطورين ينبغي أن يبنوا المنتج بدلًا من ذلك.
نعم — ننشر في عناقيد قائمة بانتظام ونتبع الأعراف التي وضعها فريق منصتك بدل إدخال أعرافنا. فطريقتان للعمل في عنقود واحد أسوأ من أي منهما وحدها.
عادةً لا عند المقياس الموصوف. فخادم واحد بحجم مناسب يتحمل حركة أكثر مما يفترض معظم الناس، وإضافة ثانٍ خلف موزّع أحمال تغطي معظم الباقي. وKubernetes يحل التوسع عبر أجهزة كثيرة وخدمات كثيرة، وهذه مشكلة مختلفة عن أن يكون لديك زوار أكثر من قبل.
نعم، وهو أسهل مما يتوقع معظم الناس إن كان التطبيق في حاويات — فالحاويات تعمل في أي مكان. وما تفكّه هو إعداد التنسيق لا التطبيق. وقد فعلنا ذلك لعملاء كلّفهم عنقودهم انتباهًا أكثر مما أعاد.
نعم، ونفعل كثيرًا. فالتوصية بعنقود لعميل بأربع خدمات وبلا مهندس منصات بيعٌ لتعقيد سنُدفع بعده لإدارته. ونصيحتنا عادةً خدمة حاويات مُدارة وفاتورة أصغر، وهي النصيحة نفسها سواء كسبت لنا العمل أم لا.