سيتم إطلاق سراح Kubernetes -
1.14 هذه الليلة. وفقًا للتقليد الذي تم تطويره لمدونتنا ، فإننا نتحدث عن التغييرات الرئيسية في الإصدار الجديد من هذا المنتج الرائع المصدر المفتوح.
المعلومات المستخدمة لإعداد هذه المادة مأخوذة من
جدول تتبع تحسينات Kubernetes ،
CHANGELOG-1.14 والقضايا ذات الصلة ، طلبات السحب ، Kubernetes Enhancement Proposals (KEP).
تحديث (26 مارس): ظهر
إعلان الإفراج الرسمي أيضًا على مدونة K8s.
دعنا نبدأ بمقدمة مهمة من دورة حياة الكتلة لـ SIG:
يمكن الآن
إنشاء مجموعات Kubernetes
لتجاوز الفشل الديناميكي (وبشكل أكثر دقة ، عمليات نشر HA ذاتية
kubeadm )
kubeadm (في سياق مجموعات أحادية العقدة) المعتادة (في سياق مجموعات واحدة). باختصار ، لهذا:
- يتم نقل الشهادات المستخدمة من قبل الكتلة إلى أسرار ؛
- لإمكانية استخدام مجموعة etcd داخل مجموعة K8s (أي التخلص من التبعية الخارجية الموجودة حتى الآن) ، يتم استخدام المشغل etcd ؛
- يتم توثيق الإعدادات الموصى بها لموازن التحميل الخارجي الذي يوفر تكوينًا يتحمل الأخطاء (في المستقبل ، يتم التخطيط لإمكانية الفشل من هذه التبعية ، ولكن ليس في هذه المرحلة).
بنيت Kubernetes HA كتلة الهندسة المعمارية مع kubeadmيمكن العثور على تفاصيل التنفيذ في
اقتراح التصميم . هذه الميزة كانت طال انتظارها: كان من المتوقع عودة إصدار alpha إلى الإصدار K8 1.9 ، ولكن لم يظهر الآن إلا.
API
يتم نقل الأمر kubectl وإدارة الكائنات التعريفية بشكل عام من
kubectl إلى apiserver. يشرح المطورون أنفسهم باختصار قرارهم بالقول إن
kubectl apply يعد جزءًا أساسيًا من العمل مع التكوينات في Kubernetes ، ومع ذلك ، فهو "مليء بالأخطاء ويصعب إصلاحه" ، وبالتالي يجب استعادة هذه الوظيفة إلى وضعها الطبيعي ونقلها إلى مستوى التحكم. أمثلة بسيطة وتوضيحية لمشاكل اليوم:
تفاصيل التنفيذ في
KEP . التوافر الحالي هو إصدار ألفا (يتم التخطيط للترقية إلى الإصدار التجريبي للإصدار التالي من Kubernetes).
في إصدار ألفا ، أصبحت
القدرة على استخدام نظام OpenAPI v3
لإنشاء ونشر وثائق OpenAPI على CustomResources (CR) المستخدمة للتحقق من موارد K8s المعرفة من جانب المستخدم (CustomResourceDefinition ، CRD). يتيح نشر OpenAPI لـ CRD للعملاء (على سبيل المثال ،
kubectl ) إجراء التحقق من الصحة من جانبهم (كجزء من
kubectl create kubectl apply ) وإصدار وثائق وفقًا للمخطط (
kubectl explain ). التفاصيل في
KEP .
يتم
فتح السجلات الموجودة مسبقًا
الآن مع علامة
O_APPEND (بدلاً من
O_TRUNC ) لتجنب فقد السجلات في بعض الحالات
O_TRUNC مساعدة للتدوير الخارجي.
أيضًا في سياق واجهة برمجة تطبيقات Kubernetes ، تجدر الإشارة إلى أنه في
PodSandbox و
PodSandboxStatus تتم
runtime_handler حقل
PodSandboxStatus لمراعاة معلومات حول
RuntimeClass في pod (اقرأ المزيد عنها في النص
الخاص بإصدار Kubernetes 1.12 ، حيث ظهرت هذه الفئة كإصدار ألفا) طبقت عمليات القبول في Webbooks القدرة على تحديد إصدارات
AdmissionReview التي تدعمها. أخيرًا ، في قواعد القبول في Webhooks ،
يمكنك الآن
تقييد نطاق التطبيق الخاص بهم على مساحة الاسم ونطاق الكتلة.
مرافق التخزين
تم
إعلان PersistentLocalVolumes التي تتمتع بحالة تجريبية منذ إصدار
K8s 1.10 بأنها مستقرة (GA): لن يتم تعطيل بوابة الميزات هذه بعد الآن وسيتم إزالتها في Kubernetes 1.17.
تم تطوير القدرة على استخدام متغيرات البيئة لما يسمى
Downward API (على سبيل المثال ، اسم pod) لأسماء الدليل التي تم تثبيتها على
subPath - في شكل حقل
subPathExpr جديد ، يتم الآن تحديد اسم الدليل المرغوب فيه. في البداية ، ظهرت الميزة في Kubernetes 1.11 ، لكن بالنسبة إلى 1.14 فقد ظلت في حالة إصدار alpha.
كما هو الحال مع إصدار Kubernetes السابق ، يتم إدخال العديد من التغييرات المهمة على CSI (واجهة حاوية التخزين) سريعة التطور:
CSI
أصبح دعم تغيير حجم الدعم لوحدات تخزين CSI متاحًا (كجزء من إصدار ألفا). لاستخدامها ، ستحتاج إلى تمكين بوابة الميزات المسماة
ExpandCSIVolumes ، بالإضافة إلى وجود دعم لهذه العملية في برنامج تشغيل CSI محدد.
ميزة أخرى لـ CSI في إصدار alpha هي
القدرة على الرجوع مباشرة (أي دون استخدام PV / PVC) إلى وحدات تخزين CSI كجزء من مواصفات pod.
يؤدي ذلك إلى
إزالة القيود المفروضة على استخدام CSI كمستودعات بيانات بعيدة بشكل خاص ، مما يفتح الباب أمامهم لعالم
المجلدات المؤقتة المؤقتة . لاستخدام (
مثال من الوثائق ) ، يجب تمكين بوابة ميزة
CSIInlineVolume .
تم إحراز تقدم في "الأجزاء الداخلية" من Kubernetes المتعلقة بـ CSI ، والتي ليست ملحوظة للغاية للمستخدمين النهائيين (مسؤولي النظام) ... في الوقت الحالي ، يضطر المطورون إلى دعم نسختين من كل مكون إضافي للتخزين: واحد "بالطريقة القديمة" ، داخل قاعدة كود K8s (في -tree) ، والثاني - كجزء من CSI الجديد
(اقرأ المزيد عنها ، على سبيل المثال ، هنا ) . هذا يسبب إزعاجًا مفهومًا يحتاج إلى معالجة عند استقرار CSI على هذا النحو. ببساطة ، لا يمكن إهمال واجهة برمجة التطبيقات (API) المهملة للمكونات الإضافية الموجودة داخل الشجرة بسبب
سياسة Kubernetes المقابلة .
كل هذا أدى إلى حقيقة أن إصدار ألفا قد وصل إلى
عملية ترحيل الكود الإضافي الداخلي للمكونات الإضافية المطبقة كإضافات في الإضافات إلى CSI ، نظرًا لتقليل اهتمامات المطورين إلى دعم إصدار واحد من المكونات الإضافية الخاصة بهم ، وسيتم الحفاظ على التوافق مع واجهات برمجة التطبيقات القديمة أعلن عفا عليها الزمن كالمعتاد. من المتوقع أنه بحلول الإصدار التالي من Kubernetes (1.15) ، سيتم ترحيل جميع المكونات الإضافية لمزود الخدمة السحابية ، وسيحصل التطبيق على حالة تجريبية وسيتم تنشيطه في عمليات التثبيت الافتراضية لـ K8s. انظر
اقتراح التصميم للحصول على التفاصيل. نتج عن هذا الترحيل أيضًا
رفض القيود المفروضة على وحدات التخزين المعرّفة من قِبل موفري سحابة معينين (AWS و Azure و GCE و Cinder).
بالإضافة إلى ذلك ، تم
تحويل دعم أجهزة كتلة CSI (
CSIBlockVolume ) إلى إصدار تجريبي.
العقد / Kubelet
قدم نسخة ألفا من
نقطة النهاية الجديدة في Kubelet ، المصممة
لإرجاع مقاييس الموارد الرئيسية . بشكل عام ، إذا اعتاد Kubelet على الحصول على إحصائيات حول استخدام الحاويات من cAdvisor ، فإن هذه البيانات تأتي الآن من وقت تشغيل الحاوية عبر CRI (Container Runtime Interface) ، ولكن يتم الحفاظ على التوافق مع الإصدارات الأقدم من Docker. في السابق ، تم توفير الإحصاءات التي تم جمعها في Kubelet من خلال واجهة برمجة تطبيقات REST ، لكنها تستخدم الآن نقطة النهاية الموجودة على
/metrics/resource/v1alpha1 . تتمثل الإستراتيجية طويلة المدى للمطورين في تقليل مجموعة المقاييس التي توفرها Kubelet.
بالمناسبة ، تسمى هذه المقاييس نفسها الآن "المقاييس الأساسية" ، ولكن "مقاييس الموارد" ، ويتم وصفها بأنها "موارد من الدرجة الأولى ، مثل وحدة المعالجة المركزية والذاكرة".فارق بسيط للغاية: على الرغم من الميزة الواضحة في أداء نقطة نهاية gRPC مقارنةً بالحالات المختلفة لاستخدام تنسيق Prometheus
(نتيجة لأحد المعايير المرجعية أدناه) ، فضل المؤلفون تنسيق نص Prometheus نظرًا للقيادة الواضحة لنظام الرصد هذا في المجتمع.
"GRPC غير متوافق مع خطوط أنابيب المراقبة الرئيسية. لن تكون نقطة النهاية مفيدة إلا لتقديم المقاييس إلى خادم القياسات أو مكونات المراقبة التي تتكامل معها مباشرةً. عند استخدام التخزين المؤقت في خادم القياسات ، يكون أداء تنسيق نص بروميثيوس جيدًا بما فيه الكفاية بالنسبة لنا لتفضيل بروميثيوس على gRPC ، بالنظر إلى الاستخدام الواسع النطاق لبروميثيوس في المجتمع. عندما يصبح تنسيق OpenMetrics أكثر استقرارًا ، يمكننا أن نقترب من أداء gRPC بتنسيق قائم على البروتوكول ".
أحد اختبارات الأداء المقارن باستخدام تنسيقات gRPC و Prometheus في نقطة نهاية Kubelet الجديدة للمقاييس. المزيد من الرسوم البيانية وغيرها من التفاصيل يمكن العثور عليها في KEP .من بين التغييرات الأخرى:
- يقبل Kubelet الآن المعلمة
pid=<number> في الخيارات --kube-reserved ، مما يضمن أن معرّف PID المحدد محجوز للنظام بأكمله أو شياطين نظام Kubernetes ، على التوالي. يتم تنشيط الميزة عند تمكين بوابة الميزة ، والتي تسمى SupportNodePidsLimit . - يحاول Kubelet الآن (مرة واحدة) إيقاف الحاويات في حالة غير معروفة قبل إعادة التشغيل وحذف العمليات.
- عند استخدام
PodPresets ، تتم الآن إضافة نفس المعلومات إلى حاوية init كحاوية عادية. - بدأ Kubelet باستخدام
usageNanoCores من موفر إحصاءات CRI ، وتمت إضافة إحصائيات الشبكة للعُقد والحاويات على Windows. - يتم الآن تسجيل معلومات حول نظام التشغيل
kubernetes.io/arch و kubernetes.io/arch لكائنات العقدة (المنقولة من kubernetes.io/arch التجريبي إلى GA). RunAsGroup القدرة على تحديد مجموعة مستخدمين نظام معين للحاويات في pod ( RunAsGroup ، ظهرت في K8s 1.11 ) إلى الإصدار التجريبي ( ممكّن بشكل افتراضي).- يتم استبدال du وتجد المستخدمة في cAdvisor بواسطة تطبيقات Go.
CLI
تمت
إضافة علامة k إلى وقت تشغيل cli و kubectl للتكامل مع
kustomize (بالمناسبة ، يتم تطويره الآن في مستودع منفصل) ، أي لمعالجة ملفات YAML إضافية من دلائل التخصيص الخاصة (للحصول على تفاصيل حول استخدامها ، راجع
KEP ):
مثال على استخدام بسيط لملف التخصيص (من الممكن أيضًا استخدام أكثر تعقيدًا للتخصيص خلال التراكبات )بالإضافة إلى ذلك:
- تم تحديث شعار kubectl ووثائقه - راجع kubectl.docs.kubernetes.io .
- تمت
kubectl create cronjob أمر kubectl create cronjob الجديد ، والذي يتحدث عن نفسه. - في
kubectl logs يمكنك الآن دمج الإشارات -f ( -f --follow سجلات التدفق) و -l (- تحديد استعلام التسمية). - kubectl تدرس لنسخ الملفات المحددة مع بطاقة البرية.
- تمت إضافة العلامة
kubectl wait إلى الأمر kubectl wait لتحديد جميع الموارد في مساحة الاسم لنوع المورد المحدد. - أعلن آلية البرنامج المساعد مستقرة ل kubectl .
آخر
تلقى حالة مستقرة (GA) الميزات التالية:
- دعم عقد Windows (بما في ذلك Windows Server 2019) ، مما يعني إمكانية تخطيط حاويات Windows Server في Kubernetes (انظر أيضًا KEP ) ؛
ReadinessGate المستخدمة في مواصفات pod لتحديد الشروط الإضافية التي يتم أخذها في الاعتبار في استعداد pod ؛- دعم للصفحات الكبيرة (بوابة الميزة تسمى
HugePages ) ؛ - CustomPodDNS
- PriorityClass API ، Pod Pod & Preemption .
تغييرات أخرى أدخلت في Kubernetes 1.14:
- لم تعد سياسة RBAC الافتراضية توفر الوصول إلى واجهة برمجة التطبيقات
discovery access-review للمستخدمين غير المصادقين. - يتم توفير الدعم الرسمي لـ CoreDNS فقط لنظام التشغيل Linux ، لذلك عند استخدام kubeadm لنشره (CoreDNS) في نظام مجموعة ، يجب أن تعمل العقد فقط في Linux (يتم استخدام nodeSelectors لهذا التحديد).
- يستخدم تكوين CoreDNS الافتراضي الآن المكوّن الإضافي للأمام بدلاً من الوكيل. بالإضافة إلى ذلك ، تمت إضافة ReadinessProbe إلى CoreDNS ، مما يمنع موازنة التحميل على السنفات المقابلة (غير الجاهزة للخدمة).
- في kubeadm ، في مرحلتي
init أو upload-certs ، أصبح من الممكن تحميل الشهادات المطلوبة لتوصيل طائرة التحكم الجديدة بسر kubeadm-certs (يتم استخدام علامة --experimental-upload-certs ). - بالنسبة إلى عمليات تثبيت Windows ، ظهر إصدار ألفا من دعم gMSA (حساب خدمة المدارة الجماعي) - حسابات خاصة في Active Directory ، والتي يمكن استخدامها بواسطة الحاويات.
- بالنسبة إلى الحملة العالمية للتعليم ، تم تنشيط تشفير mTLS بين etcd و kube-apiserver.
- تحديثات البرامج المستخدمة / المعتمدة: دعم Go 1.12.1 و CSI 1.1 و CoreDNS 1.3.1 و Docker 18.09 في kubeadm والحد الأدنى للنسخة المعتمدة من Docker API هو 1.26.
PS
اقرأ أيضًا في مدونتنا: