كان من المفترض أن يتم يوم الاثنين رسميًا
( ولكن لم يحدث هذا حتى الآن ... تم التحديث 06/20 : ظهر الإعلان على مدونة K8) الإصدار
Kubernetes التالي هو
1.15 . وفقًا للتقاليد التي تطورت لمدونتنا ، نتحدث عن أهم التغييرات في الإصدار الجديد.
المعلومات المستخدمة لإعداد هذه المواد مأخوذة من
جدول تتبع تحسينات Kubernetes و
CHANGELOG-1.15 والمشكلات ذات الصلة وطلبات السحب وكذلك اقتراحات Kubernetes Enhancement Proposals (KEP). نظرًا لأن مؤتمر KubeCon في شنغهاي سيعقد الأسبوع المقبل ، فقد كان لهذا الإصدار دورة قصيرة مدتها 11 أسبوعًا (بدلاً من 12 أسبوعًا) ، والتي ، مع ذلك ، لم تؤثر بشكل كبير على عدد التغييرات المهمة. لذلك دعونا نذهب! ..
مستودعات البيانات
قدم
API ExecutionHook جديدة ، والتي تتيح لك تنفيذ أوامر المستخدم بشكل حيوي في pod / حاوية أو مجموعة من pods / container ، ومعها وحدة التحكم المقابلة (
ExecutionHookController ) التي تنفذ إدارة دورة حياة الخطاف. كان الدافع وراء ظهور هذه الميزة هو الرغبة في تزويد المستخدمين بالقدرة على إنشاء / حذف اللقطات وفقًا لمنطق التطبيق ، أي تنفيذ أي أوامر خاصة بالتطبيق قبل وبعد إنشاء اللقطة. من المفترض أن هذه الخطافات يمكن أن تكون مفيدة أيضًا في المواقف الأخرى - على سبيل المثال ، إجراء التحديثات وتصحيح الأخطاء وتحديث ملفات التكوين وإعادة تشغيل الحاوية والتحضير لأحداث أخرى مثل ترحيل قاعدة البيانات. الحالة الحالية - إصدار ألفا (يُتوقع ترجمته إلى الإصدار التجريبي للإصدار التالي) ، التفاصيل - في
KEP .
في التخزين المؤقت ، الذي يسمح لك بالتمييز بين حاويات / حاويات معينة حجم المساحة
المشتركة (التخزين المشترك) ،
تمت إضافة دعم لنظام
الحصص النسبية للملف. تستخدم هذه الآلية الجديدة حصص المشروع (حصص
المشروع ) المتاحة في XFS و ext4 ، مما يوفر مراقبة استهلاك الموارد وفرض قيود اختيارية عليها. الوضع الحالي - نسخة ألفا. لم يتم تحديد خطط للإصدارات المستقبلية.
ميزة أخرى جديدة مقدمة بواسطة sig-storage هي استخدام المواد البلاستيكية الحالية كمصدر
DataSource لإنشاء مواد بلاستيكية جديدة. بمعنى آخر ، هذا هو
تنفيذ وظيفة استنساخ وحدة التخزين . يجب التمييز بين المستنساخ واللقطات ، لأن كل استنساخ هو وحدة تخزين جديدة و "كاملة": يتم إنشاؤه كنسخة من واحد موجود ، لكنه يتبع دورة حياة وحدات التخزين العادية تمامًا (على عكس اللقطات ، على الرغم من كونها نسخًا من مجلدات في وقت معين ، ولكنها ليست مستقلة مجلدات). فرصة توضيحية:
kind: PersistentVolumeClaim apiVersion: v1 metadata: name: pvc-2 namespace: myns spec: capacity: storage: 10Gi dataSource: kind: PersistentVolumeClaim name: pvc-1
في هذه الحالة ، سيتم إنشاء PV / PVC مستقل جديد ( pvc-2 ) يحتوي على نفس البيانات الموجودة على pvc-1 . يشار إلى أن PVC الجديد يجب أن يكون له نفس مساحة الاسم الأصلي.القيود الحالية هي دعم
CLONE_VOLUME الديناميكي وفقط لمكونات CSI (يجب أن يكون لديهم القدرة
CLONE_VOLUME ). اقرأ المزيد في
KEP .
لقد "تطورت" الميزات التالية إلى حالة الإصدار التجريبي (وبالتالي ، التنشيط في عمليات التثبيت الافتراضية لـ Kubernetes):
- وظيفة توسيع حجم وحدة التخزين الثابتة "عبر الإنترنت" ، أي دون الحاجة إلى إعادة تشغيل جراب باستخدام PVC المناسبة. لأول مرة (في حالة ألفا) ، ظهر في K8s 1.11.
- دعم متغيرات البيئة لأسماء الدليل المحمّلة كـ
subPath ، والذي تم تقديمه لأول مرة في K8s 1.11 وتم تطويره في الماضي 1.14.
لكن عملية ترحيل الأجزاء الداخلية من المكونات الإضافية القديمة للمستودعات التي تم تنفيذها داخل قاعدة كود Kubernetes (في الشجرة) قد استمرت في صالح المكونات الإضافية لواجهة CSI الجديدة. كان من المتوقع أن يكمل إصدار 1.15 عملية ترحيل جميع المكونات الإضافية لموفري الخدمات السحابية ، ومع ذلك ، فقد
تقرر الحفاظ على حالة إصدار ألفا ، لأن الميزة تعتمد على واجهات برمجة التطبيقات المقدمة في K8s 1.15 وحتى الآن لم يتم تنفيذها إلا في إصدار ألفا (على وجه الخصوص ، نحن نتحدث عن التحسينات في دعم Azure: الإضافات
Azure File و
Azure Disk في csi-translation-lib).
مخطط
يتوفر ابتكاران بارزان - كلاهما في شكل ألفا حتى الآن - في Kubernetes Scheduler.
الأول هو
إطار الجدولة (
Kubernetes Scheduling Framework ) ، وهو عبارة عن مجموعة جديدة من واجهات برمجة التطبيقات للمكونات الإضافية التي تزيد من إمكانات برنامج جدولة موجود. يتم إنشاء المكونات الإضافية خارج المستودع الرئيسي (خارج الشجرة) ، ولكن يتم تضمينها في برنامج الجدولة أثناء التجميع. وبالتالي ، يظل النواة الوظيفية لجدول المواعيد بسيطة ومناسبة للدعم قدر الإمكان ، ويتم تنفيذ ميزات إضافية بشكل منفصل ، دون قيود كثيرة على أن
الطريقة الحالية لتوسيع ميزات المجدول "عانت" بمساعدة webhooks.
في الإطار الجديد ، يتم تقسيم كل محاولة جدولة pod إلى مرحلتين:
- دورة الجدولة - حيث يتم تحديد العقدة الخاصة بالجراب ،
- وربط (دورة الربط) - حيث يتم تنفيذ الحل المحدد داخل الكتلة.
في كل مرحلة من هذه المراحل (يطلق عليها أيضًا
سياق الجدولة ) ، هناك العديد من
نقاط الامتداد ، في كل منها يمكن استدعاء المكونات الإضافية للإطار.
(دورة حياة لاستدعاء المكونات الإضافية في إطار الجدولة.)كجزء من إصدار ألفا من الإطار ،
يتم تطبيق نقاط الحجز وإلغاء الحجز وتسجيل النقاط فقط . اقرأ المزيد عن هذا الابتكار الهائل في
KEP .
والثاني هو
خيار عدم الاستباق لـ PriorityClasses .
حصلت الفئات ذات الأولوية على حالة مستقرة (GA) في الإصدار الأخير من Kubernetes ، مما أثر على تخطيط واختيار القرون: يتم التخطيط للقرون وفقًا للأولوية ، وإذا تعذر إنشاء قرنة بسبب نقص الموارد ، فإن القرون يمكن مزاحمة أولوية أقل لتحرير المساحة اللازمة.
يعني الخيار الجديد -
Preempting ، المعرّف على أنه منطقي في بنية
PriorityClass ،: إذا كان جراب ينتظر تخطيطه ولديه
Preempting=false ، فإن إنشاءه لن يستبق البرامج الأخرى. يظهر هذا الحقل في
PodSpec أثناء عملية
قبول التسجيل (تشبه قيمة
PriorityClass ). تفاصيل التنفيذ في
KEP .
آلات API
بالنسبة إلى
CustomResources ، يتم تقديم تحسينات مصممة للتنفيذ للبيانات المخزنة بهذه الطريقة (في إطار JSON في CRD) سلوك يطابق بشكل أفضل واجهة Kubernetes API المقبولة عمومًا (لكائنات K8s "الأصلية"):
- الحذف التلقائي للحقول غير المحددة في مخططات التحقق من OpenAPI - للحصول على التفاصيل ، راجع KEP " Pruning for Custom Resources " ؛
- القدرة على تعيين القيم الافتراضية للحقول في مخططات التحقق من الصحة OpenAPI v3 ، والتي تعتبر مهمة بشكل خاص للحفاظ على توافق API عند إضافة حقول جديدة إلى الكائنات ، للحصول على التفاصيل ، راجع KEP "التعتير الافتراضي للموارد المخصصة ".
تم تخطيط كلتا الميزتين في الأصل لإصدار K8s 1.12 ، لكن الآن فقط يتم تقديمهما في إصدارات ألفا.
التغييرات في CRD لم تقتصر على هذا:
- نشر ميزة CRD OpenAPI - أي التحقق من صحة CustomResources من جانب الخادم (باستخدام نظام OpenAPI v3) الذي تم تقديمه في إصدار Kubernetes الأخير - تم الوصول إلى الإصدار التجريبي وتم تمكينه الآن افتراضيًا ؛
- كما تم تحويل آلية تحويل الإصدار لموارد CRD المستندة إلى webhooks الخارجية إلى تجريبي.
يسمى ابتكار آخر مثير للاهتمام
ووتش المرجعية . يتلخص جوهرها في إضافة نوع جديد من الأحداث إلى
Watch API -
Bookmark . هذا النوع يعني تسمية أن جميع الكائنات حتى
resourceVersion معين قد تمت معالجتها بالفعل بواسطة الساعة. ستعمل هذه الآلية على تقليل الحمل على kube-apiserver ، مما يقلل من عدد الأحداث التي يجب معالجتها في كل مرة يتم فيها إعادة تشغيل الساعة ، بالإضافة إلى تقليل عدد الأخطاء غير المرغوب فيها مثل
"إصدار المورد قديم جدًا" . في Kubernetes 1.15 ، تتمتع الميزة بحالة إصدار alpha ، ومن المتوقع أن تزيد الإصدار التجريبي للإصدار التالي.
Added EventType = "ADDED" Modified EventType = "MODIFIED" Deleted EventType = "DELETED" Error EventType = "ERROR" Bookmark EventType = "BOOKMARK"
(أنواع الأحداث المحتملة في واجهة برمجة تطبيقات المراقبة).في القبول Webhooks:
- إضافة دعم لمحدِد كائن بالإضافة إلى محددات مساحة الاسم الحالية
- تطبيق القدرة على تسجيل إصدار محدد من المورد والاتصال عند تعديل أي إصدار قديم من هذا المورد ؛
- تمت إضافة حقل
Option إلى AdmissionReview API ، خيارات الإبلاغ عن العملية التي يجري تنفيذها.
شبكة
هناك ابتكار هام في جزء الشبكة من Kubernetes وهو ما يسمى "
Finalizer Protection" لموازنات التحميل. الآن قبل حذف موارد LoadBalancer ، يتم التحقق من أن مورد الخدمة المقابل لم يتم حذفه بالكامل. للقيام بذلك ، يتم إرفاق ما يسمى finalizer بكل خدمة مع
type=LoadBalancer : عند حذف هذه الخدمة ، يتم حظر الحذف الحقيقي للمورد حتى يتم حذف finalizer ولا يتم حذف finalizer حتى يتم الانتهاء من "محو" موارد موازن التحميل المقابل (
service.kubernetes.io/load-balancer-cleanup ). الإصدار الحالي من التطبيق هو إصدار ألفا ، ويمكن العثور على تفاصيل حوله في
KEP .
بالإضافة إلى ذلك:
- وصل البرنامج المساعد NodeLocal DNS Cache الذي تم تقديمه في Kubernetes 1.13 وتحسين أداء DNS إلى مرحلة تجريبية.
- لم يعد Kube-proxy يزيل قواعد الشبكة التي تم إنشاؤها تلقائيًا نتيجة لتشغيلها في أوضاع أخرى (وهذا يتطلب إطلاق صريح لـ
kube-proxy --cleanup ).
CLI
كما هو الحال دائمًا ، كانت هناك بعض الأشياء الصغيرة اللطيفة في أوامر وحدة التحكم للعمل مع مجموعات Kubernetes:
آخر
من بين التغييرات الملحوظة الأخرى في Kubernetes 1.15:
- تمت إضافة دعم ميزانية Pod Disruption Budget (PDB) للموارد / وحدات التحكم المستندة إلى CRD لجهة خارجية (على سبيل المثال: EtcdCluster ، MySQLReplicaSet ...) باستخدام مصدر التحليل Scale . حتى الآن هذه نسخة تجريبية ستصبح مستقرة في الإصدار التالي. التفاصيل في KEP .
- وصلت ميزتان للعقد / Kubelet إلى الإصدار التجريبي: دعم المكونات الإضافية لمراقبة الأجهزة الخارجية (من أجل إزالة جميع المعرفة الخاصة بالجهاز من Kubelet ، أي خارج الشجرة) و
SupportNodePidsLimit (عزل SupportNodePidsLimit من العقدة إلى pod'am). - تمت إضافة دعم Go Modules وتمكينه افتراضيًا لقاعدة كود Kubernetes (بدلاً من Godep ووضع GOPATH ، والذي تم إهماله).
- وصل دعم AWS NLB (Network Load Balancer) ، الذي تم تقديمه لأول مرة في الإصدار K8s 1.9 ، إلى مستوى الإصدار التجريبي. على وجه الخصوص ، حصلت على القدرة على تكوين
accessLogs وإنهاء TLS LoadBalancerSourceRanges . - تم تطبيق القدرة على تكوين موفر السحابة Azure من أسرار Kubernetes (لهذا ، تمت
cloudConfigType خيار cloudConfigType جديد ، قد يكون cloudConfigType secret ). أيضًا ، يمكن الآن تشغيل Kubelet في Azure بدون هوية Azure (يجب تمكين useInstanceMetadata لهذا). - في دورة حياة الكتلة ، تم إحضار إمكانية إنشاء مجموعات HA باستخدام kubeadm إلى النسخة التجريبية ، كما أنها أكملت الخطوة التالية (v1beta2) في إعادة تنظيم تنسيق ملف تكوين kubeadm.
- تمت إضافة عدد من القرون في الحالة المعلقة في طوابير مختلفة إلى المقاييس من المجدول ، والإحصائيات على وحدات التخزين عبر مقاييس حجم kubelet من CSI.
- تحديثات البرامج المستخدمة / المعتمدة: Go 1.12.5 ، cri-tools 1.14.0 ، إلخ 3.3.10 (لم يتغير الإصدار للخادم ، ولكن تم تحديثه للعميل) . لم يتم تغيير إصدارات CNI و CSI و CoreDNS (في أحد إصدارات alpha من Kubernetes 1.15 ، تم تحديثه إلى 1.5.0 ، ولكن تم التراجع إلى 1.3.1) ، الإصدارات المدعومة من Docker.
PS
اقرأ أيضًا في مدونتنا: