رائع! أعتقد أنه يجب علينا بالتأكيد دمج هذا. في ملاحظة منفصلة ، كنت أرى الوكيل يأكل حوالي 30٪ من النواة تحت عبء ثقيل ، يجب أن أصدق أن iptables ستمنحنا أداءً أفضل من ذلك.

يجب أن نعطي الأولوية لهذا - إنها إعادة كتابة كاملة تقريبًا لـ kube-proxy و
كل الاختبارات. كما أن لديها مشاكل في التوافق الخلفي (لن تعمل على
النوى الأقدم أو ثنائيات iptables الأقدم).

يوم الاثنين ، 26 كانون الثاني (يناير) 2015 الساعة 11:06 صباحًا ، Brendan Burns [email protected]
كتب:

رائع! أعتقد أنه يجب علينا بالتأكيد دمج هذا. وفي ملاحظة منفصلة ،
كنت أرى الوكيل يأكل حوالي 30٪ من اللب تحت حمولة ثقيلة ، لا بد لي من ذلك
نعتقد أن iptables ستمنحنا أداءً أفضل من ذلك.

قم بالرد على هذا البريد الإلكتروني مباشرة أو قم بعرضه على GitHub
https://github.com/GoogleCloudPlatform/kubernetes/issues/3760#issuecomment -71517501
.

ربما يكون تطبيقه كخيار موازي والترحيل ببطء أمرًا منطقيًا؟

يوم الاثنين ، 26 كانون الثاني (يناير) 2015 الساعة 12:01 مساءً ، Tim Hockin [email protected]
كتب:

يجب أن نعطي الأولوية لهذا - إنها إعادة كتابة كاملة تقريبًا لـ kube-proxy و
كل الاختبارات. كما أن لديها مشاكل في التوافق الخلفي (لن تعمل على
النوى الأقدم أو ثنائيات iptables الأقدم).

يوم الاثنين ، 26 كانون الثاني (يناير) 2015 الساعة 11:06 صباحًا ، Brendan Burns [email protected]
كتب:

رائع! أعتقد أنه يجب علينا بالتأكيد دمج هذا. على حدة
ملاحظة،
كنت أرى الوكيل يأكل حوالي 30٪ من اللب تحت حمولة ثقيلة ، لا بد لي من ذلك
نعتقد أن iptables ستمنحنا أداءً أفضل من ذلك.

قم بالرد على هذا البريد الإلكتروني مباشرة أو قم بعرضه على GitHub
<
https://github.com/GoogleCloudPlatform/kubernetes/issues/3760#issuecomment -71517501

.

-
قم بالرد على هذا البريد الإلكتروني مباشرة أو قم بعرضه على GitHub
https://github.com/GoogleCloudPlatform/kubernetes/issues/3760#issuecomment -71527216
.

أحاول إقناع شخص آخر لا يعرف هذا الرمز جيدًا لتعلمه
وخذها. أنا حقًا _أريد_ أن أتصدى لها ، لكن سيكون من الأفضل لو
تعلم شخص آخر هذه المساحة (ليس أنت! :)

ومع ذلك ، فقد أرسلت أيضًا بريدًا إلكترونيًا (جيدًا) حول قائمة P1 الضخمة - وأنا
لا أعتقد أن هذا موجود في تلك القائمة حتى الآن.

يوم الاثنين ، 26 كانون الثاني (يناير) 2015 الساعة 1:06 مساءً ، Brendan Burns [email protected]
كتب:

ربما يتم تنفيذه كخيار مواز وترحيل ببطء يجعل
يشعر؟

يوم الاثنين ، 26 كانون الثاني (يناير) 2015 الساعة 12:01 مساءً ، Tim Hockin [email protected]
كتب:

يجب أن نعطي الأولوية لهذا - إنها إعادة كتابة كاملة تقريبًا لـ kube-proxy
و
كل الاختبارات. كما أن لديها مشاكل في التوافق الخلفي (لن تنجح
تشغيل
النوى الأقدم أو ثنائيات iptables الأقدم).

يوم الاثنين ، 26 كانون الثاني (يناير) 2015 الساعة 11:06 صباحًا ، بريندان بيرنز <
[email protected]>
كتب:

رائع! أعتقد أنه يجب علينا بالتأكيد دمج هذا. على حدة
ملاحظة،
كنت أرى الوكيل يأكل حوالي 30٪ من اللب تحت حمولة ثقيلة ، لا بد لي من ذلك
نعتقد أن iptables ستمنحنا أداءً أفضل من ذلك.

قم بالرد على هذا البريد الإلكتروني مباشرة أو قم بعرضه على GitHub
<

https://github.com/GoogleCloudPlatform/kubernetes/issues/3760#issuecomment -71517501

.

قم بالرد على هذا البريد الإلكتروني مباشرة أو قم بعرضه على GitHub
<
https://github.com/GoogleCloudPlatform/kubernetes/issues/3760#issuecomment-71527216>

.

قم بالرد على هذا البريد الإلكتروني مباشرة أو قم بعرضه على GitHub
https://github.com/GoogleCloudPlatform/kubernetes/issues/3760#issuecomment -71538256
.

هل هذا P2؟ هل يستحق الأمر جعله P3 في الوقت الحالي؟

آمل أن نجعلها تعمل ، لكن ربما نخفض رتبتها

يوم الأربعاء ، 11 فبراير 2015 ، الساعة 2:49 مساءً ، Satnam Singh [email protected]
كتب:

هل هذا P2؟ هل يستحق الأمر جعله P3 في الوقت الحالي؟

قم بالرد على هذا البريد الإلكتروني مباشرة أو قم بعرضه على GitHub
https://github.com/GoogleCloudPlatform/kubernetes/issues/3760#issuecomment -73982161
.

ألا تعني "الأمل" مستوى P3 الذي سنصل إليه إذا استطعنا؟

من المناقشة مع thockin : هذا مطلب لدعم نطاقات منافذ الخدمة ، والتي ليست مطلوبة لـ 1.0 ، لكننا نرغب في دعمه في النهاية.

thockin "هذا له جانب سلبي

ليس جديدًا جدًا ، ولكن لدينا بعض المستخدمين الذين يريدون حقًا iptables من 2012 إلى
الشغل.

يوم الاثنين 23 فبراير 2015 الساعة 2:44 مساءً ، Sidharta Seethana < [email protected]

كتب:

thockin https://github.com/thockin "هذا له جانب سلبي من عدم الوجود
متوافق مع iptables و kernels الأقدم. "ما مدى" الجديد "من kernel
يجب ان تكون؟

قم بالرد على هذا البريد الإلكتروني مباشرة أو قم بعرضه على GitHub
https://github.com/GoogleCloudPlatform/kubernetes/issues/3760#issuecomment -75654187
.

thockin شكرا. نحن نستخدم / نختبر مع RHEL / CentOS 6 ، على سبيل المثال - لذلك سيكون من الجيد إذا لم يكن لدينا اعتماد قوي على نواة 3.x الأخيرة.

@ pweil - كنا نناقش هذا الأمر قبل أيام
يوم الاثنين 23 فبراير 2015 الساعة 11:40 مساءً Sidharta Seethana [email protected]
كتب:

thockin https://github.com/thockin شكرا. نحن نستخدم / نختبر مع
RHEL / CentOS 6 ، على سبيل المثال - لذلك سيكون من الجيد إذا لم يكن لدينا صعوبة
الاعتماد على نواة 3.x الحديثة.

-
قم بالرد على هذا البريد الإلكتروني مباشرة أو قم بعرضه على GitHub
https://github.com/GoogleCloudPlatform/kubernetes/issues/3760#issuecomment -75698480
.

حسنًا ، أنت بحاجة إلى Docker للتشغيل ، وفي مرحلة ما يتعين علينا قطعه.
لن يمنعني دعم back-rev iptables من صنع ملفات
هذا التغيير ، وسيؤثر على بعض الناس.

يوم الاثنين 23 فبراير 2015 الساعة 8:40 مساءً ، Sidharta Seethana < [email protected]

كتب:

thockin https://github.com/thockin شكرا. نحن نستخدم / نختبر مع
RHEL / CentOS 6 ، على سبيل المثال - لذلك سيكون من الجيد إذا لم يكن لدينا صعوبة
الاعتماد على نواة 3.x الحديثة.

قم بالرد على هذا البريد الإلكتروني مباشرة أو قم بعرضه على GitHub
https://github.com/GoogleCloudPlatform/kubernetes/issues/3760#issuecomment -75698480
.

بمساعدة thockin ، حاولنا نفس الشيء مع udp.

لقد أنشأنا مجموعة GCE Kubernetes مع 3 وحدات تحكم في النسخ المتماثل لـ sky-dns.
في kubernetes-master ، قمنا بتعيين ما يلي في iptables:
كان عنوان IP لخدمة نظام أسماء النطاقات هو 10.0.0.10 ، وكانت نقاط نهاية البود التي تعمل بنظام أسماء النطاقات هي 10.244.0.5:53 و 10.244.3.6:53 و 10.244.0.6:53

iptables -t nat -N TESTSVC
iptables -t nat -F TESTSVC
iptables -t nat -N TESTSVC_A
iptables -t nat -F TESTSVC_A
iptables -t nat -N TESTSVC_B
iptables -t nat -F TESTSVC_B
iptables -t nat -N TESTSVC_C
iptables -t nat -F TESTSVC_C
iptables -t nat -N مضيف KUBE-PORTALS
iptables -t nat -F KUBE-PORTALS-HOST.COM

iptables -t nat -A TESTSVC -m حديث - اسم المضيف A - التحقق - ثانية 1 --reap -j TESTSVC_A
iptables -t nat -A TESTSVC -m حديث - اسم المضيف ب - فحص - ثانية 1 --reap -j TESTSVC_B
iptables -t nat -A TESTSVC -m حديث - اسم المضيف C - فحص - ثانية 1 --reap -j TESTSVC_C

iptables -t nat -A TESTSVC -m statistic - وضع عشوائي - الاحتمال 0.333 -j TESTSVC_A
iptables -t nat -A TESTSVC -m statistic - وضع عشوائي - احتمال 0.5 -j TESTSVC_B
iptables -t nat -A TESTSVC -m statistic - وضع عشوائي - الاحتمال 1.000 -j TESTSVC_C

iptables -t nat -A TESTSVC_A -m Recent --name hostA --set -j DNAT -p udp - to-destination 10.244.0.5:53
iptables -t nat -A TESTSVC_B -m Recent --name hostB --set -j DNAT -p udp - to-destination 10.244.3.6:53
iptables -t nat -A TESTSVC_C -m Recent - name hostC --set -j DNAT -p udp - to-destination 10.244.0.6:53
iptables -t nat -A KUBE-PORTALS-HOST -d 10.0.0.10/32 -p udp -m udp --dport 53 -j TESTSVC
iptables -t nat -A الإخراج -j KUBE-PORTALS-HOST

kubernetes-master> nslookup kubernetes.default.kuberenetes.local 10.0.0.10

لقد حصلنا على رد!

أشياء عظيمة! فقط لمعلوماتك (تأكيدًا من محادثتنا وجهًا لوجه) ، ليس من الآمن تشغيل أوامر iptables المتعددة المتزامنة بشكل عام (تبدو السلاسل المختلفة وكأنها قد تكون على ما يرام). iptables عبارة عن غلاف حول libiptc ، وانظر التعليق على iptc_commit: http://www.tldp.org/HOWTO/Querying-libiptc-HOWTO/mfunction.html

تم إصلاح هذا على ما يبدو في عام 2013 ، ولكن ربما فقط إذا نجحت - انتظر (؟): http://git.netfilter.org/iptables/commit/؟id=93587a04d0f2511e108bbc4d87a8b9d28a5c5dd8

السبب الجذري لهذا هو أن iptables يستدعي بشكل فعال iptables-save / iptables-response (على الأقل لكل سلسلة) ؛ لقد رأيت الكثير من التعليمات البرمجية التي تستدعي فقط iptables-save & iptables-Restore بدلاً من القيام بالأشياء من خلال عمليات الإضافة والحذف. قد يكون لدي بعض التعليمات البرمجية للقيام بذلك يمكنني البحث عنها إذا كان ذلك مفيدًا.

يحير ذهني أنه لا توجد طريقة للقيام بأنواع من العمليات في CAS أو LL / SC.

يجب أن نضيف دعمًا لـ - انتظر ، على الرغم من أنه حديث بما يكفي للحملة العالمية للتعليم
debian-backports لا يملكها.

ربما يجب أن نقوم بالقفل الخاص بنا داخل التعليمات البرمجية الخاصة بنا لمنعنا على الأقل
من الدوس على أنفسنا.

يوم الخميس ، 26 شباط (فبراير) 2015 الساعة 1:56 مساءً ، جاستن سانتا باربرا <
[email protected]> كتب:

أشياء عظيمة! فقط لمعلوماتك (تأكيدًا من محادثتنا وجهًا لوجه) ،
ليس من الآمن تشغيل عدة أوامر iptables متزامنة بشكل عام
(تبدو السلاسل المختلفة وكأنها قد تكون على ما يرام). iptables عبارة عن غلاف حوله
libiptc ، وانظر التعليق على iptc_commit:
http://www.tldp.org/HOWTO/Querying-libiptc-HOWTO/mfunction.html

يبدو أنه تم إصلاح هذا في عام 2013 ، ولكن ربما فقط إذا نجحت - انتظر (؟):
http://git.netfilter.org/iptables/commit/؟id=93587a04d0f2511e108bbc4d87a8b9d28a5c5dd8

السبب الجذري لهذا هو أن iptables يستدعي بشكل فعال iptables-save /
- استعادة iptables (على الأقل لكل سلسلة) ؛ لقد رأيت الكثير من التعليمات البرمجية التي
لذلك يستدعي iptables-save & iptables-response بدلاً من فعل الأشياء
من خلال عمليات الإضافة والحذف. قد يكون لدي بعض التعليمات البرمجية للقيام بذلك يمكنني الحفر
إذا كان ذلك مفيدًا.

قم بالرد على هذا البريد الإلكتروني مباشرة أو قم بعرضه على GitHub
https://github.com/GoogleCloudPlatform/kubernetes/issues/3760#issuecomment -76282629
.

ماذا يحدث في حالة الفشل في منتصف إنشاء مجموعة من القواعد؟

سؤال وجيه - ربما ينبغي أن نفكر مليًا حقًا فيما يعنيه ذلك
واجهت خطأ في منتصف هذا

يوم الخميس ، 26 فبراير 2015 الساعة 8:47 مساءً ، Brian Grant [email protected]
كتب:

ماذا يحدث في حالة الفشل في منتصف إنشاء مجموعة من
قواعد؟

قم بالرد على هذا البريد الإلكتروني مباشرة أو قم بعرضه على GitHub
https://github.com/GoogleCloudPlatform/kubernetes/issues/3760#issuecomment -76331174
.

thockin من irc اليوم:

يسمح net.ipv4.conf.all.route_localnet بأن يكون 127.0.0.1 هدفًا لقواعد DNAT . من المستندات :

route_localnet - قيمة منطقية

لا تعتبر عناوين الاسترجاع مصدرًا أو وجهة مريخية
أثناء التوجيه. يتيح ذلك استخدام 127/8 لأغراض التوجيه المحلي.
الافتراضي FALSE

هل يمكننا دمج هذا في kubelet ، أو الاحتفاظ به في برنامج خفي منفصل؟ يراقب Kubelet بالفعل الخدمات من أجل ملء Vars.

أود الاحتفاظ به كثنائي منفصل. هناك أسباب لماذا أنت
قد ترغب في تشغيل هذا على أجهزة أخرى (مثل الحيوانات الأليفة VMs) خارج k8s
الكتلة من أجل الوصول إلى خدمات k8s.

- بريندان

يوم الجمعة ، 13 آذار (مارس) 2015 الساعة 11:37 صباحًا ، Brian Grant [email protected]
كتب:

هل يمكننا دمج هذا في kubelet ، أو الاحتفاظ به في برنامج خفي منفصل؟
يراقب Kubelet بالفعل الخدمات من أجل ملء Vars.

-
قم بالرد على هذا البريد الإلكتروني مباشرة أو قم بعرضه على GitHub
https://github.com/GoogleCloudPlatform/kubernetes/issues/3760#issuecomment -79230747
.

يمسك. فيما يتعلق بما يحدث في حالة الإخفاقات (التي سيكون هناك الكثير منها ، صدقني) ، أنا من أشد المعجبين بالنهج المضاد للإنتروبيا - تخزين الحالة المرغوبة في مكان ما ، والتوفيق بشكل دوري بين الحالة المرغوبة والفعلية (عن طريق تغيير الحالة الفعلية ). في هذه الحالة ، ربما تكون بسيطة مثل:

احيانا صحيح) {
realState = iptablesSave ()
إذا كانت القيمة الفعلية! = الحالة المرغوبة {iptablesRestore (الحالة المرغوبة))
sleep_a_ في الوقت نفسه ()
}

توافق بنسبة 100٪ على أن هذه هي الطريقة الصحيحة للتعامل مع الفشل في كتابة iptables
قواعد.

يوم الجمعة ، 13 آذار (مارس) 2015 الساعة 1:16 مساءً ، Quinton Hoole [email protected]
كتب:

يمسك. فيما يتعلق بما يحدث في حالة الفشل (منها
سيكون هناك الكثير ، صدقني) ، أنا من أشد المعجبين بمقاربة مكافحة الانتروبيا

• تخزين الحالة المطلوبة في مكان ما ، والتوفيق بشكل دوري بين المطلوب و
  الحالة الفعلية (بتغيير الحالة الفعلية). في هذه الحالة ، ربما تكون بسيطة مثل:

احيانا صحيح) {
realState = iptablesSave ()
إذا كانت القيمة الفعلية! = الحالة المرغوبة {iptablesRestore (الحالة المرغوبة))
sleep_a_ في الوقت نفسه ()
}

-
قم بالرد على هذا البريد الإلكتروني مباشرة أو قم بعرضه على GitHub
https://github.com/GoogleCloudPlatform/kubernetes/issues/3760#issuecomment -79336296
.

هذا أكثر أو أقل ما يحدث الآن ، أليس كذلك؟ لكل قاعدة متوقعة ،
تحقق مما إذا كان موجودًا وإذا لم يكن كذلك ، فافعله.

يوم الجمعة ، 13 آذار (مارس) 2015 الساعة 2:02 مساءً ، Brendan Burns [email protected]
كتب:

توافق بنسبة 100٪ على أن هذه هي الطريقة الصحيحة للتعامل مع الفشل في كتابة iptables
قواعد.

يوم الجمعة ، 13 آذار (مارس) 2015 الساعة 1:16 مساءً ، Quinton Hoole [email protected]
كتب:

يمسك. فيما يتعلق بما يحدث في حالة الفشل (منها
سيكون هناك الكثير ، صدقني) ، أنا من أشد المعجبين بمكافحة الانتروبيا
مقاربة

• تخزين الحالة المطلوبة في مكان ما ، والتوفيق بشكل دوري بين المطلوب و
  الحالة الفعلية (بتغيير الحالة الفعلية). في هذه الحالة ، ربما بهذه البساطة
  كما:

احيانا صحيح) {
realState = iptablesSave ()
إذا كانت القيمة الفعلية! = الحالة المرغوبة {iptablesRestore (الحالة المرغوبة))
sleep_a_ في الوقت نفسه ()
}

-
قم بالرد على هذا البريد الإلكتروني مباشرة أو قم بعرضه على GitHub
<
https://github.com/GoogleCloudPlatform/kubernetes/issues/3760#issuecomment -79336296

.

-
قم بالرد على هذا البريد الإلكتروني مباشرة أو قم بعرضه على GitHub
https://github.com/GoogleCloudPlatform/kubernetes/issues/3760#issuecomment -79392626
.

أوافق على وجود فائدة في ثنائي منفصل ، لكن ربما نقوم بربطها به
kubelet (بنفس الطريقة التي يسير بها cAdvisor) وجعلها قائمة بذاتها في
نفس الوقت.

يوم الجمعة ، 13 آذار (مارس) 2015 الساعة 12:03 مساءً ، Brendan Burns [email protected]
كتب:

أود الاحتفاظ به كثنائي منفصل. هناك أسباب لماذا أنت
قد ترغب في تشغيل هذا على أجهزة أخرى (مثل الحيوانات الأليفة VMs) خارج k8s
الكتلة من أجل الوصول إلى خدمات k8s.

- بريندان

يوم الجمعة ، 13 آذار (مارس) 2015 الساعة 11:37 صباحًا ، Brian Grant [email protected]
كتب:

هل يمكننا دمج هذا في kubelet ، أو الاحتفاظ به في برنامج خفي منفصل؟
يراقب Kubelet بالفعل الخدمات من أجل ملء Vars.

-
قم بالرد على هذا البريد الإلكتروني مباشرة أو قم بعرضه على GitHub
<
https://github.com/GoogleCloudPlatform/kubernetes/issues/3760#issuecomment -79230747

.

-
قم بالرد على هذا البريد الإلكتروني مباشرة أو قم بعرضه على GitHub
https://github.com/GoogleCloudPlatform/kubernetes/issues/3760#issuecomment -79257059
.

سأكون فضوليًا لسماع ما يقوله أهل Kubernetes-Mesos حول ما إذا كان يجب أن تكون مكونات العقدة أكثر تكاملاً أو معيارية. jdef؟

[[محرر]] أنا حقًا أحب نمطية مكونات k8s ، على سبيل المثال تشغيل عملية بروكسي منفصلة عن عملية kubelet. إذا فشل الوكيل لأي سبب من الأسباب ، فإنه لا يقوم بإزالة kubelet. هذا رائع جدًا نظرًا لأن منفذي Mesos ليس لديهم نموذج تجاوز فشل رشيق جدًا في الوقت الحالي - ومنفذ إطار عمل kubernetes-mesos عبارة عن هجين kubelet / منفذ. يتيح لي هذا النموذج أيضًا تشغيل خدمة وكيل على خادم mesos الرئيسي واستخدامه كموازن دائري للعملاء الخارجيين (كما في دليل البدء الذي قدمناه).

فيما يتعلق بثنائيات التعبئة / الشحن ، أعتقد أنه من المفيد جدًا تجميع الوظائف معًا ، كما هو الحال في hyperkube. لقد فكرت أيضًا في كيفية تجميع مكونات إطار عمل kubernetes-mesos في حاويات Docker قليلة . تحتوي Iptables على تبعيات خارجية للمكتبة وهذا يعقد الأمور. لذلك قد يكون الحل الوسط الجيد هو إرسال إطار عمل k8sm باعتباره Docker يحتوي على صورة hyperkube مفردة - ولكن عندما يتم تنفيذ هذا الإطار ويبدأ في توزيع منفذي kubelet عبر المجموعة ، فإنه يشحن بشكل أساسي صورة hyperkube يمكن أن تتحول إلى kubelet- المنفذ أو الوكيل - ويمكن تشغيل كل عملية مباشرة على المضيف. يؤدي هذا بشكل أساسي إلى تشغيل نهائي حول iptables- {binaries، libraries} - في مشكلة التبعية في Docker.

+1 للوظائف المعيارية ، +1 للصورة الثنائية المفردة

thockin إعادة: مكافحة الانتروبيا: آه نعم. أرى proxier.SyncLoop () يفعل ذلك. في هذه الحالة ، ليست الإجابة على سؤال @ bgrant0607 في 26 فبراير بأنه يمكن تجاهل الأخطاء وسيتم إصلاحها في التكرار التالي لـ SyncLoop () (حاليًا دقيقة واحدة)؟ أو ربما أفتقد شيئًا ما؟

thockin

1. هل نحن قلقون بشأن حركة مرور شبكة الثقب الأسود أم أنه شيء يحتاج مؤلف الخدمة / البود إلى الاهتمام به؟

مع وكيل مساحة المستخدمين
افترض أن IP الظاهري 10.0.0.11 يحتوي على 3 نقاط نهاية على سبيل المثال ، 10.240.1.1 ، 10.240.1.2 ، 10.240.1.3
باستخدام وكيل مساحة المستخدم ، إذا ذكرت إحدى نقاط النهاية أن 10.240.1.1 لم تعمل ، فسوف يدرك الوكيل أن اتصال tcp لم يتم تأسيسه باستخدام 10.240.1.1 ، ويمكن أن يتراجع إلى إحدى نقطتي النهاية الأخريين.

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

