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

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



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

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



وفي الوقت نفسه ، قام المتحمسون من فريق SUSE بإعداد سحابة كلمات استنادًا إلى ملاحظات الإصدار للالتزامات 3412 التي تم إجراؤها لـ K8s 1.18. واتضح مثل هذا:



الآن - حول ما وراء هذه الكلمات ، في شكل أكثر قابلية للفهم للمستخدمين.

المجدول


الابتكار الرئيسي هنا - هو ملفات تعريف التخطيط (جدولة الملامح) . وهو مرتبط بحقيقة أنه كلما أصبحت أعباء العمل غير المتجانسة في المجموعة ، كلما كانت الحاجة إلى مناهج مختلفة للتخطيط أسرع.

لحل هذه المشكلة ، يقترح المؤلفون أن المجدول يستخدم تكوينات مختلفة مخصصة للجدولة وتسمى ملفات التعريف. بداية ، يقوم kube-Scheduler بمسح جميع الملفات الشخصية المتاحة وحفظها في التسجيل. إذا لم تكن هناك ملفات شخصية في التكوين ، فسيتم تحديد الخيار الافتراضي ( default-scheduler). بعد وجود القرون في قائمة الانتظار ، ينفذ مجدول kube تخطيطه مع مراعاة المجدول المحدد.

تخطيط سياسة سامي على أساس المسند ( PodFitsResources، PodMatchNodeSelector،PodToleratesNodeTaintsالخ) والأولويات ( SelectorSpreadPriority، InterPodAffinityPriority، MostRequestedPriority، EvenPodsSpreadPriorityالخ). يوفر التنفيذ على الفور نظامًا من المكونات الإضافية بحيث تتم إضافة جميع الملفات الشخصية من خلال إطار عمل خاص.

هيكل التكوين الحالي (سيتم تغييره قريبًا):

type KubeSchedulerConfiguration struct {
   ...
   SchedulerName string
   AlgorithmSource SchedulerAlgorithmSource
   HardPodAffinitySymmetricWeight
   Plugins *Plugins
   PluginConfig []PluginConfig
   ...
}

... وإعداد مثال:

profiles:
  - schedulerName: 'default-scheduler'
    pluginConfig:
      - name: 'InterPodAffinity'
      - args:
          hadPodAffinityWeight: <value>

بحلول الإصدار التالي من K8s ، من المتوقع أن تترجم الميزة إلى بيتا ، وبعد اثنين آخرين - التثبيت. لمزيد من المعلومات حول ملفات تعريف المجدول ، راجع KEP المناسب .

ابتكار آخر ظهر في حالة إصدار ألفا هو القاعدة الافتراضية للتوزيع المتساوي للقرون ( حتى توزيع Pod) . يتم حاليًا تحديد القواعد PodSpecوإرفاقها بالقرصنة ، وأصبح من الممكن الآن ضبط التكوين العام على مستوى العنقود. التفاصيل في KEP .

في الوقت نفسه ، تمت ترجمة ميزة Pod Topology Spread نفسها (بوابة السمات الخاصة بها EvenPodsSpread) ، والتي تسمح بتوزيع القرون بالتساوي عبر مجموعة متعددة المناطق ، إلى حالة بيتا.

بالإضافة إلى ذلك ، تم الإعلان عن تثبيت الإخلاء القائم على Taint ، المصمم لإضافة الصبغات إلى العقد عند حدوث ظروف معينة. لأول مرة ، ظهرت الميزة في الإصدار البعيد بالفعل من K8s 1.8 ، وحصلت على حالة بيتا في 1.13 .

سرعة التحجيم المخصصة HPA


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

كما تعلم ، يقوم جهاز أفقي Pod Pods Autoscaler (HPA) في Kubernetes بقياس عدد القرون لأي مورد يدعم مصدرًا فرعيًاscaleبناءً على استهلاك وحدة المعالجة المركزية أو مقاييس أخرى. تسمح لك ميزة جديدة بالتحكم في السرعة التي يحدث بها هذا التحجيم ، وفي كلا الاتجاهين. حتى الآن ، كان من الممكن تنظيمه إلى حد محدود جدًا (انظر ، على سبيل المثال ، المعلمة العالمية للمجموعة --horizontal-pod-autoscaler-downscale-stabilization-window).

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

الحل المقترح - كائن مضاف لتكوينات HPAbehavior، مما يسمح لك بتحديد قواعد التحكم في القياس في كلا الاتجاهين ( scaleUpو scaleDown). على سبيل المثال ، التكوين:

behavior:
  scaleUp:
    policies:
    - type: percent
      value: 900%

