Container Compute Service:Configure sidecar startup and shutdown

Descrição do recurso

Os clusters do Alibaba Cloud Container Compute Service (ACS) não suportam DaemonSets devido às limitações dos nós virtuais. Para obter um efeito similar ao do DaemonSet, adicione containers sidecar aos pods nos clusters ACS. Como o ciclo de vida dos containers sidecar não é independente do ciclo de vida do pod, configure as prioridades de inicialização e encerramento para simular o comportamento de um DaemonSet. Por exemplo, os containers sidecar podem precisar iniciar antes dos containers da aplicação principal durante a criação do pod. Em pods do tipo Job, talvez seja necessário forçar o encerramento dos containers sidecar após o término dos containers da aplicação principal.

O ACS oferece os seguintes métodos para configurar as prioridades de inicialização e encerramento de containers sidecar:

• Configuração nativa de container sidecar do Kubernetes

  No Kubernetes 1.29 e versões posteriores, o suporte à configuração nativa de sidecar vem ativado por padrão. Configure um sidecar definindo-o como um init container e ajustando seu restartPolicy para Always.

  Nota

  A abordagem nativa implementa o container sidecar como um init container especial. Durante a inicialização do Pod, os containers da aplicação aguardam o início do container sidecar. A configuração restartPolicy: Always permite que o container sidecar inicie, pare e reinicie sem afetar o container da aplicação principal ou outros init containers.

• Configuração de container sidecar otimizada pelo ACS

  Nas versões 1.28 e anteriores do Kubernetes, o ACS permite definir a variável de ambiente especial __IS_SIDECAR__ para marcar um container comum como sidecar.

  Importante

  A configuração otimizada pelo ACS permite declarar um container comum como sidecar. Ele inicia antes de outros containers comuns e reinicia automaticamente em caso de falha, como se seu restartPolicy fosse Always. Além disso, clusters ACS em versões mais antigas do Kubernetes (1.28 e inferiores) incluem recursos de compatibilidade para garantir a atualização correta do status do container.

  Contudo, em versões mais recentes do Kubernetes ou em outros tipos de cluster, este método sofre restrições quanto às atualizações de status. Após a falha e reinicialização de um sidecar configurado pelo método otimizado do ACS, seu containerStatus e o status do Pod não serão atualizados para Running. Para obter um status preciso, baseie-se no estado real do Pod. Recomendamos atualizar o cluster para a versão 1.29 ou posterior e usar a configuração nativa de container sidecar do Kubernetes.

Métodos de configuração de container sidecar

Exemplo

1. Crie um arquivo chamado test-sidecar.yaml e copie o conteúdo abaixo. Esse arquivo cria um Job que provisiona dois containers: app (aplicação) e sidecar.

   Configuração de container sidecar otimizada pelo ACS

   apiVersion: batch/v1
   kind: Job
   metadata:
     name: test
   spec:
     template:
       metadata:
         labels:
           app: test
       spec:
         containers:
         - name: app
           image: registry-cn-hangzhou.ack.aliyuncs.com/ack-demo/busybox:1.28
           command: ['sh', '-c', 'for i in $(seq 1 10);do echo "logging" >> /var/logs.txt; sleep 1; done']
         - name: sidecar
           image: registry-cn-hangzhou.ack.aliyuncs.com/ack-demo/busybox:1.28
           command: ['sh', '-c', 'touch /var/logs.txt && tail -F /var/logs.txt']
           env:
           - name: __IS_SIDECAR__   # Add an environment variable to the container.
             value: "true"          # Specify the container as a sidecar container.
         restartPolicy: Never
     backoffLimit: 2

   Configuração nativa de container sidecar do Kubernetes

   apiVersion: batch/v1
   kind: Job
   metadata:
     name: test
   spec:
     template:
       metadata:
         labels:
           app: test
       spec:
         initContainers:
         - name: sidecar
           image: registry-cn-hangzhou.ack.aliyuncs.com/ack-demo/busybox:1.28
           command: ['sh', '-c', 'touch /var/logs.txt && tail -F /var/logs.txt']
           restartPolicy: Always  # Specify the container as a sidecar container.
         containers:
         - name: app
           image: registry-cn-hangzhou.ack.aliyuncs.com/ack-demo/busybox:1.28
           command: ['sh', '-c', 'for i in $(seq 1 10);do echo "logging" >> /var/logs.txt; sleep 1; done']
         restartPolicy: Never
     backoffLimit: 2

