Какие есть два вида admission-вебхуков в Kubernetes?

В Kubernetes Admission Webhooks — это механизм расширения контроля над объектами API. Существует два основных типа, которые я использовал для обеспечения compliance и автоматизации в кластерах:

1. Validating Admission Webhook:

   • Назначение: Проверяет, соответствует ли запрос на создание/изменение объекта определённым политикам. Не может изменять объект.
   • Мой опыт использования: Я настраивал такие вебхуки для enforcement политик безопасности. Например, вебхук, который отвергает создание Pod'а, если:
     • Не установлены обязательные метки (например, app и env).
     • Контейнер запускается от имени root (securityContext.runAsNonRoot: false).
     • Не указаны лимиты ресурсов (requests/limits).
   • Пример фрагмента конфигурации:

     
     apiVersion: admissionregistration.k8s.io/v1
     kind: ValidatingWebhookConfiguration
     webhooks:

   • name: "pod-policy.example.com" rules:
     • apiGroups: [""] apiVersions: ["v1"] operations: ["CREATE", "UPDATE"] resources: ["pods"] clientConfig: service: name: "policy-webhook-svc" namespace: "kube-system" path: "/validate-pod"

2. Mutating Admission Webhook:

   • Назначение: Может изменять (мутировать) объект перед его сохранением. Выполняется до Validating Webhook.
   • Мой опыт использования: Я применял их для автоматической инъекции sidecar-контейнеров (например, прокси-сервис-меш), добавления стандартных толерансов (tolerations) для работы с tainted-нодами или для автоматической подстановки секретов из внешнего хранилища (например, Vault) в виде переменных окружения.
   • Пример сценария: Автоматическое добавление sidecar-контейнера для логирования во все Pod'ы в определённом namespace.

Критически важный момент в продакшене: Вебхуки должны быть высокодоступными и быстрыми, иначе они могут заблокировать критичные операции в кластере. Мы всегда разворачивали их с несколькими репликами и настраивали timeoutSeconds и failurePolicy (часто на Ignore, чтобы сбой вебхука не ломал весь кластер).