أكبر كذبة في عالم التكنولوجيا في السنوات 5-6 الماضية هي: «ضع تطبيقك على Kubernetes وسيقوم بالباقي.» سيخبرك أولئك الذين يأخذون المسرح في المؤتمرات عن مدى «الشفاء الذاتي» لـ Kubernetes (K8s) وأداة تنسيق مذهلة. لكن لا أحد يخبرك عن تكلفة جيش المهندسين المطلوب لتشغيل تلك الأوركسترا.
الحقيقة المحزنة هي أنك لست Google. ربما لا تواجه مشاكل تحجيم Google أيضًا. ولكن بسبب «FOMO» (الخوف من التخلف عن الركب) في الصناعة، فإنك تحاول إدارة حتى موقع ويب بسيط بنظام تعقيد لوحة التحكم في الغواصات النووية. دعونا نلقي نظرة على فاتورة «YAML hell» غير المرئية
1. عمليات «اليوم الثاني»: الحلم انتهى، الواقع يبدأ
يعد إنشاء مجموعة Kubernetes هو الجزء السهل («اليوم 1"). يبدأ الكابوس الرئيسي بعمليات «اليوم الثاني». الحفاظ على تحديث المجموعة وإدارة عمليات تدوير الشهادات وعدم توافق الإصدارات وتعطل العقد...
- تكلفة الموارد البشرية: إدارة K8s هي وظيفة بدوام كامل في حد ذاتها. هل تتمثل مهمة المطورين في كتابة التعليمات البرمجية، أو تصحيح سبب عدم قيام Ingress Controller بتوجيه حركة المرور؟
- تسرب التجريد: يقولون إن أجهزة K8 مجردة ولكنها كذبة. في اللحظة التي تقوم فيها بتعيين حدود وحدة المعالجة المركزية («الطلبات» و «الحدود») بشكل غير صحيح، يموت التطبيق الخاص بك بصمت بسبب الخطأ «OOMkilled » (نفاد الذاكرة).
- الشبكات: الاتصال بين PODs وشبكة الخدمة ومكونات CNI... يمكن أن يتحول طلب HTTP البسيط فجأة إلى مشكلة هندسة شبكة مستعصية .
2. التطوير القائم على السيرة الذاتية
عندما أدخل شركة كخبير متشكك، فإن أول شيء أنظر إليه هو: هل كانت هذه البنية مفروضة بمتطلبات الوظيفة، أم أنها رغبة المهندسين في كتابة «Kubernetes Expert» على سيرتهم الذاتية؟
إذا كان تطبيقك مناسبًا لخادم افتراضي واحد (VM) وقمت بتقسيمه إلى مجموعة K8s المكونة من 3 عقد، فإن الشيء الوحيد الذي تحله هو غرورك، وليس المشكلةالتقنية
3. الثغرات الأمنية الناتجة عن التعقيد
التعقيد هو العدو الأول للأمن. عادةً ما تكون إعدادات Kubernetes الافتراضية «موجهة نحو العمل» وليست «آمنة»
. تشغيلحاوية Docker بسلطة الجذر، أو تجاوز إدارة الأسرار (التشفير وما إلى ذلك)، أو قواعد RBAC (التحكم في الوصول المستند إلى الأدوار) التي تم تكوينها بشكل غير صحيح... بالنسبة للقراصنة، تعد K8s متنزهًا ترفيهيًا عند تكوينها بشكل غير صحيح. لضمان سلامة K8s، تحتاج إلى أدوات إضافية (تريفي، فالكو، وما إلى ذلك) ووقت إضافي لإدارتها.
4. متى تكون K8s، متى تكون PaaS؟
لذا، هل يجب علينا التخلص من Kubernetes؟ لا. دعونا فقط نعثر على الظفر الصحيح.
- Microservice Hell: إذا كان لديك حقًا أكثر من 50 خدمة مصغرة لإدارتها، وتتحدث بشكل مكثف مع بعضها البعض، فإن K8s هي المنقذ.
- التطبيقات المتجانسة: إذا كان لديك تطبيق مترابط، فإن تخصيصه وتشغيله على نظام PaaS بسيط (Heroku، ومنصة تطبيقات DigitalOcean، وما إلى ذلك) أو خدمة الحاويات المُدارة (AWS ECS) سيكلفك عبئًا تشغيليًا أقل بنسبة 80٪.