Пять ошибок при внедрении Kubernetes

Логотип компании
06.05.2021Автор Дмитрий Лазаренко
Пять ошибок при внедрении Kubernetes
Kubernetes (K8s) позволяет компаниям из разных отраслей вывести разработку приложений на новый уровень.

Технологию применяют для автоматизации управления множеством контейнеров, в которые упакованы современные приложения. Возможность включать и выключать контейнеры, увеличивать и уменьшать размер кластера в зависимости от нагрузки на ИТ-инфраструктуру обеспечивает высокую стабильность работы приложений. Поэтому интерес к Kubernetes стремительно растет. Например, по итогам 2020 года объем затрат заказчиков на облачный сервис от MCS Kubernetes aaS вырос в 7 раз.

Переход на Kubernetes своими силами может вызвать определенные сложности. И дело не только в нехватке квалифицированных специалистов. Предстоит провести серьезные преобразования в масштабах всего ИТ-отдела.

О чем следует подумать до начала проекта и какие нюансы могут возникнуть в процессе миграции, рассказывает Дмитрий Лазаренко, директор по продукту облачной платформы Mail.ru Cloud Solutions.

Kubernetes — технология, которая достигла пика популярности в 2020 году. Она помогла компаниям в условиях неопределенности быстрее разрабатывать и выводить на рынок новые ИТ-продукты и сервисы, сохранять их доступность во время пиковых нагрузок. Интерес к контейнеризации и системам оркестрации контейнеров будет расти. При этом компании, особенно Enterprise-сегмента, будут отказываться от самостоятельного развертывания K8s в пользу Managed Kubernetes. Это экономит трудозатраты на миграцию и поддержку решения, позволяя сосредоточиться непосредственно на разработке и обновлении приложений.

Ошибка 1: пытаться перевести на Kubernetes все проекты

Kubernetes — сложная технология, ее внедрение требует усилий и затрат. Технология выгодна тем компаниям, где постоянно ведется разработка приложений, регулярно выпускаются новые релизы, а высокая нагрузка на инфраструктуру предъявляет к ПО повышенные требования. Как правило, это крупные компании из сферы ретейла, финансов, логистики, ИТ.

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

Ошибка 2: не рассчитать возможности своей команды

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

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

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

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

Ошибка 3: игнорировать DevOps

Готовить к переходу на Kubernetes нужно не только команду администраторов, но и процессы разработки. Обязательным условием здесь является внедрение методологии DevOps, которая затрагивает всю разработку кода. Без этого Kubernetes будет просто бесполезен.

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

Ошибка 4: переложить ответственность на облачного провайдера

Использование облачного сервиса K8s aaS (Kubernetes-as-a-Service) позволит избежать части проблем. Например, администрированием технологии в рамках такого сервиса, поддержкой и обновлением занимается облачный провайдер. Это позволит заказчику ограничиться наймом только тех специалистов, которые будут заниматься эксплуатацией кластера. Они необходимы, несмотря на то, что кластер развертывается в облаке всего за 10 минут.

Действительно, провайдеры стремятся к тому, чтобы обеспечить и Kubernetes, и приложения в нем необходимыми надстройками. Но никто не может гарантировать 100-процентной доступности сервиса. В SLA провайдера, как правило, прописан показатель в 99,95%, а это означает, что допустимы 5 часов простоя сервиса в течение года. Для многих компаний это может быть критичным, и, чтобы предотвратить недоступность сервиса, необходимо балансировать нагрузку на кластер и организовывать его репликацию.

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

Ошибка 5: не уделить внимания безопасности

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

Однако в конфигурации «по умолчанию» Kubernetes оставляет незакрытые уязвимости, способные привести к инцидентам. Известен случай, когда кластер разработчиков видеоплеера был использован для майнинга криптовалюты.

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

Похожие статьи