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

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

 

img

Ошибка 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, сетевые политики, мониторинг, авторизация пользователей и ограничение привилегий.

Ссылка на источник

Больше не нужно искать и обзванивать диджитал-агентства!
Создайте тендер и получите предложения по цене и срокам от лучших веб-студий Украины.
Это бесплатно и займет 2 минуты. В каталоге 1500+ диджитал-агенств, готовых помочь в реализации ваших задач. Выберите и сэкономьте до 30% времени и бюджета!
Создать тендер
Подписка на рассылку
Подпишитесь на рассылку новостей и получите:
5% скидку на все услуги веб студий или 10% на рекламу.
Популярные статьи в разделе Разное
Разное
Разное
30-07-2021
На Большом адронном коллайдере открыли новую форму материи IT Рейтинг RU
Коллаборация LHCb, одного из экспериментов Большого адронного коллайдера, куда входят представите...
Разное
Разное
28-07-2021
Вышла третья бета-версия операционной системы Haiku IT Рейтинг RU
После года разработки опубликован третий бета-выпуск операционной системы Haiku R1. ...
Разное
Разное
21-07-2021
Google удалила из поисковой выдачи сотни тысяч ссылок, чтобы удовлетворить российский закон о VPN IT Рейтинг RU
За последние два года Google удалила несколько сотен тысяч ссылок в рамках требования закона о VP...
Bug