تاريخ Kubernetes

عندما يتعلق الأمر بالبنية التحتية الحديثة لتكنولوجيا المعلومات—لا يمكن التقليل من دور Kubernetes—منصة تنسيق الحاويات مفتوحة المصدر التي تعمل على أتمتة نشر تطبيقات (apps) وخدمات البرامج المعبأة في حاويات وإدارتها وتوسيع نطاقها.

وفقًا لتقرير صادر عن مؤسسة الحوسبة السحابية الأصلية (CNCF) (يوجد الرابط خارج موقع ibm.com)، تعد Kubernetes هي ثاني أكبر مشروع مفتوح المصدر في العالم بعد Linux وأداة تنسيق الحاويات الأساسية لـ 71% من شركات Fortune 100. ولفهم كيف سيطرت Kubernetes على أسواق الحوسبة السحابية والخدمات المصغرة، علينا دراسة تاريخها.

يعود تاريخ Kubernetes، الذي يأتي اسمه من الكلمة اليونانية القديمة التي تعني "الربان أو قائد الدفة" (الشخص الذي يقود السفينة) إلى عام 2013 عندما طرح ثلاثي من المهندسين في Google-كريج مكلوكي وجو بيدا وبريندان بيرنز-فكرة بناء نظام إدارة حاويات مفتوح المصدر. كان رواد التقنية هؤلاء يبحثون عن طرق لجلب خبرة البنية التحتية الداخلية لشركة Google إلى عالم الحوسبة السحابية واسعة النطاق وأيضا تمكين Google من التنافس مع Amazon Web Services (AWS)-الشركة الرائدة التي لا مثيل لها بين مزودي الخدمات السحابية في ذلك الوقت.

البنية التحتية التقليدية لتكنولوجيا المعلومات مقابل البنية التحتية الافتراضية لتكنولوجيا المعلومات

ولكن لفهم تاريخ Kubernetes حقًا-والذي يُشار إليه غالبًا باسم "Kube" أو "K8s"، وهو "اسم رقمي " (يوجد الرابط خارج ibm.com)-يتعين علينا النظر إلى الحاويات في سياق البنية التحتية لتقنية المعلومات التقليدية مقابل البنية التحتية لتقنية المعلومات الافتراضية.

في الماضي، كانت المنظمات تدير تطبيقاتها فقط على الخوادم المادية (المعروفة أيضًا باسم Bare Metal Server). ومع ذلك، لم تكن هناك طريقة للحفاظ على حدود موارد النظام لتلك التطبيقات. على سبيل المثال، عندما يقوم خادم فعلي بتشغيل تطبيقات متعددة، فقد يستهلك تطبيق واحد كل طاقة المعالجة أو الذاكرة أو مساحة التخزين أو الموارد الأخرى على هذا الخادم. ولمنع حدوث ذلك، ستقوم الشركات بتشغيل كل تطبيق على خادم فعلي مختلف. لكن تشغيل التطبيقات على خوادم متعددة يُنشئ موارد غير مستغلة ومشاكل في عدم القدرة على التوسع. وعلاوة على ذلك، فإن امتلاك عدد كبير من الآلات المادية يشغل مساحة وهو مسعى مكلف.

المحاكاة الافتراضية

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

تعتمد المحاكاة الافتراضية على برنامج يُعرف باسم مراقب الأجهزة الافتراضية. ومراقب الأجهزة الافتراضية هو شكل خفيف الوزن من البرامج التي تمكن العديد من الأجهزة الافتراضية (VM) من العمل على وحدة المعالجة المركزية (CPU) لخادم مادي واحد. كل جهاز افتراضي يحتوي على نظام تشغيل ضيف (OS)، ونسخة افتراضية من المكونات المادية اللازمة لتشغيل النظام التشغيلي  وتطبيقه ومكتباته المرتبطة  وتبعياته. 

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

الحاويات

