نتایج معیار پلاگین شبکه Kubernetes (CNI) بیش از 10 گیگابیت بر ثانیه (به‌روزرسانی: آوریل 2019)

این به روز رسانی من است معیار قبلی، که اکنون در Kubernetes 1.14 با آخرین نسخه CNI از آوریل 2019 اجرا می شود.

اول از همه، من می خواهم از تیم Cilium تشکر کنم: بچه ها به من کمک کردند تا اسکریپت های نظارت بر معیارها را بررسی و تصحیح کنم.

آنچه از نوامبر 2018 تغییر کرده است

این چیزی است که از آن زمان تاکنون تغییر کرده است (اگر علاقه دارید):

Flannel سریع‌ترین و ساده‌ترین رابط CNI است، اما همچنان از سیاست‌های شبکه و رمزگذاری پشتیبانی نمی‌کند.

Romana دیگر پشتیبانی نمی شود، بنابراین ما آن را از معیار حذف کردیم.

WeaveNet اکنون از سیاست های شبکه برای Ingress و Egress پشتیبانی می کند! اما بهره وری کاهش یافته است.

در Calico، همچنان باید حداکثر اندازه بسته (MTU) را برای بهترین عملکرد به صورت دستی پیکربندی کنید. Calico دو گزینه برای نصب CNI ارائه می دهد، بنابراین می توانید بدون مخزن ETCD جداگانه این کار را انجام دهید:

• ذخیره سازی حالت در Kubernetes API به عنوان ذخیره داده (اندازه خوشه < 50 گره).
• حالت ذخیره سازی در Kubernetes API به عنوان یک ذخیره سازی داده با یک پراکسی Typha برای کاهش بار روی K8S API (اندازه خوشه > 50 گره).

Calico پشتیبانی خود را اعلام کرد سیاست های سطح برنامه در بالای ایستیو برای امنیت در سطح برنامه.

Cilium اکنون از رمزگذاری پشتیبانی می کند! Cilium رمزگذاری را با تونل های IPSec ارائه می دهد و جایگزینی برای شبکه رمزگذاری شده WeaveNet ارائه می دهد. اما WeaveNet سریعتر از Cilium با رمزگذاری فعال است.

به لطف اپراتور ETCD داخلی، استفاده از Cilium اکنون آسان تر است.

تیم Cilium سعی کرده است با کاهش مصرف حافظه و هزینه های CPU مقداری از وزن CNI خود را کاهش دهد، اما رقبای آن همچنان سبک تر هستند.

زمینه معیار

این معیار روی سه سرور Supermicro غیر مجازی با سوئیچ 10 گیگابایتی Supermicro اجرا می شود. سرورها مستقیماً از طریق کابل های DAC SFP+ غیرفعال به سوئیچ متصل می شوند و روی همان VLAN با فریم های جامبو (MTU 9000) پیکربندی می شوند.

Kubernetes 1.14.0 روی Ubuntu 18.04 LTS با Docker 18.09.2 (نسخه پیش‌فرض Docker در این نسخه) نصب شده است.

برای بهبود تکرارپذیری، ما تصمیم گرفتیم همیشه master را در اولین گره پیکربندی کنیم، بخش سرور از معیار را در سرور دوم و قسمت مشتری را در سومین قسمت قرار دهیم. برای این کار از NodeSelector در استقرارهای Kubernetes استفاده می کنیم.

ما نتایج معیار را در مقیاس زیر توصیف خواهیم کرد:

انتخاب یک CNI برای یک معیار

این یک معیار فقط برای CNI از لیست موجود در بخش است در مورد ایجاد یک خوشه اصلی با kubeadm اسناد رسمی Kubernetes را ببینید. از 9 CNI، ما فقط 6 مورد را می گیریم: مواردی را که نصب آنها دشوار است و/یا طبق مستندات بدون پیکربندی کار نمی کنند (Romana، Contiv-VPP و JuniperContrail/TungstenFabric) را حذف می کنیم.

ما CNI های زیر را با هم مقایسه می کنیم:

• Calico نسخه 3.6
• Canal نسخه 3.6 (در اصل فلانل برای شبکه + Calico به عنوان فایروال)
• سیلیوم 1.4.2
• فلانل 0.11.0
• کوبه روتر 0.2.5
• WeaveNet 2.5.1

نصب

هرچه نصب CNI آسان تر باشد، اولین برداشت ما بهتر خواهد بود. نصب تمام CNIهای بنچمارک بسیار آسان است (با یک یا دو دستور).

