Docker Swarm klaszter szolgátlatásai között a névfeloldás néha nem működik, a Docker belső DNS-e nem oldja fel a service neveket IP címekké. Azonban ez nem mindig fordul elő, sok esetben tökéletesen működik a névfeloldás.
Láttam ezt a topikot már: https://hup.hu/node/181972 De nem releváns, nem Windows konténereket használunk.
Sajnos nem tudtam a különféle fórumokon választ találni a problémámra sehol. A moby GtiHub repositoryjában bejelentett hibákat már végignéztem, rengeteg több éves nyitott Swarm+DNS probléma van, régi verziókkal kapcsolatban, és nagyon sok nem is releváns már, nem vitt előrébb.
Ti tapasztaltatok már ilyet? Ha igen, és sikerült megoldani, mi volt a gyökérok és mi volt a megoldás?
A Docker Engine verziója 24.0.2, a kernel verzió 3.10 (CentOS 7, még egy évig támogatott).
Hozzászólások
Ahogy ott is írtam, nem tapasztaltam ilyet, azóta sem, de IPv6-ot használsz esetleg? Ott azt állapítottuk meg különbségnek, a konténerek esetén én nem, de ha ti is, akkor arra el lehet indulni.
Nem, nem használunk IPv6-ot.
Hogyan működik, amikor működik? hosts-fájl, saját DNS-szerver, egyéb?
A Docker Swarm biztosít egy saját DNS szervert a klaszter tagjainak.
Lásd: https://docs.docker.com/network/#dns-services
A Docker engine ebbe jegyzi be a szolgáltatásokat, és a többi szolgáltatás innen tudja lekérdezni.
Majd 24.0.3-ban javítják: https://github.com/moby/moby/issues/45646
A probléma fennállt 20.10-ben is, aztán updateltünk 24-re.
Tudom nem segít, de én is tapasztalom nem tudom hanyadik verzió óta (nem Swarm), van amikor 2 hétig jó, van amikor 5 percig sem.
Kiváló. Akkor ha jól értem, Docker Engine-re nem igazán lehet alapozni éles szolgáltatást. Mi marad helyette? K8s csillagromboló?
A k8s sem csillagrombolo, mert igen csak minimal az az egy kubelet service meg a ket-harom container amit alapbol futtat, de ha sok neked akkor nezd meg a k3s-t
Nem ez a sok benne, hanem a domain modellje. ScaledSet-ek, StatefulService, NodePort, ezerféle fogalom van, amivel dolgozik. A Docker fogalmi modellje sokkal egyszerűbb.
Nem az a sok, hogy hány konténert futtat, meg milyen szoftvert kell hozzá feltelepíteni. Hanem az, hogy hogyan modellezi az üzemeltetési fogalmakat a k8s. Mert azt bizony meg kell tanulni.
Docker Swarm esetén is meg kell tanulni, csak ott a tanulógörbe rövidebb, alacsonyabb a küszöb, viszont hamar ott a fal, aminek fáj nekimenni.
https://iotguru.cloud
Mit jelent a fal annál?
Például az, hogy Docker-hez vagy kötve. Ez egy jelentős limitáción azon túl, hogy nagyon sok feature nem is létezik Swarm esetén, ami alapból van Kubernetes-nél.
A fő probléma amúgy az, hogy a Kubernetes esetén van egy olyan érzésed, hogy ezt alapvetően megtervezték, van egy roadmap, ami alapján változik; a Swarm esetén meg az az érzésed van, hogy organikusan fejlődött, mindig csak hozzáragasztottak ezt-azt.
https://iotguru.cloud
> Docker-hez vagy kötve.
Ami K8s eseten is igaz. Vagy nem ertem, mit akarsz mondani.
> nagyon sok feature nem is létezik Swarm esetén
Azt nem neveznem fal-nak, h vmit egyeb eszkozzel kell megoldani.
Vagy lehet, h epp nem lehet megoldani es nincs es nem is lesz ra szuksege az emberkenek.
> Swarm esetén meg az az érzésed van
Nincsenek ilyen erzeseim, viszonylag megbizhatoan ki tudom jelenteni.
Azt hittem, olyanokat fogsz tudni mondani, h X meret folott nem skalazodik v. hogy vmi, amit iger, nem tudja teljesiteni v. egy feature koncepcionalisan rosszul mukodik.
Az, h mas feature set-tel rendelkezik, nem fal (blocker).
Olyannyira nem, hogy 1.20 verzióval deprecated lett a core Docker támogatás és az 1.24 verzióval el is távolították (volt is szopás belőle). Korábban már átálltak belül OCI modellre és CRI interfészre, így bármit támogat, ami képes OCI/CRI modell alapján dolgozni (cri-o, containerd, docker-engine, stb).
Aham... akkor nevezzük magas kerítésnek, amikor heteket kell szopni valamivel, ami másik megoldásnál fél sor.
Igen, ettől fal, hogy nem lehet megoldani és nyilván a falon belül élve nem is tudod, hogy amúgy szükséged lenne rá, csak nem tudod, hogy van olyan.
És ezt hány év Kubernetes tapasztalattal tudod kijelenteni? :D
Akkor nem fal, használd nyugodtan, drótozz hozzá egyéb eszközöket és tapaszd be sárral, hogy ne legyen feltűnő.
https://iotguru.cloud
> Korábban már átálltak belül OCI modellre és CRI interfészre, így bármit támogat, ami képes OCI/CRI modell alapján dolgozni (cri-o, containerd, docker-engine, stb).
Jahogy erre gondolsz.
Ez IMO annak nemsok vizet zavar, aki Swarm meretben gondolkozik.
> Aham... akkor nevezzük magas kerítésnek, amikor heteket kell szopni valamivel, ami másik megoldásnál fél sor.
Akkor visszatertunk az eredeti problemahoz. Vagy itt kell szopni v. ott. A kerdes, h melyikkel eri meg a szopas (nembeszelve arrol, h megeri-e egyaltalan a szopas). Kabathoz a gombot.
> Igen, ettől fal, hogy nem lehet megoldani és nyilván a falon belül élve nem is tudod, hogy amúgy szükséged lenne rá, csak nem tudod, hogy van olyan.
Ezen kivul ha nincs ra szuksege, akkor sem tud rola, nem?
Igazabol nem tudom, mit akartal ezzel mondani. Ez egy amolyan a viz nedves jellegu mondas volt.
> És ezt hány év Kubernetes tapasztalattal tudod kijelenteni? :D
Tokmind1. Alapvetoen meglep, h te azt gondolod, h tudod, milyen erzeseim vannak.
> Akkor nem fal, használd nyugodtan, drótozz hozzá egyéb eszközöket és tapaszd be sárral, hogy ne legyen feltűnő.
Azt latom rajtad, h kerdeztem toled vmit, amirol erdekeltek (volna) konkret informaciok (es amugy emellett az amugy szubjektiv, de ertelmesen negfogalmazott velemenyed is), erre arrogansan elkezdtel nyomulni es kozben 0 informaciot adni.
Kar, jo beszelgetes lehetett volna, mivel tobbszor volt, h tenyszeruen (ertekeset) nyilatkoztal.
Most mar nem erdekel.
Oké, összefoglalom: a Docker Swarm fasza, nincsenek benne limitek, ha vannak, akkor arra amúgy se lenne szükség.
https://iotguru.cloud
Flame OFF.
Nagyjából jól foglaltad össze.
A szükséges esetek 95%-át lefedi, cserébe jóval egyszerűbb mint a kubernetes bármelyik verziója.
pl egy ugyanolyan szolgáltatást (több konténeer, hálózat, replikáció stb) leíró docker file 20 sor ugyanez a kubernetes alatt 120 (!). Ebből következik, hogy a deocker file szemre sokkal olvashatóbb.
Olyan limitbe még én sem szaladtam még bele, ami gondot okozott volna, ezért is érdekelt volna engem is, hogy hol lehetnek azok a limitek, amit a swarm nem tud megugrani, de kubernetesben meg + 2 sor.
Akkor szerintem le is zárhatjuk, ugyanoda kerülünk vissza: a Docker Swarm fasza, nincsenek benne limitek, ha vannak, akkor arra amúgy se lenne szükség, mert a Swarm limitációi azért nem limitációk, mert úgyse jutni el odáig és ettől kezdve loop:
- [...] ott van hamar a fal
- Milyen fal?
- Ez-és-ez-és-ez.
- Ja, hogy azok?! Hát addig sose jutottam, tehát engem nem korlátoz, szóval nincs fal.
https://iotguru.cloud
Nem kell támadásnak venni a kérdést. Nem volt "Ez-és-ez-és-ez.", hanemcsak 1db példa ami arról szólt, hogy a kub tud több container engine-t kezelni.
Ez nyilván hasznos, de annak aki docker contaier-t szeretne futtatni annak meg nyílván mindegy. Ettől még persze plusz tudás.
De engem tényleg érdekelnének azok a technikai limitek (kapcsolatok száma, hálózat kialakítás bármi) amiben ezen kívül még limitbe ütköztetek.
Akkor ne vedd támadásnak... :D
De, volt ez-és-ez-és-ez. Igen, a legnagyobb különbség az, hogy a K8s tud több container engine-t kezelni, azoknak előnyeivel és hátrányaival, éppen mire kell: nagyon fontos különbség. Ezen túl leírtam, hogy a K8s egy komplett megtervezett egész, a Docker Swarm pedig általában a Docker hátán összedrótozott dolog, idézem szó szerint ezt a feelinget: "Azt nem neveznem fal-nak, h vmit egyeb eszkozzel kell megoldani.". De, az egy fal, ha hozzá kell drótozni valamit, hogy tudja, amit amúgy másvalami out-of-the-box tud.
Ezen túl, ha nem tudod, hogy mi ez a sok lényegi különbség egy Kubernetes és egy Docker Swarm között, akkor kb. egy percig se használtál még Kubernetes-t, különben nem jönnél ilyen kérdéssel, hogy ugyan, írjam már le, mivel tud többet vagy jobbat...
Szóva lásd loop, nem tudod, hogy kell-e, mert nem tudod, hogy mit nem tud, de mivel neked pont jó, ezért nyilván mindenkinek pont jó, kivéve kb. 5 százalék, viszont valami varázslatos módon pont a Kubernetes-t használják elsöprő többségében.
A limit nem azt jelenti, hogy mennyi konténer futhat, hanem azt, hogy mennyi feature hiányzik belőle és mekkora effort azt a feature-t beletenni és karbantartani.
https://iotguru.cloud
Erről mesélsz kicsit, hogy a gyakorlatban milyen különbségek tudnak lenni?
A CRI-O specifikusan Kubernetes alá készült from scratch, jobban együtt mozognak, kisebb a kódbázis, kevesebb a hiba, kevesebb az ismert security hole (ki van hagyva egy csomó capabilities), mert nem kell Docker-t is támogatni, ahogy a containerd esetén kell. Ebből adódóan előfordul, hogy nem megy az image CRI-O esetén, ami megy containerd esetén.
https://iotguru.cloud
"Ezen túl, ha nem tudod, hogy mi ez a sok lényegi különbség egy Kubernetes és egy Docker Swarm között, akkor kb. egy percig se használtál még Kubernetes-t, különben nem jönnél ilyen kérdéssel, hogy ugyan, írjam már le, mivel tud többet vagy jobbat..."
Ez többé kevésbé így is van. Kísérleteztük vele, hogy swarmról átállítsuk a szolgáltatásokat kubernetesre (értsd: van futó kub-unk rajta teszt szolgáltatással), de végül elvetettük, mert a gyakorlatban nem nyertünk vele semmit, csak kevésbé olvasható stack leírásokat.
És igen, ezért érdekelt volna olyan KONKRÉT eset, hogy ki milyen limitbe szaladt bele. Azok a bizonyos napi életben hasznos és hiányzó featurek.
És igen, TE valószínűleg sokkal jobban értesz hozzá, és nyilván ezért kérdeztem kvázi segítség kérésként. Persze erre lehet válasz a RTFM, de a leíráskból néha pont a lényeg nem derült ki. Pl mi Cephez akatuk illeszteni a kuberetest , de a neten talált megoldások egy részét vagy nem tartották már karban évek óta vagy simán csak nem működtek. Itt pl zavaró volt a kubernetes nagy szabadsága.
Had találjam ki: pont úgy építetted fel a Kubernetes cluster-t, ahogy a Docker Swarm felépült, pont annyira nem használod ki a Kubernetes tudását és lehetőségeit, aztán annyi maradt meg, hogy kevésbé olvashatók a stack leírások, gondolom Helm és GitOps az kanyarba se merült fel, a namespace sem volt használva, operátorok, selector-ok és egyebek szintén nem. Jól gondolom?
Lásd előző bekezdés. Ha ezekkel nem találkoztál, akkor nem hiányoznak, amikor találkozol ezekkel, akkor utólag azt fogod mondani, hogy a faszba tudtam ezek nélkül rendszert üzemeltetni.
Segítségkérés?!
Ezzel nyitottál, mintha használnál bőven éles üzemben Kubernetes-t, de egyszerűen a featureset nem kellene: "A szükséges esetek 95%-át lefedi, cserébe jóval egyszerűbb mint a kubernetes bármelyik verziója."
Aztán most kiderült, hogy van valami teszt Kubernetes, amiben felépítettél egy Docker Swarm logikával valamit, ami nem tetszik, mert többet kellett írni a .yaml fájlokba, ezért a Kubernetes felesleges, mert egyébként se érted. De nyilván segítséget kértél.
A Ceph amúgy is egy olyan kés, aminek a nyele is vág, de mutass már egy ilyet kérlek, hogy mit sikerült találni és az miért nem Ceph doksija volt.
https://iotguru.cloud
Ezek is falak ugyebár. A K8S sok koncepcióval dolgozik, és sok dolgot meg lehet benne oldani többféleképpen. A kérdés az, hogy mi az idiomatikus megoldás rá? Más lesz az idiomatikus megoldás bare K8S-ben, OpenShiftben, Azure AKS-ben, Google GKE-ben, AWS EKS-ben. A tanulási görbéje nemhogy meredek, de végtelen meredekségű, látva a verziók közötti inkompatibilitást.
Amúgy elszomorító az is, hogy mindenféle k8s szoftverhez githubról kell letölteni tgz-ket, ahelyett, hogy létezne deb vagy rpm csomag hozzá. Szabályozott környezetekben sima tgz-ket nem nagyon engednek telepíteni.
Nagyrészt ugyanaz lesz.
Meredek, de messze nem végtelen meredekségű, és jól dokumentáltak a deprecated és obsoleted részek eltávolításai, illetve az adott felhős rendszerek plusz szolgáltatásai.
Helm?
Másrészt egy Git repository alapú deployment a GitOps.
https://iotguru.cloud
Nem, nem Helmre gondolok.
Hanem arra, hogy:
- kubeadm RHEL9-re nincs RPM-ből. Az el7-re forduló csomag ugyan telepíthető, de isten őrizz, hogy bármilyen inkompatibilitás lépjen fel
- cri-o projekt nem ad ki RPM-et, az OpenSUSE-től tudsz letölteni ilyet, CentOS 9 Streamre. A dokumentációban meg kéne adni egy verziót is (lásd: https://github.com/cri-o/cri-o/blob/main/install.md#other-yum-based-ope…), viszont sehol nincs meg az értéke annak, hogy mit kéne ide megadni, mi mivel kompatibilis
- containerd.io elérhető RPM-ben a Dockertől (maga a projekt nem ad ki csomagot), de régi build, az új kubeadm nem kompatibilis vele (1.6.x nem implementálja az API-t, ami az 1.27-es-nek kell).
- nosza, telepíts containerd-t vagy cri-o-t tgz-ből, minden más egyéb függőségével (runc, stb.).
- próbáld meg összerakni, hogy mi mivel kompatibilis és mivel nem, nyilván erről dokumentáció könnyen elérhető helyen sehol.
Eléggé agyrém.
Ha meg OKD-t akarsz használni, akkor egyből 3 gépes klaszter kéne.
Ha meg k3s-t, akkor ugyanúgy nincs RPM, van curl | sh a tgz-re, a telepítési dokumentáció invalid, nem működnek bizonyos lépései permission probléma miatt. Persze, ki lehet javítani, meg utánajárni, de ehhez is el kell olvasni, hogy minek miért milyen jogosultságának kell lennie, mi hogyan helyes.
És ez még csak a telepítés.
Official Kubernetes repository miért nem jó? Eddig még soha nem telepítettem tgz-ből, csak csomagból.
https://iotguru.cloud
cri-o hol érhető el official Kubernetes repositoryból?
Sehol, mivel nem ott a helye. Csomagolják a distro-k: https://cri-o.io/
Én meg igen, erről szól ez a topik.
És elárulnád mi volt az?
Mondjuk elolvashatnád a fórumbejegyzést, én nyitottam, erről szól ez az egész topik: néha megy, néha nem megy a Swarm tagok között a névfeloldás.
De most komolyan, olyan topikhoz szólsz hozzá, amit el sem olvasol?
Bocs igazad van. De amit írtál az egy konkrét bug ami nyilván nagy szopás, de nem technológiai korlát.
Amely bug production problémát okoz.
Nem igazán látom, hogy miért lenne a Docker Swarm egy megbízható eszköz, ha az ilyen, eléggé komoly impakttal rendelkező bug csak úgy kikerülhet teszteletlenül a kiadásba.
Lehet, hogy papíron nincs technológiai korlátja a Docker Swarmnak, de ha az implementáció és a minőségbiztosítás tényleg ennyire csapnivaló, hogy egy alapvető klaszterszolgáltatás nem működik (nem arról van szó, hogy egy albeállítás albeállítása rosszul értelmeződik), akkor nincs helye productionben. Játszani jó, de éles rendszert nem lehet rábízni.
Nem akartam leírni korábban, de szerintem Docker nem való productionre.
Ha el tudod engedni a docker-compose használatát akkor lehet szórakozni podman-nel, de ez még mindig olyan lesz mint sajtreszelővel...
Igen, marad a K8s. Akár 1 node-os rendszerekhez is pl k3s.
Dockernek egyetlen piaci előnye van, az hogy a tanulási görbéje megugorható egy délután alatt. K8s-nek ha nekifekszel akkor pár nap alatt ugyanott vagy, utána meg nem érted miért nem ezzel kezdted.
offtopic: ha végignézed időrendben a hivatkozott blogom régebbi bejegyzéseit látni lehet, hogy minden út Rómába vezet. :/
Van már podman compose
Viszont az nem tud klasztert, az csak egy stacket húz fel egygépes környezetben.
A Compose leíró viszont működik Docker Engine és Docker Swarm esetén is (docker stack deploy vs docker compose up)
Tudom, de amire reagáltam, az konkrétan csak arról szólt, hogy a docker nem jó, és hogy compose file nélkül sajtreszelőzhetsz a podmannal. Értem, hogy a generic topic swarm volt, és tudom nincsen podman swarm (vagy hát van, k8snek hívják), csak itt most szűkebbnek tűnt a nem jó a docker productionbe. (Ami meg egyébként elég vicces, mert azért a világon egész sok dolog fut benne prodban. Gondolom ezekből van swarm is, bár azt én se hittem el sose, hogy szeretném élesben látni :))