Облачные приложения и Kubernetes: основы Cloud Native

Поскольку облачные платформы, инфраструктура и инструментарий быстро развивались с момента первой публикации «Двенадцати факторов», а масштабные облачные миграции и развертывания сформировали сообщество разработчиков программного обеспечения, появилась расширенная методология под названием Cloud Native. Приложения Cloud Native (или просто облачные приложения) контейнеризованы, сегментированы на микросервисы и предназначены для динамического развертывания и эффективного запуска такими системами оркестровки, как Kubernetes.

Читайте также: Облачные приложения и Kubernetes: основы и тренды

Какие приложения считаются Cloud Native?

Для эффективного развертывания, запуска и управления в облачном приложении должны быть реализованы несколько основных методов  Cloud Native. Например, приложение Cloud Native должно:

  • Предоставлять конечную точку проверки работоспособности, чтобы системы контейнеризации и оркестровки могли проверять состояние приложения и реагировать соответствующим образом.
  • Постоянно публиковать данные логов и телеметрии, которые будут храниться и анализироваться такими системами, как Elasticsearch и Prometheus.
  • Корректно обрабатывать ошибки, чтобы система оркестровки могла восстановиться, перезапустив или заменив приложение новой копией.
  • Не требовать вмешательства человека для запуска и начала работы.

Чтобы стимулировать распространение основных методов  Cloud Native, а также поддержку и продвижение растущего Cloud Native Landscape, под эгидой Linux Foundation был создан фонд Cloud Native Computing Foundation (CNCF), который призван способствовать росту и развитию высококачественных проектов (например, Kubernetes). Среди других проектов, которые поддерживает CNCF, — Prometheus (система мониторинга и база данных временных рядов, часто развертываемая вместе с Kubernetes) и FluentD (сборщик данных и логов, часто используемый для реализации распределенного логирования в больших кластерах).

Согласно текущей документации CNCF определяет три базовых свойства, которые лежат в основе приложений Cloud Native:

  1. Упаковка приложений в контейнеры: контейнеризация.
  2. Динамическое планирование этих контейнеров: контейнерная оркестровка.
  3. Архитектуры программного обеспечения, которые состоят из нескольких небольших слабо связанных и независимо развертываемых сервисов: микросервисы.

Масштабирование с помощью Kubernetes на примере Snappy

Чтобы продемонстрировать преимущества реализации базовых методов Cloud Native, включая контейнеризацию и архитектуру микросервисов, мы рассмотрим простой пример: приложение для обмена фотографиями под названием Snappy, которое предоставляет базовые функции загрузки и обмена фотографиями между пользователями через веб-интерфейс.

В этой серии статей мы модернизируем Snappy таким образом:

  • Разделим бизнес-функции приложения на микросервисы.
  • Контейнеризируем различные части в портируемые и дискретно развертываемые компоненты.
  • Используем кластера Kubernetes для масштабирования и непрерывного развертывания этих stateless микросервисов.
Интернет
Монолит Snappy
Балансировщик нагрузки
API / WEB UI Уровень презентации
Монолит Snappy →→ Управление фото Управление пользователями Бизнес-логика
Адаптер базы данных Уровень БД
Хранилище объектов База данных Бинарный код / библиотеки / среда выполнения языка программирования
Операционная система

Виртуальный сервер

В этом монолитном приложении для обмена фотографиями Snappy мы видим: сначала веб-интерфейс, управление фотографиями и бизнес-функции управления объединяются в единую кодовую базу, где эти отдельные компоненты активируют друг друга посредством вызовов функций. Затем создается кодовая база, она тестируется и разворачивается как единое целое, которое можно масштабировать как горизонтально, так и вертикально.

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

Tags: ,