همانطور که گفتیم، سرورها و سوئیچ با فریم های جامبو پیکربندی شده اند (ما MTU را روی 9000 تنظیم کردیم). اگر CNI به طور خودکار MTU را بر اساس پیکربندی آداپتورها تعیین کند، خوشحال خواهیم شد. با این حال، فقط سیلیوم و فلانل موفق به انجام این کار شدند. بقیه 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 آن را به روشی پیچیده توصیف می کند، اما همه چیز به سادگی انجام می شود. رمزگذاری سیلیوم با دستورات، با ایجاد اسرار Kubernetes، و از طریق اصلاح daemonSet (کمی پیچیده تر از WeaveNet، اما Cilium گام به گام دارد، پیکربندی شده است. دستورالعمل).

در مورد اجرای سیاست شبکه، آنها موفق بوده اند Calico، Canal، Cilium و WeaveNet، که در آن می توانید قوانین Ingress و Egress را پیکربندی کنید. برای کوبه روتر قوانینی فقط برای ورود وجود دارد، و فلنج هیچ سیاست شبکه ای اصلا وجود ندارد.

در اینجا نتایج کلی آمده است:

نتایج معیار عملکرد ایمنی

کارایی

این معیار میانگین توان عملیاتی را در حداقل سه اجرای هر آزمایش نشان می دهد. ما عملکرد TCP و UDP (با استفاده از iperf3)، برنامه های کاربردی واقعی مانند HTTP (با Nginx و curl) یا FTP (با vsftpd و curl) و در نهایت عملکرد برنامه را با استفاده از رمزگذاری مبتنی بر SCP (با استفاده از کلاینت و سرور OpenSSH) آزمایش می کنیم.

برای همه آزمایش‌ها، ما یک معیار فلزی خالی (خط سبز) برای مقایسه عملکرد CNI با عملکرد شبکه بومی انجام دادیم. در اینجا ما از همان مقیاس استفاده می کنیم، اما رنگی:

• زرد = خیلی خوب
• نارنجی = خوب
• آبی = فلانی
• قرمز = بد

ما CNI هایی را که به درستی پیکربندی نشده اند نمی گیریم و فقط نتایج را برای CNI هایی با MTU صحیح نشان می دهیم. (توجه: اگر رمزگذاری را فعال کنید Cilium MTU را به درستی محاسبه نمی کند، بنابراین باید به صورت دستی MTU را به 8900 در نسخه 1.4 کاهش دهید. نسخه بعدی، 1.5، این کار را به صورت خودکار انجام می دهد.)

در اینجا نتایج آمده است:

عملکرد TCP

همه CNI ها در معیار TCP عملکرد خوبی داشتند. CNI با رمزگذاری بسیار عقب است زیرا رمزگذاری گران است.

عملکرد UDP

در اینجا نیز همه CNI ها به خوبی کار می کنند. CNI با رمزگذاری تقریباً همان نتیجه را نشان داد. سیلیوم کمی از رقبا عقب است، اما تنها 2,3 درصد از فلز لخت است، بنابراین نتیجه بدی نیست. فراموش نکنید که فقط Cilium و Flannel خودشان MTU را به درستی تعیین کردند و اینها نتایج آنها بدون هیچ گونه تنظیمات اضافی است.

در مورد یک برنامه واقعی چطور؟ همانطور که می بینید، عملکرد کلی برای HTTP کمی کمتر از TCP است. حتی اگر از HTTP با TCP استفاده می‌کنید، ما iperf3 را در معیار TCP پیکربندی کرده‌ایم تا از شروع کندی که بر معیار HTTP تأثیر می‌گذارد جلوگیری کنیم. همه اینجا کار خوبی کردند. Kube-router یک مزیت واضح دارد، اما WeaveNet عملکرد خوبی نداشت: حدود 20٪ بدتر از فلز لخت. Cilium و WeaveNet با رمزگذاری واقعا غم انگیز به نظر می رسند.

با FTP، پروتکل دیگر مبتنی بر TCP، نتایج متفاوت است. Flannel و Kube-router این کار را انجام می دهند، اما Calico، Canal و Cilium کمی عقب هستند و حدود 10٪ کندتر از فلز لخت هستند. WeaveNet تا 17٪ عقب است، اما WeaveNet رمزگذاری شده 40٪ جلوتر از Cilium رمزگذاری شده است.

