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

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







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



لنبدأ ببعض الابتكارات الرئيسية ذات الطبيعة العامة إلى حد ما ...



مع إصدار Kubernetes 1.19 ، تمت زيادة "نافذة الدعم" لإصدارات Kubernetes من 9 أشهر (أي آخر 3 إصدارات) إلى عام واحد (أي 4 إصدارات). لماذا ا؟



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





(في وقت المسح ، كان إصدار Kubernetes الحالي 1.13 ، أي جميع مستخدمي K8s 1.9 و 1.10 يعملان مع الإصدارات التي لم تعد مدعومة في ذلك الوقت.)



وبالتالي ، من المفترض أن التمديد لمدة 3 أشهر لفترة الدعم لإصدارات Kubernetes - إصدار التصحيحات التي تعمل على إصلاح المشكلات الموجودة في الكود - سيضمن أن أكثر من 80٪ من المستخدمين سيعملون على الإصدارات المدعومة من K8s (بدلاً من 50-60٪ المفترض في الوقت الحالي ).



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



بالتزامن مع الترحيل إلى klog v2 ، يتم الانتقال إلى تنسيق جديد لإخراج السجلات في JSON ، مما يسهل تنفيذ الطلبات إلى السجلات ومعالجتها. لهذا ، تظهر علامة --logging-format، والتي تستخدم تنسيق النص القديم افتراضيًا.



نظرًا لأن مستودع Kubernetes ضخم والمؤلفونيُعد KEPs للتسجيل المنظم واقعيًا وسيركز جهودهم لإحياء أفكار جديدة على الرسائل الأكثر شيوعًا.



توضيح للتسجيل باستخدام الطرق الجديدة في klog:

klog.InfoS("Pod status updated", "pod", "kubedns", "status", "ready")

I1025 00:15:15.525108       1 controller_utils.go:116] "Pod status updated" pod="kubedns"

klog.InfoS("Pod status updated", "pod", klog.KRef("kube-system", "kubedns"), "status", "ready")

I1025 00:15:15.525108       1 controller_utils.go:116] "Pod status updated" pod="kube-system/kubedns" status="ready"

klog.ErrorS(err, "Failed to update pod status")

E1025 00:15:15.525108       1 controller_utils.go:114] "Failed to update pod status" err="timeout"

باستخدام تنسيق JSON:

pod := corev1.Pod{Name: "kubedns", Namespace: "kube-system", ...}
klog.InfoS("Pod status updated", "pod", klog.KObj(pod), "status", "ready")

{
   "ts": 1580306777.04728,
   "v": 4,
   "msg": "Pod status updated",
   "pod":{
      "name": "nginx-1",
      "namespace": "default"
   },
   "status": "ready"
}

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



لحل هذه المشكلة ، الآن عند استخدام واجهة برمجة التطبيقات (API) التي تم إهمالها ، تتم إضافة رأس إلى ردودها Warning، والتي يتم التعرف عليها من جانب العميل (client-go) مع القدرة على الاستجابة بطرق مختلفة: تجاهل ، إلغاء تكرار ، تسجيل. في الأداة المساعدة kubectl ، قاموا بتدريس كيفية إخراج هذه الرسائل إلى stderr ، وتمييز الرسالة في وحدة التحكم بالألوان ، وإضافة أيضًا علامة --warnings-as-errorsباسم واضح .



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



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



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

1. تلبية معايير GA ويتم ترقيتها إلى حالة مستقرة ؛
2. لديك إصدار تجريبي جديد يلغي الإصدار التجريبي السابق.

الآن بالنسبة للتغييرات الأخرى في Kubernetes 1.19 ، مصنفة حسب SIGs الخاصة بها.

الخزائن