2. Execute o comando a seguir para criar o Job:

   kubectl apply -f test-sidecar.yaml

3. Visualize os detalhes do Job e do pod para observar o efeito da variável de ambiente.

   • Confirme se o Job foi concluído e se seu status é Succeeded.

     kubectl describe job <job-name>

     Exemplo:

     Parallelism:    1
     Completions:    1
     Completion Mode:  NonIndexed
     Start Time:     Tue, 29 Oct 2024 11:24:18 +0800
     Completed At:   Tue, 29 Oct 2024 11:25:17 +0800
     Duration:       59s
     Pods Statuses:  0 Active (0 Ready) / 1 Succeeded / 0 Failed
     Pod Template:

4. Visualize os detalhes do container sidecar e verifique a sequência de inicialização e o código de saída real dos containers.

   kubectl describe pod <pod-name>

   • A saída abaixo mostra que o container sidecar iniciou antes do container app, garantindo que recursos dependentes, como roteamento de tráfego, estivessem prontos antecipadamente. O container sidecar foi encerrado 10 segundos após a parada do container app, permitindo o encerramento normal do pod provisionado pelo Job.

     Events:
       Type    Reason     Age    From                Message
       ----    ------     ----   ----                -------
       Normal  Scheduled  5m11s  default-scheduler   Successfully assigned default/test-729nd to virtual-kubelet-cn-shenzhen-f
       Normal  Pulling    5m13s  kubelet             Pulling image "registry-cn-hangzhou.ack.aliyuncs.com/ack-demo/busybox:1.28"
       Normal  Pulled     5m12s  kubelet             Successfully pulled image "registry-cn-hangzhou.ack.aliyuncs.com/ack-demo/busybox:1.28" in 384ms
       Normal  Created    5m12s  kubelet             Created container sidecar
       Normal  Started    5m12s  kubelet             Started container sidecar
       Normal  Pulling    5m12s  kubelet             Pulling image "registry-cn-hangzhou.ack.aliyuncs.com/ack-demo/busybox:1.28"
       Normal  Pulled     5m12s  kubelet             Successfully pulled image "registry-cn-hangzhou.ack.aliyuncs.com/ack-demo/busybox:1.28" in 342ms
       Normal  Created    5m12s  kubelet             Created container app
       Normal  Started    5m12s  kubelet             Started container app
       Normal  Killing    5m1s   kubelet             Stopping container sidecar

   • A saída abaixo indica que o container sidecar foi encerrado forçadamente com código de saída 0. Isso garante que o pod possa ser encerrado com sucesso ou falha normalmente, sem interferência do container sidecar.

     sidecar:
         Container ID:  containerd://bd85de5ad7ee1cb5a4807b094f2d41fa90881916857172 0e73ef0dfbd26f1dfb
         Image:         registry-cn-hangzhou.ack.aliyuncs.com/ack-demo/busybox:1.28
         Image ID:      registry-cn-hangzhou.ack.aliyuncs.com/ack-demo/busybox@sha256:141c253bc4c3fd0a20
         Port:          <none>
         Host Port:     <none>
         Command:
           sh
           -c
           touch /var/logs.txt && tail -F /var/logs.txt
         State:          Terminated
           Reason:       Completed
           Message:      Force this container to be success(137, Error, )
           Exit Code:    0
           Started:      Tue, 29 Oct 2024 11:24:32 +0800
           Finished:     Tue, 29 Oct 2024 11:25:13 +0800
         Ready:          False
         Restart Count:  0