نتائج اختبار البرنامج المساعد لشبكات Kubernetes (CNI) التي تزيد عن 10 جيجابت في الثانية (تم التحديث في أبريل 2019)

هذا هو التحديث الخاص بي المعيار السابق، والذي يعمل الآن على Kubernetes 1.14 مع أحدث إصدار من CNI اعتبارًا من أبريل 2019.

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

ما الذي تغير منذ نوفمبر 2018؟

إليك ما تغير منذ ذلك الحين (إذا كنت مهتمًا):

يظل Flannel أسرع وأبسط واجهة CNI، لكنه لا يزال لا يدعم سياسات الشبكة والتشفير.

لم يعد Romana مدعومًا، لذا قمنا بإزالته من المعيار.

يدعم WeaveNet الآن سياسات الشبكة الخاصة بالدخول والخروج! لكن الإنتاجية انخفضت.

في Calico، لا تزال بحاجة إلى تكوين الحد الأقصى لحجم الحزمة (MTU) يدويًا للحصول على أفضل أداء. تقدم كاليكو خيارين لتثبيت CNI، بحيث يمكنك الاستغناء عن مستودع ETCD منفصل:

• حالة التخزين في Kubernetes API كمخزن بيانات (حجم المجموعة <50 عقدة)؛
• حالة التخزين في Kubernetes API كمخزن بيانات مع وكيل Typha لتخفيف الحمل على K8S API (حجم المجموعة > 50 عقدة).

أعلنت كاليكو الدعم سياسات مستوى التطبيق أعلى Istio للأمان على مستوى التطبيق.

Cilium يدعم الآن التشفير! يوفر Cilium التشفير باستخدام أنفاق IPSec ويقدم بديلاً لشبكة WeaveNet المشفرة. لكن WeaveNet أسرع من Cilium مع تمكين التشفير.

أصبح الآن نشر Cilium أسهل بفضل مشغل ETCD المدمج.

لقد حاول فريق Cilium تقليل بعض الوزن من CNI الخاص به عن طريق تقليل استهلاك الذاكرة وتكاليف وحدة المعالجة المركزية، لكن منافسيه ما زالوا أخف وزنًا.

السياق المرجعي

يتم تشغيل المعيار على ثلاثة خوادم Supermicro غير افتراضية مع محول Supermicro بسعة 10 جيجا بايت. يتم توصيل الخوادم مباشرة بالمحول عبر كابلات DAC SFP + السلبية ويتم تكوينها على نفس شبكة VLAN مع إطارات ضخمة (MTU 9000).

تم تثبيت Kubernetes 1.14.0 على Ubuntu 18.04 LTS مع Docker 18.09.2 (إصدار Docker الافتراضي في هذا الإصدار).

لتحسين إمكانية التكرار، قررنا دائمًا تكوين العقدة الرئيسية على العقدة الأولى، ووضع جزء الخادم من المعيار على الخادم الثاني، وجزء العميل على العقدة الثالثة. للقيام بذلك، نستخدم NodeSelector في عمليات نشر Kubernetes.

سنقوم بوصف النتائج المعيارية على المقياس التالي:

اختيار CNI للمعيار

يعد هذا معيارًا فقط لـ CNI من القائمة الموجودة في القسم حول إنشاء مجموعة رئيسية واحدة باستخدام kubeadm راجع وثائق Kubernetes الرسمية. من بين 9 CNIs، سنأخذ 6 فقط: سنستبعد تلك التي يصعب تثبيتها و/أو لا تعمل بدون تكوين وفقًا للوثائق (Romana، وContiv-VPP، وJuniperContrail/TungstenFabric).

سنقوم بمقارنة CNIs التالية:

• كاليكو v3.6
• Canal v3.6 (أساسًا Flannel للتواصل + Calico كجدار حماية)
• الهدب 1.4.2
• الفانيلا 0.11.0
• جهاز توجيه كوبي 0.2.5
• ويفينت 2.5.1

تركيب

كلما كان تركيب CNI أسهل، كان انطباعنا الأول أفضل. من السهل جدًا تثبيت جميع CNIs من المعيار (باستخدام أمر واحد أو أمرين).

كما قلنا، تم تكوين الخوادم والمحولات مع تمكين الإطارات الضخمة (قمنا بضبط وحدة الإرسال الكبرى (MTU) على 9000). سنكون سعداء إذا قامت CNI تلقائيًا بتحديد وحدة الإرسال الكبرى (MTU) بناءً على تكوين المحولات. ومع ذلك، فقط Cilium وFlannel تمكنا من ذلك. لدى بقية CNIs طلبات على GitHub لإضافة اكتشاف MTU تلقائيًا، ولكننا سنقوم بتكوينه يدويًا عن طريق تغيير ConfigMap لـ Calico وCanal وKube-router، أو تمرير متغير بيئة لـ WeaveNet.