تهدف كائنات CSIStorageCapacity الجديدة إلى تحسين عملية الجدولة للبودات التي تستخدم وحدات تخزين CSI: لن يتم وضعها على العقد التي نفدت مساحة التخزين فيها. لهذا ، سيتم تخزين المعلومات حول مساحة القرص المتوفرة في خادم API وستتوفر لسائقي CSI وجدولة. حالة التنفيذ الحالية هي إصدار ألفا ؛ انظر KEP للحصول على التفاصيل .



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



تقدم الآلية الجديدة واجهة برمجة تطبيقات بسيطة لتحديد وحدات التخزين المؤقتة لأي محرك مزود بتزويد ديناميكي (في السابق ، كان هذا يتطلب تعديل برنامج التشغيل). يتيح لك العمل مع أي وحدات تخزين سريعة الزوال (كل من CSI و in-tree ، مثل EmptyDir) ، كما يوفر دعمًا لميزة جديدة أخرى (موصوفة أعلاه) - تتبع مساحة التخزين المتاحة.



مثال على كائن Kubernetes عالي المستوى باستخدام وحدة تخزين مؤقتة جديدة (مضمنة عامة):

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: fluentd-elasticsearch
  namespace: kube-system
spec:
  selector:
    matchLabels:
      name: fluentd-elasticsearch
  template:
    metadata:
      labels:
        name: fluentd-elasticsearch
    spec:
      containers:
      - name: fluentd-elasticsearch
        image: quay.io/fluentd_elasticsearch/fluentd:v2.5.2
        volumeMounts:
        - name: varlog
          mountPath: /var/log
        - name: scratch
          mountPath: /scratch
      volumes:
      - name: varlog
        hostPath:
          path: /var/log
      - name: scratch
        ephemeral:
          metadata:
            labels:
              type: fluentd-elasticsearch-volume
          spec:
            accessModes: [ "ReadWriteOnce" ]
            storageClassName: "scratch-storage-class"
            resources:
              requests:
                storage: 1Gi

هنا ، تُنشئ وحدة التحكم DaemonSet قرونًا بأسماء العرض fluentd-elasticsearch-b96sd، وبعد ذلك ستتم إضافة PersistentVolumeClaim لمثل هذه البودات fluentd-elasticsearch-b96sd-scratch.



وأخيرًا ميزة تخزين جديدة تمامًا ، تم تقديمها كإصدار ألفا ، هي حقل جديد لمحركاتcsidriver.spec.SupportsFSGroup CSI يشير إلى دعم الأذونات المستندة إلى FSGroup ( KEP ). الدافع: يتم إجراء تغيير الملكية لوحدة تخزين CSI قبل تثبيتها في حاوية ، ولكن لا تدعم جميع أنواع التخزين مثل هذه العملية (على سبيل المثال ، NFS) ، وهذا هو السبب في أنها قد تؤدي الآن إلى حدوث أخطاء.



حتى الإصدار التجريبي (أي التضمينات الافتراضية):

• CSI- Azure vSphere ( , Kubernetes);
• Secrets ConfigMaps.

/ Kubelet

تم إعلان Seccomp مستقرًا (GA) . على وجه الخصوص ، أدت هذه الأعمال إلى الانتقال إلى الحقول الخاصة بـ seccomp في واجهة برمجة التطبيقات بدلاً من التعليقات التوضيحية التي تم الإعلان عنها بأنها قديمة (تجاهل Kubelets الجديد للتعليقات التوضيحية) ، وتأثر PodSecurityPolicy . تمت إضافة حقل جديد إلى



PodSpec للسماح لك بتعيين FQDN (اسم المجال المؤهل بالكامل) لمضيف pod . الهدف هو تحسين دعم التطبيقات القديمة في Kubernetes. إليك كيف يشرح المؤلفون نواياهم:fqdnInHostname

« Unix Linux-, Red Hat CentOS, FQDN- hostname. , , Kubernetes, . ».

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



