Trident: المكون الإضافي Trident CSI Node غير مسجل بعد تحديث إصدار Kubernetes

تم إنشاؤها على ٢٥ نوفمبر ٢٠٢٠  ·  4تعليقات  ·  مصدر: NetApp/trident

صف الخلل

المكون الإضافي Trident CSI Node ( csi.trident.netapp.io ) على عقدة واحدة غير مسجل الآن بعد تحديث إصدار Kubernetes من v1.18.9 إلى v1.19.4. لم يعد بإمكان الكبسولات الموجودة على هذه العقدة تحميل وحدات تخزين Trident وإلغاء تحميلها.

رسائل خاطئة

نرى الرسائل التالية في سجل kubelet.

كان csi.trident.netapp.io غير مسجل منذ إزالة مقبس التسجيل ( /var/lib/kubelet/plugins_registry/csi.trident.netapp.io-reg.sock ).

I1119 05: 47: 54.246972 6550 plugin_watcher.go: 212] إزالة مسار المقبس /var/lib/kubelet/plugins_registry/csi.trident.netapp.io-reg.sock من ذاكرة التخزين المؤقت للحالة المطلوبة
I1119 05: 47: 53.162305 6550 ... /lib/kubelet/plugins_registry/csi.trident.netapp.io-reg.sock 2020-11-04 05:08: 19.553684094 +0000 التوقيت العالمي المنسق m = + 38.893901704 0x704c200 csi.trident.netapp.io})
I1119 05: 47: 53.163390 6550 csi_plugin.go: 177] kubernetes.io/csi: registrationHandler.DeRegisterPlugin request for plugin csi.trident.netapp.io

تعذر على الكبسولة إلغاء تحميل وحدة التخزين لأنه لم يتم العثور على csi.trident.netapp.io .

E1119 09: 02: 52.819122 6550 nestedpendingoperations.go: 301] عملية لـ "{v olumeName: kubernetes.io/csi/csi.trident.netapp.io ^ pvc-75a6fd7f-7aee-45e8-a5fa-d4500272528e podName: ad18a7d1-4090 -4e0c-9e71-cba46dfc3657 nodeName:} "فشل. لا يُسمح بإعادة المحاولة حتى 2020-11-19 09: 04: 54.819071328 +0000 UTC م = + 1310234.159288938 (المدة قبل إعادة المحاولة 2 م 2). خطأ: "UnmountVolume.TearDown فشل لبيانات وحدة التخزين" (UniqueName: "kubernetes.io/csi/csi.trident.netapp.iouablepvc-75a6fd7f-7aee-45e8-a5fa-d4500272528e") pod "ad18a7d1-4090-4e0c -9e71-cba46dfc3657 "(UID:" ad18a7d1-4090-4e0c-9e71-cba46dfc3657 "): kubernetes.io/csi: mounter.SetUpAt فشل في الحصول على عميل CSI: اسم برنامج التشغيل csi.trident.netapp.io غير موجود في القائمة من برامج تشغيل CSI المسجلين "

تم تشغيل اثنين من ترايدنت-سي إس آي في نفس الوقت

وجدنا أن اثنين من trident-csi (Node Plugin) على هذه العقدة كانت تعمل في نفس الوقت لفترة قصيرة جدًا ، وأن driver-registrar القديم قد توقف بعد أن بدأ واحد جديد.

