Kubernetes 1.14: إبراز الميزات الجديدة

هذه الليلة عقد الإصدار القادم من Kubernetes - 1.14. وفقا للتقليد الذي تم تطويره لمدونتنا، فإننا نتحدث عن التغييرات الرئيسية في الإصدار الجديد من هذا المنتج الرائع مفتوح المصدر.

المعلومات المستخدمة لإعداد هذه المادة مأخوذة من تحسينات Kubernetes لجداول التتبع, سجل التغيير-1.14 والمشكلات ذات الصلة وطلبات السحب ومقترحات تحسين Kubernetes (KEP).

لنبدأ بمقدمة مهمة من دورة حياة مجموعة SIG: مجموعات تجاوز الفشل الديناميكية Kubernetes (أو لنكون أكثر دقة، عمليات نشر HA ذاتية الاستضافة) أصبحت الآن ثستطيع ان تخلق باستخدام أوامر مألوفة (في سياق مجموعات العقدة الواحدة). kubeadm (init и join). باختصار لهذا:

• يتم نقل الشهادات التي تستخدمها المجموعة إلى الأسرار؛
• لإمكانية استخدام مجموعة etcd داخل مجموعة K8s (أي التخلص من التبعية الخارجية الموجودة سابقاً) etcd-operator;
• توثيق الإعدادات الموصى بها لموازن التحميل الخارجي الذي يوفر تكوينًا متسامحًا مع الأخطاء (من المخطط في المستقبل التخلص من هذه التبعية، ولكن ليس في هذه المرحلة).

بنية مجموعة Kubernetes HA التي تم إنشاؤها باستخدام kubeadm

تفاصيل التنفيذ تجدونها في اقتراح تصميم. لقد طال انتظار هذه الميزة حقًا: كان من المتوقع ظهور إصدار ألفا مرة أخرى في K8s 1.9، ولكنه ظهر الآن فقط.

API

فريق apply وبشكل عام إدارة الكائنات التصريحية اجتاز من kubectl في خادم أبي. يشرح المطورون أنفسهم قرارهم بإيجاز بقول ذلك kubectl apply - جزء أساسي من العمل مع التكوينات في Kubernetes، ومع ذلك، "فهو مليء بالأخطاء ويصعب إصلاحه"، وبالتالي يجب إعادة هذه الوظيفة إلى وضعها الطبيعي ونقلها إلى مستوى التحكم. أمثلة بسيطة وواضحة للمشاكل الموجودة اليوم:

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

متاحة في نسخة ألفا فرصة باستخدام مخطط OpenAPI v3 لـ إنشاء ونشر وثائق OpenAPI لـ CustomResources (CR) يُستخدم للتحقق من صحة موارد K8 المحددة (من جانب الخادم) (CustomResourceDefinition، CRD). يتيح نشر OpenAPI لـ CRD للعملاء (على سبيل المثال. kubectl) إجراء التحقق من جانبك (داخل kubectl create и kubectl apply) وإصدار الوثائق وفقا للمخطط (kubectl explain). التفاصيل - في KEP.

السجلات الموجودة مسبقًا يتم فتحها الآن مع العلم O_APPEND (لكن لا O_TRUNC) لتجنب فقدان السجلات في بعض المواقف ولتسهيل اقتطاع السجلات باستخدام أدوات مساعدة خارجية للتدوير.

أيضًا في سياق Kubernetes API، يمكن الإشارة إلى أنه في PodSandbox и PodSandboxStatus وأضاف حقل runtime_handler لتسجيل معلومات عنها RuntimeClass في الكبسولة (اقرأ المزيد عنها في النص حول إصدار كوبيرنيت 1.12، حيث ظهر هذا الفصل كإصدار ألفا)، وفي Webhooks للقبول مُنفّذ القدرة على تحديد الإصدارات AdmissionReview هم يساندون. أخيرًا، أصبحت قواعد Webhooks للقبول الآن يمكن أن تكون محدودة مدى استخدامها من قبل مساحات الأسماء وأطر الكتلة.

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

PersistentLocalVolumes، والتي كانت في حالة تجريبية منذ إصدارها K8s 1.10, معلن مستقر (GA): لم تعد بوابة الميزات هذه معطلة وستتم إزالتها في Kubernetes 1.17.

فرصة باستخدام متغيرات البيئة تسمى واجهة برمجة التطبيقات الهبوطية (على سبيل المثال، اسم pod) لأسماء الدلائل المثبتة كـ subPathتم تطويره - في شكل مجال جديد subPathExpr، والذي يُستخدم الآن لتحديد اسم الدليل المطلوب. ظهرت هذه الميزة في البداية في الإصدار 1.11 من Kubernetes، ولكن بالنسبة للإصدار 1.14 ظلت في حالة إصدار ألفا.

كما هو الحال مع إصدار Kubernetes السابق، تم إدخال العديد من التغييرات المهمة على CSI (واجهة تخزين الحاويات) التي يتم تطويرها بشكل نشط:

سي أيس آئي

