Вытеснение, инициированное через API
Вытеснение, инициированное через API — процесс, при котором с помощью Eviction API
создается объект Eviction
, который запускает корректное завершение работы Pod'а.
Вытеснение можно инициировать напрямую с помощью Eviction API или программно,
используя клиент API-сервера
(например, командой kubectl drain
). В результате будет создан объект Eviction
,
который запустит процесс контролируемого завершения работы Pod'а.
Вытеснения, инициированные через API, учитывают настройки PodDisruptionBudget
и terminationGracePeriodSeconds
.
Создание с помощью API объекта Eviction для Pod'а аналогично выполнению
операции DELETE
для этого Pod'а, которая контролируется политикой.
Вызов API Eviction
Для доступа к API Kubernetes и создания объекта Eviction
можно воспользоваться клиентской библиотекой. Необходимая операция оформляется в виде POST-запроса (см. пример ниже):
policy/v1
доступно начиная с v1.22. Для более ранних релизов используйте policy/v1beta1
.{
"apiVersion": "policy/v1",
"kind": "Eviction",
"metadata": {
"name": "quux",
"namespace": "default"
}
}
policy/v1
.{
"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'а выглядит следующим образом:
- К ресурсу
Pod
на сервере API добавляется метка времени удаления, после чего сервер API считает ресурс Pod завершенным (terminated). РесурсPod
также помечается настроенным grace-периодом. - kubelet на узле, где запущен
локальный Pod, замечает, что ресурс
Pod
помечен на удаление, и приступает к корректному завершению работы локального Pod'а. - Пока kubelet завершает работу Pod'а, управляющий слой удаляет Pod из объектов Endpoint и EndpointSlice. В результате контроллеры больше не рассматривают Pod как валидный объект.
- После истечения периода корректного завершения работы (grace-периода) kubelet принудительно завершает работу локального Pod'а.
- kubelet передает API-серверу информацию о необходимости удалить ресурс
Pod
. - Сервер API удаляет ресурс
Pod
.
Зависшие вытеснения
В некоторых ситуациях сбой приводит к тому, что API Eviction начинает возвращать
исключительно ответы 429
или 500
. Такое может случиться, если, например,
за создание Pod'ов для приложения отвечает ReplicaSet, однако новые Pod'ы не
переходят в состояние Ready
. Подобное поведение также может наблюдаться в случаях,
когда у последнего вытесненного Pod'а слишком долгий период завершения работы (grace-период).
Одно из следующих решений может помочь решить проблему:
- Прервите или приостановите автоматическую операцию, вызвавшую сбой. Перед повторным запуском операции внимательно изучите сбойное приложение.
- Подождите некоторое время, затем напрямую удалите Pod из управляющего слоя кластера вместо того, чтобы пытаться удалить его с помощью Eviction API.
Что дальше
- Обеспечение работоспособности приложений с помощью Pod Disruption Budget.
- Вытеснение из-за дефицита ресурсов на узле.
- Приоритет Pod'а и приоритизация.