Технологию применяют для автоматизации управления множеством контейнеров, в которые упакованы современные приложения. Возможность включать и выключать контейнеры, увеличивать и уменьшать размер кластера в зависимости от нагрузки на ИТ-инфраструктуру обеспечивает высокую стабильность работы приложений. Поэтому интерес к 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, сетевые политики, мониторинг, авторизация пользователей и ограничение привилегий.