Kubernetes: меняя будущее разработки приложений

Kubernetes стал незаменимым для разработки современных приложений. Узнайте, как он развивается для поддержки рабочих нагрузок искусственного интеллекта и машинного обучения и меняет среду разработки.

Kubernetes стал де-факто стандартом оркестрации контейнеров, совершив революцию в том, как разработчики создают, развертывают приложения и управляют ими. Недавний отчет Портала Российские Технологии показывает, что 80% респондентов планируют создавать большую часть своих новых приложений на облачных платформах в ближайшие пять лет. Этот сдвиг — не просто тенденция; это фундаментальное изменение в нашем подходе к разработке программного обеспечения и управлению инфраструктурой.

Преимущество Kubernetes для разработчиков

Разработчики компании DST Global подчеркивают, что Kubernetes создан с учетом потребностей разработчиков. Он предлагает три ключевых преимущества:

1. Ускоренный выход на рынок: Kubernetes оптимизирует процесс разработки и развертывания, позволяя командам быстрее выполнять итерации и выпускать приложения.

2. Гибкость в развертывании. Приложения можно запускать где угодно — локально, в публичных облаках, таких как AWS или GCP, или в гибридных средах.

3. Разработчики Возможности самообслуживания. могут заявлять о своих потребностях в инфраструктуре, а Kubernetes автоматически выделяет необходимые ресурсы и управляет ими.

Эти преимущества способствуют быстрому внедрению Kubernetes во всех отраслях. «Если вы сегодня являетесь ИТ-директором и создаете приложение на чем-то другом, кроме Kubernetes, вас застрелят».

Переход от виртуальных машин к Kubernetes

Поскольку 58% организаций планируют перенести некоторые рабочие нагрузки виртуальных машин в Kubernetes, разработчики и архитекторы сталкиваются с новыми проблемами. Разработчики DST Global предлагают несколько идей по управлению этим переходом:

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

- Зрелость технологий. Хотя технологии виртуальных машин, такие как VMware, уже достигли зрелости, решения на базе Kubernetes для запуска виртуальных машин (например, KubeVirt) все еще развиваются.

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

- Опыт имеет значение: организации с большим опытом работы с Kubernetes лучше подготовлены к миграции с виртуальных машин.

Обзор Kubernetes для программистов: как он устроен, как работает и как связан с облаками

Kubernetes — это оркестратор для контейнеров, написанный на языке Go в Google. Раньше уже существовали решения для создания и развёртывания виртуальных машин — такие как Microsoft Hyper-V или продукты от VMware.

Для контейнеров был тот же Docker — он позволял администрировать по несколько контейнеров одновременно. Однако для развёртывания больших многокомпонентных продуктов для сервисов и приложений, использующих контейнеры в своей архитектуре, технологий не было.

Поэтому появился Kubernetes: он позволяет автоматизировать развёртывание целых кластеров с контейнерами, гибко задавать различные политики и настройки и пользоваться подходом Infrastructure as Code.

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

Когда стоит использовать Kubernetes

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

А теперь представьте, что у нашего приложения довольно много пользователей и ему требуются серьёзные ресурсы. Понятно, что мы не будем собирать под него суперкомпьютер — современная IT-индустрия выбрала путь распределённых систем, когда какое-то количество относительно слабых серверов собираются в единую распределённую систему и дают необходимые мощность, быстродействие и ресурсы. Это удобно: их количество можно наращивать постепенно, масштабируя ресурсы под требования приложения, а отдельные серверы можно легко заменять, если они вдруг выйдут из строя.

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

Тут на помощь и приходит Kubernetes. Мы просто описываем необходимые характеристики инфраструктуры (ресурсы для приложения, дизайн сети и так далее), а Kubernetes выполняет указания и управляет серверами, которые к нему подключены. Так он экономит время администраторам и разработчикам.

Как появился Kubernetes

В книге Site Reliability Engineering описан внутренний проект Google — система управления кластерами Borg. В 2014 году Google опубликовал исходные коды этого проекта, а уже в 2015 году в партнёрстве с Linux Foundation организовал фонд Cloud Native Computing Foundation (CNCF), которому и передал сорцы Kubernetes в качестве своего технического вклада. Этот фонд развивает open-source-проекты по разработке утилит и библиотек, которые позволяют создавать приложения ориентированные на облачные модели архитектур.

Сейчас Kubernetes — alumni, или по-русски «выпускник», Cloud Native Computing Foundation. Его довели до стабильной версии, и он получил статус Graduated Project (завершённый проект) в терминологии CNCF.

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

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

Принцип работы Kubernetes

Kubernetes состоит из двух больших частей (см. изображение ниже):

- Control Plane — оркестратор, API и база конфигурации.

- Node Pools — серверы с доступными ресурсами.

