ProHoster > Blog > Pangangasiwa > Pagtatasa ng pagganap ng CNI para sa Kubernetes sa 10G network (Agosto 2020)
Pagtatasa ng pagganap ng CNI para sa Kubernetes sa 10G network (Agosto 2020)
TL; DR: Gumagana ang lahat ng CNI ayon sa nararapat, maliban sa Kube-Router at Kube-OVN, ang Calico, maliban sa awtomatikong pagtukoy ng MTU, ay ang pinakamahusay.
Artikulo-update ng aking mga nakaraang pagsusuri (2018 ΠΈ 2019), sa oras ng pagsubok ay gumagamit ako ng Kubernetes 1.19 sa Ubuntu 18.04 na may mga na-update na CNI noong Agosto 2020.
Bago tayo sumisid sa mga sukatan...
Ano ang bago mula noong Abril 2019?
Maaaring subukan sa iyong sariling cluster: Maaari kang magpatakbo ng mga pagsubok sa iyong sariling cluster gamit ang aming tool Benchmark ng Kubernetes Network: knb
Mga Bagong Sitwasyon: Ang mga kasalukuyang pagsusuri ay nagpapatakbo ng mga pagsubok sa pagganap ng network na "Pod-to-Pod", at isang bagong script na "Pod-to-Service" ang idinagdag na nagpapatakbo ng mga pagsubok na mas malapit sa mga tunay na kondisyon sa mundo. Sa pagsasagawa, ang iyong Pod na may API ay gumagana sa base bilang isang serbisyo, at hindi sa pamamagitan ng Pod ip address (siyempre sinusuri namin ang parehong TCP at UDP para sa parehong mga sitwasyon).
Pagkonsumo ng mapagkukunan: ang bawat pagsubok ay mayroon na ngayong sariling paghahambing ng mapagkukunan
Pag-aalis ng Mga Pagsusuri sa Application: Hindi na kami nagsasagawa ng mga pagsubok sa HTTP, FTP at SCP dahil ang aming mabungang pakikipagtulungan sa komunidad at mga tagapanatili ng CNI ay nakatuklas ng agwat sa pagitan ng mga resulta ng iperf sa mga resulta ng TCP at curl dahil sa pagkaantala sa pagsisimula ng CNI (ang unang ilang segundo ng Pod startup, na hindi karaniwan sa mga tunay na kondisyon).
Open source: available ang lahat ng test source (mga script, yml setting at orihinal na βrawβ data). dito
Reference Test Protocol
Ang protocol ay inilarawan nang detalyado ditoPakitandaan na ang artikulong ito ay tungkol sa Ubuntu 18.04 na may default na kernel.
Pagpili ng CNI para sa Pagtatasa
Ang pagsubok na ito ay naglalayong ihambing ang mga CNI na na-configure sa isang yaml file (samakatuwid, ang lahat ng na-install ng mga script, tulad ng VPP at iba pa, ay hindi kasama).
Una sa lahat, sinusuri namin ang epekto ng awtomatikong pagtuklas ng MTU sa pagganap ng TCP:
Epekto ng MTU sa Pagganap ng TCP
Mas malaking gap ang makikita kapag gumagamit ng UDP:
Epekto ng MTU sa Pagganap ng UDP
Dahil sa MALAKING epekto sa performance na ipinakita sa mga pagsubok, gusto naming magpadala ng liham ng pag-asa sa lahat ng CNI maintainers: mangyaring magdagdag ng awtomatikong MTU detection sa CNI. Makakatipid ka ng mga kuting, unicorn at maging ang pinaka-cute: ang maliit na Devop.
Gayunpaman, kung kailangan mong gumamit ng CNI nang walang suporta para sa awtomatikong pagtuklas ng MTU, maaari mo itong i-configure nang manu-mano upang makakuha ng pagganap. Pakitandaan na nalalapat ito sa Calico, Canal at WeaveNet.
Ang aking munting kahilingan sa mga kasamang CNI...
Pagsusuri ng CNI: Raw Data
Sa seksyong ito, ihahambing namin ang CNI sa tamang MTU (awtomatikong tinutukoy o manu-manong itinakda). Ang pangunahing layunin dito ay ipakita ang raw data sa mga graph.
Alamat ng kulay:
kulay abo - sample (i.e. hubad na bakal)
berde - bandwidth na higit sa 9500 Mbps
dilaw - bandwidth na higit sa 9000 Mbps
orange - bandwidth na higit sa 8000 Mbps
pula - bandwidth na mas mababa sa 8000 Mbps
asul - neutral (hindi nauugnay sa bandwidth)
Walang-load na pagkonsumo ng mapagkukunan
Una sa lahat, suriin ang pagkonsumo ng mapagkukunan kapag ang cluster ay "natutulog".
Walang-load na pagkonsumo ng mapagkukunan
Pod-to-Pod
Ipinapalagay ng sitwasyong ito na direktang kumokonekta ang Pod ng kliyente sa Pod ng server gamit ang IP address nito.
Pod-to-Pod Scenario
TCP
Mga resulta ng Pod-to-Pod TCP at kaukulang pagkonsumo ng mapagkukunan:
UDP
Mga resulta ng Pod-to-Pod UDP at kaukulang pagkonsumo ng mapagkukunan:
Pod-to-Serbisyo
Ang seksyong ito ay may kaugnayan para sa mga tunay na kaso ng paggamit, ang client Pod ay kumokonekta sa server Pod sa pamamagitan ng ClusterIP service.
Pod-to-Service Script
TCP
Mga resulta ng Pod-to-Service TCP at kaukulang pagkonsumo ng mapagkukunan:
UDP
Mga resulta ng Pod-to-Service na UDP at kaukulang pagkonsumo ng mapagkukunan:
Suporta sa patakaran sa network
Sa lahat ng nabanggit, ang tanging hindi sumusuporta sa pulitika ay ang Flannel. Ang lahat ng iba ay wastong nagpapatupad ng mga patakaran sa network, kabilang ang papasok at palabas. Mahusay na trabaho!
Pag-encrypt ng CNI
Kabilang sa mga naka-check na CNI ay mayroong mga maaaring mag-encrypt ng palitan ng network sa pagitan ng mga Pod:
Antrea gamit ang IPsec
Calico gamit ang wireguard
Cilium gamit ang IPsec
WeaveNet gamit ang IPsec
Throughput
Dahil mas kaunti na ang mga CNI, ilagay natin ang lahat ng mga sitwasyon sa isang graph:
Pagkonsumo ng mapagkukunan
Sa seksyong ito, susuriin namin ang mga mapagkukunang ginagamit kapag nagpoproseso ng komunikasyon ng Pod-to-Pod sa TCP at UDP. Walang saysay ang pagguhit ng graph ng Pod-to-Service dahil hindi ito nagbibigay ng karagdagang impormasyon.
Pinagsasama-sama ang lahat
Subukan nating ulitin ang lahat ng mga graph, ipinakilala namin ang isang maliit na subjectivity dito, pinapalitan ang aktwal na mga halaga ng mga salitang "vwry fast", "low", atbp.
Konklusyon at ang aking mga konklusyon
Ito ay isang maliit na subjective, dahil ako ay nagdadala ng aking sariling interpretasyon ng mga resulta.
Natutuwa ako na lumitaw ang mga bagong CNI, mahusay na gumanap ang Antrea, maraming mga function ang ipinatupad kahit na sa mga unang bersyon: awtomatikong MTU detection, pag-encrypt at madaling pag-install.
Kung ihahambing namin ang pagganap, gumagana nang maayos ang lahat ng CNI, maliban sa Kube-OVN at Kube-Router. Hindi rin na-detect ng Kube-Router ang MTU, hindi ako nakahanap ng paraan para i-configure ito kahit saan sa dokumentasyon (dito bukas ang isang kahilingan sa paksang ito).
Sa mga tuntunin ng pagkonsumo ng mapagkukunan, ang Cilium ay gumagamit pa rin ng mas maraming RAM kaysa sa iba, ngunit malinaw na tina-target ng tagagawa ang malalaking kumpol, na malinaw na hindi katulad ng isang pagsubok sa isang tatlong-node na kumpol. Ang Kube-OVN ay gumagamit din ng maraming mapagkukunan ng CPU at RAM, ngunit ito ay isang batang CNI batay sa Open vSwitch (tulad ng Antrea, ito ay gumaganap nang mas mahusay at kumonsumo ng mas kaunti).
Ang lahat maliban sa Flannel ay may mga patakaran sa network. Malamang na hindi niya sila susuportahan, dahil ang layunin ay mas simple kaysa sa isang steamed turnip: mas magaan, mas mabuti.
Gayundin, bukod sa iba pang mga bagay, ang pagganap ng pag-encrypt ay kamangha-manghang. Ang Calico ay isa sa mga pinakalumang CNI, ngunit idinagdag lamang ang pag-encrypt ilang linggo na ang nakalipas. Pinili nila ang wireguard sa halip na IPsec, at sa madaling salita, ito ay gumagana nang mahusay at kamangha-manghang, ganap na nalalampasan ang iba pang mga CNI sa bahaging ito ng pagsubok. Siyempre, ang pagkonsumo ng mapagkukunan ay tumataas dahil sa pag-encrypt, ngunit ang throughput na nakamit ay sulit (Nagpakita ang Calico ng anim na beses na pagpapabuti sa pagsubok ng pag-encrypt kumpara sa Cilium, na pumapangalawa). Bukod dito, maaari mong paganahin ang wireguard anumang oras pagkatapos mong i-deploy ang Calico sa cluster, at maaari mo ring i-disable ito sa maikling panahon o permanente kung gusto mo. Ito ay hindi kapani-paniwalang maginhawa, bagaman! Ipinapaalala namin sa iyo na kasalukuyang hindi na-auto-detect ng Calico ang MTU (pinlano ang feature na ito para sa mga susunod na bersyon), kaya siguraduhing i-configure ang MTU kung sinusuportahan ng iyong network ang Jumbo Frames (MTU 9000).
Sa iba pang mga bagay, tandaan na maaaring i-encrypt ng Cilium ang trapiko sa pagitan ng mga cluster node (at hindi lamang sa pagitan ng Pods), na maaaring maging napakahalaga para sa mga pampublikong cluster node.
Bilang konklusyon, iminumungkahi ko ang mga sumusunod na kaso ng paggamit:
Kailangan ng CNI para sa napakaliit na kumpol O hindi ko kailangan ng seguridad: magtrabaho kasama pranela, ang pinakamagaan at pinaka-matatag na CNI (isa rin siya sa pinakamatanda, ayon sa alamat ay naimbento siya ni Homo Kubernautus o Homo Contaitorus). Maaari ka ring maging interesado sa pinaka mapanlikhang proyekto k3s, tingnan mo!
Kailangan ng CNI para sa isang regular na kumpol: kalenkor - iyong pinili, ngunit huwag kalimutang i-configure ang MTU kung kinakailangan. Madali at natural mong makalaro ang mga patakaran sa network, i-on at i-off ang pag-encrypt, atbp.
Kailangan ng CNI para sa (napakalaking) cluster: Buweno, ang pagsubok ay hindi nagpapakita ng pag-uugali ng malalaking kumpol, natutuwa akong magsagawa ng mga pagsubok, ngunit wala kaming daan-daang mga server na may koneksyon na 10Gbps. Kaya ang pinakamagandang opsyon ay magpatakbo ng isang binagong pagsubok sa iyong mga node, kahit man lang sa Calico at Cilium.