"гораздо меньше памяти и ЦП, чем в Kubernetes" - overhead на ВМ в KubeVirt не такой драматичный, как может показаться. В поде доп. ресурсы для работы ВМ резервируются в основном под процесс virt-launcher (его базовое потребление относительно низкое) и сам QEMU. Объём дополнительно резервируемых ресурсов зависит от конфигурации самой VM, и в KubeVirt это видно явно через requests/limits, в отличие от традиционной виртуализаций, где overhead для обеспечения работы ВМ не так явен.
В данном случае я хочу понять правильность применения терминологии.
Мне всегда казалось следующее:
— есть сертификат, который содержит некую информацию (информация о владельце, разрешения, алгоритмы) + открытый ключ
— есть закрытый ключ соответствующий открытому ключу, который хранится в неком отдельном контейнере.
При желании сертификат в данный контейнер можно поместить, но сам сертификат закрытый ключ содержать не должен и говорить о закрытой части сертификата мне кажется странным.
чем тогда обусловлено название «сертификат открытого ключа»?
разве в X.509 что-либо говорится о том, что сертификат состоит из «открытой и закрытой» частей?
Все можно тюнить, вот 2.5к подиков на узел
так это целевой вариант для запуска, поскольку нет смысла использовать виртуальную машину поверх вложенной виртуализации.
> С дефолтным лимитом в 250 подов
это дефолт, его же можно менять
"гораздо меньше памяти и ЦП, чем в Kubernetes" - overhead на ВМ в KubeVirt не такой драматичный, как может показаться. В поде доп. ресурсы для работы ВМ резервируются в основном под процесс virt-launcher (его базовое потребление относительно низкое) и сам QEMU. Объём дополнительно резервируемых ресурсов зависит от конфигурации самой VM, и в KubeVirt это видно явно через requests/limits, в отличие от традиционной виртуализаций, где overhead для обеспечения работы ВМ не так явен.
для ВМ, работающих под управлением Kubernetes/Kubevirt, это поведение можно контролировать: есть живая миграция которая решаем эту проблему
Да, такая возможность есть. Можно выполнить операцию Evict с force, либо в ВМ задать политику liveMigrationPolicy. Подробнее можно посмотреть в доке https://deckhouse.ru/products/virtualization-platform/documentation/user/resource-management/virtual-machines.html#механизм-autoconverge
Мотивация описана в самой статье, причем тут биланы, баяны и прочие домыслы.
Что именно в статье вас привело к таким умозаключениям?
На домашнем продакшене можно)
А на мастере ВМ можно запускать?
а можно пояснить, что есть в данном случае SCM?
Мне всегда казалось следующее:
— есть сертификат, который содержит некую информацию (информация о владельце, разрешения, алгоритмы) + открытый ключ
— есть закрытый ключ соответствующий открытому ключу, который хранится в неком отдельном контейнере.
При желании сертификат в данный контейнер можно поместить, но сам сертификат закрытый ключ содержать не должен и говорить о закрытой части сертификата мне кажется странным.
разве в X.509 что-либо говорится о том, что сертификат состоит из «открытой и закрытой» частей?