Все, что вы хотели знать, но боялись спросить про Kubernetes + KubeVirt vs. Среда виртуализации + Kubernetes

В варианте Kubernetes+KubeVirt возникает лишний слой абстракции в виде подов, которого в условном VMware просто нет. Этот слой тоже не святым духом питается, а значит, отнимает ресурсы ЦП и ОЗУ.

Ммм.. А вы не могли бы поподробнее про "слои абстракции"? Особенно на примере "обычной" виртуализации на QEMU/KVM vs Kata Containers vs KuberVirt? И кто там что "отнимает", т.е. dataplane, а не control/mgmt-plane?

на поверку быстродействие ВМ в Kubernetes оказывается сопоставимым с быстродействием ВМ в среде виртуализации

Разумеется. Просто потому что и то, и то - ВМ, которая аппаратно работает на CPU. Чем/как она управляется и оркестрируется - дело второе.

Получается, при выборе KubeVirt придется дополнительно что-то придумывать для критичных приложений, то есть выносить их за пределы среды Kubernetes. 

Эм.. В K8s давным-давно крутят реляционные СУБД в общем-то. И прочие stateful нагрузки. Что там надо придумывать - не очень понятно. Даже VMware крутит СУБД, в рамках своего DBaaS, поверх K8s. https://techdocs.broadcom.com/us/en/vmware-cis/dsm/data-services-manager/2-1/getting-started-with-vmware-data-services-manager/concepts-of-vmware-data-services-manager/architecture-and-components-of-vmware-data-services-manager.html

А вот с KubeVirt таких кейсов пока нет, причем не только у нас, но и в мире.

RedHat с вами не согласен. https://www.redhat.com/en/blog/success-story-snapshots-whos-building-openshift-virtualization Kubevirt тоже (тут есть список End Users) - https://kubevirt.io/

но пока не было крупных внедрений

Cloudflare на сотни ВМ достаточно большое внедрение? https://blog.cloudflare.com/leveraging-kubernetes-virtual-machines-with-kubevirt/ Может Goldman Sachs, Ford, Emirates на много-много тысяч ВМ? https://www.youtube.com/watch?v=vJV4inq-1CQ + https://www.dayofdubai.com/news/the-strategic-shift-how-ford-and-emirates-nbd-reduced-complexity-in-virtualization + https://www.redhat.com/en/blog/strategic-shift-how-ford-and-emirates-nbd-stopped-paying-complexity-tax-virtualization

Вместе с тем в Kubernetes нет привычного графического интерфейса,

Ну как нет... OpenShift Virtualization, Deckhouse, и прочие

Гипервизор может «потерять» связь с хостом на 50 секунд и потом спокойно его подхватить и продолжить работу как ни в чем не бывало.

Гипервизор не может потерять связь с хостом, потому что он работает на хосте. ESXi - гипервизор, vCenter - нет :)

связка Kubernetes + KubeVirt относительно молодая на рынке

Так вам не нужны компетенции по этой связке. Вам нужен человек, который просто умеет в K8s. Дальше он "он довольно быстро, в среднем даже за один день, сможет освоиться в решении другого вендора просто потому, что есть куча шаблонов, все компоненты плюс-минус похожи, да и их названия тоже"

Так вот, Kubernetes относится к контейнерам и новоприбывшим ВМ как к скоту, и в этом нет ничего оскорбительно.

для ВМ, работающих под управлением Kubernetes/Kubevirt, это поведение можно контролировать: есть живая миграция которая решаем эту проблему

"гораздо меньше памяти и ЦП, чем в Kubernetes" - overhead на ВМ в KubeVirt не такой драматичный, как может показаться. В поде доп. ресурсы для работы ВМ резервируются в основном под процесс virt-launcher (его базовое потребление относительно низкое) и сам QEMU. Объём дополнительно резервируемых ресурсов зависит от конфигурации самой VM, и в KubeVirt это видно явно через requests/limits, в отличие от традиционной виртуализаций, где overhead для обеспечения работы ВМ не так явен.

А как же вариант где KubeVirt поднимает ВМ на железных серверах, а уже в них поды с контейнерами? С дефолтным лимитом в 250 подов тяжело утилизировать железку на 256 ядер и 4тб озу, а маленькие серверы не эффективны по занимаемым юнитам...

И тут уже вопрос как проще админить кластер кубера, когда он сам управляет ВМ или когда этим занимается прослойка в виде VMware...