... سيؤدي إلى حقيقة أن عدد القرون العاملة حاليًا سيرتفع بنسبة 900٪. أي ، إذا بدأ التطبيق كجراب واحد ، إذا كان من الضروري قياسه ، فسوف يبدأ في النمو كـ 1 → 10 → 100 → 1000. للحصول على

أمثلة أخرى وتفاصيل التنفيذ ، انظر KEP .

عقده


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

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

حالة الإصدار التجريبي للحصول على فكرة في ميزة K8s 1.16 PodOverhead ، الآلية المقترحة لحساب النفقات العامة pod'y.

kubectl


تمت إضافة نسخة ألفا من أمر تصحيح kubectl ( KEP الخاص به ) ، والتي طورت مفهوم " الحاويات المؤقتة ". تم تقديمها لأول مرة في K8s 1.16 بهدف تبسيط التصحيح في القرون. للقيام بذلك ، في الحاوية اليمنى ، يتم إطلاق حاوية مؤقتة (أي العيش لفترة قصيرة) تحتوي على الأدوات اللازمة لتصحيح الأخطاء. كما كتبنا بالفعل ، فإن هذا الأمر مطابق بشكل أساسي للمكون الإضافي kubectl-debug الموجود حتى الآن ( مراجعته ).

التوضيح الوظيفي kubectl debug:

% kubectl help debug
Execute a container in a pod.

Examples:
  # Start an interactive debugging session with a debian image
  kubectl debug mypod --image=debian

  # Run a debugging session in the same namespace as target container 'myapp'
  # (Useful for debugging other containers when shareProcessNamespace is false)
  kubectl debug mypod --target=myapp

Options:
  -a, --attach=true: Automatically attach to container once created
  -c, --container='': Container name.
  -i, --stdin=true: Pass stdin to the container
  --image='': Required. Container image to use for debug container.
  --target='': Target processes in this container name.
  -t, --tty=true: Stdin is a TTY

Usage:
  kubectl debug (POD | TYPE/NAME) [-c CONTAINER] [flags] -- COMMAND [args...] [options]

Use "kubectl options" for a list of global command-line options (applies to all commands).

فريق آخر ، kubectl diff ، الذي ظهر لأول مرة في K8s 1.9 وحصل على حالة بيتا في 1.13 ، أعلن أخيرًا عن الاستقرار. كما يوحي الاسم ، فإنه يسمح لك بمقارنة تكوينات الكتلة. بمناسبة ميزات التثبيت ظهرت KEP ، وتم تحديثها مع جميع مواقع Kubernetes التوثيق ذات الصلة.

وبالإضافة إلى ذلك، علم kubectl --dry-تشغيل اضاف الدعم لقيم مختلفة من ( client، server، none)، والتي تمكنك من محاولة لتنفيذ الأمر فقط على جانب العميل أو الخادم. لتنفيذها على جانب الخادم نفذت الدعم للفرق الرئيسية بما في ذلك create،apply، patchوغيرها.

الشبكات


