As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.

# Configurar ganchos do ciclo de vida do contêiner
<a name="lifecycle-hooks"></a>

Durante um desligamento normal do contêiner, seu aplicativo deve responder a um `SIGTERM` sinal iniciando o desligamento para que os clientes não tenham nenhum tempo de inatividade. Seu aplicativo deve executar procedimentos de limpeza como os seguintes:
+ Salvando dados
+ Fechando descritores de arquivo
+ Fechando conexões de banco de dados
+ Concluindo solicitações em voo com elegância
+ Saindo em tempo hábil para atender à solicitação de encerramento do pod

Defina um período de carência que seja longo o suficiente para que a limpeza termine. Para saber como responder ao `SIGTERM` sinal, consulte a documentação da linguagem de programação que você usa para seu aplicativo.

Os [ganchos do ciclo de vida do contêiner](https://kubernetes.io/docs/concepts/containers/container-lifecycle-hooks/) permitem que os contêineres estejam cientes dos eventos em seu ciclo de vida de gerenciamento. Os contêineres podem executar código implementado em um manipulador quando o gancho de ciclo de vida correspondente é executado. Os ganchos do ciclo de vida do contêiner fornecem uma solução alternativa para a natureza assíncrona do Kubernetes e da nuvem. Essa abordagem pode evitar a perda de conexões que são encaminhadas para o pod de encerramento antes do recurso de entrada e `iptables` são atualizadas para não enviar novo tráfego para o pod.

O ciclo de vida do contêiner e `EndpointSlice` fazem parte de diferentes APIs. `Endpoint` É importante orquestrar essas APIs. No entanto, quando um pod está sendo encerrado, a API Kubernetes notifica simultaneamente o kubelet (para o ciclo de vida do contêiner) e o controlador. `EndpointSlice` Para obter mais informações, incluindo um diagrama, consulte [Lidar com elegância com as solicitações do cliente no Guia de melhores](https://docs.aws.amazon.com/eks/latest/best-practices/load-balancing.html#_gracefully_handle_the_client_requests) práticas do *Amazon EKS*.

Quando `kubelet` envia `SIGTERM` para o pod, o `EndpointSlice` controlador está encerrando o `EndpointSlice` objeto. Esse encerramento notifica os servidores da API Kubernetes para notificarem cada nó a ser `kube-proxy` atualizado. `iptables` Embora essas ações ocorram ao mesmo tempo, não há dependências ou sequências entre elas. Há uma grande chance de o contêiner receber o `SIGKILL` sinal muito antes de cada nó atualizar as `iptables` regras locais. `kube-proxy` Nesse caso, os cenários possíveis incluem o seguinte:
+ Se sua solicitação cancelar imediatamente e sem rodeios as solicitações e conexões em voo após o recebimento`SIGTERM`, os clientes verão erros. `500`
+ Se seu aplicativo garantir que todas as solicitações e conexões em andamento sejam processadas completamente após o recebimento`SIGTERM`, durante o período de carência, as novas solicitações do cliente ainda serão enviadas ao contêiner do aplicativo, pois `iptables` as regras talvez ainda não tenham sido atualizadas. Até que o procedimento de limpeza feche o soquete do servidor no contêiner, essas novas solicitações resultarão em novas conexões. Quando o período de carência termina, as novas conexões estabelecidas após o `SIGTERM` envio são descartadas incondicionalmente.

Para abordar os cenários anteriores, você pode implementar a integração no aplicativo ou o gancho do PreStop ciclo de vida. Para obter mais informações, incluindo um diagrama, consulte [Encerrar aplicativos normalmente no Guia de melhores práticas do *Amazon* EKS](https://docs.aws.amazon.com/eks/latest/best-practices/load-balancing.html#_gracefully_shutdown_applications).

**nota**  
Independentemente de o aplicativo ser encerrado normalmente ou do resultado de um problema, os contêineres do `preStop` aplicativo acabam sendo encerrados no final do período de carência. `SIGKILL`

Use o `preStop` gancho com um `sleep` comando para atrasar o envio`SIGTERM`. Isso ajudará a continuar aceitando as novas conexões enquanto o objeto de entrada as encaminha para o pod. Teste o valor temporal do `sleep` comando para garantir que qualquer latência do Kubernetes e de outras dependências do aplicativo seja levada em consideração, conforme mostrado no exemplo a seguir:

```
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx
spec:
  containers:
    - name: nginx
      lifecycle:
        # This "sleep" preStop hook delays the Pod shutdown until
        # after the Ingress Controller removes the matching Endpoint or EndpointSlice
        preStop:
          exec:
            command:
              - /bin/sleep
              - "20"
              # This period should be turned to Ingress/Service Mesh update latency
```

*Para obter mais informações, consulte [Container hooks](https://kubernetes.io/docs/concepts/containers/container-lifecycle-hooks/#container-hooks) na documentação do Kubernetes e [desligar aplicativos normalmente no Amazon EKS Best Practices](https://docs.aws.amazon.com/eks/latest/best-practices/load-balancing.html#_gracefully_shutdown_applications) Guide.*