CNI-suorituskyvyn arviointi Kubernetesille 10G-verkossa (elokuu 2020)

TL; DR: Kaikki CNI:t toimivat kuten pitääkin, paitsi Kube-Router ja Kube-OVN, Calico, automaattista MTU-tunnistusta lukuun ottamatta, on paras.

Artikkelipäivitys aiemmista tarkastuksistani (2018 и 2019), käytän testaushetkellä Kubernetes 1.19:ää Ubuntu 18.04:ssä päivitetyillä CNI:illä elokuussa 2020.

Ennen kuin sukeltaamme mittareihin...

Mitä uutta huhtikuun 2019 jälkeen?

• Voi testata omassa klusterissasi: Voit suorittaa testejä omassa klusterissasi työkalumme avulla Kubernetes Network Benchmark: knb
• Uusia jäseniä on ilmestynyt
  • Antrea VMware Tanzulta
  • Kube-OVN osoitteesta alauda.io
• Uudet skenaariot: Nykyiset tarkistukset suorittavat "Pod-to-Pod"-verkon suorituskykytestejä, ja uusi "Pod-to-Service"-skripti on lisätty, joka suorittaa testejä lähempänä todellisia olosuhteita. Käytännössä Pod with API toimii tukikohdan kanssa palveluna, ei Pod-ip-osoitteen kautta (tietenkin tarkistamme sekä TCP:n että UDP:n molemmissa skenaarioissa).
• Resurssien kulutus: jokaisessa testissä on nyt oma resurssivertailu
• Sovellustestien poistaminen: Emme enää tee HTTP-, FTP- ja SCP-testejä, koska hedelmällinen yhteistyömme yhteisön ja CNI-ylläpitäjien kanssa on havainnut aukon TCP:n iperf-tulosten ja curl-tulosten välillä CNI-käynnistyksen viivästymisen vuoksi (Podin ensimmäiset sekunnit). käynnistys, mikä ei ole tyypillistä todellisissa olosuhteissa).
• Avoin lähdekoodi: kaikki testilähteet (skriptit, yml-asetukset ja alkuperäinen "raaka" data) ovat saatavilla täällä

Viitetestiprotokolla

Protokolla on kuvattu yksityiskohtaisesti täälläHuomaa, että tämä artikkeli käsittelee Ubuntu 18.04:ää oletusytimen kanssa.

CNI:n valitseminen arviointia varten

Tämän testauksen tarkoituksena on vertailla yhteen yaml-tiedostoon määritettyjä CNI:itä (täten kaikki skriptien, kuten VPP ja muut, asentamat ovat poissuljettuja).

Valitsemamme CNI:t vertailuun:

• Antrea v.0.9.1
• Calico v3.16
• Canal v3.16 (Flannel-verkko + Calicon verkkokäytännöt)
• Cilium 1.8.2
• Flanelli 0.12.0
• Kube-reititin uusin (2020–08–25)
• WeaveNet 2.7.0

MTU:n määrittäminen CNI:lle

Ensinnäkin tarkistamme automaattisen MTU-tunnistuksen vaikutuksen TCP:n suorituskykyyn:

MTU:n vaikutus TCP:n suorituskykyyn

Vielä suurempi aukko löytyy UDP:tä käytettäessä:

MTU:n vaikutus UDP:n suorituskykyyn

Ottaen huomioon testeissä paljastuneet VALTAVAT suorituskykyvaikutukset, haluamme lähettää toivon kirjeen kaikille CNI-ylläpitäjille: lisää automaattinen MTU-tunnistus CNI:hen. Säästät kissanpentuja, yksisarvisia ja jopa suloisimman: pienen Devopin.

Jos kuitenkin haluat käyttää CNI:tä ilman automaattisen MTU-tunnistuksen tukea, voit määrittää sen manuaalisesti suorituskyvyn saamiseksi. Huomaa, että tämä koskee Calicoa, Canalia ja WeaveNetiä.

Pieni pyyntöni mukana oleville CNI:ille...

CNI-testaus: Raw Data

Tässä osiossa vertaamme CNI:tä oikeaan MTU:hun (määritetty automaattisesti tai asetettu manuaalisesti). Päätavoitteena tässä on näyttää raakadata kaavioissa.

Värien legenda:

• harmaa - näyte (eli paljas rauta)
• vihreä - kaistanleveys yli 9500 Mbps
• keltainen - kaistanleveys yli 9000 Mbps
• oranssi - kaistanleveys yli 8000 Mbps
• punainen - kaistanleveys alle 8000 Mbps
• sininen - neutraali (ei liity kaistanleveyteen)

Resurssien kulutus ilman kuormitusta

Ensinnäkin, tarkista resurssien kulutus, kun klusteri on "nukkumassa".

Resurssien kulutus ilman kuormitusta

Pod-to-Pod

Tässä skenaariossa oletetaan, että asiakasyksikkö muodostaa yhteyden suoraan palvelinkoteloon IP-osoitteensa avulla.

Pod-to-pod -skenaario

TCP

Pod-to-Pod TCP-tulokset ja vastaava resurssien kulutus:

UDP

Pod-to-Pod UDP-tulokset ja vastaava resurssien kulutus:

Pod-to-Service

Tämä osio koskee todellisia käyttötapauksia, asiakas Pod muodostaa yhteyden palvelinpodiin ClusterIP-palvelun kautta.

Pod-to-Service Script

TCP

