Всем привет!

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



Time to market — скорость вывода обновлений на рынок — сегодня становится ключевым фактором эффективности ИТ-решения. Продукт нужно дорабатывать каждый день: добавлять в него новые функции и модули, поддерживать документацию и скрипты в идеальном состоянии. При этом онлайн-системы должны работать бесперебойно и обновляться не затрагивая пользователей.

На страже незаметного непрерывного обновления стоят микросервисы, контейнеры и инфраструктура для их оркестрации – Kubernetes (или K8S, его именуют в технических кругах).

Как Kubernetes обеспечивает непрерывное обновление систем

Главная задача при обновлении ИТ-решения состоит в том, чтобы обеспечить его корректную работу после переноса со среды разработки на продуктовую платформу. А также в бесперебойной работе системы на момент обновления продукта.

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

Незаметно для пользователей обновления проходят за счет дублирования контейнеров и последовательного перенаправления пользователей с одного на другой. Для управления контейнерами (оркестрации) мы используем Kuberenetes. В конечном счете он облегчает управление решением, развертывание и обновление, мониторинг работы и отладку при сбоях.

Когда компании нужен Kubernetes

Компании пора задуматься о переходе на платформу Kubernetes, когда:

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

Kubernetes также нужен вам как инструмент автоматизации и стандартизации работы с решением, если в дополнение к сказанному выше:

• Между ИТ-системами компании нет изоляции и каждая может оказывать влияние на другую.
• Если необходимо каждый раз писать отдельный скрипт для связи с параметрами сервера, на котором разворачивается система, то есть масштабировать этот процесс можно только руками.
• В команде разработки есть ключевые люди — носители «тайного знания» о проекте или системе, и они кажутся уникальными и незаменимыми.

По сути, переход на Kubernetes – это необходимость для компаний, которым нужно поддерживать информационные системы онлайн в режиме 24/7.

Почему именно Kubernetes

Kubernetes — не единственная альтернатива для обеспечения непрерывной интеграции и развертывания (CI/CD). Но именно Kubernetes стал отраслевым стандартом в управлении системами, которые требуют высокой доступности.

Для нас как разработчика решающими аргументами в пользу Kubernetes являются следующие:

• Платформа ориентирована на приложения, а не инфраструктуру.
• Kubernetes удобен как для работы с одним дата-центром, так и с несколькими, распределенными по разным городам.
• Легкая поддержка решения за счет понятной документации и активного сообщества.
• Гибкая конфигурация разных приложений, безопасное распределение трафика.
• Поддержка Docker-контейнеров.

Какие преимущества дает Kubernetes бизнесу

• Гибкая настройка и автоматизированный процесс обновлений
  Вы сами определяете, какую часть системы запустить в промышленную эксплуатацию. Kubernetes позволяет сделать короткий цикл релиза. Все операции — от исходного кода системы до релиза в продуктовую среду — проходят в автоматическом режиме. Вам не нужна команда инженеров, чтобы система заработала. Текущие обновления не затрагивают работоспособность системы и могут проводиться в любое удобное для разработчиков время.
• Размещение и масштабирование системы
  Система может быть размещена как на вычислительных мощностях заказчика (либо в дата-центре), так и у любого облачного провайдера, например, Amazon или Azure. Можно легко обеспечить любой уровень производительности и отказоустойчивости за счет масштабирования кластера.
• Стандартизация и самодокументация
  Решение не требует инструкций. Оно самодокументировано и уже сразу автоматически упаковано в единицу использования — контейнер. Мы описываем конфигурацию в Kubernetes в виде плана/схемы. Не пишем скрипты, которые готовят окружение, как это было до Kubernetes. Вместо этого мы передаем в Kubernetes информацию (схему), как решение должно работать. А он сам реализует эту схему.
  
  Разработчики теперь пишут приложение для работы в контейнере. DevOps-инженеры пишут схему, как приложение должно работать в контейнере, и Kubernetes cам выполняет задачи по построению решения.
  
  Технология работы с Kubernetes стандартизована. Вам будет легко обучить нового сотрудника вашей системе релизов или передать систему новому подрядчику.
  
  Итоговое описание конфигурации, которую создает Kubernetes, также выступает документацией к системе. Из названий сразу понятно, какие параметры настроены и для чего они.
  
  За счет этого платформа Kubernetes в целом универсализирует релизы, апдейты и выпуск приложения.

• Безболезненное тестирование «на живую»
  Изменился процесс тестирования решения. Разработчики могут по требованию создавать окружения, идентичные продуктовым, для автоматизированного тестирования. А общие логи работы приложения и работы Kubernetes с приложением помогают еще быстрее расследовать проблемы и находить ошибки.

Чего потребует от бизнеса процесс перехода на Kubernetes

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

• Архитектура решения
  С точки зрения продукта переход возможен, только если система реализована или обновлена до микросервисной архитектуры на базе сервисов, которые могут быть упакованы в контейнеры (stateless сервисы).
• Процесс разработки
  С точки зрения процесса разработки переход прежде всего предполагает изменение мышления. Совершенно исключаются любые ситуативные доработки и «костыли», добавляемые в последний момент. Разработчик ИТ-решения может работать только как одна команда, которая изначально делает изначально тестируемый, поддерживаемый, упаковываемый в контейнеры, декомпозируемый продукт. Всё должно строиться логично от первой строчки кода до эксплуатации.
