<p>يشتكي kubeadm من bridge-nf-call و ip_forward في حالة عدم استخدام وقت تشغيل عامل الإرساء</p>

تم إنشاؤها على ١٦ أغسطس ٢٠١٨ · 10تعليقات · مصدر: kubernetes/kubeadm

هل هذا تقرير خطأ أم طلب ميزة؟ :

/ نوع الخطأ

ماذا حدث :

بعد تشغيل نظام نظيف ، يؤدي تشغيل kubeadm init مع وقت تشغيل CRI بخلاف تكوين عامل الإرساء إلى ظهور الزوجين التاليين من رسائل الخطأ:

[ERROR FileContent--proc-sys-net-bridge-bridge-nf-call-iptables]: /proc/sys/net/bridge/bridge-nf-call-iptables does not exist [ERROR FileContent--proc-sys-net-ipv4-ip_forward]: /proc/sys/net/ipv4/ip_forward contents are not set to 1

ما توقعت حدوثه :

يجب اجتياز هذين الفحصين قبل الرحلة لأنه يمكن إرضاؤهما تلقائيًا.

من الواضح أنه يتم التعامل معها تلقائيًا من خلال بدء البرنامج الخفي docker طبيعي ، ولكن بالنسبة لـ openSUSE Kubic ، فإننا نتحرى عن استخدام CRI-O افتراضيًا ، حيث لا نمتلك رفاهية الخفي المتعجرف للتدخل في مثل هذه الأشياء .

لذلك فإن تقرير الخطأ هذا هو إما فرصة لـ kubeadm للتعامل مع الأشياء بنفسه. أعتقد أن هناك سببًا لذلك نظرًا لأن kubeadm يعرف ما يحتاج إليه ، يجب على kubeadm modprobe br_netfilter و echo '1' > /proc/sys/net/ipv4/ip_forward تلقائيًا بدلاً من الشكوى من المشكلات.

بدلاً من ذلك ، إذا كان هذا الاقتراح غير مقبول ، فسأكون ممتنًا لاقتراح حول كيفية قيام openSUSE Kubic بمعالجة هذه المشكلات تلقائيًا بطريقة تظل متوافقة مع التوقعات العامة لـ kubeadm.

كيفية إعادة إنتاجه (بأقل قدر ممكن من الدقة والدقة) :

قم بتثبيت kubeadm و cri-o
systemctl تمكن - الآن كريو
قم بتكوين kubeadm لتشغيل kublet بأرقام إضافية --container-runtime=remote --container-runtime-endpoint=unix:///var/run/crio/crio.sock --runtime-request-timeout=15m
تشغيل kubeadm init --cri-socket /var/run/crio/crio.sock

أي شيء آخر نحن بحاجة إلى معرفته؟ :

البيئة :

إصدار Kubernetes (استخدم kubectl version ): v1.11.2
مزود السحابة أو تكوين الأجهزة: qemu-kvm x86_64 16GB RAM 2 core
نظام التشغيل (على سبيل المثال من / etc / os-release): opensuse-tumbleweed-kubic
Kernel (على سبيل المثال uname -a ): 4.17.13
أدوات التثبيت: kubeadm

help wanted kinbug

مصدر

sysrich

👍6

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

لقد أدت إعادة تشغيل Docker إلى الحيلة ... شكرًا لك

itpings في ٢٥ أبريل ٢٠١٩

👍10 ❤7 😕1

ال 10 كومينتر

لا يبدو وكأنه خطأ في المنتج ، ولكن خطأ في التوثيق (مجرد دليل مفقود). حاليًا لدينا صفحات فقط حول كيفية تثبيت kubernetes مع kubeadm مع عامل الإرساء كوقت تشغيل الحاوية ، يجب أن يكون لدينا صفحة أخرى لـ cri-o.

outcoldman في ٣ سبتمبر ٢٠١٨

يجب أن يقوم kubeadm IMO على الأقل بعمل modprobe نفسه. سواء كان الأمر كذلك بالنسبة لـ ip_forward أيضًا فهو قابل للنقاش لأن هذا هو تكوين النظام ويعود إلى المسؤول.

