الكهانة

لعبت Kubernetes بالفعل دوراً هاماً في عملي ، وفي المستقبل سوف يصبح أكثر أهمية. لكن عام 2018 يقترب من نهايته ، لذلك انسوا التواضع واعملوا على التنبؤ الجريء:

مستقبل Kubernetes هو الأجهزة الافتراضية ، وليس الحاويات

وفقا للبرج الصيني ، كان عام 2018 عام الكلب ، ولكن في التكنولوجيا كان عام Kubernetes. يتعلم الكثيرون الآن هذه التكنولوجيا الثورية ، وتحاول أقسام تكنولوجيا المعلومات في كل مكان تطوير "استراتيجية Kubernetes" [1]. نقلت بعض المنظمات بالفعل أعباء عمل كبيرة إلى Kubernetes.

[1] إذا كنت تحاول تطوير استراتيجية Kubernetes ، فقد فشلت بالفعل ، ولكن هذا موضوع لمقال آخر.

بمعنى آخر ، يوجد الكثير من الأشخاص في Kubernetes في كل خطوة من "Gartner Sensation Cycle". عالقون في جوف من خيبة الأمل أو غرقوا في حفرة من اليأس.


جيريميكب ، ويكيبيديا . المشاع الإبداعي CC BY-SA 3.0

أنا معجب كبير بالحاويات ولن أقول إن الحاويات قد ماتت . في عام 2013 ، قدم لنا Docker غلافًا لـ Linux Containers: طريقة جديدة مذهلة لإنشاء التطبيقات وحزمها ومشاركتها ونشرها. بدا في الوقت المناسب ، حيث بدأنا نأخذ على محمل الجد التسليم المستمر. أصبح نموذجهم مثاليًا لسلسلة التسليم وساهم في ظهور منصة PaaS ، ثم CaaS.



رأى مهندسو Google أن مجتمع تكنولوجيا المعلومات جاهز أخيرًا للحاويات. تستخدم Google حاويات لفترة طويلة جدًا ، وبمعنى ما ، يمكن اعتبارها مخترعين للحاويات. بدأوا تطوير Kubernetes. كما تعلم الآن ، هذا هو التناسخ المجاني لمنصة Borg الخاصة بـ Google.

قريبًا ، تم توفير الدعم لـ Kubernetes من خلال جميع السحب الكبيرة (GKE ، AKS ، EKS). كما أدت الخدمات المحلية إلى رفع المنصات استنادًا إلى Kubernetes (Pivotal Container Service ، Openshift ، وما إلى ذلك).

لينة متعددة الإيجار

كان من الضروري حل مشكلة مزعجة واحدة ، والتي يمكن اعتبارها نقص في الحاويات ... هذا متعدد الإيجار.

لم يتم إنشاء حاويات Linux كصناديق رمل آمنة (مثل Solaris Zones أو FreeBSD Jails). بدلاً من ذلك ، اعتمدوا على نموذج kernel شائع يستخدم وظائف kernel لتوفير عزل أساسي للعملية. كما قال جيسي فرازيل ، "الحاويات ليست هي الشيء الحقيقي".


ومما يضاعف ذلك حقيقة أن معظم مكونات Kubernetes ليست على علم بالمستأجرين. بالطبع ، لديك مساحات أسماء وسياسات أمان Pod ، ولكن لا يوجد شيء من هذا القبيل في API. وكذلك في المكونات الداخلية مثل kubelet أو kube-proxy . وهذا يؤدي إلى حقيقة أن Kubernetes تنفذ نموذج "الإيجار المريح" (الإيجار الناعم).


Kubernetes العمارة

التجريدات تتسرب أكثر. منصة على رأس الحاويات ترث العديد من جوانب الإيجار الناعم. تكتسب المنصات الموجودة أعلى الأجهزة الافتراضية متعددة المستأجرين هذا الإيجار الصعب (VMware وخدمات Amazon Web و OpenStack وما إلى ذلك).

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

بعض توزيعات Kubernetes ، مثل Pivotal Container Service (PKS) ، تدرك جيدًا مشكلة الإيجار هذه وتستخدم نموذجًا مشابهًا ، وتقدم نفس Kubernetes كخدمة يمكن الحصول عليها من سحابة عامة ، ولكن في مركز البيانات الخاص بك.

وقد أدى ذلك إلى ظهور نموذج "العديد من المجموعات" ، بدلاً من "مجموعة واحدة كبيرة مشتركة". غالبًا ما يكون لدى عملاء GKE من Google العشرات من مجموعات Kubernetes المنتشرة في فرق متعددة. غالبًا ما يحصل كل مطور على مجموعة خاصة به. ينشئ هذا السلوك عددًا مروعًا من الحالات (Kubesprawl).

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

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

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

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

أجهزة VM صغيرة جدًا مُحسّنة للسرعة ...

Kata Containers عبارة عن مشروع مفتوح المصدر يعمل فيه المجتمع لإنشاء تطبيق قياسي للأجهزة الافتراضية خفيفة الوزن التي تبدو وتعمل مثل الحاويات ولكنها توفر عزلًا عن عبء العمل وفوائد أمان VM.

