Чтобы сделать ваш проект таким же отказоустойчивым и масштабируемым, как, например, Spotify, нужно мигрировать в Kubernetes. Вокруг него много споров, но на текущий момент это один из лучших инструментов для контейнеризации больших проектов. И, надо сказать, задача переехать в него не самая простая.
Наши специалисты уже накопили достаточно опыта в работе с проектами, которые на разных этапах нуждались во внедрении или поддержке Kubernetes. Но чтобы грамотно внедриться в столь масштабный процесс из любой точки, важно не просто спросить команду клиента, что уже готово или что требуется от нас. Нужно иметь представление обо всех этапах работы, дабы не упустить ничего важного.
Если на вашем проекте планируется внедрение контейнеризации Kubernetes, предлагаем нашу статью для ознакомления с основными этапами этого процесса. Так вы будете понимать, к чему быть готовыми и сколько времени это займёт. В этой статье команда Initlab поделится опытом миграции различных проектов в Kubernetes и даст пошаговый план грамотного переезда.
11 этапов миграции
Любые описания таких сложных процессов лишь «пример в вакууме». Мы составили наш список, исходя из собственного опыта и приводим его как некий идеальный с нашей точки зрения вариант. Успешная миграция должна проходить по следующим этапам.
1. Аудит и документирование текущей серверной инфраструктуры проекта. На этом этапе мы определяем, какие приложения и на каких серверах запускаются, какой стек технологий используется. В случае, если нас приглашают на проект с уже запущенным процессом перехода на Kubernetes, мы должны оценить количество выполненных работ и готовых скриптов, которые можно использовать повторно. Результатом аудита является документ с описанием текущей инфраструктуры и взаимосвязей, а также оценкой состояния процесса миграции.
2. Формулирование требований к масштабированию и отказоустойчивости приложений. Здесь мы выясняем, требуется ли запуск дополнительных экземпляров приложений при увеличении нагрузки на систему. Помимо этого, для нас важно понимать, требуется ли запуск резервных копий приложений для повышения надёжности системы.
Например, у нас есть интернет-магазин, на который в чёрную пятницу ложится очень большая нагрузка. Чтобы сайт не тормозил и не падал, нам понадобится автоматическое развёртывание дополнительных веб-серверов, которое как раз можно реализовать при помощи Kubernetes.
3. Подготовка приложения к запуску в кластере Kubernetes. На этом шаге мы проверяем, соответствует ли приложение требованиям 12-факторного приложения. Мы описали это понятие с техническими подробностями на примере запуска Drupal в Kubernetes в этой статье. При необходимости дорабатываем и завершаем настройку приложения для соответствия требованиям. На этом этапе нашим DevOps-инженерам нужно знать ответы от команды разработки на следующие ключевые вопросы:
- работает ли приложение без сохранения состояния? (stateless)
- хранит ли состояние взаимодействия с пользователем? (stateful)
Для stateful:
- как организована работа с сессиями пользователей?
- каковы зависимости?
- как приложение настраивается и как запускается?
4. Контейнеризация каждого приложения. Создаём Docker-контейнеры. По возможности используем готовые базовые образы.
5. Проектирование и внедрение системы сбора логов и мониторинга приложений и кластера. В этот момент нужно решить, нет ли необходимости организовать сбор логов централизованно.
6. Автоматизация CI/CD. Она необходима, чтобы разработчики могли писать код приложений, который, по мере изменений, будет оперативно доставляться в кластер, благодаря чему соответствующие приложения смогут корректно собираться и перезапускаться. Иными словами, чтобы любые изменения и коммиты разработчиков вступали в силу при помощи автоматизации.
7. Подготовка сред и миграции, создание манифестов Kubernetes. На данном этапе выполняется настройка кластера Kubernetes, настройка необходимых для работы приложения СУБД, ПО для очередей и другого ПО. Для каждого сервиса подготавливается манифест для деплоя его в кластер Kubernetes. Выполняется запуск и тестирование деплоев всех сервисов и работы приложения.
8. Тестирование под нагрузкой, тестирование в случае сбоев. Работает ли кластер так, как он спроектирован? Выдерживает ли текущая инфраструктура необходимую нагрузку/количество обращений? На этом этапе тестируется отказ в работе нод кластера, выясняется, сколько по времени займёт перенос подов на рабочую ноду, а также проверяется отказ одного из нод в кластерах СУБД, очередей и подобного ПО.
9. Миграция приложений и запуск. Выполняется актуализация сервисов путем запуска деплоев для последних версий сервисов, актуализируются данные в СУБД и файлы во внешних хранилищах. В этом случае требуется приостановка работы приложения на время актуализации, чтобы не рассинхронизировались данные на старом и новом стенде. Также есть возможность переключения работы приложения без приостановки, когда на новом стенде настраиваются реплики для СУБД. В момент переключения они переводятся в мастер-роль. Затем выполняется переключения продакшн доменов на новый кластер.
10. Финальное тестирование после запуска. После запуска приложения на основном домене, тестировщики проводят полноценное тестирование его функционала с целью поиска ошибок и дальнейшего их устранения. В случае, если они будут слишком серьёзными и помешают дальнейшей работе приложения, их исправление может занять продолжительное время. В таком случае, вероятнее всего, придётся переключиться обратно на старый стенд и исправить найденные ошибки.
11. Мониторинг и поддержка кластера Kubernetes. Мониторинг — регулярная проверка работоспособности всех компонентов кластера Kubernetes: системных, а также запущенных подом с сервисами. Проверяется их работа, а также количество рестартов. В случае, если сервис часто перезагружается, это говорит о проблемах, которые необходимо устранить. Также выполняется мониторинг всего дополнительного ПО для работы приложения — СУБД, очередей, хранилищ и т.д.
Поддержка кластера — обработка проблем, найденных при помощи мониторинга. В развивающемся проекте — добавление новых сервисов: контейнеризация, написание манифестов, написание CI/CD, деплой. А также интеграция тестирования в процессы CI/CD, интеграция проверок на уязвимости в коде сервисов и docker-образов.
Канареечные релизы
Чтобы не бояться масштабных перемен при миграции приложений и запуске, Kubernetes позволяет делать развёртывание и откаты сервисов новых версий. Это означает, что мы можем совершать так называемые канареечные релизы — частично запускать новую версию и переводить часть пользователей на неё. Это помогает оценивать изменение нагрузки, отслеживать ошибки, контролировать состояние проекта и в случае, если всё идёт хорошо, плавно продолжать перевод на новую версию.
При этом данный процесс автоматизирован. В случае критических неполадок можно также автоматически откатиться на предыдущую версию для исправления ошибок.
Наши кейсы
Разумеется, наш опыт не ограничивается тремя кейсами. Мы подобрали их для демонстрации вступления на проект на разных этапах.
Проект №1. Приложение для взаимодействия с автомобилем
Отрасль: приложение для автомобиля: управление, заправка, отслеживание маршрутов, штрафы и счета за парковку. Каждый функционал — отдельный сервис, который запускается в кластере.
Язык, платформа приложения:
- Node.js — фронт и бэк сервисы;
- Python — бэкенд;
- PHP (Laravel) — бэкенд.
Какие шаги проделали:
На старте работы с проектом все микросервисы запускались отдельно на одном-единственном сервере. В какой-то момент количество сервисов сильно увеличилось — их стало около 50, из-за чего стало сложно управлять ими.
Понадобилось:
- с нуля проектировать архитектуру, мигрировать и запускать проект;
- масштабировать некоторые микросервисы, чтобы ускорить обработку данных;
- осуществить переезд с одного облака на другое, который мы заодно связали с настройкой кластера;
- повышать отказоустойчивость, потому что все системы были в единичном экземпляре. Один сервер под приложение привёл к тому, что выход из строя любого сервера приводил к недоступности всего приложения. Поэтому был развернут кластер, где под сервисы выделен пул серверов, а также все системы (СУБД, очереди) развернуты в кластерном виде.
Также мы настроили мониторинг доступности при запуске сервисов в кластере. Он проверяет работоспособность сервисов и оповещает о проблемах в кластере. Миграция в кластер позволила гибко распределять ресурсы серверов под сервисы. Был выделен пул серверов, на которых запущены сервисы, и если какой-то из них начинает потреблять много ресурсов, происходит перераспределение сервисов на нодах так, чтобы остальные сервисы продолжали работать, а самый ресурсоёмкий сервис не мешал.
В кластере настроен CI/CD. Для каждого сервиса реализована проверка его работоспособности, а в случае обнаружения некорректного функционирования, выполняется его перезагрузка. Разработчикам стало проще: они могут вносить свои изменения в процесс запуска приложения.
Срок реализации: 6 месяцев.
Проект №2. Туристический портал
Отрасль: сервис для планирования путешествий
Язык, платформа приложения:
- Node.js — фронт и бэк сервисы;
- Java — бэкенд.
Какие шаги проделали:
Перед нами стояла задача: из существующего dev-а развернуть кластер для prod-а с учётом нагрузки и отказоустойчивости. Приложение было уже разработано.
Понадобилось:
- спроектировать архитектуру серверов и служб (СУБД, очереди, кэш) под prod;
- настроить отказоустойчивость СУБД, служб очередей, кэширования;
- настроить сервера под кластер k8s;
- настроить CI/CD для prod-а кластера.
В этом кейсе за отдельный функционал каждого микросервисного приложения отвечает разный сервис. Фронт — отдельный сервис, т.е. отображение, которое обращается к большому количеству сервисов бэка. На сайте могут быть условные отели, кинотеатры, самолёты в виде отдельных сервисов, которые, при взаимодействии через фронт, начинают обращаться к своему правильному сервису бэка. Обычно для приложений, которые разделяются на фронт и на бэк, а также при большом количестве бэкэнд-сервисов как раз используется Kubernetes.
Бэкэнд — это сервис, у которого нет графического интерфейса. Он отвечает на запрос текстом, из которого фронт строит итоговое отображение. Например, если нас интересует театр, бэк ответит массивом спектаклей с названиями, афишами и url-ами для бронирования.
Срок реализации: 6 месяцев.
Проект №3. Государственный портал
Отрасль: госзакупки
Язык, платформа приложения:
- Java
Какие шаги проделали:
Сервис «большие данные» в экосистеме портала предназначался для обработки данных, которые настолько секретны, что мы не можем на них сослаться. От предыдущих разработчиков нам был передан архив с кодом и скриптами развертывания.
Понадобилось:
- в первую очередь развернуть dev;
- затем развернуть prod;
- исправить скрипты развертывания, так как это всё разрабатывалось давно и версии софта и библиотек устарели в зависимостях сервисов.
- настроить CI/CD для автоматического деплоя.
В основном из проблем со сборкой сервисов долго разворачивался первый dev стенд, пока нас не связали с разработчиками и они не помогли собрать сервисы. Пришлось ставить свой репозиторий для mvn библиотек и собирать библиотеки, которые являются зависимостями в сервисах. После запуска мы исправляли конфигурации сервисов и настраивали интеграции между ними, а без знания проекта было очень сложно.
Затем prod развернули буквально за пару недель, так как всё было актуализировано и работало.
Срок реализации: 6 месяцев.
Ещё немного о сроках развёртывания и процессе запуска
Может показаться, что часть проектов нам досталась на полпути, но на самом деле все три кейса — это развертывание кластера с нуля. И хотя в двух случаях мы получили скрипты и код,
- в Проекте №1 были инфраструктурные сложности, он осуществлялся вместе с поддержкой проекта, из-за чего затянулся переезд;
- в Проекте №2 нужно было продумать и организовать архитектуру + процесс получился довольно долгим, потому что параллельно велась разработка и несколько месяцев добавляли сервисы и исправлялись текущие. К идеалу пришлось идти долго.
Если же все приложения контейнеризованы, то есть выполнены 5-10 шаги, по опыту больших данных, миграция готового рабочего проекта может занять около двух недель.
Иногда часть третьего пункта сделана заказчиком. То есть мы заходим на проект, проводим аудит готовых скриптов, аудит качества контейнеризации, но такое происходит нечасто — в основном работаем с нуля. Без погружения в проект нельзя быть уверенным в том, насколько хорошо всё уже работает и спрогнозировать, как процесс пойдёт в дальнейшем.
Запуск на девятом шаге, одном из самых ответственных, происходит в зависимости от архитектуры приложения. Если его можно разделить на части так, чтобы одна часть работала в одном месте, а другая в другом, то можно переносить частично и постепенно исправлять ошибки миграции.
Но если все сервисы представляют одно приложение и общаются между собой, как в Проекте №1, то переезд всего приложения осуществляется целиком. В этом случае очень важно, чтобы была возможность тестирования новой среды.
При миграции нам нужно актуализировать данные на новом кластере а потом переключить трафик на него. Есть случаи, когда можно это сделать без остановки — тогда нужно настраивать репликацию всех данных в новый кластер, а есть когда остановка нужна.
Заранее сказать, сколько времени займет миграция, очень сложно и ближе к невозможному. Проекты, на которых требуется внедрение Kubernetes в большинстве своём очень крупные, где нельзя всё продумать и предусмотреть. Особенно пока devops не знает нюансов приложения и что ему требуется для работы.
В случае, когда нас привлекают для всех этапов целиком, начиная с первого шага, заканчивая мониторингом и поддержкой, нам приходится плотно взаимодействовать с разработчиками, проводить аудиты, документировать систему приложений и проектировать кластер, при необходимости задействовать инфраструктурные сервисы initlab для мониторинга и CI/CD кластера Kubernetes или внедрять новые по требованиям заказчика.
Переходить в Kubernetes или нет?
Однозначного ответа на вопрос о переходе нет. С уверенностью можно говорить только о проектах с большими массивами данных и количеством приложений. С увеличением количества последних работоспособности серверов может начать не хватать и контейнеризация станет единственным выходом из положения. Тем, кто планирует расширяться и тем, кто уже на грани своих возможностей однозначно стоит рассмотреть вариант переезда в кластер Kubernetes, который работает на любых платформах.
Если вы планируете переезд проекта в кластер Kubernetes для масштабирования и повышения отказоустойчивости или вашему проекту нужна поддержка кластера k8s — обращайтесь к нам.
Источник: https://vc.ru/dev/782278-kubernetes-masshtabirovanie-rezervirovanie-etapy-i-sroki
Добавить комментарий