Разместить здесь вашу рекламу


Зачем мигрировать на Managed Kubernetes и с чем придётся столкнуться

Моя цель - предложение широкого ассортимента товаров и услуг на постоянно высоком качестве обслуживания по самым выгодным ценам.

Привет, Хабр! В прошлом году компания Statista провела опрос среди разработчиков, специалистов по эксплуатации и безопасности, спросив у них: «Используете ли вы Kubernetes?» 46% респондентов, которые занимали разные должности в крупных и небольших компаниях из разных отраслей, ответили положительно. При введении Kubernetes компания столкнётся с двумя возможными путями: самостоятельное развёртывание кластера или Managed Kubernetes. В этой статье расскажем о последнем варианте, его плюсах и минусах и об общем алгоритме действий для его реализации.

Почему стоит выбрать Managed Kubernetes

На первый взгляд кажется, что self-hosted Kubernetes лучше, чем Managed Kubernetes, по ряду рациональных факторов: дешевле, надёжнее и более настраиваемый. Да и что уж греха таить, эмоции тоже оказывают влияние на выбор — всё-таки свой кластер. Однако за этими плюсами скрываются сложности. 

Квалифицированные специалисты

Первое, с чем столкнётся компания при желании создать Self-Hosted кластер, — это дефицит квалифицированных кадров. Kubernetes — это, мягко говоря, сложная технология, которая требует квалификации не только на старте проекта, но и при его поддержке. Не получится прочитать документацию с официального сайта и сразу ринуться в бой. Профессионалов, которые действительно разбираются, на рынке ну прям очень немного. Компания может уткнуться в HR-барьер: своих специалистов не хватает, а имеющиеся кадры, скорее всего, придётся взращивать годами. Свой кластер Kubernetes создают крупные компании, для которых найти квалифицированных кандидатов среди сотрудников или на просторах профильных ресурсов не проблема.

В случае использования Managed Kubernetes компания не избавится от необходимости в квалифицированных сотрудниках, но сможет снизить в них потребность. Провайдер берёт на себя ряд обязательств, связанных с администрированием Kubernetes, позволяя заказчику сконцентрироваться на разработке и деплое. 

Архитектура в облаке

Вопрос архитектуры кластера — основополагающий, поскольку определяет степень отказоустойчивости и масштабируемости. Self-hosted кластеры разворачивают как на физических серверах, в собственном ЦОДе, так и облаке — это не нужно путать с Managed Kubernetes.

У физического сервера есть плюсы, такие как скорость работы локальных дисков. К тому же своё железо, буи купленное, и арендованное, в большинстве случаев быстрее окупается и предоставляет больший доступ к тонкой настройке. Но физическое оборудование приходится обслуживать, а его его сложно масштабировать. Хотите добавить новый под, но вычислительных ресурсов не хватает → покупайте новый сервер. Облако нивелирует недостатки физического сервера —  проще добавить вычислительной мощности для отказоустойчивости или новых подов. Но облако всё равно не решает проблемы с недостатком кадров.

При выборе Managed Kubernetes по умолчанию используется облако и его преимущества. Так решается вопрос с серверами, а первоначальная настройка кластера и подключение к нему систем хранения данных становится проще. 

Через интерфейс, API и другие инструменты пользователь конфигурирует сервер, как ему нужно. К слову, обновление Kubernetes, одну из самых рискованных процедур, провайдер берёт на себя.

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

Алгоритм: как мигрировать на Managed Kubernetes

Конкретные действия для миграции на Managed Kubernetes зависят от первоначального состояния проекта. Есть несколько типичных сценариев:

  • Приложения монолитны, контейнеризация не использовалась.

  • Приложения построены на микросервисной архитектуре:

    — контейнеры не использовались,

    — контейнеризация использовалась, но не в Kubernetes,

    — уже имеется кластер на Kubernetes.

Процесс миграции можно разделить на четыре основных этапа: подготовка кода, создание кластера, создание helm-чартов и миграция в облако.

Подготовка кода

Контейнеры плохо работают с монолитными приложениями. Поэтому первый этап миграции — рефакторинг кода и переход от монолитной архитектуры к микросервисной с учётом особенностей работы Kubernetes. Проект необходимо научить работать:

  • с локальными хранилищами данных (для stateful приложений),

  • с локальными кешами,

  • в несколько реплик.

Оптимальный вариант — разместить в Kubernetes не весь проект, а его части, как stateless приложений.

Создание кластера

Исходя из требований проекта, необходимо подобрать конфигурацию кластера и создать его в облаке. Важные моменты:

  • географическая доступность,

  • количество вычислительных ресурсов,

  • мониторинг кластера,

  • политики безопасности,

  • число кластеров,

  • постоянное хранилище данных.

Helm charts

Если на проекте не использовались оркестраторы или использовались, но отличные от Kubernetes, то helm-чарты создают с нуля. Если использовались Kubernetes-платформы, такие как OpenShift или Rancher, то helm-чарты подгоняют под Kubernetes.

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

Миграция

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

  • нагрузочное тестирование,

  • функциональное тестирование,

  • проверка производительности,

  • аудит безопасности кластера,

  • интеграционное тестирование.

После проведения подготовки и тестирования можно переходить к миграции. По сути, это процесс применения новых helm-чартов к созданному кластеру. Это можно осуществить как вручную, так и с помощью конвейера CI/CD. По итогу проверки работоспособности кластер будет готов к работе.

В целом, Managed Kubernetes подойдёт малому и среднему бизнесу под малонагруженные проекты, которые не будут страдать из-за недостатка настройки. В этом случае Managed Kubernetes поможет сэкономить деньги на поиск сотрудников, закупку оборудования и время на создание инфраструктуры.

Общие минусы Managed Kubernetes:

  • зависимость от провайдера;

  • техподдержку, которая может быть занята другими проектами;

  • ограничения, например на количество сетевых соединений;

  • ограниченная настройка Kubernetes. 

Источник: https://habr.com/ru/company/netologyru/blog/673112/


Интересные статьи

Интересные статьи

Если поинтересоваться у людей вокруг, слышали ли они что-нибудь о Биткоине, то наверняка каждый ответит: "о да, конечно". Уже несколько лет криптовалюты подгоняются под р...
Придя в компанию Мегафон как iOS-разработчик, Валентин Чернов попал в сегодняшний основной тренд — переход приложений в оффлайн. Основная работа Валентина — разработка главного приложения...
Вам приходилось сталкиваться с ситуацией, когда сайт или портал Битрикс24 недоступен, потому что на диске неожиданно закончилось место? Да, последний бэкап съел все место на диске в самый неподходящий...
Недавно общался со своим знакомым. Парнишка учится Android разработке и обладает довольно крепким багажом знаний. Я ему задал вопрос: «Почему ты до сих пор не ходишь на собеседования? Ты бы у...
«Битрикс» — кошмар на костылях. Эта популярная характеристика системы среди разработчиков и продвиженцев ныне утратила свою актуальность.