Ito ang update ko , na tumatakbo na ngayon sa Kubernetes 1.14 na may pinakabagong bersyon ng CNI noong Abril 2019.
Una sa lahat, gusto kong pasalamatan ang koponan ng Cilium: tinulungan ako ng mga lalaki na suriin at itama ang mga script ng pagsubaybay sa sukatan.
Ano ang nagbago mula noong Nobyembre 2018
Narito kung ano ang nagbago mula noon (kung interesado ka):
Ang flannel ay nananatiling pinakamabilis at pinakasimpleng interface ng CNI, ngunit hindi pa rin sumusuporta sa mga patakaran at pag-encrypt ng network.
Hindi na sinusuportahan ang Romana, kaya inalis na namin ito sa benchmark.
Sinusuportahan na ngayon ng WeaveNet ang mga patakaran sa network para sa Ingress at Egress! Ngunit ang pagiging produktibo ay nabawasan.
Sa Calico, kailangan mo pa ring manu-manong i-configure ang maximum na laki ng packet (MTU) para sa pinakamahusay na pagganap. Nag-aalok ang Calico ng dalawang opsyon para sa pag-install ng CNI, kaya magagawa mo nang walang hiwalay na repositoryo ng ETCD:
- pag-iimbak ng estado sa Kubernetes API bilang isang data store (laki ng cluster < 50 node);
- pag-iimbak ng estado sa Kubernetes API bilang isang data store na may Typha proxy upang mapawi ang pag-load sa K8S API (laki ng cluster > 50 node).
Nagpahayag ng suporta si Calico sa itaas ng Istio para sa seguridad sa antas ng aplikasyon.
Sinusuportahan na ngayon ng Cilium ang pag-encrypt! Nagbibigay ang Cilium ng encryption gamit ang mga IPSec tunnel at nag-aalok ng alternatibo sa naka-encrypt na WeaveNet network. Ngunit ang WeaveNet ay mas mabilis kaysa sa Cilium na may naka-enable na pag-encrypt.
Mas madali na ngayong i-deploy ang Cilium salamat sa built-in na ETCD operator.
Sinubukan ng koponan ng Cilium na bawasan ang ilang timbang mula sa CNI nito sa pamamagitan ng pagbabawas ng pagkonsumo ng memorya at mga gastos sa CPU, ngunit mas magaan pa rin ang mga kakumpitensya nito.
Benchmark na konteksto
Ang benchmark ay pinapatakbo sa tatlong hindi-virtualized na Supermicro server na may 10 Gb Supermicro switch. Direktang konektado ang mga server sa switch sa pamamagitan ng mga passive na DAC SFP+ cable at naka-configure sa parehong VLAN na may mga jumbo frame (MTU 9000).
Naka-install ang Kubernetes 1.14.0 sa Ubuntu 18.04 LTS na may Docker 18.09.2 (ang default na bersyon ng Docker sa release na ito).
Upang mapabuti ang muling paggawa, nagpasya kaming palaging i-configure ang master sa unang node, ilagay ang bahagi ng server ng benchmark sa pangalawang server, at ang bahagi ng kliyente sa pangatlo. Para magawa ito, ginagamit namin ang NodeSelector sa mga deployment ng Kubernetes.
Ilalarawan namin ang mga resulta ng benchmark sa sumusunod na sukat:
Pagpili ng CNI para sa isang benchmark
Isa itong benchmark para lamang sa CNI mula sa listahan sa seksyon Tingnan ang opisyal na dokumentasyon ng Kubernetes. Sa 9 na CNI, 6 lang ang kukunin namin: ibubukod namin ang mga mahirap i-install at/o hindi gumagana nang walang configuration ayon sa dokumentasyon (Romana, Contiv-VPP at JuniperContrail/TungstenFabric).
Ihahambing namin ang mga sumusunod na CNI:
- Calico v3.6
- Canal v3.6 (talagang Flannel para sa networking + Calico bilang isang firewall)
- Cilium 1.4.2
- Flannel 0.11.0
- Kube-router 0.2.5
- WeaveNet 2.5.1
Instalasyon
Kung mas madaling i-install ang CNI, mas magiging maganda ang ating unang impression. Ang lahat ng CNI mula sa benchmark ay napakadaling i-install (na may isa o dalawang command).
Gaya ng sinabi namin, ang mga server at switch ay naka-configure na may mga jumbo frame na pinagana (itinakda namin ang MTU sa 9000). Magiging masaya kami kung awtomatikong tinutukoy ng CNI ang MTU batay sa configuration ng mga adapter. Gayunpaman, tanging ang Cilium at Flannel ang namamahala nito. Ang iba sa mga CNI ay may mga kahilingan sa GitHub na magdagdag ng awtomatikong pagtuklas ng MTU, ngunit manu-mano namin itong iko-configure sa pamamagitan ng pagbabago sa ConfigMap para sa Calico, Canal at Kube-router, o pagpasa ng environment variable para sa WeaveNet.
Ano ang problema sa maling MTU? Ipinapakita ng diagram na ito ang pagkakaiba sa pagitan ng WeaveNet na may default na MTU at mga jumbo frame na pinagana:
Paano nakakaapekto ang MTU sa throughput?
Nakita natin kung gaano kahalaga ang MTU para sa pagganap, ngayon tingnan natin kung paano ito awtomatikong tinutukoy ng ating mga CNI:
Awtomatikong nakikita ng CNI ang MTU
Ipinapakita ng graph na kailangan mong i-configure ang MTU para sa Calico, Canal, Kube-router at WeaveNet para sa pinakamainam na pagganap. Natukoy nang tama ng Cilium at Flannel ang MTU mismo nang walang anumang mga setting.
katiwasayan
Ihahambing namin ang seguridad ng CNI sa dalawang aspeto: ang kakayahang i-encrypt ang ipinadalang data at ang pagpapatupad ng mga patakaran sa network ng Kubernetes (batay sa mga tunay na pagsubok, hindi dokumentasyon).
Dalawang CNI lang ang nag-encrypt ng data: Cilium at WeaveNet. Pag-encrypt WeaveNet pinagana sa pamamagitan ng pagtatakda ng password sa pag-encrypt bilang variable ng kapaligiran ng CNI. SA Inilalarawan ito ng WeaveNet sa isang kumplikadong paraan, ngunit ang lahat ay ginagawa nang simple. Pag-encrypt Sili na-configure ng mga utos, sa pamamagitan ng paglikha ng mga lihim ng Kubernetes, at sa pamamagitan ng pagbabago ng daemonSet (medyo mas kumplikado kaysa sa WeaveNet, ngunit ang Cilium ay may sunud-sunod na hakbang. ).
Tungkol naman sa pagpapatupad ng network policy, nagtagumpay sila Calico, Canal, Cilium at WeaveNet, kung saan maaari mong i-configure ang mga panuntunan sa Ingress at Egress. Para sa Kube-router may mga panuntunan para lamang sa Ingress, at pranela Walang mga patakaran sa network sa lahat.
Narito ang pangkalahatang mga resulta:
Mga Resulta ng Benchmark sa Pagganap ng Kaligtasan
Pagiging Produktibo
Ipinapakita ng benchmark na ito ang average na throughput sa hindi bababa sa tatlong pagtakbo ng bawat pagsubok. Sinusubukan namin ang pagganap ng TCP at UDP (gamit ang iperf3), mga totoong application tulad ng HTTP (na may Nginx at curl) o FTP (na may vsftpd at curl) at panghuli ang pagganap ng application gamit ang SCP-based encryption (gamit ang client at server na OpenSSH).
Para sa lahat ng pagsubok, nagsagawa kami ng bare metal na benchmark (berdeng linya) upang ihambing ang pagganap ng CNI sa pagganap ng katutubong network. Dito ginagamit namin ang parehong sukat, ngunit sa kulay:
- Dilaw = napakahusay
- Orange = mabuti
- Asul = kaya-kaya
- Pula = masama
Hindi kami kukuha ng mga maling na-configure na CNI at magpapakita lamang ng mga resulta para sa mga CNI na may tamang MTU. (Tandaan: Hindi wastong kinakalkula ng Cilium ang MTU kung pinagana mo ang pag-encrypt, kaya kakailanganin mong manu-manong bawasan ang MTU sa 8900 sa bersyon 1.4. Ang susunod na bersyon, 1.5, ay awtomatikong ginagawa ito.)
Narito ang mga resulta:
Pagganap ng TCP
Mahusay na gumanap ang lahat ng CNI sa benchmark ng TCP. Ang CNI na may encryption ay nahuhuli dahil mahal ang encryption.
Pagganap ng UDP
Dito rin, lahat ng CNI ay gumagana nang maayos. Ang CNI na may encryption ay nagpakita ng halos parehong resulta. Ang Cilium ay medyo nasa likod ng kumpetisyon, ngunit ito ay 2,3% lamang ng bare metal, kaya hindi ito isang masamang resulta. Huwag kalimutan na ang Cilium at Flannel lang ang mismong nagtukoy ng MTU nang tama, at ito ang kanilang mga resulta nang walang anumang karagdagang configuration.
Paano ang tungkol sa isang tunay na aplikasyon? Tulad ng nakikita mo, ang pangkalahatang pagganap para sa HTTP ay bahagyang mas mababa kaysa sa TCP. Kahit na gumamit ka ng HTTP sa TCP, na-configure namin ang iperf3 sa benchmark ng TCP upang maiwasan ang mabagal na pagsisimula na makakaapekto sa benchmark ng HTTP. Maganda ang ginawa ng lahat dito. Ang Kube-router ay may malinaw na kalamangan, ngunit ang WeaveNet ay hindi gumanap nang maayos: humigit-kumulang 20% ββna mas masahol pa kaysa sa hubad na metal. Ang Cilium at WeaveNet na may encryption ay mukhang malungkot.
Sa FTP, isa pang protocol na nakabatay sa TCP, iba-iba ang mga resulta. Ginagawa ng flannel at Kube-router ang trabaho, ngunit ang Calico, Canal at Cilium ay medyo nasa likod at humigit-kumulang 10% na mas mabagal kaysa sa hubad na metal. Ang WeaveNet ay nasa likod ng hanggang 17%, ngunit ang naka-encrypt na WeaveNet ay 40% nangunguna sa naka-encrypt na Cilium.
Sa SCP makikita natin kaagad kung magkano ang halaga ng SSH encryption sa atin. Halos lahat ng CNI ay gumagana nang maayos, ngunit ang WeaveNet ay nahuhuli na naman. Ang Cilium at WeaveNet na may encryption ay inaasahang ang pinakamasama dahil sa double encryption (SSH + CNI).
Narito ang isang talahanayan ng buod na may mga resulta:
Pagkonsumo ng mapagkukunan
Ngayon, ihambing natin kung paano kumukonsumo ang CNI ng mga mapagkukunan sa ilalim ng mabibigat na karga (sa panahon ng paglilipat ng TCP, 10 Gbps). Sa mga pagsubok sa pagganap, inihahambing namin ang CNI sa bare metal (berdeng linya). Para sa pagkonsumo ng mapagkukunan, ipakita natin ang mga purong Kubernetes (linya ng lila) na walang CNI at tingnan kung gaano karaming mga karagdagang mapagkukunan ang natupok ng CNI.
Magsimula tayo sa memorya. Narito ang average na halaga para sa RAM ng mga node (hindi kasama ang mga buffer at cache) sa MB sa panahon ng paglilipat.
Pagkonsumo ng memorya
Ang flannel at Kube-router ay nagpakita ng mahusay na mga resulta - 50 MB lamang. Ang Calico at Canal ay may tig-70. Ang WeaveNet ay malinaw na kumokonsumo ng higit sa iba - 130 MB, at Cilium ay gumagamit ng hanggang 400.
Ngayon suriin natin ang pagkonsumo ng oras ng CPU. Kapansin-pansin: ang diagram ay hindi nagpapakita ng mga porsyento, ngunit ang ppm, iyon ay, 38 ppm para sa "bare iron" ay 3,8%. Narito ang mga resulta:
pagkonsumo ng CPU
Ang Calico, Canal, Flannel at Kube-router ay napakahusay ng CPU - 2% lamang ang higit sa Kubernetes na walang CNI. Nahuhuli ang WeaveNet na may dagdag na 5%, na sinusundan ng Cilium sa 7%.
Narito ang isang buod ng pagkonsumo ng mapagkukunan:
Mga resulta ng
Talahanayan na may lahat ng resulta:
Pangkalahatang benchmark na mga resulta
Konklusyon
Sa huling bahagi ay ipapahayag ko ang aking pansariling opinyon sa mga resulta. Tandaan na ang benchmark na ito ay sumusubok lamang sa throughput ng isang koneksyon sa isang napakaliit na cluster (3 node). Hindi ito nalalapat sa malalaking kumpol (<50 node) o parallel na koneksyon.
Inirerekomenda ko ang paggamit ng mga sumusunod na CNI depende sa senaryo:
- Mayroon ka ba sa iyong cluster mga node na may kaunting mapagkukunan (ilang GB ng RAM, maraming mga core) at hindi mo kailangan ng mga tampok sa seguridad - pumili pranela. Ito ay isa sa mga pinaka-cost-effective na CNI. At ito ay katugma sa iba't ibang uri ng mga arkitektura (amd64, braso, arm64, atbp.). Bilang karagdagan, ito ay isa sa dalawa (ang isa ay Cilium) CNI na maaaring awtomatikong matukoy ang MTU, kaya hindi mo kailangang i-configure ang anuman. Angkop din ang Kube-router, ngunit hindi ito bilang pamantayan at kakailanganin mong manu-manong i-configure ang MTU.
- Kung kinakailangan i-encrypt ang network para sa kaligtasan, kunin WeaveNet. Huwag kalimutang tukuyin ang laki ng MTU kung gumagamit ka ng mga jumbo frame, at paganahin ang pag-encrypt sa pamamagitan ng pagtukoy ng password sa pamamagitan ng environment variable. Ngunit mas mabuting kalimutan ang tungkol sa pagganap - iyon ang halaga ng pag-encrypt.
- Para sa normal na gamit Π‘ΠΎΠ²Π΅ΡΡΡ kalenkor. Ang CNI na ito ay malawakang ginagamit sa iba't ibang mga tool sa pag-deploy ng Kubernetes (Kops, Kubespray, Rancher, atbp.). Tulad ng sa WeaveNet, tiyaking i-configure ang MTU sa ConfigMap kung gumagamit ng mga jumbo frame. Ito ay isang multi-functional na tool na mahusay sa mga tuntunin ng pagkonsumo ng mapagkukunan, pagganap at seguridad.
At sa wakas, ipinapayo ko sa iyo na sundin ang pag-unlad Sili. Ang CNI na ito ay may napakaaktibong koponan na gumagana nang husto sa kanilang produkto (mga tampok, pagtitipid ng mapagkukunan, pagganap, seguridad, clustering...) at mayroon silang napakakagiliw-giliw na mga plano.
Visual diagram para sa pagpili ng CNI
Pinagmulan: www.habr.com