أو ربما القلق بشأن نقاط النهاية غير المستجيبة ليس من مسؤولية نظام kubernetes وهل مسؤولية مؤلف الكبسولة؟

يمكن للمستخدم إعداد تحقيقات الاستعداد ، والتي يتم تنفيذها بواسطة Kubelet. سيؤدي فشل التحقيق إلى إزالة نقطة النهاية من قائمة نقاط النهاية بواسطة وحدة التحكم في نقاط النهاية. يجب على وكيل الخدمة بعد ذلك إزالة نقطة النهاية من المجموعة المستهدفة.

لقد كنت أبحث في هذا من أجل GSoC ، وأنا أتساءل:

من الناحية المثالية ، اكتشفنا أن iptables جديد بما يكفي لاستخدامه والاستمرار في استخدامه بخلاف ذلك؟

من https://github.com/GoogleCloudPlatform/kubernetes/issues/5419 يبدو أن هذا سيكون الأسلوب المثالي ؛ مع kubelet يحدد الطقس لاستخدام جداول IP أو بدء kube-proxy.

لقد تأخرت قليلاً أيضًا في GSoC (كان في عطلة الربيع ....) ، لذلك أتساءل أيضًا عما إذا كان لا يزال بإمكاني تقديم اقتراح GSoC له غدًا / لاحقًا اليوم (بخلاف الموعد النهائي السابع والعشرين بالطبع ، هو هذا لا يزال مفتوحًا)؟

BenTheElder نعم ، لديك حتى يوم الجمعة لتقديم اقتراح. هناك شخص آخر من المحتمل أن يكون مهتمًا بهذا الموضوع ، لكن لا يوجد اقتراح محدد له حتى الآن.

لست قلقًا بشأن النوى الأقدم من عام 2012 بقدر ما أنا قلق بشأن أنظمة تشغيل لا تحتوي على iptables تمامًا ، على الرغم من أن هذه الأجهزة معطلة بالفعل إلى حد ما.

@ bgrant0607 شكرا!
أعتقد أنه يمكنني تحديد هذه المشكلة بعد ذلك. انها تبدو مثيرة للاهتمام.

سيعمل مسبار الجاهزية جيدًا لبدء تشغيل التطبيق ، لكنني لست متأكدًا من أن الجاهزية مناسبة للتخفيف من فشل التطبيق. عند فشل pod ، يجب أن تمر الإشارة من التطبيق -> kubelet -> apiserver -> endpoints_controller -> apiserver -> kube-proxy. سأكون مهتمًا بفهم زمن الانتقال بين فشل التطبيق وإزالة نقطة النهاية من دوران وكيل kube. خلال هذه الفترة ، سيتم تحويل الطلبات إلى نقطة نهاية غير مستجيبة.

تعد إعادة المحاولة عند فشل الاتصال إستراتيجية شائعة وميزة مفيدة بشكل معقول للعديد من موازنات الأحمال الشائعة (مثل haproxy و AWS ELB) ويتم التعامل معها من خلال التنفيذ الحالي لـ kube-proxy. هل يجب نقل هذه المسؤولية إلى LB الخارجي؟ ماذا عن حركة المرور داخل الكتلة؟

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

مايك يثير نقاط جيدة.

الإثنين، 23 مارس 2015 في تمام الساعة 11:00 مساء، مايك دانيسي [email protected]
كتب:

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

-
قم بالرد على هذا البريد الإلكتروني مباشرة أو قم بعرضه على GitHub
https://github.com/GoogleCloudPlatform/kubernetes/issues/3760#issuecomment -85354865
.

لقد كنت أقرأ من خلال مصدر kube-proxy و proxy pkg ؛ هل iptables غير مستخدم بالفعل في المراجعة الحالية؟

ما الذي يجب القيام به بالضبط على هذا؟ من المصدر الرئيسي الحالي ، يبدو كما لو أن iptables يُستخدم بالفعل على نطاق واسع في الوكيل.

mikedanesethockin الجاهزية هي مفيدة للغاية لانقطاع التيار المخطط لها. سوف تتسبب حالات الانقطاع غير المخطط لها دائمًا في حدوث بعض الأخطاء التي يمكن ملاحظتها. يجب أن يكون الفاصل الزمني للاستقصاء طويلًا بشكل عام بالنسبة لتحديث وقت الاستجابة ، ولكن يمكننا أيضًا وضع قواعد إعادة التوجيه على العقدة الوجهة عبر الاتصال المباشر بين Kubelet و kube-proxy ، إذا كان وقت الاستجابة عبر apiserver و etcd طويلًا جدًا و / أو ذلك المسار غير موثوق به بما فيه الكفاية.

BenTheElder تقوم القواعد الحالية

@ bgrant0607 شكرًا ، هذا منطقي تمامًا الآن. قراءة أخرى من خلال المصدر ووثائق التصميم وقد انتهيت تقريبًا من كتابة مسودة اقتراح.

مسودة مقترح GSoC: https://gist.github.com/BenTheElder/ac61900595a7ea9ea9b5

سأكون ممتنًا بشكل خاص للتعليقات على قسم الجدول الزمني. لست متأكدًا تمامًا من ذلك.
هل يجب أن أنهي مبكرًا وأحب العمل على بعض مشكلات GSoC الأخرى (الأصغر؟) غير المأخوذة مثل:
https://github.com/GoogleCloudPlatform/kubernetes/issues/1651.

شكرًا مرة أخرى ، Kubernetes يأخذ الكعكة لمجموعة ودية.

أريد فقط أن أقول إنني سعيد جدًا بالقول إن اقتراحي قد تم قبوله وأنني سأعمل على هذا خلال الصيف. : مبتسم:

أنا متحمس جدا. لسوء الحظ ، أنا في خضم نهائياتي الآن ، لكن في وقت ما من نهاية هذا الأسبوع ، يجب أن أعمل أكثر من ذلك بكثير وأعمل عليه ، وعلى الأرجح سأبدأ بالحصول على https://github.com/GoogleCloudPlatform/kubernetes/pull/7032 تم الانتهاء من.

thockinbrendanburns يمكن لأي شخص يقيم في في الطقس نريد أن نفعل ذلك بالتوازي مع الوكيل مساحة المستخدم أو كيف تهاجر إلى معاودة تطبيق النظام سيعمل؟

يبدو أننا نفضل بالفعل iptables> = 1.4.11 (تم إصداره في 2011 - 26 مايو).

// Executes the rule check without using the "-C" flag, instead parsing iptables-save.
// Present for compatibility with <1.4.11 versions of iptables.  This is full
// of hack and half-measures.  We should nix this ASAP.
func (runner *runner) checkRuleWithoutCheck(table Table, chain Chain, args ...string) (bool, error) {

المصدر: https://github.com/GoogleCloudPlatform/kubernetes/blob/aec41967416cf3463b188d72c97e71465e00719d/pkg/util/iptables/iptables.go#L206

هل نرى بالفعل مضيفين أقدم من ذلك؟

من الواضح أن أحد الأساليب هو اكتشاف إصدار iptables الذي نقوم بتشغيله في وقت التشغيل ، والقيام بـ "أفضل شيء" يمكننا تقديمه للإصدار ، على سبيل المثال ، شيء مثل:

إذا (الإصدار القديم) {
تحميل وحدة وكيل مساحة المستخدم
}
آخر {
تحميل وحدة iptables
}

أحذر من وجود عدد كبير جدًا من الفروع في عبارة if أعلاه (من الناحية المثالية 2 فقط) ، وتجنب قدر الإمكان وجود هذا النوع من عبارة if في أكثر من مكان واحد في الكود.

لم أقم بمراجعة الكود بالتفصيل لمعرفة مدى جدوى النهج أعلاه.

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

إذا قررت كل عقدة بشكل مستقل ، فمن المحتمل أن نزيد مساحة سطح الاختبار بما يتناسب مع مربع عدد الفروع في عبارة if أعلاه (على سبيل المثال ، source_mode x dest_mode) ، ولكن إذا تمكنا من الاحتفاظ بعدد الأوضاع إلى 2 ، أعتقد أن هذا جيد .

س

أوه ، والإجابة على سؤالك عما إذا كنا نرى العقد القديمة هي "نعم" للأسف.

هناك الكثير من النقاش حول ما ورد أعلاه في قضية منفصلة ، وسأحاول استكشافها من أجلك.

@ كوينتون هوول شكرا!

أنا متأكد أيضًا من أنه يمكننا تشغيل مساحة مستخدم على عقدة و iptables على عقدة أخرى.

يجب أن يكون عدد الأوضاع 2 فقط باستثناء هذا الاختراق عندما لا يكون لدينا -C ولكن العقد التي تحتوي على -C يجب أن تكون قادرة على تشغيل إصدار iptables النقي (على ما أعتقد).

آه نعم ، # 7528 يناقش إصدارات النواة وما شابه.

شكرا.
لم أر ذلك عندما بحثت عن متطلبات kubernetes. كانت المتطلبات الوحيدة التي وجدتها موجودة في مستندات الشبكات التي تناقش كيف نفترض عناوين IP الفريدة.

ربما يجب أن نحصل على بعض الوثائق المكتوبة للمتطلبات بمجرد أن تكون لدينا فكرة أفضل عن ماهيتها.

لقد بدأت القرصنة على هذا هنا: https://github.com/BenTheElder/kubernetes/tree/iptables_proxy

على وجه التحديد ، لقد نقلت تنفيذ مساحة المستخدم خلف واجهة هنا:
https://github.com/BenTheElder/kubernetes/commit/4e5d24bb74aca43b0dd37cf5cfee8a34f8eff2bf

لست متأكدًا الآن على الرغم من أن اختيار التنفيذ يجب أن يكون في cmd / kube-proxy أو في pkg / proxy ، لذا يمكنني إزالة هذا واختيار التنفيذ بواسطة kube-proxy بدلاً من ذلك.

تعديل: أعتقد عند الرجوع إلى الماضي أنه ربما يكون من المنطقي تحديد التنفيذ من وكيل kube.

BenTheElder لقد اختبرت قواعد تيم مع كاليكو وهي تعمل بشكل جيد. نقوم بكل عملنا في جدول التصفية ، لذا فإن قواعد DNAT هنا قد حددت src IP المناسبة بحلول تلك النقطة.

بشكل عام ، سيكون من الجيد إجراء مناقشة لتحديد كيفية قيام المكونات الإضافية للشبكة بتغيير iptables بأمان إذا كان Kubernetes سيقوم أيضًا بإدراج القواعد هناك. لا تريد أن تدوس (أو أن تدوس عليك) قواعد Kubernetes إذا تغيرت في الطريق.

@ متماثل نعم. لست متأكدًا من جزء المكونات الإضافية بعد على الإطلاق ، لكن هذا يبدو مهمًا جدًا.

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

هل لديك أي فكرة عما تريد أن يبدو عليه هذا / كيف يجب أن يعمل؟

FWIW ، لقد فعلت شيئًا يناسبنا لأن وكيل kube أصبح غير مستجيب تقريبًا. إنه هنا: https://github.com/MikaelCluseau/kubernetes-iptables-proxy/blob/master/iptables-routing.rb.

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

أود أيضًا أن أشارك أننا وصلنا إلى nf_conntrack_max بسرعة. ربما ينبغي زيادته.

# cat /etc/sysctl.d/nf_conntrack.conf 
net.netfilter.nf_conntrack_max = 1000000
net.nf_conntrack_max           = 1000000

ربما لم أفهم كل الحاجة إلى iptables ، لكن لماذا لا تستخدم IPVS بدلاً من ذلك؟
يبدو أنه أكثر ملاءمة للوكيل من iptables ...
إليك طريقة تنفيذ بسيطة: https://github.com/noxiouz/go-ipvs
وفقط لإكمال # 561 ، هناك أيضًا مشروع ktcpvs .

يبدو أن IPVS هو أيضًا تجريد على netfilter (مثل iptables). نحن قادرون على مشاركة بعض الوظائف مع الكود الحالي باستخدام iptables ؛ يبدو أن و iptables هو الحل الأكثر مرونة / العام لإدارة netfilter.

بالنسبة إلى # 561 و ktcpvs: لا يبدو أن ktcpvs قد حدث أي تطوير منذ عام 2004 ولا يبدو أنه يحتوي على ميزات يريدها المستخدمون مثل إعادة كتابة عنوان URL. بغض النظر عن # 561 ، يبحث عن حل عام يمكن استخدامه مع أجهزة البلاناس القابلة للتوصيل.

ملاحظة جانبية: لا يبدو أن مشروع go that لديه ترخيص.

سيتم إهمال iptables "يوم واحد" لصالح nftables ( nft cli).
أيضًا استخدام iptables CLI لإنشاء قواعد لا يبدو أنه قوي تمامًا ...

ابحث سريعًا عن مشروع MIT الآخر هذا: https://github.com/vieux/go-libipvs
ولكن يبدو أنه من السهل جدًا إنشاء عمل بسيط حيث أن كل التعقيدات محصنة بالفعل داخل كود النواة.

أشك في أن iptables ستتم إزالته من أي توزيعات رئيسية في أي وقت قريب ، وأن iptables CLI مخصصًا لإنشاء وإدارة قواعد netfilter ...؟

غلاف cgo غير مكتمل مثل ذلك المرتبط يبدو أقل أمانًا بكثير من الدفع إلى iptables و iptables-restore ونحن بالفعل بحاجة إلى iptables لقواعد أخرى (مثل nodeports) ومع iptables-restore يمكننا إجراء تحديثات مجمعة ببعض الذرات.

يبدو أنه تم تصميم IPVS أيضًا لاستخدامه على جهاز مضيف موازنة التحميل بشكل منفصل عن الخوادم "الحقيقية".
هذا يشير إلى أن أن يكون استخدام معتمد فقط:

2.2. مسكتك: أنت بحاجة إلى عميل خارجي (لا يمكن للمخرج والخوادم الحقيقية الوصول إلى الخدمة الافتراضية)

لإعداد واختبار / تشغيل LVS ، تحتاج إلى ما لا يقل عن 3 أجهزة: عميل ، مدير ، خادم (خوادم) حقيقي.

من الخارج ، يعمل LVS كآلة واحدة. لا يمكن للعميل أن يكون أحد الأجهزة الموجودة في LVS (المدير أو الخادم الحقيقي). أنت بحاجة إلى عميل خارجي. إذا حاولت الوصول إلى خدمة LVS التي يتم التحكم فيها (مثل http ، و smtp ، و telnet) من أي من الأجهزة الموجودة في LVS ؛ سيتم تعليق الوصول من المدير ، وسيتصل الوصول من خادم حقيقي بالخدمة محليًا ، متجاوزًا LVS.

يبدو أيضًا أن IPVS / LVS يضيف بعض المتطلبات الإضافية مثل برنامج خفي لنبض القلب وعمليات مراقبة إضافية. نحن نتعامل بالفعل مع معلومات نقطة النهاية ومراقبة صحة البودات وما إلى ذلك من داخل kubernetes.

+1 لمقاربة iptables. نحن نستخدم iptables على نطاق واسع في Calico وقد أثبتوا قوتهم وأداءهم وقياسهم جيدًا (بافتراض أنك تصمم قواعدك جيدًا). BenTheElder ، إذا كنت بحاجة إلى أي مساعدة في أي شيء من عمل iptables ، فيرجى إخبارنا بذلك ، لأننا سنكون سعداء بالمشاركة.

+1 بالنسبة لـ iptables و iptables-Restore ، فهو أسلوب أقل تعقيدًا
من IPVS / LVS ويفرض متطلبات نظام أقل (عفريت ضربات القلب ،
إلخ.)

يوم السبت ، 13 يونيو 2015 الساعة 11:27 صباحًا ، Alex Pollitt [email protected]
كتب:

+1 لمقاربة iptables. نحن نستخدم iptables على نطاق واسع في Calico و
لقد أثبتوا قوتهم وأداءهم وقياسهم جيدًا (بافتراض أنك
صمم قواعدك جيدًا). BenTheElder https://github.com/BenTheElder ،
إذا احتجت إلى أي مساعدة في عمل أي شيء من iptables ، فيرجى ترك
نعلم ، لأننا سنكون سعداء بالمشاركة.

-
قم بالرد على هذا البريد الإلكتروني مباشرة أو قم بعرضه على GitHub
https://github.com/GoogleCloudPlatform/kubernetes/issues/3760#issuecomment -111719474
.

شكرًا أليكس ، سأخبرك إذا فعلت ذلك.

يمكنني استخدام بعض التعليقات / المدخلات حول التنفيذ الحالي (https://github.com/GoogleCloudPlatform/kubernetes/pull/9210) إذا كان لدى أي شخص الوقت.

إنها مكتملة في الغالب ومحدثة حاليًا مع رئيس المنبع ، أحتاج إلى إنهاء كتابة الكود الذي يقارن القواعد المُنشأة بـ iptables-save ويستعيد العدادات وما إلى ذلك ، ولكن يتم إنشاء القواعد والعمل (في الغالب) ، إلى حد كبير باتباع القواعد الموضحة في OP هنا مع التغيير الأكبر فقط هو أسماء السلسلة ، والتي كانت ضرورية للإنشاء التلقائي للأسماء التي سيقبلها iptables.

تم الإبلاغ عن حالة حافة هنا: https://github.com/BenTheElder/kubernetes/issues/3 والتي قد تتطلب تغييرًا للتعامل مع البودات المتصلة ببعضها البعض.

لقد تلقيت بعض التعليقات والمناقشات الممتازة مع MikaelCluseau و Symmetric على وجه الخصوص حول إجراء بعض إعادة التصميم للتعامل مع هذا الأمر وأشياء أخرى (شكرًا مرة أخرى!) ؛ ولكن يمكننا استخدام بعض المدخلات الإضافية في تصميم القواعد على وجه الخصوص. إذا كان لدى أي شخص آخر الوقت لإلقاء نظرة ، فسيكون ذلك موضع تقدير كبير لأنني لست متأكدًا من أفضل طريق يسلكه وأريد تجنب إجراء أي تغييرات كبيرة دون مزيد من المدخلات.

العلاقات العامة نفسها كبيرة جدًا ولكن إنشاء القواعد ذات الصلة كله pkg/proxy/proxieriptables.go syncProxyRules() على: https://github.com/BenTheElder/kubernetes/blob/iptables_proxy/pkg/proxy/proxieriptables. اذهب # L286

يمكن رؤية المناقشة الحالية (هنا بالطبع) وكذلك في تعليقات العلاقات العامة وعلى https://github.com/BenTheElder/kubernetes/issues/3 وكذلك أكثر قليلاً على https://github.com/ BenTheElder / kubernetes / قضايا / 4.

هناك مشكلة أخرى تحتاج إلى مدخلات:

في الكود الحالي ، لا يزال kube-proxy مضمنًا ، للتعامل مع حالة nodePort فقط. أعتقد أنه يمكننا التخلص من kube-proxy في هذه الحالة أيضًا ، وقد اقترحنا بعض قواعد iptables البسيطة لفعل ذلك في العلاقات العامة لـ Ben .

لكن هذه القواعد لا تزال تحجب مصدر IP لأي LB خارجي ، لذا فهي ليست مثالية. تكمن المشكلة في أنه إذا قمنا فقط بحركة مرور DNAT من LB عند وصولها إلى عقدة ، فقد تأتي حزمة الاستجابة من عقدة مختلفة ، ولذا لا أعتقد أن LB سيكون قادرًا على ربط الاستجابة بجلسة TCP الأصلية . فهل هذا القلق صحيح؟ سيكون التنفيذ أبسط إذا لم يكن لدينا ما يدعو للقلق بشأن هذا.

أظن أن هناك بعض السحر الذي يمكننا القيام به لإبقاء وكلاء HTTP سعداء ، لكنني لا أرى طريقة لجعل هذا العام في L4.

أنا أعطي تجربة للسحر الأسود من العلاقات العامة الخاصة بك ، لكنها لا تولد أي شيء بالنسبة لي ، يبدو أن القواعد بدأت في الظهور بمكالمات إلى iptables ثم يتم إنشاء ملف iptables-restore.

يوجد خطأ في جزء الرأس في الملف المُنتَج ، عادةً الأجزاء التي تم ملؤها باستدعاء iptables ، هناك الجزء ذي الصلة من السجل:

I0807 11: 41: 24.560063 8369 iptables.go: 327] تشغيل iptables -N [KUBE-PORTALS-CONTAINER -t nat]
I0807 11: 41: 24.562361 8369 iptables.go: 327] تشغيل iptables -C [PREROUTING -t nat -m comment --comment handle ClusterIPs؛ ملاحظة: يجب أن يكون هذا قبل قواعد NodePort -j KUBE-PORTALS-CONTAINER]
I0807 11: 41: 24.563469 8369 iptables.go: 327] تشغيل iptables -N [KUBE-PORTALS-HOST -t nat]
I0807 11: 41: 24.565452 8369 iptables.go: 327] تشغيل iptables -C [OUTPUT -t nat -m comment --comment handle ClusterIPs؛ ملاحظة: يجب أن يكون هذا قبل قواعد NodePort -j KUBE-PORTALS-HOST]
I0807 11: 41: 24.566552 8369 iptables.go: 327] تشغيل iptables -N [KUBE-NODEPORT-CONTAINER -t nat]
I0807 11: 41: 24.568363 8369 iptables.go: 327] تشغيل iptables -C [PREROUTING -t nat -m addrtype - dst-type LOCAL -m comment - خدمة معالجة التعليقات NodePorts؛ ملاحظة: يجب أن تكون هذه هي القاعدة الأخيرة في السلسلة -j KUBE-NODEPORT-CONTAINER]
I0807 11: 41: 24.569564 8369 iptables.go: 327] تشغيل iptables -N [KUBE-NODEPORT-HOST -t nat]
I0807 11: 41: 24.571458 8369 iptables.go: 327] تشغيل iptables -C [OUTPUT -t nat -m addrtype - dst-type LOCAL -m comment - خدمة معالجة التعليقات NodePorts؛ ملاحظة: يجب أن تكون هذه هي القاعدة الأخيرة في السلسلة -j KUBE-NODEPORT-HOST]
I0807 11: 41: 24.573392 8369 iptables.go: 327] تشغيل iptables -C [POSTROUTING -t nat -m comment - جراب مقبض التعليق يتصل بـ self -s 10.240.240.78/32 -d 10.240.240.78/32 -j MASQUERADE ]
I0807 11: 41: 24.574447 8369 proxier.go: 349] مزامنة قواعد iptables.
I0807 11: 41: 24.575592 8369 proxier.go: 399] السلسلة: PREROUTING ، القاعدة:: PREROUTING ACCEPT [0: 0]
I0807 11: 41: 24.575615 8369 proxier.go: 401] القاعدة: -A PREROUTING -m تعليق - التعليق "handle ClusterIPs ؛ ملاحظة: يجب أن يكون هذا قبل قواعد NodePort" -j KUBE-PORTALS-CONTAINER
I0807 11: 41: 24.575625 8369 proxier.go: 401] القاعدة: -A prEROUTING -m addrtype - dst-type LOCAL -m comment --comment "handle service NodePorts ؛ ملاحظة: يجب أن تكون هذه هي القاعدة الأخيرة في السلسلة" -j KUBE-NODEPORT-CONTAINER
I0807 11: 41: 24.575633 8369 proxier.go: 399] السلسلة: INPUT ، القاعدة:: INPUT ACCEPT [0: 0]
I0807 11: 41: 24.575646 8369 proxier.go: 399] السلسلة: الإخراج ، القاعدة:: قبول الإخراج [0: 0]
I0807 11: 41: 24.575658 8369 proxier.go: 401] القاعدة: -A OUTPUT -m تعليق - التعليق "handle ClusterIPs ؛ ملاحظة: يجب أن يكون هذا قبل قواعد NodePort" -j KUBE-PORTALS-HOST
I0807 11: 41: 24.575670 8369 proxier.go: 401] القاعدة: -A OUTPUT -m addrtype - dst-type LOCAL -m comment --comment "handle service NodePorts ؛ ملاحظة: يجب أن تكون هذه هي القاعدة الأخيرة في السلسلة" -j KUBE-NODEPORT-HOST
I0807 11: 41: 24.575683 8369 proxier.go: 399] السلسلة: POSTROUTING ، القاعدة:: POSTROUTING ACCEPT [0: 0]
I0807 11: 41: 24.575691 8369 proxier.go: 401] القاعدة: -A POSTROUTING! -d 10.0.0.0/8 -o eth0 -j MASQUERADE
I0807 11: 41: 24.575699 8369 proxier.go: 401] القاعدة: -A POSTROUTING -s 10.240.240.78/32 -d 10.240.240.78/32 -m تعليق - التعليق "مقبض جراب متصل بالنفس" -j MASQUERADE
I0807 11: 41: 24.575709 8369 proxier.go: 399] السلسلة: KUBE-NODEPORT-CONTAINER ، القاعدة: KUBE-NODEPORT-CONTAINER - [0: 0]
I0807 11: 41: 24.575720 8369 proxier.go: 399] السلسلة: KUBE-NODEPORT-HOST ، القاعدة:: KUBE-NODEPORT-HOST - [0: 0]
I0807 11: 41: 24.575729 8369 proxier.go: 399] السلسلة: KUBE-PORTALS-CONTAINER ، القاعدة:: KUBE-PORTALS-CONTAINER - [0: 0]
I0807 11: 41: 24.575740 8369 proxier.go: 399] السلسلة: KUBE-PORTALS-HOST ، القاعدة:: KUBE-PORTALS-HOST - [0: 0]
I0807 11: 41: 24.581897 8369 proxier.go: 603] قاعدة المزامنة: KUBE-PORTALS-HOST - [0: 0]
: KUBE-PORTALS-CONTAINER - [0: 0]
: KUBE-NODEPORT-HOST - [0: 0]
: KUBE-NODEPORT-CONTAINER - [0: 0]
: KUBE-SVC-VO8JL93ZeRSf8cnsLpl - [0: 0]
: KUBE-SVC-L26cB3JYuxdW5TF84ct - [0: 0]
: KUBE-SVC-j2SF8q3nUajS8vOx2qL - [0: 0]
: KUBE-SVC-shln2urO8W1aBiB2bWJ - [0: 0]
: KUBE-SVC-8jQ3IvijvhJ4ppFj3Ui - [0: 0]
[... SNIP ...]

