Trident: حالات فشل تركيب PVC العشوائية بسبب مهلات blkid

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

صف الخلل
نلاحظ الكثير من البودات عالقة بشكل عشوائي عند ContainerCreating state لأنها لا تستطيع تحميل netapp pvcs. يشير وصف نقاط pods إلى المهلات أثناء الحصول على معلومات جهاز iSCSI وسجلات ترايدنت daemonset إلى أن هذا يرجع إلى انقضاء المهلات أثناء تنفيذ الأمر blkid على المضيف.
هذا حدث عشوائي ولا يمكن ربطه مع مضيفين و pvcs معينين.

بيئة

  • إصدار ترايدنت: 20.07.1
  • أعلام تثبيت Trident المستخدمة: tridentctl install -n sys-trident --generate-custom-yaml (ثم kubectl application -f - للبيان الذي تم إنشاؤه)
  • وقت تشغيل الحاوية : docker: //19.3.12
  • إصدار Kubernetes: v1.19.2
  • منسق Kubernetes: لا شيء
  • بوابات الميزات التي تم تمكينها بواسطة Kubernetes: إعدادات kubernetes الافتراضية فقط
  • نظام التشغيل: Flatcar Container Linux من Kinvolk 2605.6.0 (Oklo) 5.4.67-flatcar
  • أنواع الواجهة الخلفية لـ NetApp: ontap-san ، ONTAP 9.7.0

لإعادة إنتاج
يمكننا ملاحظته بشكل عشوائي على العقد العنقودية (لا يبدو أنه مرتبط بمجموعة معينة من المضيفين)

سلوك متوقع
سلوك تثبيت ثابت خلال فترة زمنية معقولة.

سياق إضافي
من خلال وصف حجرة "عالقة" يمكننا رؤية:

Events:
  Type     Reason       Age                  From     Message
  ----     ------       ----                 ----     -------
  Warning  FailedMount  51m (x5 over 72m)    kubelet  Unable to attach or mount volumes: unmounted volumes=[data], unattached volumes=[data thanos-storage vault-tls thanos-store-token-lj9j5]: timed out waiting for the condition
  Warning  FailedMount  42m (x3 over 56m)    kubelet  Unable to attach or mount volumes: unmounted volumes=[data], unattached volumes=[thanos-storage vault-tls thanos-store-token-lj9j5 data]: timed out waiting for the condition
  Warning  FailedMount  17m (x15 over 74m)   kubelet  Unable to attach or mount volumes: unmounted volumes=[data], unattached volumes=[vault-tls thanos-store-token-lj9j5 data thanos-storage]: timed out waiting for the condition
  Warning  FailedMount  14m (x22 over 74m)   kubelet  MountVolume.MountDevice failed for volume "pvc-e22cdf07-acfc-42af-a46a-bffd5ac32514" : rpc error: code = Internal desc = error getting iSCSI device information: process killed after timeout
  Warning  FailedMount  4m11s (x4 over 69m)  kubelet  Unable to attach or mount volumes: unmounted volumes=[data], unattached volumes=[thanos-store-token-lj9j5 data thanos-storage vault-tls]: timed out waiting for the condition

على نفس العقدة من سجلات جراب ترايدنت daemonset ذات الصلة:

time="2020-10-14T14:32:41Z" level=debug msg=">>>> osutils.execCommandWithTimeout." args="[if=/dev/sdc bs=4096 count=1 status=none]" command=dd timeoutSeconds=5s
time="2020-10-14T14:32:41Z" level=debug msg="<<<< osutils.execCommandWithTimeout." command=dd error="<nil>"
time="2020-10-14T14:32:41Z" level=debug msg="<<<< osutils.ensureDeviceReadable"
time="2020-10-14T14:32:41Z" level=debug msg=">>>> osutils.getFSType" device=/dev/sdc
time="2020-10-14T14:32:41Z" level=debug msg=">>>> osutils.waitForDevice" device=/dev/sdc
time="2020-10-14T14:32:41Z" level=debug msg="Device found." device=/dev/sdc
time="2020-10-14T14:32:41Z" level=debug msg="<<<< osutils.waitForDevice" device=/dev/sdc
time="2020-10-14T14:32:41Z" level=debug msg=">>>> osutils.execCommandWithTimeout." args="[/dev/sdc]" command=blkid timeoutSeconds=5s
time="2020-10-14T14:32:46Z" level=error msg="process killed after timeout" process=blkid
time="2020-10-14T14:32:46Z" level=debug msg="<<<< osutils.execCommandWithTimeout." command=blkid error="process killed after timeout"
time="2020-10-14T14:32:46Z" level=debug msg="<<<< osutils.getFSType"
time="2020-10-14T14:32:46Z" level=debug msg="<<<< osutils.getDeviceInfoForLUN" iSCSINodeName="iqn.1992-08.com.netapp:sn.0205ffce026911ebb4d9d039ea1a7953:vs.9" lunID=1 needFSType=true
time="2020-10-14T14:32:46Z" level=debug msg="<<<< osutils.AttachISCSIVolume"
time="2020-10-14T14:32:46Z" level=debug msg="<<<< NodeStageVolume" Method=NodeStageVolume Type=CSI_Node
time="2020-10-14T14:32:46Z" level=debug msg="Released shared lock (NodeStageVolume-pvc-e22cdf07-acfc-42af-a46a-bffd5ac32514)." lock=csi_node_server
time="2020-10-14T14:32:46Z" level=error msg="GRPC error: rpc error: code = Internal desc = error getting iSCSI device information: process killed after timeout"

