Trident: لا يحتوي CSINode على برنامج التشغيل csi.trident.netapp.io

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

وصف
باستخدام مشغل ترايدنت و kubernetes 1.17.6 ، يمكنني إنشاء مجلدات ثابتة ، لكن لا يمكنني تركيبها في الكبسولات.

عند الحصول على وصف الحجرة ، يتم إرجاع الخطأ التالي:
CSINode does not contain driver csi.trident.netapp.io

بيئة

  • إصدار Trident: [20.07.1]
  • تم استخدام علامات تثبيت Trident: [لا توجد علامات مخصصة ، نظرًا لأننا نستخدم الموقع الافتراضي / var / lib / kubelet]
  • وقت تشغيل الحاوية: [Docker 19.3.12]
  • إصدار Kubernetes: [1.17.6]
  • منسق Kubernetes: [لا شيء]
  • بوابات ميزات تم تمكين Kubernetes لها: [لا شيء مطلوب]
  • نظام التشغيل: [Centos 7 - 3.10.0-1062.12.1.el7.x86_64]
  • أنواع الواجهة الخلفية لـ NetApp: [OnTap 9.7]
  • آخر:

لإعادة إنتاج
تثبيت عامل التشغيل كما هو موضح هنا: https://netapp-trident.readthedocs.io/en/stable-v20.07/kubernetes/deploying/operator-deploy.html

بعد إنشاء فئة التخزين ، والمستهلك ، يتم ربط pv ، لكن الكبسولة لا يمكنها إرفاق وحدة التخزين محليًا بالعامل

سلوك متوقع
كان من المتوقع أن يقوم الجراب بتحميل وحدة التخزين وتشغيله. بدلا من ذلك يبقى فقط في "معلق"
سياق إضافي
وصف جراب:
يصف اختبار kubectl -n po web-0
فشل التحذير
عادي مجدول افتراضي 9s مجدول تم بنجاح تعيين test / web-0 إلى hh1kbw02x
فشل التحذير(x6 أكثر) إرفاق وحدة تحكم AttachVolume.Attach فشل لوحدة التخزين "pvc-934230b9-900c-4539-bb0c-8feff6e18628": CSINode hh1kbw02x لا يحتوي على برنامج التشغيل csi.trident.netapp.io
فشل التحذير(x6 أكثر) إرفاق وحدة تحكم AttachVolume.Attach فشل لوحدة التخزين "pvc-f4c2b654-ff73-4dd5-84ef-a31491b83f26": CSINode hh1kbw02x لا يحتوي على برنامج التشغيل csi.trident.netapp.io



Logs from trident on this worker:

kubectl -n trident logs trident-csi-9sgrt -c trident-main -f
الوقت = "2020-10-21T17: 15: 31Z" level = debug msg = "n >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> nPUT https://10.111.4.90 : 34571 / trident / v1 / node / hh1kbw02xnHeaders: map [Content-Type: [application / json]] nBody: {n "name": "hh1kbw02x"، n "ips": [n "10.49.12.102" ، ن "172.17.0.1" n] n} n --------------------------------- ----------------------------------------------- "
الوقت = "2020-10-21T17: 15: 32Z" المستوى = تصحيح الأخطاء msg = "n <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<


Logs from registrar sidecar on this worker:

kubectl -n trident logs trident-csi-9sgrt -c driver-registrar
I1021 17: 14: 18.636803 6672 main.go: 110] الإصدار: v1.3.0-0-g6e9fff3e
I1021 17: 14: 18.636888 6672 main.go: 120] محاولة فتح اتصال gRPC مع: "/plugin/csi.sock"
I1021 17:14: 18.636908 6672 connect.go: 151] التوصيل بـ unix: ///plugin/csi.sock
I1021 17: 14: 18.637420 6672 main.go: 127] استدعاء سائق CSI لاكتشاف اسم السائق
I1021 17: 14: 18.637435 6672 connect.go: 180] استدعاء GRPC: /csi.v1.Identity/GetPluginInfo
I1021 17: 14: 18.637442 6672 connect.go: 181] طلب GRPC: {}
I1021 17: 14: 18.639851 6672 connection.go: 183] استجابة GRPC: {"name": "csi.trident.netapp.io"، "vendor_version": "20.07.1"}
I1021 17:14: 18.640235 6672 connect.go: 184] خطأ GRPC:
I1021 17: 14: 18.640242 6672 main.go: 137] اسم برنامج تشغيل CSI: "csi.trident.netapp.io"
I1021 17: 14: 18.648537 6672 node_register.go: 51] بدء خادم التسجيل على: /registration/csi.trident.netapp.io-reg.sock
I1021 17:14: 18.648666 6672 node_register.go: 60] بدأ خادم التسجيل في: /registration/csi.trident.netapp.io-reg.sock