بدأ مورد Ingress في الانتقال من مجموعة API ( extensions.v1beta1) الحالية networking.v1beta1إلى ، متبوعًا بالاستقرار في العرض v1. تم التخطيط لسلسلة من التغييرات ( KEP ) لهذا الغرض . في الوقت الحالي - كجزء من الإصدار التجريبي في K8s 1.18 - تلقى Ingress ابتكارين مهمين :

  • حقل جديد pathTypeالذي يسمح لك لتحديد ما ما المبدأ سيتم مقارنة المسار ( Exact، Prefixأو ImplementationSpecific، يتم تحديد سلوك الماضي في IngressClass
  • مورد IngressClassجديد وحقل جديد (غير قابل للتغيير) Classفي التعريف IngressSpecالذي يشير إلى وحدة التحكم التي تنفذ مورد Ingress. تحل هذه التغييرات محل التعليق التوضيحي kubernetes.io/ingress.class، والذي سيتم إيقاف استخدامه.

بالنسبة للعديد من ميزات الشبكة ، تم زيادة حالة التوفر:

  • أصبح البرنامج المساعد NodeLocal DNS Cache مستقرًا ، مما يحسن أداء DNS عن طريق استخدام وكيل لذاكرة التخزين المؤقت لـ DNS على عقد الكتلة ؛
  • مستقر وأعلن عن حقل AppProtocolيحدد بروتوكول التطبيق لكل منفذ خدمة (الموارد ServicePortو EndpointPort) ؛
  • يعتبر دعم IPv6 مستقرًا بما يكفي لترجمته إلى إصدار تجريبي ؛
  • بشكل افتراضي ، يتم تنشيط واجهة برمجة تطبيقات EndpointSlices الآن (كجزء من الإصدار التجريبي) ، وتعمل كبديل أكثر قابلية للتوسيع والتوسيع لنقاط النهاية المعتادة.

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


يوفر إصدار ألفا الأساس لإنشاء وحدات تخزين مع تحميل البيانات عليها مسبقًا - بيانات البيانات العامة ( KEP ). كتطبيق ، يُقترح إضعاف التحقق من صحة الحقل DataSourceبحيث يمكن أن تكون الكائنات ذات الأنواع التعسفية مصادر بيانات.

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

بالنسبة للكائنات Secrets، تمت ConfigMaps إضافة حقل جديدimmutable ، مما يجعلها غير قابلة للتغيير. كقاعدة ، يتم استخدام هذه الكائنات في القرون كملفات. تنطبق أي تغييرات في هذه الملفات بسرعة (بعد حوالي دقيقة) على جميع الأقراص التي قامت بتحميل الملفات. وبالتالي ، يمكن أن يؤدي التحديث غير الناجح للسر أو ConfigMap إلى فشل التطبيق بأكمله.

يقول مؤلفو الميزة أنه حتى في حالة تحديث التطبيقات بالطريقة الموصى بها - من خلال الترقيات المتدحرجة - قد يكون هناك إخفاقات ناتجة عن تحديثات غير ناجحة للأسرار / ConfigMaps الموجودة. علاوة على ذلك ، فإن عملية تحديث هذه الكائنات في تشغيل القرون معقدة من حيث الأداء وقابلية التوسع (كل kubelet مجبر على مراقبة كل سر / CM فريد بشكل مستمر).

في التنفيذ الحالي ، يتم إجراء ذلك بحيث لا يمكن التراجع عن هذا التغيير بعد وضع علامة على المورد على أنه غير قابل للتغيير. لن تحتاج فقط إلى حذف الكائن وإنشائه مرة أخرى ، ولكن أيضًا إعادة إنشاء القرون التي تستخدم السر البعيد. الإصدار - ألفا ، التفاصيل - KEP .

أعلن مستقر:

  • استنساخ PVC
  • القدرة على استخدام الأجهزة الأولية المحظورة (وليس الشبكة) مثل وحدات التخزين المستمرة ؛
  • دعم الأجهزة الخام الخام في CSI ؛
  • نقل معلومات حول جراب تطلب وحدة التخزين.

تغييرات أخرى


من بين الابتكارات الأخرى في Kubernetes 1.18 (للحصول على قائمة أكثر اكتمالاً ، انظر التغيير ) :

  • JWT- Kubernetes service accounts (KSA) Kubernetes API. - . API- discovery-, OIDC (OpenID Connect) . OIDC (.. K8s-) KCA-, API-. — KEP.
  • - Priority and Fairness API (KEP) — API- ( max-in-flight). . ( FlowSchema) ( RequestPriority). kubectl:

    kind: RequestPriority
    meta:
      name: workload-high
    spec:
      assuredConcurrencyShares: 30
      queues: 128
      handSize: 6
      queueLengthLimit: 100
    
    kind: FlowSchema
    meta:
      name: workload-high
    spec:
      requestPriority:
        name: workload-high
      flowDistinguisher:
        source: namespace
        # no transformation in this case
      match:
      - and: # users using kubectl
        - notPatternMatch:
          field: user
          pattern: system:serviceaccount:.*
  • CertificateSigningRequest API, x509- Certificate Authority. K8s 1.4 - 1.6.
  • عدد من التحسينات المهمة في العمل مع Windows: دعم CRI-ContainerD (إصدار ألفا) ، تنفيذ RuntimeClass (إصدار ألفا) ، دعم برنامج تشغيل CSI عبر وكيل CSI (إصدار ألفا) ، إصدارات مستقرة من دعم GMSA (حساب الخدمة المدارة للمجموعة) و RunAsUserName .

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

  • إصدار CoreDNS في kubeadm - 1.6.7 ؛
  • أدوات cri 1.17.0 ؛
  • CNI (واجهة شبكة الحاويات) 0.8.5 ، كاليكو 3.8.4 ؛
  • إصدار Go المستخدم هو 1.13.8.

ما هو عفا عليه الزمن؟


  • API خادم ليست خدمة API التي عفا عليها الزمن: جميع الموارد apps/v1beta1و extensions/v1beta1الحاجة للمضي قدما apps/v1، والالتفات إلى مورد معين daemonsets، deployments، replicasets، networkpolicies، podsecuritypolicies،
  • /metrics/resource/v1alpha1 لا تتم خدمة نقطة النهاية للمقاييس - الآن بدلاً من ذلك /metrics/resource؛
  • kubectl run تمت إزالة جميع مولدات الفريق باستثناء المسؤول عن توليد الكبسولات.

ملاحظة


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


All Articles