با SCP می توانیم بلافاصله ببینیم که رمزگذاری SSH چقدر برای ما هزینه دارد. تقریباً همه CNI ها خوب کار می کنند، اما WeaveNet دوباره عقب مانده است. به دلیل رمزگذاری مضاعف (SSH + CNI) پیش بینی می شود که Cilium و WeaveNet با رمزگذاری بدترین هستند.

این یک جدول خلاصه با نتایج است:

مصرف منابع

حال بیایید مقایسه کنیم که CNI چگونه منابع را تحت بارهای سنگین (در حین انتقال TCP، 10 گیگابیت بر ثانیه) مصرف می کند. در تست های عملکرد ما CNI را با فلز لخت (خط سبز) مقایسه می کنیم. برای مصرف منابع، بیایید Kubernetes خالص (خط بنفش) را بدون CNI نشان دهیم و ببینیم که CNI چقدر منابع اضافی مصرف می کند.

بیایید با حافظه شروع کنیم. در اینجا مقدار متوسط ​​رم گره ها (به استثنای بافرها و کش) در مگابایت در حین انتقال آمده است.

مصرف حافظه

فلانل و کوبه روتر نتایج عالی را نشان دادند - فقط 50 مگابایت. Calico و Canal هر کدام 70 عدد دارند. WeaveNet به وضوح بیش از بقیه مصرف می کند - 130 مگابایت، و Cilium از 400 استفاده می کند.
حالا بیایید مصرف زمان CPU را بررسی کنیم. قابل توجه: نمودار نه درصد، بلکه ppm را نشان می دهد، یعنی 38 ppm برای "آهن لخت" 3,8٪ است. در اینجا نتایج آمده است:

مصرف CPU

Calico، Canal، Flannel و Kube-router بسیار کارآمد از CPU هستند - فقط 2٪ بیشتر از Kubernetes بدون CNI. WeaveNet با 5% اضافی بسیار عقب است و پس از آن Cilium با 7% قرار دارد.

در اینجا خلاصه ای از مصرف منابع آمده است:

نمایش نتایج: از

جدول با تمام نتایج:

نتایج معیار عمومی

نتیجه

در قسمت آخر نظر ذهنی خود را در مورد نتایج بیان خواهم کرد. به یاد داشته باشید که این معیار تنها توان عملیاتی یک اتصال را روی یک خوشه بسیار کوچک (3 گره) آزمایش می کند. این برای خوشه های بزرگ (<50 گره) یا اتصالات موازی اعمال نمی شود.

من توصیه می کنم بسته به سناریو از CNI های زیر استفاده کنید:

• آیا در خوشه خود دارید گره هایی با منابع کم (چند گیگابایت رم، چندین هسته) و به ویژگی های امنیتی نیاز ندارید - انتخاب کنید فلنج. این یکی از مقرون به صرفه ترین CNI ها است. و با طیف گسترده ای از معماری ها (amd64، arm، arm64 و غیره) سازگار است. علاوه بر این، این یکی از دو CNI (دیگری Cilium) است که می تواند به طور خودکار MTU را تعیین کند، بنابراین نیازی به پیکربندی چیزی ندارید. کوبه روتر نیز مناسب است، اما استاندارد نیست و باید MTU را به صورت دستی پیکربندی کنید.
• در صورت لزوم شبکه را رمزگذاری کنید برای ایمنی، بگیرید WeaveNet. اگر از فریم های جامبو استفاده می کنید، فراموش نکنید که اندازه MTU را مشخص کنید و رمزگذاری را با تعیین رمز عبور از طریق متغیر محیطی فعال کنید. اما بهتر است عملکرد را فراموش کنید - این هزینه رمزگذاری است.
• برای استفاده معمولی توصیه میکنم چلوار. این CNI به طور گسترده در ابزارهای مختلف استقرار Kubernetes (Kops، Kubespray، Rancher و غیره) استفاده می شود. مانند WeaveNet، اگر از فریم های جامبو استفاده می کنید، حتما MTU را در ConfigMap پیکربندی کنید. این یک ابزار چند منظوره است که از نظر مصرف منابع، عملکرد و امنیت کارآمد است.

و در آخر به شما توصیه می کنم که توسعه را دنبال کنید سیلیوم. این CNI تیم بسیار فعالی دارد که روی محصول خود (ویژگی ها، صرفه جویی در منابع، عملکرد، امنیت، خوشه بندی...) بسیار کار می کنند و برنامه های بسیار جالبی دارند.

نمودار بصری برای انتخاب CNI

منبع: www.habr.com