Description of csi node

kubectl الحصول على csinode hh1kbw02x -n ترايدنت -o yaml
الإصدار: storage.k8s.io/v1
النوع: CSINode
البيانات الوصفية:
الخلق الطابع الزمني: 2020-09-10T07: 58: 40Z
الاسم: hh1kbw02x
المالك المراجع:

  • الإصدار: v1.0
    النوع: عقدة
    الاسم: hh1kbw02x
    uid: d3db28d6-e2be-4ad4-8534-c853b2e025b5
    الموارد الإصدار: "30914526"
    selfLink: /apis/storage.k8s.io/v1/csinodes/hh1kbw02x
    uid: a764977a-be67-4ee9-8b7e-9aac304e0890
    المواصفات:
    السائقين: لاغية

سجلات Kubelet:
6 تشرين الثاني (نوفمبر) 10:14:18 hh1kbw01x kubelet: I1106 10: 14: 18.883059 2393augiler.go: 209] operationExecutor.VerifyControllerAttachedVolume بدأ لوحدة التخزين "pvc-3bcc4e38-2e69-4541-9910-711d2c086671" (UniqueesName: "kubernet.net csi / csi.trident.netapp.io ^ pvc-3bcc4e38-2e69-4541-9910-711d2c086671 ") pod" web-0 "(UID:" a235d5f9-05bf-4c77-8a84-e48f2f657d98 ")
6 تشرين الثاني (نوفمبر) 10:14:18 hh1kbw01x kubelet: E1106 10: 14: 18.883223 2393 nestedpendingoperations.go: 301] عملية لـ "{v olumeName: kubernetes.io/csi/csi.trident.netapp.io ^ pvc-3bcc4e38-2e69- 4541-9910-711d2c086671 podName: nodeName:} "فشل. لا يُسمح بإعادة المحاولة حتى 2020-11-06 10: 14: 19.383183856 +0100 CET م = + 1353591.737508759 (المدة قبل إعادة المحاولة 500 مللي ثانية). خطأ: "لم تتم إضافة وحدة التخزين إلى قائمة VolumesInUse في حالة وحدة تخزين العقدة لوحدة التخزين" pvc-3bcc4e38-2e69-4541-9910-711d2c086671 "(UniqueName:" kubernetes.io/csi/csi.trident.netapp.io ^ pvc-3bcc4e38-2e69-4541-9910-711d2c086671 ") pod" web-0 "(UID:" a235d5f9-05bf-4c77-8a84-e48f2f657d98 ")"
تشرين الثاني (نوفمبر) 6 10:14:18 hh1kbw01x kubelet: I1106 10: 14: 18.983580 2393augiler.go: 209] operationExecutor.VerifyControllerAttachedVolume قيد التشغيل لوحدة التخزين "pvc-f138b6cc-988b-455c-bb2e-fce022755634" (Uniqueesio.io: " csi / csi.trident.netapp.io ^ pvc-f138b6cc-988b-455c-bb2e-fce022755634 ") pod" web-0 "(UID:" a235d5f9-05bf-4c77-8a84-e48f2f657d98 ")
6 تشرين الثاني (نوفمبر) 10:14:18 hh1kbw01x kubelet: E1106 10: 14: 18.983662 2393 nestedpendingoperations.go: 301] عملية لـ "{v olumeName: kubernetes.io/csi/csi.trident.netapp.io ^ pvc-f138b6cc-988b- 455c-bb2e-fce022755634 podName: nodeName:} "فشل. لا يُسمح بإعادة المحاولة حتى 2020-11-06 10: 14: 19.483629729 +0100 CET م = + 1353591.837954619 (المدة قبل إعادة المحاولة 500 مللي ثانية). خطأ: "لم تتم إضافة وحدة التخزين إلى قائمة VolumesInUse في حالة وحدة تخزين العقدة لوحدة التخزين" pvc-f138b6cc-988b-455c-bb2e-fce022755634 "(UniqueName:" kubernetes.io/csi/csi.trident.netapp.io ^ pvc-f138b6cc-988b-455c-bb2e-fce022755634 ") pod" web-0 "(UID:" a235d5f9-05bf-4c77-8a84-e48f2f657d98 ")"
6 تشرين الثاني (نوفمبر) 10:14:19 hh1kbw01x kubelet: I1106 10: 14: 19.385072 2393augiler.go: 209] operationExecutor.VerifyControllerAttachedVolume بدأ تشغيلها لوحدة التخزين "pvc-3bcc4e38-2e69-4541-9910-711d2c086671" (UniqueesName: "kubernet csi / csi.trident.netapp.io ^ pvc-3bcc4e38-2e69-4541-9910-711d2c086671 ") pod" web-0 "(UID:" a235d5f9-05bf-4c77-8a84-e48f2f657d98 ")
""

