Контейнеризация и оркестрация (Docker, Kubernetes)

15 мин

На этой странице

1. Суть темы
2. Ключевые понятия
Контейнеры и образы
Локальная оркестрация: Docker Compose
Kubernetes: единицы размещения
Автомасштабирование: HPA
Модель доставки артефакта
3. Как применяется в работе аналитика
Контекст системы и декомпозиция
Функциональные требования: Job, CronJob, Init
Нефункциональные требования в терминах платформы
Конфигурация, хранилище и окружения
Сеть и интеграции
Health checks, observability и метрики масштабирования
Деплой, релизы и миграции
Вопросы на discovery
4. Типовые ошибки и ограничения
Ограничения платформы
Типичные ошибки аналитика
Когда контейнеры — не ответ
Связи с другими разделами базы
Источники и дополнительные материалы
Официальная документация Docker
Официальная документация Kubernetes
Стандарты и экосистема

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

1. Суть темы

Контейнеризация (containerization) — упаковка приложения вместе с зависимостями в изолированный, переносимый образ (image), из которого на любой хосте запускается одинаковый контейнер (container). Docker — де‑факто стандарт инструментов сборки образов и запуска контейнеров на одном хосте.

Оркестрация (orchestration) — автоматическое размещение, масштабирование, обновление и восстановление множества контейнеров. Kubernetes (K8s) — доминирующая платформа оркестрации в продакшене; на AWS, Azure и GCP та же модель «образ → registry → workload» реализуется через managed K8s (EKS, AKS, GKE) или альтернативные оркестраторы (ECS, Cloud Run). Заголовок статьи фиксирует самую частую пару инструментов, но логика требований не привязана исключительно к K8s.

Граница темы для аналитика:

В зоне этой статьи	Вынесено в соседние заметки
Контейнер (runtime), образ, pod, deployment, service, ingress	Семантика HTTP/REST — 03.05.02 Синхронные протоколы (REST, gRPC, GraphQL), 07.02 Принципы работы HTTP, REST, SOAP; проверка контракта и практика — 07.02 Работа с API (практика)
Цепочка доставки: образ → registry → кластер (4 шага)	Конвейеры CI/CD, GitOps, promotion — 07.06 CICD и конвейеры — влияние на требования
Внутренний DNS, ingress host/path	TLS termination, egress, L4/L7 — 07.07 Сетевые основы (подсети, протоколы и маршрутизация)
ConfigMap, Secret, Helm values	Форматы конфигурации — 07.03 Основы XML, JSON, YAML
NFR: доступность, масштабирование, ресурсы (таблица перевода)	Классификация НФТ — 08.02 Нефункциональные требования (НФТ) — классификация и стандарты

Контейнер — не замена виртуальной машины (ВМ) и не гарантия отказоустойчивости сам по себе. ВМ эмулирует железо и несёт полную ОС; контейнеры делят ядро хоста — быстрее старт, плотнее упаковка, слабее изоляция на уровне «отдельная операционная система». Отказоустойчивость, бэкапы и масштабирование задаёт архитектура и оркестратор, а не факт упаковки в Docker.

Число реплик ≠ высокая доступность для пользователя. Три Pod'а бесполезны при единственной точке отказа: один Ingress, одна БД без failover, отсутствие PodDisruptionBudget (PDB). В спецификации фиксируйте не только «сколько реплик», но и цепочку: балансировка, health checks, персистентность, допустимое обслуживание кластера.

flowchart LR
    A[Код в Git] --> B[CI: сборка образа]
    B --> C[Registry]
    C --> D[Pull на кластер]
    D --> E[Манифесты / Helm]
    E --> F[Kubernetes приводит состояние]
    F --> G[Сервис доступен через Service / Ingress]

2. Ключевые понятия

Контейнеры и образы

