O que acontece quando o kubernetes reinicia os contêineres ou o cluster é ampliado?
Estamos usando o Helm Chart para implantar o aplicativo no cluster Kubernetes .
Temos um serviço statefulsets e headless. Para inicializar o mTLS, criamos um tipo de 'trabalho' e em 'comando' estamos passando os scripts shell e python como argumentos. E criou um tipo de 'cronjob' para atualizar o certificado.
Escrevemos um 'docker-entrypoint.sh' dentro da 'imagem docker' para algum trabalho de inicialização e para gerar certificados TLS.
Perguntas a serem feitas :
- Quem (Helm Chart / Kubernetes) cuida do dimensionamento / monitoramento / reinicialização dos contêineres?
- Ele implanta uma nova imagem do docker se o pod falhar / reiniciar?
- O docker ENTRYPOINT será executado depois que o contêiner falhar / reiniciar?
- 'Job' e 'cronjob' são executados se o contêiner for reiniciado?
Quais são as outras etapas executadas pelo Kubernetes? Você também compartilharia insights sobre contêineres?
Respostas
O Kubernetes, e não o helm, reiniciará um contêiner com falha por padrão, a menos que você defina restartPolicy: Neverna especificação do pod
Reiniciar o contêiner é exatamente igual a iniciá-lo da primeira vez. Portanto, na reinicialização, você pode esperar que as coisas aconteçam da mesma maneira que aconteceria ao iniciar o contêiner pela primeira vez.
O agente kubelet em execução em cada nó do kubernetes delega a tarefa de iniciar um contêiner para o tempo de execução do contêiner de reclamação OCI , como docker, containerd etc, que então ativa a imagem do docker como um contêiner no nó.
Eu esperaria que o script do entrypoint fosse executado ao iniciar uma reinicialização de um contêiner.
Ele implanta uma nova imagem do docker se o pod falhar / reiniciar?
Ele cria um novo contêiner com a mesma imagem especificada na especificação do pod.
'Job' e 'cronjob' são executados se o contêiner for reiniciado?
Se um contêiner que faz parte do cronjob falhar, o kubernetes continuará reiniciando (a menos que restartPolicy: Neverna especificação do pod) o contêiner até que o job não seja considerado com falha. Verifique isso para saber como fazer um cronjob não reiniciar um contêiner em caso de falha. Você pode especificar backoffLimitpara controlar o número de vezes que ele tentará novamente antes que o trabalho seja considerado com falha.
Aumentar a escala é equivalente a programar e iniciar outra instância do mesmo contêiner no mesmo nó Kubernetes ou em um nó Kubernetes totalmente diferente.
Como uma observação lateral, você deve usar abstração de nível mais alto, como implantação em vez de pod, porque quando um pod falha, o Kubernetes tenta reiniciá-lo no mesmo nó, mas quando uma implantação falha, o Kubernetes tentará reiniciá-lo em outros nós também se não for capaz de inicie o pod em seu nó agendado atual.