Комментарии 4
В статье ряд неточностей:
1) Флаг--enable-admission-plugins=NodeRestriction никакого отношения к Validating Admission Policy не имеет.
2) Версия API admissionregistration.k8s.io/v1alpha1 уже очень сильно устарела. В документации написано использовать как минимум admissionregistration.k8s.io/v1beta1 , но на самом деле начиная с 1.22 по дефолту используется admissionregistration.k8s.io/v1 .
3) "повысить доступность веб-хуков, задеплоив несколько инстансов webhook server в некий отдельный webhook-namespace". О каких вебхуках вообще идет речь? Validating Admission Policy - это фича самого аписервера, вебхуки тут не используются.
По самой статье - нужно больше примеров, хотя бы даже из документации.
По самой фиче - интересная и полезная штука, но мы используем Kyverno. Гораздо более мощный функционал и огромное количество готовых политик.
Благодарю за дельные комментарии. Вы правы, альфа началась с 1.26, и в офиц.доке упоминается бета. Думается мне, благодаря успеху Kyverno и похожих проектов разработчики куба не стали делать обширных комплексных фичей в этом направлении, дабы не конкурировать напрямую с теми, кто немного опережает и, тем самым, варианты решений и развития показывает. Дождёмся очередного релиза, любопытно, какие из них добавят в куб через год.
Офиц.документация с примерами CEL-выражений является очень подробной, а посему мне хотелось раскрыть саму суть фичи, предложив всего 2-3 годных примера, дабы оценить лёгкость в её использовании. Статья с плотным наборов готовых решений, мне кажется, будет походить на приличный воркшоп или гайд с переводом на русский, чего не хотелось бы. Ну, по-крайней мере, не в этот раз.
enable NodeRestriction не имеет отношения. Это я всего лишь хотел показать, что validating admission policy такой же адмишен плагин, как и остальные, которые включены по дефолту в списке enable-admission-plugins. Правда, чтобы он заработал, необходимы остальные 2 опции.
Вебхук-сервер это уже некий взгляд вперёд, к чему можно прийти по части адмишен-плагинов. Накопление множества различных validating admission policy, рано или поздно, приведёт или к переезду на Kyverno , или к созданию собственных адмишен-плагинов, и это, с большой вероятностью, скажется на скорости работы кластера. В доке я нашёл только общие рекомендации о том, как создать собственный сервер для вебхуков и вынести туда Mutating, Validating: kubernetes.io / docs / Reference / API Access Control / Dynamic Admission Control. По этой части я встречал материалы с примерами, кто-то занимается целыми командами, анализирует и масштабирует самописные инстансы
А почему в хабах Rust?
Validating Admission Policy: Магия кастомных политик безопасности Kubernetes