0%

Кто такой Deckhouse-разработчик: карта экосистемы

Уровень: beginner ~35 мин

Что нужно знать перед уроком

Ничего — это первый урок курса. Единственное ожидание: базовый опыт работы в терминале Linux/macOS (cd, ls, редактирование текстовых файлов) и общее представление о том, что такое контейнер (Docker или аналог). Если контейнеры вам не знакомы вообще — не страшно, к ним мы вернёмся подробно в M3 уроке 1, а пока достаточно понимать: контейнер — это упакованное вместе с зависимостями приложение, которое можно запустить где угодно одинаково.

Теория

Зачем нужен весь этот стек

Представьте, что вы написали веб-приложение и хотите, чтобы оно надёжно работало «в проде»: переживало падение сервера, автоматически обновлялось, масштабировалось при росте нагрузки, было доступно по человеческому доменному имени, безопасно хранило пароли от БД. Решать все эти задачи вручную — воспроизводить велосипед, который уже изобретён. Экосистема, которую вы изучаете в этом курсе, — это набор проверенных индустрией инструментов, решающих эти задачи по отдельности, но работающих как единое целое:

flowchart LR subgraph "Оркестрация workload'ов" K8s["Kubernetes\n(что запускать, где, сколько реплик)"] end subgraph "Платформа поверх Kubernetes" DH["Deckhouse\n(готовые модули: мониторинг, ingress, СУБД, backup...)"] end subgraph "Сборка и поставка" Werf["Werf\n(собрать образ + упаковать чарт)"] Nelm["Nelm\n(отрендерить чарт и применить в кластере)"] end subgraph "Что разрабатываете вы" App["Application\n(ваш пакет: templates + openapi + package.yaml)"] end App -->|"собирается"| Werf Werf -->|"публикует образы и чарт"| Registry["OCI Registry"] Registry -->|"устанавливается через"| Nelm Nelm -->|"создаёт ресурсы в"| K8s DH -->|"управляет"| K8s DH -->|"предоставляет модули, от которых зависит"| App

Дальше разбираем каждый слой этой схемы отдельно — подробно, но пока без практики (практика начнётся с урока 2).

Kubernetes — оркестратор контейнеров

Kubernetes (сокращённо K8s — «8 букв между K и s») — система оркестрации контейнеров с открытым кодом, изначально разработанная в Google, сейчас — проект Cloud Native Computing Foundation. Задача Kubernetes — управлять жизненным циклом контейнеризированных приложений на кластере серверов (узлов, node): решать, на каком узле запустить контейнер, перезапускать его при падении, распределять входящий трафик, масштабировать число копий приложения.

Kubernetes работает декларативно: вы не пишете скрипт «запусти 3 копии, потом ещё 2, потом удали одну», а описываете желаемое состояние («хочу 3 реплики этого контейнера») в YAML-манифесте, а специальные управляющие циклы (controllers) внутри Kubernetes непрерывно сверяют текущее состояние кластера с желаемым и приводят одно к другому. Этот принцип — «декларативность + постоянное приведение в соответствие» — центральный для всего курса и будет повторяться на каждом уровне: в Kubernetes-объектах (M1), в Application (M5) и в механике деплоя Nelm (M4, M7).

Базовые объекты Kubernetes, которые мы разберём в M1: Pod (единица запуска контейнеров), Deployment (декларативное управление количеством и версией Pod’ов), Service (стабильная точка доступа к Pod’ам), ConfigMap/Secret (конфигурация), Ingress/Gateway API (внешний доступ), Job/CronJob (разовые и периодические задачи), объекты RBAC (права доступа).

Deckhouse — платформа поверх Kubernetes

Голый Kubernetes — это только оркестратор. Чтобы получить продуктив-готовый кластер, вам ещё нужны: сетевой плагин (CNI), система мониторинга, Ingress-контроллер, управление сертификатами, бэкапы, консистентная СУБД, механизм обновлений самого Kubernetes и десятки других компонентов. Собирать и поддерживать их вручную — огромный объём инженерной работы, которую большинство команд не готовы делать самостоятельно.

Deckhouse — платформа (дистрибутив Kubernetes с батарейками), которая берёт эту работу на себя. Технически Deckhouse — это набор модулей (Module), каждый из которых закрывает одну инфраструктурную задачу (cert-manager, ingress-nginx, alb для Gateway API, managed-postgres, prometheus/observability, backup и десятки других), и управляющий контроллер (deckhouse-controller), который следит за состоянием этих модулей.

Здесь — первое ключевое разграничение курса, которое будет повторяться постоянно:

Application vs Module — фундамент курса

Платформа Deckhouse оперирует абстракцией Package, у которой есть два вида:

  • Module — cluster-wide компонент платформы (один на весь кластер), может создавать CRD и cluster-wide объекты, предназначен для расширения инфраструктуры. Пример: managed-postgres, ingress-nginx, cert-manager.
  • Application — namespaced пользовательский workload, неограниченное число инстансов в кластере, не может создавать CRD или cluster-wide объекты. Пример: ваш веб-сайт, бот, внутренний сервис.

Этот курс целиком про Application. Module мы будем упоминать только тогда, когда Application от него зависит (например, ваше приложение требует БД из модуля managed-postgres) — подробно эта граница разбирается в M2 уроке 1, а весь процесс разработки Application — в M5.

