صف الخلل
المكون الإضافي 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. أعتقد أن هذا هو سبب المشكلة.
تتم إدارة أقراص 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 ).
بيئة
silenceAutosupport: true
(مشغل Trident)لإعادة إنتاج
قد يؤدي تحديث إصدار Kubernetes إلى ظهور هذه المشكلة. نظرًا لأن تحديث Kubernetes يستغرق وقتًا طويلاً ولا يحدث دائمًا ، فقد أكدنا السلوكيات التالية التي تسبب هذه المشكلة من خلال عروض توضيحية مختلفة.
$ kubectl describe csinodes.storage.k8s.io <NODE_NAME>
...
Spec:
Drivers:
csi.trident.netapp.io:
Node ID: <NODE_NAME>
Topology Keys: [topology.kubernetes.io/zone]
trident-csi
DaemonSet لتشغيل قرصين من نوع trident-csi على كل عقدة.$ kubectl get ds -n trident trident-csi -o json | jq '.metadata.name|="trident-csi-2"' | kubectl apply -f -
trident-csi-2
.$ kubectl delete ds -n trident trident-csi-2
$ kubectl describe csinodes.storage.k8s.io <NODE_NAME>
Spec:
trident-csi
. سيتم إعادة إنشاء مجموعة DaemonSet بعد فترة وجيزة بواسطة مشغل ترايدنت.$ kubectl delete ds -n trident trident-csi
trident-csi
على كل عقدة.$ kubectl get pods -n trident -o wide
سلوك متوقع
يمكن للوحدات تحميل وحدات تخزين Trident وإلغاء تحميلها بعد تحديث إصدار Kubernetes.
سياق إضافي
لا أحد
مرحبا tksm
شكرًا لك على تقديم تفاصيل هذه المشكلة والنظر عن كثب في السبب الأساسي ، فإن تحليلك مفيد للغاية. تعد النافذة بين إنهاء جراب daemonset والحصول على الاستجمام أمرًا بالغ الأهمية ، ويجب أن يحدث الأخير فقط عند اكتمال الأول. لذلك ، يجب على المشغل التأكد من أنه قبل إنشاء المجموعة الشيطانية ، يتم حذف جميع البودات التي تنتمي إلى مجموعة الشيطان السابقة ثم إنشاء مجموعة شيطان جديدة فقط.
بدافع الفضول ، هل تمانع في أن أسأل عن عدد المجموعات التي واجهت هذه المشكلة أثناء الترقية؟
شكرا لك!
مرحبًا @ ntap-arorar
شكرا لك على التأكيد. أعتقد أن فكرتك ستصلح هذه المشكلة.
لقد واجهنا هذه المشكلة في مجموعة واحدة فقط حتى الآن ، نظرًا لأننا قمنا بترقية عدد قليل من المجموعات كاختبار.
سنقوم بتضمين هذا الإصلاح في إصدار Trident v21.01.
تم إصلاح هذه المشكلة من خلال الالتزام 820579d .
التعليق الأكثر فائدة
سنقوم بتضمين هذا الإصلاح في إصدار Trident v21.01.