أصبح متاحًا (كجزء من إصدار ألفا) دعم تغيير الحجم لأحجام CSI. لاستخدامه سوف تحتاج إلى تمكين بوابة الميزة تسمى ExpandCSIVolumesبالإضافة إلى وجود دعم لهذه العملية في برنامج تشغيل CSI محدد.

ميزة أخرى لـ CSI في إصدار ألفا - فرصة قم بالرجوع مباشرة (أي بدون استخدام PV/PVC) إلى وحدات تخزين CSI ضمن مواصفات الكبسولة. هذا يزيل القيود المفروضة على استخدام CSI كمخزن للبيانات عن بعد حصريًاوفتح الأبواب أمام العالم لهم مجلدات سريعة الزوال المحلية. للاستخدام (مثال من التوثيق) يجب تمكينه CSIInlineVolume بوابة الميزة.

كان هناك أيضًا تقدم في "الأجزاء الداخلية" لـ Kubernetes المتعلقة بـ CSI، والتي ليست مرئية جدًا للمستخدمين النهائيين (مسؤولي النظام) ... حاليًا، يضطر المطورون إلى دعم نسختين من كل مكون إضافي للتخزين: واحد - "في الطريقة القديمة"، داخل قاعدة بيانات K8s (في الشجرة)، والثانية - كجزء من CSI الجديد (اقرأ المزيد عنها، على سبيل المثال، في هنا). وهذا يسبب مضايقات مفهومة تحتاج إلى معالجة مع استقرار CSI نفسها. ليس من الممكن ببساطة إهمال واجهة برمجة التطبيقات (API) للمكونات الإضافية الداخلية (داخل الشجرة) بسبب سياسة Kubernetes ذات الصلة.

كل هذا أدى إلى وصول نسخة ألفا عملية الهجرة رمز البرنامج المساعد الداخلي، تم تنفيذه على شكل شجرة في المكونات الإضافية لـ CSI، وبفضل ذلك سيتم تقليل مخاوف المطورين إلى دعم إصدار واحد من المكونات الإضافية الخاصة بهم، وسيظل التوافق مع واجهات برمجة التطبيقات القديمة ويمكن الإعلان عن أنها قديمة في السيناريو المعتاد. من المتوقع أنه بحلول الإصدار التالي من Kubernetes (1.15) سيتم ترحيل جميع المكونات الإضافية لموفر الخدمة السحابية، وسيتلقى التنفيذ حالة تجريبية وسيتم تنشيطه في عمليات تثبيت K8s افتراضيًا. لمزيد من التفاصيل، انظر اقتراح تصميم. كما أدت هذه الهجرة فشل من حدود الحجم التي يحددها موفرو الخدمات السحابية المحددون (AWS، وAzure، وGCE، وCinder).

بالإضافة إلى ذلك، دعم أجهزة الحظر مع CSI (CSIBlockVolume) نقل إلى الإصدار التجريبي.

العقد/Kubelet

تم تقديم نسخة ألفا نقطة نهاية جديدة في كوبيليت، مصممة ل مقاييس العائد على الموارد الرئيسية. بشكل عام، إذا كان Kubelet قد تلقى سابقًا إحصائيات حول استخدام الحاوية من cAdvisor، فإن هذه البيانات تأتي الآن من بيئة تشغيل الحاوية عبر CRI (واجهة تشغيل الحاوية)، ولكن يتم أيضًا الحفاظ على التوافق للعمل مع الإصدارات الأقدم من Docker. في السابق، تم إرسال الإحصائيات التي تم جمعها في Kubelet عبر REST API، ولكن الآن تقع نقطة النهاية في /metrics/resource/v1alpha1. استراتيجية طويلة المدى للمطورين غير هو تقليل مجموعة المقاييس التي تقدمها Kubelet. بالمناسبة، هذه المقاييس نفسها الآن يتصلون ليست "المقاييس الأساسية"، ولكن "مقاييس الموارد"، وتوصف بأنها "موارد من الدرجة الأولى، مثل وحدة المعالجة المركزية والذاكرة".

فارق بسيط مثير للاهتمام: على الرغم من ميزة الأداء الواضحة لنقطة نهاية gRPC مقارنة بالحالات المختلفة لاستخدام تنسيق Prometheus (انظر نتيجة أحد المعايير أدناه)، فضل المؤلفون تنسيق نص بروميثيوس بسبب القيادة الواضحة لنظام المراقبة هذا في المجتمع.

"gRPC غير متوافق مع خطوط أنابيب المراقبة الرئيسية. ستكون نقطة النهاية مفيدة فقط لتقديم المقاييس إلى Metrics Server أو مراقبة المكونات التي تتكامل معها مباشرةً. أداء تنسيق نص Prometheus عند استخدام التخزين المؤقت في Metrics Server جيد بما فيه الكفاية بالنسبة لنا أن نفضل Prometheus على gRPC نظرًا لاعتماد Prometheus على نطاق واسع في المجتمع. بمجرد أن يصبح تنسيق OpenMetrics أكثر استقرارًا، سنكون قادرين على التعامل مع أداء gRPC باستخدام تنسيق قائم على النموذج الأولي."