Термин	Суть
Контейнер	Изолированный процесс (или группа процессов) с собственной файловой системой из слоёв образа; изоляция через namespaces и cgroups на хосте
Образ (image)	Неизменяемый шаблон: слои файловой системы + метаданные (точка входа, порты, переменные по умолчанию)
OCI-образ	Стандарт Open Container Initiative; образ Docker и образ в Harbor/ECR — один формат, «у нас не Docker» не отменяет ту же модель immutable image
Dockerfile / build	Декларативное описание сборки образа
Registry	Хранилище и дистрибуция образов по тегам и digest (Docker Hub, Harbor, ECR, GCR и др.)
Volume / bind mount	Персистентные или монтируемые данные вне жизненного цикла контейнера

Образ immutable (неизменяемый): чтобы изменить приложение, собирают новый образ с новым тегом или digest. Конфигурация окружения (URL БД, ключи API) не должна «запекаться» в образ без версионирования — её выносят в ConfigMap, Secret или переменные Helm.

Локальная оркестрация: Docker Compose

Docker Compose — описание нескольких контейнеров на одном хосте: сервисы, сети, volumes. На проекте это типичный способ поднять dev-окружение («backend + postgres + redis»). Для аналитика Compose полезен как модель границ сервисов: что запускается отдельно, какие порты и зависимости между контейнерами. Compose ≠ prod Kubernetes, но логика та же: сервис, порт, зависимость, volume — удобный черновик декомпозиции до манифестов.

Kubernetes: единицы размещения

Кластер управляется декларативно через API: вы описываете желаемое состояние, контроллеры его поддерживают. Детали control plane (etcd, scheduler) — зона platform/SRE; в требованиях важны workload-объекты и параметры размещения.

