TL; DR: Усе CNI працуюць як трэба, за выключэннем Kube-Router і Kube-OVN, Calico за выключэннем аўтаматычнага вызначэння MTU – лепш за ўсіх.
Артыкул-абнаўленне маіх мінулых праверак ( и ), на момант тэсціравання я выкарыстоўваю Kubernetes 1.19 у Ubuntu 18.04 з абноўленымі CNI на жнівень 2020 года.
Перш чым пагрузіцца ў метрыкі...
Што новага з красавіка 2019 года?
- Можна пратэставаць на ўласным кластары: можна запускаць тэсты на ўласным кластары з выкарыстаннем нашай прылады Kubernetes Network Benchmark:
- З'явіліся новыя ўдзельнікі
- ад VMware Tanzu
- ад alauda.io
- Новыя сцэнары: бягучыя праверкі запускаюць тэсты прадукцыйнасці сеткі "Pod-to-Pod", таксама дададзены новы сцэнар "Pod-to-Service", які запускае тэсты, набліжаныя да рэальных умоў. На практыцы ваш Pod з API працуе з базай у выглядзе сэрвісу, а не праз Pod ip-адрас (вядома ж мы правяраем і TCP і UDP для абодвух сцэнараў).
- Спажыванне рэсурсаў: кожны тэст зараз мае ўласнае параўнанне рэсурсаў
- Выдаленне тэстаў прыкладанняў: мы больш не робім тэсты HTTP, FTP і SCP, паколькі наша плённае супрацоўніцтва з супольнасцю і суправаджаючымі CNI выявіла прабел паміж вынікамі iperf па TCP і вынікамі curl з-за затрымкі ў запуску CNI (першыя некалькі секунд пры запуску Pod, што не характэрна ў рэальных умовах).
- Адкрыты зыходны код: усе крыніцы тэстаў (скрыпты, наладкі yml і зыходныя "сырыя" дадзеныя) даступныя
Эталонны пратакол тэсціравання
Пратакол падрабязна апісаны , звярніце ўвагу, што гэты артыкул прысвечаны Ubuntu 18.04/XNUMX з ядром па змаўчанні.
Выбар CNI для ацэнкі
Гэта тэставанне нацэлена на параўнанне CNI, якія наладжваюцца адным файлам yaml (таму выключаны ўсе, усталёўваныя скрыптамі, тыпу VPP і іншых).
Выбраныя намі CNI для параўнання:
- Antrea v.0.9.1
- Calico v3.16
- Canal v3.16 (Flannel network + Calico Network Policies)
- Cilium 1.8.2
- Flannel 0.12.0
- Kube-router latest (2020-08-25)
- WeaveNet 2.7.0
Настройка MTU для CNI
У першую чаргу правяраем уплыў аўтаматычнага вызначэння MTU на прадукцыйнасць TCP:
Уплыў MTU на прадукцыйнасць TCP
Яшчэ большы разрыў выяўляецца пры выкарыстанні UDP:
Уплыў MTU на прадукцыйнасць UDP
З улікам ВЯЛІКІЯ ўплыву на прадукцыйнасць, раскрытага ў тэстах, мы хацелі б адправіць ліст-надзею ўсім суправаджаючым CNI: калі ласка, дадайце аўтаматычнае вызначэнне MTU ў CNI. Вы выратуеце кацянят, аднарожак і нават самага сімпатычнага: маленькага дэвопсіка.
Тым не менш калі вам па-любому трэба ўзяць CNI без падтрымкі аўтаматычнага вызначэння MTU - можна наладзіць яго рукамі для атрымання прадукцыйнасці. Звярніце ўвагу, што гэта адносіцца да Calico, Canal і WeaveNet.
Мая маленькая просьба да суправаджаючых CNI…
Тэставанне CNI: неапрацаваныя дадзеныя
У гэтым раздзеле мы параўнаем CNI з правільным MTU (пэўным аўтаматычна, або выстаўленым рукамі). Асноўная мэта тут - паказаць у выглядзе графікаў неапрацаваныя дадзеныя.
Каляровая легенда:
- шэры - узор (г.зн. голае жалеза)
- зялёны - прапускная здольнасць вышэй 9500 мбітс
- жоўты - прапускная здольнасць вышэй 9000 мбітс
- аранжавы - прапускная здольнасць вышэй за 8000 мбітс
- чырвоны - прапускная здольнасць ніжэй за 8000 мбітс
- сіні - нейтральны (не звязана з прапускной здольнасцю)
Спажыванне рэсурсаў без нагрузкі
У першую чаргу - праверка спажывання рэсурсаў, калі кластар "спіць".
Спажыванне рэсурсаў без нагрузкі
Pod-to-Pod
Гэты сцэнар мае на ўвазе, што кліенцкі Pod падлучаецца напрамую да сервернага Pod па ім ip-адрасу.
Сцэнар Pod-to-Pod
TCP
Вынікі Pod-to-Pod TCP і адпаведнае спажыванне рэсурсаў:
UDP
Вынікі Pod-to-Pod UDP і адпаведнае спажыванне рэсурсаў:
Pod-to-Service
Гэты падзел актуальны для рэальных выпадкаў выкарыстання, кліенцкі Pod злучаецца з серверным Pod праз сэрвіс ClusterIP.
Сцэнар Pod-to-Service
TCP
Вынікі Pod-to-Service TCP і адпаведнае спажыванне рэсурсаў:
UDP
Вынікі Pod-to-Service UDP і адпаведнае спажыванне рэсурсаў:
Падтрымка палітык сеткі
Сярод усіх вышэйпералічаных, адзіны, які не падтрымлівае палітыкі, гэта Flannel. Усе астатнія правільна рэалізуюць сеткавыя палітыкі, у тым ліку ўваходныя і выходныя. Выдатная праца!
Шыфраванне CNI
Сярод правяраемых CNI ёсць тыя, што могуць шыфраваць абмен па сетцы паміж Pod:
- Antrea з дапамогай IPsec
- Calico з дапамогай wireguard
- Cilium з дапамогай IPsec
- WeaveNet з дапамогай IPsec
Прапускная здольнасць
Паколькі засталося менш CNI – звядзем усе сцэнары ў адзін графік:
Спажыванне рэсурсаў
У гэтым раздзеле мы будзе ацэньваць рэсурсы, якія выкарыстоўваюцца пры апрацоўцы сувязі Pod-to-Pod у TCP і UDP. Няма сэнсу маляваць графік Pod-to-Service, паколькі ён не дае дадатковай інфармацыі.
Зводзім усё разам
Давайце паспрабуем паўтарыць усе графікі, мы тут крыху прыўнеслі суб'ектыўнасці, замяняючы фактычныя значэння словамі "vwry fast", "low" і да т.п.
Заключэнне і мае высновы
Тут крыху суб'ектыўна, бо я перадаю ўласную інтэрпрэтацыю вынікаў.
Я рады, што з'явіліся новыя CNI, Antrea выступіў нядрэнна, рэалізавана шмат функцый нават у ранніх версіях: аўтаматычнае вызначэнне MTU, шыфраванне і простая ўстаноўка.
Калі параўноўваць прадукцыйнасць – усе CNI працуюць добра, акрамя Kube-OVN і Kube-Router. Kube-Router таксама не змог вызначыць MTU, я не знайшоў нідзе ў дакументацыі спосабу яго наладкі ( адкрыты запыт на гэтую тэму).
Што да спажывання рэсурсаў, то па-ранейшаму Cilium выкарыстоўвае больш аператыўнай памяці, чым іншыя, але кампанія-вытворца відавочна нацэлена на буйныя кластары, што відавочна не тое ж самае, як тэст на трохвузлавым кластары. Kube-OVN таксама спажывае шмат рэсурсаў працэсарнага часу і аператыўнай памяці, але гэта малады CNI, заснаваны на Open vSwitch (як і Antrea, які працуе лепш і з меншым спажываннем).
Сеткавыя палітыкі ёсць ва ўсіх, акрамя Flannel. Вельмі верагодна, што ён ніколі не будзе іх падтрымліваць, паколькі мэта прасцей паранай рэпы: чым лягчэй, тым лепш.
Таксама акрамя іншага, прадукцыйнасць шыфравання які наладжвае захапленне. Calico – адзін з найстарэйшых CNI, але шыфраванне было дададзена ўсяго пару тыдняў таму. Яны выбралі wireguard замест IPsec, і прасцей кажучы, усё працуе цудоўна і ўзрушана, цалкам выцясняючы іншыя CNI ў гэтай частцы тэсціравання. Вядома ж расце спажыванне рэсурсаў з-за шыфраванні, але дасяганая прапускная здольнасць таго варта (Calico у цесцю з шыфраваннем паказаў шасціразовую перавагу ў параўнанні з Cilium, якія займаюць другое месца). Больш таго, можна ўключыць wireguard у любы час пасля разгортвання Calico у кластары, а таксама, калі пажадаеце, можаце адключыць яго на кароткі час ці назаўжды. Гэта неверагодна зручна, але! Мы нагадваем, што Calico не ўмее зараз аўтаматычна вызначаць MTU (гэтая функцыя запланаваная ў наступных версіях), так што не забывайце наладжваць MTU, калі ваша сетка падтрымлівае Jumbo Frames (MTU 9000).
Акрамя іншага, звернеце ўвагу, што Cilium умее шыфраваць трафік паміж вузламі кластара (а не толькі паміж Pod), што можа быць вельмі актуальна для публічных вузлоў кластара.
У якасці зняволення я прапаную наступныя варыянты выкарыстання:
- Патрэбен CNI для моцна дробнага кластара, АБО мне не патрэбна бяспека: працуйце з фланель, найбольш лёгкім і стабільным CNI (ён жа адзін з найстарэйшых, яго па легендзе вынайшаў Homo Kubernautus ці Homo Contaitorus). Таксама вас магчыма зацікавіць найгеніяльны праект , праверце!
- Патрэбен CNI для звычайнага кластара: каленкор - ваш выбар, але не забывайце наладзіць MTU, калі яно трэба. Лёгка і нязмушана можна гуляць з сеткавымі палітыкамі, уключаць і выключаць шыфраванне і да т.п.
- Патрэбен CNI для (вельмі) буйнамаштабнага кластара: ну, тэст не паказвае паводзіны вялікіх кластараў, я быў бы рады правесці тэсты, але ў нас няма сотняў сервераў з падключэннем 10гбітс. Так што лепшы варыянт - запуск мадыфікаванага тэсту на вашых вузлах, хоць бы з Calico і Cilium.
Крыніца: habr.com