Viime aikoina olen työskennellyt PaaS-sisällön parissa, ja olen juuri päässyt tekemisiin Kubernetesin kanssa, joka liittyy verkon kattavuuteen, eli viestintään isäntäristiinkonttien välillä. Näin on syntynyt sarja avoimen lähdekoodin komponentteja, kuten flanelli, kaliko, kudos jne. Tässä ovat pääasiassa Calico ja Fannel.
Flanelliperiaate
Flannel, CoreOS:n kehittämä projekti, on todennäköisesti suorin ja suosituin CNI-lisäosa. Se on yksi kypsimmistä verkkoarkkitehtuurin esimerkeistä konttiorkestrointijärjestelmissä ja on suunniteltu mahdollistamaan parempi konttien ja isäntien välinen verkottuminen. CNI-konseptin nousun myötä Flannel CNI -lisäosa on varhainen esittely.
Flanellin asentaminen ja konfigurointi on suhteellisen helppoa verrattuna muihin vaihtoehtoihin. Se on pakattu yhtenä binäärisenä FlannelD:nä, ja monet yleiset Kubernetes-klusterien käyttöönottotyökalut sekä monet Kubernetes-jakelut voivat asentaa Flannelin oletuksena. Flannel voi käyttää Kubernetes-klusterin olemassa olevaa etcd-klusteria tallentaakseen tilatietonsa API:n kautta, joten se ei tarvitse erillistä tietovarastoa.
Flannel konfiguroi kerroksen 3 IPv4-overlay-verkon. Se luo suuren sisäisen verkon, joka kattaa kaikki klusterin solmut. Tässä Overlay-verkossa jokaisella solmulla on aliverkko, jota käytetään IP-osoitteiden määrittämiseen sisäisesti. Kun podia konfiguroidaan, Docker-sillan rajapinta jokaiselle solmulle antaa osoitteen jokaiselle uudelle kontille. Saman isännän podit voivat kommunikoida Docker-siltojen avulla, kun taas eri isäntien podit käyttävät flanelldia kapseloidakseen liikenteensä UDP-paketteiksi, jotta ne voidaan reitittää oikeaan kohteeseen.
Flanellissa on useita erilaisia taustajärjestelmiä, joita voidaan käyttää kapselointiin ja reititykseen. Oletus ja suositeltu lähestymistapa on käyttää VXLANia, koska VXLAN toimii paremmin ja vaatii vähemmän manuaalista puuttumista.
Calico-arkkitehtuuri
Calico sisältää seuraavat tärkeät komponentit: Felix, etcd, BGP Client ja BGP Route Reflector. Seuraavassa on selitykset kullekin näistä komponenteista.
Felix: Se vastaa pääasiassa reitityskonfiguraatiosta, ACLS-sääntöjen konfiguroinnista ja toimituksesta, ja se on olemassa jokaisessa solmussa.
etcd: Hajautettu avain-arvovarasto, joka vastaa pääasiassa verkon metatietojen yhdenmukaisuudesta ja Calico-verkon tilan tarkkuuden varmistamisesta, voidaan jakaa Kubernetesin kanssa;
BGPClient (BIRD) vastaa pääasiassa Felixin ytimeen kirjoittaman reititystiedon jakamisesta nykyiseen Calico-verkkoon varmistaakseen työkuormien välisen viestinnän tehokkuuden.
BGPRoute Reflector (BIRD) on käytössä laajamittaisissa käyttöönotossa, luopuen mesh-tilasta, jossa kaikki solmut yhdistetään keskenään, ja käytetään yhtä tai useampaa BGPRoute Reflectoria keskitetyn reitityksen ja jakelun toteuttamiseen.
Calico-periaate
Kuten seuraavassa kaaviossa näkyy, prosessi kuvataan lähdekontista lähdeisännän kautta, datakeskuksen reitityksen kautta ja lopulta kohde-isäntälle ja lopuksi kohdekontille.
Kontrasti
Yllä olevasta periaatteesta voidaan nähdä, että flanelli suorittaa pakettien purkutoiminnot reititysvälityksen pohjalta, mikä tuhlaa prosessorin laskentaresursseja. Alla oleva kaavio vertaa eri avoimen lähdekoodin verkkokomponenttien suorituskykyä, joita löytyy verkosta. On nähtävissä, että kaistanleveyden ja verkon viiveen osalta Calicon ja isännän suorituskyky on samankaltainen.
|
Julkaistu 9.11.2020 11.23.01
|
|
|
|