ما هي المشكلة مع MTU غير صحيحة؟ يوضح هذا الرسم البياني الفرق بين WeaveNet مع تمكين MTU الافتراضي والإطارات الضخمة:

كيف تؤثر MTU على الإنتاجية؟

لقد رأينا مدى أهمية MTU للأداء، والآن دعونا نرى كيف تحددها CNIs تلقائيًا:

يكتشف CNI تلقائيًا MTU

يوضح الرسم البياني أنك بحاجة إلى تكوين وحدة الإرسال الكبرى (MTU) لـ Calico وCanal وKube-router وWeaveNet للحصول على الأداء الأمثل. تمكن Cilium وFlannel من تحديد MTU بأنفسهم بشكل صحيح دون أي إعدادات.

أمن

سنقارن أمان CNI في جانبين: القدرة على تشفير البيانات المرسلة وتنفيذ سياسات شبكة Kubernetes (استنادًا إلى اختبارات حقيقية، وليس الوثائق).

يقوم اثنان فقط من CNIs بتشفير البيانات: Cilium وWeaveNet. التشفير ويفينيت تم تمكينه عن طريق تعيين كلمة مرور التشفير كمتغير بيئة CNI. في توثيق يصف WeaveNet ذلك بطريقة معقدة، ولكن كل شيء يتم ببساطة. التشفير كيليوم تم تكوينه بواسطة الأوامر، ومن خلال إنشاء أسرار Kubernetes، ومن خلال تعديل daemonSet (أكثر تعقيدًا قليلاً مما هو عليه في WeaveNet، لكن Cilium لديه خطوة بخطوة تعليمات).

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

وفيما يلي النتائج الإجمالية:

النتائج المعيارية لأداء السلامة

أداء

يوضح هذا المعيار متوسط ​​الإنتاجية خلال ثلاث عمليات تشغيل على الأقل لكل اختبار. نحن نختبر أداء TCP وUDP (باستخدام iperf3)، والتطبيقات الحقيقية مثل HTTP (باستخدام Nginx وcurl) أو FTP (باستخدام vsftpd وcurl)، وأخيرًا أداء التطبيق باستخدام التشفير المستند إلى SCP (باستخدام العميل والخادم OpenSSH).

بالنسبة لجميع الاختبارات، أجرينا معيارًا معدنيًا (الخط الأخضر) لمقارنة أداء CNI مع أداء الشبكة الأصلية. هنا نستخدم نفس المقياس، ولكن بالألوان:

• الأصفر= جيد جداً
• البرتقال = جيد
• الأزرق = هكذا
• الأحمر = سيء

لن نأخذ CNIs التي تم تكوينها بشكل غير صحيح وسنعرض فقط نتائج CNIs ذات وحدة الإرسال الكبرى الصحيحة. (ملاحظة: لا يقوم Cilium بحساب وحدة الإرسال الكبرى بشكل صحيح إذا قمت بتمكين التشفير، لذلك سيتعين عليك تقليل وحدة الإرسال الكبرى يدويًا إلى 8900 في الإصدار 1.4. الإصدار التالي، 1.5، يقوم بذلك تلقائيًا.)

ها هي النتائج:

أداء برنامج التعاون الفني

كان أداء جميع CNIs جيدًا في معيار TCP. CNI مع التشفير متخلف كثيرًا لأن التشفير باهظ الثمن.

أداء UDP

وهنا أيضاً كان أداء كل المؤسسات الوطنية المركزية طيباً. أظهر CNI مع التشفير نفس النتيجة تقريبًا. يتأخر Cilium قليلًا عن المنافسة، لكنه يتكون من 2,3% فقط من المعدن، لذا فهي ليست نتيجة سيئة. لا تنس أن Cilium وFlannel فقط هما من قاما بتحديد MTU بشكل صحيح، وهذه هي نتائجهما دون أي تكوين إضافي.

ماذا عن التطبيق الحقيقي؟ كما ترون، الأداء الإجمالي لـ HTTP أقل قليلاً من أداء TCP. حتى إذا كنت تستخدم HTTP مع TCP، فقد قمنا بتكوين iperf3 في اختبار TCP لتجنب البداية البطيئة التي قد تؤثر على اختبار HTTP. لقد قام الجميع بعمل جيد هنا. يتمتع جهاز التوجيه Kube بميزة واضحة، لكن أداء WeaveNet لم يكن جيدًا: فهو أسوأ بنحو 20% من جهاز التوجيه المعدني. يبدو Cilium وWeaveNet مع التشفير حزينًا حقًا.