يمكن استيراد دمج iptable-save مع النتيجة الناتجة في الوضع المطول والقيام بأشياء جيدة.

bnprss شكرًا للتقرير ، كان هناك مؤخرًا عدد من التغييرات غير المختبرة بما في ذلك استخدام ملف مؤقت واستخدام علامة "-T table" لـ iptables-restore أثناء بعض عمليات إعادة الكتابة لعملية المراجعة. سوف أضع إصلاحًا بمجرد معرفة سبب الانحدار (الانحدارات).

bnprss كما قلت ، رأس الجدول مفقود (يجب أن يكون "* nat" السطر الأول) ، تمت إزالته عن طريق الخطأ وبعد إعادة ذلك إلى كل شيء يبدو أنه يعمل بشكل جيد مرة أخرى مع عدم وجود أخطاء أخرى على ما يبدو (باستثناء: https: / /github.com/BenTheElder/kubernetes/issues/3). شكرا مرة أخرى ، آسف لذلك. لقد دفعت الإصلاح.

عمل جيد ، يتم تحميل القواعد ويبدو أنها تعمل من الداخل ولكن لا حظ مع موازن التحميل الخارجي لا يوجد اتصال من الخارج يعطي إجابة.

هاه. هل يمكنك الانتقال إلى العلاقات العامة وتقديم المزيد من التفاصيل؟ بعيد جدا
لقد كانت تعمل بشكل جيد ولكني لا أنشر نفسي خارج نطاق الاختبارات المحلية وأنا
لا تعتقد أن أيًا من المختبرين الآخرين كان يستخدم موازن تحميل خارجي.
في 7 آب (أغسطس) 2015 ، الساعة 1:29 مساءً ، كتب "bnprss" [email protected] :

عمل رائع ، يتم تحميل القواعد ويبدو أنها تعمل من الداخل ولكن لا حظ
مع وجود موازن خارجي لا يوجد اتصال من الخارج يجيب.

-
قم بالرد على هذا البريد الإلكتروني مباشرة أو قم بعرضه على GitHub
https://github.com/GoogleCloudPlatform/kubernetes/issues/3760#issuecomment -128772763
.

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

هل يمكنك حساب رمز القواعد بدون فواصل "-_"؟

bnprss ، عظيم.
سلاسل القواعد المُنشأة للخدمات عبارة عن تجزئة لمنفذ / نقطة نهاية الخدمة ، ثم عنوان url الخاص بـ base64 مشفر ومقطع. KUBE-SVC-. الكود موجود هنا: https://github.com/GoogleCloudPlatform/kubernetes/pull/9210/files#diff -d51765b83fe795b469e8a86276b12dc9R321
اخترنا هذا كطريقة لإنشاء أسماء سلاسل صالحة تلبي حد الأحرف في iptables بينما لا تزال حتمية.
لذلك يجب أن يكون من الممكن التكرار خارجيًا.
إذا كنت تقصد ، هل يمكننا التوقف عن استخدام الفواصل ، فربما يمكننا ولكن "_" تأتي من بعض التجزئة المشفرة و "-" كلها تتبع الأنماط الموجودة في أسماء القواعد من وكيل مساحة المستخدمين الحالي.
ربما يمكننا استخدام شيء آخر دون الكثير من المتاعب إذا كان ذلك ضروريًا.

أنا موافق على ذلك ، وهذا حقًا تجميلي! :)
لكن هذا يختلف عن الأشياء التي رأيتها من قبل:
قواعد gce lb: a07f76b3b2ec311e59e2642010af0479
قواعد gce fw: k8s-fw-a7ecad94f3ba511e59e2642010af0479
قواعد توجيه gce: المسار الافتراضي 6973e029b504a0e8
توجيه gce إلى العقدة: obfuscated_cluster_node-43506797-2eb2-11e5-9e26-42010af04793

هذا جميل:
KUBE-SVC-6ADi2TVfn7mFPvBjC56
هؤلاء هم مضحك:
KUBE-SVC-zU6ParcQ-UfW_LdRDUc
KUBE-SVC-y - z1xTUpHPT6sgAUCC

نعم ، أنا لست معجبًا بهم أيضًا ، ربما يمكننا تغيير التجزئة
التشفير.

في الجمعة ، 7 آب (أغسطس) 2015 الساعة 2:16 مساءً ، كتب bnprss [email protected] :

أنا موافق على ذلك ، وهذا حقًا تجميلي! :)
لكن هذا يختلف عن الأشياء التي رأيتها من قبل:
قواعد gce lb: a07f76b3b2ec311e59e2642010af0479
قواعد gce fw: k8s-fw-a7ecad94f3ba511e59e2642010af0479
قواعد توجيه gce: المسار الافتراضي 6973e029b504a0e8
توجيه gce إلى العقدة:
obfuscated_cluster_node-43506797-2eb2-11e5-9e26-42010af04793

هذا جميل:
KUBE-SVC-6ADi2TVfn7mFPvBjC56
هؤلاء هم مضحك:
KUBE-SVC-zU6ParcQ-UfW_LdRDUc
KUBE-SVC-y - z1xTUpHPT6sgAUCC

-
قم بالرد على هذا البريد الإلكتروني مباشرة أو قم بعرضه على GitHub
https://github.com/GoogleCloudPlatform/kubernetes/issues/3760#issuecomment -128785914
.

نعم ، يمكن استخدام الجزء المقتطع من SHA فقط ، git لا بأس بذلك ، عامل الإرساء أيضًا ، ويبدو أنه الطريقة التي تتم بها الإشارة الأخرى إلى كيانات kube. في حالة الاصطدام في قاعدة التجزئة التي تم إنشاؤها لن يساعد. ؛)
أعتقد أن thockin يمكنه تقديم المشورة بشأن هذه النقطة.

كنت مهتمًا أكثر بالأحرف الصالحة في iptables ، والتي واجهت صعوبة في العثور على مرجع جيد لها. سأبحث في هذا الأمر بعد قليل.

في الجمعة ، 7 آب (أغسطس) 2015 الساعة 2:29 مساءً ، كتب bnprss [email protected] :

نعم ، يمكن فقط استخدام الجزء المقتطع من SHA ، git موافق عليه
هذا ، عامل إرساء أيضًا ، ويبدو أنه الطريقة الأخرى للإشارة إلى kube
الكيانات مصنوعة. في حالة الاصطدام في قاعدة التجزئة التي تم إنشاؤها لن تفعل ذلك
يساعد. ؛)
أعتقد أن thockin https://github.com/thockin يمكنه تقديم المشورة بشأن هذه النقطة.

-
قم بالرد على هذا البريد الإلكتروني مباشرة أو قم بعرضه على GitHub
https://github.com/GoogleCloudPlatform/kubernetes/issues/3760#issuecomment -128788454
.

bnprss fyi ، العلاقات العامة غير مستقرة إلى حد كبير ويتم إعادة بنائها ، لكل ثوكين ، نحن نقطع NodePort وما إلى ذلك في الوقت الحالي ونركز على الحصول على نسخة أبسط وأنظف مع دعم للبوابات ، ثم نعمل على النسخ الاحتياطي إلى التكافؤ الكامل.

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

بالنسبة لأولئك منكم الذين يلعبون على أرضهم ، أنا واثق من أننا قادرون على تحقيق أقصى استفادة
التكافؤ ، ولكن سيكون من الأسهل كثيرًا مراجعته على مراحل :)

الجمعة، 7 أغسطس 2015 في 09:35، بنيامين المسنين [email protected]
كتب:

إجابتي على التعليق أعلاه ، سيتم سحقها أيضًا قريبًا:

تمت مناقشته في IRC:

• سيظل بحاجة إلى التعامل مع العدادات ، لكنك تريد الاستمرار في تحليل
  الحالة في حزمة الاستخدام / iptables.
• لا تزال بحاجة إلى تجزئة أو ما شابه للتعامل مع حدود طول السلسلة

خلاف ذلك يبدو وكأنه تبسيط نظيف للغاية ، سيتم تنفيذه بعد
بعض المزيد من المناقشة.

-
قم بالرد على هذا البريد الإلكتروني مباشرة أو قم بعرضه على GitHub
https://github.com/GoogleCloudPlatform/kubernetes/issues/3760#issuecomment -128912169
.

الحالة: يتم التحقق من المنطق "الرئيسي" وبوابة العلم.

أنا أعمل على منافذ العقدة الآن. هناك الكثير من الحالات الغريبة التي تحتاج إلى معالجة خاصة. ملاحظاتي حتى الآن:

# Basic node ports:
iptables -t nat -N KUBE-NODEPORTS
iptables -t nat -A PREROUTING -j KUBE-NODEPORTS
iptables -t nat -A OUTPUT -j KUBE-NODEPORTS
iptables -t nat -A KUBE-NODEPORTS -p tcp -m comment --comment "TEST: default/nodeport:p" -m tcp --dport 30241 -j KUBE-SVC-EQKU6GMUKRXBR6NWW53

# To get traffic from node to localhost:nodeport to the service:
echo 1 > /proc/sys/net/ipv4/conf/all/route_localnet
# Mark packets that are destined for services from localhost, then masquerade those
iptables -t nat -I KUBE-SVC-EQKU6GMUKRXBR6NWW53 -s 127.0.0.0/16 -j MARK --set-mark 0x4b000001;
iptables -t nat -A POSTROUTING -m mark --mark 0x4b000001 -j MASQUERADE

# To get traffic from a pod to itself via a service:
for intf in $(ip link list | grep veth | cut -f2 -d:); do brctl hairpin cbr0 $intf on; done
# Mark packets that are destined for each endpoint from the same endpoint, then masquerade those.
# This is hacky, but I don't really know which pods are "local" and I don't really want to right now. (but I will eventually)
iptables -t nat -I KUBE-SEP-HHNEQBOLY57T5MQCFIY -s 10.244.1.6 -j MARK --set-mark 0x4b000001

تم العمل على أداة مساهمة للاختبار.
حتى الآن أفكر في تشغيل خادم على عقدة ، وقت الاستجابة للوقت
الطلبات إليه ، اطلع على تحميل مورد kube-proxy وتفريغ ملف
البيانات إلى CSV للرسم البياني وما إلى ذلك.
نأمل أن يتم ذلك قبل يوم الجمعة ، والتعرف أكثر على kubectl الآن.

يوم الأربعاء ، 12 آب (أغسطس) 2015 الساعة 8:48 مساءً ، Tim Hockin [email protected]
كتب:

الحالة: يتم التحقق من المنطق "الرئيسي" وبوابة العلم.

أنا أعمل على منافذ العقدة الآن. هناك الكثير من الحالات الغريبة التي تحتاج إليها
تعامل خاص. ملاحظاتي حتى الآن:

منافذ العقد الأساسية:

iptables -t nat -N KUBE-NODEPORTS
iptables -t nat -A prEROUTING -j KUBE-NODEPORTS
iptables -t nat -A الإخراج -j KUBE-NODEPORTS
iptables -t nat -A KUBE-NODEPORTS -p tcp -m comment - التعليق "TEST: افتراضي / nodeport: p " -m tcp --dport 30241 -j KUBE-SVC-EQKU6GMUKRXBR6NWW53

للحصول على حركة المرور من عقدة إلى مضيف محلي: nodeport إلى الخدمة:

صدى 1> / proc / sys / net / ipv4 / conf / all / route_localnet

حدد الحزم الموجهة للخدمات من المضيف المحلي ، ثم تنكرها

iptables -t nat -I KUBE-SVC-EQKU6GMUKRXBR6NWW53 -s 127.0.0.0/16 -j MARK - علامة المجموعة 0x4b000001 ؛
iptables -t nat -A POSTROUTING -m مارك - علامة 0x4b000001 -j MASQUERADE

للحصول على حركة المرور من حجرة إلى نفسها عبر خدمة:

لـ intf في $ (ip link list | grep veth | cut -f2 -d :) ؛ تفعل brctl hairpin cbr0 $ intf on ؛ انتهى

ضع علامة على الحزم الموجهة لكل نقطة نهاية من نفس نقطة النهاية ، ثم تنكرها.

هذا متطفل ، لكنني لا أعرف حقًا أي البودات "محلية" ولا أريد ذلك حقًا في الوقت الحالي. (لكنني سأفعل ذلك في النهاية)

iptables -t nat -I KUBE-SEP-HHNEQBOLY57T5MQCFIY -s 10.244.1.6 -j MARK - علامة المجموعة 0x4b000001

-
قم بالرد على هذا البريد الإلكتروني مباشرة أو قم بعرضه على GitHub
https://github.com/kubernetes/kubernetes/issues/3760#issuecomment -130492394
.

BenTheElder لقد

netperf هي أداة مثالية للعميل / الخادم ، لقد قمت بتجميع كل من العميل والخادم في حاوية عامل الميناء paultiplady / netserver: ubuntu.2. هناك الكثير من الخيارات على netperf ، ولكن هناك شيء مثل تدوير جرابين من netserver وتشغيلها

kubectl exec  -t $netserver-pod-1 -- netperf –l 30 -i 10 -I 99,1 -c -j -H $netserver-pod-2-ip -t OMNI --  -T tcp -D -O THROUGHPUT,THROUGHPUT_UNITS,MEAN_LATENCY,MIN_LATENCY,MAX_LATENCY,P50_LATENCY,P90_LATENCY,P99_LATENCY,STDDEV_LATENCY,LOCAL_CPU_UTIL

يجب أن يمنحك انتشارًا جيدًا للإحصائيات بما في ذلك زمن الوصول والإنتاجية. يمكنك تشغيل حاوية netserver باستخدام docker run --net=host لإجراء اختبارات node-> pod أيضًا.

إن ملف dockerfile لهذه الحاوية بسيط جدًا ، يمكنني إطلاقه إذا كنت ترغب في تمديده إلى شيء أصغر حجمًا (على سبيل المثال ، حاوية تعتمد على alpinelinux لسحب أسرع).

شكرا سأبحث في ذلك.

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

سألقي نظرة على netperf / qperf بالرغم من ذلك ، ويمكننا دائمًا إجراء اختبارات متعددة.
أرغب في إنجاز هذا الرسم البياني أولاً على الرغم من كل مناقشة سابقة معthockin

يوم الخميس ، 13 أغسطس 2015 الساعة 12:02 صباحًا ، Paul Tiplady [email protected]
كتب:

BenTheElder https://github.com/BenTheElder لقد فعلت بعض الشيء بشكل معقول
قياسات أداء الشبكة التفصيلية على GCE - أوصي بإلقاء نظرة على
netperf (يعطي qperf أيضًا قياسات زمن الوصول).

netperf هي أداة مثالية للعميل / الخادم ، لقد قمت بتجميع كل من العميل و
الخادم في حاوية عامل الميناء paultiplady / netserver: ubuntu.2. هناك
الكثير من الخيارات على netperf ، ولكن شيء مثل تدوير اثنين
القرون نتسيرفير وتشغيلها

kubectl exec -t $ netserver-pod-1 - netperf –l 30 -i 10 -I 99،1 -c -j -H $ netserver-pod-2-ip -t OMNI - -T tcp -D -O THROUGHPUT ، THROUGHPUT_UNITS ، MEAN_LATENCY ، MIN_LATENCY ، MAX_LATENCY ، P50_LATENCY ، P90_LATENCY ، P99_LATENCY ، STDDEV_LATENCY ، LOCAL_CPU_UTIL

يجب أن يمنحك انتشارًا جيدًا للإحصائيات بما في ذلك زمن الوصول والإنتاجية.
يمكنك تشغيل حاوية netserver باستخدام docker run --net = host to do
عقدة-> اختبارات جراب أيضا.

إن ملف dockerfile لهذه الحاوية بسيط جدًا ، ويمكنني إطلاقه إذا
تريد توسيعه إلى شيء أصغر حجمًا (على سبيل المثال ، يعتمد على alpinelinux
حاوية لسحب أسرع).

-
قم بالرد على هذا البريد الإلكتروني مباشرة أو قم بعرضه على GitHub
https://github.com/kubernetes/kubernetes/issues/3760#issuecomment -130524576
.

بخصوص منافذ العقدة: في # 9210 ، أحضر Symmetric هذه الحالة:

إذا كانت حركة المرور تتدفق:
LB -> node1:nodePort
وحجرة الخدمة موجودة على العقدة 2 ، فسيكون التدفق الكامل:
LB -> node1:nodePort -> node2 -> pod:svcPort
سيظل srcIP هو LB ، لذلك سيذهب الرد
pod -> node2 -> LB
نظرًا لأن node2 يمكن أن توجه مباشرة إلى LB.

الآن نفقد فرصة un-DNAT لاستعادة IP المصدر الصحيح لحزمة الإرجاع (يمكن أن يحدث ذلك فقط على العقدة 1).

لقد أعدت إنتاج المشكلة. ACK أنها مشكلة حقيقية. يُظهر tcpdump الحزم التي يتم توصيلها DNAT إلى pod IP (خارج الجهاز): المنفذ ، مع src سليمة ، لكن tcpdump على الجهاز الوجهة لا يُظهر أي شيء. لست متأكدًا مما أتوقع حدوثه حتى لو وصلت الحزم إلى هناك.

أعتقد أن الحل الوحيد هو SNAT. سيكون الحل الأقل تأثيرًا هو _ فقط_ حزم SNAT من LB الموجهة خارج العقدة ، لكن أ) ليس لدي هذه المعلومات في kube-proxy (يمكنني الحصول عليها بتكلفة الكود) و ب) منذ أي يجب أن تأخذ السياسة في الاعتبار حالة SNAT على أي حال ، يمكنني التبسيط من خلال SNATing دائمًا حزم LB الخارجية. ما مدى سوء ذلك لمحركات السياسة؟

في النهاية ، ستكون LBs ذكية بما يكفي لاستهداف المضيفين الذين لديهم كبسولات فقط وستظل حركة المرور محلية ، وبعد ذلك سيكون هذا موضع نقاش.

على الرغم من أن الأمر يصبح أكثر تعقيدًا. لدينا حقل PublicIPs مهمل والذي من المحتمل أننا سنلغي استخدامه ببعض التعديلات على السلوك. أعتقد أننا بحاجة لفعل الشيء نفسه بالنسبة لهؤلاء. ولكن الأمر يصبح أكثر تعقيدًا - فأنا لا أعرف في الواقع جميع عناوين IP العامة (على سبيل المثال ، يمتلك الجهاز الظاهري عنوان IP خارجي 1 إلى 1 NAT). إجابة سهلة - دائمًا حزم SNAT node-port. ما رأيك؟

سأختبر المزيد غدًا.

BenTheElder يمكنك جعل netserver pod خدمة ، بحيث تكون حركة المرور من perf <->
يذهب الخادم عبر خدمة VIP. بهذه الطريقة لا يتعين عليك القيام بامتداد
أخذ العينات / حسابات وقت الاستجابة بنفسك ...

الأربعاء، 12 أغسطس 2015 في 09:20، بنيامين المسنين [email protected]
كتب:

شكرا سأبحث في ذلك.

من هذا التعليق
على الرغم من أنني أعتقد أننا نريد إجراء نوع من وقت الاستجابة لطلب الخدمة. حق
الآن حاولت استخدام حاوية nginx القياسية كعقدة X وأعمل عليها
نمتلك وقتًا للاختبار يضربه بشكل متكرر حتى نتمكن من إنشاء رسم بياني عليه
العقدة Y.

سألقي نظرة على netperf / qperf بالرغم من ذلك ، ويمكننا دائمًا إجراء اختبارات متعددة.
أرغب في إنجاز هذا الرسم البياني أولاً على الرغم من كل مناقشة سابقة مع
thockin

يوم الخميس ، 13 أغسطس 2015 الساعة 12:02 صباحًا ، Paul Tiplady [email protected]
كتب:

BenTheElder https://github.com/BenTheElder لقد فعلت بعض الشيء بشكل معقول
قياسات أداء الشبكة التفصيلية على GCE - أوصي بإلقاء نظرة على
netperf (يعطي qperf أيضًا قياسات زمن الوصول).

netperf هي أداة مثالية للعميل / الخادم ، لقد قمت بتجميع كل من العميل و
الخادم في حاوية عامل الميناء paultiplady / netserver: ubuntu.2. هناك
الكثير من الخيارات على netperf ، ولكن شيء مثل تدوير اثنين
القرون نتسيرفير وتشغيلها

kubectl exec -t $ netserver-pod-1 - netperf –l 30 -i 10 -I 99،1 -c -j -H
$ netserver-pod-2-ip -t OMNI - -T tcp -D -O
THROUGHPUT ، THROUGHPUT_UNITS ، MEAN_LATENCY ، MIN_LATENCY ، MAX_LATENCY ، P50_LATENCY ، P90_LATENCY ، P99_LATENCY ، STDDEV_LATENCY ، LOCAL_CPU_UTIL

يجب أن يمنحك انتشارًا جيدًا للإحصاءات بما في ذلك زمن الوصول و
الإنتاجية.
يمكنك تشغيل حاوية netserver باستخدام docker run --net = host to do
عقدة-> اختبارات جراب أيضا.

إن ملف dockerfile لهذه الحاوية بسيط جدًا ، ويمكنني إطلاقه إذا
تريد توسيعه إلى شيء أصغر حجمًا (على سبيل المثال ، يعتمد على alpinelinux
حاوية لسحب أسرع).

-
قم بالرد على هذا البريد الإلكتروني مباشرة أو قم بعرضه على GitHub
<
https://github.com/kubernetes/kubernetes/issues/3760#issuecomment -130524576

.

-
قم بالرد على هذا البريد الإلكتروني مباشرة أو قم بعرضه على GitHub
https://github.com/kubernetes/kubernetes/issues/3760#issuecomment -130527558
.

حقيقي. أعتقد أن thockin ذكر في النهاية أنه يريد اختبار زمن
حسنا. إذا سمح الوقت ، فسيكون هناك عدد من الاختبارات المختلفة وسنقوم بذلك
ربما يتعين عليك حساب gce مقابل AWS وما إلى ذلك.
في 13 أغسطس 2015 ، الساعة 1:47 مساءً ، كتب "Paul Tiplady" [email protected] :

يمكنك جعل netserver pod خدمة ، بحيث تكون حركة المرور من perf <->
يذهب الخادم عبر خدمة VIP. بهذه الطريقة لا يتعين عليك القيام بامتداد
أخذ العينات / حسابات وقت الاستجابة بنفسك ...

