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/16Kí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 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 resetwill not delete any etcd data if external etcd is used. This means that if you runkubeadm initagain 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?
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-
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.