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 o endpoint EndpointSlice fazem parte de algo diferente. APIs É importante orquestrá-los. 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 nos Guias de Melhores Práticas do 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 seu aplicativo cancelar imediatamente e sem rodeios as solicitações e conexões em voo após o recebimento SIGTERM, dos clientes, verá 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 nos Guias de Melhores Práticas do EKS.

Nota: Independentemente de o aplicativo ser encerrado normalmente ou do resultado de um preStop gancho, os contêineres do 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 e EKS Best Practices — Load Balancing (desligar aplicativos normalmente).