الأربعاء، 12 أغسطس 2015 في 09:20، بنيامين المسنين [email protected]
كتب:

شكرا سأبحث في ذلك.

من [هذا التعليق] (

https://github.com/kubernetes/kubernetes/pull/9210#issuecomment-130154261)
على الرغم من أنني أعتقد أننا نريد إجراء نوع من وقت الاستجابة لطلب الخدمة. حق
الآن حاولت استخدام حاوية nginx القياسية كعقدة X والعمل
تشغيل
نمتلك وقتًا للاختبار يضربه بشكل متكرر حتى نتمكن من إنشاء رسم بياني عليه
العقدة Y.

سألقي نظرة على netperf / qperf بالرغم من ذلك ، ويمكننا دائمًا إجراء اختبارات متعددة.
أرغب في إنجاز هذا الرسم البياني أولاً على الرغم من كل مناقشة سابقة مع
thockin

يوم الخميس ، 13 آب (أغسطس) 2015 الساعة 12:02 صباحًا ، بول تيبلادي < [email protected]

كتب:

BenTheElder https://github.com/BenTheElder أنا فقط فعلت بعض
بشكل معقول
قياسات أداء الشبكة التفصيلية على GCE - أوصي بإلقاء نظرة
في
netperf (يعطي qperf أيضًا قياسات زمن الوصول).

netperf هي أداة مثالية للعميل / الخادم ، لقد قمت بتعبئة كل من العميل
و
الخادم في حاوية عامل الميناء paultiplady / netserver: ubuntu.2.
هناك
الكثير من الخيارات على netperf ، ولكن شيء مثل تدوير اثنين
القرون نتسيرفير وتشغيلها

kubectl exec -t $ netserver-pod-1 - netperf –l 30 -i 10 -I 99،1 -c -j
-ح
$ netserver-pod-2-ip -t OMNI - -T tcp -D -O

THROUGHPUT ، THROUGHPUT_UNITS ، MEAN_LATENCY ، MIN_LATENCY ، MAX_LATENCY ، P50_LATENCY ، P90_LATENCY ، P99_LATENCY ، STDDEV_LATENCY ، LOCAL_CPU_UTIL

يجب أن يمنحك انتشارًا جيدًا للإحصاءات بما في ذلك زمن الوصول و
الإنتاجية.
يمكنك تشغيل حاوية netserver باستخدام docker run --net = host to do
عقدة-> اختبارات جراب أيضا.

ملف قفص الاتهام لهذه الحاوية بسيط جدًا ، يمكنني إطلاقه عليه
لو
تريد توسيعه إلى شيء أصغر حجمًا (على سبيل المثال ، يعتمد على alpinelinux
حاوية لسحب أسرع).

-
قم بالرد على هذا البريد الإلكتروني مباشرة أو قم بعرضه على GitHub
<

https://github.com/kubernetes/kubernetes/issues/3760#issuecomment -130524576

.

-
قم بالرد على هذا البريد الإلكتروني مباشرة أو قم بعرضه على GitHub
<
https://github.com/kubernetes/kubernetes/issues/3760#issuecomment -130527558

.

-
قم بالرد على هذا البريد الإلكتروني مباشرة أو قم بعرضه على GitHub
https://github.com/kubernetes/kubernetes/issues/3760#issuecomment -130776866
.

Symmetric تعمل اختبارات netperf بشكل جيد. شكرا على اقتراحك :-)

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

يسعدني سماع أن هذا يعمل من أجلك - هناك عدد محير من ملفات
على تلك الأداة ، لكنها أثبتت أنها مفيدة جدًا لعملي التنميط.
بالتأكيد أفضل من iperf ...

الخميس، 13 أغسطس 2015 في 14:32، بنيامين المسنين [email protected]
كتب:

Symmetric https://github.com/Symmetric اختبارات netperf تعمل
بشكل جميل. شكرا على اقتراحك :-)

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

-
قم بالرد على هذا البريد الإلكتروني مباشرة أو قم بعرضه على GitHub
https://github.com/kubernetes/kubernetes/issues/3760#issuecomment -130850398
.

thockin أعتقد أنه يمكننا التعايش مع SNAT لحركة مرور LB. تفكيري الحالي هو أنك ستحتاج إلى تحديد سياسة الوصول إلى البود كواحد مما يلي:

• الافتراضي هو "السماح من [مساحة الاسم الخاصة بي]" ، وفي هذه الحالة يتم إسقاط حزم LB
• 'السماح من [قائمة مساحات الأسماء]' ، أو 'السماح من [جميع مساحات الأسماء في المجموعة]' ، مرة أخرى يتم دائمًا إسقاط حزم LB
• "السماح من الكل" ، وفي هذه الحالة لا نهتم إذا كان من LB ، أو عقدة أخرى ، أو في أي مكان

لذا فإن فقدان عنوان IP المصدر لـ LBs فقط لا يكلفنا كثيرًا في الواقع.

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

فيما يتعلق بـ publicIPs ، أعتقد أنه سيكون لديهم نفس الاعتبارات مثل nodePort ، ولذا سنحتاج إلى SNAT حتى يتمكن LBs من الوصول إلى المضيفين المناسبين. وهو ما ورد أعلاه على ما يرام ، إلا إذا فاتني طريقة تجعلهم أكثر شرًا من nodePort ...

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

-------- رسالة الأصل --------
دي: Paul Tiplady [email protected]
التاريخ: 14/08/2015 12:50 (GMT + 11: 00)
À: kubernetes / kubernetes [email protected]
نسخة إلى: Mikaël Cluseau [email protected]
Objet: Re: [kubernetes] استخدم iptables للوكيل بدلاً من مساحة المستخدمين
(# 3760)

thockin أعتقد أنه يمكننا التعايش مع SNAT لحركة مرور LB. تفكيري الحالي هو أنك ستحتاج إلى تحديد سياسة الوصول إلى البود كواحد مما يلي:

الافتراضي هو "السماح من [مساحة الاسم الخاصة بي]" ، وفي هذه الحالة يتم إسقاط حزم LB
'السماح من [قائمة مساحات الأسماء]' ، أو 'السماح من [جميع مساحات الأسماء في المجموعة]' ، مرة أخرى يتم دائمًا إسقاط حزم LB
"السماح من الكل" ، وفي هذه الحالة لا نهتم إذا كان من LB ، أو عقدة أخرى ، أو في أي مكان

لذا فإن فقدان عنوان IP المصدر لـ LBs فقط لا يكلفنا كثيرًا في الواقع.

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

فيما يتعلق بـ publicIPs ، أعتقد أنه سيكون لديهم نفس الاعتبارات مثل nodePort ، ولذا سنحتاج إلى SNAT حتى يتمكن LBs من الوصول إلى المضيفين المناسبين. وهو ما ورد أعلاه على ما يرام ، إلا إذا فاتني طريقة تجعلهم أكثر شرًا من nodePort ...

-
قم بالرد على هذا البريد الإلكتروني مباشرة أو قم بعرضه على GitHub.

MikaelCluseau هذه ليست فكرة سيئة - هل يمكنك من فضلك فتح مشكلة جديدة حول هذا الموضوع على وجه التحديد ، حتى لا أفقدها؟

لا يزال TODO: إصلاح دبوس الشعر ، e2e ، تمكين افتراضيًا

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

كانت هذه ملاحظة لنفسي - هل كنت تخطط لمعالجة بعض من هذا؟ :)

نعم ، بالتأكيد ، كما قلت عندما كنا نتحدث عن اختبار e2e. سأقوم بتقديم المساعدة ، Kubernetes هي مساعدة كبيرة بالنسبة لي ، لذلك من الأفضل أن أتقن ذلك قدر الإمكان ، وما هو أفضل من أخذ الأخطاء؟ :-) لا تتردد في اقتراح أي شيء ذي أولوية أعلى ، لكنني أعتقد أن دبوس الشعر مفيد جدًا كبداية. يجب أن يحدث في kubelet وأن يكون لديه علامة لتمكين (تعطيل افتراضيًا في البداية). سأحاول أن أعمل 0.5 إلى 1 يوم في الأسبوع.

AFAIK الجزء الوحيد المتبقي من هذا هو جعله الافتراضي الذي يمكن أن يحدث (بافتراض عدم وجود تفجيرات) بعض الوقت بعد الإصدار 1.1 وهذا يحتوي على بعض الأميال عليه.

واو!

يوم الخميس ، 24 سبتمبر 2015 الساعة 11:21 صباحًا ، Tim Hockin [email protected]
كتب:

AFAIK الجزء الوحيد المتبقي من هذا هو جعله الافتراضي الذي يمكن
يحدث (بافتراض عدم وجود انفجارات) بعض الوقت بعد الإصدار 1.1 وهذا له بعض الأميال
عليه.

-
قم بالرد على هذا البريد الإلكتروني مباشرة أو قم بعرضه على GitHub
https://github.com/kubernetes/kubernetes/issues/3760#issuecomment -142960614
.

بعض الوقت بعد v1.1 وهذا لديه بعض الأميال عليه.

أوتش. كنا نعتمد عليه حقًا مقابل 1.1 ....
https://github.com/kubernetes/kubernetes/blob/master/docs/roadmap.md

bgrieder لا يزال بإمكانك تمكينه من خلال المعلمة.

إنه IN ولكنه ليس قيد التشغيل افتراضيًا. يمكنك الاشتراك مع تعليق توضيحي واحد لكل
العقدة (وإعادة تشغيل kube-proxy)

في الخميس ، 24 سبتمبر 2015 الساعة 8:27 صباحًا ، كتب Bruno G. [email protected] :

بعض الوقت بعد v1.1 وهذا لديه بعض الأميال عليه.

أوتش. كنا نعتمد عليه حقًا مقابل 1.1 ....
https://github.com/kubernetes/kubernetes/blob/master/docs/roadmap.md

-
قم بالرد على هذا البريد الإلكتروني مباشرة أو قم بعرضه على GitHub
https://github.com/kubernetes/kubernetes/issues/3760#issuecomment -142962932
.

thockinbnprss طيب لكننا نتوقع الإصدار 1.1 لتشغيل على محرك جوجل الحاويات بعد الافراج عنهم. أتساءل عن نوع المرونة التي سنضطر إلى "الاشتراك فيها بتعليق توضيحي واحد لكل عقدة". هل يمكنك إعطائنا بعض التفاصيل حول ماهية العملية أو توجيهنا إلى بعض الوثائق؟

بمجرد الترقية إلى 1.1:

$ for node in $(kubectl get nodes -o name); do kubectl annotate $node net.beta.kubernetes.io/proxy-mode=iptables; done

ثم SSH لكل عقدة وأعد تشغيل kube-proxy (أو أعد تشغيل كل عقدة).

إذا كنت تريد أن تكون أكثر حذرًا ، فافعل عقدة واحدة أو عقدتين ثم جربها :)

لقد حددت هذه المشكلة على أنها "ملاحظة إصدار" حتى لا ننسى تضمين تلك الحلقة السحرية في وثائقنا 1.1.

تضمين التغريدة

(أردت فقط أن أقول إننا نستخدم وكلاء iptables لمدة أسبوع الآن ويبدو كل شيء على ما يرام!)

thockin هل يجب إغلاق هذا أو إزالته من 1.1؟

سوف أنقله إلى 1.2 فقط من أجل التمكين الافتراضي.

نعتذر عن سؤال قد يكون غبيًا ، ولكن فيما يتعلق بالحفاظ على عناوين IP الخاصة بالعميل:

thockin رأيت في عدد آخر في 2 سبتمبر أن "حركة المرور داخل الكتلة فقط هي التي تحتفظ بعنوان IP الخاص بالعميل" - هل هذا لا يزال صحيحًا بالنسبة لـ 1.2 alpha؟

أطلقنا كتلة 1.2 جديدة ، وطبقنا شرح العقدة ، وأعدنا التشغيل ، وما زلنا نرى 10.244.0.1 كعنوان المصدر لجميع الطلبات المقدمة إلى حجرة تعمل بنظام HAProxy.

في هذه المرحلة ، أحاول فقط معرفة ما إذا كان قد فاتنا إعدادًا أم لا أو أنني أحاول تحقيق شيء غير ممكن بعد - وهو رؤية عنوان IP العام للعميل الفعلي الذي يقدم الطلب من خارج الكتلة.

لا يزال الافتراضي يستخدم وضع مساحة المستخدمين. يجب عليك تعيين تعليق توضيحي على
العقدة (net.beta.kubernetes. io / proxy-mode = iptables) وأعد تشغيل
الوكيل. ولكن هذا لن يعرض عناوين IP الخارجية للعميل ، فقط داخل الكتلة
عناوين IP.
في 23 أكتوبر 2015 ، 5:09 مساءً ، كتب "Ben Hundley" [email protected] :

أعتذر عن سؤال قد يكون غبيًا ، ولكن بخصوص الحفظ
من عناوين IP الخاصة بالعميل:

thockin https://github.com/thockin رأيت في عدد آخر في 2 سبتمبر
أن "حركة المرور داخل الكتلة فقط تحتفظ بـ IP للعميل" - هل هذا لا يزال
صحيح بالنسبة لـ 1.2 ألفا؟

أطلقنا مجموعة 1.2 جديدة ، وطبقنا شرح العقدة ، وأعدنا التشغيل ،
وما زلت ترى 10.244.0.1 كعنوان المصدر لجميع الطلبات المقدمة إلى
جراب يعمل بنظام HAProxy.

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

-
قم بالرد على هذا البريد الإلكتروني مباشرة أو قم بعرضه على GitHub
https://github.com/kubernetes/kubernetes/issues/3760#issuecomment -150725513
.

أنا قادر على الحفاظ على عنوان IP للعميل الخارجي عن طريق DNAT 'حركة المرور الخارجية + التوجيه من خلال وكيل kube. على سبيل المثال ، إذا كانت شبكة الخدمة الخاصة بك هي 10.42.0.0/16 وكان لديك وكيل kube متاح للغاية على IP 10.10.1.1 ، فيمكنك الحصول على قاعدة iptable التالية:

-A PREROUTING -i public -p tcp -m tcp --dport 25 -j DNAT --to-destination 10.42.12.34

والطريق التالي:

10.42.0.0/16 via 10.10.1.1 dev edge 

ثم يرى الجزء الخلفي عنوان IP الحقيقي:

Oct 24 02:41:39 email-0yr7n mail.info postfix/smtpd[469]: connect from zed.yyy.ru.[94.102.51.96]

يجب أن يكون لديك الحق في مسار عودة الحزمة بالطبع.

نعم ، إذا كان DNATs هذا إلى خلفية خارج الجهاز ، فإنك تشكل مثلثًا بدونه
سنات. هذه هي المشكلة الأساسية.

يوم الجمعة 23 أكتوبر 2015 الساعة 8:12 مساءً ، Mikaël Cluseau [email protected]
كتب:

أنا قادر على الاحتفاظ بعنوان IP للعميل الخارجي عن طريق DNAT'ing حركة المرور الخارجية +
التوجيه من خلال وكيل kube. على سبيل المثال ، إذا كانت شبكة الخدمة الخاصة بك
10.42.0.0/16 ولديك وكيل kube متاح للغاية على IP
10.10.1.1 ، يمكنك الحصول على قاعدة iptable التالية:

-A PREROUTING -I public -p tcp -m tcp --dport 25 -j DNAT - to-Destination 10.42.12.34

والطريق التالي:

10.42.0.0/16 عبر 10.10.1.1 dev edge

ثم يرى الجزء الخلفي عنوان IP الحقيقي:

24 أكتوبر 02:41:39 mail.info-0yr7n postfix / smtpd [469]: الاتصال من zed.yyy.ru. [94.102.51.96]

يجب أن يكون لديك الحق في مسار عودة الحزمة بالطبع.

-
قم بالرد على هذا البريد الإلكتروني مباشرة أو قم بعرضه على GitHub
https://github.com/kubernetes/kubernetes/issues/3760#issuecomment -150747217
.

صوت مثير للاهتمام ، أي ارتباط؟ :-) أحاول إيجاد طريقة للتأكد من أن الحزمة ستخضع لقاعدة conntrack الصحيحة. كنت أفكر في تكرار حالة conntrack من خلال الكتلة.

أنا ضائع قليلاً فيما تحاول تحقيقه.

الطريقة التي من المفترض أن يعمل بها وكيل iptables الحالي هي تلك الحزمة
يصل إلى عقدة ، نكتشف أنه لم يتم إنشاؤه محليًا ، فضع علامة عليه
SNAT ، اختر الخلفية ، أعد توجيهه إلى الخلفية باستخدام SNAT ، تستجيب الخلفية
بالنسبة لنا ، نحن نتخلى عن SNAT ، ونفحص DNAT ، ونستجيب للمستخدم الخارجي.

يوم الجمعة 23 أكتوبر 2015 الساعة 9:32 مساءً ، Mikaël Cluseau [email protected]
كتب:

صوت مثير للاهتمام ، أي ارتباط؟ :-) أحاول إيجاد طريقة للتأكد من
الحزمة سوف تمر من خلال قاعدة conntrack الصحيحة. كنت أفكر حول
تكرار حالة conntrack من خلال الكتلة.

-
قم بالرد على هذا البريد الإلكتروني مباشرة أو قم بعرضه على GitHub
https://github.com/kubernetes/kubernetes/issues/3760#issuecomment -150753147
.

أوه ، آسف إذا كنت غير واضح. كنت أتحدث عن قضية SNAT-less. إذا كان لكل وكيل kube نفس قائمة الاتصال ، فيجب أن يكون أي منهم قادرًا على إلغاء DNAT بشكل صحيح عندما ترد الحاوية على العميل.

لم أتمكن من رؤية نسخة بدون نسخ لا تتضمن HA للاحتفاظ بهيكل على شكل خط مثل هذا:

[client] ----- [proxy in HA] ------ [node1]
                           `------- [node2]

ولكن إذا نجح شيء على شكل مثلث ، فيجب أن يفتح المزيد من الاحتمالات.

[client] ----- [proxy1] ------ [node1]
       `------ [proxy2] ------ [node2]

سيكون هذا لطيفًا ولكنه يبدو مجنونًا

يوم الأحد 25 أكتوبر 2015 الساعة 11:20 مساءً ، Mikaël Cluseau [email protected]
كتب:

أوه ، آسف إذا كنت غير واضح. كنت أتحدث عن قضية SNAT-less. لو
كل وكيل kube لديه نفس قائمة conntrack ، يجب أن يكون أي منهم قادرًا على ذلك
un-DNAT بشكل صحيح عندما ترد الحاوية على العميل.

لم أستطع رؤية كان بدون نسخ متماثل لا يتضمن HA للاحتفاظ بامتداد
هيكل على شكل خط مثل هذا:

[العميل] ----- [الوكيل في HA] ------ [العقدة 1]
"------- [عقدة 2]

ولكن إذا نجح شيء على شكل مثلث ، فيجب أن يفتح المزيد من الاحتمالات.

[العميل] ----- [proxy1] ------ [node1]
"------ [proxy2] ------ [عقدة 2]

-
قم بالرد على هذا البريد الإلكتروني مباشرة أو قم بعرضه على GitHub
https://github.com/kubernetes/kubernetes/issues/3760#issuecomment -151037663
.

الطريقة التي يجب علي استكشافها (لم أرغب في طرح السؤال قبل إجراء البحث المناسب ولا أحب ذلك ، ولكن نظرًا لأن subjet مفتوح الآن ...) هو "التوجيه متعدد المسارات غير المتماثل" الذي يمكنك رؤيته هنا: http: // conntrack-tools.netfilter.org/manual.html#sync-aa. ونعم ، سيكون ذلك رائعًا حقًا :-)

أبسط شيء يمكن أن ينجح ...

1. يتلقى proxy1 اتصالًا جديدًا من خلال خطاف iptables (أعتقد أنني رأيت ذلك في مكان ما) ، ويقوم LB الخاص به بتعيينه إلى عقدة proxy2.
2. يرسل proxy1 طلبًا مثل "إعداد إدخال conntrack لـ {src-ip}: {src-port} -> {pod-ip}: {pod-port}"
3. يتلقى proxy2 الطلب ، وإعداد إدخال conntrack ، وإرساله إلى proxy1
4. proxy1 دع الحزمة تمر عبر قاعدة DNAT (التي تضع إدخال conntrack في proxy1 أيضًا).
5. عندما يرد الكبسولة ، فإن مضيف proxy2 هو unDNATs وفقًا لذلك.
6. عندما يرسل العميل حزمة أخرى على هذا التدفق من خلال proxy1 ، يقوم إدخال conntrack بعمل DNAT الصحيح أيضًا.

بهذه الطريقة ، تكون النفقات العامة عبارة عن حزمتين لكل اتصال جديد ، ويتم سدادها سريعًا عن طريق تجنب التوجيه الإضافي un-SNAT + (لأنه بخلاف ذلك ، يجب أن تعود الحزمة من خلال الوكيل 1).

أنا لست رجل شبكة لذا قد أفترض الكثير ، لكن هذا يبدو معقولاً.

في حالتي ، كنت أهدف إلى إنشاء قواعد جدار الحماية ، لكل خدمة NodePort.

يبدو أنه يمكنني إضافة قواعد ALLOW IP / DROP بسيطة لكل شيء آخر في سلسلة INPUT ، مثل:

iptables -A INPUT -s $WHITELISTED_IP -p tcp --dport $CONTAINER_PORT -j ACCEPT
iptables -A INPUT -p tcp --dport $CONTAINER_PORT -j DROP

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

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

هل هناك أي شيء يمكن أن يسبب مشكلة هنا؟ هل أنا مجنون؟

thockin لديها وجهة نظر أفضل مني ، لكنني لن أستخدم

# while true; do etcdctl watch "/iptables/$(hostname)" && etcdctl get /iptables/$(hostname) |iptables-restore --noflush; done &
# iptables -F my-filter
# iptables -nvL my-filter
Chain my-filter (0 references)
 pkts bytes target     prot opt in     out     source               destination      
# ~nwrk/go/bin/etcdctl set /iptables/$(hostname) >/dev/null <<EOF
*filter
:my-filter -
-A my-filter -j ACCEPT -s 1.2.3.4 -p tcp --dport 80
-A my-filter -j DROP -p tcp --dport 80
COMMIT
EOF
# iptables -nvL my-filter
Chain my-filter (0 references)
 pkts bytes target     prot opt in     out     source               destination         
    0     0 ACCEPT     tcp  --  *      *       1.2.3.4              0.0.0.0/0            tcp dpt:80
    0     0 DROP       tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcp dpt:80

أعتقد أنك تريد # 14505

يوم الإثنين 26 أكتوبر 2015 الساعة 8:53 صباحًا ، أرسل Ben Hundley [email protected]
كتب:

في حالتي ، كنت أهدف إلى إنشاء قواعد جدار الحماية ، لكل خدمة NodePort.

يبدو أنه يمكنني إضافة قواعد ALLOW IP / DROP البسيطة لكل شيء آخر
سلسلة INPUT ، مثل:

iptables -A INPUT -s $ WHITELISTED_IP -p tcp --dport $ CONTAINER_PORT -j ACCEPT
iptables -A INPUT -p tcp --dport $ CONTAINER_PORT -j DROP

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

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

هل هناك أي شيء يمكن أن يسبب مشكلة هنا؟ هل أنا مجنون؟

-
قم بالرد على هذا البريد الإلكتروني مباشرة أو قم بعرضه على GitHub
https://github.com/kubernetes/kubernetes/issues/3760#issuecomment -151181267
.

كان هذا هو النهج الأولي ، مع إرفاق مجموعات الأمان بموازنات التحميل. لقد وصلت للتو إلى الحد الأقصى للمستمعين لكل واجهة شبكة بسرعة كبيرة على AWS ، وواجهت بعض المنطق المشعر الذي يحاول نشر قواعد جدار الحماية عبر عدة SGs و ELBs متعددة لمجموعة kube واحدة.

لحسن الحظ ، نحن نصل إلى حل أفضل لا يتضمن الشد مع iptables.

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

@ shaylevi2 لا توجد طريقة جيدة حاليًا للحصول على عنوان IP للعميل أثناء الارتداد عبر LB السحابي وإلى nodePort. بمجرد اللحاق بـ Cloud LB ، سأقفز فوقه مباشرة. ولكن هذا لا يحافظ على عنوان IP للعميل داخل الكتلة

ولكن هذا لا يحافظ على عنوان IP للعميل داخل الكتلة