Pod-to-Service TCP-tulokset ja vastaava resurssien kulutus:

UDP

Pod-to-Service UDP-tulokset ja vastaava resurssien kulutus:

Verkkopolitiikan tuki

Kaikista edellä mainituista ainoa, joka ei tue politiikkaa, on Flanelli. Kaikki muut toteuttavat verkkokäytännöt oikein, mukaan lukien saapuva ja lähtevä liikenne. Hyvää työtä!

CNI-salaus

Tarkistettujen CNI:iden joukossa on sellaisia, jotka voivat salata verkkojen välisen tiedonsiirron:

• Antrea IPsecillä
• Calico käyttämällä lankasuojaa
• Cilium IPsecillä
• WeaveNet IPsecillä

kapasiteetti

Koska CNI:itä on vähemmän jäljellä, laitetaan kaikki skenaariot yhteen kaavioon:

Resurssien kulutus

Tässä osiossa arvioimme resursseja, joita käytetään käsiteltäessä Pod-to-Pod-viestintää TCP:ssä ja UDP:ssä. Ei ole mitään järkeä piirtää Pod-to-Service-kaaviota, koska se ei anna lisätietoja.

Laittamalla kaikki yhteen

Yritetään toistaa kaikki kaaviot, otimme tänne hieman subjektiivisuutta korvaamalla todelliset arvot sanoilla "vwry fast", "low" jne.

Johtopäätös ja minun johtopäätökseni

Tämä on hieman subjektiivista, koska välitän oman tulkintani tuloksista.

Olen iloinen, että uusia CNI:itä ilmestyi, Antrea suoriutui hyvin, monet toiminnot toteutettiin jo varhaisissa versioissa: automaattinen MTU-tunnistus, salaus ja helppo asennus.

Jos vertaamme suorituskykyä, kaikki CNI:t toimivat hyvin, paitsi Kube-OVN ja Kube-Router. Kube-Router ei myöskään pystynyt havaitsemaan MTU:ta, en löytänyt tapaa määrittää sitä mistään dokumentaatiosta (täällä tätä aihetta koskeva pyyntö on avoin).

Resurssinkulutuksen osalta Cilium käyttää edelleen enemmän RAM-muistia kuin muut, mutta valmistaja on selkeästi tähtäämässä suuriin klustereihin, mikä ei selvästikään ole sama asia kuin kolmen solmun klusterin testi. Kube-OVN kuluttaa myös paljon CPU- ja RAM-resursseja, mutta se on nuori Open vSwitchiin perustuva CNI (kuten Antrea, se toimii paremmin ja kuluttaa vähemmän).

Kaikilla paitsi Flanelilla on verkkokäytännöt. On hyvin todennäköistä, että hän ei koskaan tue heitä, koska tavoite on yksinkertaisempi kuin höyrytetty nauris: mitä kevyempi, sitä parempi.

Myös muun muassa salauksen suorituskyky on hämmästyttävä. Calico on yksi vanhimmista CNI:istä, mutta salaus lisättiin vasta pari viikkoa sitten. He valitsivat johdinsuojan IPsecin sijasta, ja yksinkertaisesti sanottuna se toimii loistavasti ja hämmästyttävästi peittäen kokonaan muut CNI:t tässä testin osassa. Tietysti resurssien kulutus kasvaa salauksen takia, mutta saavutettu suoritusteho on sen arvoista (Calico osoitti kuusinkertaisen parannuksen salaustestissä toiseksi sijoittuvaan Ciliumiin verrattuna). Lisäksi voit ottaa Wireguardin käyttöön milloin tahansa sen jälkeen, kun olet ottanut Calicon käyttöön klusterissa, ja voit myös poistaa sen käytöstä lyhyeksi ajaksi tai pysyvästi, jos haluat. Se on kuitenkin uskomattoman kätevä! Muistutamme, että Calico ei tällä hetkellä tunnista automaattisesti MTU:ta (tämä ominaisuus on suunniteltu tuleviin versioihin), joten muista määrittää MTU, jos verkkosi tukee Jumbo Frame -kehyksiä (MTU 9000).

Huomaa muun muassa, että Cilium voi salata liikenteen klusterisolmujen välillä (eikä vain podien välillä), mikä voi olla erittäin tärkeää julkisille klusterisolmuille.

Johtopäätöksenä ehdotan seuraavia käyttötapauksia:

• Tarvitsen CNI:tä hyvin pienelle klusterille TAI en tarvitse suojausta: työskennellä Flanelli, kevyin ja vakain CNI (hän on myös yksi vanhimmista, legendan mukaan Homo Kubernautus tai Homo Contaitorus keksi hänet). Saatat olla kiinnostunut myös nerokkaimmista projekteista k3s, tarkistaa!
• Tarvitset CNI:n tavalliseen klusteriin: kalikoo - valintasi, mutta älä unohda määrittää MTU:ta tarvittaessa. Voit helposti ja luonnollisesti pelata verkkokäytännöillä, kytkeä salauksen päälle ja pois jne.
• Tarvitsemme CNI:n (erittäin) suuren mittakaavan klusteriin: No, testi ei näytä suurten klustereiden käyttäytymistä, tekisin mielelläni testejä, mutta meillä ei ole satoja palvelimia 10 Gbps yhteydellä. Joten paras vaihtoehto on suorittaa muokattu testi solmuissasi, ainakin Calicon ja Ciliumin kanssa.

Lähde: will.com