اليوم ، يوم الأربعاء ، سيعقد الإصدار التالي من Kubernetes - 1.16. وفقًا للتقليد الذي تم تطويره لمدونتنا ، للمرة العاشرة ، نتحدث عن أهم التغييرات في الإصدار الجديد.
المعلومات المستخدمة لإعداد هذه المواد مأخوذة من
جدول تتبع تحسينات Kubernetes و
CHANGELOG-1.16 والمشكلات ذات الصلة وطلبات السحب وكذلك اقتراحات Kubernetes Enhancement (KEP). لذلك دعونا نذهب! ..
عقدة
يتم تقديم عدد كبير بالفعل من الابتكارات البارزة (في حالة إصدار ألفا) على جانب العقد من مجموعات K8s (Kubelet).
أولاً ، يتم تقديم ما يسمى
" الحاويات المؤقتة " (حاويات سريعة الزوال) ، المصممة لتبسيط عملية تصحيح الأخطاء في القرون . تتيح لك الآلية الجديدة تشغيل حاويات خاصة تبدأ في مساحة الاسم الخاصة بالقرون الموجودة وتعيش لفترة قصيرة. والغرض منها هو التفاعل مع القرون والحاويات الأخرى من أجل حل أي مشاكل وتصحيح الأخطاء. بالنسبة لهذه الميزة ، يتم
kubectl debug أمر
kubectl debug الجديد ، والذي يشبه في جوهره
kubectl exec : فقط بدلاً من بدء العملية في الحاوية (كما في حالة
exec ) ، يبدأ الحاوية في pod. على سبيل المثال ، سيقوم هذا الأمر بتوصيل حاوية جديدة بالقرنة:
kubectl debug -c debug-shell --image=debian target-pod -- bash
يمكن العثور على تفاصيل حول الحاويات المؤقتة (وأمثلة على استخدامها) في
KEP المقابلة . التنفيذ الحالي (في K8s 1.16) هو إصدار ألفا ، ومن بين المعايير لنقله إلى الإصدار التجريبي "اختبار Epimeral Containers API لإصدارين على الأقل [Kubernetes]".
ملاحظة : في جوهرها وحتى اسم الميزة يشبه البرنامج المساعد kubectl-debug الموجود بالفعل ، والذي كتبنا عنه بالفعل . من المفترض أنه مع ظهور الحاويات المؤقتة ، سيتوقف تطوير مكون إضافي خارجي منفصل.تم تصميم ابتكار آخر ،
PodOverhead لتوفير
آلية لحساب التكاليف العامة للقرون ، والتي يمكن أن تختلف اختلافًا كبيرًا اعتمادًا على وقت التشغيل المستخدم. على سبيل المثال ، يستشهد مؤلفو
KEP بحاويات Kata ، التي تتطلب إطلاق kernel الضيف أو وكيل kata أو نظام init ، إلخ. عندما تصبح النفقات العامة كبيرة جدًا ، لا يمكن تجاهلها ، مما يعني أن هناك حاجة إلى طريقة لأخذها في الاعتبار لمزيد من الحصص والتخطيط وما إلى ذلك. لتنفيذه ، تمت إضافة حقل
Overhead *ResourceList إلى
PodSpec (مقارنةً بالبيانات الموجودة في
RuntimeClass ، إذا تم استخدام واحدة).
هناك ابتكار بارز آخر هو
Node Topology Manager ، المصمم لتوحيد النهج لضبط تخصيص موارد الأجهزة لمختلف المكونات في Kubernetes. سبب هذه المبادرة هو الطلب المتزايد من مختلف الأنظمة الحديثة (من مجال الاتصالات السلكية واللاسلكية ، والتعلم الآلي ، والخدمات المالية ، وما إلى ذلك) على الحوسبة المتوازية عالية الأداء والتقليل إلى أدنى حد من التأخير في تنفيذ العمليات ، والتي تستخدم فيها قدرات متقدمة من وحدة المعالجة المركزية وتسريع الأجهزة. لقد تم تحقيق مثل هذه التحسينات في Kubernetes حتى الآن بفضل المكونات المتباينة (مدير وحدة المعالجة المركزية ، إدارة الأجهزة ، CNI) ، والآن ستضيف واجهة داخلية واحدة توحد النهج وتبسط اتصال مكونات جديدة متشابهة - ما يسمى بطبولوجيا الطوبولوجيا - على جانب Kubelet. التفاصيل في
KEP المقابلة .
مخطط مكون مدير الطوبولوجياالميزة التالية هي
فحص الحاويات أثناء بدء التشغيل ( اختبار بدء التشغيل ) . كما تعلمون ، بالنسبة للحاويات التي تعمل لفترة طويلة ، من الصعب الحصول على الوضع الحالي: إما أنها "تُقتل" قبل البدء الفعلي للعملية ، أو ينتهي بها المطاف في طريق مسدود لفترة طويلة. يؤدي إجراء فحص جديد (يتم تمكينه من خلال بوابة الميزات التي يطلق عليها
StartupProbeEnabled ) إلى إلغاء - أو بالأحرى -
StartupProbeEnabled - إجراء أي عمليات تحقق أخرى حتى اللحظة التي تنتهي فيها عملية النشر. لهذا السبب ، كانت الميزة تسمى في الأصل
خاصية إيقاف التشغيل المسبار pod-startup . بالنسبة للقرون التي تستغرق وقتًا طويلاً للبدء ، يمكنك استطلاع الحالة في فترات زمنية قصيرة نسبيًا.
بالإضافة إلى ذلك ، على الفور في حالة تجريبية ، يتم إضافة تحسين لـ RuntimeClass ، مضيفًا دعم "المجموعات غير المتجانسة". باستخدام
RuntimeClass Scheduling ، ليس من الضروري الآن لكل عقدة أن تحصل على دعم لكل RuntimeClass: بالنسبة للقرون ، يمكنك اختيار RuntimeClass دون التفكير في طبولوجيا الكتلة. في السابق ، لتحقيق ذلك - من أجل ظهور القرون على العقد مع دعم كل ما يحتاجون إليه - كان يتعين عليهم تعيين القواعد المناسبة إلى NodeSelector والتحمل. يتحدث
KEP عن أمثلة الاستخدام ، وبطبيعة الحال ، تفاصيل التنفيذ.
شبكة
فيما يلي اثنين من ميزات الشبكة الهامة التي ظهرت لأول مرة (في إصدار ألفا) في Kubernetes 1.16:
- دعم مكدس الشبكة المزدوج - IPv4 / IPv6 - و "الفهم" المقابل له على مستوى القرون والعقد والخدمات. يتضمن تفاعل IPv4 إلى IPv4 و IPv6 إلى IPv6 بين القرون ، من القرون إلى الخدمات الخارجية ، والتطبيقات المرجعية (ضمن إطار Bridge CNI و PTP CNI و IPAM المضيف الإضافي) ، وكذلك العكس متوافق مع مجموعات Kubernetes التي تعمل فقط على IPv4 أو IPv6. تفاصيل التنفيذ في KEP .
مثال على إخراج نوعين من عناوين IP (IPv4 و IPv6) في قائمة البرامج:
kube-master
- API الجديد لـ Endpoint هو EndpointSlice API . إنه يحل مشاكل واجهة برمجة تطبيقات Endpoint الحالية من حيث الأداء / التدرجية التي تؤثر على المكونات المختلفة في مستوى التحكم (apiserver ، etcd ، وحدة التحكم في النهاية ، kube-proxy). ستتم إضافة API الجديدة إلى مجموعة Discovery API وستكون قادرة على تقديم عشرات الآلاف من نقاط النهاية الخلفية على كل خدمة في مجموعة تتكون من ألف عقدة. للقيام بذلك ، يتم تعيين كل خدمة إلى كائنات N
EndpointSlice ، وكل واحدة منها لا تحتوي على أكثر من 100 نقطة نهاية (القيمة قابلة للتكوين). ستوفر واجهة برمجة تطبيقات EndpointSlice أيضًا فرصًا لتطويرها في المستقبل: دعم عناوين IP متعددة لكل جراب ، حالات جديدة لنقاط النهاية (ليس فقط Ready و NotReady ) ، NotReady ديناميكي لنقاط النهاية.
تم
وضع الصيغة النهائية المقدمة في الإصدار الأخير تسمى
service.kubernetes.io/load-balancer-cleanup ومرفقة بكل خدمة بنوع
LoadBalancer تقدم إلى الإصدار التجريبي. في وقت إزالة هذه الخدمة ، يمنع الحذف الفعلي للمورد حتى يتم "تنظيف" جميع الموارد المقابلة للموازن.
آلات API
يتم إصلاح "معلم الاستقرار" الحقيقي في منطقة خادم Kubernetes API والتفاعل معه. في كثير من النواحي ، حدث هذا بسبب
النقل إلى الحالة المستقرة لـ CustomResourceDefinitions (CRD) التي
لم تكن في حاجة إلى عرض تقديمي خاص ، والتي كان لها وضع تجريبي منذ Kubernetes 1.7 البعيد (وهذا هو يونيو 2017!). جاء الاستقرار نفسه إلى الميزات المتعلقة بها:
- "مصادر فرعية" مع
/status و /scale لـ CustomResources ؛ - تحويل نسخة ل CRD ، بناء على webhook خارجي ؛
- أحدث القيم (في K8s 1.15) القيم الافتراضية ( الافتراضية ) وحذف الحقل التلقائي (تشذيب) لـ CustomResources ؛
- إمكانية استخدام نظام OpenAPI v3 لإنشاء ونشر وثائق OpenAPI المستخدمة للتحقق من موارد CRD على جانب الخادم.
هناك آلية أخرى مألوفة منذ فترة طويلة لمسؤولي Kubernetes:
القبول عبر الإنترنت - كما كانت في حالة تجريبية لفترة طويلة (منذ K8s 1.9) وقد تم الإعلان عنها الآن مستقرة.
تم الوصول إلى اثنين من الميزات التجريبية:
تطبيق جانب الخادم ومشاهدة الإشارات المرجعية .
وكان الابتكار المهم الوحيد في إصدار ألفا هو
رفض SelfLink - وهو URI خاص يمثل الكائن المحدد وهو جزء من
ObjectMeta و
ListMeta (أي جزء من أي كائن في Kubernetes). لماذا رفض ذلك؟
يبدو الدافع "البسيط" مثل عدم وجود أسباب حقيقية (لا يمكن التغلب عليها) لهذا الحقل للاستمرار في الوجود. هناك أسباب أكثر رسمية تتمثل في تحسين الأداء (إزالة حقل غير ضروري) وتبسيط عمل generis-apiserver ، الذي يضطر لمعالجة مثل هذا الحقل بطريقة خاصة (هذا هو الحقل الوحيد الذي تم تعيينه قبل تسلسل الكائن). سيحدث "التقادم" الحقيقي (في الإصدار التجريبي) من SelfLink لإصدار Kubernetes 1.20 والأخير - 1.21.
تخزين البيانات
يتم ملاحظة العمل الرئيسي في مجال التخزين ، كما في الإصدارات السابقة ، في مجال
دعم CSI . التغييرات الرئيسية هنا هي:
- لأول مرة (في إصدار ألفا) ، ظهر دعم المكونات الإضافية لـ CSI لعقد عمل Windows : الطريقة الحالية للعمل مع المستودعات ستحل محل الإضافات الموجودة داخل الشجرة في Kubernetes core و FlexVolume المستندة إلى Powershell من Microsoft ؛
Kubernetes ويندوز CSI البرنامج المساعد لتنفيذ مخطط
- نمت القدرة على تغيير حجم وحدات تخزين CSI ، المقدمة في K8s 1.12 ، إلى إصدار تجريبي ؛
- وصلت إمكانية استخدام CSI لإنشاء وحدات التخزين المؤقتة المحلية ( CSI Inline Volume Support ) إلى "زيادة" مماثلة (من ألفا إلى تجريبي).
إن
وظيفة استنساخ وحدات التخزين التي ظهرت في الإصدار السابق من Kubernetes (باستخدام المواد البلاستيكية الحالية كمصدر
DataSource لإنشاء مستندات PVC جديدة) قد حصلت الآن على حالة تجريبية.
مخطط
تغييران ملحوظان في التخطيط (كلاهما في إصدار ألفا):
EvenPodsSpreading هي القدرة على استخدام البرامج "لتوزيع الأحمال" بدلاً من الوحدات المنطقية للتطبيق (مثل النشر و ReplicaSet) وضبط هذا التوزيع (كشرط صارم أو كشرط معتدل ، أي الأولوية). ستعمل هذه الميزة على توسيع قدرات التوزيع الحالية PodAffinity المخطط لها ، والتي أصبحت محدودة الآن PodAffinity و PodAntiAffinity ، مما يمنح المسؤولين مزيدًا من التحكم في هذه المشكلة ، مما يعني إمكانية وصول أفضل واستهلاك أفضل للموارد. التفاصيل في KEP .- استخدام سياسة BestFit في وظيفة RequestedToCapacityRatio ذات الأولوية أثناء جدولة pod ، والتي تسمح باستخدام حاوية التعبئة ("التعبئة في حاويات") في الموارد الأساسية (المعالج ، الذاكرة) والممتدة (مثل GPU). انظر KEP لمزيد من التفاصيل.
جدولة قرنة: قبل استخدام أفضل سياسة ملائمة (مباشرة من خلال المجدول الافتراضي) واستخدامها (عبر موسع المجدول)
بالإضافة إلى ذلك ،
يتم تقديم الفرصة لإنشاء المكونات الإضافية الخاصة بك لجدولة خارج شجرة التطوير الرئيسية Kubernetes (خارج الشجرة).
تغييرات أخرى
أيضًا في إصدار Kubernetes 1.16 ، يمكنك ملاحظة
المبادرة لترتيب المقاييس الحالية بترتيب كامل ، أو بشكل أكثر دقة ، وفقًا
للمتطلبات الرسمية لأجهزة K8s. يعتمدون بشكل أساسي على
وثائق Prometheus ذات الصلة. تشكلت أوجه عدم الاتساق لعدة أسباب (على سبيل المثال ، تم إنشاء بعض المقاييس قبل ظهور الإرشادات الحالية) ، وقرر المطورون أن الوقت قد حان للوصول بكل شيء إلى معيار واحد ، "تمشيا مع بقية النظام البيئي في بروميثيوس." يحتوي التطبيق الحالي لهذه المبادرة على حالة إصدار alpha ، والذي سيزداد تدريجياً في الإصدارات المستقبلية من Kubernetes إلى الإصدار التجريبي (1.17) ومستقر (1.18).
بالإضافة إلى ذلك ، يمكن ملاحظة التغييرات التالية:
- تطوير دعم Windows مع ظهور الأداة المساعدة Kubeadm لنظام التشغيل هذا (إصدار ألفا) ، وإمكانية
RunAsUserName Windows (إصدار ألفا) ، وتحسين دعم حساب خدمة مدارة المجموعة (gMSA) لإصدار تجريبي ، ودعم التحميل / إرفاق وحدات تخزين vSphere. - إعادة تصميم آلية ضغط البيانات في استجابات API . في السابق ، تم استخدام مرشح HTTP لهذه الأغراض ، والتي فرضت عددًا من القيود التي حالت دون إدراجها افتراضيًا. يعمل الآن "ضغط الطلبات الشفافة": يتلقى العملاء الذين يرسلون
Accept-Encoding: gzip في الرأس استجابة مضغوطة في GZIP إذا تجاوز حجمها 128 كيلو بايت. العملاء على الذهاب يدعمون الضغط تلقائيًا (أرسل الرأس المطلوب) ، لذلك يلاحظون انخفاضًا في حركة المرور على الفور. (بالنسبة للغات أخرى ، قد تكون التعديلات الطفيفة مطلوبة.) - أصبح من الممكن توسيع نطاق HPA من / إلى الصفر القرون على أساس المقاييس الخارجية . إذا كان القياس يعتمد على الكائنات / المقاييس الخارجية ، فعندما تكون أحمال العمل في وضع الخمول ، يمكنك القياس تلقائيًا إلى 0 نسخ متماثلة لحفظ الموارد. يجب أن تكون هذه الميزة مفيدة بشكل خاص للحالات التي يطلب فيها العاملون موارد GPU ، وأن يتجاوز عدد الأنواع المختلفة من العمال العاطلين عدد وحدات معالجة الرسومات المتاحة.
- عميل جديد -
k8s.io/client-go/metadata.Client - للوصول "المعمم" إلى الكائنات. وهو مصمم للحصول بسهولة على البيانات التعريفية (أي القسم الفرعي metadata ) من موارد نظام المجموعة وإجراء عمليات معهم من فئة تجميع البيانات المهملة والحصص النسبية. - يمكن الآن إنشاء Kubernetes بدون موفري سحابة عفا عليها الزمن "مدمجون" (إصدار ألفا).
- تمت إضافة القدرة التجريبية (إصدار ألفا) إلى تطبيق تصحيحات مخصصة أثناء عمليات
init join upgrade إلى الأداة المساعدة kubeadm. للحصول على تفاصيل حول كيفية استخدام علامة --experimental-kustomize ، راجع KEP . - نقطة النهاية الجديدة لـ apiserver هي
readyz ، والتي تتيح لك تصدير معلومات الاستعداد. يحتوي خادم واجهة برمجة التطبيقات (API) أيضًا على علامة --maximum-startup-sequence-duration ، والتي تتيح لك ضبط إعادة --maximum-startup-sequence-duration . - تم الإعلان عن ثبات ميزتين لـ Azure : دعم مناطق التوفر ومجموعة الموارد المشتركة (RG). بالإضافة إلى ذلك ، أضاف Azure:
- دعم مصادقة ADAD و ADFS
- الشرح
service.beta.kubernetes.io/azure-pip-name لتحديد عنوان IP العام لموازن التحميل ؛ - القدرة على تكوين
LoadBalancerName و LoadBalancerResourceGroup .
- AWS لديه دعم ل EBS على ويندوز ومكالمات EC2 API المحسنة DescriptionInaterial.
- تقوم Kubeadm الآن بترحيل تكوين CoreDNS من تلقاء نفسها عند الترقية إلى CoreDNS.
- جعل الثنائيات وما إلى ذلك في صورة Docker المقابلة قابلة للتنفيذ على مستوى العالم ، مما يسمح لك بتشغيل هذه الصورة دون الحاجة إلى امتيازات الجذر. بالإضافة إلى ذلك ، أسقطت صورة الترحيل etcd دعمًا لإصدار etcd2.
- تحولت Cluster Autoscaler 1.16.0 إلى استخدام distroless كصورة أساسية ، وتحسين الأداء ، وإضافة موفري سحابة جدد (DigitalOcean ، Magnum ، Packet).
- تحديثات البرامج المستخدمة / المعتمدة: اذهب 1.12.9 ، إلخ 3.3.15 ، CoreDNS 1.6.2.
PS
اقرأ أيضًا في مدونتنا: