Am moștenit o aplicație pe care trebuie să o implementez în interiorul clusterului ca un pod persistent pentru a avea acces la alte resurse, dar care rulează numai la cerere când un utilizator kubectl execs în pod. La inițializare, nu am nevoie de el pentru a face nimic altceva decât să fac podul disponibil pentru un utilizator exec la o dată ulterioară.
Acest lucru funcționează bine pe vechiul nostru cluster Jenkins-X 2, dar noua versiune Jenkinx-X 3 nu merge nicăieri.
Când este implementat, starea pare să treacă printr-un ciclu de viață de
Alergare
Efectuat
CrashLoopBackOff
in orice caz kubectl înregistrează -n <<namespace>> <<podname>> -p nu afișează erori și în kubectl descrie pod -n <<namespace>> <<podname>> cel Containers/<<appname>> sectiunea include
Stare: În așteptare
Motiv: CrashLoopBackOff
Ultima stare: Terminat
Motiv: finalizat
Cod de ieșire: 0
Ceea ce pare inconsecvent - nu văd cum a intrat CrashLoopBackoff cu o ultimă stare de Terminat deoarece Efectuat si un Cod de ieșire de 0 - aplicația, din câte văd, nu eșuează, doar că Kubernetes închide podul ca fiind finalizat, în loc să-l lase în funcțiune, iar apoi se blochează cumva în CrashLoopBackoff.
M-am întrebat dacă acest lucru are legătură cu probele de pregătire sau de viabilitate care îl distrug prin faptul că nu găsesc un proces care rulează permanent pentru a răspunde unei cereri, dar eliminarea acestora sau revenirea la versiuni mai vechi nu pare să facă nicio diferență.
Probabil că există ceva care a mers prost în topurile dintre versiunea veche și cea nouă, dar am rămas fără idei despre unde să caut. Există ceva ce oamenii pot sugera care ar putea fi cauza asta?
