‫إذن ، ما هي الخطوة التالية لـ Kubernetes؟
‫أعتقد أن هذا سؤال يطرحه الكثير منا
‫عندما ننظر في مدى سرعة نموه ، والنظام البيئي بأكمله
‫من حوله ، وكيف أن هذا كثير جدًا على أي شخص
‫للتعامل معه.
‫ما هو المستقبل؟
‫حسنًا ، الخبر السار هو أنه إذا كان علي توقع
‫ذلك ، أعتقد أن المستقبل يجب أن يبدأ في الشعور
‫بالملل. ستسمع الكثير من المؤسسين يتحدثون عن
‫هذا كلما رأيتهم في الأماكن العامة.
‫كما تعلم ، سيتحدثون فقط عن حاجتنا لجعل البنية
‫التحتية مملة قدر الإمكان حتى نتمكن من
‫الاعتماد أكثر على الأشياء التي نقوم
‫بها فوق ذلك. لأنه حقًا ، كل هذا موجود هنا فقط حتى نتمكن من نشر
‫تطبيقاتنا هناك ، بشكل صحيح.
‫ليس الهدف من Kubernetes أن يكون Kubernetes نفسه.
‫إنه يسمح لك بالقيام بالأشياء التي تريد القيام بها بشكل أسرع.
‫أعتقد أنه بالنسبة لـ Kubernetes ،
‫إذا نظرت إلى الإصدارات القليلة الماضية
‫، فقد بدأت بالفعل في التركيز على الموثوقية
‫، والاستقرار ، والأمان ، واستقرت بشكل أساسي لدرجة
‫أنها موجودة فقط.
‫لا داعي للقلق بشأن ذلك كثيرًا.
‫ليس عليك إصلاحه كثيرًا.
‫لديهم إصدارات منتظمة ، لذلك يمكنك بالتأكيد
‫التحقق من جدول الإصدار وملاحظات الإصدار ، التي
‫ربطتها في هذا الفيديو.
‫الشيء الوحيد الذي حدث هذا العام ، في عام 2019 ، كان تدقيقًا أمنيًا
‫كبيرًا للكثير من التعليمات البرمجية الأساسية
‫والذي كشف عن الكثير من الأشياء.
‫في الواقع ، لديهم في مدونتهم تحليل كامل
‫ومفصل لما حدث.
‫أعتقد أنه من الرائع حقًا أن مشروعًا مفتوح المصدر
‫على نفس القدر من الأهمية والكبر ، لم يقم فقط بتحليل
‫الأمان من طرف ثالث ، ولكنه كشف عن جميع المشكلات والنتائج المحتملة.
‫أعتقد أنه نتج عنه الكثير من العلاقات العامة التي كانت مقدمة
‫لإصلاح الأشياء بسرعة ، ولكن أيضًا بعض الأشياء التي سيتم إصلاحها
‫في النهاية بمرور الوقت.
‫لا يتعلق الأمر بالضرورة بالضعف ، ولكن يمكن
‫تحسين المزيد من هذه المنطقة لذلك سنقوم بتغييرها
‫بمرور الوقت.
‫شيء آخر ستراه هو أن بعض هذه المفاهيم القديمة
‫، عندما كانت أداة أبسط ، ستبدأ في التلاشي بمجرد
‫إزالتها. أعتقد أن مكونات التخزين الإضافية
‫التي ليست CSI سيتم سحبها في النهاية بحيث يتعين عليك الاعتماد
‫على CSI لمكونات التخزين الإضافية بدلاً من العناصر
‫المضمنة.
‫سترى أوامر مختلفة مثل kubectl run change
‫وتتوقف عن إعطائنا تحذيرات لأنها ستتحول
‫إلى عداء بسيط بدلاً من إنشاء جميع المولدات خارج
‫الصندوق.
‫ثم سترى أشياء أخرى ذكرتها هنا ، مثل التشغيل
‫الجاف من جانب الخدمة ، والحصول على الاستقرار والمزيد
‫من الميزات من حوله. لأنني أعتقد أن هناك دفعة
‫قوية من أجل تدقيق أفضل وفهم أفضل للتغيير
‫بمرور الوقت. ما الذي سيتغير قبل أن أفعل ذلك
‫، وما الذي تغير بعد أن فعلت ذلك ، وتلك الأنواع من
‫مقاييس إعداد التقارير.
‫عندما يتعلق الأمر بطرف ثالث ، سيستمر ذلك
‫في التضخم والنمو ، وهو حقًا أكثر مما يمكن لأي
‫منا أن يعرفه.
‫خوذة 3. 0 على وشك الانتهاء.
‫سيكون لدينا بالتأكيد المزيد من المشغلين الذين سيكونون
‫لأدوات الجهات الخارجية لتسهيل نشرهم وإدارتهم
‫في Kubernetes.
‫هذا حقًا أمل أكثر ، لكنني أعتقد
‫أننا سنركز أكثر على مهام سير العمل
‫التقريري.
‫لأن هذا الموضوع الجديد حول DevOps ، وبشكل أكثر تحديدًا git-ops
‫، هذا هو git ops ، الذي تحدثت
‫عنه في البودكاست الخاص بي.
‫يعد سير عمل git-ops مفهومًا جديدًا نسبيًا ، ولكن الفكرة القائلة
‫بأننا نحن المشغلين ، وهم الأشخاص
‫الذين يديرون مجموعات Kubernetes هذه
‫، نحن بالفعل نعمل كمشغلين.
‫يأخذ المشغلون التطورات من فرق البرامج حيث اضطروا
‫إلى إدارة التعليمات البرمجية وتغيير
‫الكود بمرور الوقت والإصدارات ، والتي أدت إلى ظهور أدوات
‫مثل GitHub ، حقًا ، لاستخدام هذه الأدوات نفسها
‫لإدارة بنيتنا التحتية في بطريقة تصريحية.
‫لقد سمعتني أتحدث عن ذلك.
‫أعتقد أنه عندما تنظر إلى الميزة التي تم تعيينها
‫بمرور الوقت لـ Kubernetes ، يمكنك أن ترى
‫كيف أصبحت أكثر وضوحًا في الأسلوب ، وأن مجموعة الميزات والتركيز ينصب
‫على سير العمل التعريفي.
‫آمل أن نحصل على أدوات أفضل والأدوات التي لدينا
‫ستحصل على المزيد من الميزات بمرور الوقت.
‫شيء كبير آخر هنا هو دعم Windows Server.
‫شهد عام 2019 الإعلان الكبير
‫حول دعم Windows Server لخادم
‫2019 ، وهذا في بدايته.
‫هذا شيء يتفوق عليه Swarm تقنيًا من Kubernetes.
‫حيث يتمتع Docker و Swarm بدعم Windows Server لسنوات حتى
‫الآن ، وقد تم تحسينه بالتأكيد بمرور الوقت.
‫لكنهم بدأوا ذلك مع Server 2016 ودفعوا ذلك إلى
‫الأمام وجعلوه أفضل.
‫وحيث إن Kubernetes الآن في Windows Server
‫2019 يقول حقًا أنهم يتمتعون بالدعم.
‫من الأشخاص الذين سمعت أنهم يتحدثون عن Server
‫في الإنتاج ، لا يزال بإمكان Windows Server استخدام
‫الكثير من العمل في عالم Kubernetes ليكون مساويًا لنظام
‫Linux. لذلك ، أعتقد أن هذا سيكون
‫مجالًا كبيرًا للتركيز حيث تتبنى المزيد من شركات Windows
‫منظمي الحاويات هؤلاء.
‫الأشياء القليلة الأخيرة هنا هي بالتأكيد سيتم العمل
‫على حالات Edge.
‫أشياء مثل التعلم الآلي.
‫أشياء مثل Edge والبنية التحتية الصغيرة التي سيتم
‫التركيز عليها جميعًا لأنه في بداية Kubernetes ،
‫كانت كبيرة جدًا ومرهقة
‫للغاية ، لكنها تسحب الكثير منها
‫وتجعل نشرها أسهل.
‫لهذا السبب ترى أدوات مثل kubeadm تخرج وتكون قادرة على
‫نشر مجموعات HA.
‫إنه آمن تمامًا وإذا كان متسامحًا
‫مع الخطأ. هذه كلها أشياء ستؤتي
‫ثمارها الآن.
‫جزء من هذا المستقبل هو معرفة المشاريع الأخرى ذات الصلة.
‫هذه
‫قائمة سريعة بالأشياء التي لم أذكرها في هذه الدورة
‫والتي قد ترغب في التحقق منها. لأن Kubernetes نفسها أصبحت
‫النظام الأساسي الذي بدأ بناء جميع الأشياء
‫الأخرى عليه. في الواقع ، كانت هذه هي الأهداف
‫الأصلية لمؤلفي المشروع.
‫لم يقصدوا حقًا بالنسبة لنا استخدام Kubernetes
‫مباشرة من حيث Kubernetes الخام والمفتوحة
‫المصدر.
‫لقد قصدوا حقًا للآخرين أن يبنوا أفكارًا مجردة فوقها
‫لكي ندير أعباء العمل لدينا.
‫هذا هو سبب ظهور التوزيعات ، في كثير من
‫الحالات ، لأنهم يقومون ببناء طبقة أخرى في الأعلى للقيام
‫بذلك. في هذه الحالة ، نرى كل
‫أنواع البنية التحتية الأخرى تأتي من أجل القيام بأشياء
‫أخرى. أولا ، هو Knative.
‫يوجد هذا حول قوائم الخوادم ، وهو بالتأكيد
‫مشروع CNCF رسمي لذلك فهو مرتبط ارتباطًا وثيقًا بعالم Kubernetes.
‫إذا كنت مهتمًا بقوائم الخوادم ، فهي بالتأكيد أحد المشاريع
‫التي تريد التحقق منها.
‫بعد ذلك ، هناك مشروعان من Rancher هما
‫K3s و K3os.
‫K3s هو في الأساس فريقهم
‫الذي يتولى النشر المعقد وإدارة Kubernetes وتبسيطها
‫، وإزالة جميع الأشياء غير الضرورية
‫التي تأتي معها.
‫ربما بعض الأوامر القديمة والكود.
‫ربما بعض برامج تشغيل التخزين التي لم تعد بحاجة إليها
‫إذا كان لديك CSI.
‫هذا النوع من الأشياء. إنهم يسحبون كل شيء ، ويقدمون
‫لك قاعدة بيانات سهلة حقًا.
‫حتى أنه لا يستخدم الخلاصة خارج الصندوق.
‫يستخدم قاعدة بيانات أبسط.
‫إنه مخصص حقًا لأشياء مثل إنترنت الأشياء.
‫ولكن الآن ، مع هدفهم المتمثل في جعل Kubernetes بسيطًا مثل
‫Swarm ، والذي قاله دارين شيبرد ، كبير التكنولوجيا
‫والمؤسس المشارك ، في DockerCon هذا العام.
‫لقد كان بيانًا مثيرًا للاهتمام.
‫لقد كان يقول حقًا ، كما تعلم ، أن Swarm يعمل جيدًا في
‫النشر ، وسهولة الاستخدام ، وأقل تأثير.
‫إنه ثنائي صغير جدًا.
‫لديها القليل جدا من النفقات العامة
‫من حيث البنية التحتية. Kubernetes هو
‫عكس ذلك تمامًا. إنهم يحاولون إيجاد حل وسط.
‫هل من الممكن إذا استبعدنا ما يكفي من الأشياء وما زلنا نجعلها
‫حقيقية Kubernetes ، هل يمكننا أن نجعل من السهل جدًا نشرها على أنظمة
‫صغيرة مثل ARM و Raspberry Pis وأشياء
‫من هذا القبيل. لذلك ، هذا مشروع يجب مشاهدته.
‫K3os هو نظام تشغيل
‫مع K3s فوقه.
‫إنه تثبيت Linux ضئيل للغاية
‫مصمم لتشغيل K3s على الأجهزة
‫الصغيرة. إنه مشروع جديد جدًا ولكنه مشروع
‫مثير للاهتمام مع ذلك. مجال تركيز كبير آخر حقًا
‫، والذي سوف تسمعني أتحدث عنه كثيرًا في البودكاست
‫الخاص بي ، هو شبكة الخدمة ، وهو مفهوم جديد في العامين الماضيين
‫، وهو حقًا مصطلح جديد.
‫لم نستخدم هذه الكلمة حقًا في الصناعة من قبل.
‫شبكة الخدمة هي فكرة
‫طبقة الوكيل هذه عبر المجموعة بأكملها ، ليس
‫فقط للاتصالات الواردة من الإنترنت ، ولكن حقًا لجميع
‫أجزاء التطبيق الخاص بك.
‫يصبح وسيطًا للتحكم ، من حيث الأمان ، من حيث
‫المراقبة والتوجيه إلى المواقع المناسبة
‫، كل حركة المرور لجميع أجزاء
‫التطبيق الموزع.
‫إنها سلسلة من المشاريع التي نتجت عن مشكلة
‫الخدمات المصغرة. إذا سبق لك أن قمت
‫بأي خدمات مصغرة ، فإن أحد التحديات الحقيقية هو ما كان موجودًا
‫في ثنائي واحد على خادم واحد ، ويصبح من السهل نسبيًا استكشاف
‫الأخطاء وإصلاحها العشرات من الحاويات ، عبر
‫عشرات الخوادم.
‫يصبح من الصعب للغاية استكشاف الأخطاء وإصلاحها ما
‫لم يكن لديك أدوات شبكات رائعة.
‫لذلك ، تشير شبكة الخدمة إلى هذه
‫المشكلة وتحاول أن تصبح معيارًا ، مع وجود
‫معايير وراءها ، حول وضع طبقة
‫هناك لزيادة الرؤية والمراقبة واستكشاف الأخطاء
‫وإصلاحها والأمان حول تطبيقاتنا الموزعة وخدماتنا المصغرة.