يعتمد ذلك على كيفية إنشاء الشبكات العنقودية بالضبط ؛ على سبيل المثال ، لا يعمل بشكل صحيح في OpenShift في الوقت الحالي ، لأن قواعد iptables لا تعمل على حركة المرور الداخلية OVS. لذلك تحصل الحزم على DNAT عند الانتقال إلى نقطة نهاية الخدمة ، ولكن نظرًا لأن عنوان IP المصدر داخلي في المجموعة ، ستبقى الاستجابة داخل OVS ، لذلك لا تصل إلى iptables مرة أخرى ، لذلك لا يتم عكس DNAT ، لذلك لا يتعرف جراب العميل على الحزم. في الوقت الحالي ، أبسط حل لهذا هو التنكر الكامل للحزم التي تذهب إلى نقطة النهاية ، وإجبارها على الارتداد من OVS مرة أخرى في طريق الخروج. (أنا أعمل على اكتشاف طريقة ما للتغلب على هذا.)

هل لدى OVS مفهوم VIP داخليًا؟ يمكنك فقط التخلص من
وكيل kube (cf opencontrail)

يوم الجمعة ، 20 تشرين الثاني (نوفمبر) 2015 الساعة 7:09 صباحًا ، Dan Winship [email protected]
كتب:

ولكن هذا لا يحافظ على عنوان IP للعميل داخل الكتلة

يعتمد ذلك على كيفية إنشاء الشبكات العنقودية بالضبط ؛ على سبيل المثال ، لا
تعمل بشكل صحيح في OpenShift في الوقت الحالي ، لأن قواعد iptables لا تعمل
على حركة المرور الداخلية OVS. لذلك تحصل الحزم على DNAT'ed في الخدمة
نقطة النهاية ، ولكن نظرًا لأن IP المصدر هو داخلي للكتلة ، فستكون الاستجابة
ابق داخل OVS ، لذلك لا يضرب iptables مرة أخرى ، لذا فإن DNAT لا يفعل ذلك
يتم عكسها ، لذلك لا يتعرف جراب العميل على الحزم. في ال
أبسط حل لذلك هو تنكر الحزم بالكامل
الذهاب إلى نقطة النهاية ، وإجبارهم على الارتداد من OVS مرة أخرى
طريق الخروج. (أنا أعمل على اكتشاف طريقة ما للتغلب على هذا.)

-
قم بالرد على هذا البريد الإلكتروني مباشرة أو قم بعرضه على GitHub
https://github.com/kubernetes/kubernetes/issues/3760#issuecomment -158426296
.

لقد تحدثنا عن القيام بشكل أساسي بما يعادل وكلاء iptables الخالص تمامًا داخل OVS ، لكن هذا يتطلب دعمًا لـ OVS conntrack ، الأمر الذي يتطلب نواة حديثة جدًا ، والتي لا نريد الاعتماد عليها بعد. ربما تكون هذه هي الخطة طويلة المدى.

(في الوقت الحالي ، يبدو أنه يمكننا جعلها تعمل عن طريق إضافة قفزة إضافية غير مبررة للخروج من OVS للحزم ذات منفذ IP + المصدر المطابق لنقطة نهاية خدمة معروفة تأتي من واجهة حاوية ؛ ومن المحتمل أن تكون العقدة بعد ذلك غير DNAT ، ثم ارتدها مرة أخرى إلى OVS حيث يمكن إعادتها إلى حجرة العميل بشكل صحيح.)

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

يوم الاثنين 23 نوفمبر 2015 الساعة 6:54 صباحًا ، Dan Winship [email protected]
كتب:

لقد تحدثنا عن القيام بشكل أساسي بما يعادل
pure-iptables-proxying بالكامل داخل OVS ، لكن هذا يتطلب اتصال OVS
الدعم ، الذي يتطلب نواة حديثة جدًا ، والتي لا نريد الاعتماد عليها
حتى الآن. ربما تكون هذه هي الخطة طويلة المدى.

(في الوقت الحالي ، يبدو أنه يمكننا جعلها تعمل عن طريق إضافة ميزة إضافية غير مبررة
قفز من OVS للحزم ذات منفذ IP + المصدر المطابق لخدمة معروفة
نقطة النهاية التي تأتي من واجهة حاوية ؛ سوف العقدة بعد ذلك
ربما un-DNAT ، ثم ارتدها مرة أخرى إلى OVS حيث يمكن أن تحصل عليها
إعادته إلى حجرة العميل بشكل صحيح.)

-
قم بالرد على هذا البريد الإلكتروني مباشرة أو قم بعرضه على GitHub
https://github.com/kubernetes/kubernetes/issues/3760#issuecomment -158959014
.

على الرغم من أن iptables / nftables ستحل كل من حالات استخدام موازنة تحميل TCP و UDP ، فأنا شخصيًا أعتقد أن IPVS https://github.com/kubernetes/kubernetes/issues/17470 سيكون مناسبًا بشكل أفضل لأنه مصمم لغرض موازنة التحميل (اقرأ: تغيير / صيانة أقل لفريق k8s) ، يقدم مجموعة أكثر ثراءً من خوارزميات موازنة الحمل ، وقد أثبت ثباته في السرعات القريبة من معدل الخط ، كما أن AMD لديها مكتبات golang جاهزة للتعامل مع القواعد.

thockin ، آخرون ، وفقًا لـ https://github.com/kubernetes/kubernetes/issues/3760#issuecomment -150743158 ، قمت بالتعليق التوضيحي ، ولكن كما ذكرنا بشكل صحيح ، لا يزال عنوان IP الخارجي للعميل غير مرئي من خلال التطبيق الموجود في حاوية .

كيف يمكن تحقيق ذلك ، أي الحصول على عنوان IP للعميل الخارجي؟ في الإعداد الخاص بي ، لا يوجد LB خارجي ، ويتم الكشف عن الخدمة على أنها nodeport ويقوم العميل بإجراء اتصال TCP عادي (وليس http / Websocket) مع تطبيق الحاوية الخاص بي.

ashishvyas ما هو إصدار وكيل kube الذي تقوم بتشغيله؟

أنا أقوم بتشغيل v1.1.3

اتبع الإرشادات في https://github.com/kubernetes/kubernetes/issues/3760#issuecomment -143280584 و https://github.com/kubernetes/kubernetes/issues/3760#issuecomment -150743158 ولكن بدلاً من استخدام التعليق التوضيحي المسمى net.beta.kubernetes.io/proxy-mode ، استخدم التعليق التوضيحي المسمى net.experimental.kubernetes.io/proxy-mode .

for node in $(kubectl get nodes -o name); do
  kubectl annotate $node net.experimental.kubernetes.io/proxy-mode=iptables;
done

يجب أن تشاهد عبارات السجل في بداية بدء تشغيل kube-proxy مثل "العثور على تعليق توضيحي تجريبي" و "Annotation allow iptables proxy"

الإصدار الأول الذي قدمه https://github.com/kubernetes/kubernetes/commit/da9a9a94d804c5bfdf3cc86ee76a2bc1a2742d16 كان 1.1.4 لذا فإن net.beta.kubernetes.io/proxy-mode لا يعمل مع العديد من الأشخاص. أنت لست أول شخص يواجه هذا.

نظرًا للطريقة التي يعمل بها الوكيل ، نفقد عنوان IP الخاص بالعميل عندما يأتي
منفذ عقدة. أعلم أن هذا ليس رائعًا. إنه يدور في ذهني كثيرًا حول كيفية القيام بذلك
قم بإصلاح هذا الأمر بشكل صحيح ، ولكن غالبًا ما يرجع ذلك إلى إمكانات
موازن التحميل (أو الطرق الأخرى التي تصل بها حركة المرور إلى العقدة ، مثل
كـ DNS-RR)

يوم الأربعاء ، 13 كانون الثاني (يناير) 2016 ، الساعة 10:25 صباحًا ، Mike Danese [email protected]
كتب:

اتبع التعليمات الموجودة في # 3760 (تعليق)
https://github.com/kubernetes/kubernetes/issues/3760#issuecomment -143280584
و # 3760 (تعليق)
https://github.com/kubernetes/kubernetes/issues/3760#issuecomment -150743158
ولكن بدلاً من استخدام التعليق التوضيحي المسمى
net.beta.kubernetes.io/proxy-mode ، استخدم التعليق التوضيحي المسمى
net.experimental.kubernetes.io/proxy-mode.

للعقدة في $ (kubectl get nodes -o name) ؛ فعل
kubectl annotate $ node net.experimental.kubernetes.io/proxy-mode=iptables؛
انتهى

يجب أن تشاهد عبارات السجل في بداية بدء تشغيل kube-proxy
مثل "العثور على تعليق توضيحي تجريبي" و "التعليق التوضيحي يسمح ببروكسي iptables"

الإصدار الأول الذي da9a9a9
https://github.com/kubernetes/kubernetes/commit/da9a9a94d804c5bfdf3cc86ee76a2bc1a2742d16
جعله 1.1.4. أنت لست أول شخص يواجه هذا.

-
قم بالرد على هذا البريد الإلكتروني مباشرة أو قم بعرضه على GitHub
https://github.com/kubernetes/kubernetes/issues/3760#issuecomment -171387997
.

thockin ، هل من

لا ، لا يوجد حل حقيقي حاليا. المشكلة تعود إلى
حقيقة أن كل وكيل kube قد يختار خلفية على عقدة مختلفة.
سيكون لإعادة توجيه حركة المرور باستخدام عنوان IP الأصلي للعميل العقدة الأخرى
الرد مباشرة والتي من الواضح أنها لن تعمل.

يتمثل "الإصلاح" في _ فقط_ في إرسال حركة مرور الخدمة S إلى العقد الموجودة في
خلفية واحدة على الأقل لـ S _ و_ لإرسال حركة مرور متناسبة مع عدد
الخلفية لكل عقدة. يمكن بعد ذلك اختيار Kube-proxy الخلفيات المحلية
حصريا.

ضع في اعتبارك عقدتين و 3 خلفيات خلفية. عقدة واحدة تنتهي بالضرورة بـ 2
الخلفية. مهما كانت المسارات التي يجب أن ترسلها حركة المرور بمقدار ضعفين إلى عقدة واحدة
هل لعقدة أخرى. نحن فقط لم نعالج هذه المشكلة حتى الآن - لا شيء منها
تدعم موازنات التحميل السحابي هذا ، لذا فهو نوع من المضاربة و
لذلك من الخطورة جدًا البدء في العمل عليها.

يوم الأربعاء ، 13 كانون الثاني (يناير) 2016 ، الساعة 12:17 ظهرًا ، Ashish Vyas [email protected]
كتب:

thockin https://github.com/thockin ، أي حل مؤقت
عنوان هذا ممكن الآن؟ إذا كانت الإجابة بنعم ، فإنني أوصي بتوفير
من شأن الخطوات التفصيلية لي وللآخرين في هذا الموضوع أن تساعد.

-
قم بالرد على هذا البريد الإلكتروني مباشرة أو قم بعرضه على GitHub
https://github.com/kubernetes/kubernetes/issues/3760#issuecomment -171420567
.

mikedanese ، لا يبدو أنني قادر على العثور على 1.1.4 على gcr.io:

sudo docker pull gcr.io/google_containers/ hyperkube: v1.1.4
سحب المستودع gcr.io/google_containers/hyperkube
لم يتم العثور على العلامة v1.1.4 في المستودع gcr.io/google_containers/hyperkube
sudo docker pull gcr.io/google_containers/ hyperkube: v1.1.3
v1.1.3: السحب من google_containers / hyperkube
الخلاصة: sha256: 004dde049951a4004d99e12846e1fc7274fdc5855752d50288e3be4748778ca2
الحالة: الصورة محدثة لـ gcr.io/google_containers/ hyperkube: v1.1.3

thockin Apologies على الاستجابة الطويلة ، أردت تغطية كلتا الطريقتين اللتين حاولنا

كخلفية صغيرة ، يعد تطبيقنا الرئيسي نظامًا أساسيًا ذكيًا لنظام أسماء النطاقات عالي الأداء (أي أنه يحتاج إلى UDP ويحتاج إلى ما لا يقل عن 100 ألف طلب / ثانية لكل جراب) ، وتطبيقه الداعم في وكيل SNI الذي يحتاج إلى رؤية العملاء حقيقيين عنوان IP (هذا سدادة عرض بالنسبة لنا). لم نرغب في استخدام أساليب شبكات مختلفة لتطبيقات مختلفة ، لذلك قررنا توحيد طريقة شبكة واحدة للجميع ، واخترنا استخدام IPVS للأسباب التي ذكرتها أعلاه (الأداء / الاستقرار / المرونة / الغرض بناء SLB) ، ولكن ربما يمكنك اختراق شيء ما معًا باستخدام iptables فقط على نفس المنوال أيضًا. نحن نستخدم vxlan (سريع وسهل ويعمل بين المواقع) ولكن يجب أن تعمل كلتا الطريقتين أيضًا مع GRE / VXLAN مع OVS أو مع شبكة مضيف من الطبقة الثانية أيضًا (بافتراض أن مضيفيك جميعًا على نفس شبكة L2).

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

لقد حاولنا استخدام نموذجين لمعالجة هذا:

الطريقة الأولى التي جربناها كانت طبقتين من الشخصيات المهمة. الشخصيات المهمة الخارجية (1 لكل خدمة) ، والتي توزع حركة المرور عبر العقد (بناءً على عدد البود لتلك الخدمة على العقدة) ، ثم الشخصيات المهمة الداخلية (التي تعمل على العقدة مع البودات) ، والتي توزع الحمل داخل العقد (عادةً بالتساوي عبر القرون). كان الحد من هذا النموذج هو أن العقد التي تشغل VIP خارجيًا تحتاج إلى تشغيل مساحتين مختلفتين لأسماء الشبكة ، أو تشغيل العقد المادية الخاصة بها. الشيء الجميل مع IPVS في وضع DSR (عودة الخادم المباشر) هو أنه لا يحتاج إلى رؤية حركة العودة ، حيث يذهب المرور:

Consumer >> (over L3) >> External VIP node >> (1) >> Internal VIP node >> (2) >> Container >> (any which way you want) >> Consumer

(1) IPVS (في وضع DSR) على المضيف مع VIP خارجي يختار _node_ لإرسال حركة المرور إلى ("خادم حقيقي" بمصطلحات IPVS) ، ولا يغير سوى عنوان DST MAC للحزمة (على سبيل المثال ، تصل حزمة IP دون تغيير في عقدة k8s). يقوم بتحميل الأرصدة عبر العقد بناءً على عدد الكبسولات التي تقوم بتشغيل تلك الخدمة على العقدة.
(2) IPVS (أيضًا في وضع DSR) على تحميل عقدة k8s يوازن حركة المرور عبر القرون (عبر veths إلى العقدة). تعود الردود من الحاويات (TCP و UDP) مباشرة إلى مستهلك الخدمة.

الجانب الإيجابي لهذا النموذج ، هو أنه كان من السهل حقًا البدء وكان من السهل جدًا إدارة مجموعة القواعد. يتمثل الجانب السلبي لهذا النموذج في أنه يركز جميع طلبات الخدمة لدينا (ولكن ليس الردود) من خلال عدد من العقد التي تدير كبار الشخصيات الخارجية. نحن نحب "لا شيء مشترك" ، لذا أدخل الإصدار 2:

النموذج الثاني هو الآن ترفيهي هو طبقة واحدة من الشخصيات المهمة مع تكوين IPVS و iptables أكثر ذكاءً.

Consumer >> Any node/local node >> (1) >> Container >> (any which way you want) >> Consumer
أو قد ينتقل إلى عقدة أخرى:
Consumer >> Any node/local node >> (1) >> Remote Node >> (2) >> Container >> (any which way you want) >> Consumer

(1) تصل حركة المرور إلى VIP الأساسي ، ويتم موازنة حركة المرور عبر جميع القرون في المجموعة.
(2) حركة المرور تصل إلى VIP الثانوي ، يتم تحميل حركة المرور بشكل متوازن فقط عبر جميع القرون المحلية. يتم استخدام VIP الثانوي هذا فقط لحركة المرور الواردة من مضيفين آخرين على الشبكة (إنها FWMARK VIP). نضع علامة على حركة المرور الواردة في أي واجهة خارجية باستخدام FWMARK = 1234 ، وهذا يجبر حركة المرور على الانتقال إلى مجموعة قواعد مختلفة ، مما يمنع الحلقات بين العقد.

يحتوي VIP الأساسي على قائمة بالقرون المحلية والمضيفين البعيدين مع القرون (مع وزن 100 لكل قرون محلية ، و 100 * عدد من البودات للعقد البعيدة). لذلك على سبيل المثال ، إذا كانت 3 حاضنات تعمل محليًا على العقدة A ، وهناك جرابان يعملان على nodeB ، فإن القواعد في العقدة A ستبدو كما يلي:

Prot LocalAddress:Port Scheduler Flags
-> RemoteAddress:Port Forward Weight ActiveConn InActConn
TCP service.ip.address:0 rr persistent 360
-> pod1.on.nodeA.ip:80 Route 100 0 0
-> pod2.on.nodeA.ip:80 Route 100 0 0
-> pod2.on.nodeA.ip:80 Route 100 0 0
-> interfaceip.of.nodeB:80 Route 200 0 0
FWM 1234 rr
-> pod1.on.nodeA.ip:80 Route 100 0 0
-> pod2.on.nodeA.ip:80 Route 100 0 0
-> pod3.on.nodeA.ip:80 Route 100 0 0

ومع ذلك ، في nodeB ، سيبدو تكوين IPVS مختلفًا بعض الشيء لأنه يحتوي على وحدتين محليتين فقط ، وثلاثة بودات بعيدة على العقدة A:

Prot LocalAddress:Port Scheduler Flags
-> RemoteAddress:Port Forward Weight ActiveConn InActConn
TCP service.ip.address:0 rr persistent 360
-> pod1.on.nodeB.ip:80 Route 100 0 0
-> pod2.on.nodeB.ip:80 Route 100 0 0
-> interfaceip.of.nodeA:80 Route 300 0 0
FWM 1234 rr
-> pod1.on.nodeB.ip:80 Route 100 0 0
-> pod2.on.nodeB.ip:80 Route 100 0 0

هناك طريقة أخرى تتمثل في تبديل FWMARKs ، واستخدام iptables إلى FWMARK أي شيء في واجهات veth + (تطابق حرف البدل) واستخدام تطابق FWMARK فقط لموازنة الحمل المحلي.

نظرًا لعدم وجود NAT متضمن هنا ، فأنت بحاجة إلى إضافة SVC_XXX_YYY IPs في البيئة إلى واجهة استرجاع أو وهمية عند بدء كل جراب ، ولكن ربما يمكنك أيضًا تغيير IPVS VIPs للقيام بـ DNAT أيضًا ، لا أرى لماذا لا يعمل ذلك.

والنتيجة النهائية هي أكثر الشبكات المباشرة ، دون الحاجة إلى مركزية معالجة / توجيه الطلبات بحيث تتوسع بشكل أفضل. الجانب السلبي هو بعض الذكاء الإضافي عند إنشاء قواعد IPVS. نستخدم القليل (golang) daemon للقيام بكل هذا ، لكنني سأفكر في كتابة وحدة k8s لهذا إذا كان لدي الوقت وكان هناك اهتمام كافٍ.

إنني أتعمق في هذه المشكلة مؤخرًا ، وربما لم أقرأ المسار الكامل بالتفصيل الكافي ، ولكن فقط في حالة المساعدة: إذا فهمت منشورqoke أعلاه ، فإنهم يريدون استخدام الشخصيات المهمة ، وليس منافذ العقدة . كان أحد المخاوف التي أثيرت سابقًا في الخيط هو عدم الحفاظ على عنوان IP المصدر عند استخدام iptables kubeproxy. ومع ذلك ، يتم الاحتفاظ بها إذا كنت تستخدم خدمة VIP وليس ميزة منفذ العقدة على ما أعتقد. (على أي حال ، كما قلت ، لم أقرأ حقًا المسار الكامل ، لذا إذا كانت هذه التعليقات واضحة أو غير مفيدة ، فيرجى تجاهلها! سأحاول تخصيص وقت لقراءتها بعمق في الأسبوع المقبل عندما أعود من الإجازة).

lxpollitt صحيح ، يتم الحفاظ على عنوان IP المصدر عند استخدام IPVS ، ولكن ضع في اعتبارك أنه باستخدام هذه الطريقة كان علينا أن نقوم بكل الشبكات بأنفسنا إلى حد كبير ، لأن تكوين IPVS غير مدعوم من قبل kube-proxy. يمكنك أيضًا الاحتفاظ بمصدر IP مع iptables ، ولكنك تحتاج إلى طبقتين من IPtables DNAT حتى تتمكن من "un-nat" حركة المرور في طريق العودة

من جانبي ، مع flannel (في وضع vxlan) لإدارة شبكة الحاويات الخاصة بي ، أستخدم kube-proxy (في وضع iptables وليس التنكر) + flannel في مساحة اسم على عقد التوجيه الخاصة بي. يتم إرسال الطلبات الخارجية DNAT إلى عناوين IP للخدمة ثم إعادة توجيهها عبر مساحة الاسم باستخدام وكيل kube. لم أقم باختبار مجموعة جهاز التوجيه النشط / النشط ، لكن هذا الإعداد يسمح لي بالاحتفاظ بعنوان IP الخارجي. أذكرها FWIW ، لكنني أفهم أنها ليست "أكثر الشبكات المباشرة".

أفهم أنه إذا كان بإمكان kube-proxy إدارتها فسيكون ذلك أمرًا رائعًا ، ولكن نظرًا لاحتياجاتك الخاصة وخاصة حقيقة أن موازنة التحميل خارج وكيل kube بالفعل ، أليس من المنطقي ترميز مدير قواعد iptables للعميل مشاهدة حالة مجموعة kubernetes وإعداد القواعد لـ DNAT VIPs فقط لبودات المضيف قيد التشغيل؟ قد يكون هذا أيضًا وضعًا لـ kube-proxy ، على الرغم من ذلك ، مثل ... حسنًا .. أنا لست جيدًا في الأسماء ... - proxy-mode = iptables-to-node-pods-only.

شكرا على الكتابة التفصيلية. حلك مثير للاهتمام ، وقضيت
قدرًا كبيرًا من الوقت اليوم أفكر فيه. للأسف كنت
عبرت إلى منطقة محددة للغاية لا تعمل بالمعنى العام.
لا تستطيع السحابة مثل GCE استخدام وضع بوابة IPVS بسبب التوجيه
شبكة الاتصال. حتى إذا نجحت البوابة ، فهي لا تدعم إعادة تعيين المنفذ ،
وهو ما يفعله Kubernetes ، لذلك لا يتم تطبيقه إلا إذا كان منفذ الخدمة == target
ميناء.

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

في الخميس ، 14 يناير 2016 الساعة 3:37 صباحًا ، كتب qoke [email protected] :

thockin https://github.com/thockin أعتذر عن الاستجابة الطويلة ، أنا
أردنا تغطية كلتا الطريقتين ، حاولنا حل هذه المشكلة حتى يتمكن الآخرون من ذلك
فهم التحديات التي واجهناها مع كليهما.

كخلفية صغيرة ، تطبيقنا الرئيسي هو أداء عالي جدًا
منصة DNS الذكية (أي أنها تحتاج إلى UDP وتحتاج إلى ما لا يقل عن 100 ألف +
الطلبات / ثانية لكل جراب) ، والتطبيق الداعم لها في وكيل SNI
الذي يحتاج إلى رؤية عنوان IP الحقيقي للعملاء (هذا سدادة عرض لـ
نحن). لم نرغب في استخدام أساليب مختلفة للشبكات المختلفة
التطبيقات ، لذلك قررنا التوحيد القياسي على طريقة شبكة واحدة لـ
الكل ، واخترنا استخدام IPVS للأسباب التي ذكرتها أعلاه
(الأداء / الاستقرار / المرونة / الغرض بناء SLB) ، لكن يمكنك ذلك
ربما تخترق شيئًا ما معًا باستخدام iptables فقط على طول هذه الأسطر
جدا. نحن نستخدم vxlan (سريع ، سهل ، يعمل بين المواقع) ولكن كلاهما
يجب أن تعمل الطرق أيضًا مع GRE / VXLAN مع OVS أو مع الطبقة القياسية 2
الشبكة المضيفة أيضًا (على افتراض أن جميع مضيفيك على نفس شبكة L2).

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

