تكاليف Kubernetes الست التي لا يذكرها أحد في عرض السعر

نبني Kubernetes ونشغّله للشركات الأسترالية منذ سنوات، ومع ذلك ما زلنا نُقنع نحو ثلث من يستفسرون بالعدول عنه. ليس لأن التقنية سيئة، فهي ممتازة فيما صُممت له، بل لأن دراسة الجدوى التي تُعرض علينا تستند عادةً إلى مقارنة تكاليف تُغفل معظم التكاليف.

إذا كنت تدرس الانتقال، فهذه هي البنود الستة التي تحدد ما إذا كان سيغطي تكلفته. ولا يظهر أي منها في مقارنة التراخيص.

ما الذي يغطيه عرض السعر

يغطي عرض السعر النموذجي للانتقال بناء العنقود، والعمل على خط CI/CD، ووضع التطبيقات في حاويات، والتحويل إلى البيئة الجديدة. هذا العمل حقيقي والتقديرات معقولة عادةً.

الفجوة أن بناء العنقود هو الجزء السهل والمفهوم جيداً والقابل للأتمتة بدرجة عالية. فباستخدام Terraform وطبقة تحكم مُدارة، يحتاج عنقود بمستوى الإنتاج إلى أيام من العمل. أما ما يستنزف الميزانية فهو كل ما يمسّه العنقود بعد ذلك.

1. إعادة كتابة التطبيقات التي لم تدخل في التقدير

"موضوع في حاوية" و"جاهز للحاويات" حالتان مختلفتان، والفجوة بينهما هي موضع أول تجاوز للميزانية.

يمكن وضع أي شيء في حاوية. أما ما إذا كان سيعمل بشكل صحيح عندما يعامله Kubernetes بالطريقة التي يعامل بها كل شيء، فتلك مسألة أخرى. سيقتل Kubernetes الـ pod الخاص بك، ويعيد جدولته على عقدة أخرى، ويشغّل عدة نسخ منه، ويعيد تشغيله في أوقات غير مناسبة. والتطبيقات التي تفترض غير ذلك تتعطل بطرق تبدو متقطعة.

المسببات المعتادة:

• الكتابة إلى نظام الملفات المحلي. الملفات المرفوعة، والذاكرات المؤقتة، والملفات المولّدة، والسجلات المكتوبة على القرص. نظام ملفات الحاوية مؤقت. وكل واحد من هذه يجب نقله إلى تخزين الكائنات أو إلى وحدة تخزين.
• حالة الجلسة في الذاكرة. تعمل مع نسخة واحدة. ومع ثلاث نسخ يُسجَّل خروج المستخدمين عشوائياً.
• قراءة الإعدادات من ملفات على القرص بدلاً من البيئة، فتحتاج كل بيئة إلى صورة مختلفة، وهذا يُفقد الفكرة معناها.
• بدء تشغيل بطيء أو غير صادق. يحتاج Kubernetes إلى معرفة متى يكون تطبيقك جاهزاً فعلاً. والتطبيقات التي تُبلغ بأنها جاهزة ثم تقضي أربعين ثانية في تهيئة الذاكرة المؤقتة ستُسقط حركة المرور مع كل عملية نشر.
• تجاهل SIGTERM. من دون إيقاف سلس، تقتل كل عملية نشر الطلبات الجارية. يرى المستخدمون عدداً قليلاً من الأخطاء مع كل إصدار، ولا أحد يربط ذلك بعملية النشر.

بالنسبة لتطبيق حديث يتبع أصلاً مبادئ twelve-factor، يكاد هذا العمل يكون معدوماً. أما لتطبيق عمره عشر سنوات لم يعمل يوماً إلا على خادم واحد، فقد يكون أكبر بند في المشروع. والطريقة الصادقة لمعرفة ذلك هي وضع تطبيق تمثيلي واحد في حاوية وتشغيله بثلاث نسخ قبل الالتزام بالنطاق الكامل.

2. الحالة (Statefulness)

أحمال العمل عديمة الحالة هي ما يتقنه Kubernetes فعلاً ومن دون أي لبس. أما الحالة فهي حيث تتركز الصعوبة.

قواعد البيانات، وطوابير الرسائل، وأي شيء يحتفظ ببيانات يحتاج إلى وحدات تخزين دائمة، ما يعني فئات التخزين، وأنماط الوصول، ونسخاً احتياطياً واستعادة تفهم هذا التجريد، وخطة لما يحدث عندما تتعطل عقدة في منتصف عملية كتابة. لدى Kubernetes أدوات أساسية جيدة لذلك. لكنها تظل أصعب بشكل ملموس في تشغيلها بشكل صحيح من قاعدة بيانات على جهاز افتراضي بمهمة نسخ احتياطي تعمل منذ 2019.

3. الشبكات وحركة البيانات الصادرة

هنا مفاجأتان مختلفتان.

نموذج الشبكات جديد فعلاً. الخدمات (Services)، ووحدات التحكم في الدخول (ingress controllers)، وسياسات الشبكة، وشبكة الخدمات (service mesh) إن ذهبت إليها، وDNS داخل العنقود، وكيفية وصول أي من ذلك إلى شبكة شركتك الحالية. الفرق المعتادة على VLAN وقواعد الجدار الناري كفؤة لكنها ليست متمرسة بعد، والتمرس يستغرق أشهراً.

