I've inherited an application I need to deploy inside the cluster as a persistent pod to have access to other resources, but which only runs on demand when a user kubectl exec
s into the pod. At initialisation I don't need it to do anything at all other than make the pod available for a user to exec
into at a later date.
This works fine on our old Jenkins-X 2 cluster, but the new Jenkinx-X 3 version is going nowhere.
When it's deployed the status appears to go through a lifecycle of
Running
Completed
CrashLoopBackOff
However kubectl logs -n <<namespace>> <<podname>> -p
shows no errors, and in kubectl describe pod -n <<namespace>> <<podname>>
the Containers/<<appname>>
section includes
State: Waiting
Reason: CrashLoopBackOff
Last State: Terminated
Reason: Completed
Exit Code: 0
Which looks inconsistent - I can't see how it's got into CrashLoopBackoff
with a last state of Terminated
because Completed
and an Exit Code
of 0 - the application, as far as I can see isn't failing, it's just that Kubernetes is shutting down the pod as completed rather than leaving it running, and it's then somehow getting stuck in CrashLoopBackoff.
I'd wondered whether this was something to do with readiness or liveness probes killing it through not finding a perpetually running process to service a request, but removing them or reverting to older versions doesn't seem to make any difference.
There's presumably something that's gone wrong in the charts between the old and new versions, but I'm running out of ideas on where to look. Is there anything people can suggest that might be causing this?