لقد حاولنا استخدام نموذجين لمعالجة هذا:

الطريقة الأولى التي جربناها كانت طبقتين من الشخصيات المهمة. كبار الشخصيات الخارجية (1 لكل
service) ، والتي توزع حركة المرور عبر العقد (بناءً على عدد pod لـ
تلك الخدمة على العقدة) ، ثم الشخصيات المهمة الداخلية (التي تعمل على العقدة
مع القرون) ، والتي توزع الحمل داخل العقد (عادةً بالتساوي
عبر القرون). كان الحد من هذا النموذج هو أن العقد الخارجية تعمل
يحتاج كبار الشخصيات إلى تشغيل مساحتين مختلفتين لأسماء الشبكة ، أو تشغيل مساحاتهم الخاصة
العقد المادية. الشيء الجميل مع IPVS في وضع DSR (إرجاع مباشر للخادم)
الوضع هو أنه لا يحتاج إلى رؤية حركة العودة ، يذهب المرور:

المستهلك >> (فوق L3) >> عقدة VIP خارجية >> (1) >> عقدة VIP داخلية >>
(2) >> حاوية >> (بأي طريقة تريدها) >> المستهلك

(1) IPVS (في وضع DSR) على المضيف مع VIP خارجي يختار عقدة إلى
إرسال حركة المرور إلى ("خادم حقيقي" بمصطلحات IPVS) ، وتغيير DST MAC فقط
عنوان الحزمة (على سبيل المثال ، تصل حزمة IP دون تغيير عند العقدة k8s). يتم تحميلها
أرصدة عبر العقد بناءً على عدد الكبسولات التي تعمل على هذه الخدمة
العقدة.
(2) IPVS (أيضًا في وضع DSR) على تحميل عقدة k8s يوازن حركة المرور عبر
القرون (عبر veths إلى العقدة). تنتقل الردود من الحاويات (TCP و UDP)
يعود مباشرة إلى مستهلك الخدمة.

الجانب الإيجابي لهذا النموذج ، هو أنه كان من السهل حقًا البدء و
كان من السهل جدًا إدارة مجموعة القواعد. الجانب السلبي لهذا النموذج هو أنه
يركز على جميع طلبات الخدمة لدينا (ولكن ليس الردود) من خلال أ
عدد العقد التي تشغل الشخصيات المهمة الخارجية. نحن نحب "لا شيء مشترك" ، لذا
أدخل الإصدار 2:

النموذج الثاني هو الآن ترفيهي هو طبقة واحدة من الشخصيات المهمة مع
تكوين أكثر ذكاءً لـ IPVS و iptables.

المستهلك >> أي عقدة / عقدة محلية >> (1) >> حاوية >> (بأي طريقة أنت
تريد) >> المستهلك
أو قد ينتقل إلى عقدة أخرى:
المستهلك >> أي عقدة / عقدة محلية >> (1) >> عقدة بعيدة >> (2) >> حاوية

(بأي طريقة تريدها) >> المستهلك

(1) تصل حركة المرور إلى VIP الأساسي ، حيث يتم تحميل حركة المرور بشكل متوازن عبر جميع البودات في
الكتلة.
(2) حركة المرور تصل إلى VIP الثانوي ، يتم تحميل حركة المرور بشكل متوازن فقط عبر الكل
القرون المحلية. يتم استخدام VIP الثانوي هذا فقط لحركة المرور القادمة من
مضيفون آخرون على الشبكة (إنها FWMARK VIP). نحن نحتفل حركة المرور القادمة
أي واجهة خارجية مع FWMARK = 1234 ، وهذا يفرض حركة المرور للذهاب
إلى مجموعة قواعد مختلفة تمنع الحلقات بين العقد.

يحتوي VIP الأساسي على قائمة بالقرون المحلية والمضيفين البعيدين مع القرون (مع
الوزن هو 100 لكل قرون محلية ، و 100 * عدد القرون لـ
العقد البعيدة). لذلك على سبيل المثال ، إذا كانت 3 حاضنات تعمل محليًا على العقدة A ، و
هناك نوعان من البودات تعمل على nodeB ، ستبدو مجموعة القواعد على العقدة A
هذه:

Prot LocalAddress: Port Scheduler Flags
-> RemoteAddress: Port Forward Weight ActiveConn InActConn
TCP service.ip.address: 0 rr المستمر 360
-> pod1.on.nodeA.ip: 80 طريق 100 0 0
-> pod2.on.nodeA.ip: 80 طريق 100 0 0
-> pod2.on.nodeA.ip: 80 طريق 100 0 0
-> interfaceip.of.nodeB: 80 طريق 200 0 0
FWM 1234 ص
-> pod1.on.nodeA.ip: 80 طريق 100 0 0
-> pod2.on.nodeA.ip: 80 طريق 100 0 0
-> pod3.on.nodeA.ip: 80 طريق 100 0 0

ومع ذلك ، في nodeB ، سيبدو تكوين IPVS مختلفًا بعض الشيء لأنه
يحتوي على وحدتين محليتين فقط ، وثلاثة قرون بعيدة على العقدة أ:

Prot LocalAddress: Port Scheduler Flags
-> RemoteAddress: Port Forward Weight ActiveConn InActConn
TCP service.ip.address: 0 rr المستمر 360
-> pod1.on.nodeB.ip: 80 طريق 100 0 0
-> pod2.on.nodeB.ip: 80 طريق 100 0 0
-> interfaceip.of.nodeA: 80 طريق 300 0 0
FWM 1234 ص
-> pod1.on.nodeB.ip: 80 طريق 100 0 0
-> pod2.on.nodeB.ip: 80 طريق 100 0 0

هناك طريقة أخرى تتمثل في تبديل FWMARKs ، واستخدام iptables
FWMARK أي شيء في واجهات veth + (تطابق حرف البدل) ولديه FWMARK
مطابقة تستخدم فقط لموازنة الحمل المحلي.

والنتيجة النهائية هي أكثر الشبكات المباشرة ، دون الحاجة إلى المركزية
طلب المعالجة / التوجيه حتى المقاييس أفضل بكثير. الجانب السلبي هو بعض
ذكاء إضافي عند إنشاء قواعد IPVS.

-
قم بالرد على هذا البريد الإلكتروني مباشرة أو قم بعرضه على GitHub
https://github.com/kubernetes/kubernetes/issues/3760#issuecomment -171619663
.

أعتقد أن تجربة الوضع iptables-to-node-pods-only ستكون ممتعة ،
ولكن لديها الكثير من التموج. احتمال عدم التوازن هو حقيقي جدا و
على الأقل سيحتاج مراقب الخدمة إلى معرفة كيفية برمجة
موازنات التحميل الخارجية.

يوم الخميس ، 14 كانون الثاني (يناير) 2016 ، الساعة 3:59 مساءً ، Mikaël Cluseau [email protected]
كتب:

من جانبي ، مع الفانيلا (في وضع vxlan) لإدارة شبكة الحاويات الخاصة بي ، أنا
استخدم kube-proxy (في وضع iptables وليس التنكر) + flannel في ملف
مساحة الاسم على عقد التوجيه الخاصة بي. الطلبات الخارجية DNATed للخدمة
عناوين IP ثم إعادة توجيهها عبر مساحة الاسم باستخدام وكيل kube. لم أفعل
تم إجراء اختبار مجموعة جهاز التوجيه النشط / النشط ، لكن هذا الإعداد يسمح لي بالاحتفاظ به
عنوان IP الخارجي. أذكرها FWIW ، لكنني أفهم أنها ليست "الأكثر"
التواصل المباشر ".

أفهم أنه إذا تمكنت kube-proxy من إدارتها ، فسيكون ذلك رائعًا ، لكن
بالنظر إلى احتياجاتك الخاصة وخاصة حقيقة أن موازنة التحميل
موجود بالفعل خارج kube-proxy ، فهل من المنطقي كتابة رمز للعميل
iptables-rules manager يراقب حالة مجموعة kubernetes وإعدادها
القواعد الخاصة بـ DNAT VIPs فقط إلى حاضنات المضيف قيد التشغيل؟ هذا ممكن
يكون أيضًا وضعًا لـ kube-proxy ، على الرغم من ذلك ، مثل ... حسنًا .. أنا لست جيدًا في
أسماء ... - proxy-mode = iptables-to-node-pods-only.

-
قم بالرد على هذا البريد الإلكتروني مباشرة أو قم بعرضه على GitHub
https://github.com/kubernetes/kubernetes/issues/3760#issuecomment -171821603
.

thockin هل تقصد ما إذا كانت

أعتقد أنه يمكنني محاولة تنفيذ شيء من هذا القبيل غدًا: وضع "iptables-to-node-pods-only" في kube-proxy ، بالإضافة إلى Contrib / ip-route-elb الذي يحافظ على جدول توجيه Linux مع مسار واحد لكل خدمة ، مع الوزن المناسب لكل عقدة بناءً على عدد نقاط النهاية التي تمتلكها العقدة لخدمة معينة.

thockin هل تقصد وجود
موازن التحميل الخارجية "خارج نطاق وكيل kube ، حيث أنه يحتوي على مثيلات متعددة و LB خارجي
ربما يجب أن يكون المبرمج في وضع "رئيسي واحد". وبالتالي ، فإن السماح بوضع kube-proxy "iptables-to-node-
pods-only "هي الخطوة الأولى فقط من عملية من خطوتين.

يجب أن يكون "الوكيل فقط للقرون المحلية" هو الخطوة 2 من العملية. الخطوة 1
يجب تغيير وحدة تحكم الخدمة لإرسال موازين التحميل فقط
إلى العقد التي لها خلفية خلفية واحدة أو أكثر لخدمة معينة. تلك الخطوة
من المحتمل أن يكون وحده معقولاً ، ولكنه سيتطلب الكثير من الاختبارات
تأكد من حصولنا عليها بشكل صحيح. أعتقد أننا نريد القيام بذلك في النهاية ،
على أي حال.

بمجرد الانتهاء من ذلك ، يمكننا التحدث عن جعل منافذ العقدة تفضل المحلية
الخلفية إن أمكن ، لكن هذه الخطوة تتطلب الكثير من الحذر
الفكر .. هل هذا يعني _ دائمًا_ (أي ، لا تختار أبدًا جهاز تحكم عن بعد
الخلفية إذا كانت هناك واحدة محلية متوفرة) أم احتمالية؟ هل نفعل
أنه من خلال نفس منفذ العقدة (ستحصل العقد المختلفة جدًا
سلوكيات مختلفة) أو هل نخصص منفذًا مختلفًا يتم استخدامه
إذا وفقط إذا كانت هذه العقدة بها 1 أو أكثر من الخلفيات الخلفية؟ كيف نتعامل مع
مشكلة عدم التوازن؟

أعتقد أنه يمكنني محاولة تنفيذ شيء من هذا القبيل: وضع "iptables-to-node-pods-only" في kube-proxy ،
بالإضافة إلى Contrib / ip-route-elb الذي سيحافظ على جدول توجيه Linux بمسار واحد لكل خدمة ، بالوزن المناسب
لكل عقدة بناءً على عدد نقاط النهاية التي تمتلكها العقدة لخدمة معينة.

إذا كان ELB يدعم الأوزان ، فسيعمل بشكل أفضل في بعض النواحي من
GCE ، التي لا تفعل ذلك. هذا جيد ، أنا فقط لا أعتقد أنه يدعم
الأوزان. لا أعتقد أنه يمكن أن يكون مساهمة ، رغم ذلك - إنها جميلة
جزء أساسي من النظام.

في 16/01/2016 05:19 صباحًا ، كتب تيم هوكين:

يجب أن يكون "الوكيل فقط للقرون المحلية" هو الخطوة 2 من العملية. الخطوة 1
يجب تغيير وحدة تحكم الخدمة لإرسال موازين التحميل فقط
إلى العقد التي لها خلفية خلفية واحدة أو أكثر لخدمة معينة. تلك الخطوة
من المحتمل أن يكون وحده معقولاً ، ولكنه سيتطلب الكثير من الاختبارات
تأكد من حصولنا عليها بشكل صحيح. أعتقد أننا نريد القيام بذلك في النهاية ،
على أي حال.

منطقي.

بمجرد الانتهاء من ذلك ، [...]

لذا دعنا نرى ما إن يتم ذلك :-)

إذا كان ELB يدعم الأوزان ، فسيعمل بشكل أفضل في بعض النواحي من
GCE ، التي لا تفعل ذلك. هذا جيد ، أنا فقط لا أعتقد أنه يدعم
الأوزان.

نظرًا لأنه من الدليل وربما يكون لديك أكثر من 10x بلدي
خبرة في هذا النوع من الشبكات ، يجب أن أتجاهل تمامًا أي مشكلة.
يقول man ip-route:

           nexthop NEXTHOP
                  the nexthop of a multipath route.  NEXTHOP is a 

قيمة معقدة ببنائها الخاص المشابه لقوائم وسيطات المستوى الأعلى:

                          via [ FAMILY ] ADDRESS - is the nexthop 

جهاز التوجيه.

                          dev NAME - is the output device.

                          weight NUMBER - is a weight for this 

عنصر لمسار متعدد المسارات يعكس عرض النطاق الترددي النسبي أو جودته.

لا أعتقد أنه يمكن أن يكون مساهمة ، رغم ذلك - إنها جميلة
جزء أساسي من النظام.

نظرًا لأن الحرف "E" يشير إلى "خارجي" ، فقد شعرت أنه يمكن أن يبدأ من هناك ،
على الأقل للحصول على بعض التعليمات البرمجية لدعم الأفكار.

يوم الجمعة ، 15 كانون الثاني (يناير) 2016 الساعة 2:55 مساءً ، ميكائيل كلوسو
كتب [email protected] :

في 16/01/2016 05:19 صباحًا ، كتب تيم هوكين:

يجب أن يكون "الوكيل فقط للقرون المحلية" هو الخطوة 2 من العملية. الخطوة 1
يجب تغيير وحدة تحكم الخدمة لإرسال موازين التحميل فقط
إلى العقد التي لها خلفية خلفية واحدة أو أكثر لخدمة معينة. تلك الخطوة
من المحتمل أن يكون وحده معقولاً ، ولكنه سيتطلب الكثير من الاختبارات
تأكد من حصولنا عليها بشكل صحيح. أعتقد أننا نريد القيام بذلك في النهاية ،
على أي حال.

منطقي.

لقد فكرت أكثر في هذا اليوم ، لا أعتقد أنه سيكون صعبًا للغاية.
فقط متوسط ​​الصعب.

بمجرد الانتهاء من ذلك ، [...]

لذا دعنا نرى ما إن يتم ذلك :-)

عادل بما فيه الكفاية ، أود فقط أن أعرف إلى أين ستتم مجموعة من التغييرات :)

إذا كان ELB يدعم الأوزان ، فسيعمل بشكل أفضل في بعض النواحي من
GCE ، التي لا تفعل ذلك. هذا جيد ، أنا فقط لا أعتقد أنه يدعم
الأوزان.

نظرًا لأنه من الدليل وربما يكون لديك أكثر من 10x بلدي
خبرة في هذا النوع من الشبكات ، يجب أن أتجاهل تمامًا أي مشكلة.
يقول man ip-route:

نيكستوب نيكستوب
nexthop لمسار متعدد المسارات. NEXTHOP هو ملف
قيمة معقدة ببنائها الخاص المشابه لقوائم وسيطات المستوى الأعلى:

عبر [العائلة] العنوان - هو nexthop
جهاز التوجيه.

ديف NAME - هو جهاز الإخراج.

الوزن NUMBER - هو وزن لهذا
عنصر لمسار متعدد المسارات يعكس عرض النطاق الترددي النسبي أو جودته.

لكننا لا نستخدم حقًا مفهوم لينكس لتوجيه IP. لا شيء من
تطبيقات LB التي أعرف استخدامها ، على أي حال. يستخدم GCE سحابة Google
الموازن ، الذي لا يحتوي على أوزان. لا أعرف هو Amazon ELB
هل.

لا أعتقد أنه يمكن أن يكون مساهمة ، رغم ذلك - إنها جميلة
جزء أساسي من النظام.

نظرًا لأن الحرف "E" يشير إلى "خارجي" ، فقد شعرت أنه يمكن أن يبدأ من هناك ،
على الأقل للحصول على بعض التعليمات البرمجية لدعم الأفكار.

بالتأكيد ، يمكننا البدء في المساهمة :)

أيضًا ، إذا كنت ترغب في متابعة هذا الأمر ، فيجب عليك فتح خطأين ، شيء مثل:

1) يجب أن تستهدف موازنات التحميل لإحدى الخدمات العقد التي تستهدف بالفعل فقط
لديك خلفية لهذه الخدمة

2) للحفاظ على عنوان IP للعميل عبر موازنات التحميل ، يجب على kube-proxy
تفضل دائمًا الخلفية المحلية إذا كانت موجودة (xref # 1)

ثم شرح النية والاتجاه

في يوم الجمعة ، 15 كانون الثاني (يناير) 2016 الساعة 5:11 مساءً ، كتب تيم هوكين [email protected] :

يوم الجمعة ، 15 كانون الثاني (يناير) 2016 الساعة 2:55 مساءً ، ميكائيل كلوسو
كتب [email protected] :

في 16/01/2016 05:19 صباحًا ، كتب تيم هوكين:

يجب أن يكون "الوكيل فقط للقرون المحلية" هو الخطوة 2 من العملية. الخطوة 1
يجب تغيير وحدة تحكم الخدمة لإرسال موازين التحميل فقط
إلى العقد التي لها خلفية خلفية واحدة أو أكثر لخدمة معينة. تلك الخطوة
من المحتمل أن يكون وحده معقولاً ، ولكنه سيتطلب الكثير من الاختبارات
تأكد من حصولنا عليها بشكل صحيح. أعتقد أننا نريد القيام بذلك في النهاية ،
على أي حال.

منطقي.

لقد فكرت أكثر في هذا اليوم ، لا أعتقد أنه سيكون صعبًا للغاية.
فقط متوسط ​​الصعب.

بمجرد الانتهاء من ذلك ، [...]

لذا دعنا نرى ما إن يتم ذلك :-)

عادل بما فيه الكفاية ، أود فقط أن أعرف إلى أين ستتم مجموعة من التغييرات :)

إذا كان ELB يدعم الأوزان ، فسيعمل بشكل أفضل في بعض النواحي من
GCE ، التي لا تفعل ذلك. هذا جيد ، أنا فقط لا أعتقد أنه يدعم
الأوزان.

نظرًا لأنه من الدليل وربما يكون لديك أكثر من 10x بلدي
خبرة في هذا النوع من الشبكات ، يجب أن أتجاهل تمامًا أي مشكلة.
يقول man ip-route:

نيكستوب نيكستوب
nexthop لمسار متعدد المسارات. NEXTHOP هو ملف
قيمة معقدة ببنائها الخاص المشابه لقوائم وسيطات المستوى الأعلى:

عبر [العائلة] العنوان - هو nexthop
جهاز التوجيه.

ديف NAME - هو جهاز الإخراج.

الوزن NUMBER - هو وزن لهذا
عنصر لمسار متعدد المسارات يعكس عرض النطاق الترددي النسبي أو جودته.

لكننا لا نستخدم حقًا مفهوم لينكس لتوجيه IP. لا شيء من
تطبيقات LB التي أعرف استخدامها ، على أي حال. يستخدم GCE سحابة Google
الموازن ، الذي لا يحتوي على أوزان. لا أعرف هو Amazon ELB
هل.

لا أعتقد أنه يمكن أن يكون مساهمة ، رغم ذلك - إنها جميلة
جزء أساسي من النظام.

نظرًا لأن الحرف "E" يشير إلى "خارجي" ، فقد شعرت أنه يمكن أن يبدأ من هناك ،
على الأقل للحصول على بعض التعليمات البرمجية لدعم الأفكار.

بالتأكيد ، يمكننا البدء في المساهمة :)

تكمن خطورة العلاقات العامة بدون مستندات في أنها في الاتجاه الخاطئ. إنها
أسهل بكثير لمراجعة شيء كاقتراح. سوف ألقي نظرة على الخاص بك
العلاقات العامة عندما تسنح لي الفرصة ، آمل قريبًا.
في 15 كانون الثاني (يناير) 2016 ، الساعة 7:02 مساءً ، كتب "Mikaël Cluseau" [email protected] :

هل يجوز فتح طلب سحب لـ (1) مباشرة بهذا الاسم والبعض
تفسيرات؟

-
قم بالرد على هذا البريد الإلكتروني مباشرة أو قم بعرضه على GitHub
https://github.com/kubernetes/kubernetes/issues/3760#issuecomment -172149777
.

لسوء الحظ ، لقد عبرت إلى منطقة محددة جدًا لا تعمل بالمعنى العام.
لا تستطيع السحابة مثل GCE استخدام وضع بوابة IPVS بسبب الشبكة الموجهة. حتى إذا نجحت البوابة ، فهي لا تدعم إعادة تعيين المنفذ ، وهو ما تفعله Kubernetes ، لذلك فهي تنطبق فقط إذا كان منفذ الخدمة == المنفذ الهدف.

على جانب البوابة ، يعمل هذا بشكل جيد عبر شبكة من الطبقة الثالثة (نستخدم التراكب) ، وعلى الرغم من أنه كان من الممكن أن نفلت بدون شبكة تراكب ، فقد قمنا ببنائها بهذه الطريقة لأننا أردنا أن يكون الأسلوب الذي نستخدمه محمولًا ويعمل في سحب الطرف الثالث (مثل GCE).

تصحيح القيد في وضع DSR هو أن منفذ الخدمة == المنفذ الهدف ، ولكن هذه ليست مشكلة حقًا ما لم يكن لديك تطبيقان _ في نفس الحاوية_ يحتاجان إلى التشغيل على نفس المنفذ (قضينا الكثير من الوقت في التفكير فيه هذا ، وبافتراض المبدأ التوجيهي "تطبيق واحد لكل حاوية" ، لم نتمكن من العثور على حالة استخدام واحدة لهذا). لدينا العديد من الحاويات تعمل جميعها على نفس العقد مع وجود خدمات بداخلها جميعها على نفس المنافذ ، وكلها حمولة متوازنة بشكل جيد. إذا كنت بحاجة إلى إعادة تعيين المنافذ (أحب أن أفهم الأسباب الحقيقية وراء السبب) ، يمكنك استخدام وضع IPVS NAT بدلاً من وضع "ROUTE".

يتمثل التحدي في جوهر kubernetes في إيجاد طرق للتعامل مع هذا النوع من المواقف بشكل عام أو الابتعاد عن طريقك وتمكينك من إعداده بنفسك. ربما يمكننا القيام بشيء ما باستخدام وضع encap ipvs ، لكنني لا أعرف الآثار المترتبة عليه.

ما فعلناه هو عام بقدر ما يمكننا صنعه (يعمل هنا ، يعمل في أمازون ، وأنا متأكد من أنه سيعمل في GCE عندما نحتاج إلى التوسع) ، مع القيد الوحيد على DSR هو أن التطبيق التشغيل في الحاوية / الحاوية يحتاج إلى أن يعمل على نفس المنفذ مثل الخدمة التي بعد الكثير من المناقشات الداخلية ، لم يتمكن أي شخص من العثور على سيناريو حيث سيكون هذا مقيدًا من منظور مكدس تطبيقات E2E.

الآن بعد قولي هذا ، إذا قمت بإزالة DSR (وضع مسار IPVS) من المعادلة ، واستخدمت "وضع NAT" الخاص بـ IPVS بدلاً من ذلك ، فيمكن إعادة تعيين المنافذ وستظل تستفيد من الحصول على ميزات / أداء IPVS / إلخ. الجانب السلبي الوحيد هو أن NAT تضيف بعض ضرائب الأداء ولكنها (أ) تدعم UDP ، و (ب) لا تزال سريعة للغاية مقارنة بحل مساحة المستخدم.

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

https://docs.google.com/presentation/d/1vv5Zszt4HDGbuyVlvOe76unHskxPuZQseQnarNbhQVc

