Helm: تقارير `حذف الدفة`" فقد الاتصال بالجهاز "" خطأ: يتم إغلاق النقل "على الرغم من النجاح الظاهر
رأس العميل والخادم 2.6.1
k8s 1.7.4 (نفس السلوك مع 1.7.0 أيضًا)
لقد رأيت العديد من المشكلات التي تناقش "فقد الاتصال بالجراب" ولكن لا يوجد أي منها يتطابق مع حالتنا.
عندما أقوم بتشغيل تقارير helm delete --purge _releaseName_ helm
portforward.go:178] lost connection to pod
Error: transport is closing
ومع ذلك ، يبدو أن delete قد نجح. يتم تنظيف جميع موارد k8s المحددة في الرسم البياني كما هو متوقع. يبدو سجل الحارث كما يلي:
[storage] 2017/09/28 14:14:19 getting release history for "xxx"
[tiller] 2017/09/28 14:14:19 uninstall: Deleting xxx
[tiller] 2017/09/28 14:14:19 executing 0 pre-delete hooks for xxx
[tiller] 2017/09/28 14:14:19 hooks complete for pre-delete xxx
[storage] 2017/09/28 14:14:19 updating release "xxx.v1"
(many lines of "Starting delete for yyy" and "Using reaper for deleting yyy" omitted here)
[tiller] 2017/09/28 14:16:42 executing 0 post-delete hooks for xxx
[tiller] 2017/09/28 14:16:42 hooks complete for post-delete xxx
[tiller] 2017/09/28 14:16:42 purge requested for xxx
[storage] 2017/09/28 14:16:42 deleting release "xxx.v1"
هذه نهاية السجل. لا يحتوي على أخطاء أو استثناءات.
تشير k8s إلى عدم إعادة تشغيل جراب الحارث.
الوقت المنقضي ، من الخارج ومن السجل ، حوالي 2 مليون و 30 ثانية ، وهو أقل بكثير من قيمة المهلة الافتراضية لعملية delete .
في أي مكان آخر يمكنني البحث عن مزيد من المعلومات حول الخطأ الذي يتسبب في حدوث هذا الخطأ؟
شكرا.
tjquinno
ال 3 كومينتر
يبدو هذا مثل https://github.com/kubernetes/helm/issues/2025 إذا كان أقل بكثير من المهلة الافتراضية (5 دقائق). هل يمكنك التحقق من موازن التحميل الذي يواجه واجهة برمجة تطبيقات kubernetes الرئيسية الخاصة بك والتعليق على هذه المشكلة من الآن فصاعدًا؟ بهذه الطريقة يمكننا الاحتفاظ بالمناقشة في مكان واحد. شكرا لك! ❤️
bacongobbler
في ٢٩ سبتمبر ٢٠١٧
رأيت الخطأ Error: transport is closing أيضًا عندما قمت بتشغيل helm install ، وبعد تنفيذ rm -rf ~/.helm ، لم يعد الخطأ مرئيًا. تخمين أن حذف ذاكرة التخزين المؤقت للدفة ( rm -rf ~/.helm ) قد يحل الخطأ.
vhosakot
في ٣٠ مايو ٢٠١٨
تمكنت من تصحيح هذا عن طريق إضافة معلومات مضيف الحارث إلى أمر تثبيت الدفة.
--host=10.111.221.14:443
يمكنك الحصول على IP الخاص بك عن طريق هذه الطريقة
$ kubectl get svc -n kube-system tiller-deploy
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
tiller-deploy ClusterIP 10.111.221.14 <none> 44134/TCP 34h
مثال قيادة كامل
helm install stable/grafana --name=grafana --host=10.111.221.14:4413
أعلم أن هذا قليل من العمل ولكن جميع وظائف الدفة الأخرى تعمل بشكل صحيح بعد التثبيت عبر هذه الطريقة. لم أضطر إلى إضافة معلومات المضيف مرة أخرى بعد التثبيت الأولي لإجراء الترقيات أو التراجع. أتمنى أن يساعدك هذا!
castironclay
في ٢١ أبريل ٢٠١٩
القضايا ذات الصلة
sgoings
·
3تعليقات
mikhno-s
·
3تعليقات
technosophos
·
3تعليقات
hobti01
·
3تعليقات
dkirrane
·
3تعليقات
التعليق الأكثر فائدة
تمكنت من تصحيح هذا عن طريق إضافة معلومات مضيف الحارث إلى أمر تثبيت الدفة.
--host=10.111.221.14:443يمكنك الحصول على IP الخاص بك عن طريق هذه الطريقة
$ kubectl get svc -n kube-system tiller-deployNAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGEtiller-deploy ClusterIP 10.111.221.14 <none> 44134/TCP 34hمثال قيادة كامل
helm install stable/grafana --name=grafana --host=10.111.221.14:4413أعلم أن هذا قليل من العمل ولكن جميع وظائف الدفة الأخرى تعمل بشكل صحيح بعد التثبيت عبر هذه الطريقة. لم أضطر إلى إضافة معلومات المضيف مرة أخرى بعد التثبيت الأولي لإجراء الترقيات أو التراجع. أتمنى أن يساعدك هذا!