Kubernetes 1.13: نظرة عامة على الابتكارات الرئيسية

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

كمصدر للمعلومات ، قمنا بالعمل على بيانات من تتبع تحسينات Kubernetes وجدول CHANGELOG-1.13 والقضايا ذات الصلة وطلبات السحب ومقترحات Kubernetes Enhancement (KEP).

GA ل kubeadm

أحد الأحداث الرئيسية لإصدار Kubernetes 1.13 كان الإعلان عن حالة مستقرة (General Available ، GA) لأداة التحكم kubeadm . خصصت مدونة K8s منشوراً منفصلاً لهذا الغرض . كما يعلم الكثير من الناس ، يعد kubeadm أداة لإنشاء مجموعات Kubernetes وفقًا لأفضل الممارسات في المشروع ، فضلاً عن الحد الأدنى من الدعم. الميزة المميزة هي أن المطورين يبذلون قصارى جهدهم لإبقائها مضغوطة ومستقلة عن الموفر / البنية التحتية ، دون تضمين حلول للمشاكل مثل توفير البنية التحتية ، وحلول شبكات الطرف الثالث ، والوظائف الإضافية (المراقبة ، وقطع الأشجار ، وما إلى ذلك) والتكاملات المحددة مع السحابة مقدمي الخدمات.

وضع GA وضع علامة على نضج kubeadm في المجالات التالية:

• واجهة وحدة التحكم المستقرة التي تتبع سياسة تقادم Kubernetes: يجب دعم الأوامر والإشارات المقدمة في إصدار GA لمدة عام على الأقل بعد إهمالها ؛
• تنفيذ مستقر "تحت الغطاء" نظرًا لحقيقة أن الكتلة تم إنشاؤها بواسطة طرق لن تتغير في المستقبل القريب: يتم إطلاق مستوى التحكم حيث يتم استخدام العديد من القرون الثابتة ، يتم استخدام الرموز المميزة kubeadm join ، ويتم استخدام ComponentConfig لتكوين kubelet ؛
• مخطط التكوين مع API جديد (v1beta1) ، والذي يسمح بوصف جميع مكونات نظام المجموعة تقريبًا (GitOps ممكن للمجموعات التي تم إنشاؤها باستخدام kubeadm) - من المخطط إجراء ترقية إلى الإصدار v1 بدون تغييرات أو الحد الأدنى من التغييرات ؛
• أطوار ما يسمى (أو واجهة صندوق الأدوات ) في kubeadm ( kubeadm init phase ) ، مما يسمح لك باختيار إجراءات التهيئة التي سيتم تنفيذها ؛
• يضمن فريق kubeadm upgrade تحديثات الكتلة بين الإصدارات 1.10.x و 1.11.x و 1.12.x و 1.13.x (تحديثات etcd و API Server و Controller Manager و Scheduler) ؛
• التثبيت الآمن لـ etcd افتراضيًا (يستخدم بروتوكول TLS في كل مكان) مع إمكانية التوسع إلى نظام HA إذا لزم الأمر.

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

CoreDNS افتراضيا

ذهب CoreDNS ، الذي حصل على حالة مستقرة في إصدار Kubernetes 1.11 ، إلى أبعد من ذلك وأصبح خادم DNS الافتراضي في K8s (بدلاً من kube-dns المستخدمة حتى الآن). كان من المخطط أن يحدث هذا في وقت مبكر من 1.12 ، ولكن واجه المطورون الحاجة إلى تحسينات إضافية في قابلية التوسع واستهلاك الذاكرة ، والتي لم تكتمل إلا من خلال الإصدار الحالي.



سيستمر دعم kube-dns "لإصدار واحد على الأقل لاحقًا" ، لكن المطورين يتحدثون عن الحاجة إلى بدء الترحيل إلى حل محدّث الآن.

من بين التغييرات المرتبطة بموضوع CoreDNS في Kubernetes 1.13 ، يمكن أيضًا ملاحظة المكون الإضافي NodeLocal DNS Cache لتحسين أداء DNS. يتم تحقيق التحسين من خلال تشغيل وكيل على عقد نظام المجموعة لذاكرة التخزين المؤقت DNS ، والتي سيتم الوصول إليها مباشرة من خلال قرون هذه العقدة. بشكل افتراضي ، يتم تعطيل الوظيفة ، KUBE_ENABLE_NODELOCAL_DNS=true ، يجب عليك تعيين KUBE_ENABLE_NODELOCAL_DNS=true .

مرافق التخزين

يتم إيلاء الكثير من الاهتمام في الإصدارات الأخيرة من Kubernetes للعمل مع واجهة حاوية التخزين (CSI) ، والتي بدأت بالإصدار ألفا من CSI في K8s 1.9 ، واستمرت مع الإصدار التجريبي في 1.10 ... ومع ذلك ، فقد كتبنا بالفعل حول هذا الموضوع أكثر من مرة . تم الوصول إلى معلم جديد مهم في K8s 1.13: دعم CSI ثابت (GA).


(مخطط من مقال " فهم واجهة تخزين الحاويات ")