تم تمكين DNAT على IPVS لإجراء مقارنة عادلة مع الحلين الآخرين (وهذا يعني أيضًا أن منفذ الخدمة يمكن أن يكون مختلفًا عن منفذ الخدمة المستهدف). قد تبدو أعباء العمل لدينا غير عادية إلى حد ما بالنسبة للبعض ، لكن أهداف الأداء لدينا ربما لا تختلف عن غيرها (على سبيل المثال ، الضغط على الأجهزة للحصول على كل ما يمكنك الحصول عليه).

شكرا!

لست متأكدًا من أين تأتي فكرة أن kube-proxy لا يعمل UDP - إنها
يفعل ذلك تمامًا ، على الرغم من أنه ربما ليس تمامًا (بدون اتصال يأتي
وصولا إلى المهلات).

يجدر أيضًا توضيح iptables (الجديد) kube-proxy مقابل مساحة المستخدمين
(قديم).

في يوم السبت ، 16 يناير 2016 الساعة 9:45 مساءً ، كتب qoke [email protected] :

thockin https://github.com/thockin في وقت سابق من الموضوع الذي طلبته
بعض أرقام الأداء. لن أسمي هذه المجموعة الأكثر شمولاً
من الاختبارات ، لكنني أتوقع أن HTTP هو أحد أحمال العمل الأكثر شيوعًا في
هنا بعض أرقام مقاعد أباتشي كنقطة بداية:

https://docs.google.com/presentation/d/1vv5Zszt4HDGbuyVlvOe76unHskxPuZQseQnarNbhQVc

تم تمكين DNAT على IPVS لإجراء مقارنة عادلة مع الحلين الآخرين
(هذا يعني أيضًا أن منفذ الخدمة يمكن أن يكون مختلفًا عن منفذ الخدمة المستهدف). لنا
قد تبدو أعباء العمل غير معتادة إلى حد ما بالنسبة للبعض ، ولكن أهداف الأداء لدينا
ربما لا تختلف عن الآخرين (أي الضغط على الأجهزة للجميع
يمكنك الحصول).

-
قم بالرد على هذا البريد الإلكتروني مباشرة أو قم بعرضه على GitHub
https://github.com/kubernetes/kubernetes/issues/3760#issuecomment -172293881
.

مكالمة جيدة على الوضع الجديد مقابل الوضع القديم - تم تدوينه وتحديثه.

أيضًا من جانب UDP للأشياء ، شكرًا لك على التوضيح ؛ لم أكن أعلم أن UDP كان مدعومًا بالكامل في kube-proxy حتى الآن. عندما جربنا لأول مرة kube-proxy مع UDP ، حصلنا على الكثير والكثير من حالات التوقف. لست متأكدًا من السبب ولكننا قمنا بزيادة المهلات وما زلنا نواجه مشكلات. كان علينا أن نجد حلاً سريعًا لذلك انتهى بنا الأمر إلى العمل حوله باستخدام IPVS بدلاً من تصحيحه. في ذلك الوقت ، كان يعمل فقط مع أعباء عمل منخفضة جدًا للحزمة في الثانية (أقل من 1k نقطة في الثانية) ولكننا لم نعد الاختبار مؤخرًا.

المشكلة الرئيسية مع iptables وأي خدمة UDP عالية السعر هي ملء جداول netfilter conntrack. حتى إذا قمت بزيادة حجم الاتصال إلى 1 مليون ، فإن بعض هجمات DDoS للمستخدم النهائي المصابة بالبرامج الضارة هي أنت أو تحاول استخدامك لهجوم تضخيم DNS ثم يملأ جدول الاتصال الخاص بك مرة أخرى. بشكل عام ، تتمثل أفضل الممارسات لخوادم DNS (أو أي خدمات UDP عالية المعدل) في تعطيل conntrack (باستخدام -j NOTRACK في الجدول الأولي) ، وإذا قمت بتعطيل conntrack ، فإن iptables NAT وفواصل الأشياء ذات الحالة (-m state).

بصرف النظر عن GIT repo ، ما هو أفضل مكان للبحث فيه قبل محاولة إنشاء وحدة / حزمة "k8s.io/kubernetes/pkg/proxy/ipvs"؟ أم أنه من الأفضل ترك هذا لشخص يعرف قاعدة الشفرة بشكل أفضل؟

أيضًا ، إذا كنت ترغب في أي معايير محددة ، فأخبرني بذلك وسأرى ما يمكنني فعله.

في 17/01/2016 ، الساعة 08:50 مساءً ، كتب قوك:

بصرف النظر عن GIT repo ، أين سيكون أفضل مكان للبحث فيه من قبل
هل تحاول إنشاء وحدة / حزمة "k8s.io/kubernetes/pkg/proxy/ipvs"؟

أعتقد أنه يمكنك البدء في المساهمة أيضًا.

FWIW ... لقد استخدمت قائمة الساعات ومتاجر undelta لعمل مستقل
binay يتفاعل مع حالة الكتلة في
https://github.com/kubernetes/kubernetes/pull/19755. إذا كانت المعلومات
في
https://github.com/kubernetes/kubernetes/pull/19755/files#diff -0becc97ac222c3f2838fbfe8446d5375R26
يكفي ، يجب عليك فقط تغيير المكالمة بضعة أسطر أدناه
(https://github.com/kubernetes/kubernetes/pull/19755/files#diff-0becc97ac222c3f2838fbfe8446d5375R44).

يرجى ملاحظة أنني أدعم فقط خدمات الكتلة IP في PoC هذا.

لسوء الحظ ، لقد عبرت إلى منطقة محددة جدًا لا تعمل بالمعنى العام.
لا تستطيع السحابة مثل GCE استخدام وضع بوابة IPVS بسبب الشبكة الموجهة. حتى لو نجحت البوابة ، فإنها لا تفعل ذلك
دعم إعادة تعيين المنفذ ، وهو ما يفعله Kubernetes ، لذلك لا ينطبق إلا إذا كان منفذ الخدمة == المنفذ الهدف.

على جانب البوابة ، يعمل هذا بشكل جيد عبر شبكة من الطبقة الثالثة (نستخدم تراكبًا) ، وعلى الرغم من أنه كان من الممكن أن نكون قد ابتعدنا
بدون شبكة تراكب ، قمنا ببنائها بهذه الطريقة لأننا أردنا أن يكون الأسلوب الذي نستخدمه قابلاً للنقل والعمل مع جهات خارجية
السحب (مثل GCE).

لست متأكدا كيف يمكن أن تعمل. المسارات الثابتة على مستوى الآلة لا تعمل
في GCE. ربما أفتقد بعض التقنيات التي طبقتها. أنا
أعترف بحرية أنني لست خبيرًا في هذا :)

تصحيح القيد هو أن منفذ الخدمة == المنفذ الهدف ، ولكن هذه ليست مشكلة حقًا ما لم يكن لديك تطبيقان في
نفس الحاوية التي يجب تشغيلها على نفس المنفذ (قضينا الكثير من الوقت في التفكير في هذا الأمر ، وافتراض "التطبيق الأول"
لكل حاوية "، لم نتمكن من العثور على حالة استخدام واحدة لهذا). لدينا العديد من الحاويات جميعها تعمل على نفس العقد
مع الخدمات بداخلها كلها على نفس المنافذ ، وكل الحمل متوازن بشكل جيد. باختصار ، النهج الذي نستخدمه لا يمنعك
من تشغيل خدمات متعددة على نفس المنافذ على نفس العقدة.

كما ينطبق أيضًا إذا كانت لديك إصدارات خلفية تعمل على تغيير الإصدارات (على سبيل المثال
الانتقال بين etcd1 و etcd2) أو أي حالة أخرى حيث
يحتاج منفذ الواجهة الخلفية فقط إلى أن يكون مختلفًا. المشكلة هي
يسمح Kubernetes بالتعبير عنه ، لذلك نحتاج إلى التأكد من الأشخاص
يمكن استخدامها بالفعل (أو إهمالها وموسوعة الحياة هي الميزة التي
يبدو غير مرجح).

يكمن التحدي في جوهر kubernetes في إيجاد طرق للتعامل مع هذا النوع من المواقف بشكل عام أو الابتعاد عن طريقك
وتمكينك من إعداده بنفسك. ربما يمكننا القيام بشيء ما باستخدام وضع encap ipvs ، لكنني لا أعرف الأداء
الآثار المترتبة عليه.

ما فعلناه هو عام بقدر ما يمكننا صنعه (يعمل هنا ، يعمل في أمازون ، وأنا متأكد من أنه سيعمل في
GCE عندما نحتاج إلى التوسيع) ، مع القيد الوحيد هو أن التطبيق الذي يعمل في الحاوية / الحاوية يحتاج> للتشغيل على نفس المنفذ مثل الخدمة التي بعد الكثير من المناقشات الداخلية ، لم يتمكن أي شخص من العثور على سيناريو أين
سيكون هذا مقيدًا من منظور مكدس تطبيقات E2E.

أنا حقا أريد أن أفهم كيف. هل لديك شيء أكثر خطوة بخطوة؟

أيضًا من جانب UDP للأشياء ، شكرًا لك على التوضيح ؛ لم أكن أعلم أن UDP كان مدعومًا بالكامل في kube-proxy حتى الآن.
عندما جربنا لأول مرة kube-proxy مع UDP ، حصلنا على الكثير والكثير من حالات التوقف. لست متأكدًا من السبب ولكننا قمنا بزيادة المهلات و
لا يزال لديه مشاكل. كان علينا أن نجد حلاً سريعًا لذلك انتهى بنا الأمر إلى العمل حوله باستخدام IPVS بدلاً من تصحيحه. في ال
الوقت الذي نجح فيه فقط لأعباء عمل منخفضة جدًا للحزمة في الثانية (أقل من 1k نقطة في الثانية) ولكننا لم نعد الاختبار مؤخرًا.

المشكلة الرئيسية مع iptables وأي خدمة UDP عالية السعر هي ملء جداول netfilter conntrack. حتى لو قمت بزيادة
حجم الاتصال يصل إلى 1 مليون ، ثم بعض هجمات DDoS للمستخدم النهائي المصابة بالبرامج الضارة هي أنت أو تحاول استخدامك لتضخيم DNS
هجوم ومن ثم تملأ طاولة conntrack الخاصة بك مرة أخرى. بشكل عام ، أفضل الممارسات لخوادم DNS (أو أي معدل مرتفع
خدمات UDP) هي تعطيل conntrack (باستخدام -j NOTRACK في الجدول الأولي) ، وإذا قمت بتعطيل conntrack و iptables NAT و
الاشياء ذات الحالة (الدولة -m) فواصل.

نعم ، إن NAT لـ UDP أمر مؤسف حقًا. العثور على non-conntrack
سيكون الحل رائعًا ، ولكن يجب أن ينطبق على الجميع
البيئات أو أن تكون معلمات من خلال النظام الأساسي (وهو أمر صعب في حد ذاته
طريق).

بصرف النظر عن GIT repo ، أين سيكون أفضل مكان للبحث قبل محاولة إنشاء ملف
"k8s.io/kubernetes/pkg/proxy/ipvs" وحدة / حزمة؟ أم أنه من الأفضل ترك هذا لشخص يعرف قاعدة الشفرة بشكل أفضل؟

فتحت مشكلة github حول IPVS ، لكنني كنت أستخدم masquerade (NAT)
الوضع لأنني لم أتمكن من العمل على GCE بدون (وبسبب
ميزة إعادة تعيين المنفذ). إذا أثار إعادة تعيين المنفذ أقل مثالية
وضع التوازن ، ربما يمكنني التعايش مع ذلك وتوثيقه فقط
كما.

يجب أن ننقل هذا القافلة إلى هناك - سوف يضيع هنا.

في 18/01/2016 الساعة 12:34 ظهرًا ، كتب تيم هوكين:

نعم ، إن NAT لـ UDP أمر مؤسف حقًا. العثور على non-conntrack
سيكون الحل رائعًا ، ولكن يجب أن ينطبق على الجميع
البيئات أو أن تكون معلمات من خلال النظام الأساسي (وهو أمر صعب في حد ذاته
طريق).

يمكن أن يعمل NAT عديم الحالة للحالة التي يوجد بها زوجان (pod ، port) في
أكثر خدمة واحدة (العديد من البودات لخدمة واحدة)؟

سيبدو هذا كالتالي:

{from: clientIP: clientPort، to: externalIP: externalPort} --- [proxy يختار مجموعة عشوائية] ---> {from: clientIP: clientPort، to: podIP: targetPort} ---> [تم التوجيه من خلال المضيف الصحيح ...]

في طريق العودة ، سيكون لجدار الحماية قاعدة تنص على وجود حزمة {من:
podIP: targetPort ، إلى: أي} يجب أن يكون SNATed إلى {من:
e xternalIP: externalPort ، to: unchanged}.

لتوضيحها بلهجة iptables:

iptables -t nat -N stateless-svc-in

iptables -t nat -N stateless-svc-out

iptables -t nat -A stateless-svc-in  -j DNAT -s 1.2.3.4  -p udp --dport 53 --to-destination 10.1.0.1 -m statistic --mode random --probability 0.3333

iptables -t nat -A stateless-svc-in  -j DNAT -s 1.2.3.4  -p udp --dport 53 --to-destination 10.2.0.1 -m statistic --mode random --probability 0.5

iptables -t nat -A stateless-svc-in  -j DNAT -s 1.2.3.4  -p udp --dport 53 --to-destination 10.2.0.2 -m statistic --mode random --probability 1

iptables -t nat -A stateless-svc-out -j SNAT -s 10.1.0.1 -p udp --sport 53 --to-source 1.2.3.4

iptables -t nat -A stateless-svc-out -j SNAT -s 10.2.0.1 -p udp --sport 53 --to-source 1.2.3.4

iptables -t nat -A stateless-svc-out -j SNAT -s 10.2.0.2 -p udp --sport 53 --to-source 1.2.3.4

لا أرى أين لا يعمل هذا عندما تأتي الحزمة من الخارج
الكتلة.

الطريقة التي يتم بها التعبير عن الخدمات في Kubernetes تسمح لحجرة واحدة أن تكون
يتصدرها أي عدد من الخدمات ، لذلك ينهار هذا - لا نعرف ماذا
إلى SNAT إلى.

يوم الأحد ، 17 يناير 2016 الساعة 6:13 مساءً ، Mikaël Cluseau [email protected]
كتب:

في 18/01/2016 الساعة 12:34 ظهرًا ، كتب تيم هوكين:

نعم ، إن NAT لـ UDP أمر مؤسف حقًا. العثور على non-conntrack
سيكون الحل رائعًا ، ولكن يجب أن ينطبق على الجميع
البيئات أو أن تكون معلمات من خلال النظام الأساسي (وهو أمر صعب في حد ذاته
طريق).

يمكن أن يعمل NAT عديم الحالة للحالة التي يوجد بها زوجان (pod ، port) في
أكثر خدمة واحدة (العديد من البودات لخدمة واحدة)؟

سيبدو هذا كالتالي:

{from: clientIP: clientPort، to: externalIP: externalPort} --- [proxy select
جراب عشوائي] ---> {from: clientIP: clientPort، to: podIP: targetPort} --->
[تم توجيهه عبر المضيف الصحيح ...]

في طريق العودة ، سيكون لجدار الحماية قاعدة تنص على وجود حزمة {من:
podIP: targetPort ، إلى: أي} يجب أن يكون SNATed إلى {من:
e xternalIP: externalPort ، to: unchanged}.

لتوضيحها بلهجة iptables:

iptables -t nat -N stateless-svc-in

iptables -t nat -N stateless-svc-out

iptables -t nat -A stateless-svc-in -j DNAT -s 1.2.3.4 -p udp --dport 53
--to-destination 10.1.0.1 -m statistic --mode random --probability 0.3333

iptables -t nat -A stateless-svc-in -j DNAT -s 1.2.3.4 -p udp --dport 53
--to-destination 10.2.0.1 -m statistic --mode random --probability 0.5

iptables -t nat -A stateless-svc-in -j DNAT -s 1.2.3.4 -p udp --dport 53
--to-destination 10.2.0.2 -m statistic --mode random --probability 1

iptables -t nat -A stateless-svc-out -j SNAT -s 10.1.0.1 -p udp --sport 53
--to-source 1.2.3.4

iptables -t nat -A stateless-svc-out -j SNAT -s 10.2.0.1 -p udp --sport 53
--to-source 1.2.3.4

iptables -t nat -A stateless-svc-out -j SNAT -s 10.2.0.2 -p udp --sport 53
--to-source 1.2.3.4

لا أرى أين لا يعمل هذا عندما تأتي الحزمة من الخارج
الكتلة.

-
قم بالرد على هذا البريد الإلكتروني مباشرة أو قم بعرضه على GitHub
https://github.com/kubernetes/kubernetes/issues/3760#issuecomment -172408290
.

في 18/01/2016 03:31 مساءً ، كتب تيم هوكين:

تسمح طريقة التعبير عن الخدمات في Kubernetes بحجرة واحدة
أن تكون
يتصدرها أي عدد من الخدمات ، لذلك ينهار هذا - لا نعرف
ماذا او ما
إلى SNAT إلى.

لهذا السبب اقتصرت الحالة على واحد بأطراف (الجملة الأولى :-)).
أحاول فقط أن أرسم خطاً حول ما يمكن فعله أم لا.

بالتأكيد ، لدي الوظيفة المؤسفة للإشارة إلى سبب عدم وجود ملفات
حل عام بما فيه الكفاية :(

يوم الأحد ، 17 يناير 2016 الساعة 8:34 مساءً ، Mikaël Cluseau [email protected]
كتب:

في 18/01/2016 03:31 مساءً ، كتب تيم هوكين:

تسمح طريقة التعبير عن الخدمات في Kubernetes بحجرة واحدة
أن تكون
يتصدرها أي عدد من الخدمات ، لذلك ينهار هذا - لا نعرف
ماذا او ما
إلى SNAT إلى.

لهذا السبب اقتصرت الحالة على واحد بأطراف (الجملة الأولى :-)).
أحاول فقط أن أرسم خطاً حول ما يمكن فعله أم لا.

-
قم بالرد على هذا البريد الإلكتروني مباشرة أو قم بعرضه على GitHub
https://github.com/kubernetes/kubernetes/issues/3760#issuecomment -172421828
.

في 18/01/2016 03:46 مساءً ، كتب تيم هوكين:

بالتأكيد ، لدي الوظيفة المؤسفة للإشارة إلى سبب عدم وجود ملفات
حل عام بما فيه الكفاية :(

نعم ... ولكن الأسئلة الشائعة. يمكننا أيضًا أن نضع ، في مكان ما ، "if len (services)
== 1 {تنفيذ الحالة} else {تنفيذ الحالة} ". ولكن هذا ممكن
تبدو وكأنها فوضى للمبتدئين. يمكنني أيضًا أن أكون مساهمًا / إلفًا / شيءًا ...

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

يوم الأحد ، 17 يناير 2016 الساعة 8:51 مساءً ، Mikaël Cluseau [email protected]
كتب:

في 18/01/2016 03:46 مساءً ، كتب تيم هوكين:

بالتأكيد ، لدي الوظيفة المؤسفة للإشارة إلى سبب عدم وجود ملفات
حل عام بما فيه الكفاية :(

نعم ... ولكن الأسئلة الشائعة. يمكننا أيضًا أن نضع ، في مكان ما ، "if len (services)
== 1 {تنفيذ الحالة} else {تنفيذ الحالة} ". ولكن هذا ممكن
تبدو وكأنها فوضى للمبتدئين. يمكنني أيضا أن أكون
مساهم / إلبس / شيء ...

-
قم بالرد على هذا البريد الإلكتروني مباشرة أو قم بعرضه على GitHub
https://github.com/kubernetes/kubernetes/issues/3760#issuecomment -172425404
.

في 18/01/2016 04:07 مساءً ، كتب تيم هوكين:

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

أوافق ، لكن ليس لدي فكرة أفضل في الوقت الحالي :-(

حتى SDN المصمم لهذا الغرض سيحتاج إلى تتبع شيء أفترضه. يمكن
حلول قائمة على الملصقات مثل MPLS ..؟

في 18/01/2016 ، 04:18 مساءً ، كتب ميكائيل كلوسو:

حتى SDN المصمم لهذا الغرض سيحتاج إلى تتبع شيء أفترضه.
ربما الحلول القائمة على التسمية مثل MPLS ..؟

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

"" "

• خارجي إلى مضيف: {from: clientIP: clientPort، to: externalIP: servicePort} ----- [ELB
  يختار نقطة نهاية واحدة] --------> {from: clientIP: clientPort ، إلى:
  endpointServiceIP: podPort} -> التوجيه إلى المضيف

• المضيف إلى pod: {from: clientIP: clientPort، to: endpointServiceIP: podPort} - [قياسي
  التوجيه إلى الحاويات] -> {from: clientIP: clientPort ، إلى:
  endpoint ServiceIP: podPort }

• Pod to host: {from: endpointServiceIP: podPort، to: clientIP: clientPort}
  -------- [توجيه قياسي إلى أجهزة التوجيه] -----> {من:
  endpointServiceIP: podPort، to: clientIP: clientPort} - مضيف خارجي: {from: endpointServiceIP: podPort، to: clientIP: clientPort} -------- [ELB
  عودة SNAT] ------------------> {from: clientIP: clientPort ، إلى:
  e xternalIP: servicePort } "`

تعتقد أنه يمكننا أن نجعل هذا العمل بالنسبة للكتل IPs أيضًا.
"" "

لا يمكنني أن أجعل هذا يعمل على GCE ، ولست متأكدًا من AWS - فهناك ملف
يتوفر عدد محدود من المسارات الثابتة.

أتساءل عما إذا كان بإمكاني القيام بذلك عن طريق ربط نطاقي IP معًا في واحد
طريق. هناك الكثير من عناوين IP التي يجب إنفاقها ، لكنني أعتقد أنها مهمة فقط لـ UDP.
سآخذ لتجربته.

تحرير: جربته ولم أستطع أن أجعله يعمل ، لكنني أفتقد شيئًا ما.
سيتعين علينا إضافة / إزالة عناوين IP في الحاويات استجابة للخدمات القادمة
ويذهب ، لكنني لم أتمكن من إنشاء عناوين IP "إضافية" في حاوية تعمل (يمكن ذلك
ping ولكن ليس TCP أو UDP ، لست متأكدًا من السبب).

سأحاول مرة أخرى في وقت ما.

يوم الأحد ، 17 يناير 2016 الساعة 10:22 مساءً ، Mikaël Cluseau [email protected]
كتب:

في 18/01/2016 ، 04:18 مساءً ، كتب ميكائيل كلوسو:

حتى SDN المصمم لهذا الغرض سيحتاج إلى تتبع شيء أفترضه.
ربما الحلول القائمة على التسمية مثل MPLS ..؟

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

"" "

• خارجي إلى مضيف: {from: clientIP: clientPort، to: externalIP: servicePort}
  ----- [ELB
  يختار نقطة نهاية واحدة] --------> {from: clientIP: clientPort ، إلى:
  endpointServiceIP: podPort} -> التوجيه إلى المضيف

• المضيف إلى pod: {from: clientIP: clientPort، to: endpointServiceIP: podPort}
  --[اساسي
  التوجيه إلى الحاويات] -> {from: clientIP: clientPort ، إلى:
  endpoint ServiceIP: podPort }

• Pod to host: {from: endpointServiceIP: podPort، to: clientIP: clientPort}
  -------- [توجيه قياسي إلى أجهزة التوجيه] -----> {من:
  endpointServiceIP: podPort ، إلى: clientIP: clientPort} - المضيف لـ
  خارجي: {from: endpointServiceIP: podPort، to: clientIP: clientPort}
  -------- [ELB
  عودة SNAT] ------------------> {from: clientIP: clientPort ، إلى:
  e xternalIP: servicePort } "`

تعتقد أنه يمكننا أن نجعل هذا العمل بالنسبة للكتل IPs أيضًا.

-
قم بالرد على هذا البريد الإلكتروني مباشرة أو قم بعرضه على GitHub
https://github.com/kubernetes/kubernetes/issues/3760#issuecomment-172438133
.

"" "

أحاول من جانبي الحصول على شيء (بشبكات نقية على مضيفي المحلي
في الوقت الراهن).

أحاول أسلوبًا يؤثر فيه على نطاقات IP للخدمة لمضيفي
تقليل عدد إدخالات التوجيه:

cli - elb - h1 - c1

| "--- ج 2

"--- h2 - c2

h1_ep_ip_ranges = (10.1.1.0/24 10.1.2.0/24)
h2_ep_ip_ranges = (10.1.3.0/24)

لا يوجد ping ATM (الحزم لا تمر عبر سلسلة PREROUTING ...) ، و
بحاجة إلى النوم. المزيد عن هذا غدًا ؛)

في 18/01/2016 06:28 مساءً ، كتب تيم هوكين:

لا يمكنني أن أجعل هذا يعمل على GCE ، ولست متأكدًا من AWS - فهناك ملف
يتوفر عدد محدود من المسارات الثابتة.

أتساءل عما إذا كان بإمكاني القيام بذلك عن طريق ربط نطاقي IP معًا في واحد
طريق. هناك الكثير من عناوين IP التي يجب إنفاقها ، لكنني أعتقد أنها مهمة فقط لـ UDP.
سآخذ لتجربته.

تحرير: جربته ولم أستطع أن أجعله يعمل ، لكنني أفتقد شيئًا ما.
سيتعين علينا إضافة / إزالة عناوين IP في الحاويات استجابة للخدمات القادمة
ويذهب ، لكنني لم أتمكن من إنشاء عناوين IP "إضافية" في حاوية تعمل (يمكن ذلك
ping ولكن ليس TCP أو UDP ، لست متأكدًا من السبب).

سأحاول مرة أخرى في وقت ما.

لقد ابتعدت قليلاً ، لكن شيئًا كان يجب أن أتوقع حدوثه.

لقد قمت بإعداد جراب مع 10.244.2.8/25 كواجهة رئيسية و 10.244.2.250/25
كواجهة "داخل الخدمة". كنت آمل أن أتمكن من إرسال UDP إلى
.250 وكشف الاستجابات ، لسنات لهم. لكن بالطبع ، إذا كان العميل
ليس في نفس / 25 (وهو لا يمكن أن يكون) يندمج المسار الافتراضي ، والذي
يأتي من عنوان .8. يؤكد tcpdump أن الردود تأتي من .8
عند استخدام UDP.

أنا مرة أخرى في مكان لست متأكدًا من كيفية إنجاحه. سوف يفكر
المزيد عن ذلك.

يوم الاثنين ، 18 يناير 2016 ، الساعة 2:59 صباحًا ، Mikaël Cluseau [email protected]
كتب:

أحاول من جانبي الحصول على شيء (بشبكات نقية على مضيفي المحلي
في الوقت الراهن).

أحاول أسلوبًا يؤثر فيه على نطاقات IP للخدمة لمضيفي
تقليل عدد إدخالات التوجيه:

cli - elb - h1 - c1

| "--- ج 2

"--- h2 - c2

h1_ep_ip_ranges = (10.1.1.0/24 10.1.2.0/24)
h2_ep_ip_ranges = (10.1.3.0/24)

لا يوجد ping ATM (الحزم لا تمر عبر سلسلة PREROUTING ...) ، و
بحاجة إلى النوم. المزيد عن هذا غدًا ؛)

في 18/01/2016 06:28 مساءً ، كتب تيم هوكين:

لا يمكنني أن أجعل هذا يعمل على GCE ، ولست متأكدًا من AWS - فهناك ملف
يتوفر عدد محدود من المسارات الثابتة.

أتساءل عما إذا كان بإمكاني القيام بذلك عن طريق ربط نطاقي IP معًا في نطاق
غير مرتبطة
طريق. هناك الكثير من عناوين IP التي يجب إنفاقها ، لكنني أعتقد أنها مهمة فقط لـ UDP.
سآخذ لتجربته.

تحرير: جربته ولم أتمكن من إنجاحه ، لكنني في عداد المفقودين
شيئا ما.
سيتعين علينا إضافة / إزالة عناوين IP في الحاويات استجابة للخدمات القادمة
ويذهب ، لكنني لم أتمكن من إنشاء عناوين IP "إضافية" في حاوية تعمل (يمكن ذلك
ping ولكن ليس TCP أو UDP ، لست متأكدًا من السبب).

سأحاول مرة أخرى في وقت ما.

-
قم بالرد على هذا البريد الإلكتروني مباشرة أو قم بعرضه على GitHub
https://github.com/kubernetes/kubernetes/issues/3760#issuecomment -172497456
.

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

في يوم الاثنين ، 18 كانون الثاني (يناير) 2016 ، الساعة 9:50 مساءً ، كتب تيم هوكين [email protected] :

لقد ابتعدت قليلاً ، لكن شيئًا كان يجب أن أتوقع حدوثه.

لقد قمت بإعداد pod مع 10.244.2.8/25 كواجهة رئيسية و
10.244.2.250/25 كواجهة "أثناء الخدمة". كنت أتمنى أن أكون
يمكن إرسال UDP إلى .250 والكشف عن الردود ، إلى SNAT لهم. ولكن بالتأكيد،
إذا كان العميل ليس في نفس / 25 (وهو لا يمكن أن يكون) الافتراضي
يبدأ المسار ، والذي يأتي من العنوان .8. tcpdump يؤكد ذلك
تأتي الردود من .8 عند استخدام UDP.

أنا مرة أخرى في مكان لست متأكدًا من كيفية إنجاحه. سوف يفكر
المزيد عن ذلك.

يوم الاثنين ، 18 يناير 2016 ، الساعة 2:59 صباحًا ، Mikaël Cluseau [email protected]
كتب:

أحاول من جانبي الحصول على شيء (بشبكات نقية على مضيفي المحلي
في الوقت الراهن).

أحاول أسلوبًا يؤثر فيه على نطاقات IP للخدمة لمضيفي
تقليل عدد إدخالات التوجيه:

cli - elb - h1 - c1

| "--- ج 2

"--- h2 - c2

h1_ep_ip_ranges = (10.1.1.0/24 10.1.2.0/24)
h2_ep_ip_ranges = (10.1.3.0/24)

لا يوجد ping ATM (الحزم لا تمر عبر سلسلة PREROUTING ...) ، و
بحاجة إلى النوم. المزيد عن هذا غدًا ؛)

