Nagyszámú, elosztott konténerek futtatására ki mit javasol?

Virtualizáció

Mi most a javasolt (várhatóan nem holnap megszűnő) megoldás sokgépes (fizikai) környezetben konténerek menedzselt futtatására?

Amit keresek:

  1. támogatja a hálózati bootot (gépek mehetnek-jöhetnek, a legjobb lenne, ha PXE-vel be tudnék bootolni)
  2. képes a konténerekhez csomagszűrő szabályokat csatolni (mi hová, mivel beszélhet, honnan kaphat forgalmat)
  3. tud a fizikai gépekről perzisztens tárhelyet használni (reboot után megmaradó volume)
  4. alkalmas a valamilyen formában definiált konténerek (dockerfile, docker compose) futtatására, életben tartására, esetleg monitorozására, dashboard stb.

( blackluck v | 2019. 12. 11., sze – 10:58 )

Ha egy egyszerubb gyorsan osszedobhatobb megoldas kell akkor talan docker swarm, ha komplexebb akkor inkabb kubernetes jellemzo manapsag illetve annak valtozatai (red hat openshift, kulonfele felhos valtozatok: amazon eks, google gke, azure aks stb.). Hogy altalad igenyelt dolgokbol melyiket mennyire tudja alapbol vagy konnyen mar attol fugg melyiket nezed.

( azbest | 2019. 12. 11., sze – 11:11 )

Szerkesztve: 2019. 12. 11., sze – 11:14

A már előttem említett kubernetes.

1) A hálózati boot kapcsán, ha a fizikai vasra gondolsz, hogy hozzák viszik a szervereket, akkor ott a host rendszert kell erre összeállítni. Ha arra gondolsz, hogy a konténerek hol egyik hoston hol a másikon lehetnek, azok nem bootolnak, hanem a konfigok alapján létrehozza őket a docker-registry és kubernetes  / helm konfigok alapján.

Ha a hostok jönnek mennek, azért kell master, ami nem veszik el és a node-ok ahhoz joinolnak, s kapnak feldatot.

2) namespace-k vannak és tudtommal szabályozható, de ne windows alapon legyen.

3) ha arra gondolsz, hogy a konténer példány azon a hoston hozzon létre perzisztens tárhelyet, amin épp fut, akkor ez nem ilyen egyszerű. A sima host könyvtár felcsatolás nem lehet dinamikus. Ahhoz, hogy dinamikusan kapjanak perzisztens tárhelyet, olyan storage class-t kell használnod, ami támogatja a dinamikus kiosztást. Nameg, ha más-más vason futhat a konténer példány, akkor a helyi volume nem fog odavarázsolódni. Szóval nem véletlen, hogy a dinamikusan kiosztós perzisztens volumek hálózati tárhely classoknál támogatottak, pl nfs.

4) aha... például grafana és dashboard, azok is kvázi olyan konténerekként települnek, mint a "hasznos" szolgáltatások.

Szóval azért master(ek), hálózati tárhely és docker-registry kell legalább szerintem fixen.

A namespace-ek logikai csoportok, nem netwrok policy-ra/szűrésre valók. FQDN-el bárhonnan látszanak (pl. a busybox.default.svc.cluster.local fogja látni az elastic.monitoring.svc.cluster.local-t). Mondjuk basic szűrésnek megfelelnek...báááár...

Teny, hogy onmagaban a namespace nem fogja alapbol korlatozni, es tobbnyire csak logikai csoportositas.
De namespace-ek alapjan (is) lehet felteteleket szabni, pl network policy-ban, hogy teszem azt pod-ok csak sajat namespace-ukon belul komunikalhassanak, vagy megadott namespace melyik pod-javal. Ahogy eroforras szabalyozas, hozzaferes korlatozas es meg sok minden eseten is lehet feltetel/egyseg a namespace.

Persze. Ez igy is van es egyet is ertunk. Csak a valaszodban az volt hogy namespace, az magaban nem eleg kell egy olyan netwrok policy amiben a namespaceselector-t hasznaljuk. Szoval igen az elso lepes ha  namespace alapu network policy-kat akarunk, hogy namespace-eket gyartunk. Ez amugy egy egyszeru es jo megoldas. En megis inkabb a podselector-t es a label-eket hasznalnam erre. Persze kerdes, hogy inkabb logikailag elszeparaljuk a pod-okat vagy mindegyiket "megjeloljuk" inkabb. Ezt meg a hasznalat donti el. De mindegy is mert egyetertunk abban, hogy alapvetoen a namespace + network policy jo irany.

( golgota | 2019. 12. 11., sze – 11:21 )

1. Hogy melyik konténer orchestrátort választod tök mindegy a compute nodoknak. A PXE boot tök független ettől. Feljön egy szerver PXE-vel, bekonfigurálja magát kickstarttal és már be is jointolt a clusterbe. Hogy melyikbe kubernetes, swarm, mesos? Majd a kickstart conf eldönti.

2. A swarm-ban nem tudom mi a helyzet, de a kubernetsben ott a networkpolicy, plusz a network plugin-eknek is van saját network policy-jük, plusz az ingress controllerekben is van mindenféle

3. Mindegyik tud, de hostVolumeot használni elég rizikós, mivel a schedulerek lehet máshova teszik a pod-ot legközelebb, más hostra. Persze kubernetes-ben erre is van megoldás. Írsz saját schedulert, ami figyel erre IS, vagy használod valamelyik storage providert, amiben van ilyen (pl. stork)

4. Szeritnem ezt mindegyik tudja, mert ez az alap. Erre vannak. Itt sokkal inkább fontosabb a deploy/rollback/scale stb. amiben a kubernetes megint jobb, mint mondjuk a swarm. Illetve a kubernetes eseteben ott a helm, ami igencsak megkonyiti a templatelés segítségével, hogy ne kelljen negyvenszer ugyanazt a manifest-et leírni máshogy.

( kisg v | 2019. 12. 11., sze – 11:24 )

Nézd meg, hogy a Rancher már megint mit rakott össze: https://k3os.io/ (Ezek a fiúk - lányok már megint kitaláltak valamit! :) )

 

Ha nem akarsz teljes Kubernetes OS-t, akkor van nekik csak Kubernetes distrojuk is: https://k3s.io/