🤰🏿 🥠 👩🏼‍🤝‍👨🏾 Kubernetes 1.17: نظرة عامة على الابتكارات الرئيسية 🆑 🏇🏼 🎒

أمس ، 9 ديسمبر ، الإصدار التالي من Kubernetes - 1.17. وفقًا لتقليد مدونتنا ، نتحدث عن أهم التغييرات في الإصدار الجديد.

المعلومات المستخدمة لإعداد هذه المواد مأخوذة من الإعلان الرسمي ، جدول تتبع تحسينات Kubernetes ، CHANGELOG-1.17 والقضايا ذات الصلة ، طلبات السحب ، وكذلك مقترحات تحسين Kubernetes (KEP). إذن ما الجديد؟

الطوبولوجيا القائمة على التوجيه

لفترة طويلة ، كان مجتمع Kubernetes ينتظر هذه الميزة - توجيه الخدمة على علم الطوبولوجيا . إذا كانت KEP تستند إلى ذلك في أكتوبر 2018 ، وكان التعزيز الرسمي قبل عامين ، فالمشكلات المعتادة (مثل هذا ) أكبر من ذلك بسنوات قليلة ...

تتلخص الفكرة العامة في توفير القدرة على تنفيذ التوجيه "المحلي" للخدمات الموجودة في Kubernetes. "محلية" في هذه الحالة تعني "نفس المستوى الطوبولوجي" (مستوى الهيكل) ، والذي قد يكون:

نفس العقدة للخدمات ،
رف الخادم نفسه
نفس المنطقة
نفس مزود السحابة
...

أمثلة على استخدام هذه الميزة:

التوفير على حركة المرور في المنشآت السحابية مع العديد من مناطق التوافر (متعدد الألف إلى الياء) - انظر أحدث التوضيح على سبيل المثال من حركة المرور من منطقة واحدة ، ولكن من الألف إلى الياء مختلفة في AWS ؛
كمون أقل في الأداء / إنتاجية أفضل ؛
خدمة مظللة بها معلومات عقدة محلية في كل قشرة ؛
وضع fluentd (أو نظائرها) على عقدة واحدة مع التطبيقات التي يتم جمع سجلاتها ؛
...

يسمى هذا التوجيه ، "معرفة" حول الهيكل ، تقارب الشبكة - على غرار تقارب العقدة ، تقارب pod / مكافحة التقارب أو جدولة وحدة تخزين طبولوجيا - علم المدخل التي تم تقديمها مؤخرًا ( وتزويد وحدة التخزين ). مستوى التنفيذ الحالي لـ ServiceTopology في Kubernetes هو إصدار ألفا.

للحصول على تفاصيل حول كيفية ترتيب الميزة وكيف يمكن استخدامها بالفعل ، اقرأ هذه المقالة من أحد المؤلفين.

IPv4 / IPv6 دعم مكدس مزدوج

تم تسجيل تقدم كبير في ميزة شبكة أخرى: الدعم المتزامن لمجموعتي بروتوكولات IP ، والتي تم تقديمها لأول مرة في K8s 1.16 . على وجه الخصوص ، أحدث الإصدار الجديد التغييرات التالية:

تطبق kube-proxy إمكانية التشغيل المتزامن في كلا الوضعين (IPv4 و IPv6) ؛
ظهر دعم واجهة برمجة التطبيقات لأسفل في Pod.Status.PodIPs (في الوقت نفسه ، تتطلب /etc/hosts الآن إضافة عنوان IPv6 للمضيف) ؛
دعم مجموعتين في KIND (Kubernetes IN Docker) و kubeadm ؛
تحديث اختبارات e2e.

نوع IPV4 / IPv6 التوضيح المزدوج المكدس

تقدم CSI

تم الإعلان عن دعم طوبولوجيا المستودعات القائمة على CSI ، والتي تم تقديمها لأول مرة في K8s 1.12 ، بشكل مستقر .

CSI Migration Volume Plugins - CSI Migration - Reached Beta. هذه الميزة مهمة للغاية من أجل نقل المكونات الإضافية الموجودة داخل الشجرة إلى واجهة حديثة (CSI ، خارج الشجرة) دون أن يلاحظها المستخدمون Kubernetes النهائيون. سيكون كافياً لمسؤولي نظام المجموعة لتنشيط CSI Migration ، وبعد ذلك ستظل موارد الحالة الفعلية وأعباء العمل "تعمل فقط" ... لكن باستخدام برامج تشغيل CSI الحالية بدلاً من برامج التشغيل القديمة المضمنة في نواة Kubernetes.

