Резултати од репер за мрежен приклучок Kubernetes (CNI) над 10 Gbps мрежа (ажурирано: април 2019 година)

Ова е моето ажурирање претходен репер, кој сега работи на Kubernetes 1.14 со најновата CNI верзија од април 2019 година.

Пред сè, сакам да му се заблагодарам на тимот на Cilium: момците ми помогнаа да ги проверам и корегирам скриптите за следење на метриката.

Што се смени од ноември 2018 година

Еве што се смени оттогаш (ако ве интересира):

Flannel останува најбрзиот и наједноставниот CNI интерфејс, но сепак не поддржува мрежни политики и шифрирање.

Романа повеќе не е поддржана, па ја тргнавме од реперот.

WeaveNet сега поддржува мрежни политики за Ingress и Egress! Но, продуктивноста е намалена.

Во Calico, сепак треба рачно да ја конфигурирате максималната големина на пакетот (MTU) за најдобри перформанси. Calico нуди две опции за инсталирање на CNI, така што можете да направите без посебно складиште за ETCD:

• состојба на складирање во Kubernetes API како складиште на податоци (големина на кластерот < 50 јазли);
• состојба на складирање во Kubernetes API како складиште на податоци со Typha прокси за да се ослободи оптоварувањето на K8S API (големина на кластерот > 50 јазли).

Калико најави поддршка политики на ниво на апликација на врвот на Istio за безбедност на ниво на апликација.

Cilium сега поддржува шифрирање! Cilium обезбедува шифрирање со IPSec тунели и нуди алтернатива на шифрираната мрежа WeaveNet. Но, WeaveNet е побрз од Cilium со овозможено шифрирање.

Cilium сега е полесен за распоредување благодарение на вградениот ETCD оператор.

Тимот на Cilium се обиде да намали одредена тежина од својот CNI со намалување на потрошувачката на меморија и трошоците за процесорот, но неговите конкуренти сè уште се полесни.

Репер контекст

Реперот се извршува на три невиртуелизирани Supermicro сервери со 10 Gb Supermicro прекинувач. Серверите се поврзани директно со прекинувачот преку пасивни DAC SFP+ кабли и се конфигурирани на истиот VLAN со џамбо рамки (MTU 9000).

Kubernetes 1.14.0 инсталиран на Ubuntu 18.04 LTS со Docker 18.09.2 (стандардна верзија на Docker во ова издание).

За да ја подобриме репродуктивноста, решивме секогаш да го конфигурираме господарот на првиот јазол, да го поставуваме делот од реперот на серверот на вториот сервер, а клиентот на третиот. За да го направите ова, користиме NodeSelector во распоредувањата на Kubernetes.

Ние ќе ги опишеме реперните резултати на следната скала:

Избор на CNI за репер

Ова е репер само за CNI од списокот во делот за создавање на еден главен кластер со kubeadm Погледнете ја официјалната документација на Кубернетес. Од 9 CNI, ќе земеме само 6: ќе ги исклучиме оние кои тешко се инсталираат и/или не работат без конфигурација според документацијата (Romana, Contiv-VPP и JuniperContrail/TungstenFabric).

Ќе ги споредиме следните CNI:

