Ĉi tio estas mia ĝisdatigo , kiu nun funkcias per Kubernetes 1.14 kun la plej nova CNI-versio ekde aprilo 2019.
Antaŭ ĉio, mi volas danki la Cilium-teamon: la uloj helpis min kontroli kaj korekti la metrikajn monitorajn skriptojn.
Kio ŝanĝiĝis ekde novembro 2018
Jen kio ŝanĝiĝis ekde tiam (se vi interesiĝas):
Flanelo restas la plej rapida kaj simpla CNI-interfaco, sed ankoraŭ ne subtenas retajn politikojn kaj ĉifradon.
Romana ne plu estas subtenata, do ni forigis ĝin de la komparnormo.
WeaveNet nun subtenas retajn politikojn por Eniro kaj Eliro! Sed produktiveco malpliiĝis.
En Calico, vi ankoraŭ devas mane agordi la maksimuman pakaĵgrandecon (MTU) por plej bona agado. Calico ofertas du eblojn por instali CNI, do vi povas malhavi apartan ETCD-deponejon:
- konservado de stato en la Kubernetes API kiel datumvendejo (grupo grandeco < 50 nodoj);
- konservanta staton en la Kubernetes API kiel datumbutiko kun Typha prokurilo por malpezigi la ŝarĝon sur la K8S API (grupo grandeco > 50 nodoj).
Calico anoncis subtenon supre de Istio por aplikiĝ-nivela sekureco.
Cilium nun subtenas ĉifradon! Cilium provizas ĉifradon per IPSec-tuneloj kaj ofertas alternativon al la ĉifrita WeaveNet-reto. Sed WeaveNet estas pli rapida ol Cilium kun ĉifrado ebligita.
Cilium nun estas pli facile deplojebla danke al la enkonstruita ETCD-funkciigisto.
La Cilium-teamo provis tranĉi iom da pezo de sia CNI reduktante memorkonsumon kaj CPU-kostojn, sed ĝiaj konkurantoj ankoraŭ estas pli malpezaj.
Benchmark kunteksto
La komparnormo funkcias per tri ne-virtualigitaj Supermicro-serviloj kun 10 Gb Supermicro-ŝaltilo. La serviloj estas konektitaj rekte al la ŝaltilo per pasivaj DAC SFP+-kabloj kaj estas agorditaj sur la sama VLAN kun jumbo-kadroj (MTU 9000).
Kubernetes 1.14.0 instalita sur Ubuntu 18.04 LTS kun Docker 18.09.2 (la defaŭlta Docker-versio en ĉi tiu eldono).
Por plibonigi reprodukteblecon, ni decidis ĉiam agordi la majstron sur la unua nodo, meti la servilan parton de la komparnormo sur la dua servilo, kaj la klienta parto sur la tria. Por fari tion, ni uzas NodeSelector en Kubernetes-deplojoj.
Ni priskribos la komparnormajn rezultojn sur la sekva skalo:
Elektante CNI por komparnormo
Ĉi tio estas komparnormo nur por CNI el la listo en la sekcio Vidu la oficialan dokumentaron de Kubernetes. El la 9 CNI-oj, ni prenos nur 6: ni ekskludos tiujn, kiuj estas malfacile instaleblaj kaj/aŭ ne funkcias sen agordo laŭ la dokumentado (Romana, Contiv-VPP kaj JuniperContrail/TungstenFabric).
Ni komparos la sekvajn CNIojn:
- Calico v3.6
- Kanalo v3.6 (esence Flanelo por interkonektado + Calico kiel fajroŝirmilo)
- Cilio 1.4.2
- Flanelo 0.11.0
- Kube-enkursigilo 0.2.5
- WeaveNet 2.5.1
fikso
Ju pli facile instalos la CNI, des pli bona estos nia unua impreso. Ĉiuj CNI-oj de la komparnormo estas tre facile instaleblaj (kun unu aŭ du komandoj).
Kiel ni diris, la serviloj kaj ŝaltilo estas agorditaj kun jumbo-kadroj ebligitaj (ni agordis la MTU al 9000). Ni ĝojus, se CNI aŭtomate determinus la MTU surbaze de la agordo de la adaptiloj. Tamen, nur Cilium kaj Flannel administris tion. La ceteraj CNI-oj havas petojn en GitHub por aldoni aŭtomatan MTU-malkovron, sed ni agordos ĝin permane ŝanĝante la ConfigMap por Calico, Canal kaj Kube-enkursigilo, aŭ pasante mediovariablon por WeaveNet.
Kio estas la problemo kun malĝusta MTU? Ĉi tiu diagramo montras la diferencon inter WeaveNet kun defaŭlta MTU kaj jumbo-kadroj ebligitaj:
Kiel MTU influas trairon?
Ni vidis kiom grava estas MTU por rendimento, nun ni vidu kiel niaj CNI-oj aŭtomate determinas ĝin:
CNI aŭtomate detektas MTU
La grafikaĵo montras, ke vi devas agordi la MTU por Calico, Canal, Kube-router kaj WeaveNet por optimuma rendimento. Cilium kaj Flannel povis ĝuste determini la MTU mem sen iuj agordoj.
Sekureco
Ni komparos CNI-sekurecon en du aspektoj: la kapablo ĉifri transdonitajn datumojn kaj la efektivigon de Kubernetes-retaj politikoj (bazitaj sur realaj testoj, ne dokumentado).
Nur du CNI-oj ĉifras datumojn: Cilium kaj WeaveNet. Ĉifrado WeaveNet ebligita per fikso de la ĉifrada pasvorto kiel CNI-medivariablo. EN WeaveNet priskribas ĝin en komplika maniero, sed ĉio estas farita simple. Ĉifrado Cilio agordita per komandoj, kreante Kubernetes-sekretojn, kaj per modifo de la daemonSet (iom pli komplika ol en WeaveNet, sed Cilium havas paŝon post paŝo ).
Koncerne la efektivigon de retopolitiko, ili sukcesis Calico, Kanalo, Cilium kaj WeaveNet, en kiu vi povas agordi regulojn de Eniro kaj Eliro. Por Kube-enkursigilo estas reguloj nur por Eniro, kaj Fandalo Entute ne ekzistas retaj politikoj.
Jen la ĝeneralaj rezultoj:
Sekureca Efikeco Benchmark Rezultoj
Produkteco
Ĉi tiu komparnormo montras la mezan trairon dum almenaŭ tri kuroj de ĉiu testo. Ni testas la agadon de TCP kaj UDP (uzante iperf3), realajn aplikojn kiel HTTP (kun Nginx kaj curl) aŭ FTP (kun vsftpd kaj curl) kaj finfine aplikaĵon per SCP-bazita ĉifrado (uzante klienton kaj servilon OpenSSH).
Por ĉiuj provoj, ni faris nudan metalan komparnormon (verda linio) por kompari CNI-agadon kun denaska reto-rendimento. Ĉi tie ni uzas la saman skalon, sed en koloro:
- Yellow = tre bona
- Orange = bona
- Blue = tiel tiel
- Red = malbona
Ni ne prenos malĝuste agorditajn CNI-ojn kaj nur montros rezultojn por CNI-oj kun la ĝusta MTU. (Noto: Cilium ne ĝuste kalkulas la MTU se vi ebligas ĉifradon, do vi devos permane redukti la MTU al 8900 en versio 1.4. La sekva versio, 1.5, faras tion aŭtomate.)
Jen la rezultoj:
TCP-Efikeco
Ĉiuj CNI-oj rezultis bone en la TCP-komparnormo. CNI kun ĉifrado malfruiĝas ĉar ĉifrado estas multekosta.
UDP-agado
Ankaŭ ĉi tie ĉiuj CNI-oj bone fartas. CNI kun ĉifrado montris preskaŭ la saman rezulton. Cilium estas iom malantaŭ la konkurado, sed ĝi estas nur 2,3% de nuda metalo, do ĝi ne estas malbona rezulto. Ne forgesu, ke nur Cilium kaj Flannel mem determinis la MTU ĝuste, kaj ĉi tiuj estas iliaj rezultoj sen ia aldona agordo.
Kio pri vera aplikaĵo? Kiel vi povas vidi, ĝenerala rendimento por HTTP estas iomete pli malalta ol por TCP. Eĉ se vi uzas HTTP kun TCP, ni agordis iperf3 en la TCP-komparnormo por eviti malrapidan komencon, kiu influus la HTTP-komparnormon. Ĉiuj faris bonan laboron ĉi tie. Kube-enkursigilo havas klaran avantaĝon, sed WeaveNet ne funkciis bone: ĉirkaŭ 20% pli malbona ol nuda metalo. Cilium kaj WeaveNet kun ĉifrado aspektas vere malĝojaj.
Kun FTP, alia TCP-bazita protokolo, rezultoj varias. Flanelo kaj Kube-enkursigilo faras la laboron, sed Calico, Canal kaj Cilium estas iomete malantaŭe kaj estas ĉirkaŭ 10% pli malrapidaj ol nuda metalo. WeaveNet estas malantaŭe de eĉ 17%, sed ĉifrita WeaveNet estas 40% antaŭ ĉifrita Cilium.
Kun SCP ni tuj povas vidi kiom kostas al ni SSH-ĉifrado. Preskaŭ ĉiuj CNI-oj fartas bone, sed WeaveNet denove postrestas. Cilium kaj WeaveNet kun ĉifrado estas atendite la plej malbonaj pro duobla ĉifrado (SSH + CNI).
Jen resuma tabelo kun la rezultoj:
Rimeda konsumo
Nun ni komparu kiel CNI konsumas rimedojn sub pezaj ŝarĝoj (dum TCP-translokigo, 10 Gbps). En rendimentaj testoj ni komparas CNI kun nuda metalo (verda linio). Por konsumo de rimedoj, ni montru puran Kubernetes (purpura linio) sen CNI kaj vidu kiom da kromaj rimedoj CNI konsumas.
Ni komencu per memoro. Jen la averaĝa valoro por la RAM de nodoj (ekskludante bufrojn kaj kaŝmemoron) en MB dum translokigo.
Memorkonsumo
Flanelo kaj Kube-enkursigilo montris bonegajn rezultojn - nur 50 MB. Calico kaj Canal ĉiu havas 70. WeaveNet klare konsumas pli ol la aliaj - 130 MB, kaj Cilium uzas eĉ 400.
Nun ni kontrolu la CPU-tempokonsumon. Rimarkinda: la diagramo montras ne procentojn, sed ppm, tio estas, 38 ppm por "nuda fero" estas 3,8%. Jen la rezultoj:
CPU-konsumo
Calico, Canal, Flannel kaj Kube-enkursigilo estas tre CPU efikaj - nur 2% pli ol Kubernetes sen CNI. WeaveNet malfruiĝas kun ekstra 5%, sekvita de Cilium ĉe 7%.
Jen resumo de la konsumo de rimedoj:
Rezultoj
Tabelo kun ĉiuj rezultoj:
Ĝeneralaj komparnormaj rezultoj
konkludo
En la lasta parto mi esprimos mian subjektivan opinion pri la rezultoj. Memoru, ke ĉi tiu komparnormo nur testas la trairon de ununura konekto sur tre malgranda areto (3 nodoj). Ĝi ne validas por grandaj aretoj (<50 nodoj) aŭ paralelaj ligoj.
Mi rekomendas uzi la sekvajn CNI-ojn depende de la scenaro:
- Ĉu vi havas en via areto nodoj kun malmultaj rimedoj (kelkaj GB da RAM, pluraj kernoj) kaj vi ne bezonas sekurecajn funkciojn - elektu Fandalo. Ĉi tiu estas unu el la plej kostefikaj CNIoj. Kaj ĝi kongruas kun ampleksa vario de arkitekturoj (amd64, arm, arm64, ktp.). Krome, ĉi tiu estas unu el du (la alia estas Cilium) CNI, kiuj povas aŭtomate determini la MTU, do vi ne devas agordi ion ajn. Kube-enkursigilo ankaŭ taŭgas, sed ĝi ne estas tiel norma kaj vi devos permane agordi la MTU.
- Se necesas ĉifri la reton por sekureco, prenu WeaveNet. Ne forgesu specifi la MTU-grandecon se vi uzas jumbo-kadrojn, kaj ebligi ĉifradon specifante pasvorton per mediovariablo. Sed estas pli bone forgesi pri rendimento - tio estas la kosto de ĉifrado.
- Por normala uzo советую Kalico. Ĉi tiu CNI estas vaste uzata en diversaj deplojiloj de Kubernetes (Kops, Kubespray, Rancher, ktp.). Kiel kun WeaveNet, nepre agordu la MTU en ConfigMap se vi uzas jumbo-kadrojn. Ĝi estas multfunkcia ilo, kiu estas efika laŭ konsumo de rimedoj, rendimento kaj sekureco.
Kaj fine, mi konsilas al vi sekvi la evoluon Cilio. Ĉi tiu CNI havas tre aktivan teamon, kiu multe laboras pri sia produkto (trajtoj, ŝparado de rimedoj, rendimento, sekureco, clustering...) kaj ili havas tre interesajn planojn.
Vida diagramo por CNI-elekto
fonto: www.habr.com