O que e um sidecar container? Ajudantes que rodam ao lado do seu app
Um sidecar e um continer secundario que roda ao lado do seu app principal no mesmo pod, compartilhando sua rede e lifecycle para fornecer uma capacidade de apoio.
As vezes um recurso - envio de logs, um proxy, metricas - nao pertence dentro do seu app, mas precisa rodar bem ao lado dele. O padrao sidecar coloca esse ajudante em um continer separado no mesmo pod, para que ele compartilhe a rede e o storage do app sem inchar a imagem da aplicacao.
Como um sidecar compartilha contexto
Por viver no mesmo pod, um sidecar compartilha o namespace de rede (acessivel em localhost) e pode compartilhar volumes com o continer principal. Eles sao agendados juntos e vivem e morrem juntos.
Usos comuns
- Coletores de logs e metricas que leem arquivos compartilhados.
- Proxies de service-mesh (por exemplo, Envoy) tratando o trafego.
- Um cache local ou proxy de auth na frente do app.
Sidecar vs init container
Um init container roda ate concluir antes de o app iniciar (trabalho de setup). Um sidecar roda por toda a vida do pod, em paralelo com o app. Trabalhos diferentes, lifecycles diferentes.
Mantenha-o coeso
Um sidecar deve genuinamente pertencer ao app - mesmo lifecycle, mesmo pod. Colocar servicos nao relacionados em um pod so para "economizar um pod" acopla coisas que deveriam escalar de forma independente.
Sidecars na CI
A mesma ideia aparece na CI como service containers e processos ajudantes (por exemplo, um proxy de cache) rodando ao lado do seu job. Runners gerenciados costumam trazer esses ajudantes embutidos, para que seu job ganhe caching ou proxy sem setup extra.
Principais conclusões
- Um sidecar roda ao lado do seu app no mesmo pod, compartilhando rede e storage.
- Ele adiciona uma capacidade sem inchar a imagem da aplicacao.
- Sidecars rodam por toda a vida do pod; init containers rodam primeiro e terminam.