Init Container e Multi Containers

Multi Containers

Como sabemos um pod pode ter mais de um container.

Os containers em um pod dividem a mesma rede, os mesmos volumes declarados, e todas as coisas que estão definidas em spec.

Eles nascem juntos e morrem juntos. O containers em um pod são escalados juntos e o service aponta para o pod, sendo que cada container escuta em uma porta específica do pod. Sendo assim um service pode apontar para as portas de ambos os containers.

Como mencionado anteriormente, um pod deve rodar sua aplicação principal em um container, porém muitas vezes precisam de outros containers ao lado para ajudar em algumas coisas e não misturar as funcionalidades das aplicações.

Esses containers são chamados de sidecars.

É muito usado por exemplo para enviar log da aplicação para algum lugar específico, mas possuem outras funcionalidades que são melhores definidas no curso de CKAD.

É esperado que estes containers estejam sempre vivos para que o pod se mantenha vivo.

Se qualquer um dos containers falharem o pod irá reiniciar.

Init Containers

Algumas vezes precisamos somente rodar um processo que deve ser completado em um container como por exemplo fazer um pull de um código ou de um binário para ser usado pela aplicação principal. Após terminar o pull o container irá parar e não se manterá vivo e o pod irá ficar reiniciando.

Nesse caso usamos o init containers.

O init containers roda processos antes dos containers iniciarem e somente roda uma vez durante a criação do pod. Os containers do init containers devem ter completado sua tarefa para que os containers possam iniciar.

Caso algum pod do init containers falhe sua tarefa o Kubernetes irá ficar reiniciando o pod repetidamente até que todos os container do init containers sejam iniciado com sucesso.

Dessa forma os processos do init container precisam terminar ao invés de ter um processo que os mantém vivo como nos containers padrões.

Isso é muito usado para fazer bootstrap de aplicações.

apiVersion: v1
kind: Pod
metadata:
  name: myapp-pod
  labels:
    app: myapp
spec:
  # Esse é o container da aplicação
  containers:
  - name: myapp-container
    image: alpine
    command: ['echo', 'The app is running', '&&','sleep 3600']
  # Esses são os containers que precisam iniciar antes da aplicação.
  initContainers:
  - name: init-myservice
    image: busybox
    command: ['slepp', "30"]
    # Simulação de um segundo processo
  - name: init-mydb
    image: busybox
    command: ['sleep', '60']

Não faria sentido subir a aplicação se ela é dependente de outra e precisamos garantir que o serviço esteja disponível e usamos nesse caso dois containers para fazer as verificações.

Os containers do init-containers NÃO EXECUTAM EM PARALELO, mas SEQUENCIALMENTE. Primeiro um termina para depois começar o outro.

Se temos uma sequência de dois containers um com sleep 30 e outro com sleep 90, primeiro esperaríamos o 30 e depois o 60 dando um total de 90 segundos.

Outra curiosidade é que os pods quando mostram 2/2 3/3 significam containers e não init containers. Eles não são somados aos containers.