أدخل تقنية الحاوية. حدثت علامة تاريخيًا في تطوير الحاويات في عام 1979 مع تطوير chroot (يوجد الرابط خارج ibm.com)، وهو جزء من نظام التشغيل Unix الإصدار 7. حيث قدم Chroot مفهوم عزل العملية عن طريق تقييد وصول ملف التطبيق إلى دليل معين (الجذر) وتوابعه (أو العمليات الفرعية).

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

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

في أوائل العقد الأول من القرن الحادي والعشرين، احتاجت Google إلى طريقة للحصول على أفضل أداء من Virtual Servers لدعم بنيتها التحتية المتنامية وتقديم منصة السحابة العامة الخاصة بها. وقد أدى ذلك إلى إنشاء Borg، أول نظام موحد لإدارة الحاويات. تم تطوير نظام Borg بين عامي 2003 و2004، وتم تسميته على اسم مجموعة من الكائنات الفضائية في ستار تريك —the Borg—وهي كائنات سيبرانية تعمل من خلال مشاركة عقل خلية (وعي جماعي) يسمى "The Collective".

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

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

في عام 2013، قدمت Google منصة Omega، وهو نظام إدارة الحاويات من الجيل الثاني. أخذت Omega نظام Borg البنائي إلى أبعد من ذلك، حيث وفرت حل جدولة مرن وقابل للتطوير لمجموعات الكمبيوتر واسعة النطاق. ثم في عام 2013، ظهرت في الصورة Docker، وتمثل أحد اللاعبين الرئيسيين في تاريخ Kubernetes.

تم تطوير Docker من قِبل شركة dotCloud، وهي شركة تكنولوجيا المنصة كخدمة (PaaS)، وتم إصدار Docker في عام 2013 كأداة برمجية مفتوحة المصدر تسمح لمطوري البرامج عبر الإنترنت ببناء ونشر وإدارة التطبيقات المعبأة في حاويات.

تستخدم تقنية حاوية Docker نواة Linux (المكون الأساسي لنظام التشغيل) وميزات النواة لفصل العمليات بحيث يمكن تشغيلها بشكل مستقل. ولإزالة أي لبس، يشير اسم Docker أيضًا إلى شركة Docker, Inc. (المعروفة سابقًا باسم dotCloud، الرابط موجود خارج ibm.com)، التي تطور أدوات إنتاجية مبنية حول منصة الحاويات مفتوحة المصدر الخاصة بها، بالإضافة إلى نظام Docker البنائي والمجتمع مفتوح المصدر (الرابط موجود خارج ibm.com).

من خلال تعميم وقت تشغيل حاوية خفيف الوزن وتوفير طريقة بسيطة لحزم التطبيقات وتوزيعها ونشرها على الجهاز، قدمت Docker الأساس أو الإلهام لمؤسسي Kubernetes. وعندما ظهرت Docker على الساحة، كان موظفو Google Craig McLuckie وJoe Beda وBrendan Burns متحمسين لقدرة Docker على بناء حاويات فردية وتشغيلها على أجهزة فردية.

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

عمل العديد من مطوري Kubernetes على تطوير Borg وأرادوا بناء منسق حاويات يتضمن كل ما تعلموه من خلال تصميم نظامي Borg وOmega وتطويرهما لإنتاج أداة مفتوحة المصدر أقل تعقيدًا مع واجهة سهلة الاستخدام (UI). وكنوع من الحنين إلى Borg، أطلقوا عليها اسم مشروع Seven of Nine تيمنًا بشخصية Star Trek: Voyager التي كانت عبارة عن طائرة Borg بدون طيار. وعلى الرغم من عدم استمرار اسم المشروع الأصلي، فقد تم تخليد ذكراه من خلال النقاط السبع الموجودة على شعار Kubernetes (يوجد الرابط خارج موقع ibm.com).

تعتمد بنية Kubernetes على تشغيل المجموعات التي تسمح بتشغيل الحاويات عبر أجهزة وبيئات متعددة. تتكون كل مجموعة عادةً من فئتين من العقد:

