Por que fatores é alcançada a conclusão de pods a uma…

A finalização dos pods no Kubernetes é regulada pelos seguintes fatores:

terminationGracePeriodSeconds: Define o tempo que é dado às aplicações num pod para terminar corretamente (processar pedidos atuais, fechar conexões, etc.) após receber o sinal SIGTERM. Se a aplicação não terminar nesse tempo, é enviado um SIGKILL.

apiVersion: v1
kind: Pod
metadata:
  name: my-pod
spec:
  containers:
  - name: app
    image: my-image
  terminationGracePeriodSeconds: 30 # Valor padrão - 30 segundos

PreStop Hook: Permite realizar ações específicas antes de enviar SIGTERM. Por exemplo, parar de aceitar novas conexões.

apiVersion: v1
kind: Pod
metadata:
  name: my-pod
spec:
  containers:
  - name: app
    image: my-image
    lifecycle:
      preStop:
        exec:
          command: ["/bin/sh", "-c", "nginx -s quit"] # Exemplo: encerramento correto do Nginx

Testes de readiness e liveness: Determinam o estado de prontidão e "vida" do pod. Se os pods deixam de estar "vivos" (livenessProbe falha) ou "prontos" (readinessProbe falha e o controlador vê que o pod já não é necessário), podem ser terminados.

apiVersion: v1
kind: Pod
metadata:
  name: my-pod
spec:
  containers:
  - name: app
    image: my-image
    readinessProbe:
      httpGet:
        path: /ready
        port: 8080
      initialDelaySeconds: 5
      periodSeconds: 3
    livenessProbe:
      httpGet:
        path: /live
        port: 8080
      initialDelaySeconds: 15
      periodSeconds: 5

Estado Desejado: Os controladores do Kubernetes (por exemplo, Deployment, ReplicaSet) tentam manter o número desejado de réplicas. Quando há uma alteração no Estado Desejado (redução do número de réplicas) ou durante uma atualização, os pods que já não são necessários começam a terminar. A velocidade deste processo depende da estratégia de atualização (por exemplo, RollingUpdate) e dos parâmetros maxUnavailable.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-deployment
spec:
  replicas: 3
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 1 # Define quantos pods podem estar indisponíveis durante a atualização
      maxSurge: 1

Drenagem do Nó: Quando um nó é colocado em modo de manutenção (kubectl drain), o Kubernetes termina os pods nesse nó. A velocidade também depende de terminationGracePeriodSeconds e da configuração —ignore-daemonsets.
Aplicação que responde a SIGTERM: A própria aplicação dentro do pod deve lidar corretamente com o sinal SIGTERM e ter tempo para terminar seu trabalho dentro do terminationGracePeriodSeconds.

Fator	Impacto na finalização
`terminationGracePeriodSeconds`	Tempo para uma finalização correta após `SIGTERM`
`preStop Hook`	Ações antes de `SIGTERM`
Testes de readiness/liveness	Disparadores para iniciar o processo de finalização
Estado Desejado / Estratégia	Quantidade e velocidade de finalização ao alterar réplicas/atualizações
Drenagem do Nó	Finalização de todos os pods no nó para manutenção
Tratamento de `SIGTERM` na aplicação	Capacidade da aplicação de terminar por si própria

Por que fatores é alcançada a conclusão de pods a uma velocidade determinada e de acordo com os gerenciamentos de tempo estabelecidos?