Расскажи про admission controllers: что такое ValidatingAdmissionWebhook и MutatingAdmissionWebhook, и какую роль играют OPA/Gatekeeper или Kyverno?

Как работает

API server вызывает admission controllers в цепочке. Mutating webhooks идут до validating, потому что валидация должна видеть финальный объект после defaults и injections. Webhook получает AdmissionReview и возвращает allowed/denied, JSON patch или message.

failurePolicy определяет поведение при недоступном webhook: Fail безопаснее (отклонить запрос), но может остановить операции в кластере при падении policy service; Ignore повышает availability, но ослабляет политику. Gatekeeper использует OPA/Rego и ConstraintTemplate, Kyverno описывает политики в YAML, близком к Kubernetes-манифестам, и поддерживает validate, mutate, generate и verify images.

apiVersion: admissionregistration.k8s.io/v1
kind: ValidatingWebhookConfiguration
metadata:
  name: require-labels
webhooks:
  - name: labels.example.com
    rules:
      - apiGroups: ["apps"]
        apiVersions: ["v1"]
        operations: ["CREATE", "UPDATE"]
        resources: ["deployments"]
    clientConfig:
      service:
        namespace: policy
        name: labels-webhook
        path: /validate
    admissionReviewVersions: ["v1"]
    sideEffects: None
    failurePolicy: Fail
    timeoutSeconds: 5

Admission Controllers: MutatingAdmissionWebhook и ValidatingAdmissionWebhook

Admission control — последний рубеж перед сохранением объекта в etcd. Запрос уже прошёл authentication и authorization, но объект ещё можно изменить или отклонить. MutatingAdmissionWebhook изменяет объект: добавляет sidecar, labels, defaults. ValidatingAdmissionWebhook проверяет и запрещает: например, нельзя privileged Pod или latest image. OPA/Gatekeeper и Kyverno дают policy engine поверх этой модели.

OPA/Gatekeeper vs Kyverno

Gatekeeper требует изучения языка Rego, зато даёт мощные policy-as-code возможности с audit и violations в status ресурса. Kyverno ближе к Kubernetes-YAML и быстрее стартует для команд без опыта Rego. Оба поддерживают audit mode — включайте его перед enforcement, чтобы увидеть нарушения без блокировки.

Подводные камни

• Поставить failurePolicy: Fail на webhook без HA (одна реплика) — при падении policy service все apply в кластере начнут завершаться ошибкой.
• Делать mutation, о которой пользователи не знают. Это усложняет diff и debugging: kubectl apply возвращает одно, а кластер хранит другое.
• Писать политики без audit/exception процесса. Платформа превращается в блокер для команд, если нет способа получить временное исключение.
• Не выставлять timeoutSeconds явно. Дефолт 10 с, но при медленном webhook это добавляет latency к каждому API-запросу в данном scope.
• Забывать про namespaceSelector. Webhook без селектора применяется ко всем namespace включая kube-system, что может сломать системные компоненты.
• Не тестировать webhook на admission review примерах. Ошибка в логике может отклонить валидные объекты и заблокировать деплой в production.

• Путать admission с RBAC
• Не различать mutate и validate
• Не учитывать failurePolicy

• Понимает место admission chain
• Знает webhook risks
• Может сравнить Gatekeeper и Kyverno