صف الخلل
نلاحظ الكثير من البودات عالقة بشكل عشوائي عند ContainerCreating
state لأنها لا تستطيع تحميل netapp pvcs. يشير وصف نقاط pods إلى المهلات أثناء الحصول على معلومات جهاز iSCSI وسجلات ترايدنت daemonset إلى أن هذا يرجع إلى انقضاء المهلات أثناء تنفيذ الأمر blkid
على المضيف.
هذا حدث عشوائي ولا يمكن ربطه مع مضيفين و pvcs معينين.
بيئة
لإعادة إنتاج
يمكننا ملاحظته بشكل عشوائي على العقد العنقودية (لا يبدو أنه مرتبط بمجموعة معينة من المضيفين)
سلوك متوقع
سلوك تثبيت ثابت خلال فترة زمنية معقولة.
سياق إضافي
من خلال وصف حجرة "عالقة" يمكننا رؤية:
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" ،
"الافتراضيات": {
"التشفير": "صحيح"
}
}
""
نحن عالقون هنا حقًا ، لذا فإن أي مساعدة في هذا الأمر ستكون محل تقدير كبير!
مرحبا 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 من إرفاق وحدة التخزين بأمان.
إغلاق هذا لأننا لم نره منذ أن قمنا بتصحيح سرعة روابط الشبكة. شكرا جزيلا لمساعدتك! :))
التعليق الأكثر فائدة
إغلاق هذا لأننا لم نره منذ أن قمنا بتصحيح سرعة روابط الشبكة. شكرا جزيلا لمساعدتك! :))