View a markdown version of this page

Configurar ganchos do ciclo de vida do contêiner - AWS Orientação prescritiva

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

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 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 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 recebimentoSIGTERM, 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 recebimentoSIGTERM, 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.

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 envioSIGTERM. 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 na documentação do Kubernetes e desligar aplicativos normalmente no Amazon EKS Best Practices Guide.