• Калико v3.6
• Canal v3.6 (во суштина Flannel за вмрежување + 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-рутер или пренесување променлива на околината за WeaveNet.

Што е проблемот со неточниот MTU? Овој дијаграм ја покажува разликата помеѓу WeaveNet со овозможени стандардни MTU и џамбо рамки:

Како MTU влијае на пропусната моќ?

Видовме колку е важен MTU за перформансите, сега да видиме како нашите CNI автоматски го одредуваат тоа:

CNI автоматски го открива MTU

Графиконот покажува дека треба да го конфигурирате MTU за Calico, Canal, Kube-рутер и WeaveNet за оптимални перформанси. Cilium и Flannel можеа самите правилно да го одредат MTU без никакви поставки.

безбедност

Ќе ја споредиме безбедноста на CNI во два аспекта: способност за шифрирање на пренесените податоци и имплементација на мрежните политики на Кубернетес (врз основа на вистински тестови, а не на документација).

Само два CNI шифрираат податоци: Cilium и WeaveNet. Енкрипција WeaveNet овозможено со поставување на лозинката за шифрирање како променлива на околината CNI. ВО документација WeaveNet го опишува на комплициран начин, но сè е направено едноставно. Енкрипција Цилиум конфигуриран со команди, со креирање тајни на Kubernetes и преку модификација на daemonSet (малку покомплицирано отколку во WeaveNet, но Cilium има чекор по чекор инструкции).

Што се однесува до спроведувањето на мрежната политика, тие успеаја Calico, Canal, Cilium и WeaveNet, во кој можете да ги конфигурирате правилата за влез и излез. За Кубе-рутер има правила само за Ingress, и Фланел Воопшто нема мрежни политики.

Еве ги вкупните резултати:

Резултати од репер за безбедносни перформанси

Перформанси

Овој репер ја покажува просечната пропусност во текот на најмалку три циклуси на секој тест. Ги тестираме перформансите на 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 со шифрирање го покажа речиси истиот резултат. Цилиумот е малку зад конкуренцијата, но е само 2,3% од гол метал, така што не е лош резултат. Не заборавајте дека само Cilium и Flannel самите правилно го одредиле MTU, а ова се нивните резултати без дополнителна конфигурација.

Што е со вистинска апликација? Како што можете да видите, вкупните перформанси за HTTP се малку пониски отколку за TCP. Дури и ако користите HTTP со TCP, ние го конфигуриравме iperf3 во реперот TCP за да избегнеме бавно стартување што би влијаело на реперот HTTP. Сите направија добра работа овде. Кубе-рутерот има јасна предност, но WeaveNet не се покажа добро: околу 20% полошо од гол метал. Cilium и WeaveNet со шифрирање изгледаат навистина тажно.

Со FTP, друг протокол базиран на TCP, резултатите се разликуваат. Flannel и Kube-router ја завршуваат работата, но Calico, Canal и Cilium заостануваат малку и се околу 10% побавни од голиот метал. WeaveNet заостанува со дури 17%, но шифрираната WeaveNet е 40% пред шифрираната Cilium.

Со SCP веднаш можеме да видиме колку не чини SSH енкрипцијата. Речиси сите CNI работат добро, но WeaveNet повторно заостанува. Cilium и WeaveNet со шифрирање се очекувано најлоши поради двојното шифрирање (SSH + CNI).

Еве збирна табела со резултатите:

Потрошувачка на ресурси

Сега да споредиме како CNI троши ресурси при тешки оптоварувања (за време на пренос на TCP, 10 Gbps). Во тестовите за перформанси го споредуваме CNI со гол метал (зелена линија). За потрошувачка на ресурси, да покажеме чист Kubernetes (виолетова линија) без CNI и да видиме колку дополнителни ресурси троши CNI.

Да почнеме со меморија. Еве ја просечната вредност за RAM меморијата на јазлите (со исклучок на баферите и кешот) во MB за време на преносот.

Потрошувачка на меморија

Фланел и Кубе-рутер покажаа одлични резултати - само 50 MB. Calico и Canal имаат по 70. WeaveNet очигледно троши повеќе од другите - 130 MB, а Cilium користи дури 400.
Сега да ја провериме потрошувачката на време на процесорот. Вреди да се забележи: дијаграмот не покажува проценти, туку ppm, односно 38 ppm за „голо железо“ е 3,8%. Еве ги резултатите:

Потрошувачка на процесорот

Calico, Canal, Flannel и Kube-рутерот се многу ефикасни во процесорот - само 2% повеќе од Kubernetes без CNI. WeaveNet заостанува далеку со дополнителни 5%, по што следи Cilium со 7%.

Еве резиме на потрошувачката на ресурси:

Резултатите од

Табела со сите резултати:

Општи резултати од репер

Заклучок

Во последниот дел ќе го искажам моето субјективно мислење за резултатите. Запомнете дека овој репер само ја тестира пропусната моќ на една врска на многу мал кластер (3 јазли). Не се однесува на големи кластери (<50 јазли) или паралелни врски.

Препорачувам да ги користите следниве CNI во зависност од сценариото:

• Дали имате во вашиот кластер јазли со малку ресурси (неколку GB RAM, неколку јадра) и не ви требаат безбедносни карактеристики - изберете Фланел. Ова е еден од најисплатливите CNI. И тој е компатибилен со широк спектар на архитектури (amd64, arm, arm64, итн.). Покрај тоа, ова е едно од двете (другото е Cilium) CNI што може автоматски да го одреди MTU, така што не мора да конфигурирате ништо. Кубе-рутерот е исто така погоден, но не е стандарден и ќе треба рачно да го конфигурирате MTU.
• Ако е потребно шифрирајте ја мрежата за безбедност, земете WeaveNet. Не заборавајте да ја наведете големината на MTU ако користите џамбо рамки и овозможете шифрирање со одредување лозинка преку променлива на околината. Но, подобро е да заборавите на перформансите - тоа е цената на шифрирањето.
• За нормална употреба Ве советувам Американ. Овој CNI е широко користен во различни алатки за распоредување на Kubernetes (Kops, Kubespray, Rancher итн.). Како и кај WeaveNet, не заборавајте да го конфигурирате MTU во ConfigMap ако користите џамбо рамки. Тоа е мултифункционална алатка која е ефикасна во однос на потрошувачката на ресурси, перформансите и безбедноста.

И, конечно, ве советувам да го следите развојот Цилиум. Овој CNI има многу активен тим кој работи многу на нивниот производ (карактеристики, заштеда на ресурси, перформанси, безбедност, кластерирање...) и имаат многу интересни планови.

Визуелен дијаграм за избор на CNI

Извор: www.habr.com