تقرر التخلي عن مقاييس المسرع التي جمعتها Kubelet . يُقترح جمع هذه المقاييس بواسطة وكلاء المراقبة الخارجيين من خلال PodResources API. تم إنشاء واجهة برمجة التطبيقات هذه على وجه التحديد بهدف إزالة جميع المقاييس الخاصة بالجهاز من مستودع Kubernetes الرئيسي ، مما يسمح للموردين بتنفيذها دون إجراء تغييرات على جوهر Kubernetes. PodResources API في مرحلة تجريبية (بوابة الميزات مسؤولة عنها KubeletPodResources) وستكون مستقرة قريبًا. بالنسبة للإصدار الحالي ، تكون عملية التخلي في حالة ألفا ، والتفاصيل موجودة في KEP .



من الآن فصاعدًا ، يمكن بناء Kubelet بدون Docker : بهذا "بدون" يعني المؤلفون عدم وجود أي كود خاص بـ Docker والاعتماد على حزمة Golang docker/docker. الهدف النهائي من هذه المبادرة هو الوصول إلى Kubelet "بلا رصيف" تمامًا (أي لا تبعية Docker). يمكنك قراءة المزيد عن التحفيز ، كما هو الحال دائمًا ، في KEP . تلقت هذه الفرصة على الفور حالة GA.



أصبح Node Topology Manager ، الذي وصل إلى نسخته التجريبية في إصدار K8s الأخير ، لديه الآن القدرة على مستوى الموارد على مستوى pod.

المجدول

بالعودة إلى Kubernetes 1.18 ، كتبنا عن التكوين العام لتوزيع البودات حتى (حتى نشر بود) ، ولكن بعد ذلك تقرر تأجيل هذه الميزة بناءً على نتائج اختبار الأداء. هي الآن في Kubernetes (في حالة ألفا).



جوهر الابتكار هو إضافة القيود العالمية ( DefaultConstraints) ، والتي تسمح بتنظيم قواعد توزيع القرون على مستوى أعلى - على مستوى الكتلة ، وليس فقط في PodSpec(من خلال topologySpreadConstraints) ، كما كان حتى الآن. سيكون التكوين الافتراضي مشابهًا للمكوِّن الإضافي الحالي DefaultPodTopologySpread:

defaultConstraints:
  - maxSkew: 3
    topologyKey: "kubernetes.io/hostname"
    whenUnsatisfiable: ScheduleAnyway
  - maxSkew: 5
    topologyKey: "topology.kubernetes.io/zone"
    whenUnsatisfiable: ScheduleAnyway

التفاصيل موجودة في KEP .



ميزة أخرى متعلقة بـ Even Pod Spreading: توزيع مجموعة من البودات حسب مجالات الفشل (مناطق ، مناطق ، عقد ، إلخ) ، - تم نقلها من ألفا إلى بيتا (ممكّن افتراضيًا).



حققت ثلاث ميزات أخرى في المجدول "زيادة" مماثلة:

• ملامح التخطيط (جدولة الملفات الشخصية) ، المقدمة في 1.18 ؛
• خيار لتمكين / تعطيل استباق البود في PriorityClasses ؛
• ملف التكوين kube-Scheduler ComponentConfig .

الشبكات

تم الإعلان أخيرًا عن استقرار مورد Ingress وله إصدار v1في API. في هذا الصدد ، تم تقديم عدد غير قليل من التحديثات في الوثائق ذات الصلة. وينبغي إيلاء اهتمام خاص لتغيير ملحوظ على المستخدم من هذا PR : على سبيل المثال، هناك مثل هذه إعادة تسمية كما spec.backend→ spec.defaultBackend، serviceName→ service.name، servicePort→ service.port.number...



و الحقل AppProtocol للخدمات ونهايات، فضلا عن EndpointSlice API (كوبي-الوكيل على بدء لينكس EndpointSlices استخدام افتراضيا، لكنه بقي في ألفا ويندوز) و دعم SCTP .

kubeadm

تم تقديم ميزتين جديدتين (في إصدار ألفا) لأداة kubeadm.



