APRENDER. PRATICAR. EVOLUIR.O artefacto que chega ao runtime
Um build multi-stage produz estágios distintos. COPY --from=build /out/worker /app/worker copia o artefacto, não todo o ambiente do compilador. Para modificar a imagem, altera o código ou o Dockerfile, constrói o estágio final pretendido e publica uma identidade de imagem que o ambiente de destino consiga obter.
Um build com --target build termina no estágio intermédio e pode não representar a imagem de produção. O sucesso do build não demonstra que o executável encontra o interpretador, bibliotecas, certificados ou ficheiros de configuração no estágio final.
Verifica também arquitetura, utilizador e permissões. Usa o digest do artefacto aceite no manifesto; uma tag mutável pode apontar para outro conteúdo mais tarde.
Uma réplica por nó elegível
Um Deployment gere um número de réplicas; não promete uma réplica em cada nó. Para um coletor que deve acompanhar cada nó com etiqueta telemetry=enabled, usa um DaemonSet com essa seleção. Novos nós elegíveis passam a fazer parte do conjunto pretendido e nós que deixam de corresponder deixam de o integrar.
A seleção não dispensa condições de scheduling: verifica taints, tolerations, capacidade e regras de afinidade. Uma toleration permite considerar um nó com determinado taint; não escolhe esse nó nem demonstra capacidade. Compara desiredNumberScheduled, currentNumberScheduled, numberReady e os eventos dos Pods.
O número total de nós do cluster não é, por si só, o denominador correto.
Preparação finita ou serviço auxiliar
Um init container regular prepara algo e termina com sucesso antes do seguinte. Um processo que espera para sempre nesse lugar impede o arranque da aplicação. Um sidecar nativo é uma entrada de initContainers com restartPolicy: Always ao nível desse container.
O kubelet avança para o próximo init quando o sidecar fica started: se existir startupProbe, espera pelo seu sucesso; sem ela, basta o processo estar em execução. Essa sequência não significa que qualquer dependência de negócio já esteja disponível.
Define uma verificação de arranque que represente a preparação necessária. Um container auxiliar colocado apenas em containers não recebe automaticamente estas regras de ordenação.
Readiness e conclusão não são o mesmo sinal
Uma readinessProbe num sidecar nativo contribui para a condição Ready do Pod. Falhar readiness pode retirar esse Pod dos endpoints prontos sem reiniciar a aplicação. Num Job, um sidecar nativo ainda em execução não impede a conclusão depois de terminar o trabalho principal; um auxiliar sem fim em containers pode impedir que todos os containers da aplicação terminem.
Durante a terminação do Pod, os sidecars nativos são terminados depois dos containers principais, em ordem inversa à declaração. Isto oferece uma sequência, não uma garantia de entrega de todos os logs: o prazo de terminação continua limitado.
Para dados importantes, exige confirmação persistente e reconciliação.
Partilhar dados com um contrato explícito
Containers do mesmo Pod partilham a rede, mas cada um mantém o seu filesystem de imagem. Para passar ficheiros, declara um volume e monta-o nos dois containers; os caminhos podem ser diferentes, desde que apontem para o mesmo volume. emptyDir serve dados temporários durante a vida do Pod.
Reiniciar um container não equivale a substituir o Pod. Se a aplicação precisa de recuperar um resultado após substituição, escolhe persistência adequada e define como distinguir um resultado completo de um ficheiro parcialmente escrito. A existência de um sidecar não cria esse protocolo.
Se o coletor apenas exporta telemetria descartável, documenta essa diferença em relação aos recibos de negócio.
Ler o manifesto antes de escolher a recuperação
O excerto abaixo representa parte de um PodSpec, não um laboratório autónomo. As imagens e os comandos são nomes ilustrativos de uma aplicação. O sidecar inicia primeiro e a sua startupProbe condiciona a passagem à preparação seguinte; a readinessProbe participa depois na prontidão do Pod.
Se a preparação não começa, observa o estado e a startupProbe do sidecar antes de aumentar o timeout da aplicação. Se a aplicação corre mas o Pod não fica Ready, verifica cada readinessProbe. Se os ficheiros não aparecem, compara nomes dos volumes e mounts.
Este diagnóstico separa arranque, prontidão e dados, permitindo uma correção localizada.
initContainers:
- name: collector
image: registry.example/collector:reviewed
restartPolicy: Always
startupProbe:
exec:
command: ["/collector-check", "started"]
readinessProbe:
exec:
command: ["/collector-check", "ready"]
volumeMounts:
- name: exchange
mountPath: /input
- name: prepare
image: registry.example/prepare:reviewed
volumeMounts:
- name: exchange
mountPath: /out
containers:
- name: application
image: registry.example/application:reviewed
volumeMounts:
- name: exchange
mountPath: /work
volumes:
- name: exchange
emptyDir: {}Um Job de exportação termina o trabalho principal, mas mantém um coletor sem fim em containers. A equipa move o coletor para initContainers sem mais alterações e o trabalho deixa de arrancar. A decisão precisa das regras de sidecar nativo, de uma startupProbe útil e de um contrato de entrega para os ficheiros; mover uma linha de YAML não demonstra recuperação.
Armadilhas comuns
Confundir réplica por nó com número fixo de réplicas; usar um init regular para um serviço sem fim; tratar readiness como conclusão de negócio.
Tópicos relacionados: Workloads e configuração · Observabilidade e segurança
Escolhe o controlador pela unidade de trabalho e cada container pelo seu ciclo de vida. Confirma a imagem final, a sequência, a prontidão e a persistência separadamente.
Referências
- Sidecar containers · Kubernetes v1.37 documentation; targeted passages read 2026-10-23
- DaemonSet · Kubernetes v1.37 documentation; targeted passages read 2026-10-23
- Multi-stage container builds · Docker documentation consulted 2026-10-02
- Volumes · Kubernetes v1.37 documentation; main site consulted 2026-10-02