إلى جانب ذلك ، ظهر دعم مواصفات CSI v1.0.0 وتم إلغاء دعم الإصدارات الأقدم من المعيار (0.3 والإصدارات السابقة). هذا يعني أن برامج تشغيل CSI الأقدم ستتطلب الترقية إلى CSI 1.0 (والانتقال إلى دليل تسجيل المكوّن الإضافي Kubelet الجديد) للعمل في Kubernetes 1.15 والإصدارات الأقدم. بالمناسبة ، من برامج التشغيل نفسها ، تجدر الإشارة إلى ظهور إصدار ألفا من واجهة CSI لإدارة دورة حياة وحدات تخزين AWS (مخزن البلوك المرن).

تقوم الآن إضافة جديدة إلى مدير الملحق بتثبيت CRI تلقائيًا من CSI في حالة تنشيط واحدة من بوابتي الميزات على الأقل: CSIDriverRegistry و CSINodeInfo . يحتوي على حالة إصدار ألفا ، ولكنه في الحقيقة حل مؤقت للمشكلة ، موصوفًا بالتفصيل كآلية تثبيت CRD .

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

الفرصة التي تم تقديمها في Kubernetes 1.9 لاستخدام أجهزة كتلة خام (وليس شبكة) حيث تمت ترجمة وحدات التخزين الثابتة إلى تجريبية وتم تمكينها الآن افتراضيًا.

نختتم موضوع التخزين بحقيقة أن دعم GCERegionalPersistentDisk تم إعلانه مستقرًا.

العقد العنقودية

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

يسمح برنامج Kubelet Plugin Watcher (المعروف أيضًا باسم Kubelet Device Plugin Registration) بالاستقرار ، وهو يسمح بالإضافات على مستوى العقدة (المكونات الإضافية للجهاز ، CSI و CNI) للتواصل مع Kubelet عن أنفسهم.

