Привет, Хабр!

В последнее время меня часто спрашивают (интересно, и кто эти люди) про Kubernetes и виртуализацию, точнее про разные варианты совмещения того и другого, и можно без хлеба в одном флаконе. Проще говоря, что лучше, интереснее и эффективнее: прикрутить к Kubernetes дополнительную фичу, например, KubeVirt, чтобы можно было с помощью оркестратора Kubernetes управлять не только контейнерами, но и виртуальными машинами, или же взять классическую среду виртуализации, управляющую виртуальными машинами, и добавить в нее Kubernetes для управления контейнеризированными приложениями. Вопрос непраздный, да к тому же непростой, поэтому давайте разбираться по порядку. За подробностями добро пожаловать под кат.

Итак, есть два подхода.

Подход №1.

Начнем с комбинации Kubernetes + KubeVirt. В общем случае Kubernetes управляет подами. Под – по сути абстрактная сущность, которая нужна самому оркестратору для эффективной работы. В подах находятся контейнеры: один или несколько, это уже не абстрактные, а совершенно конкретные сущности, но Kubernetes управляет не контейнерами, а абстрактными подами, в которых эти контейнеры собраны. Сами же контейнеры работают на виртуальных или физических серверах. А сервера в свою очередь объединяются в кластеры. Если посмотреть на всю эту пирамиду Маслоу снизу вверх, то на первом уровне у нас объединенные в кластеры сервера, в идеале физические, поверх них – контейнеры, а выше в целях управления Kubernetes добавляет еще один уровень абстракции в виде подов.

Контейнеры идеально подходят для микросервисов и контейнеризированных приложений, но ведь есть еще и вполне обычные приложения, которые в контейнеры не вставишь и которые крутятся на стандартных ВМ. Как быть с ними? Создавать ради них отдельную инфраструктуру? Нет, есть другой путь. Можно добавить в среду Kubernetes решение KubeVirt, и тогда Kubernetes сможет управлять еще и виртуальными машинами. Точнее, Kubernetes по-прежнему будет управлять подами, только в одних подах будут контейнеры, а в других – виртуальные машины.

Подход №2.

Тут все немного иначе. Мы берем классическую среду виртуализации и прикручиваем к ней Kubernetes для управления контейнерами. Опять, если проводить аналогию с пирамидой Маслоу, на нижнем уровне у нас все те же физические сервера, поверх них – гипервизоры, и выше виртуальные машины, которыми гипервизоры управляют. При добавлении оркестратора Kubernetes в эту схему, он развертывается на отдельной виртуальной машине и уже там управляет своими контейнерами.

Вопрос «что ставить себе», мягко скажем, холиварный; тут на вкус и цвет товарища нет. И тот, и другой подход вполне себе имеют право на жизнь. Однако в обоих случаях нужно хорошо понимать, с чем имеешь дело. Иначе жди проблем.

Про что же стоит подумать на берегу?

1. Экспертность

Внутренняя экспертиза важна как в первом случае, так и во втором, но, по ощущениям, эта экспертиза немного разного порядка. Классическая виртуализация на рынке давно, то есть при всем уважении инновацией ее не назовешь. Но у этого «давно» есть свои плюсы. Технология обкатана и относительно стандартизирована, то есть если инженер знаком с решением для виртуализации одного вендора, то он довольно быстро, в среднем даже за один день, сможет освоиться в решении другого вендора просто потому, что есть куча шаблонов, все компоненты плюс-минус похожи, да и их названия тоже. Как следствие, для управления средой виртуализации нужно не так много людей, а значит можно неплохо сэкономить на ФОТ, ведь айтишники нынче не дешевые.

С другой стороны, связка Kubernetes + KubeVirt относительно молодая на рынке, в любом случае явно моложе своего визави. Молодость – недостаток, который быстро проходит, это да. Но ввиду молодости, какой бы прекрасной она ни была, еще не накопилась база знаний по теме, а значит, для управления Kubernetes + KubeVirt вам понадобятся более редкие и, возможно, даже уникальные специалисты, которые разбираются сразу и в виртуализации (потому что благодаря KubeVirt вы будете иметь дело и с виртуальными машинами), и в самой среде Kubernetes. Кроме того, из-за большого уровня абстракции и гораздо более сложной структуры вам понадобится больше людей, чем в случае с простой как 5 копеек классической виртуализацией. Очевидно, что здесь на ФОТ вы вряд ли сэкономите, да и сам поиск опытных кадров – задача не из легких.

