Короткий ответ: Kubernetes может заменить часть платформы эксплуатации ВМ, но не гипервизорную изоляцию. Контейнеры на одном worker-узле используют общее ядро. Поэтому решение определяется моделью угроз: кто кому доверяет, что произойдёт при захвате pod или node и допустим ли запуск чужого кода. Главное различие ВМ получает гостевое ядро и отделяется гипервизором. Обычный контейнер — изолированный процесс на ядре хоста, а Kubernetes управляет размещением workloads, API, сетью и состоянием. Namespace, RBAC и NetworkPolicy полезны, но сами по себе не становятся аппаратной границей. Официальная документация Kubernetes прямо описывает контейнеры как более слабую границу изоляции, чем ВМ, и рекомендует sandbox для недоверенного кода. Корректный вопрос звучит так: какие ВМ можно заменить контейнерами, а где нужна отдельная граница? Когда контейнеров достаточно Миграция разумна, если workloads принадлежат одной зоне доверия, не исполняют пользовательский код и не требуют privileged, host namespaces, доступа к устройствам или файловой системе узла. Компрометация одного worker не должна давать неприемлемый ущерб всему сервису. Минимум: Pod Security Admission в режиме enforce с профилем Restricted; запрет root и повышения привилегий; seccomp, минимум capabilities, read-only root filesystem; отдельные ServiceAccount и минимальный RBAC; шифрование Secrets в etcd; поддерживаемые ОС, runtime и CNI. Для сети — default deny на ingress и egress, затем точечные разрешения для DNS и зависимостей. NetworkPolicy действует только при CNI с её поддержкой. Когда сохранить ВМ или sandbox Более сильная изоляция нужна для взаимно недоверяющих tenants, произвольных CI-задач и плагинов, разных уровней чувствительности данных, privileged workloads и сценария container escape через уязвимость общего ядра. Практические варианты: Kubernetes на ВМ; отдельные кластеры или node pools; VM-backed sandbox; физическое разделение. Выделенный пул узлов уменьшает совместное размещение и радиус последствий, но kubelet и control plane могут оставаться общими. Для недоверенного кода выбирайте sandbox с отдельным ядром либо отдельную инфраструктурную границу. Как принять решение P0 — классификация. Для каждого workload укажите владельца, зону доверия, допустимых соседей, чувствительность данных и последствия компрометации pod, node и control plane. Назначьте режим: контейнер, sandbox, отдельный кластер, ВМ или bare metal. P1 — проверяемые барьеры. Тестами подтвердите, что admission отклоняет опасные pod; workload не читает чужие Secrets; запрещённый межnamespace- и внешний трафик блокируется; ненужный токен ServiceAccount не монтируется; каждое исключение имеет владельца и срок. P2 — устойчивость. Фиксируйте образы по digest, ведите SBOM, проверяйте подписи и уязвимости, собирайте audit logs, отслеживайте изменения RBAC и RuntimeClass. Репетируйте восстановление etcd и данных, развёртывание чистого кластера и ротацию учётных данных после захвата узла. Вывод Kubernetes может заменить парк ВМ для доверенных приложений одной зоны ответственности и упростить эксплуатацию. Для жёсткой multi-tenancy и недоверенного кода он не заменяет гипервизор автоматически. Часто верна гибридная архитектура: Kubernetes управляет workloads, а ВМ, sandbox или отдельные кластеры дают нужную границу. Что почитать и попробовать • Kata Containers VM-backed sandbox с привычным контейнерным интерфейсом; подходит, когда pod нужна отдельная гостевая ОС. • gVisor Userspace-ядро сокращает прямое взаимодействие приложения с ядром хоста. • KubeVirt Запускает и управляет ВМ через Kubernetes API для гибридной платформы. Я в соцсетях TG TikTok Сетка Пикабу MAX