За Control Plane отвечает сервер Kubernetes Master Node. Kubernetes Worker Nodes группируются в Node Pool (пул узлов, нод). Как правило, один Node Pool соответствует группе серверов с одинаковыми заданными характеристиками. Например, пул серверов на базе Windows, пул серверов с Linux и пул серверов с GPU.

На каждой ноде (или узле, отдельном физическом сервере или виртуальной машине) устанавливается агент kubelet — он помогает получать инструкции от сервера Master Node, а также различные компоненты, драйверы и расширения для мониторинга безопасности сети. Всё это складывается в платформу для развёртывания приложения.

Итого: само приложение описывается через deployment-ресурс, который содержит несколько pod (далее — поды), в каждом из которых находится от одного до нескольких контейнеров. Поды как раз и являются единицами масштабирования системы в Kubernetes — своеобразными молекулами, из которых состоит система. Например, когда выбирают, на какой ноде будет запущен тот или иной компонент приложения, минимальной областью ресурсов считается именно под, а не отдельный контейнер или физический сервер.

Иерархия компонентов Kubernetes. Node Pool состоит из нод (Worker Node). Application состоит из Deployment, который в свою очередь состоит из подов, в которых содержатся контейнеры.

Принцип работы Kubernetes аналогичен классическим кластерам. Мозг системы — Kubernetes Master Node, который отвечает за Control Plane и содержит:

- API для администраторов и разработчиков;

- базу конфигурации с параметрами контейнеров, приложений, деплоймента, сети, хранилищ;

- оркестратор или планировщик, которые запускают контейнеры.

Напомню, что Kubernetes объединяет пулы из нод — то есть серверов, объединённых общими характеристиками. Например, пул из Windows-северов, пул из Linux-серверов, пул из серверов, на которых есть GPU. Ноды объединяются в пулы по определённым характеристикам. Потом администратор сообщает Kubernetes, что это за характеристики: вычислительная мощность, память, хранилище — а Kubernetes самостоятельно распределяет ресурсы, находит в кластере ноды, которые удовлетворяют этим характеристикам, и запускает поды приложения на них.

Можно установить минимальное и максимальное количество подов для приложения, и Kubernetes будет стараться поддерживать это их количество. А вот за поддержание и масштабирование количества нод (то есть отдельных физических серверов или виртуальных машин в составе поды) уже могут отвечать администратор, гипервизор или облачная платформа по типу Azure, GCP, AWS — но не сам Kubernetes.

А если какой-то из элементов инфраструктуры даёт сбой, Kubernetes автоматически пытается решить проблему: например, перезапустить одну поду или deployment, чтобы состояние системы в целом соответствовало конфигурациям, загруженным через API и сохранённым в Master Node. В результате приложение, компоненты которого поделены на поды и контейнеры, крутятся в пространстве ресурсов, объединённых в кластер Kubernetes — в своеобразное облако-контейнер.

Риски использования Kubernetes и облачной инфраструктуры

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

Самый частый кейс использования Kubernetes во Франции — попытка вырваться из тисков привязки к конкретному вендору (vendor lock).

Достоинство любых облачных сервисов — Platform as a service, то есть приложение можно сразу же развернуть и заниматься более высоким уровнем абстракции, не думая о реализации уровня middleware, наподобие LAMP-stack (Linux/Apache/MySQL/PHP). Но если мы хотим, чтобы наше приложение могло одинаково работать на разных облачных платформах, решением может быть Kubernetes и запаковка приложения в контейнеры. Однако когда наше приложение привязывается к особенностям того или иного PaaS, переход от одного облачного провайдера к другому с технической точки зрения усложняется.

Хотя и при выборе Platform as a Service есть определённый риск стать Vendor locked — ведь существует не так много облачных решений. По сути, мы выбираем между Microsoft, Amazon, Alibaba или «Яндексом». А ведь делать темплейты приходится под конкретную конфигурацию конкретного облачного провайдера.

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

А в случае не с IT-бизнесом мы имеем ещё одну проблему: для таких компаний IT-инфраструктура не является основной, профильной деятельностью (то, что называется Core Business) — они рассматривают её лишь как внутренний сервис для удовлетворения потребностей бизнеса, а значит, команда IT-специалистов у них будет маленькой и поддерживать режим Multicloud будет практически нереально.

Типичный кейс Multicloud — когда покупают сервера Azure и Amazon и разворачивают Kubernetes-кластер на каждом из них. Один из облачных провайдеров становится главным, а второй используют для бэкапа и на случай, если что-то произойдёт с первым. Приложение контейнизируют и делают конфигурацию под Kubernetes, а компания может переходить из одного облака на другое без дополнительных инвестиций (кроме затрат на постоянную поддержку этого режима и стартовую конфигурацию под два облака).

