Все о Kubernetes: контейнеры, оркестрация, тулинг, виртуальные машины, конкуренты и экосистема #2

Эксперты «Онланты», Ксения Ваганова, руководитель направления DevOps, и Кирилл Буев, системный архитектор, приняли участие в подкасте «Люди и код». В выпуске вы узнаете, что такое Kubernetes, какие инструменты существуют в экосистеме Kubernetes и используются в связке с ней, а также что такое Kubernetes-платформа собственной разработки, как такие платформы устроены, для чего они нужны и многое другое. Ведущий подкаста – Тимур Тукаев, выпускающий редактор Skillbox.

Полностью послушать подкаст вы можете на нашем канале. А если вам по каким-то причинам неудобен аудиоформат, вы можете прочитать текстовую версию.

Ниже часть 2, а часть 1 читайте здесь.

Все о Kubernetes: контейнеры, оркестрация, тулинг, виртуальные машины, конкуренты и экосистема. Часть 2.

Тимур Тукаев: Если говорить про мирусы самого Kubernetes, чего ему не хватает, чтобы быть идеальным? От чего, например, у сообщества, которые пользователи Kubernetes, пригорает больше всего, на что жалуются, может, о чем прямо говорят: «Давайте уже добавьте, не можем без этого»?

Кирилл Буев: Основной минус в том, что Kubernetes сам по себе – это не готовый какой-то инструмент, не готовое решение, это конструктор. Я бы даже сказал, это часть конструктора, то есть это всего несколько элементов из такой огромной коробки с Lego, которую представляет собой Cloud Native экосистема, которая сама по себе практически бесполезна. Голый Kubernetes сам по себе, отдельно, он бесполезен практически, им практически невозможно пользоваться. Поэтому, так или иначе, если компания рассматривает для себя переход на Kubernetes, ей приходится искать либо какие-то готовые решения, то есть Kubernetes-платформы, в частности, либо делать такую платформу самостоятельно. От решения «да, мы точно уверены, что Kubernetes нам нужен, мы точно хотим идти в сторону контейнеризации и оркестрации» до непосредственно того момента, когда бизнес начнет получать от этого какой-то профит, проходит достаточно много времени. И, соответственно, понять, что да, точно все хорошо, и все идет как надо, понимают это обычно достаточно поздно. Нужно очень много времени потратить на то, чтобы, в принципе, это довести до какого-то работоспособного состояния и понять, работает это действительно или нет в реальных условиях. «Из коробки» пользоваться этим практически нельзя, нужно тратить много сил и времени на допиливание этого под свои задачи. Собственно, именно по этой причине появились такие вещи, как OpenShift или Rancher от компании SUSE, то есть инструменты, которые закрывают типовые задачи, с которыми сталкивается любой бизнес, любой пользователь, который хочет начать использовать Kubernetes и контейнеры на каком-то масштабе.

Тимур Тукаев: Если говорить об ограничениях технологического стека, который мы используем вместе с контейнерами, оркестрацией контейнеров, то какие здесь существуют ограничения, рамки, где здесь проблемы могут возникнуть?

Кирилл Буев: В целом, непреодолимых ограничений нет, но есть определенные, скажем так, нюансы и требования, которые эта новая среда налагает на приложение. Исторически так сложилось, что и контейнеризация, и оркестрация лучше подходят для работы со stateless-приложениями, то есть приложениями, которым не нужно хранить какое-то свое внутреннее состояние в каком-то виде, например, просто у себя, условно, «под ногами» в виде обычных файлов. Изначально Kubernetes, например, если мы говорим про него, был очень очевидно предназначен и заточен, скажем так, под эксплуатацию stateless-приложений. В нем было очень мало удобных инструментов для того, чтобы нормально эксплуатировать в нем stateful-приложения, то есть те, которым нужно персистентно хранить какие-то данные. Сейчас, поскольку Kubernetes активно развивается, в нем достаточно многое для этого есть, и, в принципе, сейчас гораздо менее страшно запускать в нем такие вещи, как базы данных, объектные хранилища и все прочее, в чем нужно хранить данные, но все равно с этим связано достаточно много нюансов. Если хочется это делать, то есть запускать такие приложения в контейнерах и в том же Kubernetes, нужно очень хорошо знать заранее ответ на вопрос, зачем это нужно. Это можно делать, это приходится делать в некоторых случаях, но в целом тот же Kubernetes – это не универсальный инструмент для запуска вообще любых приложений. Всегда есть нюансы, всегда нужно смотреть на то, что приложению нужно, насколько оно готово, в принципе, к работе в такой новой парадигме.

Тимур Тукаев: Kubernetes стал в определенной степени каким-то, может быть, центром, определенной экосистемой технологической, и вокруг него развивается различный тулинг, какие-то инструменты, которые с ним используются, в том числе, например, у вас есть свое какое-то решение Kubernetes. Какой вообще тулинг вот такой существует в этой экосистеме, и что используется в связке с Kubernetes?

Кирилл Буев: Да, экосистема инструментов вокруг Kubernetes сложилась очень большая, объемная. У CNCF на их сайте есть так называемая схема Cloud Native Landscape, то есть ландшафт Cloud Native инструментов. Это такая очень большая, страшная схема, на которую наносятся все инструменты, про которые знает CNCF. Она огромная, то есть ее можно распечатать на постере и повесить на свою стену, чтобы периодически вдохновляться или наоборот.

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