في 18/01/2016 06:28 مساءً ، كتب تيم هوكين:

لا يمكنني أن أجعل هذا يعمل على GCE ، ولست متأكدًا من AWS - فهناك ملف
يتوفر عدد محدود من المسارات الثابتة.

أتساءل عما إذا كان بإمكاني القيام بذلك عن طريق ربط نطاقي IP معًا في نطاق
غير مرتبطة
طريق. هناك الكثير من عناوين IP التي يجب إنفاقها ، لكنني أعتقد أنها مهمة فقط لـ UDP.
سآخذ لتجربته.

تحرير: جربته ولم أتمكن من إنجاحه ، لكنني في عداد المفقودين
شيئا ما.
سيتعين علينا إضافة / إزالة عناوين IP في الحاويات استجابة للخدمات
آت
وتذهب ، لكنني لم أتمكن من إنشاء عناوين IP "إضافية" في حاوية تعمل (هي
استطاع
ping ولكن ليس TCP أو UDP ، لست متأكدًا من السبب).

سأحاول مرة أخرى في وقت ما.

-
قم بالرد على هذا البريد الإلكتروني مباشرة أو قم بعرضه على GitHub
https://github.com/kubernetes/kubernetes/issues/3760#issuecomment -172497456
.

هذا أمر مؤسف: - (لست متأكدًا من السبب بالمناسبة. سأحاول شيئًا ما مع MPLS بعد ذلك ، أريد أن أتعلمه على أي حال.

إذا كان لديك 2 خلفية للخدمة وتريد إرسال أكثر من واحدة
حزمة ، تحتاج إلى تتبع التدفقات بطريقة ما ، أليس كذلك؟ ام انك
على افتراض أنه من الآمن رش الحزم في خلفيات مختلفة؟

يوم الأربعاء 20 كانون الثاني (يناير) 2016 الساعة 12:24 ظهرًا ، Mikaël Cluseau [email protected]
كتب:

هذا مؤسف: - (لست متأكدًا لماذا بالمناسبة. سأحاول شيئًا ما
MPLS إذن ، أريد أن أتعلمها على أي حال.

-
قم بالرد على هذا البريد الإلكتروني مباشرة أو قم بعرضه على GitHub
https://github.com/kubernetes/kubernetes/issues/3760#issuecomment -173348973
.

لقد افترضت نوعًا ما أنه بالنسبة لأحمال عمل UDP ، نعم. كما يمكن أن يكون اختياريًا أن تصبح عديم الحالة حتى بالنسبة لـ UDP. qoke أي تعليق على هذا؟

أيضًا ، يمكننا استخدام أشياء مثل تجزئة عنوان IP للعميل لجعل التدفق أكثر استقرارًا بينما لا يزال متوازنًا (لا أعرف ما إذا كان بإمكاننا تسمية ذلك "نوعًا من التتبع" :-)).

MikaelCluseau نستخدم سلوك IPVS الافتراضي ، والذي يقوم ببعض "لزوجة" UDP خفيفة الوزن جدًا ...

لجدولة مخططات بيانات UDP ، يسجل موازن تحميل IPVS جدولة مخطط بيانات UDP بمهلة قابلة للتكوين ، ومهلة UDP الافتراضية هي 300 ثانية. قبل انقضاء مهلات اتصال UDP ، سيتم توجيه كافة مخططات بيانات UDP من نفس المقبس (البروتوكول وعنوان IP والمنفذ) إلى نفس الخادم.

- مقتبس من http://kb.linuxvirtualserver.org/wiki/IPVS

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

نقوم بموازنة الكثير من حركة مرور DNS و RADIUS - يقع DNS عادةً في الفئة الأولى (الكثير جدًا من العملاء ، أو العملاء الذين لديهم الكثير من منافذ المصدر) ، وعادةً ما يقع RADIUS في الفئة اللاحقة (عدد قليل من العملاء ، الكثير من الحزم كلها من نفس IP / المنفذ). بدلاً من استخدام تجزئة عديمة الحالة لـ RADIUS ، قررنا بدلاً من ذلك توزيع منافذ المصدر بشكل عشوائي للحصول على انتشار متساوٍ.

بعد قراءة الموضوع بالكامل ، ما زلت لا أستطيع معرفة ما إذا كان تنشيط وضع iptables لـ kube-proxy يجب أن يحل مشكلة إخفاء عناوين IP الخارجية (# 10921) أم لا. لقد قمنا بتمكين وضع iptables مع v1.1 كما هو مقترح هنا ولكننا ما زلنا نرى عناوين IP من المجموعة ، وليست حقيقية من المستخدمين.

مجموعتنا موجودة في GCE ونحتاج فقط إلى موازن تحميل مع دعم HTTPS قبل أن نبدأ العمل. نظرًا لأن GCE لا يدعم الإصدار 1.2 ألفا ، فلا يمكننا استخدام Ingress الجديد (الذي يدعم AFAIK موازن تحميل HTTPS) ، لذا فإن Network Load Balancer هو خيارنا الوحيد. لكن من الواضح أننا لا نستطيع أن نعيش بدون القدرة على تسجيل IPS الحقيقي من مستخدمينا.

سيكون موضع تقدير بعض التوضيحات للمستخدمين الجدد حول هذا. يعد دعم HTTPS إلزاميًا للعديد منا. شكرا!

لقد كنت أستخدم وكيل iptables في وضع التشغيل والإيقاف لبعض الوقت ويمكنني أن أؤكد أن عناوين IP الخارجية للعملاء لا تزال مخفية / تظهر عناوين IP للمجموعة.

لقد تجاوزنا هذا الأمر حتى الآن من خلال تشغيل وكيل HTTP / HTTPS للواجهة الأمامية الخاص بنا والذي يعمل في وضع الشبكة المضيفة بحيث يرى عنوان IP المصدر.

maclof شكرا على ردود الفعل. هل يمكنك مشاركة المزيد من المعلومات حول كيفية الحل؟ ماذا تقصد بتشغيل HTTP / HTTPS في الشبكة المضيفة؟

javiercr نستخدم مواصفات بود شيء مثل هذا: http://pastie.org/private/zpdelblsob654zif7xus5g

يعني استخدام الشبكة المضيفة أن البود يعمل في شبكة الأجهزة المضيفة ، بدلاً من تعيين عنوان IP للكتلة.

هذا يعني أنه عندما يرتبط خادم nginx بالمنفذ 80/443 ، فإنه سيستمع إلى عنوان IP مضيف وسيرى عناوين IP المصدر.

أنا أستخدم kubernetes 1.1 و /opt/bin/kube-proxy ... --proxy-mode=iptables --masquerade-all=false وأقوم بتوجيه شبكة cluser IP عبر مضيف به وكيل kube. في هذا الإعداد ، ترى خدماتي عنوان IP الخارجي. أستخدم مساحة اسم شبكة متاحة للغاية والتي لها عنوان IP خارجي وطريق إلى المضيفين:

I0221 01:20:32.695440       1 main.go:224] <A6GSXEKN> Connection from 202.22.xxx.yyy:51954 closed.

لقد تعلمت الكثير من قراءة هذا الموضوع!

بصفتك FYI ، ينص هذا المستند على أن AWS ELB يستخدم round-robin لاتصالات TCP وأقل الاتصالات لـ http / https: http://docs.aws.amazon.com/ElasticLoadBalancing/latest/DeveloperGuide/how-elb-works.html# طلب- كروت

أوافق على أن التركيز على الحصول على الطلبات فقط للعقد التي تشغل البودات ومحاولة خدمة القرون المحلية هو أفضل طريقة للقيام بذلك. الميزة الجانبية الجيدة لهذا هي أنه سيكون هناك حركة مرور أقل من عقدة إلى عقدة داخل المجموعة وأفترض أن هناك تحسينًا في زمن الانتقال من خلال خدمة الطلبات المحلية دائمًا من الخدمة إلى البود (والذي أعتقد أنه سيكون أكثر فائدة إذا كان لديك عقد في مناطق توافر متعددة في نفس المجموعة).

فيما يتعلق بالعمل مع موازن التحميل الذي لا يدعم الترجيح ، يمكنك حل ذلك باستخدام وحدة التحكم في النسخ المتماثل من خلال محاولة الاحتفاظ دائمًا بنفس عدد القرون على عقدة (إذا كان هناك أكثر من 1 لكل عقدة) ثم التوزيع بالتساوي بين منهم ، حتى لو كان هذا يعني الاضطرار إلى نقل البودات من العقدة في مواقف معينة والسماح فقط بعدد معين من النسخ المتماثلة. على سبيل المثال ، بالنسبة لمجموعة العقد المكونة من 4 عقدة مع خدمة متصلة بموازنة تحميل ، سيكون العدد الوحيد للنسخ المتماثلة للقرص المقبولة هو 1،2،3،4،6،8،9،12،16،20 ، إلخ.

نحن نتطلع أيضًا إلى حل مشكلة حركة المرور لتوجيهها إلى البودات المحلية فقط. سأكون على ما يرام مع إزالة nodeport على عقدة في الأوقات التي لا توجد فيها حواجز محلية لخدمة ما. بهذه الطريقة ، سيمنع فحص صحة TCP لموازن التحميل البسيط الطلبات من الانتقال إلى تلك العقد. أعتقد أنه إذا تمكنا على الأقل من حل جزء iptables \ kube-proxy من هذا ، فسنكتشف آثار موازنة الحمل عندما لا تكون الكبسولات متوازنة عبر الكتلة. أعتقد أن هناك طرقًا لحل ذلك على موازنات التحميل دون الحاجة إلى تعيين وزن لكل عقدة مع استدعاء API.

تتعامل موازين التحميل بالفعل مع هذا باستخدام طرق ديناميكية أخرى. أيضًا ، اعتمادًا على ما تقوم به الخدمة التي تقوم بتشغيلها داخل تلك الحاوية لكل مكالمة api ، فقد لا تتمكن من دعم ضعف حركة المرور عندما يكون هناك جرابان على عقدة مقابل واحدة على أي حال. إذا تم تعيين حدود Kubernetes وإذا تم الاقتراب من الحد الأقصى لمستويات الاستخدام على podnode ، فقد يؤدي ذلك أيضًا إلى إضافة طبقة أخرى من التعقيد لمحاولة العثور على إعداد الوزن المناسب على موازن التحميل الخارجي.

أود أن أقول ، ابق بعيدًا عن هذا المستوى من التعقيد ولا تحاول ضبط وزن موازن التحميل من kubernetes.

yoshiwaan هل يمكنني اقتراح فتح إصدار جديد لاقتراح حركة المرور بين العقد ، حيث تم إغلاق هذه المشكلة الآن. أنا شخصياً أعتقد أن الخطوة الأولى الجيدة ستكون التأكد من أن _if_ جراب يعمل على العقدة المحلية ، وأن نوجهها إلى الكبسولة المحلية. أظن أن هذا سيكون كافيًا ، لأنه يمكنك بعد ذلك توسيع نطاق RC الخاص بك بحيث تكون هناك كبسولات على كل عقدة.

justinsb +1 ، نحن أيضًا نواجه مشكلة الآن حيث نحتاج إلى رؤية عناوين IP للعميل وهو أمر مستحيل أساسًا مع الإعداد الحالي.

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

يعني وضع Userland أن kube-proxy يتعامل مع الاتصالات نفسها عن طريق تلقي طلب الاتصال من العميل وفتح مقبس للخادم ، والذي (1) يستهلك قدرًا أكبر بكثير من وحدة المعالجة المركزية والذاكرة و (2) يقتصر على عدد المنافذ التي يمكن لكل منها مفتوح (<65 كيلو). يعمل وضع iptables على مستوى أدنى ، في النواة ، ويستخدم تتبع الاتصال بدلاً من ذلك ، لذا فهو أخف بكثير ويتعامل مع الكثير من الاتصالات *.

(عدل) (*) طالما أنك لا تمر حزم SNAT ، وهذا بدوره يتطلب إعدادًا حيث تكون متأكدًا من أن الحزم ستعبر قواعد تتبع الاتصال المرتبطة بها. على سبيل المثال ، يتيح لك استخدام تصميم الوصول الموجه تجنب SNAT ، مما يعني أن نقطة نهاية الخدمة ستشاهد عنوان IP الخاص بالعميل الحقيقي.

تضمين التغريدة
يعني أن kube-proxy مسؤول فقط عن إعداد قواعد iptables والحفاظ عليها ولم نعد نحصل على منفذ محلي عشوائي لكل خدمة في وضع iptables ، أليس كذلك؟

في 19/04/2016 10:51 مساءً ، كتب إيما:

بمعنى أن kube-proxy مسؤول فقط عن الإعداد والصيانة
iptables ولم نعد نحصل على منفذ محلي عشوائي لكل خدمة في
وضع iptables ، أليس كذلك؟

نعم فعلا.

آسف لكنني بالتأكيد فاتني هذا في وقت سابق.

(عدل) (*) طالما أنك لا تمر حزم SNAT ، وهذا بدوره يتطلب إعدادًا حيث تكون متأكدًا من أن الحزم ستعبر قواعد تتبع الاتصال المرتبطة بها. على سبيل المثال ، يتيح لك استخدام تصميم الوصول الموجه تجنب SNAT ، مما يعني أن نقطة نهاية الخدمة ستشاهد عنوان IP الخاص بالعميل الحقيقي.

MikaelCluseau كنت أفكر في أن iptables يعتمد SNAT و DNAT ، وهذا ليس هو الحال بالنسبة لك. هل يمكنك توضيح هذا لي من فضلك؟

في 04/20/2016 01:59 مساءً ، كتب إيما:

MikaelCluseau https://github.com/MikaelCluseau كنت أفكر
يعتمد iptables على SNAT و DNAT ، وهذا ليس هو الحال بالنسبة لك.
هل يمكنك توضيح هذا لي من فضلك؟

إنه الجزء الصعب.

(1) يتطلب استخدام عناوين IP للخدمة / الخارجية DNAT.
(2) إذا كنت متأكدًا من أن حزم الرد سوف تمر عبر نفس الاتصال
القاعدة (على سبيل المثال ، نفس مكدس الشبكة أو جدول conntrack منسوخ) ، أنت
يمكن تخطي جزء SNAT (أي قواعد MASQUERADE).

عادة ما تكون حالة (2) جيدة في تصميمات شبكة الوصول الموجهة
(وهو أبسط تصميم يمكنني التفكير فيه).

على سبيل المثال ، معطى

• عميل 1.0.1.1 ،
• خدمة 1.0.2.1 ،
• جراب تنفيذ الخدمة 1.0.3.1.

ثم،

1. جهاز التوجيه / جدار الحماية / loadbalancer / المضيف / أي شيء يتلقى حزمة
   للخدمة حتى ترى الحزمة "1.0.1.1 -> 1.0.2.1" ؛
2. إنه DNAT يصل إلى نقطة النهاية (pod) لذا ستكون الحزمة "1.0.1.1 ->
   1.0.3.1 "في شبكة الكتلة ؛
3. يرد الجراب بحزمة "1.0.3.1 -> 1.0.1.1" ؛
4. تمر الحزمة عبر جهاز توجيه / جدار حماية / أداة تحميل / مضيف / أيًا كان
   مع وجود قاعدة conntrack ، يعيد نظام conntrack كتابة الحزمة
   إلى "1.0.2.1 -> 1.0.1.1" قبل إعادته إلى العميل.

إذا تعذر الوفاء بشرط (2) ، فيجب عليك استخدام SNAT / MASQUERADING
للتأكد من أن الحزمة ستعود من خلال
جهاز التوجيه / جدار الحماية / loadbalancer / المضيف / أيا كان conntrack.

MikaelCluseau -
شيء لك

يوم الثلاثاء ، 19 أبريل 2016 ، الساعة 8:20 مساءً ، Mikaël Cluseau [email protected]
كتب:

في 04/20/2016 01:59 مساءً ، كتب إيما:

MikaelCluseau https://github.com/MikaelCluseau كنت أفكر
يعتمد iptables على SNAT و DNAT ، وهذا ليس هو الحال بالنسبة لك.
هل يمكنك توضيح هذا لي من فضلك؟

إنه الجزء الصعب.

(1) يتطلب استخدام عناوين IP للخدمة / الخارجية DNAT.
(2) إذا كنت متأكدًا من أن حزم الرد سوف تمر عبر نفس الاتصال
القاعدة (على سبيل المثال ، نفس مكدس الشبكة أو جدول conntrack منسوخ) ، أنت
يمكن تخطي جزء SNAT (أي قواعد MASQUERADE).

عادة ما تكون حالة (2) جيدة في تصميمات شبكة الوصول الموجهة
(وهو أبسط تصميم يمكنني التفكير فيه).

على سبيل المثال ، معطى

• عميل 1.0.1.1 ،
• خدمة 1.0.2.1 ،
• جراب تنفيذ الخدمة 1.0.3.1.

ثم،

1. جهاز التوجيه / جدار الحماية / loadbalancer / المضيف / أي شيء يتلقى حزمة
   للخدمة حتى ترى الحزمة "1.0.1.1 -> 1.0.2.1" ؛
2. إنه DNAT يصل إلى نقطة النهاية (pod) لذا ستكون الحزمة "1.0.1.1 ->
   1.0.3.1 "في شبكة الكتلة ؛
3. يرد الجراب بحزمة "1.0.3.1 -> 1.0.1.1" ؛
4. تمر الحزمة عبر جهاز توجيه / جدار حماية / أداة تحميل / مضيف / أيًا كان
   مع وجود قاعدة conntrack ، يعيد نظام conntrack كتابة الحزمة
   إلى "1.0.2.1 -> 1.0.1.1" قبل إعادته إلى العميل.

إذا تعذر الوفاء بشرط (2) ، فيجب عليك استخدام SNAT / MASQUERADING
للتأكد من أن الحزمة ستعود من خلال
جهاز التوجيه / جدار الحماية / loadbalancer / المضيف / أيا كان conntrack.

-
أنت تتلقى هذا لأنه تم ذكرك.
قم بالرد على هذا البريد الإلكتروني مباشرة أو قم بعرضه على GitHub
https://github.com/kubernetes/kubernetes/issues/3760#issuecomment -212230959

justinsbyoshiwaan هل قام أي شخص بإنشاء مشكلة لهذا؟ بحثي fu يخذلني ، ولدي حاجة مماثلة.

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

أنا لم أرفعها بنفسي

Ahhhhh ، أعتقد أنني وجدته ، يبدو أن هذه هي الميزة / الإصلاح: https://github.com/kubernetes/features/issues/27

يبدو أنه إصدار تجريبي اعتبارًا من 1.5.x.