> А можете также подробно рассказать про openshift/okd/kubernetes ?Попробую, только я не девопс, а инфраструктурщик. Я мало что в этом понимаю...
> Там теперь можно и виртуалки запускать и контейнеры одновременно.
А это, друг мой, прямое следствие фразы, которую я писал выше: "oVirt без OpenStack в проде это действительно редкость". Из-за того что oVirt-образные решения используют IBM/Red Hat и Oracle для организации своих облаков и для предоставления ПО для гибридных облаков уже как вендоры on-prem OpenStack им очень интересно брать низкоуровневые ключевые модули опенстека и сопровождать их в рамках своей открытой инфраструктуры виртуализации.
Из oVirt появляется RHEV и OEV поверх которых чаще всего ставится OpenStack, который в свою очередь собирают также в платные продукты/пакеты и сопровождается теми же вендорами. Напрашивается закономерный вопрос. Зачем делать работу по 2 раза? Можно просто взять важнейшие компоненты опенстека и сразу их засунуть в инфраструктуру виртуализации, а не делать одну и ту же работу по 2 раза, по 2 раза.
Одной из важнейших задач OpenStack является k8saas - предоставление кластеров кубернетис как сервисов. Но не в виртуалки же, простите, пихать эти контейнеры. Отсюда следует, что поддержка контейнеров разного типа должна присутствовать на стороне инфраструктуры виртуализации.
Вот есть гипервизор и вот есть OpenStack Nova, которая предоставляет REST API для гипервизоров. Задача привязать nova к вашему KVM и, вуаля (nova сама по себе может быть привязана к любому гипервизору, хоть hyper-v). Тут всё понятно. Но вот когда дело доходит до сети, нельзя просто так взять и привязать OpenStack Neutron API к инфраструктуре виртуализации, нужно сначала поменять драйверы виртуальных коммутаторов с LVS на OVS. А исторически, они разрабатывались совместно с Neutron как альтернатива VMware NSX (старых версий до перехода на протокол geneva) и, соответственно, добавляя Neutron, мы добавляем OVS и поддержку программно-определяемых сетей. По такой же логике появляется поддержка контейнеров. Они ведь уже есть LXC/LXD/Docker и прочее. Им-то в конечном итоге нужно предоставить OpenStack Magnum API, которое в сочетанием с API оркестратора (Openstack Heat) и позволит автоматом деплоить кубернетис внутри проекта (теннанта). Отсюда и желание сделать так, чтобы всё уже было готово по-максимуму внутри инфраструктуры виртуализации, а установка Openstack сводилась к запуску плейбуков ансибла... точнее OpenStack Kolla.
Суть в том что все контейнерные компоненты не просто открыты, они еще и стандартизируются облачным консорциумом (забыл как он называется, сами погуглите), который занимается стандартизацией и самого опенстека и кубернетиса тоже. oVirt, как я и писал выше, вообще не имеет клиента в малом бизнесе. Сейчас он сводится к тому, что если вы клиент и покупаете RHEV (c лицензией на пару сокетов проца, а даже не по ядрам) вы получаете RHEL, на который всё установлено и вот эту самую инфраструктуру виртуализации (oVirt) в её минимальной комплектации + техсаппорт за который оплата по подписке. А OpenStack у них - это расширенный пакет и OpenShift это еще один пакет, но "это другое"... короче видите как тут всё не про малый бизнес?
Теперь про OpenShift. Он соотносится с OKD так же как RHEV с oVirt. Одно стабильное и на саппорте, а второе бесплатное открытое и слегка экспериментальное. OKD - это история про то почему традиционный старый докер(-сворм) 2014-го года деплоймента был мертворождённым. В той раз-раз и в прод контейнеризации нет понятия безопасности как класса. И это не просто для красного словца, типа вай-вай докер дырявый. Это именно объективная реальность невозможности произвести должную изоляцию одних частей контейнерной инфраструктуры от другой с учетом профилирования ресурсов. Linux не просто так переходил на cgroups v2 и не просто так стандартизируют кубик и его компоненты, включая сетевые, потому что первичные попытки сделать схожую контейнерную инфраструктуру в рамках опенстека кончились разбродом, шатаниями и отсутствием безопасности, поэтому k8s используется для контейнеров массово, а голый опенстек сильно реже.
Кубик сам по себе может быть любым и может быть собран так, что одни его части не изолированы от других. Red Hat придумал ввести ограничения через SELinux, убрать root и привнести в него мультитеннантность. Вот так и появился OKD - частный случай кубика от RH с поддержкой безопасности из коробки. Это не значит, что на ванильном кубике нельзя сделать лучше или также... просто там всё это не обязательно... с одной стороны, а с другой стороны, удачи вам нагуглить докер с докерхаба в OKD. Многие не соберутся, потому что OKD режет контейнеры по правам. Оно не совместимо с ванильным кубиком.
Отсюда и разные пакеты. Вы можете развернуть кубик как сервис в рамках опенстека и ограничить его проектами (теннантами) опенстека. Тогда каждой микросервисное приложение требует отдельного OpenStack-проекта. Альтернативно можно использовать OKD/OpenShift и засунуть несколько приложений внутрь одного OKD, и тогда мультитенантность генерируется за счет OKD.
С точки зрения инфраструктуры виртуализации никакой мультитенантности и никаких проектов нет. Это сущности, которые генерирует вышестоящее API. И вот это может быть OpenStack с его теннантами по кубику в каждом теннанте под каждое микросервисное приложение. Или наоборот это OpenShift(OKD) генерирует тенанты, как сущности внутри преднастроенного кубернетис-кластера.