bug
مصدر
picture alexandru-ersenie

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

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

لقد كان مضللاً للغاية ، لأننا قمنا بتكوين الكوبيليتات الخاصة بنا للبدء بملفات التكوين الموجودة تحت / var / lib / kubelet ، وهو مسار الجذر الافتراضي.

منذ شهرين ، قررنا تقسيم الدماغ ، ونقل الكبسولات والحاويات إلى موقع تخزين منفصل ، لذلك قمنا بفصل الإدارة عن العملية

لذلك قمنا بتغيير root-dir في ملف التكوين للإشارة إلى / حاويات بدلاً من / var / lib / kubelet

سيبحث موفر ترايدنت الافتراضي في الموقع الافتراضي ، و "يدمج" الملحقات ، إذا جاز التعبير.

لذلك عليك التحقق من شيئين:

  1. ps aux | grep kubelet | grep -e 'root-dir -> أخذ المجلد الذي تم تكوينه (في حالتي كان المجلد / الحاوية)
  2. قم بتغيير trident_provisioner_cr.yaml ، وقم بتخصيصه بإضافة المعلمة " kubeletDir "
    apiVersion: trident.netapp.io/v1 kind: TridentProvisioner metadata: name: trident namespace: trident spec: debug: true kubeletDir: /container

حظا سعيدا أنا أغلق هذا.

picture alexandru-ersenie في ١٩ نوفمبر ٢٠٢٠
🎉1 👍1

ال 6 كومينتر

مشكلة مماثلة هنا مع Rancher RKE و K8S (v1.18.10) والعقد التي تقوم بتشغيل Ubuntu 18.04.4 LTS مع Docker 19.3.13 ، تطابق بقية البيئة المذكورة أعلاه ...

smangelkramer picture smangelkramer في ٣٠ أكتوبر ٢٠٢٠

نفس الشيء هنا مع k8s المنبع على أوبونتو 18.04

AndreasDeCrinis picture AndreasDeCrinis في ١٣ نوفمبر ٢٠٢٠

تمكنت من "حلها" من خلال إعادة نشر كل من مجموعة ترايدنت-سي إس آي ، ونشر وإعادة تشغيل كوبليت بعد ذلك

AndreasDeCrinis picture AndreasDeCrinis في ١٣ نوفمبر ٢٠٢٠

نعم. لقد استخدمت tridentctl بدلاً من عامل التشغيل.

smangelkramer picture smangelkramer في ١٣ نوفمبر ٢٠٢٠

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

لقد كان مضللاً للغاية ، لأننا قمنا بتكوين الكوبيليتات الخاصة بنا للبدء بملفات التكوين الموجودة تحت / var / lib / kubelet ، وهو مسار الجذر الافتراضي.

منذ شهرين ، قررنا تقسيم الدماغ ، ونقل الكبسولات والحاويات إلى موقع تخزين منفصل ، لذلك قمنا بفصل الإدارة عن العملية

لذلك قمنا بتغيير root-dir في ملف التكوين للإشارة إلى / حاويات بدلاً من / var / lib / kubelet

سيبحث موفر ترايدنت الافتراضي في الموقع الافتراضي ، و "يدمج" الملحقات ، إذا جاز التعبير.

لذلك عليك التحقق من شيئين:

  1. ps aux | grep kubelet | grep -e 'root-dir -> أخذ المجلد الذي تم تكوينه (في حالتي كان المجلد / الحاوية)
  2. قم بتغيير trident_provisioner_cr.yaml ، وقم بتخصيصه بإضافة المعلمة " kubeletDir "
    apiVersion: trident.netapp.io/v1 kind: TridentProvisioner metadata: name: trident namespace: trident spec: debug: true kubeletDir: /container

حظا سعيدا أنا أغلق هذا.

alexandru-ersenie picture alexandru-ersenie في ١٩ نوفمبر ٢٠٢٠
🎉1 👍1

لوحظ شيئًا مشابهًا عندما لا تتمكن كبسولات daemonset trident-csi من الاتصال بـ trident-controller . في هذه الحالة ، كان ذلك بسبب سياسة الشبكة التي منعتها.

balaramesh picture balaramesh في ٧ ديسمبر ٢٠٢١
هل كانت هذه الصفحة مفيدة؟
0 / 5 - 0 التقييمات

القضايا ذات الصلة

tksm picture tksm  ·  4تعليقات
Numblesix picture Numblesix  ·  5تعليقات
arndt-netapp picture arndt-netapp  ·  6تعليقات
takuhiro picture takuhiro  ·  5تعليقات
ffilippopoulos picture ffilippopoulos  ·  4تعليقات