• Процесс обновления
  Еще на этапе разработки архитектуры приложения нужно думать о том, как обновлять решение без остановки. И сразу понимать, как вы будете обновлять базы данных, API, как логично поддерживать несколько версий приложения с учетом того, что во время обновления с системой работают люди и они могут попадать на разные версии.
  
  И еще один поворот мышления связан с тем, что при переходе на Kubernetes инфраструктура начинает работать в неизменяемом режиме (read only), и чтобы обновить систему, нужно создать новые версии образов приложения и указать Kubernetes использовать новую версию, а старую версию он впоследствии выключит и удалит сам.

Так что доработок системы и изменения технологии работы не избежать. Переезд не будет быстрым. Но изменить парадигму вам будет нужно всего один раз.

Кейс. Как мы переводили на Kubernetes микросервисную систему

Мы эксплуатируем в продуктовой среде высоконагруженное решение на микросервисной архитектуре, которое в день пропускает более 300 тысяч транзакций, а в моменты пиковой нагрузки — 60-80 тысяч в час. Мы регулярно обновляем продукт, также бывают и более срочные релизы, которые раньше требовали приостановить работу системы или части ее функционала на некоторое время.

В продуктовую среду мы выходили без K8S, но систему разрабатывали изначально с прицелом. Перевод решения на Kubernetes занял 6 недель. Мы двигались в следующих направлениях:

1) Настройка конвейера развертывания

a. Настройка конвейера постоянной сборки, тестирования и обновления приложения (CI/CD) в тестовых окружениях.
b. Настройка непрерывного обновления в промышленном окружении.
c. Подготовка и конфигурация максимально приближенной к промышленному окружению среды (препрод). Мы развернули и протестировали кластер рядом с текущими виртуальными машинами.
d. Разработка плана миграции в промышленное окружение.

Итак, вроде бы все просто, у нас есть конвейер CI/CD для всех сред и можно переключать, но еще рано!

2) Подбор конфигурации кластера

Пару недель мы потратили на подбор самой стабильной конфигурации компонентов и версий кластера Kubernetes: операционная система + Docker + Kubernetes.

Мы протестировали 3 разных конфигурации операционных систем (Ubuntu, CentOS, Oracle Linux последних версий). На каждой операционной системе проверили по 2 разных версии Docker и Kubernetes – ту, что поставлялась в последних версиях стандартных пакетов операционной системы, и самую свежую версию от производителя. В итоге наибольшую стабильность показали все же конфигурации из стандартной поставки Oracle Linux, и мы остановились на них.

3) Настройка параметров контейнера

Еще некоторое время потратили на тюнинг параметров контейнера – настроили требования к памяти, к диску, к процессам.

И только после того, как мы сделали все это и протестировали разные параметры функционирования системы (стабильность, отказоустойчивость и другие) в препроде при нагрузках, приближенных к боевым, и система отработала стабильно, мы перешли к финальному этапу – миграция.

Дальше все было просто.

День Ч. Миграция

Для боевой миграции выбрали время с минимальной нагрузкой системы: минимальное количество пользователей и отсутствие повышенной нагрузки по графику внутренних работ алгоритмов системы.

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

Жизнь с Kubernetes

Теперь процесс обновления не затрагивает работоспособность системы, может проводиться в любое удобное для разработчиков время и выглядит следующим образом:

1. Разработчики сделали доработку, протестировали ее, отправили код в публикацию.
2. Прошла автоматическая сборка кода, упаковка в докер-образы и публикация в приватный докер-репозиторий.
3. Kubernetes автоматически поднимает новые версии сервисов, проверяет, что сервисы работают корректно, переключает пользователей на использование новых версий сервисов, останавливает работу старых версий и удаляет их из кластера. Обновление состоялось.

Резюмируя наш опыт

Kubernetes нужен вам, если:

1. Требуется обеспечить высокую доступность системы.
2. Система динамично развивается, и вам нужно с закрытыми глазами доставлять изменения для продуктовой среды.
3. Вы хотите работать как единая команда от кода до продуктовой среды.
4. Вы делаете динамичную, развивающуюся систему, которую будете эксплуатировать годами.

Kubernetes — это «дорого», так как вход в технологию потребует:

1. Изучения разработчиками сопутствующих технологий.
2. Пересмотра процессов проектирования, разработки, развертывания, тестирования, управления окружениями.
3. Опыт в эксплуатации самого Kubernetes: теперь вам нужно следить не только за своей системой, но и за прикладными сервисами Kubernetes.

Окупить Kubernetes очень быстро:

1. Процедура обновления системы значительно более простая и быстрая. Разработчики освобождены от целого блока трудозатрат.
2. Каждый новый специалист будет входить в проект уже по рельсам.
3. Конвейер будет прозрачен и автоматизирован.
4. Опыт будет повторяем вашей командной для других систем.
5. Вы будете обновлять систему, не выводя ее из эксплуатации, а значит, не останавливая бизнес.

P.S. Практический совет: разделите вход в технологию на два этапа: разработку системы с правильной микросервисной архитектурой и перевод ее под управление K8S. Тем самым, переход под Kubernetes не превратится в глобальный рефакторинг.