С нуля до запуска. Как создать свою Kubernetes-платформу?

Вокруг только и разговоров, что о Kubernetes… В ИТ-сообществе (и не только) все больше обсуждают методологию DevOps, ее особенности и работу с Kubernetes. Мы в компании «Онланта» давно познакомились с технологией контейнеризации, полюбили ее и, в какой-то момент полюбили ее и наши заказчики. Но обо всем по порядку.

 
«Онланта» в первую очередь – сервисная компания. Мы занимаемся поддержкой ИТ-инфраструктуры, облаками и информационной безопасностью. В какой-то момент наши заказчики стали обращаться к нам с задачами, которые связаны с внедрением DevOps-процессов и инструментов. Таких запросов становилось все больше, поэтому выделение отдельной DevOps-команды стало не только вполне логичным решением, но и определенной необходимостью. В рамках направления DevOps мы развиваем решение Managed DevOps и Kubernetes-платформу собственной разработки ONPLATFORM.

 
С чего все начиналось?

 
Сегодня DevOps – формирующийся и динамично развивающийся рынок, на котором большинство решений появляются по опыту реализации платформ как для внутренних потребностей компаний, так и для реализации задач на внешних проектах.

 
Есть одно «но».

 
Приоритеты, возможности и ограничения разрабатываемых решений в основном определяются опытом компании, теми рамками и задачами, которые изначально стояли перед командой. Большинство продуктов и инструментов DevOps не идеальны для внешних проектов: они либо не закрывают весь спектр потребностей заказчиков, либо изначально не подразумевают их использование без отрыва от ИТ-инфраструктуры разработчика и могут внедряться и поддерживаться только локальными специалистами самой платформы. Это ставит нас и наших клиентов в зависимость от конкретного вендора, его планов и рыночной обстановки в целом.

 
И, самое главное, никто не знает потребности наших заказчиков лучше нас. Поэтому мы решили сделать свою Kubernetes-платформу – ONPLATFORM.

 
Ресурсы, люди, экспертиза – что нужно, чтобы начать разработку Kubernetes-платформы?

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

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

 
Мы начинали с небольшой команды, где собрались люди, у которых был накоплен подобный опыт из разных областей и которые хотели его упаковать так, чтобы он не потерялся и мог быть повторно использован на будущих проектах компании.

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

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

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

Поэтапно наш путь можно представить в виде Roadmap

И грянул гром: первый реализованный проект

Первый наш проект был связан с образовательной платформой, которую мы полностью готовили к переходу в Kubernetes-среду и в нашу платформу соответственно.

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

 
На этом проекте перед нашей командой стояли следующие задачи:

• Повысить доступность информационных систем (ИС), в том числе при плановом или внеплановом повышении нагрузки;
• Обеспечить готовность ИС к масштабированию;
• Создать полноценный конвейер доставки кода для повышения надежности и скорости выпуска новых версий в различные среды;
• Обеспечить высокий уровень безопасности для компонентов новой инфраструктуры и компонентов информационных систем.

 
Как итог, после внедрения ONPLATFORM, заказчик получил современную ИТ-инфраструктуру и перестал тратить закупленные мощности в хаотичном порядке – использование вычислительных мощностей стало оптимальным и управляемым процессом.

 
В заключение

Сейчас мы ведем активную работу по крупному проекту – полностью мигрируем порталы заказчика на нашу платформу. А на осень мы запланировали релиз ONPLATFORM 2.0, в который войдут доработки, связанные с созданием интерфейса и интеграцией с биллинговой системой компании. 

По готовности мы обязательно обо всем расскажем и продолжим делиться нашим опытом.