ميزة جديدة في حالة ألفا هي NodeLease . إذا تم تحديد "نبضات" العقدة في وقت سابق بواسطة NodeStatus ، ثم باستخدام ميزة جديدة ، يكون لكل عقدة كائن Lease مرتبط به (في مساحة الاسم kube-node-lease ) ، والتي يتم تحديثها دوريًا بواسطة العقدة. يتم الآن تعيين "النبض" بواسطة كلا المعلمتين: NodeStatus القديم ، الذي يتم إبلاغه إلى الرئيسي فقط في حالة حدوث تغييرات أو عن طريق مهلة محددة (افتراضياً ، مرة واحدة في الدقيقة) ، وكائن جديد (يتم تحديثه بشكل متكرر). نظرًا لأن هذا الكائن صغير جدًا ، فسيحسن بشكل كبير قابلية التوسع والأداء. بدأ المؤلفون في إنشاء "نبضة" جديدة بعد اختبار الكتل بحجم يزيد عن 2000 عقدة ، والتي قد تتوقف أثناء عملهم مع حدود الخ ، للحصول على مزيد من التفاصيل ، انظر KEP-0009 .

 type Lease struct { metav1.TypeMeta `json:",inline"` // Standard object's metadata. // More info: https://git.k8s.io/community/contributors/devel/api-conventions.md#metadata // +optional ObjectMeta metav1.ObjectMeta `json:"metadata,omitempty"` // Specification of the Lease. // More info: https://git.k8s.io/community/contributors/devel/api-conventions.md#spec-and-status // +optional Spec LeaseSpec `json:"spec,omitempty"` } type LeaseSpec struct { HolderIdentity string `json:"holderIdentity"` LeaseDurationSeconds int32 `json:"leaseDurationSeconds"` AcquireTime metav1.MicroTime `json:"acquireTime"` RenewTime metav1.MicroTime `json:"renewTime"` LeaseTransitions int32 `json:"leaseTransitions"` } 

(المواصفات المدمجة للكائن الجديد لتمثيل "نبض" العقدة - Lease - مطابقة لـ LeaderElectionRecord )

السلامة

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

تم نقل تشفير البيانات في etcd (انظر الوثائق الرسمية ) من الحالة التجريبية إلى التجريبية.

 kind: EncryptionConfiguration apiVersion: apiserver.config.k8s.io/v1 resources: - resources: - secrets providers: - identity: {} - aesgcm: keys: - name: key1 secret: c2VjcmV0IGlzIHNlY3VyZQ== - name: key2 secret: dGhpcyBpcyBwYXNzd29yZA== - aescbc: keys: - name: key1 secret: c2VjcmV0IGlzIHNlY3VyZQ== - name: key2 secret: dGhpcyBpcyBwYXNzd29yZA== - secretbox: keys: - name: key1 secret: YWJjZGVmZ2hpamtsbW5vcHFyc3R1dnd4eXoxMjM0NTY= 

(يتم أخذ تكوين مثال مع البيانات المشفرة من الوثائق .)

من بين الابتكارات الأقل أهمية في هذه الفئة:

• يمكن الآن تكوين apiserver لرفض الطلبات التي لا يمكنها الدخول في سجلات التدقيق.
• PodSecurityPolicy إضافة كائنات PodSecurityPolicy بدعم قاعدة fsGroup و fsGroup ، مما يسمح بتعريف نطاق معرفات المجموعة المسموح بها (GIDs) للقرون / الحاويات دون فرض GID الافتراضي. بالإضافة إلى ذلك ، مع PodSecurityPolicy ، أصبحت استراتيجية RunAsGroup ممكنة الآن في تحديد البرامج ، على سبيل المثال يمكنك التحكم في GID الرئيسي للحاويات.
• بالنسبة إلى kube-scheduler ، استبدلنا المنفذ غير الآمن السابق (10251) بمنفذ آمن جديد (10259) وقمنا بتشغيله بشكل افتراضي. إذا لم يتم تحديد أعلام إضافية ، فعند التحميل ، يتم إنشاء شهادات موقعة ذاتيا في الذاكرة.

CLI

kubectl diff ، الذي يظهر الفرق بين التكوين المحلي والوصف الحالي للكائن العامل (يعمل وبشكل متكرر للأدلة مع التكوينات) ، حالة تجريبية.

في الواقع ، diff "يتنبأ" بالتغييرات التي سيتم إجراؤها باستخدام kubectl apply ، ويتم استخدام ميزة جديدة أخرى - APIServer DryRun . يجب أن يكون جوهره - بداية الخمول - واضحًا من الاسم ، ويتوفر وصف أكثر تفصيلًا في وثائق Kubernetes . بالمناسبة ، في الإصدار 1.13 ، تمت أيضًا ترقية وظيفة DryRun إلى الإصدار التجريبي وتشغيلها افتراضيًا.

وقد أثر تقدم آخر إلى الإصدار التجريبي في عالم الكونسول من Kubernetes على آلية البرنامج المساعد الجديدة . على طول الطريق ، قاموا بتصحيح ترتيب إخراج المكونات الإضافية ( kubectl plugin list المكونات الإضافية kubectl plugin list ) ، وإزالة الفرز الإضافي من هناك.

بالإضافة إلى ذلك ، تمت إضافة ناتج موارد التخزين المؤقت المستخدمة إلى kubectl describe node ، وتمت إضافة وحدات التخزين من نوع المسقطة إلى kubectl describe pod .

تغييرات أخرى

تم تحويل وظيفة جدولة الإخلاء المستند إلى Taint إلى حالة تجريبية وتم تمكينها افتراضيًا بعد توقف طويل في التطوير. والغرض منه هو إضافة مواد الطلاء إلى العقد تلقائيًا (عبر NodeController أو kubelet) عند حدوث شروط معينة ، على سبيل المثال ، node.kubernetes.io/not-ready ، والتي تتوافق مع قيمة NodeCondition في Ready=False .

تم إهمال شرح للقرون الحرجة لتشغيل المجموعة - critical-pod . بدلاً من ذلك ، يُقترح استخدام الأولويات (في النسخة التجريبية مع Kubernetes 1.11) .

بالنسبة لـ AWS ، لأول مرة (كجزء من إصدارات ألفا) ، أصبح ما يلي متاحًا:

• تكامل AWS ALB (موازن تحميل التطبيقات) مع موارد Kubernetes Ingress - aws-alb-ingress-controller (تم إنشاء المشروع في الأصل بواسطة Ticketmaster و CoreOS لترحيل الأول إلى سحابة AWS) ؛
• CCM الخارجي لـ AWS (مدير وحدة التحكم في السحاب) - سحابة - مزود - aws ، وهو المسؤول عن إطلاق وحدات التحكم مع وظائف الموفر السحابي (AWS).

نفذت SIG Azure دعمًا إضافيًا لـ Azure Disk (Ultra SSD و SSD قياسي وملفات Premium Azure) وعززت عقد مجموعة موارد المصادر إلى الإصدار التجريبي. بالإضافة إلى ذلك ، أصبحت الإضافات CNI لنظام التشغيل Windows الآن قادرة على تكوين DNS في حاوية.

التوافق

• إصدار etcd هو 3.2.24 (لم يتغير منذ Kubernetes 1.12).
• تم التحقق من الإصدارات من Docker - 1.11.1 ، 1.12.1 ، 1.13.1 ، 17.03 ، 17.06 ، 17.09 ، 18.06 (أيضًا لم تتغير).
• إصدار Go - 1.11.2 ، يتزامن مع الحد الأدنى المدعوم.
• إصدار CNI هو 0.6.0.
• إصدار CSI هو 1.0.0.
• إصدار CoreDNS هو 1.2.6.

PS

اقرأ أيضًا في مدونتنا:

• "نحن نفهم واجهة تخزين الحاويات (في Kubernetes وليس فقط) " ؛
• " Kubernetes 1.12: نظرة عامة على الابتكارات الرئيسية " ؛
• " Kubernetes 1.11: نظرة عامة على الابتكارات الرئيسية " ؛
• " Kubernetes 1.10: نظرة عامة على الابتكارات الرئيسية " ؛
• Kubernetes 1.9: نظرة عامة على الابتكارات الرئيسية .