Тимур Тукаев: Еще рядом с Kubernetes частенько, по крайней мере, в вакансиях возникает слово Ansible. Что это такое, как они связаны между собой?

Кирилл Буев: Ansible – это система управления конфигурациями, одна из доступных, то есть это ПО, которое позволяет конфигурировать виртуальные машины, софт, который на них запускается. В связке с Kubernetes обычно это упоминается, если компания использует непосредственно Ansible, его возможности для автоматизации, развертывания кластеров Kubernetes. Например, есть готовые дистрибутивы Kubernetes, такие, как Kubespray, которые разрабатываются непосредственно самим сообществ Kubernetes. Kubespray, например, полностью построен на Ansible, то есть это просто набор определенных сущностей Ansible, который позволяет развернуть готовый production cluster в Kubernetes достаточно быстро. Многие компании, включая нас, Ansible как компонент своих решений, своих платформенных решений, то есть мы его используем как средство автоматизации в составе своего дистрибутива нашей платформы, то есть мы в этом плане похожи на Kubespray. Естественно, это не единственный вариант, с помощью которого можно эти задачи автоматизировать, используются и другие. Используется, например, Terraform от компании HashiCorp, если мы говорим про управление инфраструктурой и особенно про управление инфраструктурой в публичных облаках, где тот же Kubernetes часто предоставляется в виде SaaS или PaaS. В принципе, Ansible упоминается в вакансиях действительна часто, по той причине, что порог входа в него относительно остальных похожих инструментов несколько ниже, и, соответственно, большое количество людей его знает и использует.

Тимур Тукаев: Ксения, можешь подсказать, есть экосистема вокруг Kubernetes, и насколько это классный, интересный и развивающийся рынок, если смотреть с точки зрения технических команд, которые хотели бы какой-то стартап сделать в этой сфере? Это «алый океан», или здесь много места еще? Какие, может быть, направления самые перспективные?

Ксения Ваганова: Слушай, наверное, здесь места хватит всем. По крайней мере, мы со своим платформенным решением вошли в нишу где-то чуть больше года назад, успешно развиваемся. У нас есть заказчики, есть клиенты. Мы успешно проводим аудит, внедряем свое платформенное решение или помогаем командам в рамках своего направления решать какие-то точечные задачки. Поэтому в целом, наверное, место в нише еще есть. Однако здесь, конечно же, нужно учитывать тот факт, что на этом рынке достаточно много конкурентов. О них Кирилл уже говорил, это есть вендорские решения, например, OpenShift от Red Hat или Rancher от SUSE, или в целом просто SaaS-решения от «Яндекса», VK и так далее. Поэтому нужно все-таки будет задумываться о том, кто твои пользователи, как правильно определить свою целевую аудиторию, и как правильно продавать свой продукт, потому что, так как есть такие крупные гиганты и гиперскейлеры в конкурентах, здесь прежде всего нужно будет ответить на основные продуктовые вопросы, прежде чем идти и что-то разрабатывать.

Тимур Тукаев: Если говорить не о конкуренции внутри экосистемы, это уже, наверное, больше к Кириллу вопрос, а об аналогах Kubernetes, мы же понимаем, что в современном мире нет продуктов, у которых бы не было аналогов или конкурентов, которые хотя бы насколько-то их рынок как-то теснили, что вместо Kubernetes можно использовать?

Кирилл Буев: В качестве аналогов, я бы не сказал, что это именно конкуренты, а, скорее, именно аналоги, потому что они все немножко занимают такую отдельную свою нишу. Обычно называют четыре продукта: это HashiCorp Nomad, то есть это продукт из части так называемого Hashi Stack, то есть такая продуктов, которая разрабатывается компанией HashiCorp, Docker Swarm и Apache Mesos. В случае с Nomad это больше планировщик задач, необязательно в контейнерах при этом, то есть он, в принципе, может использоваться для управления и распределения задач внутри пула вычислительных ресурсов, необязательно контейнеризованных. Это, собственно, та ниша, в которой его обычно используют. По сути, это один компонент из, если проводить аналогию с Kubernetes, это собственно планировщик, то есть scheduler кластерный. Все остальные компоненты, которые, допустим, есть в Kubernetes, или которые появляются там благодаря каким-то сторонним решениям из экосистемы в Hashi Stack предполагается заменять другими продуктами компании HashiCorp, то есть Consul, Vault, Boundary и так далее.

В случае с Apache Mesos это больше фреймворк для разработки собственно ПО для управления кластерами, а не готовое решение. Его обычно используют компании, у которых очень специфические юзкейсы, и которым по какой-то причине не подходит Kubernetes. В прошлом году развитие Apache Mesos настолько замедлилось, что его хотели переместить в архив проектов Apache Foundation, но в какой-то момент увидели, что интерес вдруг начал расти, и собственно это событие было. Пока это решение продолжает в каком-то виде развиваться.

А вот Docker Swarm раньше был очень хорош для совсем простых задач, то есть когда нужно было просто запустить контейнеры на нескольких машинах, и как-то этим управлять. Он был хорош, он был встроен, и есть, собственно говоря, сейчас встроен непосредственно в сам Docker, но он практически не развивается, судя по всему, потому что, по мнению разработчиков, видимо, битва с Kubernetes проиграна.

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

Читайте продолжение здесь – часть 3.