За счет каких факторов достигается завершение подов с определенной скоростью и по заданным тайм-менеджментам?

Завершение подов в Kubernetes регулируется следующими факторами:

• ** terminationGracePeriodSeconds:** Определяет время, которое дается приложениям в поде на корректное завершение (обработка текущих запросов, сброс соединений и т.д.) после получения сигнала SIGTERM. Если приложение не завершается за это время, посылается SIGKILL.

apiVersion: v1
kind: Pod
metadata:
  name: my-pod
spec:
  containers:
  - name: app
    image: my-image
  terminationGracePeriodSeconds: 30 # Значение по умолчанию - 30 секунд

• ** preStop Hook:** Позволяет выполнить определенные действия перед посылкой SIGTERM. Это может быть, например, остановка приема новых соединений.

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"] # Пример: корректное завершение Nginx

• ** readiness и liveness пробы:** Определяют состояние готовности и "жизни" пода. Если поды перестают быть "живыми" (livenessProbe падает) или "готовыми" (readinessProbe падает, и контроллер видит, что под больше не нужен), они могут быть завершены.

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

• ** Desired State:** Контроллеры Kubernetes (например, Deployment, ReplicaSet) стремятся поддерживать заданное количество реплик. При изменении Desired State (уменьшение количества реплик) или обновлении, поды, которые больше не нужны, начинают завершаться. Скорость этого процесса зависит от стратегии обновления (например, RollingUpdate) и параметров maxUnavailable.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-deployment
spec:
  replicas: 3
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 1 # Определяет, сколько подов могут быть недоступны во время обновления
      maxSurge: 1

• ** Node Drain:** При переводе узла в режим обслуживания (kubectl drain) Kubernetes завершает поды на этом узле. Скорость также зависит от terminationGracePeriodSeconds и настройки —ignore-daemonsets.

• ** Приложение, реагирующее на SIGTERM:** Само приложение внутри пода должно корректно обрабатывать сигнал SIGTERM и успевать завершить свою работу в рамкахterminationGracePeriodSeconds.