Гэта абнаўленне майго , які зараз працуе на 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 абвясціў аб падтрымцы па-над Istio для забеспячэння бяспекі на прыкладным узроўні.
Cilium зараз падтрымлівае шыфраванне! Cilium дае шыфраванне з IPSec-тунэлямі і прапануе альтэрнатыву зашыфраванай сетцы WeaveNet. Але WeaveNet хутчэй, чым Cilium з уключаным шыфраваннем.
Cilium зараз прасцей дэплоіць – дзякуй убудаванаму аператару ETCD.
Каманда Cilium паспрабавала сагнаць са свайго CNI вагу, скараціўшы спажываную памяць і выдаткі ЦП, але канкурэнты пакуль усё роўна лягчэй.
Кантэкст бенчмарку
Бенчмарк праводзіцца на трох ня віртуалізаваных серверах Supermicro з камутатарам Supermicro на 10 Гбіт. Серверы падлучаныя да камутатара напрамую праз пасіўныя кабелі DAC SFP+ і настроены ў адным VLAN з jumbo-кадрамі (MTU 9000).
Kubernetes 1.14.0 усталяваны на Ubuntu 18.04/18.09.2 LTS з Docker XNUMX (версія Docker па змаўчанні ў гэтым выпуску).
Каб палепшыць узнаўляльнасць, мы вырашылі заўсёды наладжваць майстар на першай нодзе, серверную частку бенчмарку размяшчаць на другім серверы, а кліенцкую - на трэцім. Для гэтага мы выкарыстоўваем NodeSelector у дэплоях Kubernetes.
Вынікі бенчмарку будзем апісваць па такой шкале:
Выбар CNI для бенчмарку
Гэта бенчмарк толькі для CNI са спісу ў раздзеле у афіцыйнай дакументацыі Kubernetes. З 9 CNI мы возьмем толькі 6: выключым тыя, якія складана ўсталёўваюцца і/ці не працуюць без налады па дакументацыі (Romana, Contiv-VPP і JuniperContrail/TungstenFabric).
Будзем параўноўваць наступныя CNI:
- Calico v3.6
- Canal v3.6 (па сутнасці, гэта Flannel для арганізацыі сеткі + Calico у якасці міжсеткавага экрана)
- Cilium 1.4.2
- Flannel 0.11.0
- Kube-router 0.2.5
- WeaveNet 2.5.1
Ўстаноўка
Чым прасцей устанавіць CNI, тым лепш будзе наша першае ўражанне. Усе CNI з бенчмарку вельмі проста ўсталёўваць (адной-дзвюма камандамі).
Як мы сказалі, сервера і камутатар настроены з актываванымі jumbo-кадрамі (мы ўсталявалі MTU 9000). Мы былі б рады, калі б CNI аўтаматычна вызначыў MTU, зыходзячы з наладкі адаптараў. Аднак з гэтым зладзіліся толькі Cilium і Flannel. У астатніх CNI ёсць запыты ў GitHub для дадання аўтаматычнага выяўлення MTU, на мы будзем наладжваць яго ўручную, змяніўшы ConfigMap для Calico, Canal і Kube-router, ці перадаючы зменную асяроддзі для WeaveNet.
У чым праблема няправільнага MTU? На гэтай дыяграме відаць розніцу паміж WeaveNet з MTU па змаўчанні і з уключанымі jumbo-кадрамі:
Як параметр 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. Для Kube-router ёсць правілы толькі для Ingress, а ў фланель увогуле няма сеткавых палітык.
Вось агульныя вынікі:
Вынікі бенчмарку па характарыстыках бяспекі
Proizvoditelnost
Гэты бенчмарк паказвае сярэднюю прапускную здольнасць мінімум за тры запуску кожнага тэсту. Мы тэстуем прадукцыйнасць 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 з шыфраваннем паказалі амаль аднолькавы вынік. Cilium крыху адстае ад канкурэнтаў, але гэта ўсяго 2,3% ад «голага жалеза», так што вынік нядрэнны. Не забудзьцеся, што толькі Cilium і Flannel самі правільна вызначылі MTU, і гэта іх вынікі без дадатковай наладкі.
Як наконт рэальнага прыкладання? Як бачым, для HTTP агульная прадукцыйнасць крыху ніжэй, чым для TCP. Нават калі выкарыстоўваць HTTP з TCP, у бенчмарку TCP мы наладзілі iperf3, каб пазбегнуць павольнага старту, а гэта паўплывае на бенчмарк 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 зноў адстае. 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 вузлоў) або паралельныя падключэнні.
Я раю выкарыстоўваць наступныя CNI у залежнасці ад сцэнара:
- У вас у кластары ёсць вузлы з невялікай колькасцю рэсурсаў (некалькі ГБ аператыўкі, некалькі ядраў) і вам не патрэбныя функцыі бяспекі - выбірайце фланель. Гэта адзін з самых эканамічных CNI. І ён сумяшчальны з самымі рознымі архітэктурамі (amd64, arm, arm64 і т. д.). Да таго ж гэта адзін з двух (другі - Cilium) CNI, які можа аўтаматычна вызначыць MTU, так што нічога наладжваць не прыйдзецца. Kube-router таксама падыходзіць, але ён не такі стандартны і спатрэбіцца ўручную наладжваць MTU.
- Калі трэба зашыфраваць сетку для бяспекі, бярыце WeaveNet. Не забудзьцеся паказаць памер MTU, калі выкарыстоўваеце jumbo-кадры, і актываваць шыфраванне, паказаўшы пароль праз зменную асяроддзі. Але аб прадукцыйнасці лепш забыцца - такая плата за шыфраванне.
- Для звычайнага прымянення раю каленкор. Гэты CNI шырока выкарыстоўваецца ў розных інструментах дэплою Kubernetes (Kops, Kubespray, Rancher і т. д.). Як і з WeaveNet, не забудзьцеся наладзіць MTU у ConfigMap, калі карыстаецеся jumbo-кадры. Гэта шматфункцыянальны інструмент, эфектыўны ў плане спажывання рэсурсаў, прадукцыйнасці і бяспекі.
І, нарэшце, раю сачыць за развіццём Ресничка. У гэтага CNI вельмі актыўная каманда, якая шмат працуе над сваім прадуктам (функцыі, эканомія рэсурсаў, прадукцыйнасць, бяспека, размеркаванне па кластарах…), і ў іх вельмі цікавыя планы.
Наглядная схема для выбару CNI
Крыніца: habr.com