يزيل driver-registrar مأخذ التوصيل ( /var/lib/kubelet/plugins_registry/csi.trident.netapp.io-reg.sock ) عندما يتلقى SIGTERM ( node_register.go # L113-L116 ). تؤدي إزالة المقبس إلى قيام kubelet بإلغاء تسجيل المكون الإضافي Trident. أعتقد أن هذا هو سبب المشكلة.

image

تم إعادة إنشاء DaemonSet بعد التحديث

تتم إدارة أقراص Trident-csi (Node Plugin) بواسطة DaemonSet. عادة ، يتم تشغيل جراب واحد فقط على كل عقدة. ولكن بعد تحديث Kubernetes ، تم إعادة إنشاء trident-csi Daemonset بواسطة trident-operator . يتيح حذف DaemonSet تشغيل جرابين (قديم وجديد) في وقت واحد.

أكدنا ذلك في السجل trident-operator .

هنا ، تم حذف Daemonset trident-csi .

الوقت = "2020-11-19T05: 47: 45Z" المستوى = تصحيح الأخطاء msg = "تم حذف Kubernetes DaemonSet." DaemonSet = مساحة الاسم trident-csi = trident

تم إنشاء Daemonset trident-csi بعد ذلك بفترة وجيزة.

الوقت = "2020-11-19T05: 47: 45Z" المستوى = تصحيح الأخطاء msg = "إنشاء كائن." النوع = اسم DaemonSet = مساحة الاسم ترايدنت-csi = ترايدنت

بعد تحديث Kubernetes ، تم تعيين علامة shouldUpdate على true ( controller.go # L1110 ). يبدو أن العلامة shouldUpdate # $ 9 $ # $ تتسبب في حذف Daemonset trident-csi ( installer.go # L1489-L1494 ).

بيئة

  • إصدار ترايدنت: 20.10.0 مع مشغل ترايدنت
  • أعلام تثبيت Trident المستخدمة: silenceAutosupport: true (مشغل Trident)
  • وقت تشغيل الحاوية: Docker 19.03.13
  • إصدار Kubernetes: v1.19.4
  • منسق Kubernetes: Kubernetes
  • بوابات الميزات الممكّنة لـ Kubernetes:
  • نظام التشغيل: Ubuntu 18.04
  • أنواع الواجهة الخلفية لـ NetApp: ONTAP AFF 9.1P14
  • آخر:

لإعادة إنتاج

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

يتسبب اثنان من trident-csi في قيام kubelet بإلغاء تسجيل المكون الإضافي Trident

  1. تأكد من تسجيل برنامج تشغيل Trident CSI في العقدة.
$ kubectl describe csinodes.storage.k8s.io <NODE_NAME>
...
Spec:
  Drivers:
    csi.trident.netapp.io:
      Node ID:        <NODE_NAME>
      Topology Keys:  [topology.kubernetes.io/zone]
  1. انسخ trident-csi DaemonSet لتشغيل قرصين من نوع trident-csi على كل عقدة.
$ kubectl get ds -n trident trident-csi -o json | jq '.metadata.name|="trident-csi-2"' | kubectl apply -f -
  1. انتظر حتى يتم تشغيلها ، ثم احذف مجموعة DaemonSet المنسوخة trident-csi-2 .
$ kubectl delete ds -n trident trident-csi-2
  1. تأكد من اختفاء برنامج تشغيل Trident CSI في قسم Drivers في العقدة. (سيستغرق هذا بعض الوقت)
$ kubectl describe csinodes.storage.k8s.io <NODE_NAME>
Spec:

تتيح إعادة إنشاء DaemonSet تشغيل جرابين (قديم وجديد) في وقت واحد

  1. حذف DaemonSet trident-csi . سيتم إعادة إنشاء مجموعة DaemonSet بعد فترة وجيزة بواسطة مشغل ترايدنت.
$ kubectl delete ds -n trident trident-csi
  1. سترى قرصين trident-csi على كل عقدة.
$ kubectl get pods -n trident -o wide

سلوك متوقع
يمكن للوحدات تحميل وحدات تخزين Trident وإلغاء تحميلها بعد تحديث إصدار Kubernetes.

سياق إضافي
لا أحد

bug tracked

التعليق الأكثر فائدة

سنقوم بتضمين هذا الإصلاح في إصدار Trident v21.01.

ال 4 كومينتر

مرحبا tksm

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

بدافع الفضول ، هل تمانع في أن أسأل عن عدد المجموعات التي واجهت هذه المشكلة أثناء الترقية؟

شكرا لك!

مرحبًا @ ntap-arorar

شكرا لك على التأكيد. أعتقد أن فكرتك ستصلح هذه المشكلة.

لقد واجهنا هذه المشكلة في مجموعة واحدة فقط حتى الآن ، نظرًا لأننا قمنا بترقية عدد قليل من المجموعات كاختبار.

سنقوم بتضمين هذا الإصلاح في إصدار Trident v21.01.

تم إصلاح هذه المشكلة من خلال الالتزام 820579d .

هل كانت هذه الصفحة مفيدة؟
0 / 5 - 0 التقييمات