Sziasztok,
Az van hogy a self hosted kuberentes cluster worker node-ok csak egy halozati kartyat hasznaltak(VNIC). Eddig minden szep es jo volt. Network (10.10.31.x/24)
Mivel most a felhaszalok szeretnenek NFS share-hez csatlakozni ami masik halozati szegmensben van es ezert hozza kellett adni egy masik halokartyat is a gepekhez.(10.10.32.x/24)
Egy egyszeru ubuntu gepen ez siman mukodik. Hozzaadtam egy masodiuk route tablat es az nfs mount mukodik is szepen.
de ezt hogyn valositom meg a kubernetes node-okon?
- Ugyanugy meg kell adni a masodlagos route tablat azokon a node-okon is?
- Hogyan etetem meg mindezt a kubernetessel? Kell valami magia a CNI -szel? Weave a hasznalt CNI plugin. Jelenleg sajnos nem talaltam semmi erre utalo dokumentumot
koszonom
Hozzászólások
Multus-al megprobalhatsz jatszani a tobb podnetwork-hoz.
De tarhely felcsatolast nem a podnak kellene intezni hanem nfs storage driveren keresztul pvc-vel, amikor a node fogja felcsatolni az adott node-ra ahol elindul a pod az tarhelyet es adja oda a hozzaferest a podnak.
Igy van. Kell a Multus, de azzal se lesz nativ elmeny.
A K8s halozati alrendszere arra lett kitallava, hogy a kis kontenerek majd jol elbeszelgetnek egymassal. IPv4-en (esetleg IPv6-on) 1 cimmel. Meg a transzport retegbeni titkositas majd jol megvedi oket mindentol is.
Hamar rajottek szerencsere, hogy ez azert keves lesz. Sok profi vendor es felhasznalo ceg is raugrott, hogy besegit az IP alrendszerbe. Ahogy latom, meg beta es a kulvilag fele a kapcsolattartas se az igazi meg.
Az is szep elgondolas, hogy majd a futtatokornyezet gondoskodik pl a halozati meghajtok csatolasarol. Szep dolog is az, amig nem valami egzotikus megoldast hasznal a delikvens, nem kell dinamikus eroforrasfoglalas, QoS es hasonlo dolgok. Persze, ha annyi, hogy "itt az NFS share, hasznaljatok egeszseggel", akkor siman jo igy. Kulonben kezdhetunk nezelodni, hogy van-e a storage megoldashoz K8s driver, es mennyibe fog az nekunk kerulni.
Ha kis bonyolultsagu rendszerrol beszelunk es/vagy hazi vagy kis ceges hasznalatrol, akkor lehet patkolni. Amint kritikus a ceg eletere nezve, jobb profira bizni. De ez barmi workloadra / halozatra igaz.
A dual stack mas, ott ugyanugy csak 1 interface-t kap a pod csak azon kap ipv4 es ipv6 cimet is dual stack-ben. A topoknyito eltero interface-t akarna hasznalni, arra nem lesz jo a dual stack.
Amugy az is egy egyszeru megoldas hogy nem direktben a worker node-okra viszi oda layer2-vel az nfs elerest hanem routeren felkonfiguraltan, worker node szempontjabol ugyanazon az interface-en keresztul.
Sok esetben nfs-bol nem is szoktak tobbet hasznalni csak csatolt fel, mert az van/azt ismerik, de cloud kornyezetben nem is tulzottan jellemzo nfs hasznalata.
Igaz. Ha megfelelo megoldas, hogy csak ugy odaadja az NFS-t akar L2-n, akar routolva, akkor nincs baj. Sok helyen azonban alapveto elvaras, hogy a traffic, O&M, storage es egyeb halozatok akar fizikailag is el legyenek valasztva egymastol.
A dual-stack-et azert hoztam fel, mert eredetileg (es Multus nelkul) 1 interfesz, 1 cim ami jar a szerencsetlennek. A Multus mar egy, a K8s szempontjabol kulsos, patkolas a gyenge halozati alrendszerre. A K8s dual-stack egy nagyon fontos lepes a jo iranyba. Igy legalabb tobb cime lehet, meg akkor is, ha interfesze nem. De ne akarjunk mindent egyszerre :)
Az NFS hasznalata sokszor csak tortenelmi problema, de nehez tole megszabadulni. Storage megoldast valtani legalabb akkora tudomany, mint minden mas. Itt is az jon szembe, hogy hat ott az az NFS, hasznaljuk mar, hisz nincs semmi baja. Aztan majd raerunk csodalkozni, hogy hova is lett az adat, amikor az eddigi 2 darab fix kliens helyett mostantol n..k darab, dinamikusan valtozo szamu egyed probalja tullicitalni egymast.
Egyszerubb rendszerek eseten megint csak okes lehet, hogy egy router majd megoldja. De ki konfiguralja fel azt? Teljesen statikus a rendszer, vagy majd naponta 2x at kell piszkalni? Ennel az is jobb, ha megertik az NFS CSI osszes elnyet es hatranyat, majd beuzemelik.
Ez igy van, barmelyik iranyba is mennek lesz vele teendo es valoszinuleg tanulni valo is es ha mar ugyis at kell alakitani meg megtanulni dolgokat en inkabb abba az iranyba mennek amit masok is hasznalnak a hosszabb tavu celok erdekeben. De persze lehetnek helyi sajatossagok, korlatok vagy csak berogzult dolgok, felhoztunk tobb otletet is amibol valogathat vagy mehet a sajat feje utan is. :)
ajajj. Akkor ez azt jelenti hogy csereljem le a weave cni-t multusra ha szeretnem h mukodhon a tortenet?
Nem, multus a primary cni mellett van.
Dehogy, egyszerre egy aktiv CNI van. Ha ez a Multus, akkor a Multus configja tartalmazza a primary interface-hez tartozo (delegalt) CNI-t.
A pod altal managelt nfs felcsatolas igazabol csak kenyelmi szempontbol volt.
A devek igy hasznaltak eddig, nekik jo volt, en a kubernetes layerert felelek de majd atszoktatom oket.
Mondjuk hozzáadsz egy SNAT szabályt az összes nodeon, hogy a k8s internal networkből az nfs hálózatba a 10.10.32.x címet használja. Azt nem igazán értem, hogy maga a pod hogy fog NFS-t mountolni, de gondolom ezt már kitaláltad.
gondolkoztam meg egy nfs node-on. Felcsatolom az nfs share-t a masik szegmensbol es ujra kiajanlom a kubernetes szegmensebe
Azt azert tisztazni kellene, hogy megis mikent lenne az az NFS share hasznalva?
Minden Pod maga mountolja fel a Podon belul? Ilyen jogokat nem kellene adni egy Podnak.
Talan a legegyszerubb az lenne, ha minden (worker) node-on felmountolod az NFS share-t egy konyvtarba es azt host-volume mountoljak azok a Podok, akiknek szuksege van ra.
Ultimate megoldas persze az NFS storage CSI hasznalata, es a Podok PVC-vel kerhetik a hozzaferest.
Egyebkent ha egy ilyen modern, cloud-native kozegben barki is NFS-t szeretne hasznalni Podbol, akkor azert illene atgondolni, hogy biztos, hogy jo-e az a workflow. Nem biztos, hogy mindenaron egy legacy megoldast kellene beleeroltetni. Szerintem.
cloud-native kozegben barki is NFS-t szeretne hasznalni
Nem biztos, hogy mindenaron egy legacy megoldast kellene beleeroltetni
Hú, de jó lenne, egy "nem legacy" open-source megoldás az NFS helyett!
"Apró" probléma, hogy ilyen nincs egyelőre még. Vannak olyan megoldások, amik valamilyen funkciót nem tudnak (pl. a CIFS nem POSIX ugye), vagy amik eleve nem ugyanezt a feladatot akarják megoldani (pl. CEPH), esetleg amik akár stabilitásban, akár teljesítményben a közelében sincsenek az NFS tudásának (pl. Gluster).
Úgyhogy ha valaki tudja a jó megoldást, ne tartsa magában pls...
> Úgyhogy ha valaki tudja a jó megoldást, ne tartsa magában pls...
Pont ezt akartam irni, hogy nem az NFS-t kell kivaltani egy masik file share-rel, hanem a szoftver architekturajat/mukodeset atgondolni, hogy egy Podnak miert is kell egyaltalan egy tavoli file-hoz hozzaferni (config file?, binaris blob?, logolas?).
Idealis cloud-native esetben a Podoknak csak verziozott API-n (HTTP(S)) keresztul kellene egymassal kommunikalni. Nem szerencses egy NFS share okozta dependencyvel uzemeltetni a Podokat.
Nem értem.
ezert hozza kellett adni egy masik halokartyat is a gepekhez.(10.10.32.x/24)
Hozzaadtam egy masodiuk route tablat
- Ugyanugy meg kell adni a masodlagos route tablat azokon a node-okon is?
Minek? Amint felkonfigurálod a második hálókártyát az adott gépen, a 'connected network', azaz a hálókártya IP subnetje automatikusan megjelenik a routing táblában, nem kell ott csinálni semmit se.
- Hogyan etetem meg mindezt a kubernetessel? Kell valami magia a CNI -szel? Weave a hasznalt CNI plugin. Jelenleg sajnos nem talaltam semmi erre utalo dokumentumot
Semmit nem kell csinálni. Automágikusan menni fog mindegyik node-on, amiről ez a hálózat elérhető. Nem is értem itt fentebb a multus előhozását...
A Pod hálózatából minden, ami nem Kubernetes, az ekvivalens az "Internet" elérésével. Tehát valami vagy belül van (pod network, service network, node-ok címei), vagy ha nem, akkor a kimenő forgalmat indító fizikai node saját routing táblájával, source NAT (MASQ) után kvázi a hostról indított forgalomként jelenik meg. Pont, mint amikor a gmail weboldalát címezed. Esetünkben ez baromi egyszerű: mivel a hostnak saját közvetlen kapcsolata van az adott subnettel, így az mindig azon keresztül fog menni.
Másrészt: az NFS mount kernel funkció, így az nem a Podon belül történik. Azaz még ha esetleg a Pod szintjén is csinálod a mount parancsot, a mountolást a kernel végzi, és az eleve nem a Pod hálózatából indul, hanem a hostéból. Ha a Pod volume listájában NFS mount van, az nem a Pod neve alatt fog megvalósulni, mert ezeket a mountolásokat a kubelet végzi, a saját kontextusában, egy random jól megválasztott host könyvtárban, aztán ezt a host könyvtárat fogja a kubelet az adott Pod adott konténerébe local bind mountként bevinni (mint a -v opció a docker run alatt). Azaz az egész fenti elmélkedés N/A esetünkben, eleve nem is a Podon belül történik az NFS mount.
Ahha? Szoval elvilg tul van bonyolitva reszemrol a tortenet?
Hozzadom a workerekhez a plusz halokartyat ami csatlakozik az NFS halozatahoz azutan mindenki boldog? Na ma kiprobalom.
jahm. igaz nekem ceph rbd-t er el, de igen.