في الوقت الحالي ، حالة الترحيل الخاصة kubernetes.io/aws-ebs تشغيل AWS EBS ( kubernetes.io/aws-ebs ) و GCE PD ( kubernetes.io/gce-pd ) جاهزة في حالة النسخة التجريبية. فيما يلي توقعات المستودعات الأخرى:

كيف جاء دعم التخزين "التقليدي" في K8s إلى CSI ، تحدثنا عنها في هذا المقال . يكرس الانتقال إلى ترحيل CSI في حالة تجريبية لمنشور منفصل على مدونة المشروع.

بالإضافة إلى ذلك ، تم الوصول إلى حالة الإصدار التجريبي (أي ، التضمين بشكل افتراضي) في إصدار Kubernetes 1.17 بواسطة وظيفة هامة أخرى في سياق CSI ، والتي نشأت في (تطبيق alpha) في K8s 1.12 - إنشاء لقطات واستعادة منها . من بين التغييرات التي تم إجراؤها في Kubernetes Volume Snapshot في الطريق إلى الإصدار التجريبي:

انقسام sidecar CSI الخارجية اللقطة إلى جهازي تحكم ،
إضافة سر الحذف كتعليق توضيحي على محتويات لقطة وحدة التخزين ،
أداة نهائية جديدة لمنع إزالة كائن واجهة برمجة تطبيقات لقطة إذا كان هناك أي اتصالات المتبقية.

في وقت الإصدار 1.17 ، كانت الميزة مدعومة من قبل ثلاثة برامج تشغيل CSI: GCE Persistent Disk CSI Driver ، Portworx CSI Driver و NetApp Trident CSI Driver. يمكنك قراءة المزيد حول تنفيذه واستخدامه في منشور المدونة هذا .

سحابة مزود العلامات

تم توفير التسميات ، التي يتم تعيينها تلقائيًا للعُقد والمجلدات التي تم إنشاؤها بناءً على الموفر السحابي المستخدم ، في Kubernetes كإصدار تجريبي لفترة طويلة جدًا - بدءًا من إصدار K8s 1.2 (أبريل 2016!) . نظرًا لاستخدامها على نطاق واسع لفترة طويلة ، قرر المطورون أن الوقت قد حان لإعلان أن الميزة مستقرة (GA).

لذلك ، تم إعادة تسمية جميعهم وفقًا لذلك (حسب الهيكل):

beta.kubernetes.io/instance-type → node.kubernetes.io/instance-type
failure-domain.beta.kubernetes.io/zone → topology.kubernetes.io/zone
failure-domain.beta.kubernetes.io/region → topology.kubernetes.io/region

... ولكن لا تزال متاحة بأسمائها القديمة (للتوافق مع الإصدارات السابقة). ومع ذلك ، يتم تشجيع جميع المسؤولين على التبديل إلى التصنيفات الحالية. تم تحديث وثائق K8 ذات الصلة .

kubeadm الناتج منظم

في تنسيق ألفا ، يتم تقديم الإخراج المهيكل للأداة المساعدة kubeadm لأول مرة. التنسيقات المدعومة: JSON ، YAML ، Go-template.

الدافع لتنفيذ هذه الميزة (وفقًا لـ KEP ) هو كما يلي:

على الرغم من إمكانية نشر Kubernetes يدويًا ، فإن المعيار الفعلي (إن لم يكن قانونيًا) لهذه العملية هو استخدام kubeadm. تعتمد أدوات إدارة النظام الشائعة مثل Terraform على kubeadm لنشر Kubernetes. تتضمن التحسينات المجدولة على Cluster API حزمة قابلة للتثبيت من أجل التمهيد Kubernetes باستخدام kubeadm و cloud-init.

بدون الإخراج المنظم ، حتى التغييرات الأكثر حميدة للوهلة الأولى يمكنها كسر Terraform و Cluster API والبرامج الأخرى التي تستخدم نتائج kubeadm.

في المستقبل القريب ، يظهر الدعم (في شكل مخرجات منظمة) لأوامر kubeadm التالية:

alpha certs
config images list
init
token create
token list
upgrade plan
version

