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

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

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

Ниже часть 3, а начало читайте здесь: часть 1 и часть 2.

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

Тимур Тукаев: Почему компании не используют «голый» Kubernetes, почему выбирают какие-то платформенные сервисы? Почему так сложилось?

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

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

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

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

Ксения Ваганова: Давай я, может, определение дам нашего чудесного продукта, а ты уже дальше немножко расшифруешь.

Кирилл Буев: Да, давай.

Ксения Ваганова: Наша платформа называется On Platform, и мы позиционируем нашу форму как all-in-one инфраструктурную платформу, с помощью которой заказчики «Онланты» при разработке продуктовых решений могут работать с системой контейнеризации и оркестрации нагрузки, с инструментами быстрой и качественной доставки кода в рабочее окружение, с системами мониторинга, сбора логов, а также с инструментами по безопасности. Здесь, наверное, технические расшифровки будут уже от Кирилла.

Кирилл Буев: Да, немножко подробнее расскажу, чтобы было понятно, как это все выглядит и как с этим пользователи работают на наших проектах. Собственно, на таком верхнем уровне Kubernetes-платформа наша – это продукт, который состоит, во-первых, из нашего собственного дистрибутива Kubernetes, который мы внутри себя создали и развиваем. Он очень похож на Kubespray, про который я уже говорил. Мы создали собственный дистрибутив по той же причине, про которую я недавно говорил - мы считаем, что мы лучше понимаем потребности наших клиентов, по крайней мере, на тех проектах, которые есть в нашей компании, и нам проще поддерживать собственное решение, которое заточено под эти конкретные потребности, а не пользоваться каким-то общедоступным, которое должно удовлетворять требованиям огромного количества разных людей, компаний, и вносить в которое изменения достаточно сложно.

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

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

Если проводить пример, наша система мониторинга платформенная построена на стеке Prometheus, то есть это Prometheus в качестве системы агрегации метрик, Victoria Metrics в качестве долгосрочного хранилища метрик, Grafana для визуализации аналитики. Все эти средства после развертывания платформы сразу же готовы к работе, интегрированы между собой, установлены коробочные дашборды, алерты, средства для аналитики, то есть этим всем можно сразу пользоваться. Что для нас очень важно, это все настраивается, естественно, потому что это все разворачивается не руками, это все настраивается на наших проектах одинаково. Какое-то развитие, которое, допустим, платформа получает в результате того, что мы увидели на каком-то одном проекте, то есть по результатам обратной связи наших клиентов, это развитие сразу же доступно всем клиентам, которые пользуются нашей платформой, потому что, опять же, это единое решение для всех. Опыт при переиспользуется, мы не теряем его, и очень этому рады.

Тимур Тукаев: На каком стеке вас устроено, ты упоминал Grafana, Prometheus, а с точки зрения языков программирования, фреймворков что использовали, и почему именно это выбрали?

Кирилл Буев: Как я уже говорил, дистрибутив Kubernetes конкретно у нас очень похож на Kubespray, то есть там активно используется Ansible. Для управления непосредственно инфраструктурой, то есть виртуальными машинами и всем, что с этим связано, мы используем Terraform, a для склейки этого всего и написания, так сказать, назовем это бизнес-логикой, мы используем Go, используем именно Go, просто потому, что когда все это начиналось, у нас в команде были люди, которые его знали. Мы поэтому просто начали его использовать. Это, в общем-то, частая история.

Ксения Ваганова: Да-да.

Кирилл Буев: Собственно, нам, на самом деле, повезло, что это был, допустим, именно Go, а не Python, потому что Kubernetes, как и многие инструменты в этой экосистеме вокруг него, написаны именно на этом языке. Мы можем это еще и использовать для того, чтобы, допустим, самостоятельно и быстро исправить какой-нибудь баг, с которым мы столкнулись, но который, допустим, достаточно редкий, и, соответственно, в апстриме будет исправлен достаточно для нас быстро. У нас были случаи, когда мы находили баг, допустим, в каком-нибудь CNI-плагине для Kubernetes, который у нас воспроизводился в каком-то из окружений, мы провели, отправляли этот патч в upstream, и собственно дальше могли пользоваться апстримной же версией этого плагина, не поддерживая собственный Fork. Это все стало возможно только благодаря тому, что у нас, собственно, были люди, которые знали этот язык.

Тимур Тукаев: Я так понимаю, вы даже частично контрибьютите в Kubernetes, или в какие-то решения опенсорсные, которые с ним связаны, не знаю, Ansible, еще что-то.

Кирилл Буев: У нас есть определенное количество контрибуции, да, в определенный open source, но не в сам Kubernetes пока что. Естественно, объем у нас ниже, чем у некоторых компаний – понятное дело, что конкурировать с Red Hat по объему коммитов в Kubernetes достаточно сложно. Но да, мы очень рады, что у нас есть такая возможность, потому что эта экосистема очень быстро развивается, и она развивается настолько быстро, что документация очень быстро устаревает. Очень часто проще посмотреть, что в коде происходит, чтобы понять, как с этим работать. Поэтому мы уже не раз просто радовались, что у нас есть люди, которые пишут на Go, которые могут для нас это сделать, или исправить какой-то баг, или добавить функциональность. У нас был случай, что нам не хватало конкретной вещи в CSI-драйвере для Kubernetes, то есть компонент, который интегрирует Kubernetes с внешним хранилищем данных. Нам не хватало определенной фичи, мы сделали, отправили патч, и, собственно, теперь этим могут пользоваться все. Это еще и приятно.

