Van egy 1 node-s Kubernetes clusterem, amin semmi nem fut(na), csak egy gitlab, aminek hostpathon vannak a cuccai. 1.22-ről jöttem fel 1.31-re, már ott tartok, h nulláról húzom újra, és 2 perc futás után minden ok nélkül lekapcsol a cluster.
Átmegy ready-be, minden faszának tűnik majd szétrohad a picsába. A kubelet logja gyakorlatilag olvashatatlan, nem tudom mit keressek benne, a kube-system alatti cuccokban nincs érdemi hiba, minden error kezdetű dolgot meggoogleztam, de semmi.
Nem tudok mire keresni, a kubelet logjában ugyan van egy csomó error, de tapasztalatból tudom, hogy ez normális, idő mire elindulnak a dolgok, de közben force probál minden mindenhez csatlakozni. 5 órája szopok vele, és kicsit tele van a hócipőm ezen a ponton.
A kubeadm reset / kubeadm init után van ez, nem fut még semmi, még a calicot sem tettem fel, mert odáig sem jutunk el. A containerd jó, abban sem látok hibát. Már csináltam egy default cni konfigot is ez alapján, de az se segít. El sem tudom képzelni már, mit rontok el, semmi extra nincsen a konfigban.
A kubeadm-et így futtatom:
kubeadm reset -f
kubeadm init --pod-network-cidr=10.88.0.0/16
Kínomban már leszedtem az ufw-t is (amúgy disabledben volt), az sem segített. Találtam egy ufw konfigot hozzá, bekonfiguráltam, hogy hátha valami defaultja van, ami beleszól, az se.
A kubelet logja főleg azzal van tele, hogy CrashLoopBackOff -ba került a kube-scheduler meg a kube-apiserver.
A kube-apiserver logja lényegében eseménytelen, a kube-schedulerben látok ilyet:
I0928 22:12:48.463694 1 shared_informer.go:313] Waiting for caches to sync for client-ca::kube-system::extension-apiserver-authentication::client-ca-file
E0928 22:12:48.463762 1 shared_informer.go:316] "Unhandled Error" err="unable to sync caches for client-ca::kube-system::extension-apiserver-authentication::client-ca-file" logger="UnhandledError"
de ezt azt tippelem, azért írja, mert a kube-apiserver épp nem fut olyankor. És mindegyik szervíznél azt látom, hogy valamilyen - számára - külső ok miatt álltak le.
FONTOS:
Nincs érdemi mentendő dolog a clusteren, a gépet nem tudom újra telepíteni, és a gitlab mappái kellenek ofc, de minden más kuka lehet mindaddig, amíg a gép maga még be tud bootolni és SSH-n elérhető lesz.
Felhőbe menni nem opció, külső szolgáltató nem opció (tőlem félig-meddig független okok miatt, erről nem tudok és nem is akarok bővebben beszélni). Szeretnék itt egy egy node-os k8s clustert, mert később kerülnének ide szolgáltatások, de ha ezt holnap délig nem oldom meg, akkor vmi docker alapú rendszer kerül ide (nem ragaszkodok múlhatatlanul a kuberneteshez, Portainerrel vagy valami más Docker konténereket kezelő cuccal is meg tudom oldani a problémáimat).
A fenti két bekezdést figyelembe nem vevő kommentekre nem fogok reagálni. Minden más segítséget megköszönök és igyekszem válaszolni.
Hozzászólások
Régebben (még ubuntu 20.04 alatt) próbálkoztam minikube-bal is megcsinálni ezt a rendszert, de valahogy nem volt szimpatikus az, ahogy összerakta a dolgot + hogy nem lehetett standard kubernetes parancsokkal operálni csak a minikube.kubectl meg társaival, ezért döntöttem az egy node-os kubeadm rendszer mellett, és eddig nagyon elégedett voltam ezzel a megoldással. Nincs szükségem sem HA -ra sem semmire, az kell, hogy egy standard kuberneteses szerverként működjön a gép, mert pár olyan dolgot is szeretnék integrálni majd, aminek kell az, hogy kubernetes legyen (pl GitLab CI-t kubernetes runnerrel is akarom majd használni).
Blog | @hron84
via @snq-
a minikube-bal mindig is lehetett kubectl-el dolgozni (minikube kubectl helyett) csak a kubeconf-ot kellett a megfelelo helyre masolni vagy az ENV vart beallitani. Csak hogy pontositsunk. Amugy ezt meg is csinalja neked.
"A kubelet logja főleg azzal van tele, hogy CrashLoopBackOff -ba került a kube-scheduler meg a kube-apiserver. "
Ezen a vonalon indulnék tovább. Akármilyen nagy is, log nélkül senki sem fog tudni segíteni, szerintem egy pastebin jellegű helyre bedobhatnád a releváns logokat. Mondjuk init után várj egy fél órát, hogy a "zaj" nagyjából elmúljon, és utána szedd ki a logokat.
Kubeadm reset a doksi szerint best effort jellegű. Etcd-t kézzel kiírtottad reset után?- *Bocs, koran volt. External etcdrol van szo :)"
kubeadm reset
will not delete any etcd data if external etcd is used. This means that if you runkubeadm init
again using the same etcd endpoints, you will see state from previous clusters."Próbáltad másik pod network cidr-el inicializálni a clustert?
> Próbáltad másik pod network cidr-el inicializálni a clustert?
Persze. Volt már a default kubeadm init is, ami nem tudom mivel próbálkozik, a Calico által ajánlott 192.168.0.0/16 is volt már. Amit érdekenek tartok, hogy a reset után nem hozza létre az /etc/cni/net.d alatt a cuccokat, amit 1.22 alatt egészen biztosan nem én hoztam létre. Valami rossz vudu biztos van a dologban, és érzem, hogy errefele van a baj, de nem jövök rá mi. Minden external CNI cucchoz működő cluster kellene, hogy a YAML-öket felrakjam rá (gondolok itt Calico, Flannel, Cilium, stb... ehhez kell egy 2 percnél tovább is működő cluster).
Blog | @hron84
via @snq-
systemd service logokat ki tudod tolni valahova? abbol azert sok minden kiderulhet.
Már nem, elbontottam a kubeadm-es rendszert.
Blog | @hron84
via @snq-
Ez egy elég nagy ugrás valószínűleg sok változás van, amit le kell követni 1.22. -> 1.31
Nagyobb változások voltak asszem 1.23, 1.27 és 1.30- as verzióknál.
https://kubernetes.io/releases/
A release notes-ba mindig bele van linkelve a changelog, ami segíthet a megoldásban.
Az 1.30.0 changelogba néztem bele, mert ott vannak az utolsó komoly major változások emlékeim szerint.
https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELO…
Ez a rész talán segíthet a fenti hibaüzenet megoldásában:
Nem upgrade-lek, már nullárol hozom létre a clustert. 1 darab deployment és 1 darab service volt kritikus belőle, az le van mentve, a cluster többi része pedig nem tartalmazott olyan információt, amiért kár lenne, így lebombáztam az egész clustert "kubeadm reset" -tel.
Amúgy, ez a feature gate érdekes, és megér egy misét. Azonban a helyzet az, hogy még a sima API szerveres várakozás is hazudik, ugyanis amint az API szerver egyetlen pillanatra is elérhetővé válik, már tovább lép, úgy, hogy közben n-szer újraindítgatja a kube-system teljes tartalmát.
Blog | @hron84
via @snq-
A client CA, amit hiányol (vagy vár) az létrejön vagy sose jut hozzá?
Van valami cert manager, ahonnan a cert-et kapja a Kubernetes API?
Ha kapok több logot és infót, akkor megpróbálom lemodellezni egy VM-ben, hogy ott is jelentkezik-e a hiba.
Meg tudod próbálni, 1.29 vagy 1.28 verzióval, ha van repóban. Lehet a 24.04 még nem támogatja az 1.31-et...
Feltettem a Kubernetes 1.31-et a Ubuntu 24.04-en, csak IPV4 alapon (asszem nem kellett a dualstack)
Amit használtam:
- Virtualbox VM: Linux/Ubuntu , 8GB memória, 50GB HDD, bridged network, promiscous mode engedélyezve.
- Ubuntu 24.04 server image, alap telepítés, SSH szerverrel
- Kubeadm telepítési útmutató a kubernetes.io oldalon
A dokumentációban sok manuális lépés volt a keyringek, IPv4 forward, swap-ot ki kellett kapcsolni, majd letiltani, containerd-t telepíteni. Docker már nem preferált, ezért célszerű lecserélni. Ha több hálózati interface van benne, akkor a `kubeadm init` parancsot fel kell paraméterezni, hogy hol listen-eljen.
Ha tudsz adni egy kubedm init parancs kimenetet, és egy `kubectl get -n kube-system pods`, ha már kubeadm init lefutott sikeresen.
A kubeadm init eseménytelenül lefutott, abban nem volt hiba, nem a preflight-nál haltunk meg. De már megoldottam k0s-sel (lásd lejjebb), feladtam a kubeadm-mel való beláthatatlan küzdelmet.
Blog | @hron84
via @snq-
Milyen OS, milyen repok vannak aktiválva, milyen csomagok vannak felrakva, milyen módszer / leírás / automatizmus szerint telepítetted a Kubernetest ? Egyáltalán melyiket (micrko8s, k3s, rke2, CNCF-féle)? Bare metal vagy virtualizáció (ha virt akkor melyik es milyen verzió)?
Honnan - mivel telepítetted a gitlabot ? Ha helm akkor milyen chart verzióval, mik voltak a template paraméterek ?
Azt irtad 1.22 -ről indultál: ott hibátlanul ment minden ? Miért kezdtél el upgrade-lni (eol, kellett vmi api ami csak magasabb verzioban volt, egyéb)? Mi a minimális cél verzió amit el kell érned ?
Amit én tennék egy hasonló helyzetben:
- shutdown és snapshot a gépről -> ha minden kötél szakad ide vissza lehet állni 1p alatt
- kube vissza 1.22-re, úgy menne - e ?
- ha igen, akkor egyesével, egy lépésben a köv minor legutolsójára frissítenék, és nézném meddig megy el, hol akad el
- utolsó lépésként: kiresetelném a kubeadm-mel, leszedném, lepurgálnám az etcd-t és minden konténert, reboot, etcd-t nulláról visszaraknám és ujjak csuriban
- kérnék egy új vm-et és Rancherrel vagy Kubespray-vel felhuznek egy uj clustert
- Milyen OS: Ubuntu 24.04. A standard kubernetes / kubeadm telepítési doksin mentem végig, teljesen standard Kubernetes cluster. Le is írtam a parancsokat.
- A GitLab jelenleg csak egy docker image. De teljesen irreleváns a kérdésben, nem a GitLab okozza a gondot, jelenleg nem is létezik a deploymentje, ahogy leírtam kb 2x, nulláról húzom újra a Kubernetes clustert már
- Miért kezdtél el upgradelni: részben mert EOL, részben pedig mert - amint azzal gondolom tisztában vagy te is - meg fognak szűnni azok a repositoryk, amikbők az 1.22-t lehet telepíteni, már az APT repót félig ki is vezették (ez a váltás már az 1.23 környékén elkezdődött, de mostanáig nem jutottam el idáig). Inkább tervezetten akarok ezzel szívni, mintsem egy esetleges komolyabb problémánál még ezzel is kínlódni.
- Minimális cél verzió nincs, de szeretnék egy olyan Kubernetes verzión lenni, ami egy ideig nem fog kikerülni a registry-kből / repókból.
- Fizikai gép, nem tudok snapshotot készíteni róla. Ha tudtam volna, most nem lennék szarban.
- vissza 1.22-re: Igen, jelenleg ez a tervem, de nem tudom ez mennyire opció, pont azért, mert a Google elkezdte megszűntetni a repókat. Nem tudom, hogy a régi docker image-k még elérhetők-e a kubeadm-es telepítéshez. A másik, hogy az 1.22-nél még Dockert használtam Container Engine-nek, és ez most már nem biztos, hogy opció. Megnézem ezt a cri-docker dolgot, de az a sejtésem, hogy másképpen működik, mint a régi Dockeres implementáció. Nem tudom, hogy hogyan működik, és ez zavar.
- utolsó lépésként: nem tudom, mit olvastál, de egészen konkrétan ezt írtam le. A kubeadm reset pontosan ezt csinálja.
Köszönöm a segítséget, de arra kérlek, még egyszer olvasd át a nyitó postot, mert nem vettél át minden részletet.
Blog | @hron84
via @snq-
Ugye nem direkt-be frissitettel 1.22-tol 1.31-re, hanem lepesenkent?
Lépésenként próbáltam, de a Docker -> Containerd átállásnál már hibákba szaladtam bele. Mivel semmilyen kritikus adat nem volt a Kubernetes clusterben, ezért nulláról akartam újratelepíteni 1.31-gyel, nem valódi kubeadm upgrade-del (1 darab deployment és 1 darab svc objektmot félálomban is tudok reprodukálni).
Blog | @hron84
via @snq-
A kollega amugy irta, hogy mar ott tart, hogy "nullarol huzza ujra"
Szoval az upgrade-et mar elengedte.
Az en tippem az, hogy a kubeadm reset nem takarit el valami CRD-t amivel osszeakad a legfrissebb verzio (microk8s pl. egy csomo CRD-t otthagy reset utan)
Amennyire tudom, a CRD-k az etcd-ben tárolódnak, azt meg fájl szinten törli el. Illetve a /var/lib/kubelet mappát is teljesen leüríti, az /etc/kubernetes mappával egyetemben. Hard to belive, hogy egy CRD ezek után valahogy túlélne.
Blog | @hron84
via @snq-
Esetleg https://k0sproject.io/ ?
Megnézem, de ez még a kubeadm-esnél is nagyobb mágiának tűnik. Középkezdőként (már nem kezdő, még nem haladó) a Kubernetesben, mindig kicsit félek ezektől, mert nem tudom, milyen fekete mágia megy a háttérben. A kubeadm-est úgy-ahogy már értem.
De ezzel együtt adok neki egy esélyt, rajtam nem múlik. Ahogy nézem, ez rendes Kubernetes clustert telepít, nem ilyen MicroK8s szinten szétberheltet ugye?
Blog | @hron84
via @snq-
Rendes Kubernetes cluster épít. Erre amúgy akár egy k3s is jó, nekem egy AWX zötyög vele teljesen oké módon. Ezek a megoldások fél órán belül működőkpessé tehetők, egy node-on még talán gyorsabban is.
A k3s-t nézegettem már, de a Rancher miatt fázok tőle, mást tervezek használni automatizációra, és nem szeretem az ilyen "ajándékba" kapott megoldásokat, mert azokkal mindig csak a baj van, vagy mert kerülgetni kell őket, vagy mert nem lehet őket komolyabb sérülés nélkül kivenni a rendszerből. Inkább szeretem nulláról felépíteni a dolgokat.
A Rancher miatt egy párszor már amúgy is voltak nehéz éjszakáim, köszönöm, nem kérem.
Blog | @hron84
via @snq-
pure k3s-ben nincs rancher
A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!
A k3s ès a rancher kèt kūlön dolog. Az alapjait sem èrted a Kubernetesnek , engedd el, tèrj vissza Dockerre.
Köszönöm, megfontoltam bölcs tanácsodat, ám arra jutottam, hogy nem fogadom meg. Ha nem használom, sosem fogom megérteni.
Blog | @hron84
via @snq-
Bocsánat, de ahhoz meg kellene tanulni a dolgok működését.
https://iotguru.cloud
Bocsánat, de én így tanulom meg a dolgok működését.
Blog | @hron84
via @snq-
Lehet belőle tanulni, az igaz... de azért minimális doksit érdemes olvasni, főleg upgrade előtt, mert különben megszopod. Nagyon.
https://iotguru.cloud
Végül ez lett. Nagyon érdekesen működik, a beépített Helm Chart telepítős rendszert 4 próbálkozásból csak egyszer sikerült működésre bírni, utána hiába definiáltam benne bármit, nem csinálta meg, és ugyanez az OpenEBS volume kezelővel. De ez a legkissebb, sokkal fontosabb, hogy egy jól működő, testreszabható, szabványos Kubernetes Clustert kaptam a végére, a Helm chartokat már pikk-pakk felpakolásztam (köztük az OpenEBS-t is, LVM kezelővel együtt). Jár a virtuális sör.
Blog | @hron84
via @snq-
Én most kollégák tanácsára, véleményére alapozva elkezdtem a microk8s-t és pont erre való amire szeretnéd. Kicsi, 1 node-os rendszerek, dev, teszt, miegymás. Production ready, eddig több gépen is próbáltam és tök jól működik. Messze ez a legjobb eddig amit próbáltam, ráadásul Ubuntu projekt, tehát nem kell hákolnod sem (mint tettem én pl. OracleLinuxra).
Felrak, init, örül. Kb. 5 perc a setup és működik. Portainert ha bekapcsolod benne akkor az is rögtön van és lát mindent is.
Nekem az összes eddigi szenvedéshez képest ez nagyon pozitív csalódás volt, már ami a telepítés, alapkonfigot illeti.
A MicroK8s nagyon testre van szabva, nekem nem tetszik, ahogy működik. Végül k0s lett, az közelebb van ahhoz, amit szeretnék.
Illetve cégnél is próbáltuk, és középtávon volt vele több problémánk a storegeclassok kapcsán.
Blog | @hron84
via @snq-
https://gitlab.com/talentiaacademy/k8s-training
Hát, ott még nem járok h. rook v. hasonlókat beledrótozzak, de eddig bejött. Teljesen offtopic, de ha errejársz leírod h. mi volt a gond?
Amúgy igen, erősen testre van szabva, de Ubuntu tolja és sztem nem fog mögüle kihátrálni, így lehet rá alapozni. Persze nálam is inkább még a teszt fázis van, mellette most nyomkodjuk az Oracle Cloud Native Environmentet, ami egyébként meglepően jónak tűnik a 2.0-ás verziótól (ez meg viszonylag új, 1.9-ig sztem teljes tévút volt)
Az a mondás microk8s-hez hogy 50 node-ig simán kiskálázódik, ami valljuk be, már nem egy kicsi 1 node-os rendszer. Szóval elég rugalmas tud lenni.
Etcd logokat nézd meg, mert azt hiszem, ha az nem megy jól, akkor esélye sincsen a többinek.
Etcd végtelen ciklusba tud esni, ha nem létező node-ot keres és szavazásra várja, olyankor kell neki egy plusz paraméter a konfigban
/etc/kubernetes/manifest/etcd.yaml
--force-new-cluster
amit sikeres indítás után ki kell szedni
kubeadm initkor nem kell egy --cri-socket= paraméter is?
Az egyetlen ami jól működött az az etcd... Az maradt mindig talpon. És nem volt hiba a logjába, a db létezett, elérte, listenelt, etcdctl-lel teljesen healthy volt.
A kubeadm init.nek akkor kell a cri socket, ha nem default socketen figyel a containerd.
Blog | @hron84
via @snq-
Azért ez merész, a tipikus upgrade path az a kettő közötti összes major (1.23, 1.24, ..., 1.30), úgy, hogy felhúzod az utolsó minor verzióra. És ezt is kifejezetten kubeadm paranccsal, például:
Enélkül tipikusan szétesik a picsába, mint a mellékelt ábra is mutatja.
Ezzel kezdjed: `mv /etc/kubernetes/ /etc/kubernetes.old/; mv ~./kube/ ~./kube.old/`
Szerintem ott maradt egy csomó szemét, ami zavart okoz az erőben.
https://iotguru.cloud
A kubeadm upgrade ott halt meg, hogy a 1.23-ban nem támogatott a Docker mint Container Engine, és amikor átállítottam ContainerD -re, akkor meg hibára szaladt az upgrade (sokkal később találtam meg a cri-docker intézményét, nem kell leírni, hogy létezik). Ekkor döntöttem úgy, hogy inkább nulláról újra húzom.
> Ezzel kezdjed: `mv /etc/kubernetes/ /etc/kubernetes.old/; mv ~./kube/ ~./kube.old/`
> Szerintem ott maradt egy csomó szemét, ami zavart okoz az erőben.
A kubeadm teljesen eltörli a /etc/kubernetes mappa tartalmát (= üres mappák maradnak utána), a ~/.kube -t pedig minden egyes reset előtt eltöröltem. Azonban nem gondolom, hogy a ~/.kube mappa bármit befolyásolt, mert a telepítés sikerült, maguk a szervizek haldokoltak össze-vissza (amik cluster-belső credentiallal működnek), a kubelet pedig teljesen saját credentiallal éri el a clustert, nem a root home-jában levő credentiallal. És a kubeadm is a /etc/kubernetes/admin.conf -ot használja a validációk során.
Mondhatnám én is, hogy nézz utána a Kubernetes működésének alapjainak - mert én ezeket ebben az esetben megtettem - de unfair lenne ez tőlem.
Blog | @hron84
via @snq-
És hogy szaladt el akkor 1.31-ig a dolog? Véletlenül? A megfelelő upgrade path betartása nélkül szinte biztosa szét fog esni a cluster, mert nem futnak le migrációs scriptek.
Nem, nem szokott mindent törölni, a node dolgait törli, a certek tipikusan maradnak (default /etc/kubernetes/pki/ alatt) és a tmp is (de ez nem szokott bajt okozni, itt vannak az upgrade során végzett mentések), kivéve, ha explicit kéred, hogy ezeket is törölje. Ha a pki ott maradt, miközben létrehoztál egy új cluster-t, akkor könnyen lehet, hogy nem tudnak egymással beszélni a részei, mert nem volt valid a cert és a "unable to sync caches for client-ca" is erre utal.
Azért jó törölni (illetve átnevezni), mert a kubectl azt használja és egy csomó dolgot kubectl használatával lehet megnézni, nem pedig a kubeadm használatával...
Oké, akkor szopjál. :D
https://iotguru.cloud
sot marad az /etc/containerd meg a /var/lib/cni meg az osszes tobbi is :D
Egy k8s ujrahuzasa teljesen szuz modon, szuz gepet IS jelent, nem azt, hogy par dolgot torlok innen onnan. Vagy mehet a "virsh undefine/define..." es akkor tuti szep uj ropogos VM-en fog futni. Vagy ugye kovetni kell az upgrade path-ot :D
De ezt mar mondtad. Na mindegy is.
Ahja, de ezekben nem szokott akkora baj maradni, mondjuk a config.toml tartalma lehet szar, az igaz, szóval ezt se árt újrakreálni adott esetben.
https://iotguru.cloud
"Mondhatnám én is, hogy nézz utána a Kubernetes működésének alapjainak - mert én ezeket ebben az esetben megtettem - de unfair lenne ez tőlem."
bármi más hülyeséget is mondhatsz, hup megbírja. Ha megnézed kettőtök közül a te clustered esett szét, nem _Franko_ -é.
Gábriel Ákos