Werf и Nelm — от кода к работающему кластеру

Написанный вами код нужно превратить в работающий в кластере сервис. Это происходит в два принципиально разных этапа:

  1. Сборка образа — превращение исходного кода в OCI-образ контейнера (по сути — архив с файловой системой + метаданными запуска). Этим занимается Werf — CLI-инструмент для сборки и поставки, разработанный компанией Флант (той же, что разрабатывает Deckhouse). Werf умеет собирать образы двумя способами («билдерами»): через обычный Dockerfile или через собственный механизм Stapel с более гибким кэшированием стадий. Подробно — в M3.
  2. Рендер и применение чарта — превращение шаблонов Helm-чарта (по сути, параметризованных YAML-манифестов Kubernetes) в конкретные объекты и их создание/обновление в кластере. Раньше эту роль в экосистеме Werf/Deckhouse играл штатный Helm 3, но у него есть архитектурная проблема при работе с реальным дрейфом состояния кластера (разберём в M4 уроке 3) — поэтому появился Nelm, деплой-инструмент нового поколения, который использует Server-Side Apply вместо клиентского сравнения версий. Nelm — то, что реально рендерит и применяет ваш Application в кластере.

Обе команды werf build/werf converge и nelm release install вы будете использовать в каждом модуле начиная с M3.

Application — то, что вы разрабатываете

Application — пакет, который вы, как разработчик, создаёте: набор Helm/Nelm-шаблонов (templates/), схема допустимых пользовательских настроек (openapi/), метаданные (package.yaml), опционально — хуки для валидации настроек. Всё это компилируется через d8 package build в образы + чарт, публикуется в OCI Registry, и после этого любой пользователь платформы может установить ваш Application через объект kind: Application, указав нужные settings.

Подробный разбор структуры пакета — весь модуль M5, это ядро курса.

Registry — точка встречи всех компонентов

OCI Registry (container registry) — не просто хранилище Docker-образов. В экосистеме Deckhouse через registry публикуются: сами образы контейнеров, Helm/Nelm-чарты (упакованные как OCI-артефакты), метаданные версий Module и Application (ApplicationPackageVersion), даже сам Deckhouse и плагины d8. Единая точка публикации артефактов — то, что связывает разработку (werf build/d8 package build) с установкой в кластер (ModuleSource/PackageRepository). Подробную структуру путей registry разберём в M9 уроке 1.

Частые ошибки и подводные камни

  • Путать Kubernetes и Deckhouse. Kubernetes — универсальный оркестратор от CNCF, работает у любого облачного провайдера и в любом дистрибутиве. Deckhouse — конкретный продукт-дистрибутив (как Ubuntu — дистрибутив Linux). Все объекты Kubernetes из M1 работают одинаково в любом кластере; Deckhouse добавляет свои CRD и модули поверх.
  • Путать Application и Module с первого дня. Если сомневаетесь, к какой категории относится задача — задайте себе вопрос: «это то, что ставится один раз на весь кластер и служит инфраструктурой, или то, что можно поставить много раз с разными настройками как конкретный сервис?». Первое — Module, второе — Application.
  • Считать Helm и Nelm одним и тем же. Nelm — не форк Helm, а независимый деплой-движок с иной моделью применения манифестов (SSA вместо 3-Way Merge). Он совместим с форматом Helm-чартов, но так не работает.

Шпаргалка команд урока

Команд в этом уроке не было — весь набор инструментов и первые команды появятся в следующем уроке. Общие шпаргалки уже доступны в разделе «Шпаргалки» и будут пополняться по ходу курса.

Вопросы для самопроверки

Что из перечисленного верно описывает Deckhouse?

Deckhouse — платформа (дистрибутив) поверх стандартного Kubernetes API, состоящая из модулей и deckhouse-controller, который ими управляет.

Источник: Deckhouse — Concepts

В чём ключевое архитектурное отличие Application от Module?

Официальная граница: Module — cluster-wide, единственный экземпляр, может создавать CRD/cluster-wide объекты; Application — namespaced, неограниченное число инстансов, без CRD и cluster-wide объектов.

Источник: Deckhouse — Concepts

Какой инструмент отвечает за сборку OCI-образа контейнера из исходного кода в экосистеме Deckhouse?

Werf — CLI-инструмент сборки (Dockerfile-builder или Stapel-builder) и поставки; Nelm отвечает за рендер и применение чарта в кластере, а не за сборку образов.

Источник: Werf — документация

Почему в экосистеме Deckhouse/Werf на смену Helm 3 пришёл Nelm?

Server-Side Apply перекладывает вычисление диффа на API-сервер, что устойчивее к внешним изменениям состояния кластера, чем клиентское сравнение трёх версий манифеста в Helm 3.

Источник: Nelm — README на GitHub

Что публикуется в OCI Registry в экосистеме Deckhouse (выберите наиболее полный вариант)?

Registry в этой экосистеме — универсальная точка публикации артефактов: образы, чарты как OCI-артефакты, версии пакетов, сам Deckhouse, плагины CLI.

Источник: Deckhouse — Структура реестра артефактов

Рекомендуемая литература

Официальная документация

Статьи и блоги

Книги

  • Marko Lukša. Kubernetes in Action. 2nd ed., 2022. ISBN 978-1617297618.

Связанные материалы