Вытеснение, инициированное через API

Вытеснение, инициированное через API, — процесс, при котором с помощью Eviction API создается объект Eviction, который запускает корректное завершение работы пода.

Вытеснение можно инициировать напрямую с помощью Eviction API или программно, используя клиент API-сервера (например, командой kubectl drain). В результате будет создан объект Eviction, который запустит процесс контролируемого завершения работы Pod'а.

Вытеснения, инициированные через API, учитывают настройки PodDisruptionBudget и terminationGracePeriodSeconds.

Создание с помощью API объекта Eviction для Pod'а аналогично выполнению операции DELETE для этого Pod'а, которая контролируется политикой.

Вызов API Eviction

Для доступа к API Kubernetes и создания объекта Eviction можно воспользоваться клиентской библиотекой. Необходимая операция оформляется в виде POST-запроса (см. пример ниже):

• policy/v1
• policy/v1beta1

{
  "apiVersion": "policy/v1",
  "kind": "Eviction",
  "metadata": {
    "name": "quux",
    "namespace": "default"
  }
}

{
  "apiVersion": "policy/v1beta1",
  "kind": "Eviction",
  "metadata": {
    "name": "quux",
    "namespace": "default"
  }
}

Также можно попытаться выполнить операцию вытеснения, обратившись к API с помощью curl или wget, как показано в следующем примере:

curl -v -H 'Content-type: application/json' https://your-cluster-api-endpoint.example/api/v1/namespaces/default/pods/quux/eviction -d @eviction.json

Как работает вытеснение, инициированное через API

При вытеснении, инициированном через API, сервер API выполняет admission-проверки и отвечает одним из следующих способов:

• 200 OK: вытеснение разрешено, подресурс Eviction создан, Pod удален (аналогично отправке запроса DELETE на URL Pod'а).
• 429 Too Many Requests: вытеснение в данный момент не разрешено из-за настроек PodDisruptionBudget. Попытку вытеснения можно повторить позже. Такой ответ также может быть вызван работой механизма по ограничению частоты запросов к API.
• 500 Internal Server Error: вытесение запрещено из-за неправильной конфигурации; например, несколько PodDisruptionBudget'ов могут ссылаться на один и тот же Pod.

Если Pod, предназначенный для вытеснения, не является частью рабочей нагрузки с настроенным PodDisruptionBudget'ом, сервер API всегда возвращает 200 OK и разрешает вытеснение.

В случае, если вытеснение разрешено, процесс удаления Pod'а выглядит следующим образом:

1. К ресурсу Pod на сервере API добавляется метка времени удаления, после чего сервер API считает ресурс Pod завершенным (terminated). Ресурс Pod также помечается настроенным grace-периодом.
2. kubelet на узле, где запущен локальный Pod, замечает, что ресурс Pod помечен на удаление, и приступает к корректному завершению работы локального Pod'а.
3. Пока kubelet завершает работу Pod'а, управляющий слой удаляет Pod из объектов Endpoint и EndpointSlice. В результате контроллеры больше не рассматривают Pod как валидный объект.
4. После истечения периода корректного завершения работы (grace-периода) kubelet принудительно завершает работу локального Pod'а.
5. kubelet передает API-серверу информацию о необходимости удалить ресурс Pod.
6. Сервер API удаляет ресурс Pod.

Зависшие вытеснения

В некоторых ситуациях сбой приводит к тому, что API Eviction начинает возвращать исключительно ответы 429 или 500. Такое может случиться, если, например, за создание Pod'ов для приложения отвечает ReplicaSet, однако новые Pod'ы не переходят в состояние Ready. Подобное поведение также может наблюдаться в случаях, когда у последнего вытесненного Pod'а слишком долгий период завершения работы (grace-период).

Одно из следующих решений может помочь решить проблему:

• Прервите или приостановите автоматическую операцию, вызвавшую сбой. Перед повторным запуском операции внимательно изучите сбойное приложение.
• Подождите некоторое время, затем напрямую удалите Pod из управляющего слоя кластера вместо того, чтобы пытаться удалить его с помощью Eviction API.

Что дальше

• Обеспечение работоспособности приложений с помощью Pod Disruption Budget.
• Вытеснение из-за дефицита ресурсов на узле.
• Приоритет Pod'а и приоритизация.