مع FTP، وهو بروتوكول آخر يعتمد على TCP، تختلف النتائج. يقوم جهاز Flannel وKube-router بهذه المهمة، لكن Calico وCanal وCilium متأخران قليلاً وأبطأ بحوالي 10% من المعدن العاري. يتخلف WeaveNet بنسبة تصل إلى 17%، لكن WeaveNet المشفر يتقدم بنسبة 40% على Cilium المشفر.

مع SCP يمكننا أن نرى على الفور كم يكلفنا تشفير SSH. تعمل جميع CNIs تقريبًا بشكل جيد، لكن WeaveNet تتخلف مرة أخرى. من المتوقع أن يكون Cilium وWeaveNet مع التشفير الأسوأ بسبب التشفير المزدوج (SSH + CNI).

فيما يلي جدول ملخص بالنتائج:

استهلاك المصدر

الآن دعونا نقارن كيفية استهلاك CNI للموارد في ظل الأحمال الثقيلة (أثناء نقل TCP بسرعة 10 جيجابت في الثانية). في اختبارات الأداء نقوم بمقارنة CNI مع المعدن العاري (الخط الأخضر). بالنسبة لاستهلاك الموارد، دعنا نعرض Kubernetes خالصًا (الخط الأرجواني) بدون CNI ونرى عدد الموارد الإضافية التي يستهلكها CNI.

لنبدأ بالذاكرة. فيما يلي متوسط ​​قيمة ذاكرة الوصول العشوائي للعقد (باستثناء المخازن المؤقتة وذاكرة التخزين المؤقت) بالميجابايت أثناء النقل.

استهلاك الذاكرة

أظهر جهاز Flannel وKube-router نتائج ممتازة - 50 ميجابايت فقط. يحتوي كل من Calico وCanal على 70 ميجابايت. ومن الواضح أن WeaveNet يستهلك أكثر من الآخرين - 130 ميجابايت، بينما يستخدم Cilium ما يصل إلى 400 ميجابايت.
الآن دعونا نتحقق من استهلاك وقت وحدة المعالجة المركزية. جدير بالملاحظة: الرسم البياني لا يظهر النسب المئوية، ولكن جزء في المليون، أي 38 جزء في المليون لـ "الحديد العاري" هو 3,8٪. وهنا النتائج:

استهلاك وحدة المعالجة المركزية

تتميز أجهزة Calico وCanal وFlannel وKube-router بكفاءة عالية في وحدة المعالجة المركزية - فقط 2% أكثر من Kubernetes بدون CNI. تتخلف شركة WeaveNet كثيرًا بنسبة 5% إضافية، يليها Cilium بنسبة 7%.

فيما يلي ملخص لاستهلاك الموارد:

نتائج

جدول بجميع النتائج:

نتائج القياس العام

اختتام

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

أوصي باستخدام CNIs التالية وفقًا للسيناريو:

• هل لديك في مجموعتك العقد مع موارد قليلة (عدة غيغابايت من ذاكرة الوصول العشوائي، والعديد من النوى) ولا تحتاج إلى ميزات الأمان - اختر الفانيلي. هذا هو واحد من CNIs الأكثر فعالية من حيث التكلفة. وهو متوافق مع مجموعة واسعة من البنيات (amd64، وarm، وarm64، وما إلى ذلك). بالإضافة إلى ذلك، هذا هو واحد من اثنين (الآخر هو Cilium) CNI الذي يمكنه تحديد MTU تلقائيًا، لذلك لا يتعين عليك تكوين أي شيء. يعد Kube-router مناسبًا أيضًا، ولكنه ليس قياسيًا وستحتاج إلى تكوين وحدة الإرسال الكبرى (MTU) يدويًا.
• إذا لزم الأمر تشفير الشبكة من أجل السلامة، خذ ويفينيت. لا تنس تحديد حجم وحدة الإرسال الكبرى (MTU) إذا كنت تستخدم إطارات ضخمة جدًا، وقم بتمكين التشفير عن طريق تحديد كلمة مرور عبر متغير البيئة. لكن من الأفضل أن ننسى الأداء، فهذه هي تكلفة التشفير.
• إلى إستعمال عادي советую كاليكو. يتم استخدام CNI هذا على نطاق واسع في أدوات نشر Kubernetes المختلفة (Kops وKubespray وRancher وما إلى ذلك). كما هو الحال مع WeaveNet، تأكد من تكوين وحدة الإرسال الكبرى (MTU) في ConfigMap في حالة استخدام الإطارات الضخمة. إنها أداة متعددة الوظائف تتسم بالكفاءة من حيث استهلاك الموارد والأداء والأمن.

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

رسم تخطيطي مرئي لاختيار CNI

المصدر: www.habr.com