اليوم هو 27 سبتمبر ، مما
يعني أنه خلال ساعات العمل (وفقًا للمنطقة الزمنية الأمريكية) يمكننا أن نتوقع إصدار Kubernetes التالي - 1.12 (ومع ذلك ، يتم تأجيل الإعلان الرسمي في بعض الأحيان). بشكل عام ، حان الوقت لمواصلة التقاليد المجيدة
والتحدث عن أهم التغييرات التي سنقوم بها استنادًا إلى المعلومات العامة من المشروع:
يتميز Kubernetes بجدول التتبع ،
CHANGELOG-1.12 ، والعديد من المشكلات ، وطلبات السحب ومقترحات التصميم. إذن ما الجديد في K8s 1.12؟
مرافق التخزين
إذا حددت شيئًا واحدًا يتم ذكره أكثر من أي شيء آخر من بين جميع المشكلات المتعلقة بإصدار Kubernetes 1.12 ، فربما تكون
واجهة تخزين الحاويات (CSI) ، التي كتبناها
بالفعل في اليوم الآخر. لهذا السبب ، فلنبدأ بالتغييرات في دعم التخزين.
على هذا النحو
، احتفظت مكونات CSI الإضافية بالنسخة التجريبية ومن المتوقع أن تكون مستقرة لإصدار Kubernetes التالي (1.13). ما الجديد إذن في دعم CSI؟
في فبراير من هذا العام
، بدأ العمل على
مفهوم الطوبولوجيا في مواصفات CSI نفسها. باختصار ، الطوبولوجيا هي معلومات حول تجزئة الكتلة (على سبيل المثال ، عن طريق "الرفوف" للتثبيتات داخل المباني أو عن طريق "المناطق" و "المناطق" للبيئات السحابية) ، والتي تحتاج أنظمة التهيئة إلى معرفتها وأخذها في الاعتبار. لماذا؟ لن يتم بالضرورة الوصول إلى الأحجام المخصصة من قبل موفري التخزين على قدم المساواة في جميع أنحاء المجموعة ، وبالتالي فإن معرفة الطوبولوجيا ضرورية لتخطيط الموارد بكفاءة واتخاذ قرارات التزويد.
كانت نتيجة ظهور الطوبولوجيا في CSI (التي تم
اعتمادها في المواصفات في 1 يونيو) دعمها في Kubernetes 1.12:
ولكن هذا لا ينتهي بالتحديثات المتعلقة CSI. هناك ابتكار مهم آخر في إصدار Kubernetes 1.12 وهو
دعم اللقطات لـ CSI (بينما في حالة ألفا). ظهرت لقطات للأحجام على هذا النحو في
إصدار K8s 1.8 . وقد تقرر نقل التطبيق الرئيسي ، الذي يتضمن وحدة التحكم والموفر (ثنائيات منفصلة) ، إلى
مستودع خارجي . منذ ذلك الحين ، تمت إضافة دعم لأحجام GCE PD و AWS EBS و OpenStack Cinder و GlusterFS و Kubernetes
hostPath .
يهدف
مقترح التصميم الجديد إلى "مواصلة هذه المبادرة من خلال إضافة دعم اللقطات لمحركات حجم CSI" (يتم وصف دعم اللقطة في مواصفات CSI
هنا ). نظرًا لأن Kubernetes تلتزم بمبدأ تضمين الحد الأدنى من الإمكانات في واجهة برمجة التطبيقات الأساسية ، فإن هذا التطبيق (كما هو الحال في اللقطات في وحدة تحكم حجم اللقطة) يستخدم CRD (
CustomResourceDefinitions ).
واثنين من الميزات الجديدة لسائقي CSI:
- إصدار ألفا من قدرة السائق على تسجيل نفسه في Kubernetes API (من أجل تسهيل الأمر على المستخدمين للعثور على برامج تشغيل مثبتة في المجموعة والسماح للسائقين بالتأثير على عمليات تفاعل Kubernetes معهم) ؛
- إصدار ألفا من قدرة السائق على تلقي معلومات حول محرك الأقراص الذي يطلب وحدة التخزين من خلال
NodePublish .
تم تقديمه في إصدار Kubernetes الأخير ، انتقلت
آلية الحد الديناميكي للأحجام على العقد من ألفا إلى بيتا ،
وتلقيت ... تخمينها ، ودعم CSI ، وكذلك Azure.
وأخيرًا ، تم إعلان ميزة
نشر مساحة الاسم Mount ، والتي تسمح لك
rshared وحدة التخزين كـ
rshared (بحيث تكون جميع دلائل الحاوية المثبتة مرئية على المضيف) ولها حالة بيتا في إصدار
K8s 1.10 ، مستقرة.
مخطط
في المجدول ، يعمل Kubernetes 1.12 على تحسين الأداء بفضل الإصدار ألفا من
آلية تقييد البحث في مجموعة من العقد المناسبة لجدولة المداخن
(العقد الممكنة) . إذا كان من قبل لكل محاولة لتخطيط كل جراب ، قام
kube-Scheduler بفحص توفر جميع العقد وتمريرها للتقييم ، والآن سيجد المجدول عددًا معينًا منها فقط ، ثم يتوقف عن العمل. في الوقت نفسه ، تنص الآلية على الاختيار الإلزامي للعقد من مناطق ومناطق مختلفة ، بالإضافة إلى الحاجة إلى عرض العقد المختلفة في دورات التخطيط المختلفة (لا تحدد أول 100 عقد في كل بداية). تم اتخاذ قرار تنفيذ هذه الآلية ، مسترشدًا بنتائج تحليل البيانات على أداء المجدول (إذا أظهر المئين 90th وقت 30 مللي ثانية للموقد ، فإن المئين 99 هو 60 مللي ثانية بالفعل).
بالإضافة إلى ذلك ، نضجت الميزات التالية للجدولة إلى الإصدار التجريبي:
- عقدة Taint حسب الشرط ، والتي ظهرت في K8s 1.8 وتسمح بوضع علامة على عقدة بحالة معينة (لمزيد من الإجراءات) عند وقوع أحداث معينة: الآن يقوم المتحكم في دورة حياة العقدة تلقائيًا بإنشاء الشوائب ، ويقوم المجدول بفحصها (بدلاً من الشروط ) ؛
- جدولة
DaemonSet في DaemonSet باستخدام kube-Scheduler (بدلاً من وحدة تحكم DaemonSet ): تم DaemonSet أيضًا بشكل افتراضي ؛ - تحديد فئة الأولوية في
ResourceQuota .
العقد العنقودية
كان الابتكار المثير للاهتمام هو المظهر (في حالة إصدار ألفا) لـ
RuntimeClass - وهو مورد جديد على مستوى المجموعة مصمم لخدمة معلمات
وقت تشغيل الحاوية (وقت تشغيل الحاوية) . يتم تعيين
RuntimeClasses إلى pods من خلال نفس الحقل في
PodSpec وتنفيذ الدعم لاستخدام بيئات متعددة قابلة للتنفيذ داخل كتلة أو عقدة. لماذا؟
"يتزايد الاهتمام باستخدام أوقات تشغيل مختلفة في مجموعة. في الوقت الحالي ، فإن الدافع الرئيسي لذلك هو صناديق الرمل ورغبة حاويات Kata و gVisor في الاندماج مع Kubernetes. كما تتطلب نماذج وقت التشغيل الأخرى مثل حاويات Windows أو حتى بيئات وقت التشغيل عن بُعد دعمًا في المستقبل. يوفر RuntimeClass طريقة للاختيار بين أوقات التشغيل المختلفة التي تم تكوينها في مجموعة وتغيير خصائصها (بواسطة كل من المجموعة والمستخدم). "
للاختيار بين التكوينات المحددة مسبقًا ،
RuntimeHandler تمرير
RuntimeHandler إلى CRI (واجهة وقت التشغيل الحاوية) ، والتي تهدف إلى استبدال التعليقات التوضيحية الحالية للموقد:
والتكوين في الحاوية لـ kata-runtime يبدو كالتالي:
[plugins.cri.containerd.kata-runtime] runtime_type = "io.containerd.runtime.v1.linux" runtime_engine = "/opt/kata/bin/kata-runtime" runtime_root = ""
معيار
RuntimeClass لنسخة ألفا هو
التحقق من صحة CRI بنجاح.
بالإضافة إلى ذلك ، نمت
آلية تسجيل المكونات الإضافية المحلية (بما في ذلك CSI) في
Kubelet و
shareProcessNamespace (أصبحت الميزة ممكّنة بشكل افتراضي) إلى حالة إصدار تجريبي.
الشبكات
الأخبار الرئيسية في جزء الشبكة من Kubernetes هي
نسخة ألفا من SCTP (بروتوكول نقل التحكم في التدفق). بعد تلقي الدعم في
Pod و
Service و
Endpoint و
NetworkPolicy ، انضم بروتوكول الاتصالات هذا إلى صفوف TCP و UDP. مع الميزة الجديدة "التطبيقات التي تتطلب SCTP كبروتوكول L4 لواجهاتهم ، سيكون من الأسهل نشرها على مجموعات Kubernetes ؛ على سبيل المثال ، سيكون بإمكانهم استخدام اكتشاف الخدمة استنادًا إلى
kube-dns ، وسيتم التحكم في تفاعلهم من خلال
NetworkPolicy ". تفاصيل التنفيذ متوفرة في
هذا المستند .
حققت أيضًا ميزتان للشبكة تم تقديمهما في K8s 1.8 حالة مستقرة:
دعم السياسات لحركة مرور
EgressRules الصادرة في NetworkPolicy API
وتطبيق قواعد CIDR للمصدر / الوجهة عبر
ipBlockRule .
تحجيم
تتضمن التحسينات التي تم إجراؤها على Autoscaler الأفقي للقرنة:
التحجيم الرأسي للموقد ، الذي كان يفتقر إلى اختبار المستخدم قبل الوصول إلى الإصدار التجريبي ، لا يقف ساكناً. اعتبر المؤلفون أنها كافية لإصدار K8s 1.12
ويذكرون أن هذه الميزة هي على الأرجح إضافة إلى Kubernetes (غير مدرجة في النواة). يتم تنفيذ جميع عمليات التطوير في مستودع منفصل ، حيث سيتم توقيت إصدار بيتا ليتزامن مع إصدار Kubernetes.
سير العمل الرأسي أوتوسكالر (VPA) ل Kubernetesوأخيرًا ، يتضمن K8s 1.12 (في شكل ألفا) نتائج
العمل على "تبسيط التثبيت باستخدام
ComponentConfig " (كجزء من دورة حياة sig-العنقودية) ، والذي استمر لمدة عامين تقريبًا. لسوء الحظ ، لسبب ما (إشراف بسيط؟) ، يتم إغلاق الوصول إلى
مستند اقتراح التصميم مع التفاصيل للمستخدمين المجهولين.
تغييرات أخرى
API
يتم تنفيذ ميزتين جديدتين في مجموعة api-machinery:
dry-run ل apiserver (نسخة ألفا) ، التي تقلد التحقق من الطلبات ومعالجتها ؛- واجهة برمجة تطبيقات Resource Quota (تجريبية مباشرة) تحدد الموارد المقيدة افتراضيًا (بدلاً من السلوك الحالي عندما يكون استهلاك الموارد غير محدود إذا لم يتم تعيين حصة).
أزور
مستقر المعلن:
- دعم مجموعات مقياس Azure Virtual Machine (VMSS) ؛
- دعم أزور في autoscaler العنقودية.
تمت إضافة عمليات التنفيذ الأولى (إصدارات ألفا):
Kubectl
- تم تنفيذ إصدار ألفا من آلية المكون الإضافي المحدثة ، والذي يسمح لك بإضافة أوامر جديدة أو إعادة كتابة الأوامر الفرعية الموجودة من أي مستوى تداخل. إنه مشابه لـ Git وينظر إلى الملفات التنفيذية بدءًا من
kubectl- في $PATH للمستخدم. راجع اقتراح التصميم لمزيد من التفاصيل. - تم تنفيذ نسخة تجريبية لفكرة عزل
pkg/kubectl/genericclioptions من kubectl إلى مستودع مستقل. - تم الإعلان عن استقرار وظيفة الطباعة من جانب الخادم .
أخرى
- يتم تقديم إصدار ألفا من TTL الجديد بعد آلية الإنهاء ، المصممة للحد من عمر وظائف و Pods الذين أنهوا التنفيذ. بعد انتهاء مدة البقاء المحددة ، سيتم تنظيف الكائنات تلقائيًا دون الحاجة إلى تدخل المستخدم.
- تم الإعلان عن استقرار إنشاء مفتاح خاص و CSR (TLS Bootstrap) لتوقيع شهادة على مستوى الكتلة في Kubelet .
- تم تدوير شهادة TLS للخادم في Kubelet إلى الحالة التجريبية.
ملاحظة
اقرأ أيضا في مدونتنا: