Conceito e mecanismo
Um init container normal executa antes dos containers de aplicação e precisa de terminar com sucesso. É adequado para preparação finita, como gerar configuração, com retries seguros. Um processo infinito num init normal bloqueia o arranque; um sidecar tem outra função e regras próprias. Num Pod com vários containers, explicita os volumes partilhados e os paths montados. O facto de partilharem um Pod não significa que qualquer diretório da imagem seja automaticamente comum. Observa o estado e os logs do container certo para distinguir preparação falhada de falha da aplicação.
Aplicação guiada
emptyDir acompanha o ciclo de vida do Pod e pode conservar ficheiros quando um container reinicia nesse Pod. Ao remover o Pod, os dados são perdidos. Serve cache e partilha temporária, não arquivo de comprovativos. Para persistência, avalia PVC, StorageClass, topologia e modos de acesso suportados. O modo de montagem não implementa coordenação de escritores nem backup. Num serviço com várias réplicas, identifica quem escreve cada objeto e como recuperar consistência após falha, em vez de assumir que um volume partilhado resolve o desenho da aplicação.
Um init gera /config/runtime.json num emptyDir montado também pela aplicação. Já os comprovativos de pagamentos exigem armazenamento durável e recuperação testada separadamente.
Armadilhas comuns
Esperar readiness para corrigir init falhado; usar emptyDir como arquivo; confundir persistência com segurança de escritas concorrentes.
Tópicos relacionados: Deployments e recuperação · Observabilidade e manutenção da aplicação
Planeia separadamente arranque, partilha temporária e durabilidade.
Referência: Init containers · CKAD Kubernetes v1.37