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

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

Развертывание кластера Kubernetes, на первый взгляд, не самая сложная задача. В распоряжении компаний имеются обширная официальная документация и специально разработанные инсталляторы, в числе которых можно назвать Kubespray и Kubeadm. И, вполне вероятно, в ИТ-службе крупной компании найдется инженер, способный разобраться в этих ресурсах и применить их. Однако Kubernetes требует внимания не только во время развертывания, но и в процессе эксплуатации. А сложности непременно возникнут — через пару недель или месяц после запуска. Причины нестабильности могут быть самыми разными: от проблем с дисками до неконтролируемого создания системой новых pod’ов («кирпичиков», из которых складывается кластер К8s).

Для того чтобы справиться с этими сложностями, придется нанимать специалиста, который будет заниматься исключительно поддержкой кластера Kubernetes. Со временем, если речь идет о масштабной инфраструктуре, потребуется расширить штат. За короткий срок нужно будет сформировать команду инженеров, которые не только хорошо знакомы с К8s, но и способны развивать кластер, дополнять его инструментами, позволяющими получить от технологии максимум пользы. Все это ограничивает аудиторию «доморощенного» (self-hosted) Kubernetes крупными компаниями, перед которыми не стоит задача экономить ресурсы и которые имеют возможность выделить сотрудников для обслуживания кластера.

Годами ИТ-службы компаний формировали свои цифровые платформы как единую экосистему сервисов. Развернув на собственных мощностях Kubernetes, они столкнутся с тем, что теперь им придется поддерживать две совершенно разные экосистемы. Увы, К8s не вписывается в корпоративные цифровые миры и требует для корректной работы отдельных инструментов.

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

Использование систем хранения данных в Kubernetes — еще одна серьезная проблема. Дело в том, что Kubernetes изначально разработан для stateless-приложений, которые не хранят данные внутри контейнеров. Для того чтобы интегрировать с кластером stateful-приложения, предстоит подключить внешние хранилища, в частности persistent volumes, позволяющие приложению работать без изменения его логики. Такие хранилища подключаются внутрь контейнеров как локальные директории, давая приложению возможность хранить данные «под собой». Это нетривиальная задача, которая потребует отдельного инженера или даже команды специалистов, обладающих профильными навыками.

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

Кроме того, в Kubernetes есть встроенный механизм самовосстановления. Если из строя выходит один из серверов, то все процессы, ранее работавшие на нем, автоматически перезапускаются на других нодах кластера. Но это подразумевает резервирование ресурсов. Выполнить такое требование можно далеко не всегда, ведь на обычных bare metal-серверах (на «голом железе») сложно создавать отказоустойчивые конфигурации. 

Еще одна проблема, с которой можно столкнуться в случае с self-hosted Kubernetes, — сложная настройка автомасштабирования. Оно потребуется, чтобы кластер всегда был готов к любой нагрузке и новые ноды подключались и отключались по необходимости. Эта проблема отчасти схожа с обеспечением отказоустойчивости. К8s предоставляет хорошие возможности автомасштабирования приложений, а вот в отношении самого кластера эту возможность еще нужно реализовать. И для этого снова придется развернуть дополнительные серверы и постоянно поддерживать их в рабочем состоянии.

* * *

Итак, при самостоятельном развертывании и эксплуатации кластера Kubernetes перед компанией встает ряд проблем:

Тенденция отдавать непрофильные задачи сторонним экспертам, получая готовую инфраструктуру и инструменты для разработки, не обошла стороной и К8s. Альтернативой self-hosted Kubernetes стал Managed Kubernetes (KaaS). Kubernetes как услуга позволяет развернуть кластер за 10 минут, а его обслуживанием и обеспечением отказоустойчивости будет заниматься провайдер. Управляемый сервис открывает доступ к совместимым хранилищам, а дополнительные ресурсы подключаются нажатием одной кнопки. Именно за Managed Kubernetes — будущее процессов разработки: компании имеют возможность сконцентрироваться на создании продуктов, не тратя ресурсы на поддержку кластеров.

Заметили неточность или опечатку в тексте? Выделите её мышкой и нажмите: Ctrl + Enter. Спасибо!