Flannel: وصول بطيء للغاية إلى عنوان IP للخدمة من المضيف (والبودات المتصلة بالشبكة المضيفة) باستخدام Flannel CNI

نرى تقارير متعددة تفيد بأن flannel + kube 1.17 لا يعمل بشكل جيد:

• https://github.com/kubernetes/kubernetes/issues/86961#issuecomment -572666655
• https://github.com/coreos/flannel/issues/1243

tomdee هل يمكنك إلقاء نظرة على هذه؟

أعتقد أنني كنت أتطرق إلى هذه المشكلة أمس / اليوم

بعض الاختبارات التي كنت أجريها ، من مضيف واحد (ليس في حاوية)

• حليقة http: // عملت
• عملت curl http: // service-ip بعد تأخير لمدة ثانية واحدة. أظهر tcpdump إعادة الإرسال التي مرت. كان هذا قابلاً للتكرار

لقد قمت للتو بالتبديل إلى الواجهة الخلفية host-gw وكل شيء يعمل بشكل طبيعي

الفانيلا: 0.11.0
kubernetes: 1.17.2 ، مثبتة باستخدام kubeadm
على شبكة Baremetal المبدلة.

ما لاحظناه هو أن عدد conntrack insert_failed كان أعلى بشكل كبير أثناء تشغيل kube 1.17.

لقد واجهنا نفس المشكلة اليوم. تم إصلاح هذا باستخدام حلmikebryant. هل هناك حل دائم في الطريق؟

tomdee لأنك آخر لإلقاء نظرة على هذا الأمر.

لمعلوماتك فقط ، لا يتعلق هذا بـ 1.17 فقط .. بسبب هذه المشكلات هنا ، حاولت الرجوع من 1.17.3 إلى 1.16.8 ، ولكن نفس النتيجة
بادئ ذي بدء ، المسار مفقود من خدمة cidr إلى بوابة واجهة cni0 ، لذلك اضطررت إلى إضافته يدويًا حتى يتم حله

ip route add 10.96.0.0/12 via 10.244.3.1

وبعد ذلك ، حتى مسار التتبع يكون بطيئًا للغاية

traceroute <service>.<namespace>.svc.cluster.local
traceroute to <service>.<namespace>.svc.cluster.local (10.106.49.44), 30 hops max, 38 byte packets
 1  10.244.3.1 (10.244.3.1)  3097.057 ms !H  3097.946 ms !H  3119.540 ms !H

مجرد فضول ، كم عدد الأشخاص الذين يعانون من هذه المشكلة يستخدمون hyperkube؟

أواجه هذه المشكلة مع vxlan backend مع كلا الإصدارين 0.11 و 0.12 من flannel أيضًا.
إصدارات kubernetes المتأثرة 1.16.X و 1.17.x و 1.18.x.

أخيرًا ، ساعدني إعداد مسار ثابت على العقد الخاصة بي لشبكة الخدمة من خلال واجهة cni0 على الفور:
ip route add 10.96.0.0/12 dev cni0

نظام التشغيل: CentOS 7
طريقة التثبيت: kubeadm
النموذج الأساسي: Virtualbox 6

أخيرًا ، ساعدني إعداد مسار ثابت على العقد الخاصة بي لشبكة الخدمة من خلال واجهة cni0 على الفور:
ip route add 10.96.0.0/12 dev cni0

تم إصلاح هذه المشكلة باستخدام حل mengmann في إصدار kubernetes v1.17.2.

أعتقد أنني كنت أتطرق إلى هذه المشكلة أمس / اليوم

بعض الاختبارات التي كنت أجريها ، من مضيف واحد (ليس في حاوية)

• حليقة http: // عملت
• عملت curl http: // service-ip بعد تأخير لمدة ثانية واحدة. أظهر tcpdump إعادة الإرسال التي مرت. كان هذا قابلاً للتكرار

لقد قمت للتو بالتبديل إلى الواجهة الخلفية host-gw وكل شيء يعمل بشكل طبيعي

الفانيلا: 0.11.0
kubernetes: 1.17.2 ، مثبتة باستخدام kubeadm
على شبكة Baremetal المبدلة.

بالضبط نفس المشكلة هنا

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

• حليقة http: // عملت
• عملت curl http: // service-ip بعد تأخير لمدة ثانية واحدة. أظهر tcpdump إعادة الإرسال التي مرت. كان هذا قابلاً للتكرار

لقد قمت للتو بالتبديل إلى الواجهة الخلفية host-gw وكل شيء يعمل بشكل طبيعي
الفانيلا: 0.11.0
kubernetes: 1.17.2 ، مثبتة باستخدام kubeadm
على شبكة Baremetal المبدلة.

بالضبط نفس المشكلة هنا

لست متأكدًا مما إذا كانت نفس المشكلة ولكننا لاحظنا تأخيرًا إضافيًا لمدة ثانية واحدة عند الترقية من kubernetes 1.15.3 إلى 1.18.1. يبدو أننا نتتبع المشكلة إلى علامة --random-fully التي قدمها PR هذا . انظر القضية هنا

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

• حليقة http: // عملت
• عملت curl http: // service-ip بعد تأخير لمدة ثانية واحدة. أظهر tcpdump إعادة الإرسال التي مرت. كان هذا قابلاً للتكرار

لقد قمت للتو بالتبديل إلى الواجهة الخلفية host-gw وكل شيء يعمل بشكل طبيعي
الفانيلا: 0.11.0
kubernetes: 1.17.2 ، مثبتة باستخدام kubeadm
على شبكة Baremetal المبدلة.

بالضبط نفس المشكلة هنا

لست متأكدًا مما إذا كانت نفس المشكلة ولكننا لاحظنا تأخيرًا إضافيًا لمدة ثانية واحدة عند الترقية من kubernetes 1.15.3 إلى 1.18.1. يبدو أننا نتتبع المشكلة إلى علامة --random-fully التي قدمها PR هذا . انظر القضية هنا

أنا أعمل حاليًا مع kubernetes 17.3 (بعض العقد 17.4). لحسن الحظ ، لا يوجد الكثير من التطبيقات التي تعمل على الكتلة المبنية حديثًا ، لذلك قمت بترحيلها هذا الأسبوع وغيرت نسيج الشبكة إلى كاليكو وفقًا لهذه المقالة. الآن كل شيء يعمل بشكل مثالي. 😄