Kubernetes ، والشبكات ، والعثور على برنامج VMware الخاص بـ Cloud Native

توماس جراف هو الشريك المؤسس والمدير التقني لشركة متساوي، ومنشئ تقنية شبكات مفتوحة المصدر (وسحابة أصلية) معروفة تسمى كيليوم. تم بناء Cilium فوق تقنية Linux على مستوى kernel تسمى eGMP.

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

---

المستقبل: كيف يجب أن نفكر في eBPF و Cilium في سياق الحوسبة والشبكات ، بشكل عام ، ثم على وجه التحديد في سياق النظام البيئي السحابي الأصلي?

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

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

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

وشبكة Cilium Service Mesh ، التي تم إطلاقها للتو ، هي تطور لهذه القدرات؟

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

تطلق شركة Gartner على هذه الطبقة الجديدة اسم "اتصال الخدمة" - سنرى ما إذا كان هذا المصطلح يمسك - ولكنه في الأساس طبقة تتضمن قطعة شبكة المؤسسة وقطعة شبكة الخدمة التي تأتي من فرق التطبيق. ولأن هذا هو ما يطلبه العملاء ، فقد أضفنا القدرات إلى Cilium نفسها. لذلك ، بشكل أساسي ، تتجه Cilium إلى أعلى من جانب شبكة المؤسسة وتتجه شبكات الخدمة إلى الأسفل إلى جانب الشبكات.

لماذا يوجد الكثير من التركيز على مستوى الشبكات والخدمات المتشابكة لمكدس Kubernetes؟

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

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

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

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

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

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

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

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

ماذا عن فكرة أن Kubernetes لا تزال بحاجة إلى تجربة مطور أفضل؟

إذا نظرنا إلى OpenShift الأصلي ، قبل إعادة تأسيسه على Kubernetes ، فقد كان هذا. لقد كانت أقرب إلى فريق التطبيق وكانت تجربة مطور تطبيقات أفضل. يمكنك الدفع إلى Git وسيتم نشره تلقائيًا. جرب Heroku أيضًا هذا ، لكن القائم على SaaS. 

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

أود أن أقول إن أكبر خطوة بين Docker و Kubernetes كانت أن Docker كان يدور حول تجربة المطور. تم حل هذا الجزء ، لكنه لم يحل جزء النظام البيئي للسحابة العامة.

كيف وصلنا إلى هذه النقطة؟ هل كان هذا التطور الطبيعي من النظام الأساسي كخدمة (PaaS) وحاويات التطبيق؟

كانت صور Docker وجانب التعبئة والتغليف لـ Docker. كانت المدرسة القديمة هي كيفية النشر في الأجهزة الافتراضية ، وكان هناك كل أنواع الأتمتة حول ذلك. ثم كان هناك ما كان Facebook يفعله مع Tupperware - مصمم خصيصًا جدًا وعلى نطاق واسع حقًا. ثم جاء Docker وقدم بشكل أساسي صورة الحاوية هذه ويمكن للجميع التعامل معها مثل جهاز افتراضي مصغر. يمكنني الآن توزيع تطبيقي وبدلاً من صورة افتراضية 600 ميغا بايت ، أصبح الآن حاوية 10 ميغا بايت. لكن يمكنك معاملته بنفس الطريقة ، فهو يحتوي على كل ما يحتاجه. 

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

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

من ترى تشغيل Kubernetes داخل الشركات؟ هل هي فرق التطبيق الفردية؟

هناك تحول مثير للاهتمام حدث مع السحابة الأصلية ، وهو أن لدينا صعود "فريق النظام الأساسي" ، سأطلق عليه. إنهم ليسوا مهندسي تطبيقات. لديهم القليل من المعرفة بعمليات الشبكة ولديهم قدر كبير من المعرفة الأمنية. لديهم معرفة SRE ويعرفون كيفية القيام بالأتمتة السحابية. إنهم يوفرون النظام الأساسي لفرق التطبيق ، ويعاملون فرق التطبيق هذه كعملائهم.

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

