Kubernetes как профстандарт работы с контейнерами

Авторы:
Юрий Семенюков, руководитель отдела корпоративных решений Центра проектирования вычислительных комплексов «Инфосистемы Джет»
Александр Алексанян, старший инженер-проектировщик вычислительных комплексов «Инфосистемы Джет»

Развитие виртуализации и облачных технологий, а также широкое распространение методологий гибкой разработки и DevOps-практик позволило создать новый подход к разработке ПО — микросервисную архитектуру (MSA — Micro-Service Architecture). В то время как в традиционной модели отдельные модули могут представлять собой тяжеловесный монолитный софт, в MSA программное обеспечение состоит из множества лёгких модулей, каждый из которых выполняет одну простую функцию. Это соответствует принципам UNIX-подобных ОС — «Do one thing and do it well». Сам микросервис — это изолированный фрагмент кода, направленный на решение одной задачи. То есть процесс разработки ПО превращается в наслаивание «кирпичиков», из которых строится полноценный «дом», и «строительство» таким образом упрощается.

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

Чтобы оптимизировать и автоматизировать процесс управления контейнерами, используется специальное программное обеспечение — оркестратор.

Мировая практика показывает, что при разработке web-приложений сегодня целесообразно применять облачный (Cloud-native) подход с использованием комплексных продуктов по работе с контейнерами. Поэтому именно сейчас необходимо задуматься о том, как в вашей компании разрабатывают, внедряют и обслуживают все бизнес-системы. Сегодня практически промышленным стандартом для запуска контейнезированных микросервисов стал Kubernetes — остальные игроки занимают лишь определённые узкие ниши, их процент очень мал.

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

Откуда ноги растут

Словом kubernetes в древнегреческом языке называли человека, управляющего кораблем. Через изящную аллегорию раскрывается суть технологии, «рулящей» контейнерами. В 2006, задолго до существования Kubernetes, двое инженеров Google начали работу над проектом Control groups (cgroups, группы управления). Решение выделилось из функционала самого ядра Linux, который делает возможной изоляцию ресурсов ОЗУ, ЦПУ, сетевую среду и дисковый ввод/вывод в коллекцию процессов.

Следующим этапом стал выпуск собственной системы с открытым исходным кодом от Google под названием lmctfy (Let Me Contain That For You — позвольте мне содержать это для вас). Инструмент должен был стать альтернативой LXC (Linux Containers) для работы с контейнерами приложений на серверах Google. На тот момент lmctfy, LXC и Docker занимали на рынке одинаковое положение. Чтобы избежать подобных пересечений, Google остановил все разработки lmctfy в 2015. В том же году поисковый гигант опубликовал документ «Крупномасштабное управление кластерами в Google при помощи Borg». Код внутреннего проекта Borg был выложен в открытый доступ, дальнейшее развитие привело к широкой популярности — проект получил внешнее название Kubernetes и с тех пор успел стать фактически промышленным стандартом в управлении контейнерами на базе Docker.

Стоит также отметить, что Docker не остался единственно возможным инструментом для контейнеризации приложений. В 2016 году организация The Linux Foundation совместно с крупными игроками индустрии запустила проект открытых стандартов для среды выполнения контейнеров — Open Container Project (сегодня известен как Open Container Initiative). Проект преследовал цель объединить конкурирующие на тот момент Docker и CoreOS в единый стандарт. В то же время компания Red Hat начала создание собственного решения для запуска контейнеров, опубликовав его в сети под названием OCID (Open Container Initiative Daemon). Уже тогда проект ставил перед собой задачу «реализовать стандартный интерфейс исполняемой среды для контейнеров в Kubernetes», впоследствии получив название CRI-O — Container Runtime Interface. Сегодня Kubernetes поддерживает обе технологии. Разработчики от этого только выиграли, получив разнообразие свободных продуктов и конкуренцию сред выполнения контейнерных приложений.

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

Контейнеры — наше всё

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

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

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

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

Помимо прочего, система оркестрации определяет:

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

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

Ещё одно преимущество такого подхода — возможность создать группу контейнеров с общими разделами и управлять ей как единым целым. Например, если ваша веб-служба работает с помощью 5 контейнеров, которые собирают и обрабатывают данные, всеми ими можно управлять как единым объектом — так называемым pod. Отдельные наборы pod, представляющие собой целое приложение, объединяются в единый объект — Deployment, которым легче управлять благодаря оркестратору.

Kubernetes обеспечивает высокую доступность систем. В каждой конфигурации есть как минимум один (для production сред — несколько, обычно три) узел управления (Master-node), который распределяет задачи, хранит конфигурации, осуществляет планирование и мониторинг. Также Kubernetes позволяет создавать ещё более надёжные конфигурации, в которых сервисы узлов управления будут распределены между независимыми инфраструктурными узлами — Infra-node. Рабочие узлы (worker-nodes) выполняют полезную нагрузку, непосредственно запуская контейнеры с вашим приложением. Если один исполнительный узел даёт сбой, кластер продолжает работать, а «пропавшие» контейнеры автоматически перезапускаются на других рабочих узлах.

Контейнеры в силу своей архитектуры обычно запускаются достаточно быстро, так что повторная загрузка не создаёт дополнительных задержек. При этом Kubernetes «из коробки» поддерживает такие важные составляющие любого современного сервиса, как балансировка нагрузки и обновление сервисов без простоя — rolling-update. Это гарантирует, что при его обновлении не будет даунтаймов.

Наконец, средства оркестрации дают возможность использовать в качестве кластера не только ваши собственные ресурсы, но и публичные облака. Это удобно, если вам, например, нужно использовать для разработки сторонние мощности, а итоговую систему запускать в своем ЦОДе. Вы работаете в публичном облаке, а когда нужно, переносите написанное приложение к себе — для этого достаточно осуществить миграцию всех контейнеров в корпоративную ИТ-инфраструктуру.

Ничто не идеально

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

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