Забудем на минуту про ФОТ (хотя как тут про него забудешь) и посмотрим на вопрос с другой стороны. Дело не только в том, что крутые DevOps специалисты дорого стоят, а в том, что их очень мало на рынке. То есть человек должен разбираться в операционных системах Linux, Kubernetes, сетях, хранилищах разного типа, потому что внутри Kubernetes всё это есть и взаимосвязано, да еще знать толк в виртуализации. Можно попробовать взрастить такого специалиста внутри, но это долго и опять же дорого, проще воспользоваться аутсорсингом или аутстаффингом.

2. Быстродействие

Есть мнение, что Kubernetes – это шибко быстрая штука, и там все рабочие нагрузки просто летают. Если мы говорим про нативные контейнеры, то да, так оно и есть. А если взять, например, виртуальные машины и сравнить их с теми же ВМ в среде виртуализации, то все не так очевидно. В среде виртуализации на голом железе стоят гипервизоры и управляют виртуальными машинами: там вполне достаточно пары не очень прожорливых в смысле ресурсоемких «демонов» или даже одного демона, например, libvirt. В варианте Kubernetes+KubeVirt возникает лишний слой абстракции в виде подов, которого в условном VMware просто нет. Этот слой тоже не святым духом питается, а значит, отнимает ресурсы ЦП и ОЗУ. Получается, что при пробросе мощностей с физических серверов, часть потребляет дополнительный слой абстракции, и на поверку быстродействие ВМ в Kubernetes оказывается сопоставимым с быстродействием ВМ в среде виртуализации, по крайней мере разница уже не столь существенная, как можно было изначально подумать. Конечно, в виртуализации тоже есть свои накладные расходы, но в разрезе всего кластера их гораздо меньше. То есть 1500 виртуальных машин в стандартном кластере виртуализации потребуют гораздо меньше памяти и ЦП, чем в Kubernetes (ну, и про 500 машин есть интересная статья).

3. Философия

Неожиданно, но не знаю, как еще этот раздел назвать. Есть два принципиально разных подхода к ВМ или контейнерам: cattle и pet. Давайте разбираться. Cattle – при переводе с английского «скот» (как правило, крупно-рогатый скот) – это какая-то непонятная общая масса. Идет стадо на водопой, где чья корова – не разберешь, забьют одну животину на скотобойне, да и не жалко – мы же для мяса ее и выращивали. А pet с английского переводится как «питомец», то есть это ваш любимый кот Мурзик, ему и корм получше хочется купить и приласкать, и чтобы он подольше с вами прожил, а смерть домашнего питомца – всегда трагедия для хозяина.

Так вот, Kubernetes относится к контейнерам и новоприбывшим ВМ как к скоту, и в этом нет ничего оскорбительно. Как говорится, ничего личного, просто бизнес. Иными словами, при внесении изменений или возникновении проблем оркестратору Kubernetes проще «убить» (то бишь удалить) все или только проблемные контейнеры/ВМ и создать их заново. Вообще подход – классный, потому что новый контейнер – это новая жизнь. Никаких тебе старых, копившихся годами ошибок, костылей, битых файлов и т. д.

С другой стороны, не все эмоционально готовы на такие регулярные «чистки». Представьте, что на виртуальной машине крутится ну очень критичное приложение, например, 1С, с которого смахивает пылинки весь ИТ-отдел и над которым трясется главный бухгалтер. Или, например, Active Directory с базой данных по всем сотрудникам, или база данных клиентов со всеми адресами, явками, паролями. А теперь положите руку на сердце и скажите, что вы готовы такую ВМ удалить и потом создать заново и что вам ни капельки не страшно, что вы ни на секунду не допускаете мысль, что что-то может пойти не так. Если вам страшно, то вы не одни такие. И для таких вот осторожных и существует подход pet, который обычно используется в классической среде виртуализации, когда одна ВМ как ваш Мурзик живет с вами годами, обрастая жирком и шерстью, то есть ошибками, техническим долгом и костылями, но зато живет, и вы не переживаете, воскреснет ли Мурзик в этот раз или нет.