Тимур Тукаев: У Red Hat, да, стратегия в open source, в free software такая, они нанимают людей, которые для них контрибьютят, и больше ничем не занимаются. У вас, я так понимаю, нет такой фокусировки, ваш contribution, скорее, связан с тем, что у вас возникли какие-то свои задачи, которые не покрывались стандартными инструментами, либо вы в процессе заметили какие-то баги, поправили, и так далее. Или есть какая-то осознанная часть работы, прям по постоянному contribution?

Кирилл Буев: Осознанной работы по постоянному contribution у нас сейчас нет, хотя мы очень надеемся, что нам удастся такую работу построить. Поэтому, да, весь наш вклад в это все связан с необходимостью, по сути. Мы с чем-то сталкивались, нам нужно было это сделать, мы видели, что это может быть полезно еще и другим. Естественно, нам проще было это исправить в апстриме, чем поддерживать, допустим, свой Fork, майнтейнить его и решать те задачи, которые с этим связаны.

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

Кирилл Буев: Собственно, написан он на Go. Соответственно, первое, что нужно – это умение писать на этом языке. С какой стороны подойти к контрибуции в этот проект? В общем-то, возможностей очень много. Исходный код находится в GitHub, любой может отправить туда pull request. Если есть какая-то проблема, допустим, которую обсуждают в сообществе, если есть какой-то issue, который пока никто не знает, как решать, или до которого не доходят руки, любой может сделать свой вклад. Ограничений для этого практически нет. Нужен просто энтузиазм и какая-то проблема, которую нужно решать, а проблем, которые нужно решать в Kubernetes и во многих инструментах, с ним связанных, огромное количество. Работы непочатый край, ее хватит на всех, и еще останется.

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

Кирилл Буев: В целом, можно сказать, что в монстра Kubernetes превратился уже какое-то время назад, поэтому ему, наверное, это не грозит, потому что это уже произошло. Развивается он достаточно активно, и такое самое активное, наверное, направление, в котором сейчас много развития видно от релиза к релизу, это безопасность. Традиционно эта сфера, к сожалению, обычно обходилась стороной в том, что касается контейнеризации и оркестрации, и поэтому очень многие вопросы, связанные с безопасностью, в Kubernetes традиционно закрывали сторонними средствами, из которых, опять же, нужно было выбирать. Сейчас в последней паре релизов в Kubernetes появляются некоторые интересные фичи, за которыми интересно наблюдать, которые еще, может быть, не совсем готовы к полноценному использованию в продакшене, но которые в будущем наверняка будут допилены и будут очень полезны. Одна из таких фич – это, например замена, pod security policy, то есть политики безопасности для подов и, соответственно, для того, что запущено в подовых контейнерах, на новую сущность, которая должна упростить написание и применение политик безопасности для контейнеризованного ПО, которое запускается в Kubernetes. Сейчас в основном для этого используются сторонние решения, такие, как ОРА или Caverna. Но, возможно, для каких-то таких не очень сложных, скажем, кейсов в будущем это можно будет полноценно делать штатными средствами самого Kubernetes.

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

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

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

Кирилл Буев: Зависит от того, как именно разработчик работает с этими инструментами. Мы предпочитаем, на самом деле, называть команды, которые работают с платформой или развивают внутреннюю платформу внутри компании, собственно, не DevOps-инженерами, а платформенными инженерами, или PlatOps, потому что они, по сути, разработчики являются их клиентами внутренними, по своей сути, и они делают именно платформу для самообслуживания другой команды. От этого зависит, какой уровень компетенции будет требоваться от разработчиков. Конечно, в общем случае ожидается, что разработчик имеет верхнеуровневое хотя бы представление о том, что такое контейнер, что означает вообще, в принципе, что приложение запускать в контейнере, и какие проблемы, какие требования с этим могут быть связаны.

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

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

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

Кирилл Буев: Я бы сказал, что людей следить, в принципе, поскольку, опять же, хорошо это или плохо, каждый решает сам для себя, контейнеризация и оркестрация с нами надолго, это факт, то есть это, так сказать, наша реальность, поэтому следить можно, в принципе, за всеми крупными технологическими компаниями, за их технологическими блогами, потому что они, так или иначе, это используют в повседневной деятельности. Это и IBM, это и Red Hat, это и VMware, то есть все крупные технологические компании, которые практически все, так или иначе, используют технологии из этой экосистемы.

Если говорить про отдельные персоналии, так сказать, про отдельных людей, я могу порекомендовать следить за тем, что пишет, за материалами, которые выпускает человек, которого зовут Брэндан Грегг, это перформанс-инженер из компании Netflix, который очень много делает в области перформанс-инжиниринга, то есть в анализе и в решении проблем, связанных с производительностью приложений. А поскольку сейчас везде контейнеры, Kubernetes и все прочее, его работа сейчас с этим, так или иначе, связана, и он выпускает очень много и книг, и просто полезных материалов на эту тему. Сама тема наблюдаемости, мониторинга, проблем с признательностью обычно очень важна, и все материалы, которые выпускает, практически, я могу порекомендовать. Его книга Systems Performance во втором издании стала у нас в группе, по сути, настольной книгой.