11 мая 2021

Kubernetes своими силами: пять неочевидных нюансов эксплуатации кластера

За последний год спрос на Kubernetes (K8s) многократно вырос. Однако попытка самостоятельно развернуть и эксплуатировать кластер нередко оканчивается провалом.

Открытая платформа для управления кластером контейнеров как единой системой применяется множеством компаний, которые разрабатывают и развертывают собственные приложения. Вокруг технологии сформировалось сообщество специалистов, она получает поддержку таких гигантов, как Microsoft, RedHat, и IBM. Из технологической новинки K8s превращается в обязательный атрибут современного процесса разработки ПО.
 
Kubernetes – технология, востребованная прежде всего крупными компаниями. Многие из них имеют штат опытных администраторов и собственные мощности, казалось бы, достаточные для того, чтобы самостоятельно развернуть и эксплуатировать кластер Kubernetes. Разберем, какие подводные камни встречаются на этом пути.
 
1. Постоянная поддержка
 
Развертывание кластера Kubernetes, на первый взгляд, не самая сложная задача. В распоряжении компаний имеются обширная официальная документация и специально разработанные инсталляторы, в числе которых можно назвать Kubespray и Kubeadm. И, вполне вероятно, в ИТ-службе крупной компании найдется инженер, способный разобраться в этих ресурсах и применить их. Однако Kubernetes требует внимания не только во время развертывания, но и в процессе эксплуатации. А сложности непременно возникнут — через пару недель или месяц после запуска. Причины нестабильности могут быть самыми разными: от проблем с дисками до неконтролируемого создания системой новых pod’ов («кирпичиков», из которых складывается кластер К8s).
 
Для того чтобы справиться с этими сложностями, придется нанимать специалиста, который будет заниматься исключительно поддержкой кластера Kubernetes. Со временем, если речь идет о масштабной инфраструктуре, потребуется расширить штат. За короткий срок нужно будет сформировать команду инженеров, которые не только хорошо знакомы с К8s, но и способны развивать кластер, дополнять его инструментами, позволяющими получить от технологии максимум пользы. Все это ограничивает аудиторию «доморощенного» (self-hosted) Kubernetes крупными компаниями, перед которыми не стоит задача экономить ресурсы и которые имеют возможность выделить сотрудников для обслуживания кластера.
 
2. Отдельная экосистема
 
Годами ИТ-службы компаний формировали свои цифровые платформы как единую экосистему сервисов. Развернув на собственных мощностях Kubernetes, они столкнутся с тем, что теперь им придется поддерживать две совершенно разные экосистемы. Увы, К8s не вписывается в корпоративные цифровые миры и требует для корректной работы отдельных инструментов.
 
Это означает, что для Kubernetes нужны отдельные дополнительные инструменты, требующие настройки: система мониторинга, балансировка нагрузки, сбор логов, отдельная настройка безопасности, сети и многое другое.
 
3. Системы хранения
 
Использование систем хранения данных в Kubernetes — еще одна серьезная проблема. Дело в том, что Kubernetes изначально разработан для stateless-приложений, которые не хранят данные внутри контейнеров. Для того чтобы интегрировать с кластером stateful-приложения, предстоит подключить внешние хранилища, в частности persistent volumes, позволяющие приложению работать без изменения его логики. Такие хранилища подключаются внутрь контейнеров как локальные директории, давая приложению возможность хранить данные «под собой». Это нетривиальная задача, которая потребует отдельного инженера или даже команды специалистов, обладающих профильными навыками.
 
4. Отказоустойчивость
 
Kubernetes славится простотой обеспечения отказоустойчивости приложений. Но при этом требует отдельного внимания к отказоустойчивости кластера в целом. Для решения задачи нужно развернуть три дополнительных сервера. Для крупной компании это незначительные расходы, но для малого бизнеса такой апгрейд мощностей может стать серьезной статьей затрат.
 
