Admission Controllers

Стражи порядка в Kubernetes

Admission Controllers — это специальные плагины, которые перехватывают запросы к API-серверу Kubernetes. Они вступают в игру сразу после того, как пользователь прошел аутентификацию и проверку прав (RBAC), но до того, как объект будет записан в базу данных кластера (etcd).

Как это работает (Схема процесса)

Любой запрос на создание или изменение ресурса (например, kubectl apply) проходит через строгую цепочку проверок:

 [ Запрос ] -> [ Аутентификация ] -> [ Авторизация ]
                                          |
        +---------------------------------+
        |
        v
 [ Mutating Admission ]  -->  Модифицирует объект (добавляет поля/метки)
        |
        v
 [ Object Validation ]   -->  Проверяет структуру YAML
        |
        v
 [ Validating Admission ] -->  Одобряет или отклоняет запрос (финальный фильтр)
        |
        v
 [ Запись в etcd ]       -->  Объект создан/изменен

Примеры встроенных контроллеров

Эти контроллеры поставляются «из коробки» и следят за базовой гигиеной и лимитами внутри кластера.

1. InitialResources (Mutating)

Устанавливает лимиты по умолчанию для ресурсов контейнера.
Он анализирует историю потребления ресурсов аналогичными контейнерами и, если разработчик не указал лимиты сам, проставляет их автоматически. Это спасает ноды от внезапного переполнения памяти «прожорливым» процессом.

2. LimitRanger (Mutating/Validating)

Устанавливает значения по умолчанию для запросов (requests) и лимитов (limits).
Работает на уровне Namespace. Если в манифесте пода пусто в разделе ресурсов, LimitRanger подставит стандартные значения из конфига пространства имен. Также он проверяет, чтобы поды не запрашивали ресурсов больше, чем разрешено правилами.

3. ResourceQuota (Validating)

Считает количество объектов и общие потребляемые ресурсы в Namespace.
Это «бухгалтер» кластера. Он следит, чтобы суммарное количество подов или объем памяти в неймспейсе не превысил установленную квоту. Если лимит исчерпан — контроллер отклонит создание нового ресурса.

Dynamic Admission Control: Webhooks

Иногда встроенных правил недостаточно. Для реализации кастомных политик безопасности (например, «запретить запуск образов из Docker Hub») используются Admission Webhooks. Это внешние HTTP-сервисы, которые вы вызываете в процессе обработки запроса.

MutatingAdmissionWebhook

Модифицирует запрос.
Вызывается первым. Он может изменять входящий объект «на лету».
Пример: Автоматическое добавление Sidecar-контейнера (например, Istio proxy) во все поды в определенном неймспейсе.

ValidatingAdmissionWebhook - Валидирует запрос.

Вызывается вторым, когда объект уже окончательно сформирован (в том числе после всех модификаций).
Проверка подписи образа или наличия обязательных меток (labels). Если проверка не пройдена, вебхук возвращает ошибку, и пользователь видит отказ в создании ресурса.

Итог

Admission Control in Kubernetes

This page provides an overview of admission controllers. An admission controller is a piece of code that intercepts requests to the Kubernetes API server prior to persistence of the resource, but after the request is authenticated and authorized. Several important features of Kubernetes require an admission controller to be enabled in order to properly support the feature. As a result, a Kubernetes API server that is not properly configured with the right set of admission controllers is an incomplete server that will not support all the features you expect.

Kubernetes