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

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

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

التوجيه المدرك للطوبولوجيا

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

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

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

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

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

مثل هذا التوجيه، الذي "يعرف" عن الهيكل، يسمى أيضًا تقارب الشبكة - قياسًا على تقارب العقدة, جراب تقارب / مكافحة تقارب أو ظهرت قبل مدة ليست ببعيدة طوبولوجيا علم جدولة الحجم (و توفير الحجم). مستوى التنفيذ الحالي ServiceTopology في Kubernetes - إصدار ألفا.

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

دعم IPv4/IPv6 المزدوج

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

في وكيل kube مُنفّذ إمكانية التشغيل المتزامن في كلا الوضعين (IPv4 وIPv6)؛
в Pod.Status.PodIPs ظهر دعم واجهة برمجة التطبيقات (API) الهبوطية (في نفس الوقت كما في /etc/hosts والآن يطلبون من المضيف إضافة عنوان IPv6)؛
دعم المكدس المزدوج طيب القلب (Kubernetes في دوكر) و com.kubeadm;
اختبارات e2e المحدثة.

توضيح باستخدام المكدس المزدوج IPV4/IPv6 في KIND

التقدم في CSI

أعلن مستقرة دعم الطوبولوجيا للتخزين المعتمد على CSI، والذي تم تقديمه لأول مرة في K8s 1.12.

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

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

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

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

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

في وقت الإصدار 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

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

الناتج المنظم من kubeadm

قدمت في نسخة ألفا لأول مرة إخراج منظم للأداة المساعدة kubeadm. التنسيقات المدعومة: قالب JSON وYAML وGo.

الدافع لتطبيق هذه الخاصية (حسب KEP) يكون:

بينما يمكن نشر Kubernetes يدويًا، فإن المعيار الفعلي (إن لم يكن قانونيًا) لهذه العملية هو استخدام kubeadm. تعتمد أدوات إدارة الأنظمة الشائعة مثل Terraform على kubeadm لنشر Kubernetes. تتضمن التحسينات المخططة لـ Cluster API حزمة قابلة للتركيب لـ Kubernetes bootstrapping باستخدام 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) تمت معالجتها بالفعل بواسطة المراقبة؛
قيم افتراضية (الافتراضي) للموارد المخصصة؛
المشتركة بين الحاويات في مساحات أسماء عملية الكبسولة؛
ScheduleDaemonSetPods - جدولة القرون في DaemonSet باستخدام جدولة kube (بدلاً من وحدة تحكم DaemonSet)؛
الحدود الديناميكية على عدد المجلدات حسب نوع العقدة؛
دعم متغير البيئة لأسماء الدليل المثبتة كـ subPath;
نقل نبضات القلب كوبيليت إلى واجهة برمجة تطبيقات الإيجار المتخصصة؛
"حماية اللمسات النهائية" (حماية اللمسات النهائية) لموازنات التحميل (التحقق من موارد الخدمة المقابلة قبل حذف موارد LoadBalancer)؛
تحسين kube-apiserver في الأداء عند العمل مع ساعات متعددة لمراقبة مجموعات متطابقة من الكائنات - يتم تحقيق ذلك عن طريق تجنب التسلسل المتكرر لنفس الكائنات لكل مراقب.

تغييرات أخرى

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

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

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

إصدار CoreDNS المضمن في kubeadm هو 1.6.5؛
تم تحديث إصدار crictl إلى الإصدار v1.16.1؛
منظمة التضامن المسيحي الدولية 1.2.0؛
إلخ 3.4.3؛
تمت ترقية أحدث إصدار من Docker تم اختباره إلى 19.03؛
الحد الأدنى لإصدار Go المطلوب لإنشاء Kubernetes 1.17 هو 1.13.4.

PS

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

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

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