Кроме того, в Kubernetes есть встроенный механизм самовосстановления. Если из строя выходит один из серверов, то все процессы, ранее работавшие на нем, автоматически перезапускаются на других нодах кластера. Но это подразумевает резервирование ресурсов. Выполнить такое требование можно далеко не всегда, ведь на обычных bare metal-серверах (на «голом железе») сложно создавать отказоустойчивые конфигурации. 
 
5. Автомасштабирование
 
Еще одна проблема, с которой можно столкнуться в случае с self-hosted Kubernetes, — сложная настройка автомасштабирования. Оно потребуется, чтобы кластер всегда был готов к любой нагрузке и новые ноды подключались и отключались по необходимости. Эта проблема отчасти схожа с обеспечением отказоустойчивости. К8s предоставляет хорошие возможности автомасштабирования приложений, а вот в отношении самого кластера эту возможность еще нужно реализовать. И для этого снова придется развернуть дополнительные серверы и постоянно поддерживать их в рабочем состоянии.
 
* * *
Итак, при самостоятельном развертывании и эксплуатации кластера Kubernetes перед компанией встает ряд проблем:
  • нужна команда специалистов, которые хорошо знают технологию;
  • в кластере необходимо настроить мониторинг, сбор логов, балансировку нагрузки и многое другое;
  • требуется развернуть систему хранения данных и обеспечить ее интеграцию с кластером;
  • чтобы обеспечить отказоустойчивость кластера, понадобятся дополнительные серверы или виртуальные машины, а значит, дополнительные затраты;
  • еще одна статья расходов — содержание резервных серверов или виртуальных машин для масштабирования кластера.
Тенденция отдавать непрофильные задачи сторонним экспертам, получая готовую инфраструктуру и инструменты для разработки, не обошла стороной и К8s. Альтернативой self-hosted Kubernetes стал Managed Kubernetes (KaaS). Kubernetes как услуга позволяет развернуть кластер за 10 минут, а его обслуживанием и обеспечением отказоустойчивости будет заниматься провайдер. Управляемый сервис открывает доступ к совместимым хранилищам, а дополнительные ресурсы подключаются нажатием одной кнопки. Именно за Managed Kubernetes — будущее процессов разработки: компании имеют возможность сконцентрироваться на создании продуктов, не тратя ресурсы на поддержку кластеров.
 
Автор: Дмитрий Лазаренко, директор по продукту, Mail.ru Cloud Solutions
Источник: Иксмедиа

Приглашаем на конференцию для директоров по маркетингу и PR-руководителей ИТ-компаний 

5 июня 2024

На мероприятии встретятся директора по маркетингу и PR-руководители крупных российских ИТ-компаний.

 

Экс-редактор Comnews присоединился к команде iTrend

30 мая 2024

На позицию руководителя проектов коммуникационного агентства iTrend вышел Денис Шишулин – ранее многолетний выпускающий редактор издательской группы ComNews, одного из самых авторитетных ИТ-изданий в России. В iTrend Денис будет отвечать за стратегическое руководство ряда PR-проектов с ИТ-компаниями, оперативное взаимодействие со СМИ, координацию работы команд, а также за качество проектов, которыми руководит в агентстве.

 

iTrend — в числе топ-агентств России по версии «Рейтинга Рунета»

28 мая 2024

Опубликованы итоги ранкинга коммуникационных агентств от «Рейтинга Рунета–2024». iTrend занял лидирующие места в ключевых для агентства срезах — PR в ИТ-отрасли, SMM в ИТ-отрасли, PR и SMM на аудиторию b2b enterprise, PR-аналитика, PR первых лиц и др.

 

Исследование iTrend: зарплата для ИТ-специалистов — не решающий фактор при выборе работодателя

23 апреля 2024

Эксперты коммуникационного агентства iTrend провели исследование, в рамках которого проанализировали критерии выбора работы, а также медиапредпочтения более 300 высокоуровневых специалистов из крупных российских ИТ-компаний.

 

Команда iTrend начала работу с Институтом iSpring

19 апреля 2024

Институт iSpring — частный ИТ-вуз нового поколения. Он был основан в 2021 году в Йошкар-Оле российским предпринимателем и основателем международной ИТ-компании iSpring Юрием Усковым.

 
Все новости iTrend