يبدو أن blkid لا يمكنه العودة في الإطار الزمني المسموح به (؟)
إذا أدخلنا إلى المضيف وجربنا الأمر نفسه:

$ time sudo blkid /dev/sdc
/dev/sdc: UUID="f593b708-ed88-47b7-88ce-f9b8c85ab96b" TYPE="ext4"

real    0m36.393s
user    0m0.016s
sys     0m0.021s

التكوين الخلفي json الخاص بنا:
""
{
"النسخة 1،
"storageDriverName": "ontap-san"،
"managementLIF": "10.20.50.6"،
"dataLIF": "10.20.50.4"،
"svm": "dev_kube"،
"igroupName": "dev_kube_trident"،
"اسم المستخدم": "xxxxxxxxx" ،
"كلمة المرور": "xxxxxxxxxxx" ،
"الافتراضيات": {
"التشفير": "صحيح"
}
}
""

نحن عالقون هنا حقًا ، لذا فإن أي مساعدة في هذا الأمر ستكون محل تقدير كبير!

bug

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

إغلاق هذا لأننا لم نره منذ أن قمنا بتصحيح سرعة روابط الشبكة. شكرا جزيلا لمساعدتك! :))

ال 4 كومينتر

مرحبا ffilippopoulos ،

كما أشرت إلى أن blkid هو أمر على مستوى المضيف. إن قدرة هذا الأمر على العودة قبل انقضاء مهلته ليست شيئًا يمكن لـ Trident التحكم فيه. تقوم Trident بنفس الشيء الذي تفعله عندما تدخل إلى المضيف وتقوم بتشغيل blkid من قذيفة. هل درست العبء على المضيف؟

أيضًا ، إذا كنت بحاجة إلى مساعدة فورية بشأن هذه المشكلة ، فيرجى الاتصال بدعم NetApp.

لفتح حالة باستخدام NetApp ، يرجى الانتقال إلى https://mysupport.netapp.com/site/.
أسفل اليسار ، انقر فوق "الاتصال بالدعم"
ابحث عن الرقم المناسب من منطقتك للاتصال به أو تسجيل الدخول.
ملاحظة: Trident غير مدرج في الصفحة ، ولكنه منتج مدعوم بواسطة NetApp استنادًا إلى تخزين Netapp SN المدعوم.
افتح العلبة على تخزين NetApp SN ، وقدم وصفًا للمشكلة.
تأكد من ذكر المنتج هو Trident على Kubernetes ، وقدم التفاصيل. أذكر هذا GitHub.
سيتم توجيه الحالة إلى مهندسي دعم Trident للاستجابة.

مرحبا gnarl شكرا لك على الرد السريع. بقدر ما أستطيع أن أرى ، هناك مهلة صعبة لمدة 5 ثوانٍ على هذا الأمر ، وهو في حقل ترايدنت: https://github.com/NetApp/trident/blob/0a245d3895af31f910a58c2f26e5a0f8b25f34f8/utils/osutils.go#L2306

بقدر ما أستطيع أن أرى العقد الخاصة بنا لم يتم تحميلها على الإطلاق (على سبيل المثال في العقدة ، نرى الآن المشكلة load average: 0.54, 0.62, 0.61 ) ولا أعتقد أن هذا من شأنه أن يفسر السلوك الذي نلاحظه.
هل هناك سبب لانتهاء الترميز الثابت؟ هل يمنع حالة لسنا على علم بها؟

ffilippopoulos ، يجب ألا يستغرق تشغيل blkid ما يقرب من 5 ثوانٍ للتشغيل. إذا كان الحمل على مضيفك يبدو جيدًا ، فهل يمكنك فحص زمن انتقال الشبكة بين المضيف و NetApp dataLIF؟

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

إغلاق هذا لأننا لم نره منذ أن قمنا بتصحيح سرعة روابط الشبكة. شكرا جزيلا لمساعدتك! :))

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