Термин	Суть
Pod	Минимальная единица деплоя: один или несколько контейнеров с общим network namespace и общими volumes
Node	Рабочая машина (физическая или ВМ) в кластере
Deployment	Декларативное управление репликами Pod'ов, rolling update и rollback
StatefulSet	Pod'ы с устойчивой идентичностью и персистентными томами (PVC)
Job / CronJob	Разовые или регламентные задачи: миграции схемы, batch, отчёты — часто отдельные user stories, не «просто Deployment»
Init container	Контейнер, выполняющийся до старта основного (миграции БД, ожидание зависимости)
Service	Стабильная сетевая точка доступа к Pod'ам (ClusterIP, NodePort, LoadBalancer)
Ingress	HTTP(S)-маршрутизация снаружи кластера к сервисам, часто с TLS termination
Namespace	Логическое разделение ресурсов в одном кластере (команды, окружения)
ConfigMap / Secret	Конфигурация и чувствительные данные отдельно от образа; версионируются в Git вместе с манифестами
Helm	Пакетный менеджер для K8s: charts и параметризация окружений
PodDisruptionBudget (PDB)	Минимум доступных Pod'ов при добровольных disruption (обновление узлов, drain)
ResourceQuota / LimitRange	Квоты CPU/memory и лимиты по умолчанию на namespace — изоляция команд
HorizontalPodAutoscaler (HPA)	Автоматическое изменение числа реплик Deployment/StatefulSet по метрикам (CPU, memory, custom metrics); задаёт min/max replicas и порог срабатывания
PVC / StorageClass	PersistentVolumeClaim — запрос на диск; StorageClass — класс хранилища (IOPS, тип носителя). Режимы доступа: RWO (один Pod на запись), RWX (несколько Pod'ов) — влияет на архитектуру stateful-нагрузок

Sidecar в том же Pod — основной сервис + агент логирования или прокси; в спецификации это часть единицы деплоя, не отдельный микросервис. DaemonSet — агент на каждой node (сбор логов, мониторинг); на discovery уточняйте, что нужно per-Pod (sidecar), а что cluster-wide (daemon).

Сеть между Pod'ами и подключение дисков задаёт платформа (CNI, CSI). В требованиях аналитика — network policies, класс storage, RPO/RTO для PVC, а не выбор плагина.

Автомасштабирование: HPA

HorizontalPodAutoscaler (HPA) меняет число реплик по метрикам. Без явных полей в спецификации формулировка «масштабирование по RPS» не проверяема — та же проблема, что с неполным описанием probes.

Минимальный набор полей для HPA в требованиях:

целевой workload (Deployment/StatefulSet) и min/max replicas;
метрика и порог (CPU %, RPS, queue depth, custom metric с именем и источником);
кто предоставляет custom metrics (platform, Prometheus adapter, service mesh);
связь с requests/limits: HPA по CPU бессмысленен без заданных requests;
поведение при недоступности метрики (hold, scale to min, alert).

Vertical Pod Autoscaler (VPA) — изменение requests/limits без смены числа реплик; реже попадает в требования продукта, но важен, если горизонтальное масштабирование упирается в лимиты узла. Согласование метрик HPA/canary между product и platform — типичная тема переговоров — 09.06 Ведение переговоров с техническими командами.

Модель доставки артефакта

Типовая цепочка, которую аналитик должен понимать при описании релиза (детали pipeline — 07.06 CICD и конвейеры — влияние на требования):

Код сливается в ветку → CI собирает образ.
Образ публикуется в registry (тег semver или digest); pull только из approved registry через imagePullSecrets.
На кластер применяются манифесты или Helm chart (часто через GitOps).
Контроллеры Kubernetes приводят фактическое состояние к желаемому: нужное число реплик, health checks, маршрутизация.

Образ — единый артефакт поставки; версия образа должна быть трассируема к коммиту и релизу в требованиях. Требования к base image, прокси-registry и срокам CVE-scan влияют на календарь релиза и compliance.

3. Как применяется в работе аналитика

Контекст системы и декомпозиция

Омоним «контейнер». В C4 Container — логический deployable-компонент на диаграмме (06.03.05 C4-модель), не обязательно один Docker-контейнер и не один Pod. Один C4 Container может быть Deployment из нескольких Pod'ов; один Pod может содержать несколько runtime-контейнеров (app + sidecar). На диаграмме фиксируйте границы ответственности и протоколы, на техническом слое — 03.01.01 Понятие архитектуры ИС и её виды (бизнес-, системная, техническая) — не подменяя бизнес-контекст и не рисуя «один C4 Container = один Pod» без обоснования.

На диаграмме контейнеров отражайте не «сервер заказчика», а контейнеры/сервисы на техническом слое архитектуры. Фиксируйте:

какие компоненты — отдельные deployable-единицы (C4 Container), а какие — runtime Pod/Deployment;
что синхронное (REST/gRPC внутри кластера) — см. 07.02 Работа с API (практика), 03.05.02 Синхронные протоколы (REST, gRPC, GraphQL);
что асинхронное (очереди, Kafka) — часто вне Pod'ов как managed-сервис — 03.05.04 Асинхронное взаимодействие (очереди, Kafka, Events).

Декомпозиция на подсистемы — 03.01.03 Декомпозиция системы на подсистемы и модули; точки интеграции — 03.01.04 Интерфейсы и интеграционные взаимодействия. Retry, mTLS между сервисами через service mesh — обычно зона platform; не дублируйте в API-спеке, см. 03.06.01 Архитектурные паттерны распределённых систем.

Функциональные требования: Job, CronJob, Init

Контейнерная платформа часто проявляется в регламентных процессах, а не только в «3 реплики API». Job/CronJob/Init — отдельные истории с БТ/ФТ и критериями приёмки — 02.03.03 Спецификация требований (SRS, Use Case, User Story).

Пример: ночной отчёт (CronJob)

Тип	Формулировка
БТ	Финансовый отдел получает сводку транзакций за прошлые сутки к 06:00 МСК
ФТ	Система по расписанию `0 3 * * *` (UTC) формирует отчёт и сохраняет в S3-бucket `reports/daily/`
ФТ	Повторный запуск за ту же дату идемпотентен: перезапись файла с тем же именем, без дублей в БД
НФТ	SLA завершения — 30 мин; при сбое — alert в канал `#finance-ops`, повтор не чаще 1 раза
Критерий приёмки	Файл `YYYY-MM-DD.csv` доступен до 06:00 МСК; статус Job = Complete в UI/monitoring

Пример: миграция схемы (Init container / Job)

Тип	Формулировка
ФТ	Перед стартом основного контейнера выполняется миграция до версии схемы, соответствующей тегу образа
ФТ	При неуспешной миграции Pod не получает трафик (readiness = false)
ФТ	Кто видит результат: platform видит статус Job/Pod в monitoring; разработка — лог Init container

Init container и Job не балансируются через Service — это не HTTP-сервис. Не описывайте их как «ещё один микросервис с REST».

Нефункциональные требования в терминах платформы

Параметры платформы оформляйте как НФТ — 02.03.01 Классификация требований (БТ, ФТ, НФТ); полная таксономия — 08.02 Нефункциональные требования (НФТ) — классификация и стандарты. Переводите бизнес-ожидания в проверяемые параметры:

Бизнес-формулировка	Что уточнить в требованиях
«Система не должна падать при обновлении»	Стратегия деплоя (rolling, blue/green, canary), readiness probe, backward-compatible API, PDB (минимум Pod'ов при обслуживании узлов)
«Высокая доступность»	Реплики и отсутствие single point of failure (Ingress, БД, кэш); health checks; failover managed DB
«Выдерживает пиковую нагрузку»	Min/max replicas, HPA (метрика, порог, custom metrics — контракт с platform), requests/limits; при фиксированных limits — VPA или резерв
«Восстановление за N минут»	RTO/RPO: stateless vs StatefulSet + PVC; managed DB вне кластера — 07.01 Базы данных и SQL на уровне аналитика
«Изоляция команд/клиентов»	Namespace, RBAC, network policies, ResourceQuota / LimitRange, multi-tenancy-модель

Шаблон для структурирования — 10.01.12 Шаблон нефункциональных требований (NFR).

Конфигурация, хранилище и окружения

Разделите явно:

Что	Где хранится	Кто меняет
Код приложения, зависимости	Образ (immutable)	Разработка + CI
Несекретные параметры (URL внутренних сервисов, feature flags)	ConfigMap, Helm values (версионируются в Git)	Platform / DevOps + согласование с продуктом
Пароли, ключи, сертификаты	Secret (не в Git!)	Platform, rotation policy
Версия образа на окружение	Deployment manifest, values.yaml	CI/CD pipeline — 07.06 CICD и конвейеры — влияние на требования
Персистентные данные приложения	PVC + StorageClass; RWO vs RWX	Platform + согласование RPO/RTO с продуктом

Что спросить про диск (stateful / PVC):

нужен ли PVC или достаточно managed-сервиса вне кластера;
режим доступа: RWO (один Pod) или RWX (shared);
размер, класс storage (IOPS, latency), политика расширения;
кто делает backup PVC, частота, RPO/RTO и кто восстанавливает при инциденте;
что происходит с данными при удалении Pod/StatefulSet (retain vs delete PVC).

Откат образа без отката ConfigMap/Helm values даёт mismatch (новый код + старая конфигурация или наоборот). В критериях релиза зафиксируйте, что откатывается согласованный набор: образ + values + миграции.

Секреты в репозитории — антипаттерн; политика хранения конфигурации связана с 07.05 Системы контроля версий (Git) для документации. Rotation секретов (срок, процесс без downtime, кто инициирует) — отдельный пункт discovery.

Сеть и интеграции

Внутри кластера сервисы обращаются друг к другу по DNS: service-name.namespace.svc.cluster.local. В требованиях к интеграции указывайте имя сервиса и namespace, а не IP Pod'а — IP эфемерны.

Снаружи кластера трафик обычно идёт через Ingress (host, path, TLS). Согласуйте с 07.07 Сетевые основы (подсети, протоколы и маршрутизация): какие порты, где terminates TLS, egress к внешним API. Балансировка — 03.06.04 Стратегии балансировки нагрузки.

Health checks, observability и метрики масштабирования

Три типа проверок, которые аналитик должен требовать явно:

Probe	Назначение	Типичная ошибка в требованиях
Liveness	Контейнер «жив»; при сбое — перезапуск	Проверяет тяжёлую операцию → ложные рестарты
Readiness	Готов принимать трафик	Нет readiness → трафик на неготовый Pod при rolling update
Startup	Долгий старт (миграции, прогрев кэша)	Путают со liveness → kill до готовности

Минимальный набор полей в спецификации сервиса для каждого probe:

HTTP path (или TCP port / exec-команда);
порт;
timeout и период опроса;
initialDelaySeconds / failureThreshold;
ожидаемый код ответа (для HTTP).

Readiness и недоступность зависимости (БД, брокер). Типичный спор на приёмке: должен ли Pod сниматься с балансировки, когда БД временно недоступна? Варианты — readiness возвращает 503 (Pod out of pool, без рестартов) vs liveness падает (рестарты, возможный шторм). Зафиксируйте ожидаемое поведение и кто отвечает за деградацию: приложение (graceful 503) или platform (circuit breaker на Ingress/mesh).

Probes — проверяемость NFR; формулировки должны пройти верификацию — 02.04.01 Верификация и валидация (V&V), 02.04.03 Управление качеством требований.

Observability (correlation id в логах, формат ошибок при 5xx, stdout → collector vs volume для логов) — критерии приёмки — 02.04.02 Критерии приёмки (Acceptance Criteria). Метрики для HPA (RPS, queue depth, custom metrics) — отдельный NFR-контракт с platform, не только observability; см. блок HPA в §2.

Деплой, релизы и миграции

Культура релизов и RACI на prod — 05.04 DevOps и непрерывная поставка — влияние на анализ; техническая цепочка pipeline — 07.06 CICD и конвейеры — влияние на требования.

Цепочка «деплой → миграция → readiness» должна быть явной:

Init container или Job выполняет миграцию схемы БД (или проверяет её версию).
Основной контейнер стартует; startup probe даёт время на прогрев.
Readiness probe переводит Pod в пул балансировки только после успешной миграции и прогрева.

Стратегия	Суть для аналитика
Rolling update	Постепенная замена Pod'ов; нужна обратная совместимость API и схемы БД — см. 10.01.04 Шаблон спецификации REST API
Blue/green	Два полных окружения; переключение трафика; кто утверждает переключение и откат, SLA переключателя
Canary	Часть трафика на новую версию; пороги в требованиях: max error rate, p95 latency, доля трафика (например 5% → 25% → 100%), условие автоматического rollback. Часть метрик (error rate, latency по маршруту) берётся из Ingress или service mesh, а не из приложения — не вешайте их на команду приложения, если источник — platform

«Zero downtime» без стратегии миграций, backward-compatible API и PDB — невыполнимое требование. Версионирование API — 03.05.07 Управление версионированием API и жизненным циклом; контракт для rolling update — 10.01.04 Шаблон спецификации REST API.

Вопросы на discovery

Задавайте на старте, чтобы не дописывать NFR постфактум; продолжение общего чеклиста — 10.04 Чеклист аналитика перед стартом разработки:

Один кластер или несколько (dev/stage/prod, регионы, DR)?
Multi-tenancy: namespace на клиента или общий кластер? Есть ли ResourceQuota на namespace?
Кто владелец манифестов и Helm charts — platform team или продукт?
Политика версионирования образов: semver, digest pin, promotion между registry? Approved registry, imagePullSecrets, требования к base image?
Stateful-нагрузки (БД, очереди) — в кластере или managed-сервис?
PVC: RWO/RWX, StorageClass, backup, кто восстанавливает данные при сбое?
Миграции БД: Init container, отдельный Job, порядок относительно readiness?
Rotation секретов: срок, процесс, downtime допустим?
Требования compliance: privileged containers запрещены, CVE-scan образов?
Логирование: stdout в collector или персистентный volume (влияет на расследование инцидентов)?
HPA/canary: кто владелец метрик (platform vs product), откуда берутся custom metrics?

Архитектурные решения фиксируйте в ADR — 10.01.13 Шаблон архитектурного решения (ADR).

4. Типовые ошибки и ограничения

Ограничения платформы

Stateful-нагрузки в K8s (БД, брокеры) сложнее stateless: бэкапы, ordering, персистентные тома (PVC). На многих проектах managed DB и managed Kafka вне кластера — проще для RPO/RTO.
12-factor и stateless-сервисы масштабируются горизонтально; сессии в памяти ломают масштабирование. Sticky session на Ingress/Service — осознанный компромисс: упрощает legacy, но усложняет масштабирование и отказ узла; альтернатива — внешний session store.
Kubernetes не бесплатен по операционной сложности: для малой системы PaaS или Docker на хосте может быть рациональнее — критерий: команда platform, число сервисов, требования к autoscaling и multi-region.
Безопасность часто недоописана: сканирование образов на CVE, запрет privileged containers, RBAC, network policies — discovery-вопросы здесь; политики admission — 08.07 Основы кибербезопасности для системного аналитика.

Типичные ошибки аналитика

Ошибка	Последствие	Как избежать
Смешать C4 Container и runtime Pod	Неверная декомпозиция, лишние «микросервисы» на диаграмме	C4 = логическая граница; Pod/Deployment — техническая реализация
Смешать образ и конфигурацию окружения	Невозможно повторить деплой, утечки секретов	Immutable образ + ConfigMap/Secret
«3 реплики = HA» без PDB и без резервирования БД/Ingress	Простой при drain узла или падении shared-компонента	Цепочка HA: реплики + probes + PDB + нет SPOF
Не различать readiness и liveness	Преждевременный трафик или бесконечные рестарты	Минимальный набор полей probe в спецификации сервиса
Не описать поведение при падении БД в readiness	Спор на приёмке: рестарты vs graceful degradation	Явное требование: out of pool vs restart
«Автомасштабирование по RPS» без полей HPA	Непроверяемое NFR	Min/max replicas, метрика, порог, источник custom metrics
Игнорировать requests/limits CPU и memory	OOMKill, деградация соседних Pod'ов	NFR с цифрами; нагрузочное тестирование
Stateful без вопросов про PVC/backup	Потеря данных, неясный RPO	RWO/RWX, StorageClass, владелец backup и restore
Интеграции «по IP Pod'а»	Обрывы при каждом redeploy	Service name, ingress host/path
«Zero downtime» без миграций (Job/Init) и совместимости API	Простой при каждом релизе	Цепочка деплой → миграция → readiness
CronJob без идемпотентности и SLA	Дубли отчётов, пропуск регламента	БТ/ФТ + критерии приёмки для batch
Canary без порогов отката и без владельца метрик	Спор «релиз успешен или нет»	Error rate, latency, доля трафика; источник метрик (app vs mesh)
Откат только образа, не values/ConfigMap	Несовместимая пара код+конфиг	Согласованный набор артефактов релиза
Sticky session «по умолчанию»	Не масштабируется, теряет сессии при падении Pod	Явное решение: sticky vs external store
Дублировать CI/CD и сети в этой заметке	Размытая ответственность	Wiki-link на 07.06 CICD и конвейеры — влияние на требования, 07.07 Сетевые основы (подсети, протоколы и маршрутизация)

Когда контейнеры — не ответ

Legacy с жёсткой привязкой к ОС, лицензиям per-host или аппаратным dongle может не контейнеризироваться без перепроектирования. Миграция legacy — отдельный кейс: 10.02 Разбор кейса "Миграция legacy-системы". Распределённые паттерны и компромиссы — 03.06.01 Архитектурные паттерны распределённых систем, 05.04 DevOps и непрерывная поставка — влияние на анализ.

Связи с другими разделами базы

Технический слой архитектуры и C4 — 03.01.01 Понятие архитектуры ИС и её виды (бизнес-, системная, техническая), 06.03.05 C4-модель
Классификация и качество НФТ — 02.03.01 Классификация требований (БТ, ФТ, НФТ), 02.04.01 Верификация и валидация (V&V), 02.04.03 Управление качеством требований
CI/CD, DevOps и релизная культура — 07.06 CICD и конвейеры — влияние на требования, 05.04 DevOps и непрерывная поставка — влияние на анализ
Чеклист старта проекта (платформа, registry, stateful) — 10.04 Чеклист аналитика перед стартом разработки
Шаблоны NFR и REST API — 10.01.12 Шаблон нефункциональных требований (NFR), 10.01.04 Шаблон спецификации REST API
Жизненный цикл и SDLC — 00.03 Жизненный цикл ПО и место аналитика (SDLC, STLC)
Переговоры с platform-командой — 09.06 Ведение переговоров с техническими командами

Источники и дополнительные материалы