Проблема организаций уровня Enterprise, точнее, одна из проблем – так-то у них проблем хватает – как раз в том, что есть много критичных для бизнеса приложений, которые ни при каком раскладе «убивать» нельзя. Некоторые заказчики используют промышленное ПО, написанное еще в 2010-е гг., и раньше 2030-х его никто переписывать не собирается. Получается, при выборе KubeVirt придется дополнительно что-то придумывать для критичных приложений, то есть выносить их за пределы среды Kubernetes. В противном случае, если их оставить в среде Kubernetes, то возможны два варианта:

1. Оркестратор будет ими управлять сам, а он в этом хорош, только помните, что он управляет контейнерами и ВМ как скотом, а значит, может произвольно удалить слегка сбойнувшее приложение и попытаться создать его заново - заранее купите корвалол своему главбуху.

2. Вы будете заниматься микроменеджментом в Kubernetes на уровне отдельных контейнеров и ВМ и тем самым лишите себя всех главных преимуществ оного.

Повторюсь, подход cattle – реально хорош, и для здоровья системы как раз то, что доктор прописал. Проблема тут в человеческом факторе, попробуйте убедить главбуха крупного металлургического завода удалить базу данных 1С: Зарплата и управление персоналом. Нет, ну может и получится, но я что-то сомневаюсь…

4. История

При выборе практически любого решения, будь то новый холодильник для дома, или CRM-система для компании, нас всегда интересует история: отзывы покупателей, патчи производителя, известные болячки и проблемы, готовность сервисных подразделений провести техническое обслуживание и ремонт, а также наличие необходимых запчастей. Не хочется быть тем самым кроликом, на котором будут обкатывать не проверенное решение. Если смотреть на наш вопрос с этой точки зрения, то кейсов внедрения классической среды виртуализации на рынке как на российском, так и на международном очень много, включая варианты с адаптацией и допиливанием продукта под нужды конкретного заказчика. Это и понятно: технология не новая. А вот с KubeVirt таких кейсов пока нет, причем не только у нас, но и в мире. Функционально потенциал у KubeVirt огромен, и технология крайне интересная, но пока не было крупных внедрений, никто не знает, что там прячется под капотом и какие проблемы вылезут при реализации в продуктивной среде (а это, к сожалению, неизбежно).

5. Удобство

Тут кому что больше нравится. В Kubernetes + KubVirt управление идет через манифесты на .yaml. В принципе один раз манифест написал и тиражируй себе. Это удобно, потому что мы можем все инфраструктуры описывать как код. По сути, мы один раз описали в GitLab манифест, который описывает, например, отдельные поды наших приложений, и также все это описывается для виртуальных машин. Получается, один раз описал и поддерживаешь состояние относительно описанного состояния в своем репозитории. Идея – просто блеск!

Вместе с тем в Kubernetes нет привычного графического интерфейса, как у VMware, например. А инфраструктура как код – действительно классная фича, но она уже появляется и в средах виртуализации.

И еще один вопрос: что удобнее? С одной стороны, можно растиражировать на всю среду логику управления Kubernetes, что и произойдет, если добавить ВМ к оркестратору с помощью KubeVirt, или с другой – можно так не делать. В классической среде виртуализации гипервизоры управляют виртуальными машинами в своей обычной, более простой и привычной нам логике, а логика Kubernetes не выходит за пределы той ВМ, где оркестратор развернут, и распространяется только на контейнеры. В подобных случаях синонимом «удобства» часто становится «простота». Чем проще система, тем надежнее она работает. Гипервизор может «потерять» связь с хостом на 50 секунд и потом спокойно его подхватить и продолжить работу как ни в чем не бывало. У Kubernetes выше частота вызовов-ответов, и эта структура более сложная и более нежная, то есть крайне чувствительная к любому даже секундному простою.

Заключение

Оба варианта развертывания – «Kubernetes + KubeVirt» и «среда виртуализации + Kubernetes»  – требуют вдумчивого подхода. Оба можно внедрять в разных организациях, но перед реализацией стоит взвесить все за и против. Следует оценить уровень внутренней экспертизы, понять, какие есть приложения и системы в организации и насколько они критичны для бизнеса. Если у вас подавляющее большинство приложений находится в контейнерах, и есть лишь несколько неконтейнеризированных приложений, то можно рассмотреть Kubernetes + KubeVirt, заранее предусмотрев План Б – через резервное копирование данных и критичных приложений за пределы контура Kubernetes. В остальных случаях, когда контейнеров меньше, чем ВМ или столько же, классическая среда виртуализации выглядит предпочтительнее ввиду своей простоты, надежности и долгой истории внедрений.