Vogtinator في ١٢ سبتمبر ٢٠١٨

@ vrothberg - ما رأيك؟ هل يجب تصحيح الشرطين المذكورين أعلاه (modprobe و sysctl) تلقائيًا بواسطة kubeadm ، أم أنك تعتقد أن هذا أمر أفضل في CRI-O؟

يقوم Docker بنفسه تلقائيًا

وإذا كنت تعتقد أن CRI-O المناسب لا ينبغي أن يحذر ، فأين تعتقد أنه يجب تنفيذ الاختراق القذر في openSUSE؟ في حزمة cri-o أو في حزمة kubeadm؟ ؛)

sysrich في ١٢ سبتمبر ٢٠١٨

أعتقد أن هذا شيء يجب أن تفعله حزمة kubeadm. بعد ذلك نستطيع
تحقق مما إذا كان هذا خطأ حقًا أم أنه يمكن تخفيضه إلى سجل معلومات.
لا تزال العديد من الأشياء في K8s مبنية حول كيفية قيام Docker بعمل الأشياء ولكن
ليست ضرورية دائمًا.

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

يوم الأربعاء 12 سبتمبر 2018 الساعة 10:30 ، Richard Brown [email protected]
كتب:

vrothberg https://github.com/vrothberg - ما رأيك؟ ينبغي لل
فوق 2 من الشروط (modprobe و sysctl) يتم تصحيحها تلقائيًا بواسطة
kubeadm ، أو هل تعتقد أن هذا شيء يتم التعامل معه بشكل أفضل في CRI-O؟
يقوم Docker بنفسه تلقائيًا
وإذا كنت تعتقد أن CRI-O المناسب لا ينبغي أن يعتني ، فأين تعتقد أن
يجب أن يتم الاختراق القذر في openSUSE؟ في حزمة cri-o أو في
حزمة kubeadm؟ ؛)
-
أنت تتلقى هذا لأنه تم ذكرك.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
https://github.com/kubernetes/kubeadm/issues/1062#issuecomment-420559942 ،
أو كتم الخيط
https://github.com/notifications/unsubscribe-auth/ALI4g1dRKf5vWXz_7H27VktuD8nP5tAsks5uaMYogaJpZM4V_W70
.

vrothberg في ١٢ سبتمبر ٢٠١٨

سيتم التعامل مع هذه المشكلة في openSUSE بالتغييرات التالية: https://build.opensuse.org/package/rdiff/devel : kubic / kubernetes؟ linkrev = base & rev = 9

أخطط لإرسال شيء مشابه في عبوة rpm المنبع على الفور

sysrich في ١٣ سبتمبر ٢٠١٨

لقد أدت إعادة تشغيل Docker إلى الحيلة ... شكرًا لك

itpings في ٢٥ أبريل ٢٠١٩

👍10 ❤7 😕1

أنا ثاني إضافة هذه المعلومات إلى صفحة الإعداد. كنت أرى هذا الخطأ وتسبب لي على الأقل 20 دقيقة من الألم حتى صادفت هذا الخيط. شكرا لتقاسم الحل.

adobo76 في ١٣ يونيو ٢٠١٩

تأكد من اتباع الإجراء ثم لا يحدث الخطأ
https://kubernetes.io/docs/setup/production-environment/container-runtimes/#cri -o

danielsand في ٢٦ مارس ٢٠٢٠

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

عند اتباع الإرشادات الخاصة بأشياء مثل هذه ، لا أحب القراءة في الأشياء ومحاولة اتخاذ خطوات إضافية بناءً على الحدس. إذا أخبرني أن أفعل شيئًا ، فأنا أفعله. إذا لم أفعل. أنتظر حتى تنكسر الأشياء وتعود وأصلحها. بهذه الطريقة لدي فكرة أفضل إذا كان التوثيق السيئ هو المشكلة بدلاً من بعض الأشياء العشوائية التي فعلتها عندما تنكسر الأمور.