أعتقد أن هناك بالتأكيد مساحة للعمل بدون خادم ، ولا سيما لتطوير التطبيقات بسرعة كبيرة. ولكن في المؤسسات ، نرى أن السحابة الأصلية هي الطبقة الجديدة فوق الافتراضية

هل هذا مشتر جديد أم فريق جديد؟ أم أن فرق النظام الأساسي تشبه شيئًا ما موجودًا داخل أماكن مثل Google أو Facebook وتنتقل الآن إلى التيار الرئيسي؟

إنهم في الغالب فريق جديد. أعتقد أنهم ، إلى حد ما ، مثل فرق SRE في Google و Facebook. ومع ذلك ، من المحتمل أن تمتلك فرق التطبيقات المزيد من نشر التطبيقات في المؤسسات ، لأن المؤسسات لا تملك هذا التمييز الواضح جدًا بين مهندسي البرمجيات و SREs مثل Google و Facebook. أود أن أقول إن هذا التطور مشابه جدًا لكيفية وجود فرق افتراضية لديك ، ومن ثم تم ترحيل الكثير من عمليات الشبكة من - أو تطورت أو متقدمة من - كونها تتعلق بالشبكة خردوات أن تكون حول الشبكة الافتراضية. وهذه الفرق ، على سبيل المثال ، بدأت في تشغيل VMware NSX. نفس الشيء يحدث هنا. 

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

كيف ترى ال مؤسسة الحوسبة السحابية الأصلية تتطور ، وهل ستكون Kubernetes دائمًا في مركزها - أم في حركة السحابة الأصلية بشكل عام؟

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

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

نحن نشهد طلبًا قويًا للغاية للاستمرار في الاتصال بالعالم القديم والتحدث عن MPLS و VLAN و sFlow و NetFlow - المجموعة الكاملة الحالية من متطلبات المؤسسة. لم يذهب أي منهم بعيدا.

بعد حوالي عقد من الزمان ، لا يبدو أن مساحة السحابة الأصلية بدعة. ما مقدار المساحة المتاحة لمواصلة التطور؟

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

أعتقد أن هناك بالتأكيد مساحة للعمل بدون خادم ، ولا سيما لتطوير التطبيقات بسرعة كبيرة. ولكن في المؤسسات ، نرى أن السحابة أصلية هي الطبقة الجديدة أعلى المحاكاة الافتراضية ، ونعتقد أن لها نفس العمر الافتراضي للافتراضية. مما يعني أننا في بداية الترحيل المحلي عبر السحابة.

ما هي المشاكل الكبيرة التي لا تزال بحاجة إلى حل على مستوى البنية التحتية؟

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

إذن هذا هو التحدي الكبير التالي: من سيكون تلك الطبقة الحيادية للسحابة المتعددة والسحابة الأصلية ، مثل ما أصبح VMware؟ من سيكون برنامج VMware للسحابة الأصلية؟

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

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

الجزء الصعب هو أن فرق التطبيقات الحديثة معتادة على تطوير طبقة البنية التحتية بأسرع ما يمكن. وهذا أجبر طبقة البنية التحتية على أن تكون أكثر قابلية للبرمجة وأكثر قابلية للتعديل. لهذا السبب نرى بالفعل طبقة شبكة وطبقة أمان أعلى طبقة الشبكات السحابية. ولكن الآن لدينا شركات قادمة ، ونحن نشهد طلبًا قويًا للغاية للاستمرار في الاتصال بالعالم القديم والتحدث عن MPLS و VLAN و sFlow و NetFlow - المجموعة الكاملة الحالية من متطلبات المؤسسة. لم يختف أي منهم ، ولا تزال جميع قواعد الامتثال كما هي. و حتى أن بعض شركات SaaS الحديثة تواجه الآن هذه التحديات لأنها تنمو بشكل أكبر وتهتم بالامتثال وما إلى ذلك وهلم جرا. 

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

من أين تأتي الموجة التالية من الابتكار المحلي السحابي؟ هل ما زالت تأتي من شركة مثل Google ، أم أن هناك نوعًا جديدًا من الشركات يتولى المسؤولية؟

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

تم النشر في 26 يوليو 2022