Tämä on minun päivitykseni , joka toimii nyt Kubernetes 1.14:ssä ja uusimmalla CNI-versiolla huhtikuussa 2019.
Ensinnäkin haluan kiittää Cilium-tiimiä: kaverit auttoivat minua tarkistamaan ja korjaamaan mittareiden seurantaskriptit.
Mikä on muuttunut marraskuun 2018 jälkeen
Tässä on, mikä on muuttunut sen jälkeen (jos olet kiinnostunut):
Flanelli on edelleen nopein ja yksinkertaisin CNI-liitäntä, mutta se ei silti tue verkkokäytäntöjä ja salausta.
Romanaa ei enää tueta, joten olemme poistaneet sen vertailuarvosta.
WeaveNet tukee nyt Ingressin ja Egressin verkkokäytäntöjä! Mutta tuottavuus on laskenut.
Calicossa sinun on silti määritettävä manuaalisesti suurin pakettikoko (MTU) parhaan suorituskyvyn saavuttamiseksi. Calico tarjoaa kaksi vaihtoehtoa CNI:n asentamiseen, joten voit tehdä ilman erillistä ETCD-arkistoa:
- tallennustilan Kubernetes API:ssa tietovarastona (klusterin koko < 50 solmua);
- tallennustilan Kubernetes API:ssa tietovarastona Typha-välityspalvelimen kanssa K8S API:n kuormituksen keventämiseksi (klusterin koko > 50 solmua).
Calico ilmoitti tukensa Istion päälle sovellustason suojausta varten.
Cilium tukee nyt salausta! Cilium tarjoaa salauksen IPSec-tunneleilla ja tarjoaa vaihtoehdon salatulle WeaveNet-verkolle. Mutta WeaveNet on nopeampi kuin Cilium salauksen ollessa käytössä.
Cilium on nyt helpompi ottaa käyttöön sisäänrakennetun ETCD-operaattorin ansiosta.
Cilium-tiimi on yrittänyt leikata painoaan CNI:stä vähentämällä muistin kulutusta ja prosessorikustannuksia, mutta sen kilpailijat ovat edelleen kevyempiä.
Vertailukonteksti
Vertailuarvoa ajetaan kolmella ei-virtualisoidulla Supermicro-palvelimella, joissa on 10 Gt:n Supermicro-kytkin. Palvelimet on kytketty suoraan kytkimeen passiivisilla DAC SFP+ -kaapeleilla ja ne on konfiguroitu samaan VLANiin jumbo-kehyksillä (MTU 9000).
Kubernetes 1.14.0 asennettuna Ubuntu 18.04 LTS:ään ja Docker 18.09.2:een (oletusarvoinen Docker-versio tässä julkaisussa).
Toistettavuuden parantamiseksi päätimme määrittää aina isäntäyksikön ensimmäiseen solmuun, sijoittaa vertailuarvon palvelinosan toiseen palvelimeen ja asiakasosan kolmanteen palvelimeen. Käytämme tätä varten NodeSelectoria Kubernetes-asetuksissa.
Kuvaamme benchmark-tuloksia seuraavalla asteikolla:
CNI:n valitseminen vertailuarvoksi
Tämä on vertailukohta vain CNI:lle osion luettelosta Katso virallinen Kubernetes-dokumentaatio. Yhdeksästä CNI:stä otamme vain kuusi: jätämme pois ne, jotka on vaikea asentaa ja/tai jotka eivät toimi ilman konfiguraatiota dokumentaation mukaan (Romana, Contiv-VPP ja JuniperContrail/TungstenFabric).
Vertailemme seuraavia CNI:itä:
- Calico v3.6
- Canal v3.6 (lähinnä Flannel verkkokäyttöön + Calico palomuurina)
- Cilium 1.4.2
- Flanelli 0.11.0
- Kube-reititin 0.2.5
- WeaveNet 2.5.1
Asennus
Mitä helpompi CNI on asentaa, sitä parempi ensivaikutelma on. Kaikki benchmarkin CNI:t on erittäin helppo asentaa (yhdellä tai kahdella komennolla).
Kuten sanoimme, palvelimet ja kytkin on määritetty jumbo-kehykset käytössä (asetimme MTU:ksi 9000). Olisimme iloisia, jos CNI määrittäisi MTU:n automaattisesti sovitinten kokoonpanon perusteella. Kuitenkin vain Cilium ja Flannel onnistuivat tässä. Muilla CNI:illä on GitHubissa pyyntöjä lisätä automaattinen MTU-etsintä, mutta määritämme sen manuaalisesti muuttamalla ConfigMapia Calicon, Canalin ja Kube-reitittimelle tai välittämällä ympäristömuuttujan WeaveNetille.
Mikä on virheellisen MTU:n ongelma? Tämä kaavio näyttää eron WeaveNetin välillä, kun oletus-MTU ja jumbokehykset ovat käytössä:
Miten MTU vaikuttaa suoritustehoon?
Olemme nähneet, kuinka tärkeä MTU on suorituskyvylle. Katsotaan nyt, kuinka CNI:mme määrittävät sen automaattisesti:
CNI tunnistaa automaattisesti MTU:n
Kaavio osoittaa, että sinun on määritettävä MTU Calicon, Canalin, Kube-reitittimen ja WeaveNetin optimaalista suorituskykyä varten. Cilium ja Flannel pystyivät määrittämään MTU:n oikein ilman asetuksia.
Безопасность
Vertailemme CNI-turvallisuutta kahdessa suhteessa: kyky salata siirretyt tiedot ja Kubernetes-verkkokäytäntöjen toteutus (perustuu todellisiin testeihin, ei dokumentaatioon).
Vain kaksi CNI:tä salaa tiedot: Cilium ja WeaveNet. Salaus WeaveNet otetaan käyttöön asettamalla salaussalasana CNI-ympäristömuuttujaksi. SISÄÄN WeaveNet kuvaa sitä monimutkaisesti, mutta kaikki tehdään yksinkertaisesti. Salaus ripsi määritetty komennoilla, luomalla Kubernetes-salaisuuksia ja muokkaamalla daemonSet (hieman monimutkaisempi kuin WeaveNetissä, mutta Ciliumissa on vaihe vaiheelta ).
Mitä tulee verkkopolitiikan toimeenpanoon, he ovat onnistuneet Calico, Canal, Cilium ja WeaveNet, jossa voit määrittää sisään- ja poistumissäännöt. varten Kube-reititin säännöt ovat vain Ingressille ja Flanelli Verkkokäytäntöjä ei ole ollenkaan.
Tässä kokonaistulokset:
Turvallisuussuorituskykyvertailutulokset
Suorituskyky
Tämä vertailuarvo näyttää keskimääräisen suorituskyvyn vähintään kolmen kunkin testin ajon aikana. Testaamme TCP:n ja UDP:n (iperf3:lla), oikeiden sovellusten, kuten HTTP:n (Nginx ja curl) tai FTP:n (vsftpd ja curl) ja lopuksi sovellusten suorituskyvyn SCP-pohjaisella salauksella (käyttäen asiakas- ja palvelin OpenSSH:ta).
Kaikille testeille suoritimme paljaan metallin vertailuarvon (vihreä viiva) vertaillaksemme CNI-suorituskykyä alkuperäisen verkon suorituskykyyn. Tässä käytämme samaa asteikkoa, mutta väreissä:
- Keltainen = erittäin hyvä
- Oranssi = hyvä
- Sininen = niin-niin
- Punainen = huono
Emme ota väärin määritettyjä CNI:itä ja näytämme tulokset vain niille CNI:ille, joilla on oikea MTU. (Huomaa: Cilium ei laske MTU:ta oikein, jos otat salauksen käyttöön, joten sinun on vähennettävä MTU manuaalisesti 8900:aan versiossa 1.4. Seuraava versio, 1.5, tekee tämän automaattisesti.)
Tässä tulokset:
TCP-suorituskyky
Kaikki CNI:t suoriutuivat hyvin TCP-benchmarkissa. Salauksella varustettu CNI on paljon jäljessä, koska salaus on kallista.
UDP-suorituskyky
Myös täällä kaikki CNI:t voivat hyvin. CNI salauksella osoitti melkein saman tuloksen. Cilium on hieman kilpailijaa jäljessä, mutta se on vain 2,3 % paljaasta metallista, joten tulos ei ole huono. Älä unohda, että vain Cilium ja Flannel määrittelivät MTU:n oikein itse, ja nämä ovat heidän tulokset ilman lisämäärityksiä.
Entä todellinen sovellus? Kuten näet, HTTP:n kokonaissuorituskyky on hieman pienempi kuin TCP:n. Vaikka käyttäisit HTTP:tä TCP:n kanssa, määritimme iperf3:n TCP-vertailuarvoon välttääksemme hitaan käynnistyksen, joka vaikuttaisi HTTP-vertailuarvoon. Kaikki tekivät hyvää työtä täällä. Kube-reitittimellä on selvä etu, mutta WeaveNet ei toiminut hyvin: noin 20% huonommin kuin paljas metalli. Cilium ja WeaveNet salauksella näyttävät todella surullisilta.
FTP:llä, toisella TCP-pohjaisella protokollalla, tulokset vaihtelevat. Flanelli ja Kube-reititin tekevät työn, mutta Calico, Canal ja Cilium ovat hieman jäljessä ja ovat noin 10% hitaampia kuin paljas metalli. WeaveNet on jäljessä jopa 17 %, mutta salattu WeaveNet on 40 % salattua Ciliumia edellä.
SCP:n avulla näemme heti, kuinka paljon SSH-salaus meille maksaa. Lähes kaikki CNI:t voivat hyvin, mutta WeaveNet on jälleen jäljessä. Cilium ja WeaveNet salauksella ovat odotetusti pahimpia kaksoissalauksen (SSH + CNI) vuoksi.
Tässä on yhteenvetotaulukko tuloksista:
Resurssien kulutus
Verrataan nyt kuinka CNI kuluttaa resursseja raskaan kuormituksen aikana (TCP-siirron aikana, 10 Gbps). Suorituskykytesteissä vertaamme CNI:tä paljaaseen metalliin (vihreä viiva). Näytetään resurssien kulutuksen osalta puhdas Kubernetes (violetti viiva) ilman CNI:tä ja katsotaan kuinka monta lisäresurssia CNI kuluttaa.
Aloitetaan muistista. Tässä on keskimääräinen arvo solmujen RAM-muistille (pois lukien puskurit ja välimuisti) megatavuina siirron aikana.
Muistin kulutus
Flanelli ja Kube-reititin osoittivat erinomaisia tuloksia - vain 50 MB. Calico ja Canal ovat kumpikin 70. WeaveNet kuluttaa selvästi enemmän kuin muut - 130 Mt, ja Cilium jopa 400.
Tarkastellaan nyt suorittimen ajankulutusta. Huomionarvoista: kaaviossa ei näy prosentteja, vaan ppm, eli 38 ppm "paljaalla raudalla" on 3,8%. Tässä tulokset:
CPU:n kulutus
Calico, Canal, Flannel ja Kube-reititin ovat erittäin CPU-tehokkaita - vain 2 % enemmän kuin Kubernetes ilman CNI:tä. WeaveNet on paljon jäljessä ylimääräisellä 5 prosentilla, jota seuraa Cilium 7 prosentilla.
Tässä on yhteenveto resurssien kulutuksesta:
Tulokset
Taulukko kaikista tuloksista:
Yleiset vertailutulokset
Johtopäätös
Viimeisessä osassa ilmaisen subjektiivisen mielipiteeni tuloksista. Muista, että tämä vertailuarvo testaa vain yhden yhteyden suorituskyvyn hyvin pienessä klusterissa (3 solmua). Se ei koske suuria klustereita (<50 solmua) tai rinnakkaisia yhteyksiä.
Suosittelen seuraavien CNI:iden käyttöä skenaariosta riippuen:
- Onko sinulla klusterissasi solmuja, joilla on vähän resursseja (useita Gt RAM-muistia, useita ytimiä) etkä tarvitse suojausominaisuuksia - valitse Flanelli. Tämä on yksi kustannustehokkaimmista CNI:istä. Ja se on yhteensopiva useiden arkkitehtuurien kanssa (amd64, arm, arm64 jne.). Lisäksi tämä on toinen kahdesta (toinen on Cilium) CNI, joka voi määrittää automaattisesti MTU:n, joten sinun ei tarvitse määrittää mitään. Kube-reititin on myös sopiva, mutta se ei ole vakio ja sinun on määritettävä MTU manuaalisesti.
- Tarvittaessa salaa verkko varmuuden vuoksi ota WeaveNet. Älä unohda määrittää MTU-kokoa, jos käytät jumbo-kehyksiä, ja ota salaus käyttöön määrittämällä salasana ympäristömuuttujan kautta. Mutta on parempi unohtaa suorituskyky - se on salauksen hinta.
- varten normaalissa käytössä Neuvon kalikoo. Tätä CNI:tä käytetään laajasti erilaisissa Kubernetes-käyttöönottotyökaluissa (Kops, Kubespray, Rancher jne.). Kuten WeaveNetissä, muista määrittää MTU ConfigMapissa, jos käytät jumbo-kehyksiä. Se on monikäyttöinen työkalu, joka on tehokas resurssien kulutuksen, suorituskyvyn ja turvallisuuden kannalta.
Ja lopuksi neuvon sinua seuraamaan kehitystä ripsi. Tällä CNI:llä on erittäin aktiivinen tiimi, joka työskentelee paljon tuotteensa parissa (ominaisuudet, resurssien säästöt, suorituskyky, tietoturva, klusterit...) ja heillä on erittäin mielenkiintoisia suunnitelmia.
Visuaalinen kaavio CNI-valinnasta
Lähde: will.com