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


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


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


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


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


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


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


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


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


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

تعلن Calico عن دعم سياسة مستوى التطبيق على رأس 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 الرسمية. من CNI 9 ، نأخذ 6 فقط: نستبعد تلك التي يصعب تثبيتها و / أو لا تعمل بدون تكوين الوثائق (Romana و Contiv-VPP و JuniperContrail / TungstenFabric).


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


  • كاليكو v3.6
  • قناة v3.6 (أساسًا فلانيل للتواصل + كاليكو كجدار حماية)
  • Cilium 1.4.2
  • الفانيلا 0.11.0
  • Kube-router 0.2.5
  • WeaveNet 2.5.1

تركيب


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


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


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



كيف تؤثر MTU على النطاق الترددي


لقد اكتشفنا مدى أهمية MTU بالنسبة للأداء ، والآن دعونا نرى كيف تكتشف CNI لدينا ذلك تلقائيًا:



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


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


سلامة


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


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


بالنسبة لتطبيق سياسة الشبكة ، نجحت Calico و Canal و Cilium و WeaveNet هنا ، حيث يمكنك تكوين قواعد الدخول والخروج. بالنسبة إلى Kube-router ، توجد قواعد لـ Ingress فقط ، بينما لا يوجد لدى Flannel سياسات شبكة على الإطلاق.


وهنا النتائج العامة:



نتائج المعيار لميزات الأمان


إنتاجية


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


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


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

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


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



أداء TCP


أداء جميع CNIs بشكل جيد في معيار TCP. CNIs المشفرة متأخرة لأن التشفير مكلف.



أداء UDP


هنا ، أيضًا ، كل CNI تعمل بشكل جيد. أظهرت CNI المشفرة نفس النتيجة تقريبًا. Cilium متأخرة قليلاً عن منافسيها ، لكنها ليست سوى 2.3 ٪ من المعدن العاري ، وبالتالي فإن النتيجة ليست سيئة. لا تنس أن Cilium و Flannel وحدهما هما اللتان حددتا وحدة MTU بشكل صحيح ، وهذه هي نتائجها دون تكوين إضافي.



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



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



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


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



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


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


لنبدأ بالذاكرة. فيما يلي متوسط ​​قيمة ذاكرة المضيف (بدون المخازن المؤقتة وذاكرة التخزين المؤقت) بالميغابايت أثناء النقل.



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


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



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


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


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



النتائج


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



النتائج المرجعية العامة


استنتاج


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


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


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

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



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

Source: https://habr.com/ru/post/ar448688/


All Articles