Pular para o conteúdo principal

Lab 7.4 - Init Containers e Sidecars

Objetivos do Lab​

Ao final deste lab, você será capaz de:

  • Compreender o conceito de Init Container.
  • Criar Pods com Init Containers.
  • Utilizar Init Containers para preparação do ambiente.
  • Compreender o padrão Sidecar.
  • Implementar um padrão Sidecar para logging.

Duração Estimada​

45-60 minutos

Pré-requisitos​

  • kubectl instalado e configurado.
  • Cluster Kubernetes local funcional (minikube ou kind).
  • Conhecimentos sobre Init Containers e Sidecars (Capítulo 7.4).

Parte 1: Compreendendo os Init Containers​

Os Init Containers são executados antes dos containers principais de um Pod. Eles são úteis para:

  • Inicializar dados ou configurações
  • Aguardar dependências ficarem prontas
  • Preparar o ambiente antes do início da aplicação

Características:​

  • São executados sequencialmente (um após o outro)
  • Todos devem ser bem-sucedidos antes que os containers principais iniciem
  • Têm acesso aos mesmos volumes que os containers principais

Parte 2: Criando um Pod com Init Container​

Vamos criar um Pod com um Init Container que prepara arquivos antes do início da aplicação.

Etapa 2.1: Criar o Pod com Init Container​

Crie um arquivo pod-init-container.yaml:

# pod-init-container.yaml
apiVersion: v1
kind: Pod
metadata:
  name: app-with-init
spec:
  volumes:
  - name: shared-data
    emptyDir: {} # Volume compartilhado entre Init Container e container principal
  initContainers:
  - name: init-setup
    image: busybox:1.35
    command: ["/bin/sh", "-c"]
    args:
    - |
      echo "Init Container: Preparando o ambiente..."
      echo "Configuração inicializada" > /shared/config.txt
      echo "Dados preparados" > /shared/data.txt
      echo "Init Container finalizado com sucesso"
    volumeMounts:
    - name: shared-data
      mountPath: /shared
  containers:
  - name: app-container
    image: nginx:1.20
    command: ["/bin/sh", "-c"]
    args:
    - |
      echo "Aplicação: Lendo arquivos preparados pelo Init Container"
      cat /shared/config.txt
      cat /shared/data.txt
      echo "Aplicação iniciada"
      nginx -g "daemon off;"
    volumeMounts:
    - name: shared-data
      mountPath: /shared
    ports:
    - containerPort: 80

Explicação:

  • O Init Container prepara arquivos no volume compartilhado.
  • O container principal lê esses arquivos após o início.

Aplique o Pod:

kubectl apply -f pod-init-container.yaml

Etapa 2.2: Verificar a Execução​

Verifique o status do Pod:

kubectl get pods app-with-init

Você deve ver o Pod passando pelas fases:

  1. Init:0/1 (Init Container em execução)
  2. PodInitializing
  3. Running (container principal iniciado)

Verifique os logs do Init Container:

kubectl logs app-with-init -c init-setup

Verifique os logs do container principal:

kubectl logs app-with-init -c app-container

Você deve ver que o container principal leu os arquivos criados pelo Init Container.

Parte 3: Init Container com Espera de Dependência​

Os Init Containers podem aguardar até que serviços externos estejam disponíveis.

Etapa 3.1: Criar um Pod que Espera um Serviço​

Crie um arquivo pod-init-wait.yaml:

# pod-init-wait.yaml
apiVersion: v1
kind: Pod
metadata:
  name: app-wait-service
spec:
  initContainers:
  - name: wait-for-service
    image: busybox:1.35
    command: ["/bin/sh", "-c"]
    args:
    - |
      echo "Aguardando o serviço ficar disponível..."
      until nslookup kubernetes.default.svc.cluster.local; do
        echo "Serviço indisponível, aguardando..."
        sleep 2
      done
      echo "Serviço disponível!"
  containers:
  - name: app-container
    image: busybox:1.35
    command: ["/bin/sh", "-c"]
    args: ["echo 'Aplicação iniciada após verificação do serviço' && sleep 3600"]

Aplique o Pod:

kubectl apply -f pod-init-wait.yaml

Verifique os logs do Init Container:

