Всё держится на одной идее - адрес не принадлежит поду.
В ванильном KubeVirt с masquerade у ВМ внутри свой адрес, а наружу она ходит через NAT пода. Под пересоздался, адрес сменился, соединения оборваны. Можно уйти на bridge, но тогда апстрим сам вешает LiveMigratable=False, и переезжать уже некуда.
Мы сделали по другому: бриджей в поде нет, вместо них свой network binding на eBPF, MAC прописан в конфигурации самой ВМ, поэтому едет вместе с ней, а IP-адрес лежит в отдельном объекте VirtualMachineIPAddress . Т.е. под ВМ поднимается не с первым свободным адресом из пула, а с тем, что закреплён за машиной.
В части миграции - во время неё оба пода живут одновременно и адрес у них один. Кто из них "настоящий", решается так: под на целевом узле создаётся с пометкой "трафик сюда не отдавать" пока идет миграция, пометка снимается в момент swtichover.
В доп. сетях по аналогии, но уже без Cilium. MAC живёт в ресурсе VirtualMachineMACAddress, а адрес выдаёт IPAM модуля SDN, статикой или автоматом. Конфигурация интерфейсов едет в под ВМ вместе с ним, поэтому на целевом узле те же MAC и адреса. Дальше отрабатывает обычная L2-механика через GARP.
Сама по себе бумажка от атак не спасает - это правда. Но смысл не в бумажке. Мы и так делаем то, что в итоге проверяют при сертификации: distroless-образы, чтобы меньше поверхность атаки, отслеживаем CVE и быстро их закрываем, процесс разработки выстроен по-взрослому. Сертификация просто заставляет это всё зафиксировать и показать внешним людям - мол, вот, проверяйте. Продукт от этого не становится безопаснее в день получения сертификата, он такой и был.
"гораздо меньше памяти и ЦП, чем в Kubernetes" - overhead на ВМ в KubeVirt не такой драматичный, как может показаться. В поде доп. ресурсы для работы ВМ резервируются в основном под процесс virt-launcher (его базовое потребление относительно низкое) и сам QEMU. Объём дополнительно резервируемых ресурсов зависит от конфигурации самой VM, и в KubeVirt это видно явно через requests/limits, в отличие от традиционной виртуализаций, где overhead для обеспечения работы ВМ не так явен.
В данном случае я хочу понять правильность применения терминологии.
Мне всегда казалось следующее:
— есть сертификат, который содержит некую информацию (информация о владельце, разрешения, алгоритмы) + открытый ключ
— есть закрытый ключ соответствующий открытому ключу, который хранится в неком отдельном контейнере.
При желании сертификат в данный контейнер можно поместить, но сам сертификат закрытый ключ содержать не должен и говорить о закрытой части сертификата мне кажется странным.
чем тогда обусловлено название «сертификат открытого ключа»?
разве в X.509 что-либо говорится о том, что сертификат состоит из «открытой и закрытой» частей?
Всё держится на одной идее - адрес не принадлежит поду.
В ванильном KubeVirt с masquerade у ВМ внутри свой адрес, а наружу она ходит через NAT пода. Под пересоздался, адрес сменился, соединения оборваны. Можно уйти на bridge, но тогда апстрим сам вешает LiveMigratable=False, и переезжать уже некуда.
Мы сделали по другому: бриджей в поде нет, вместо них свой network binding на eBPF, MAC прописан в конфигурации самой ВМ, поэтому едет вместе с ней, а IP-адрес лежит в отдельном объекте VirtualMachineIPAddress . Т.е. под ВМ поднимается не с первым свободным адресом из пула, а с тем, что закреплён за машиной.
В части миграции - во время неё оба пода живут одновременно и адрес у них один. Кто из них "настоящий", решается так: под на целевом узле создаётся с пометкой "трафик сюда не отдавать" пока идет миграция, пометка снимается в момент swtichover.
В доп. сетях по аналогии, но уже без Cilium. MAC живёт в ресурсе VirtualMachineMACAddress, а адрес выдаёт IPAM модуля SDN, статикой или автоматом. Конфигурация интерфейсов едет в под ВМ вместе с ним, поэтому на целевом узле те же MAC и адреса. Дальше отрабатывает обычная L2-механика через GARP.
Сама по себе бумажка от атак не спасает - это правда. Но смысл не в бумажке. Мы и так делаем то, что в итоге проверяют при сертификации: distroless-образы, чтобы меньше поверхность атаки, отслеживаем CVE и быстро их закрываем, процесс разработки выстроен по-взрослому. Сертификация просто заставляет это всё зафиксировать и показать внешним людям - мол, вот, проверяйте. Продукт от этого не становится безопаснее в день получения сертификата, он такой и был.
Все можно тюнить, вот 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 что-либо говорится о том, что сертификат состоит из «открытой и закрытой» частей?