Автор: Дмитрий Евдокимов · VK Cloud
Дмитрий Евдокимов — CTO Luntry, платформы безопасности для Kubernetes. Luntry строится поверх Kubernetes API, поэтому понимание KRM у него не теоретическое — это основа продукта. Доклад с VK Kubernetes Conference.
Kubernetes Resource Model — это абстракция, которую легко пропустить за привычными деплойментами и сервисами. Суть в том, что Kubernetes — это не оркестратор контейнеров, а universal control plane для управления любыми ресурсами. Всё, что можно описать как «желаемое состояние + текущее состояние + reconciler», может стать Kubernetes-ресурсом. Это означает, что KRM применима не только к подам, но и к облачным ресурсам, сетевым политикам, конфигурациям безопасности и вообще к любому объекту с жизненным циклом. Everything-as-Code здесь не лозунг, а архитектурное следствие: если ресурс существует в Kubernetes API, он автоматически версионируем, аудируем, управляем через GitOps.
Евдокимов объясняет, как устроены CRD (Custom Resource Definitions), как писать операторы, и почему правильно понятый KRM убирает необходимость в отдельных инструментах управления конфигурацией для многих сценариев.
Кому смотреть: platform engineering командам и SRE, которые уже используют Kubernetes и думают о расширении его за пределы стандартных ресурсов — управление инфраструктурой, политиками, секретами через единый API.
Из этого можно взять в работу: посмотри, какие операции ты делаешь через скрипты или сторонние инструменты, которые по сути управляют состоянием системы. Можно ли выразить это как Kubernetes-ресурс с оператором? Если да — ты получаешь GitOps, аудит и версионирование бесплатно.
KRM строится на трёх принципах. Declarative: ты описываешь желаемое состояние, а не последовательность команд. Level-triggered (не event-triggered): reconciler периодически сверяет желаемое с текущим и исправляет расхождение, независимо от того, было ли событие — это делает систему устойчивой к частичным сбоям. Shared API: все ресурсы доступны через одинаковый REST API с одинаковой семантикой (CRUD + watch).
CRD (Custom Resource Definition) позволяет добавить собственные типы ресурсов в Kubernetes API. После регистрации CRD ты можешь создавать объекты этого типа через kubectl apply, получать их через kubectl get, настраивать RBAC — всё это бесплатно из коробки. Оператор — контроллер, который следит за CRD и реализует reconciler: приводит реальное состояние к желаемому.
Евдокимов разбирает паттерн «Kubernetes as a platform for platforms»: компании строят внутренние платформы разработки поверх Kubernetes API вместо того, чтобы изобретать собственные control plane. Пример — Crossplane: управление облачными ресурсами (S3, RDS, VPC) через Kubernetes Custom Resources. Инфраструктура описывается в YAML, хранится в Git, применяется через стандартный GitOps pipeline.
Безопасность в этой модели тоже ресурс. Luntry реализует политики безопасности как Kubernetes CRD: политика создана — reconciler применяет её к кластеру. Изменена — reconciler обновляет. Удалена — откатывается. Это устраняет дрейф конфигурации, который неизбежен при ручном управлении.