Új hozzászólás Aktív témák

  • tasiadam

    Topikgazda

    válasz ViZion #1369 üzenetére

    TLDR:

    Nem VM, hanem konténerben mennek a servicek, mondanám, hogy hasonlóképp, mint egy LXC, de az LXC kicsit nagyobb, mint egy container.
    A containernél ugye a VM-el ellentétben nem kap dedikált virtuális NIC-et, disket- hanem namespacet kap, ahova pakolja a dolgait, ezen kívül dedikálhatsz neki CPU-t és RAM-ot, pl ha van 1 magod, és akarsz egy databaset- meg 3 servicet ami ezt olvassa ki, akkor 1 POD (min 1 container csomag(?) ) alá bedobhatod a dolgokat, és kiosztod, hogy a databse kapjon 0.1 CPU-t, azaz 1 mag 1 tized részét, és még 128mb ramot, és ezen felül a 3 másik servicenek 0.2 CPU-t, a maradékot meg a többinek. Ezen felül lehet alatta külön port és IP is.

    No, itt jön a móka, mert ugye sok serviced, POD-od, és ezeknek a különböző clusterei lehetnek, ekkor jönnek képbe az orchestrátorok. Pl a kubernetes: Ez on-prem, google találmány, ez van a gépemen/VM-en.
    Ennek van AWS megfelelője, ami az EKS. Definiálod, hogy mit akarsz hova, mennyi, milyen porton, címen, és az EKS-el deployolod/pullodod, ki hogy hívja. Van ebből Azure verzió is, meg GCP, alibaba cloud, akármi.

    Eddig én VMeket terrorizáltam, valaha 3 hónapig oktatás nélkül K8S-t is, de most muszáj vagyok K8S-t. (K8S = k[ubernete]s, a [ és ] között pont 8 karakter van) Kapok mellé AWS certet, meg konténerizáció tudást, a piacon nem kicsit jó.

    Én esetemben a munkából lett hobbi az egész. Szét is akarom választani az egészet kicsit. Szeretnék egy homeServer clustert, amiben több erősebb mag van a samba és hasonlók miatt, meg egy több magvas és memóriás, alap SSD-s tanuló clustert. Pl 4 magos AMD gépekből. Kutyát nem érdekli, ha pl k8s esetében 1 service 1 gyenge AMD magon megy, vagy egy intel magon, nem a sebesség a lényeg.

    [ Szerkesztve ]

    Gyermektelen, nem házas, másodrangú állampolgár

Új hozzászólás Aktív témák