• العُقد العاملة، والتي تقوم بتشغيل التطبيقات الموضوعة في حاويات.
• عُقد مستوى التحكم، التي تتحكم في المجموعة.

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

في عام 2014، ظهرت Kubernetes لأول مرة كإصدار مفتوح المصدر من Borg، حيث وقعت Microsoft وRedHat وIBM وDocker كأعضاء في مجتمع Kubernetes في وقت مبكر. تضمنت الأداة البرمجية ميزات أساسية لتنسيق الحاويات، بما في ذلك ما يلي:

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

في عام 2015، في مؤتمر O'Reilly Open Source Convention (OSCON) (يوجد الرابط خارج موقع ibm.com)، كشف مؤسسو Kubernetes عن نسخة موسعة ومحسنة من Kubernetes-Kubernetes 1.0. بعد فترة وجيزة، انضم مطورون من فريق Red Hat OpenShift إلى فريق Google، حيث قدموا خبراتهم الهندسية والمؤسسية للمشروع.

تزامنًا مع إصدار Kubernetes 1.0 في عام 2015، تبرعت Google بـ Kubernetes إلى مؤسسة Cloud Native Computing Foundation (CNCF) (يوجد الرابط خارج ibm.com)، وهي جزء من مؤسسة Linux Foundation غير الربحية. تم إنشاء منتدى CNCF بالاشتراك بين كثيرٍ من أعضاء شركات الحوسبة الرائدة في العالم، بما في ذلك Docker وGoogle وMicrosoft وIBM وRed Hat. تتمثل مهمة CNCF (يوجد الرابط خارج موقع ibm.com) في "جعل الحوسبة السحابية الأصلية متاحة في كل مكان".

في عام 2016، أصبحت Kubernetes أول مشروع مستضاف لـ CNCF، وبحلول عام 2018، كانت Kubernetes أول مشروع تخرج من CNCF. وارتفع عدد الشركات المساهمة بنشاط بسرعة إلى أكثر من 700 عضو، وسرعان ما أصبحت Kubernetes أحد أسرع المشاريع مفتوحة المصدر نموًا في التاريخ. وبحلول عام 2017، كانت تتفوق على منافسين مثل Docker Swarm وApache Mesos لتصبح معيار الصناعة لتنسيق الحاويات.

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

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

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

منذ انضمام Kubernetes إلى CNCF في عام 2016، ارتفع عدد المساهمين إلى 8012،-أي بزيادة قدرها 996% (يوجد الرابط خارج ibm.com). يجذب المؤتمر العالمي الرائد لـ CNCF، KubeCon + CloudNativeCon (الرابط موجود خارج ibm.com)، آلاف الحضور ويوفر  منتدىً سنويًا لتقديم المعلومات والمعارف للمطورين والمستخدمين بشأن Kubernetes واتجاهات  عمليات التطوير الأخرى.

على وجهات التحول السحابي وتحديث التطبيقات ، لا تُظهر عملية اعتماد Kubernetes أي علامات على التباطؤ. ووفقًا لتقرير صادر عن شركة Gartner بعنوان دليل مسؤولي التقنية حول الحاويات ومنصة Kubernetes (يوجد الرابط خارج موقع ibm.com)، فإن أكثر من 90% من منظمات العالم ستشغل تطبيقات مُعبأة في حاويات في الإنتاج بحلول عام 2027.

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

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

توفر Red Hat OpenShift on IBM Cloud لمطوري OpenShift طريقة سريعة وآمنة لتعبئة أحمال تشغيل المؤسسات في مجموعات Kubernetes ونشرها.

تتيح لك IBM Cloud Code Engine، وهي منصة خالية من الخوادم، مُدارة بالكامل، إمكانية تشغيل الحاوية أو التعليمات البرمجية للتطبيق أو مهمة مجمعة في وقت تشغيل حاوية مُدار بالكامل.