شكل توضيحي لاستجابة JSON kubeadm init -o json :

 { "node0": "192.168.20.51:443", "caCrt": "sha256:1f40ff4bd1b854fb4a5cf5d2f38267a5ce5f89e34d34b0f62bf335d74eef91a3", "token": { "id": "5ndzuu.ngie1sxkgielfpb1", "ttl": "23h", "expires": "2019-05-08T18:58:07Z", "usages": [ "authentication", "signing" ], "description": "The default bootstrap token generated by 'kubeadm init'.", "extraGroups": [ "system:bootstrappers:kubeadm:default-node-token" ] }, "raw": "Rm9yIHRoZSBhY3R1YWwgb3V0cHV0IG9mIHRoZSAia3ViZWFkbSBpbml0IiBjb21tYW5kLCBwbGVhc2Ugc2VlIGh0dHBzOi8vZ2lzdC5naXRodWIuY29tL2FrdXR6LzdhNjg2ZGU1N2JmNDMzZjkyZjcxYjZmYjc3ZDRkOWJhI2ZpbGUta3ViZWFkbS1pbml0LW91dHB1dC1sb2c=" }

استقرار الابتكارات الأخرى

بشكل عام ، تم إطلاق Kubernetes 1.17 تحت شعار " الاستقرار ". تم تسهيل ذلك من خلال حقيقة أن العديد من الميزات الموجودة فيه (إجمالي عددهم 14 ) حصلت على حالة GA. من بين هؤلاء:

العقد "وضع العلامات" تحت شروط معينة ( TaintNodesByCondition ) ، والتي ظهرت في K8s 1.8 ؛
مشاهدة الإشارات المرجعية - نوع جديد من الأحداث مع تسمية بمعالجة جميع الكائنات حتى إصدار معين ( resourceVersion ) بالفعل عن طريق المشاهدة ؛
القيم الافتراضية للموارد المخصصة ؛
مشترك بين الحاويات في مساحات الأسماء العملية pod؛
ScheduleDaemonSetPods - جدولة القرون في DaemonSet باستخدام kube-scheduler (بدلاً من وحدة التحكم DaemonSet) ؛
حدود ديناميكية على عدد وحدات التخزين اعتمادا على نوع العقدة ؛
دعم متغيرات البيئة لأسماء الدليل التي تم تحميلها على أنها subPath ؛
نقل نبضات Kubelet إلى API Lease المتخصصة ؛
" حماية Finalizer " لموازنات التحميل (التحقق من موارد الخدمة المقابلة قبل حذف موارد LoadBalancer) ؛
يتم تحقيق أمثلية kube-apiserver في الأداء عند العمل مع ساعات متعددة تراقب مجموعات مماثلة من الكائنات عن طريق تجنب إعادة إجراء تسلسل لنفس الكائنات لكل مراقب.

تغييرات أخرى

القائمة الكاملة للابتكارات في Kubernetes 1.17 ، بالطبع ، لا تقتصر على تلك المذكورة أعلاه. فيما يلي البعض الآخر ( وللاطلاع على قائمة أكثر اكتمالاً - راجع CHANGELOG ):

النسخة التجريبية من RunAsUserName for Windows المقدمة في الإصدار السابق قد RunAsUserName لتصبح النسخة التجريبية ؛
تغيير مماثل يحل محل واجهة برمجة تطبيقات EndpointSlice (أيضًا من K8s 1.16) ، ولكن حتى الآن لم يتم تنشيط هذا الحل لتحسين الأداء / قابلية تطوير واجهة برمجة تطبيقات Endpoint افتراضيًا ؛
يمكن الآن إنشاء قرون حرجة لتشغيل نظام المجموعة ليس فقط في مساحات أسماء kube-system (انظر الوثائق الخاصة باستهلاك حد فئة الأولوية للحصول على التفاصيل) ؛
يتيح لك خيار جديد لـ kubelet - - المحفوظة - --reserved-cpus - تحديد قائمة وحدات المعالجة المركزية (CPU) المخصصة للنظام بشكل صريح ؛
بالنسبة kubectl logs ، يتم تقديم علامة جديدة - البادئة ، مضيفةً اسم الجراب والحاوية المصدر إلى كل سطر من السجل ؛
في label.Selector المضافة RequiresExactMatch label.Selector ؛
جميع الحاويات في kube-dns تعمل الآن بامتيازات أقل ؛
يتم تخصيص hyperkube لمستودع GitHub منفصل ولن يتم تضمينه في إصدارات Kubernetes ؛
تحسن كبير في أداء وكيل kube لمنافذ غير UDP.

تغييرات التبعية:

إصدار CoreDNS في kubeadm - 1.6.5 ؛
إصدار crictl المحدث إلى v1.16.1 ؛
CSI 1.2.0 ؛
إلخ 3.4.3 ؛
تمت ترقية أحدث إصدار تم اختباره من Docker إلى 03/19 ؛
الحد الأدنى من إصدار Go المطلوب لبناء Kubernetes 1.17 هو 1.13.4.

PS

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

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