أحد اختبارات الأداء المقارن لاستخدام تنسيقات gRPC وPrometheus في نقطة نهاية Kubelet الجديدة للمقاييس. يمكن العثور على مزيد من الرسوم البيانية والتفاصيل الأخرى في KEP.

ومن بين التغييرات الأخرى:

• كوبيليت الآن (مرة واحدة) تحاول التوقف الحاويات في حالة غير معروفة قبل إعادة التشغيل وحذف العمليات.
• عند استخدام PodPresets الآن إلى حاوية الحرف الأول يضاف نفس المعلومات الخاصة بالحاوية العادية.
• kubelet بدأ باستخدام usageNanoCores من موفر إحصائيات CRI، وللعقد والحاويات على نظام التشغيل Windows مضاف إحصائيات الشبكة.
• يتم الآن تسجيل معلومات نظام التشغيل والهندسة المعمارية في الملصقات kubernetes.io/os и kubernetes.io/arch كائنات العقدة (المنقولة من النسخة التجريبية إلى GA).
• القدرة على تحديد مجموعة مستخدمين محددة للنظام للحاويات الموجودة في الكبسولة (RunAsGroup، ظهر في K8s 1.11) متقدم قبل الإصدار التجريبي (ممكّن افتراضيًا).
• du والعثور عليه مستخدمًا في cAdvisor، استبدال على تنفيذ الذهاب.

CLI

في وقت التشغيل cli وkubectl مضاف علامة -k للتكامل مع تخصيص (بالمناسبة، يتم تطويره الآن في مستودع منفصل)، أي. لمعالجة ملفات YAML إضافية من أدلة التخصيص الخاصة (لمزيد من التفاصيل حول استخدامها، راجع KEP):

مثال على استخدام ملف بسيط التخصيص (من الممكن تطبيق أكثر تعقيدًا لـ kustomize داخل التراكبات)

وبالإضافة إلى ذلك:

• أضيفت بواسطة فريق جديد kubectl create cronjob، الذي اسمه يتحدث عن نفسه.
• В kubectl logs الآن انت تستطيع للجمع الأعلام -f (--follow لسجلات التدفق) و -l (--selector للاستعلام عن التسمية).
• kubectl مُدَرّس نسخ الملفات المحددة بواسطة البطاقة البرية.
• الى الفريق kubectl wait مضاف علم --all لتحديد كافة الموارد في مساحة الاسم لنوع المورد المحدد.

آخرون

حصلت الإمكانات التالية على حالة مستقرة (GA):

• ReadinessGateتستخدم في مواصفات الكبسولة لتحديد الشروط الإضافية التي تؤخذ في الاعتبار عند جاهزية الكبسولة؛
• دعم الصفحات الكبيرة (بوابة الميزة تسمى HugePages);
• CustomPodDNS;
• واجهة برمجة تطبيقات فئة الأولوية جراب الأولوية والشفعة.

التغييرات الأخرى التي تم إدخالها في Kubernetes 1.14:

• لم تعد سياسة RBAC الافتراضية تسمح بالوصول إلى واجهة برمجة التطبيقات (API). discovery и access-review المستخدمين دون مصادقة (غير مصادق عليه).
• دعم CoreDNS الرسمي قدمت Linux فقط، لذلك عند استخدام kubeadm لنشره (CoreDNS) في مجموعة، يجب أن تعمل العقد فقط على Linux (يتم استخدام nodeSelectors لهذا القيد).
• التكوين الافتراضي لـ CoreDNS هو الآن الاستخدامات البرنامج المساعد إلى الأمام بدلا من الوكيل. أيضا، في CoreDNS مضاف ReadyProbe، الذي يمنع موازنة التحميل على القرون المناسبة (غير الجاهزة للخدمة).
• في kubeadm، على مراحل init أو upload-certs, أصبح ممكنا قم بتحميل الشهادات المطلوبة لتوصيل مستوى التحكم الجديد بسر kubeadm-certs (استخدم العلامة --experimental-upload-certs).
• ظهرت نسخة ألفا لعمليات تثبيت Windows دعم gMSA (حساب الخدمة المُدارة للمجموعة) - حسابات خاصة في Active Directory يمكن استخدامها أيضًا بواسطة الحاويات.
• بالنسبة لـ G.C.E. مفعل تشفير mTLS بين etcd وkube-apserver.
• التحديثات في البرامج المستخدمة/التابعة: دعم Go 1.12.1 وCSI 1.1 وCoreDNS 1.3.1 وDocker 18.09 في kubeadm، والحد الأدنى المدعوم لإصدار Docker API هو 1.26 الآن.

PS

اقرأ أيضًا على مدونتنا:

• «Kubernetes 1.13: إبراز الميزات الجديدة"؛
• «Kubernetes 1.12: إبراز الميزات الجديدة"؛
• «Kubernetes 1.11: إبراز الميزات الجديدة"؛
• «Kubernetes 1.10: إبراز الميزات الجديدة".

المصدر: www.habr.com