Uživatelé se dnes čím dál více zajímají o kontejnery, což podle Bečvaříka není nic magického. "Vlastně neemulujeme žádný hardware, ale pomocí funkcí jádra oddělujeme procesy s namespaces."
Proc maj lidi porad potrebu mluvit o vecech kterym nerozumi? Docker konkretne je dost o sitovych spojenich a tam samozrejme je emulace/virtualizace sitovyho HW nutna. https://docs.docker.com/network/#network-drivers
Nebo by sis mohl neco dostudovat ty. Network namespace neni virtualizace hardwaru, ani jeho emulace. Pouze izolace relevantnich casti codepaths od sebe, takze nektere interfacy vidis jen z nekterych ns, ze maji svoje netfilter pravidla, apod. Neni to virtualizace, je to izolace.
Mozna by se to chtelo zamyslet, nez se clovek ztrapni linkovanim doc Dockeru, obzvlast v reakci na orednasku typka, ktery ma problematiku zvladnutou a veci nactene na level zdrojaku a odexperimentovane i vlastnim kodem.
Izolovat muzes neco, co uz v systemu existuje. To znamena pokud mas dva sitovy adaptery tak ano, jeden muzes izolovat do kontejneru. Jenze to neni aplikace vetsiny kontejneru. Vetsina stroju na kterych bezi kontejnery maj jeden adapter a pak samozrejme nemas co izolovat, protoze by si tim prisel o sit pro host. Musis vytvorit virtualni adapter pro kazdej kontejner zvlast a trafik z nej routovat na fyzickej adapter. Proto vubec naky routovani mezi virtualnim adapterem a fyzickym adapterem musis resit. Doporucil bych ti i tomu typkovi, co tomu "rozumi", si to nastudovat znova...
Tady to mas hezky rozkresleny i s tema virtualnima adaptera:
https://success.docker.com/api/images/Docker_Reference_Architecture-_Designing_Scalable,_Portable_Docker_Container_Networks%2F%2Fimages%2Fbridge2.png
zdroj (zase dokumentace Dockeru):
https://success.docker.com/article/Docker_Reference_Architecture-_Designing_Scalable,_Portable_Docker_Container_Networks#dockerbridgenetworkdriver
Videl jsi nekdy trace nejakyho sitovyho syscallu z toho kontejneru, prosimte, ze delas tak chytryho? Zkus zalizt realne k veci, mrkni se do zdrojaku, jak je to poskladany a az pak machruj s obrazkama.
Dockeristi obecne maji o vecech tak zjednodusenou predstavu, ze to boli. Ale tezko se divit, kdyz je vlastne Docker nacisto marketingovo-hypovaci firma (s nejistou budoucnosti, nastesti). Vsechnu podstatnou praci odmakali lidi pred nejakym Hykesem a marketakama okolo nej - v kernelu. A tak hluboko z Dockeristu jde kdo?
No zkus si to. Uvidis, ze ty tvoje obrazky jsou jenom zjednodusene nakresy pro lepsi pochopeni, ne, ze tak je to realne postavene.
Tak to verim, ze dokeristi maj dost zkresleny predstavy. Je to videt i na tom citatu z clanku. Ja nejsem dokerista. Ja jen s virtualizaci at uz plnou emulaci (pamatuju ten obrovskej skok ve vykonu, kdyz Qemu nahrazovalo Bosch), ci HW virtualizaci (Xen, KVM-qemu a ESX) i OS lever virtualizaci (do ktery spada i Docker, Solaris Zones, LXC a dalsi) delam skoro 20 let. Porad v i ty OS level virtualizaci je spousta veci co se musi emulovat. V pripade dockeru jsou to ty virtualni adaptery a je jedno kolik syscallu se pouzije, porad je to emulace HW, kterej ve skutecnosti neexistuje.
Nebo mi chces tvrdit, ze - treba - kdyz pouziju SELinux, abych od sebe odizoloval procesy, aby na sebe nevidely, tak jsem vlastne zacal virtualizovat hardware? Nebo treba ze veth modul v kernelu je virtualni hardware? Tak to se asi nikam neposunem a nemam moc motivaci te presvedcovat o necem, co nechces chapat - hlavne kdyz v kazdym komentu hledas, jak do nekoho kopnout, ze neco dela blbe, nebo ze to umis lip ;)
:D, OK, tak ja otevru pocitac a ty mi ten "nevirtualni" veth ukazes, jo? :D To si fakt me pobavil. Schvalne, co si myslis, ze znamena to 'v' v tom 'veth'?
Napoveda: http://man7.org/linux/man-pages/man4/veth.4.html
Pokud bezis 4 virtualni masiny dockeru a kazda vidi jeden NIC, tak pokud nemas pro kazdej vyhrazenou jednu NIC nemas jinou mosnost nez jim ukazovat virtualni NIC. To jestli ta virtualni NIC je ve skutecnosti primo volani driveru skutecny NIC (coz samozrejme neni, to by byl hroznej bordel), nijak neovlivnuje definici emulace: Emulation refers to the ability of a computer program in an electronic device to emulate (or imitate) another program or device.
Jinymi slovy Docker VM nema pristup (ani nesmi) mit pristup primo k hostitelskymu NIC a proto musi pracovat s emulovanym NIC.
Nesouhlasim, ze se emuluje NIC. To, ze mas moznost volat ioctl nad nejakym devicem, neznamena, ze se neco emuluje. Ten device realne existuje, v pameti jadra a jadro ho prezentuje ven, tak, jak je. Je to device v terminologii jadra, ne hardware device, tedy zarizeni v pravem slova smyslu. Tam proste neni kde co emulovat. Jedine, co je tu navic, je delsi codepath v jednom a tom samem kernelu, ten paket prisel pravdepodobne pres nejaky BSD socket, ktery byl otevreny nad nejakym rozhranim, ale to neni nejake hardwarove zarizeni k emulovani, to je proste kernelovy interface, ktery existuje, kdyz jsi ho vytvoril. Mohl bys taky mit tun/tap od OpenVPN a neresit zadne kontejnery - a to je tun/tap podle tebe taky emulovana sitova karta, tedy NIC? Nic jako "primo hostitelsky NIC" v tomhle kontextu nedava smysl, veth neni zadny NIC, je to kernelovy interface, stejne jako bridge, stejne jako tun/tap. Neeumuluje se tim sitova karta - takovy ethtool ti nerekne, ze veth, bridge, nebo tun/tap maji nejaky link.
Samozrejme ze tun/tap, bridge atd. jsou emulovany sitovy karty. Ony se navenek (pro aplikace) tvarej jako bezna sitova karta, ale za tim interface neni HW driver. Emulace neznamena, ze musis emulovat konretne treba e1000. Staci jen tvrdit, ze sem eth0 (nebo veth0, tun0,...), ale pak musim vracet vse co se od takovyho interfacu ocekava. To ze vracim to co by normalne vracel ovladac karty, tim vlastne emuluju ten ovladac a jeho interakci s HW a interakci HW se samotnou siti a misto toho celou tu komunikaci zabalim treba do TLS v pripade tun vytvorenyho OpenVPN a poslu na skutecnou NIC.
Chapu, ze to autor myslel tak, ze docker bezi temer 100% rychlosti nativniho pusteni. Jenze dnesni pocitace jsou plny emulacnich vrstev. Virtualni inteface ma mozna minimalni overhead, ale porad tam nakej je. Takovy KVM pokud pouzije na dany zarizeni IOMMU muze mit klidne i mensi overhead nez ten docker.
No, jaksi te porad minula cela podstata toho, co ti rikam. V kriticky codepath, tj. tam, kde aplikace prijima a odesila data na otevrenym file descriptoru nad BSD socketem, je jedinej rozdil ve skoku pres par presmerovacich access-checkujicich funkci a maker. To, ze driver emuluje ioctl a vyplnuje poctive structy, aby si aplikace myslela, ze dela se sitovkou, je totalne nepodstatny. Neda se to porovnavat s tim, ze na procesoru switchnes kontext mezi tvym jadrem, vhostem a QEMU do zblbnuti, aby sis poslal paket z ty appky. SR-IOV je samozrejme spravny reseni problemu. Ale co kdyz chci nastartovat kontejneru treba 1000 nad tou sitovkou? Meanwhile, user namespace bude mit porad ten samy sotva meritelny overhead.
Jinymi slovy: Ano, je to rychly protoze je ta emulacni vrstva extremne tenka, ale nejde rict: "Vlastně neemulujeme žádný hardware", protoze to neni pravda. Emuluje se sitovej HW tim, ze neni VM pripojeny na HW primo, ale pres virtualni inteface, kde se pak teprve dle nastaveni jadro rozhodne kam to vlastne posle...
Cesta, kudy jde kod; typicky se po zavolani systemoveho volani jadra v tom jadre skace z funkce do funkce, aby se vsechny vrstvy abstrakce, co jdro musi vykonat pro dane volani, dostaly obslouzeno; no a cela moje pointa je, ze cesty, kudy plavou data z appek z kontejneru, se nelisi nijak vyznamne od tech primo na hostiteli, max o par skoku do par funkci navic, o ty virtualni sitove interfacy. Kritickou codepath se pak rozumi ta, ktera je vykonavana nejcasteji a na ktere visi podtatne vykon dane aplikace. Je to radikalne neporovnatelne s latenci VMExitu pri skoku z plne virtualky do kernelu hostitele, aby se obslouzilo sitovani.