Это существенно снижает риски — да и дешевле решений на виртуальных машинах. Но перевести бизнес с виртуальных машин на Kubernetes тоже непросто — это означает полную смену технологии. Во Франции с этим сложно, потому что придётся пересобирать IT-команду или переучивать уже нанятых сотрудников. С точки зрения бизнеса это достаточно сложный организационный процесс, который займёт не меньше трёх-шести месяцев.

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

Отличия между решениями разных облачных провайдеров

У каждого Kubernetes-провайдера есть свои особенности работы с сетью, хранилищем, вычислительными ресурсами. Например, у Azure есть GPU-серверы, и они добавили Confidential Computing, чтобы шифровать память при выполнении процессов — даже если для их выполнения нужен физический доступ к серверу.

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

Недостатки Kubernetes

Безопасность. В одной технологии много различных компонентов, за безопасностью которых приходится внимательно следить: как внешней, на уровне кластеров и нод, так и внутренней, на уровне конкретных образов. Уже появились специальные AntiMalware-решения под Kubernetes, которые сканируют всё, что происходит внутри контейнера.

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

Решить эту проблему можно сканированием активности, шифрованием сетевого трафика, установкой компонентов для безопасности, решений для аутентификации контейнеров и компонентов приложений. Это усложняет жизнь Kubernetes-администраторов, но с этим ничего не поделать — это часть нашей работы.

Kubernetes — это всё-таки не PaaS, поэтому приходится запаковывать в контейнеры ещё и middleware, а также зависимости для приложения. Но и эта задача упрощается благодаря огромному количеству уже готовых и преднастроенных образов для контейнеров, которые выложены в публичные реестры.

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

Сложность администрирования. Решается использованием облачных сервисов. Разработчики DST Global не рекомендуют самостоятельно настраивать Kubernetes, потому что для этого нужны очень узкие специалисты, а поддерживать кластер самостоятельно очень сложно.

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

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

Лучше использовать решения, предоставляемые облачными провайдерами. Сегодня практически любой облачный провайдер подключает Kubernetes as a Service. Плюс существует понятие Certified Kubernetes — все облачные провайдеры сертифицируют своё Kubernetes-подключение в Cloud Native Computing Foundation, а фонд ведёт список сертифицированных провайдеров и постоянно обновляет его.

Если брать KaaS, то вы будете платить за выделенные вычислительные ресурсы и хранилища. Как правило, в стоимость также включена оплата за Master Node, который предоставляет API и распределяет ресурсы, а вот за Worker Nodes, на которых будут размещаться сами поды, надо будет платить отдельно.

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

Это развяжет руки провайдерам, но усложнит жизнь администраторам. Ведь, например, если я хочу поддерживать Kubernetes в Azure, мне нужно будет лучше понимать, что происходит внутри Azure и понадобится поддерживать знания по конкретному облаку.

Альтернативы Kubernetes

У Kubernetes были конкуренты среди оркестраторов контейнеров. Например, есть кластеры Apache Mesos, HashiCorp Consul, Windows Server, Docker Swarm — они помогают удобно работать с виртуальными машинами и контейнерами. На решениях от этих непрямых конкурентов тоже можно строить инфраструктуру. Однако Kubernetes выиграл войну и стал стандартом де-факто, потому что у него есть много удобных инструментов для управления ролями, доступами, политиками безопасности и идентификацией.

Ещё одна альтернатива Kubernetes — FaaS Serverless-технологии. При таком варианте код приложения будет запускаться в момент запроса, а так как приложение делится на самостоятельные запускаемые функции (созданные под каждый тип запроса), то такие системы становятся более портабельными и интегрируемыми, чем целое приложение, созданное под конкретный PaaS. Подобные решения есть у разных провайдеров, но они обладают кастомным API — например, как у Droplets от DigitalOcean.

Однако использование виртуальных машин остаётся скорее более дорогой альтернативой использованию контейнеров. Такое решение просто будет сжирать больше ресурсов — хотя оно и может быть оправданно, если мы создаём архитектуру для микросервисов.

Кстати, помимо классического Kubernetes, существует и Kubernetes от RedHat — Red Hat OpenShift.

Итоги

- Kubernetes стоит использовать, если в вашем проекте счёт контейнеров идёт на десятки или сотни.

- Kubernetes сам определяет, когда надо масштабировать ресурсы, когда подключить к проекту новые мощности и тому подобное — на основании конфигурации.

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

- Чтобы избежать рисков, связанных с блокировкой облачного провайдера, есть смысл разворачивать инфраструктуру на платформе двух провайдеров: один будет основным, а второй — резервным.

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

- В Европе компании очень медленно переходят на Kubernetes и пока предпочитают более привычные и потому менее рисковые виртуальные машины.