kubectl logs app-wait-service -c wait-for-service

Parte 4: Padrão Sidecar​

Um Sidecar é um container auxiliar que roda no mesmo Pod que o container principal para fornecer funcionalidades complementares (logging, monitoring, proxy, etc.).

Etapa 4.1: Criar um Pod com Padrão Sidecar para Logging​

Crie um arquivo pod-sidecar-logging.yaml:

# pod-sidecar-logging.yaml
apiVersion: v1
kind: Pod
metadata:
  name: app-with-sidecar
spec:
  volumes:
  - name: shared-logs
    emptyDir: {} # Volume compartilhado para os logs
  containers:
  - name: app-container
    image: busybox:1.35
    command: ["/bin/sh", "-c"]
    args:
    - |
      counter=0
      while true; do
        echo "[$(date)] Log entry $counter from application" >> /logs/app.log
        counter=$((counter+1))
        sleep 5
      done
    volumeMounts:
    - name: shared-logs
      mountPath: /logs
  - name: log-collector
    image: busybox:1.35
    command: ["/bin/sh", "-c"]
    args:
    - |
      echo "Sidecar: Coletando logs da aplicação..."
      while true; do
        if [ -f /logs/app.log ]; then
          echo "=== Novos logs ==="
          tail -n 5 /logs/app.log
        fi
        sleep 10
      done
    volumeMounts:
    - name: shared-logs
      mountPath: /logs
      readOnly: true # O sidecar apenas lê os logs

Explicação:

  • O container principal escreve logs em um volume compartilhado.
  • O sidecar lê esses logs e os processa (neste caso, apenas exibe).

Aplique o Pod:

kubectl apply -f pod-sidecar-logging.yaml

Etapa 4.2: Verificar o Padrão Sidecar​

Verifique se ambos os containers estão em execução:

kubectl get pods app-with-sidecar

Verifique os logs do container principal:

kubectl logs app-with-sidecar -c app-container

Verifique os logs do sidecar:

kubectl logs app-with-sidecar -c log-collector

Você deve ver o sidecar exibindo os logs coletados do container principal.

Parte 5: Sidecar para Monitoring​

Vamos criar outro exemplo com um sidecar para monitoring.

Etapa 5.1: Criar um Pod com Sidecar de Monitoring​

Crie um arquivo pod-sidecar-monitoring.yaml:

# pod-sidecar-monitoring.yaml
apiVersion: v1
kind: Pod
metadata:
  name: app-monitored
spec:
  containers:
  - name: app-container
    image: nginx:1.20
    ports:
    - containerPort: 80
  - name: metrics-collector
    image: busybox:1.35
    command: ["/bin/sh", "-c"]
    args:
    - |
      echo "Sidecar: Coletando métricas..."
      while true; do
        # Simular coleta de métricas
        echo "[$(date)] Métricas coletadas: CPU, Memory, Network"
        sleep 15
      done

Aplique o Pod:

kubectl apply -f pod-sidecar-monitoring.yaml

Verifique os logs do sidecar:

kubectl logs app-monitored -c metrics-collector

Parte 6: Vantagens dos Padrões​

Init Containers:​

  • Separação de responsabilidades: Preparação vs execução
  • Ordem garantida: Executados antes dos containers principais
  • Reutilização: Mesmo Init Container para múltiplos Pods

Sidecars:​

  • Coesão: Containers no mesmo Pod compartilham rede e armazenamento
  • Flexibilidade: Adição de funcionalidades sem modificar a aplicação principal
  • Isolamento: Cada container pode ter seus próprios recursos

Parte 7: Limpeza​

Remova os Pods criados:

kubectl delete pod app-with-init app-wait-service app-with-sidecar app-monitored

Resumo do Lab​

Neste lab, você explorou os Init Containers e o padrão Sidecar. Você aprendeu a usar Init Containers para preparar o ambiente antes do início das aplicações, a implementar sidecars para logging e monitoring, e a entender as vantagens desses padrões para a arquitetura de aplicações.

Próximos Passos​

Este módulo sobre Workloads Avançados está agora completo. Você pode avançar para o Módulo 8 sobre Ingress e Load Balancing.

Módulo 8: Ingress e Load Balancing

Lab criado em: Dezembro 2024