
Herdei um aplicativo que preciso implantar dentro do cluster como um pod persistente para ter acesso a outros recursos, mas que só é executado sob demanda quando um usuário kubectl exec
entra no pod. Na inicialização, não preciso fazer nada além de disponibilizar o pod para um usuário exec
posteriormente.
Isso funciona bem em nosso antigo cluster Jenkins-X 2, mas a nova versão Jenkinx-X 3 não leva a lugar nenhum.
Quando é implantado, o status parece passar por um ciclo de vida de
Running
Completed
CrashLoopBackOff
No entanto kubectl logs -n <<namespace>> <<podname>> -p
não mostra erros e na kubectl describe pod -n <<namespace>> <<podname>>
seção Containers/<<appname>>
inclui
State: Waiting
Reason: CrashLoopBackOff
Last State: Terminated
Reason: Completed
Exit Code: 0
O que parece inconsistente - não consigo ver como ele chegou CrashLoopBackoff
ao último estado Terminated
porque Completed
e Exit Code
0 - o aplicativo, até onde posso ver, não está falhando, é só que o Kubernetes está desligando o pod como concluído em vez do que deixá-lo em execução e, de alguma forma, ele fica preso no CrashLoopBackoff.
Eu me perguntei se isso tinha algo a ver com testes de prontidão ou de atividade, matando-o por não encontrar um processo em execução perpetuamente para atender a uma solicitação, mas removê-los ou reverter para versões mais antigas não parece fazer nenhuma diferença.
Presumivelmente, algo deu errado nos gráficos entre as versões antiga e nova, mas estou ficando sem ideias sobre onde procurar. Há algo que as pessoas possam sugerir que possa estar causando isso?