يقترح جيسي استخدام تقنية حاوية VM ، مثل حاويات Kata . أنها توفر العزلة مستوى VM ، ولكن العمل مثل الحاويات. يتيح ذلك لـ Kubernetes منح كل "مستأجر" (نفترض المستأجر في مساحة الاسم) مجموعته الخاصة من خدمات نظام Kubernetes التي تعمل في حاويات VM متداخلة (حاوية VM داخل الجهاز الظاهري الذي توفره بنية IaaS الأساسية).


صورة جيسي فريسل: من الصعب الاستئجار في Kubernetes

هذا هو حل Kubernetes متعدد الاستئجار الأنيق. يذهب اقتراحها إلى أبعد من ذلك لكي تستخدم Kubernetes حاويات VM المتداخلة لأعباء العمل (Pods) التي تعمل على Kubernetes ، مما يوفر زيادة كبيرة في استخدام الموارد.

لدينا على الأقل تحسين واحد آخر. قم بإنشاء برنامج Hypervisor المناسب لموفر البنية التحتية الأساسي أو المزود السحابي. إذا كانت حاوية VM عبارة عن تجريد من المستوى الأول تم توفيره بواسطة IaaS ، فسنزيد من استخدام الموارد. يتم تقليل الحد الأدنى لعدد VMs لبدء كتلة Kubernetes إلى جهاز واحد (أو ثلاثة من أجل HA) لاستضافة نظام إدارة Kubernetes ، والذي يتوفر لـ "المستخدم الخارق".

الاستئجار الأمثل للموارد (التكلفة)

سيبدو نشر Kubernetes مع مساحات اسماء وعدة تطبيقات قيد التشغيل مثل هذا:

ملاحظة: هناك كميات أخرى على نفس بنية IaaS الأساسية. نظرًا لأن هذه عبارة عن حاويات VM ، فإنها تتمتع بنفس مستوى العزل مثل VMs السحابية التقليدية. لذلك ، يمكنهم العمل على نفس برنامج Hypervisor بأقل قدر من المخاطر.

في البداية ، لا يتم نشر أي بنية تحتية في السحابة ، لذلك بالنسبة للمستخدم الخارق ، تكون التكاليف صفرية.

يطلب الخارق كتلة Kubernetes من السحابة. يقوم موفر الخدمة السحابية بإنشاء جهاز ظاهري به حاوية واحدة (أو ثلاثة من أجل HA) يقوم بتشغيل واجهات برمجة التطبيقات Kubernetes الأساسية وخدمات النظام. يمكن للمستخدم الخارق نشر وحدات في مساحة اسم النظام أو إنشاء مساحات جديدة لتفويض الوصول إلى المستخدمين الآخرين.

Superuser يخلق مساحات أسماء اثنين foo bar . تطلب Kubernetes حاويتين VM من السحابة لكل مستوى من مستويات إدارة مساحة الاسم (Kubernetes API وخدمات النظام). يقوم المستخدم الخارق بتفويض الوصول إلى مساحات الأسماء هذه لبعض المستخدمين ، ويقوم كل منهم بتشغيل بعض أعباء العمل (الوحدات النمطية) ، وتطلب حاويات VM هذه الحاويات لأعباء العمل هذه.

في جميع المراحل ، يدفع المستخدم الخارق الموارد المستهلكة بالفعل فقط. يتحكم موفر الخدمة السحابية في هذه الموارد وهي متاحة لأي مستخدم سحابي.

أنا لا أقول أي شيء جديد ...

يعمل مزودو الخدمة السحابية بالفعل في هذا الاتجاه. يمكنك التحقق من ذلك من خلال مشاهدة أحداث المجتمع (ربما قامت Amazon بالفعل بهذا بهدوء مع Fargate).

النصيحة الأولى هي Virtual Kubelet ، وهي أداة مفتوحة المصدر مصممة لإخفاء kubelet. يربط Kubernetes بواجهات برمجة التطبيقات الأخرى ، مما يسمح Kubernetes بطلب حاويات VM من جدولة قياسية في السحابة.

تلميحات أخرى هي عدد كبير من التقنيات الجديدة لحاويات VM ، مثل حاويات Kata المذكورة بالفعل ، وكذلك Amazon's Firecracker ومستشار Google.

الخاتمة

إذا قمت بتنفيذ التحسينات بشكل صحيح في نموذج الإيجار الصعب ، فستجد المحاكاة الافتراضية لـ Holy Grail of Kubernetes. عزل كامل لأعباء العمل وبدون تكاليف إضافية.

إذا لم تستخدم السحابة العامة ، فستظل تحصل على فوائد استخدام الموارد الأعلى ، والذي يؤتي ثماره مع انخفاض متطلبات الأجهزة.

دعنا نأمل أن يولي VMware و OpenStack اهتمامًا وأن يطلقا برامج مراقبة تعتمد على حاويات VM خفيفة الوزن وتطبيقات Virtual Kubelet المقابلة.