رسوم حركة البيانات الصادرة من السحابة بند حقيقي في الميزانية. حركة البيانات التي تغادر مزود السحابة تُحتسب، وكثيراً ما تُحتسب أيضاً الحركة التي تعبر مناطق التوفر. فبنية الخدمات المصغرة التي كانت عملية واحدة تجري استدعاءات دوال محلية تصبح خدمات كثيرة تجري استدعاءات عبر الشبكة، وأحياناً عبر المناطق. وقد رأينا ذلك يتحول إلى مفاجأة سنوية بخمس خانات في تصميم معقول من جميع النواحي الأخرى. يمكن تجنب ذلك بالتوجيه المراعي للمناطق وحدود خدمات معقولة، لكن فقط إذا فكّر فيه أحد قبل تثبيت البنية.

4. فريق المنصة الذي تحتاجه الآن

هذه هي التكلفة التي يُغفل ذكرها في أغلب الأحيان، وهي الأكثر ترجيحاً لحسم النتيجة.

Kubernetes التزام تشغيلي. لا بد أن يتولى أحدٌ مسؤولية العنقود، ويفهم لماذا يبقى pod في حالة Pending، ويحافظ على تحديث وحدة التحكم في الدخول وCNI ومنظومة المراقبة، ويكون متاحاً عندما يتعطل شيء في ساعة غير مناسبة. إنها قدرة، سواء وظّفتها أو درّبتها أو أسندتها إلى جهة خارجية.

نمط الفشل متوقع: مهندس متحمس يقود الانتقال، ويصبح الشخص الوحيد الذي يفهم المنصة، ثم يغادر. وما يبقى هو نظام إنتاج لا يستطيع أحد لمسه بأمان. استُدعينا إلى هذا الموقف بالضبط أكثر من مرة، وهو وضع أسوأ بكثير من الأجهزة الافتراضية التي بدأوا بها.

قبل الالتزام، أجب بصراحة: من سيشغّل هذا بعد ثمانية عشر شهراً، وماذا يحدث إذا استقال ذلك الشخص؟

5. ترقيات الإصدارات، إلى الأبد

يصدر Kubernetes عدة مرات في السنة، ولكل إصدار فترة دعم تقارب سنة واحدة. وستقوم الخدمات المُدارة بترقيتك في النهاية سواء كنت مستعداً أم لا.

وهذا يعني وتيرة ترقيات متكررة، بشكل دائم. كل ترقية تحمل بعض المخاطر: واجهات API مهملة لا تزال ملفات التعريف لديك تستخدمها، ووحدات تحكم تحتاج إلى إصدارات متوافقة، وتغييرات عرضية في السلوك. الأمر قابل للإدارة، ويصبح روتينياً فعلاً بعد أن تنفّذ بضع ترقيات، لكنه عمل مستمر لم يكن موجوداً عندما كان خادم يعمل بنظام التشغيل نفسه لأربع سنوات.

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

6. تشخيص الأعطال يصبح أصعب قبل أن يصبح أسهل

على جهاز افتراضي، يدخل المهندس عبر SSH، ويتابع سجلاً، ويشغّل top، ويكوّن فرضية خلال دقيقتين مستخدماً مهارات بناها على مدى عقد.

في العنقود، تختلف العملية. أي pod؟ على أي عقدة استقر؟ هل قُتل بسبب OOM وأُعيد تشغيله قبل أن ينظر إليه أحد؟ هل تُرسل السجلات إلى مكان ما، وهل يمكن البحث في ذلك المكان؟ الإجابات موجودة والأدوات جيدة، لكن التمرس جديد ويستغرق أشهراً لإعادة بنائه.

توقّع أن يزداد متوسط وقت الحل سوءاً لفترة بعد الانتقال. هذا طبيعي ومؤقت، لكنه حقيقي، ويحدث تحديداً عندما يراقب الجميع المنصة الجديدة عن كثب. خطط لذلك: اجعل السجلات والمقاييس المركزية تعمل قبل التحويل، لا بعد أن تثبت أول حادثة أنك تحتاج إليها.

متى يستحق الأمر فعلاً

لا شيء من هذا حجة ضد Kubernetes. نحن نشغّله، ونحبه، وللنوع المناسب من المشكلات لا يقترب منه أي بديل.

أقوى دراسات الجدوى التي رأيناها لم تكن عن تكلفة البنية التحتية. كانت عن سرعة النشر، إذ انتقلت الفرق من إصدار كل أسبوعين إلى عدة إصدارات في اليوم، وعن الاتساق، حيث أصبحت بيئات التطوير والاختبار والإنتاج تتصرف بشكل متطابق أخيراً واختفت فئة كاملة من الأخطاء.

هذه نتائج حقيقية وقيّمة. لكنها ليست النتائج الموجودة في جدول مقارنة التكاليف، وتسويق الانتقال على أساس توفير تكاليف البنية التحتية ينتهي عادةً بحديث محرج عن الفاتورة بعد اثني عشر شهراً.

إذا قدّم لك أحدهم عرض سعر للانتقال إلى Kubernetes، فاسأله أي هذه البنود الستة قدّرها. الإجابة الجيدة ستكون محددة بشأن تطبيقاتك. أما الإجابة المبهمة فتعني أنك ستكتشف هذه التكاليف بنفسك، في بيئة الإنتاج.