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.
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?
É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.
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.
É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.
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.
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.
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.