الأول هو استخدام التصحيحات لتعديل البيانات الناتجة عن kubeadm. كان من الممكن بالفعل تعديلها باستخدام Kustomize (في alpha) ، لكن مطوري kubeadm قرروا أن استخدام التصحيحات العادية هو الطريقة المفضلة (نظرًا لأن Kustomize يصبح تبعية غير ضرورية ، وهو أمر غير مرحب به).



الآن فمن الممكن أن تنطبق بقع الخام (عن طريق العلم --experimental-patches) لأوامر kubeadm init، joinو upgrade، وكذلك مراحلها. سيتم إهمال التنفيذ (العلم --experimental-kustomize) المستند إلى Kustomize وإزالته.



الميزة الثانية هي طريقة جديدة للعمل مع تكوينات المكوناتالتي يعمل معها kubeadm. تقوم الأداة المساعدة بإنشاء القيم الافتراضية والتحقق منها وتعيينها وتخزين التكوينات (في شكل ConfigMaps) لمكونات مجموعة Kubernetes مثل Kubelet و kube-proxy. بمرور الوقت ، أصبح من الواضح أن هذا يجلب عددًا من الصعوبات: كيفية التمييز بين التكوينات التي تم إنشاؤها بواسطة kubeadm أو التي أرسلها المستخدم (وإذا لم يكن الأمر كذلك ، فماذا تفعل بترحيل التكوين)؟ ما هي الحقول ذات القيم الافتراضية التي تم إنشاؤها تلقائيًا ، وأي منها تم تعيينه عن قصد؟ ..



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



وهناك ميزة أخرى أقل أهمية لـ kubeadm وهي بوابة ميزة تسمى PublicKeysECDSA، والتي تتضمن القدرة على إنشاء مجموعة [عبر kubeadm init] بشهادات ECDSA. kubeadm alpha certs renewيتم أيضًا توفير تحديث الشهادات الحالية (عبر ) ، ولكن لا توجد آليات للتبديل بسهولة بين RSA و ECDSA.

تغييرات أخرى

• تلقت حالة GA ثلاث ميزات في مجال المصادقة: CertificateSigningRequest API ، وتقييد وصول العقدة إلى واجهات برمجة تطبيقات معينة (عبر مكون إضافي للقبول NodeRestriction) ، وتمهيد التشغيل والتجديد التلقائي لشهادة عميل Kubelet.
• تم الإعلان أيضًا عن استقرار واجهة برمجة تطبيقات الأحداث الجديدة من خلال نهج متغير لإلغاء البيانات المكررة (لتجنب التحميل الزائد على الكتلة بالأحداث).
• (kube-apiserver, kube-scheduler, etcd ) debian distroless. : , ( — KEP).
• Kubelet Docker runtime target-, TargetContainerName EphemeralContainer ( ).
• « » .status.conditions, API .
• kube-proxy IPv6DualStack Windows ( feature gate).
• بوابة الميزات ذات الاسم الواضح CSIMigrationvSphere(الترحيل من المكون الإضافي المدمج - داخل الشجرة - لبرنامج vSphere إلى برنامج تشغيل CSI) انتقل إلى الإصدار التجريبي.
• ل kubectl run وأضاف العلم --privileged.
• تمت إضافة نقطة تمديد جديدة إلى المجدول - PostFilter، - التي تبدأ بعد المرحلة Filter.
• وصل دعم Cri-containerd على Windows إلى الإصدار التجريبي.

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

• إصدار CoreDNS مضمن في kubeadm - 1.7.0 ؛
• أدوات cri 1.18.0 ؛
• CNI (واجهة شبكة الحاويات) 0.8.6 ؛
• إلخ 3.4.9 ؛
• إصدار Go المستخدم هو 1.15.0-rc.1.

ملاحظة

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

• « Kubernetes 1.18: مراجعة أهم الابتكارات » ؛
• «Kubernetes 1.17: »;
• «Kubernetes 1.16: »;
• «Kubernetes 1.15: ».