Глоссарий

Глоссарий собран по всем модулям курса (M0–M11) и группирует термины в порядке их появления в программе. Каждый термин — короткое определение; подробности, YAML-примеры и практика — в указанном уроке. Используйте поиск в браузере (Ctrl/Cmd+F) для быстрого перехода к нужному термину.

Модуль 0 — Старт: экосистема, инструменты, локальный кластер

Kubernetes (K8s) — система оркестрации контейнеров с открытым кодом; управляет жизненным циклом приложений на кластере узлов. Подробнее →

Node (узел) — сервер (физический или виртуальный) в кластере Kubernetes, на котором планировщик размещает Pod’ы. Подробнее →

Декларативность / желаемое состояние — принцип, при котором вы описываете «как должно быть» в YAML, а контроллеры непрерывно приводят кластер к этому состоянию. Подробнее →

Controller (контроллер) — управляющий цикл внутри Kubernetes, который сверяет текущее состояние с желаемым и создаёт/обновляет/удаляет объекты. Подробнее →

YAML-манифест — текстовое декларативное описание объекта Kubernetes (kind, apiVersion, metadata, spec). Подробнее →

CNI (Container Network Interface) — сетевой плагин кластера, обеспечивающий сетевую связность Pod’ов. Подробнее →

CNCF — Cloud Native Computing Foundation; курирует проект Kubernetes и cloud-native экосистему. Подробнее →

Deckhouse — дистрибутив Kubernetes «с батарейками»: набор модулей и deckhouse-controller, закрывающих инфраструктурные задачи. Подробнее →

Package (Deckhouse) — абстракция платформы с двумя видами: Module и Application. Подробнее →

Module (Deckhouse) — cluster-wide компонент платформы (один на кластер), может создавать CRD и cluster-wide объекты. Подробнее →

Application (Deckhouse) — namespaced пользовательский workload-пакет; может быть установлен многократно, не создаёт CRD и cluster-wide объекты. Подробнее →

deckhouse-controller — управляющий контроллер Deckhouse, следящий за состоянием и включением модулей платформы. Подробнее →

OCI-образ — стандартный артефакт контейнера (файловая система + метаданные запуска), публикуемый в registry. Подробнее →

OCI Registry — единая точка публикации образов, чартов, метаданных версий Module/Application и плагинов d8. Подробнее →

Dockerfile — способ сборки образа через описание слоёв в текстовом файле; один из «билдеров» Werf. Подробнее →

Stapel — собственный механизм сборки образов в Werf с более гибким кэшированием стадий, альтернатива Dockerfile. Подробнее →

Werf — CLI-инструмент экосистемы Флант для сборки OCI-образов и поставки (деплоя) приложений. Подробнее →

Helm-чарт — параметризованный набор шаблонов Kubernetes-манифестов, упакованный для установки в кластер. Подробнее →

Helm 3 — инструмент рендера и применения Helm-чартов; в экосистеме Deckhouse уступает Nelm при работе с дрейфом состояния. Подробнее →

3-Way Merge — клиентская модель сравнения трёх версий манифеста в Helm 3; уязвима к дрейфу состояния кластера. Подробнее →

Nelm — деплой-инструмент нового поколения, совместимый с форматом Helm-чартов, использующий Server-Side Apply. Подробнее →

Server-Side Apply (SSA) — механизм применения манифестов, при котором вычисление diff выполняется на API-сервере, а не на клиенте. Подробнее →

werf build / werf converge — команды сборки образов и деплоя (рендер + применение чарта) в экосистеме Werf. Подробнее →

nelm release install — команда Nelm для установки релиза (рендер и применение чарта) в кластере. Подробнее →

d8 package build — команда сборки Application-пакета (образы + чарт) через встроенную команду d8 package. Подробнее →

ApplicationPackageVersion (APV) — метаданные версии Module или Application, публикуемые в OCI Registry. Подробнее →

ModuleSource / PackageRepository — объекты Deckhouse, связывающие установку в кластере с источником артефактов в registry. Подробнее →

kubectl — официальный CLI-клиент для любого Kubernetes API; команды get, describe, apply, logs, exec работают одинаково во всех дистрибутивах. Подробнее →

d8 (deckhouse-cli) — CLI платформы Deckhouse: обёртка над kubectl (d8 k) плюс платформенные команды. Подробнее →

d8 k — группа команд d8, проксирующая в kubectl с тем же kubeconfig; основной инструмент работы с API в курсе. Подробнее →

trdl — механизм установки и обновления инструментов Werf/Deckhouse с криптографической верификацией и каналами стабильности. Подробнее →

Release channels — каналы обновления trdl/Deckhouse: alpha, beta, early-access, stable, rock-solid. Подробнее →

trdl add / trdl use — команды добавления репозитория инструмента и переключения на канал/версию. Подробнее →

d8 system — группа команд для настроек/модулей/очередей платформы и системных логов deckhouse-controller. Подробнее →

d8 status — команда общего статуса кластера и модулей Deckhouse. Подробнее →

d8 backup — бэкап объектов etcd (манифесты/конфигурация кластера), не данных внутри PVC приложений. Подробнее →

d8 cr — операции с container registry платформы. Подробнее →

d8 mirror — офлайн-копирование артефактов; недоступно в Community/Basic Edition. Подробнее →

d8 delivery-kit — build/publish/plan/deploy приложений и SBOM; недоступно в CE/BE. Подробнее →

d8 plugins — механизм подгружаемых версионируемых плагинов d8 (install, update, contract, remove). Подробнее →

d8 package — плагин d8 для сборки Application-пакетов; может быть скрыт из корневого --help до установки. Подробнее →

registry-packages-proxy — компонент кластера, через который плагины d8 скачиваются по Bearer-токену из kubeconfig. Подробнее →

ClusterRole d8:registry-packages-proxy:cli-download — роль, выдаваемая администратором для авторизации скачивания плагинов CLI. Подробнее →

kubeconfig — YAML-файл с адресом API-сервера, сертификатами клиента и контекстами (кластер/namespace/пользователь). Подробнее →

KUBECONFIG — переменная окружения с путём к kubeconfig; по умолчанию ~/.kube/config. Подробнее →

kubectl config view / get-contexts / use-context — команды просмотра и переключения активного контекста подключения к кластеру. Подробнее →

d8 stronghold — группа команд для работы с секретами Deckhouse Stronghold (альтернатива Kubernetes Secret). Подробнее →

d8 iam — identity/access management платформы Deckhouse. Подробнее →

d8 network — сетевые настройки платформы Deckhouse. Подробнее →

Giterminism — принцип werf: конфигурация и контекст сборки читаются строго из текущего git-коммита, отклонения декларируются явно. Подробнее →

Community Edition (CE) — редакция Deckhouse с ограниченным набором модулей и без d8 mirror/d8 delivery-kit; устанавливается на любой совместимый Kubernetes, включая kind. Подробнее →

kind (Kubernetes IN Docker) — инструмент для запуска полноценного multi-node Kubernetes-кластера внутри Docker-контейнеров на локальной машине. Подробнее →

kind-d8.sh — официальный скрипт Deckhouse: создаёт кластер kind и устанавливает на него Deckhouse CE. Подробнее →

control-plane — узел кластера, на котором работают компоненты управления (API-сервер, scheduler, controller-manager). Подробнее →

worker node — узел кластера, предназначенный для запуска пользовательских Pod’ов. Подробнее →

status.conditions / status.phase (Module) — поля статусной модели модуля Deckhouse для диагностики готовности и ошибок. Подробнее →

containerd — container runtime внутри узла kind; Pod’ы кластера — контейнеры containerd внутри Docker-контейнера узла. Подробнее →

crictl — CLI для работы с контейнерами на уровне containerd/CRI внутри узла kind. Подробнее →

kubectl get nodes — проверка видимости узлов кластера и их состояния (Ready). Подробнее →

kubectl cluster-info — вывод адреса API-сервера и базовой информации о кластере. Подробнее →

d8 k get modules — просмотр установленных модулей Deckhouse и их состояния (WEIGHT, STATE, PHASE, ENABLED). Подробнее →

kubectl create namespace — создание логического пространства имён для изоляции ресурсов в кластере. Подробнее →

kind delete cluster — полное уничтожение локального кластера kind и всех данных в нём. Подробнее →

StorageClass (локальный) — класс хранения в kind-кластере на диске Docker-хоста; отличается от сетевого storage в продакшене. Подробнее →

HA control-plane — высокодоступный control-plane из нескольких узлов; в kind отсутствует (единая точка). Подробнее →

Проброс портов Docker — механизм внешнего доступа к сервисам kind-кластера через localhost вместо реального балансировщика/DNS. Подробнее →

Модуль 1 — Kubernetes с нуля

Pod — минимальная единица деплоя в Kubernetes; оборачивает один или несколько контейнеров с общим сетевым namespace и volumes. Подробнее →

Co-location — совместное размещение контейнеров в одном Pod’е на одном узле с общими сетью и томами. Подробнее →

status.phase (Pod) — агрегированная фаза Pod’а: Pending, Running, Succeeded, Failed, Unknown. Подробнее →

Container state — состояние отдельного контейнера в status.containerStatuses[].state: Waiting, Running, Terminated. Подробнее →

OOMKilled — причина завершения контейнера при превышении лимита памяти и убийстве OOM Killer’ом. Подробнее →

initContainers — контейнеры, запускаемые строго последовательно до старта основных; каждый должен завершиться с кодом 0. Подробнее →

Native sidecar container — initContainer с restartPolicy: Always; стартует до основных контейнеров и живёт весь жизненный цикл Pod’а. Подробнее →

spec.restartPolicy — политика перезапуска контейнеров Pod’а: Always (по умолчанию), OnFailure, Never. Подробнее →

terminationGracePeriodSeconds — время (секунды) на корректное завершение процесса после SIGTERM перед принудительным SIGKILL. Подробнее →

preStop hook — хук lifecycle.preStop, выполняемый kubelet’ом параллельно с SIGTERM при остановке контейнера. Подробнее →

SIGTERM / SIGKILL — сигналы завершения процесса: сначала мягкий SIGTERM, затем принудительный SIGKILL по истечении grace period. Подробнее →

resources.requests — гарантированный минимум CPU/памяти; используется scheduler’ом при выборе узла. Подробнее →

resources.limits — жёсткий потолок CPU/памяти; превышение памяти → OOMKilled, CPU → throttling. Подробнее →

QoS-класс — класс качества обслуживания Pod’а: Guaranteed, Burstable или BestEffort, на основе соотношения requests/limits. Подробнее →

Guaranteed — QoS-класс, когда у всех контейнеров requests == limits для CPU и памяти; последний кандидат на OOM Kill. Подробнее →

Burstable — QoS-класс при наличии requests, но без условий Guaranteed; убивается раньше Guaranteed. Подробнее →

BestEffort — QoS-класс без requests/limits; первый кандидат на OOM Kill при нехватке памяти на узле. Подробнее →

kubelet — агент на узле, запускающий контейнеры, применяющий restartPolicy, preStop и пробы. Подробнее →

Scheduler — компонент Kubernetes, выбирающий узел для размещения Pod’а с учётом resources.requests. Подробнее →

Network namespace — изолированное сетевое пространство Linux; все контейнеры одного Pod’а разделяют один namespace. Подробнее →

pause-контейнер — инфраструктурный контейнер, удерживающий network namespace Pod’а открытым для остальных контейнеров. Подробнее →

Terminating — состояние Pod’а при удалении/масштабировании вниз; Pod исключается из Endpoints Service. Подробнее →

kubectl apply — декларативное создание/обновление объекта из YAML-манифеста или stdin. Подробнее →

kubectl describe pod — детальный вывод состояний контейнеров, QoS Class, Events и истории планирования. Подробнее →

kubectl logs — просмотр логов контейнера в Pod’е; флаги -c, -f для контейнера и follow. Подробнее →

kubectl exec — выполнение команды внутри работающего контейнера (-it для интерактивной сессии). Подробнее →

kubectl port-forward — временный туннель с локальной машины на порт Pod’а без Service. Подробнее →

CPU throttling — ограничение использования CPU при превышении limits (без убийства процесса, в отличие от памяти). Подробнее →

ReplicaSet — контроллер, поддерживающий заданное число Pod’ов, подходящих под selector, создавая или удаляя лишние. Подробнее →

Deployment — контроллер, управляющий ReplicaSet’ами; обеспечивает обновление версии, историю ревизий и откаты. Подробнее →

replicas — желаемое число работающих копий Pod’ов, поддерживаемое контроллером. Подробнее →

spec.selector.matchLabels — набор лейблов, определяющих, какие Pod’ы «принадлежат» Deployment/ReplicaSet; иммутабелен после создания. Подробнее →

template (Pod-шаблон) — шаблон Pod’а (spec.template) в Deployment/ReplicaSet, по которому создаются новые Pod’ы. Подробнее →

ownerReferences — ссылка в metadata Pod’а на создавший его контроллер (ReplicaSet → Deployment). Подробнее →

RollingUpdate — стратегия обновления по умолчанию: постепенная замена старых Pod’ов новыми с контролируемым даунтаймом. Подробнее →

Recreate (стратегия Deployment) — стратегия обновления: все старые Pod’ы удаляются перед созданием новых; для несовместимых версий. Подробнее →

maxUnavailable — сколько Pod’ов может быть недоступно относительно replicas в процессе RollingUpdate (число или процент). Подробнее →

maxSurge — сколько «лишних» Pod’ов сверх replicas может быть создано одновременно при RollingUpdate. Подробнее →

revisionHistoryLimit — число старых ReplicaSet’ов (ревизий), хранимых для возможности отката; 0 отключает rollout undo. Подробнее →

kubectl rollout status — ожидание завершения обновления Deployment. Подробнее →

kubectl rollout history / undo — просмотр истории ревизий и откат на предыдущую или конкретную (--to-revision=N). Подробнее →

kubectl set image — императивное обновление образа контейнера; меняет template и запускает новый ReplicaSet. Подробнее →

kubectl scale — изменение replicas у текущего ReplicaSet без смены версии образа. Подробнее →

kubectl rollout restart — перезапуск Pod’ов Deployment без смены образа (rolling restart). Подробнее →

Service — объект, дающий стабильную точку доступа (VIP и/или DNS) к динамически меняющемуся набору Pod’ов по selector. Подробнее →

EndpointSlice — современный объект со списком IP:port Pod’ов, подходящих под Service; масштабируется на большие наборы. Подробнее →

Endpoints — устаревающий формат списка адресов Pod’ов за Service; заменяется EndpointSlice. Подробнее →

kube-proxy — компонент на узлах, реализующий балансировку трафика на Pod’ы по правилам Service. Подробнее →

ClusterIP — тип Service по умолчанию: стабильный виртуальный IP, доступный только внутри кластера. Подробнее →

NodePort — расширение ClusterIP: статический порт (30000–32767) на каждом узле кластера. Подробнее →

LoadBalancer — расширение NodePort: запрос внешнего балансировщика у облачного провайдера/платформы. Подробнее →

ExternalName — тип Service без VIP: CNAME-запись, перенаправляющая DNS на внешний адрес. Подробнее →

port / targetPort — port — порт Service внутри кластера; targetPort — порт, который слушает контейнер; могут отличаться. Подробнее →

Headless Service — Service с spec.clusterIP: None; DNS возвращает A-записи всех Pod’ов, без балансировки kube-proxy. Подробнее →

svc.cluster.local — суффикс DNS-домена сервисов Kubernetes; полное имя: <service>.<namespace>.svc.cluster.local. Подробнее →

CoreDNS — DNS-сервер кластера; обрабатывает запросы к Service и Pod’ам. Подробнее →

Label selector — механизм связи Service с Pod’ами через совпадение лейблов в spec.selector и metadata.labels Pod’а. Подробнее →

Эфемерность Pod IP — IP Pod’а меняется при пересоздании; причина существования Service как стабильной точки доступа. Подробнее →

ConfigMap — объект для внешней передачи неконфиденциальной конфигурации в контейнер без изменения образа. Подробнее →

Secret — объект для чувствительных данных; не шифрует значения сам по себе (base64 — кодирование, не шифрование). Подробнее →

configMapKeyRef / secretKeyRef — поля env.valueFrom для подстановки значения ключа ConfigMap/Secret в переменную окружения при старте. Подробнее →

mountPath — путь в файловой системе контейнера, куда монтируется том. Подробнее →

subPath — монтирование одного ключа ConfigMap/Secret как отдельного файла; не обновляется при изменении источника. Подробнее →

base64 — кодировка значений в Secret; декодируется командой base64 -d, не обеспечивает защиту данных. Подробнее →

EncryptionConfiguration — настройка шифрования данных Secret at rest в etcd на уровне кластера (администратор). Подробнее →

Opaque — тип Secret по умолчанию для произвольных пар ключ-значение. Подробнее →

kubernetes.io/tls — типизированный Secret с полями tls.crt и tls.key для TLS-терминации Ingress/Gateway API. Подробнее →

kubernetes.io/dockerconfigjson — типизированный Secret с ключом .dockerconfigjson для доступа к приватному registry. Подробнее →

imagePullSecrets — ссылка в Pod/ServiceAccount на Secret с кредами registry для скачивания приватных образов. Подробнее →

immutable: true — флаг ConfigMap/Secret, запрещающий правки и снижающий нагрузку на API-сервер (нет watch на изменения). Подробнее →

kubectl create configmap / secret — создание объектов из литералов (--from-literal) или файлов (--from-file). Подробнее →

Namespace — логическое пространство имён для группировки ресурсов, RBAC и квот; имена объектов уникальны в пределах namespace. Подробнее →

Namespace-scoped ресурс — объект, существующий внутри namespace (Pod, Deployment, Service, ConfigMap, Secret, Role). Подробнее →

Cluster-scoped ресурс — объект без привязки к namespace (Namespace, Node, PV, ClusterRole, StorageClass, Module Deckhouse). Подробнее →

Label — произвольная пара key: value в metadata.labels; маркер для группировки, не влияет на поведение сам по себе. Подробнее →

Selector — выражение, отбирающее объекты по лейблам; связывает Deployment, Service, NetworkPolicy и др. Подробнее →

matchLabels — упрощённый селектор с точным равенством лейблов; эквивалент нескольких In с одним значением. Подробнее →

matchExpressions — set-based селектор с операторами In, NotIn, Exists, DoesNotExist. Подробнее →

kubectl -l — фильтрация объектов по label selector в CLI (-A для всех namespace). Подробнее →

kubectl api-resources — список типов API-ресурсов с флагом --namespaced=true|false. Подробнее →

LimitRange — объект, задающий default/min/max ресурсов для одного Pod/Container/PVC в namespace. Подробнее →

ResourceQuota — агрегатный лимит CPU/RAM/числа объектов на весь namespace. Подробнее →

spec.hard (ResourceQuota) — жёсткие лимиты квоты: requests.cpu, requests.memory, pods и др. Подробнее →

NetworkPolicy — объект для сетевой изоляции Pod’ов; namespace сам по себе трафик не ограничивает. Подробнее →

Volume — абстракция хранилища, подключаемого к Pod’у; может быть эфемерным или постоянным. Подробнее →

emptyDir — эфемерный том на узле, создаётся при старте Pod’а и удаляется при его удалении. Подробнее →

PersistentVolume (PV) — cluster-scoped объект, представляющий реальный кусок хранилища (диск, NFS, CSI). Подробнее →

PersistentVolumeClaim (PVC) — namespace-scoped запрос на хранилище с параметрами (размер, accessMode); биндится с PV. Подробнее →

accessModes: ReadWriteOnce (RWO) — том монтируется на чтение-запись одним узлом; несколько Pod’ов на том же узле допустимы. Подробнее →

ReadOnlyMany (ROX) — том монтируется многими узлами только на чтение. Подробнее →

ReadWriteMany (RWX) — том монтируется многими узлами на чтение-запись; требует сетевого хранилища (NFS, CephFS). Подробнее →

ReadWriteOncePod (RWOP) — строгая эксклюзивность: ровно один Pod во всём кластере может смонтировать том. Подробнее →

StorageClass — описание класса динамически провижинируемого хранилища с параметрами provisioner и binding mode. Подробнее →

volumeBindingMode: Immediate — провижининг PVC сразу при создании, до планирования Pod’а; риск для локальных дисков. Подробнее →

volumeBindingMode: WaitForFirstConsumer — провижининг откладывается до выбора узла планировщиком; обязателен для локального storage. Подробнее →

reclaimPolicy: Delete — при удалении PVC PV и физические данные уничтожаются (типичный дефолт динамического провижининга). Подробнее →

reclaimPolicy: Retain — при удалении PVC PV остаётся в статусе Released; данные сохраняются для ручного администрирования. Подробнее →

provisioner — идентификатор динамического провижинера в StorageClass (например, rancher.io/local-path). Подробнее →

CSI (Container Storage Interface) — стандартный интерфейс для подключения внешних систем хранения к Kubernetes. Подробнее →

Bound (статус PVC) — PVC успешно связан с PV и готов к монтированию в Pod. Подробнее →

local-path-provisioner — провижинер локальных директорий на узле; типичен для kind-кластеров. Подробнее →

livenessProbe — проба «живости»; при провале kubelet перезапускает контейнер. Подробнее →

readinessProbe — проба готовности; при провале Pod исключается из Endpoints Service без перезапуска. Подробнее →

startupProbe — проба старта; блокирует liveness/readiness до первого успеха, защищая медленно стартующие приложения. Подробнее →

httpGet (probe) — проверка HTTP; успех при кодах ответа 2xx или 3xx. Подробнее →

tcpSocket (probe) — проверка доступности TCP-порта (порт открыт и принимает соединение). Подробнее →

exec (probe) — выполнение команды в контейнере; успех при коде возврата 0. Подробнее →

grpc (probe) — проверка gRPC health (grpc.health.v1); успех при статусе SERVING. Подробнее →

initialDelaySeconds — задержка после старта контейнера перед первой проверкой пробы. Подробнее →

periodSeconds — интервал между последовательными проверками пробы. Подробнее →

timeoutSeconds — максимальное время ожидания ответа на одну проверку. Подробнее →

successThreshold — число подряд успешных проверок для признания «готовым»; для liveness/startup обязательно 1. Подробнее →

failureThreshold — число подряд неудачных проверок до признания провала пробы. Подробнее →

CrashLoopBackOff — состояние Pod’а при циклических перезапусках из-за провала livenessProbe или ошибки старта. Подробнее →

Ingress — объект L7-маршрутизации HTTP/HTTPS; направляет трафик к Service по Host и пути запроса. Подробнее →

L4 vs L7 — Service работает на транспортном уровне (IP+порт); Ingress — на уровне приложения (HTTP host/path). Подробнее →

Ingress controller — компонент (например, ingress-nginx), реально применяющий правила из объекта Ingress. Подробнее →

IngressClass — объект, описывающий класс Ingress-контроллера в кластере. Подробнее →

spec.ingressClassName — современный способ указать, какой Ingress-контроллер обработает данный Ingress. Подробнее →

pathType: Exact — точное совпадение пути символ-в-символ с учётом регистра. Подробнее →

pathType: Prefix — совпадение по сегментам пути (/foo совпадает с /foo/bar, но не с /foobar). Подробнее →

pathType: ImplementationSpecific — семантика пути зависит от конкретного Ingress-контроллера. Подробнее →

TLS-терминация — расшифровка HTTPS на Ingress-контроллере; Pod’ы получают обычный HTTP (если не passthrough). Подробнее →

nginx.ingress.kubernetes.io/proxy-body-size — аннотация ingress-nginx для лимита размера тела HTTP-запроса. Подробнее →

ingress-nginx — модуль Deckhouse, реализующий классический Ingress-контроллер на базе nginx. Подробнее →

Gateway API — набор CRD для L4/L7-маршрутизации с ролевой моделью, штатными фильтрами и traffic splitting. Подробнее →

GatewayClass — cluster-scoped ресурс, описывающий класс реализации Gateway (создаёт infrastructure provider). Подробнее →

Gateway — точка входа трафика с listeners; обычно создаётся администратором кластера. Подробнее →

HTTPRoute — namespaced ресурс маршрутизации HTTP; создаётся разработчиком Application в своём namespace. Подробнее →

parentRefs — ссылки HTTPRoute на Gateway (имя, namespace, sectionName listener’а). Подробнее →

backendRefs — ссылки HTTPRoute на backend Service с портом и опциональным weight. Подробнее →

weight (traffic splitting) — вес backend’а для канареечного релиза; нативная возможность Gateway API. Подробнее →

PathPrefix / Exact / RegularExpression — типы path-матчинга в HTTPRoute; Exact/PathPrefix — Core conformance, RegularExpression — штатное поле API (без аннотаций контроллера), но с custom conformance: разные реализации могут использовать разные regex-движки (POSIX/PCRE/RE2), поведение не гарантированно идентично между ними. Подробнее →

filters (HTTPRoute) — штатные трансформации запроса/ответа: RequestHeaderModifier, URLRewrite, RequestRedirect. Подробнее →

ReferenceGrant — объект для явного разрешения cross-namespace ссылок (Gateway→HTTPRoute, Gateway→Secret). Подробнее →

GRPCRoute / TLSRoute / TCPRoute / UDPRoute — маршруты Gateway API для gRPC, TLS, TCP и UDP трафика соответственно. Подробнее →

alb (модуль Deckhouse) — модуль платформы, реализующий Gateway API в Deckhouse. Подробнее →

Job — контроллер, создающий Pod’ы, которые должны успешно завершиться, в отличие от постоянно работающего Deployment. Подробнее →

CronJob — контроллер, создающий Job по cron-расписанию. Подробнее →

completions — сколько раз Job должен успешно выполниться (число успешных завершений). Подробнее →

parallelism — сколько Pod’ов Job может выполнять одновременно. Подробнее →

backoffLimit — число повторных попыток при ошибке до признания Job провалившимся. Подробнее →

activeDeadlineSeconds — жёсткий таймаут (секунды) на весь Job независимо от backoffLimit. Подробнее →

schedule — cron-выражение расписания CronJob (например, */15 * * * *). Подробнее →

concurrencyPolicy: Allow — разрешить параллельные запуски CronJob, если предыдущий ещё не завершился (по умолчанию). Подробнее →

concurrencyPolicy: Forbid — пропустить новый запуск, если предыдущий Job ещё выполняется. Подробнее →

concurrencyPolicy: Replace — отменить текущий Job и запустить новый по расписанию. Подробнее →

startingDeadlineSeconds — допустимая задержка запуска CronJob; не рекомендуется ставить меньше 10–15 секунд. Подробнее →

successfulJobsHistoryLimit / failedJobsHistoryLimit — число завершённых Job (успешных/неудачных), хранимых для истории и диагностики. Подробнее →

RBAC — Role-Based Access Control; механизм явной выдачи прав на операции с объектами Kubernetes API. Подробнее →

Role — namespace-scoped набор правил (rules), определяющих разрешённые операции. Подробнее →

ClusterRole — набор правил cluster-wide; может применяться ко всему кластеру или к одному namespace через RoleBinding. Подробнее →

RoleBinding — привязка Role или ClusterRole к субъекту (ServiceAccount/User/Group) в конкретном namespace. Подробнее →

ClusterRoleBinding — привязка ClusterRole к субъекту с действием на весь кластер. Подробнее →

ServiceAccount — identity для процессов внутри Pod’а; не предназначен для аутентификации людей. Подробнее →

apiGroups — группа API в правиле RBAC; "" (пустая строка) — core API (Pod, Service, ConfigMap, Secret). Подробнее →

verbs — разрешённые операции: get, list, watch, create, update, patch, delete. Подробнее →

kubectl auth can-i — быстрая проверка наличия конкретного права у субъекта без ручного разбора цепочки Role/Binding. Подробнее →

Принцип явного разрешения — в RBAC Kubernetes нет прав «по умолчанию»; всё выдаётся явными биндингами. Подробнее →

Принцип минимальных привилегий — создание отдельного SA с минимальными правами вместо расширения default SA. Подробнее →

Модуль 2 — Deckhouse Platform: Application vs Module

Package — единая абстракция платформы Deckhouse; существует ровно в двух видах: Module и Application. Подробнее →

cluster-wide — область действия ресурса или Package на весь кластер, без привязки к namespace. Подробнее →

namespaced — область действия ресурса или Package в пределах конкретного namespace Kubernetes. Подробнее →

CRD (CustomResourceDefinition) — cluster-wide объект Kubernetes, объявляющий новый тип API; Module может создавать, Application — нет. Подробнее →

workload — пользовательская нагрузка (веб-сервис, бот, внутренний инструмент), для которой предназначен Application. Подробнее →

инстанс — отдельная установка Application в namespace; их может быть сколько угодно, в том числе несколько в одном namespace. Подробнее →

module.yaml — манифест Module в корне проекта модуля; определяет метаданные cluster-wide Package. Подробнее →

package.yaml — манифест Application-пакета: apiVersion, type: Application, name, requirements и другие поля. Подробнее →

crds/ — директория с CRD модуля; присутствует только у Module, у Application отсутствует по архитектурному запрету. Подробнее →

hooks/batch/ — директория хуков; у Module — cluster-wide, у Application — ограничены namespace инстанса. Подробнее →

openapi/config-values.yaml — схема пользовательских настроек; у Module — с версионированием, у Application — схема settings. Подробнее →

openapi/conversions/ — директория версионирования схемы настроек модуля (конверсии между версиями). Подробнее →

changelog.yaml — файл истории изменений Application-пакета. Подробнее →

openapi/values.yaml — Helm-values контракт Application-пакета. Подробнее →

oss.yaml — файл с информацией об open-source лицензиях и зависимостях Application. Подробнее →

изоляция инстансов — архитектурная причина запрета CRD у Application: namespaced-модель не позволяет одному Application влиять на другой namespace. Подробнее →

d8 package verify — команда проверки Application-пакета, запускающая pkglint перед публикацией. Подробнее →

deckhouse-controller — центральный Pod платформы Deckhouse; управляет включением/выключением Module, ModuleConfig и обновлениями по release channel. Подробнее →

addon-operator — фреймворк управления модулями: рендер Helm-чартов, выполнение хуков в нужном порядке; используется внутри deckhouse-controller. Подробнее →

shell-operator — низкоуровневый механизм подписки на события Kubernetes API и запуска скриптов/бинарников в ответ. Подробнее →

OnStartup — хук Module, срабатывающий один раз при старте deckhouse-controller. Подробнее →

BeforeHelm — хук Module, выполняемый перед рендером и применением Helm-чарта модуля. Подробнее →

AfterHelm — хук Module, выполняемый после успешного применения чарта модуля. Подробнее →

Schedule (хук) — хук Module, запускаемый по cron-расписанию. Подробнее →

OnKubernetesEvent — хук Module при изменении объектов Kubernetes API, подходящих под фильтр. Подробнее →

DeckhouseRelease — ресурс Kubernetes, через который настраивается подписка кластера на release channel. Подробнее →

d8 system queue list — просмотр очереди обработки модулей в deckhouse-controller. Подробнее →

ModuleConfig — конфигурация конкретного модуля: включён/выключен, настройки в spec.settings. Подробнее →

ApplicationHookInput — механизм хуков Application (Go), гораздо более узкий и safe-by-design, чем хуки Module. Подробнее →

settingscheck — единственный тип хука Application, доступный разработчику Application-пакета. Подробнее →

d8-system — namespace, в котором работает Pod deckhouse-controller (app=deckhouse). Подробнее →

ModuleSource — cluster-scoped объект, описывающий откуда платформа берёт модули: адрес registry, авторизация, release channel источника. Подробнее →

spec.enabled (ModuleConfig) — поле ModuleConfig, включающее или выключающее модуль в кластере. Подробнее →

spec.settings (ModuleConfig) — поле ModuleConfig с настройками конкретного модуля (специфичны для каждого Module). Подробнее →

dockerCfg — base64-encoded dockerconfigjson в ModuleSource.spec.registry для авторизации в registry модулей. Подробнее →

PackageRepository — cluster-scoped источник Package (Module и Application); отвечает за появление конкретных версий для установки. Подробнее →

PackageRepositoryOperation — объект, фиксирующий операцию синхронизации PackageRepository с реальным registry. Подробнее →

ApplicationPackageVersion — объект, описывающий конкретную версию Application-пакета, доступную для установки. Подробнее →

status.conditions (общая модель) — детальный машинно-читаемый список условий готовности; общий паттерн Kubernetes API. Подробнее →

status.summary — человекочитаемая сводка состояния, специфичная для Deckhouse (отсутствует в чистом Kubernetes): state, message, tip. Подробнее →

Ready (condition) — тип condition в статусной модели Deckhouse; status: "True" означает готовность. Подробнее →

ConfigurationApplied — condition Application; False указывает на проблему в самом Application, а не в зависимом Module. Подробнее →

nelm-source-controller — платформенный компонент, отслеживающий источники чартов и синхронизирующий их состояние в кластере. Подробнее →

3p-helm-controller — компонент для поддержки релизов в third-party модели Helm; обеспечивает совместимость с чартами вне Werf/Nelm-пайплайна. Подробнее →

dmtlint — линтер Module с 9 проверками: container, docs, hooks, images, module, no-cyrillic, openapi, rbac, templates. Подробнее →

pkglint — линтер Application с 6 проверками: docs, icon, images, layout, oss, templates. Подробнее →

.dmtlint.yaml — конфигурационный файл линтера dmtlint для Module. Подробнее →

.pkglint.yaml — конфигурационный файл линтера pkglint для Application. Подробнее →

dmt lint — команда запуска линтера dmtlint для Module. Подробнее →

Deckhouse Module Tool (dmt) — инструментарий разработки и линтинга Module, включающий dmtlint. Подробнее →

Модуль 3 — Docker и Werf

Container image — не единый архив, а последовательность read-only слоёв, наложенных через union-файловую систему. Подробнее →

слой (layer) — результат одной инструкции Dockerfile; read-only после сборки, идентифицируется хэшем содержимого. Подробнее →

overlayfs — union-файловая система, используемая Docker/containerd для наложения слоёв образа. Подробнее →

read-write слой (thin writable layer) — единственный изменяемый слой, добавляемый при запуске контейнера поверх read-only слоёв образа. Подробнее →

whiteout — маркер в новом слое, помечающий файл как «удалённый» без физического удаления из нижних слоёв. Подробнее →

copy-on-write — механизм, при котором одинаковые слои разных образов хранятся на диске один раз. Подробнее →

FROM — инструкция Dockerfile, задающая базовый образ (первый слой). Подробнее →

WORKDIR — инструкция Dockerfile, устанавливающая рабочую директорию для последующих команд. Подробнее →

COPY — инструкция Dockerfile, копирующая файлы из build context в образ; создаёт отдельный слой. Подробнее →

RUN — инструкция Dockerfile, выполняющая команду при сборке и создающая новый слой. Подробнее →

CMD — инструкция Dockerfile с аргументами по умолчанию для команды запуска; легко переопределяется при docker run. Подробнее →

ENTRYPOINT — инструкция Dockerfile с неизменяемой частью команды запуска контейнера. Подробнее →

EXPOSE — инструкция Dockerfile, документирующая порт; не публикует его (нужен -p или Kubernetes Service). Подробнее →

multi-stage build — сборка с несколькими стадиями FROM; позволяет оставить в финальном образе только нужный артефакт. Подробнее →

COPY –from — копирование артефакта из другой стадии multi-stage build в финальный образ. Подробнее →

docker build — команда сборки образа из Dockerfile и build context; флаги -t (тег), -f (путь к Dockerfile). Подробнее →

docker run — команда создания и запуска контейнера; -d (фон), -p host:container (публикация порта). Подробнее →

docker history — список слоёв конкретного образа с размером каждого. Подробнее →

build context — директория, передаваемая в docker build как контекст для COPY и других инструкций. Подробнее →

content-addressable storage — хранение слоёв по хэшу содержимого; основа content-based тегирования werf. Подробнее →

Dockerfile-builder — билдер werf, использующий обычный Dockerfile для сборки образа. Подробнее →

Stapel-builder — собственный билдер werf с YAML-инструкциями вместо Dockerfile. Подробнее →

werf.yaml — главный конфигурационный файл werf; YAML-мультидокумент с метаданными проекта и блоками image:. Подробнее →

configVersion — версия схемы/формата werf.yaml; не связана с версией Application-пакета. Подробнее →

image: — секция werf.yaml, описывающая один собираемый образ; разделяется ---. Подробнее →

werf build — команда сборки одного или всех образов, описанных в werf.yaml. Подробнее →

werf converge — команда сборки и деплоя; все image:-блоки собираются одним вызовом. Подробнее →

dependencies (werf.yaml) — директива werf.yaml, объявляющая зависимости между образами. Подробнее →

dockerfile (поле) — поле Dockerfile-builder: путь к Dockerfile относительно context. Подробнее →

context (поле) — поле Dockerfile-builder: директория build context; по умолчанию — корень проекта. Подробнее →

target (поле) — поле Dockerfile-builder: выбор конкретной стадии multi-stage Dockerfile (аналог docker build --target). Подробнее →

args (werf.yaml) — поле Dockerfile-builder: build-аргументы, передаваемые в Dockerfile. Подробнее →

from (Stapel) — поле Stapel-builder: базовый образ, аналог FROM в Dockerfile. Подробнее →

git: — секция Stapel-builder: описание копирования файлов из Git-репозитория в образ. Подробнее →

git.add — путь в Git-репозитории, файлы которого копируются в образ. Подробнее →

git.to — абсолютный путь назначения в образе для файлов из git.add. Подробнее →

shell: — секция Stapel-builder с императивными shell-командами по user-стадиям. Подробнее →

ansible: — альтернатива shell: в Stapel-builder; декларативные Ansible-модули (apt, apk, yum и др.). Подробнее →

werf config render — команда вывода итогового werf.yaml после обработки Go-шаблонов. Подробнее →

beforeInstall — первая user-стадия Stapel; системные пакеты, редко меняющиеся (apt install и т.п.). Подробнее →

install (Stapel) — вторая user-стадия Stapel; зависимости приложения по манифестам (npm install, go mod download). Подробнее →

beforeSetup — третья user-стадия Stapel; конфигурация системы и сборка ассетов (webpack build, assets:precompile). Подробнее →

setup (Stapel) — четвёртая user-стадия Stapel; конфигурация приложения и финальная генерация. Подробнее →

user-стадии — четыре именованные стадии Stapel, выполняемые строго последовательно: beforeInstall → install → beforeSetup → setup. Подробнее →

git.stageDependencies — привязка масок файлов Git к конкретной стадии; инвалидация кэша только при изменении соответствующих файлов. Подробнее →

cacheVersion — произвольная строка; изменение форсирует пересборку всех user-стадий образа. Подробнее →

dependencies (image linking) — директива в image:-блоке werf.yaml, объявляющая зависимость от других образов того же файла. Подробнее →

imports (dependencies) — список внутри dependencies, определяющий, какую информацию об образе передать как build-аргумент. Подробнее →

targetBuildArg — имя build-аргумента Dockerfile, в который werf подставит значение из imports. Подробнее →

ImageName — тип import: полное имя образа в registry без тега. Подробнее →

ImageTag — тип import: тег образа. Подробнее →

ImageRepo — тип import: адрес репозитория образа. Подробнее →

ImageDigest — тип import: content-based дайджест (детерминированный хэш содержимого образа). Подробнее →

ARG (Dockerfile) — объявление build-аргумента; если используется в FROM, должен быть объявлен до первого FROM. Подробнее →

import: — директива Stapel для прямого копирования файлов/директорий между Stapel-образами. Подробнее →

add (import) — абсолютный путь к файлу/директории в source-образе для импорта. Подробнее →

to (import) — абсолютный путь назначения в целевом образе; по умолчанию равен add. Подробнее →

after (import) — стадия целевого образа (install или setup), после которой встраивается импорт. Подробнее →

before (import) — стадия целевого образа (install или setup), перед которой встраивается импорт. Подробнее →

includePaths — маски файлов, фильтрующие, какие файлы из директории add попадут в целевой образ. Подробнее →

excludePaths — маски файлов, исключающие файлы из импорта. Подробнее →

owner / group (import) — владелец и группа скопированных файлов в целевом образе (для непривилегированного runtime). Подробнее →

builder-образ — вспомогательный Stapel-образ с инструментарием сборки (компилятор, npm). Подробнее →

паттерн builder+import — раздельная сборка в builder-образе и копирование только артефакта в runtime-образ. Подробнее →

werf run — запуск контейнера из собранного werf-образа для проверки содержимого. Подробнее →

build-time секреты — секреты, нужные только при сборке образа (токен npm-registry); не попадают в итоговые слои. Подробнее →

secrets: (werf.yaml) — секция werf.yaml для объявления build-time секретов сборки. Подробнее →

env (секрет werf) — способ объявления секрета из переменной окружения на машине сборки; id по умолчанию = имени переменной. Подробнее →

src (секрет werf) — путь к локальному файлу-источнику секрета (например, ~/.aws/credentials). Подробнее →

/run/secrets/<id> — путь временного файла секрета во время выполнения инструкции сборки. Подробнее →

–mount=type=secret — синтаксис BuildKit в Dockerfile для монтирования секрета при RUN. Подробнее →

BuildKit — движок сборки Docker с поддержкой секретов через --mount=type=secret. Подробнее →

werf-giterminism.yaml — файл явного разрешения отклонений от giterminism (секреты, env, файлы вне репозитория). Подробнее →

allowEnvVariables — список переменных окружения, разрешённых как источники секретов в giterminism. Подробнее →

allowFiles — список путей к файлам вне репозитория, разрешённых как источники секретов. Подробнее →

werf cleanup — команда анализа Git-истории и безопасного удаления неактуальных образов из registry по keepPolicies. Подробнее →

cleanup (секция) — секция werf.yaml с политиками хранения образов в registry. Подробнее →

keepPolicies — список политик хранения; образ сохраняется, если удовлетворяет хотя бы одной. Подробнее →

references — часть политики: определяет, какие Git-теги/ветки участвуют в правиле (имя или regex). Подробнее →

limit (cleanup) — ограничение на количество отбираемых ссылок (тегов/веток) в references. Подробнее →

imagesPerReference — сколько образов на каждую отобранную Git-ссылку сохранять. Подробнее →

content-based тегирование — тег образа werf вычисляется от хэша содержимого; при неизменном контенте тег не меняется. Подробнее →

Модуль 4 — Helm → Nelm

Helm-чарт (структура) — пакет шаблонизируемых Kubernetes-манифестов с метаданными, values и зависимостями. Подробнее →

Chart.yaml — метаданные чарта: name, version, appVersion, dependencies, type. Подробнее →

values.yaml — статический YAML со значениями по умолчанию; не шаблонизируется движком Go templates. Подробнее →

values.schema.json — опциональная JSON Schema для валидации values при установке. Подробнее →

charts/ — директория вложенных чартов-зависимостей (sub-charts). Подробнее →

crds/ (Helm) — директория CRD, устанавливаемых до рендера шаблонов; файлы не шаблонизируются. Подробнее →

_helpers.tpl — файл общих шаблонных функций; имя начинается с _, не рендерится как отдельный манифест. Подробнее →

.helmignore — маски файлов, исключаемых из упаковки чарта (аналог .gitignore). Подробнее →

appVersion — версия приложения внутри чарта; может отличаться от version чарта. Подробнее →

.Values — встроенный объект шаблона: итоговые values после слияния values.yaml и переопределений. Подробнее →

.Release — встроенный объект: .Release.Name, .Release.Namespace, .Release.IsInstall, .Release.IsUpgrade, .Release.Revision. Подробнее →

.Chart — встроенный объект: содержимое Chart.yaml — .Chart.Name, .Chart.Version, .Chart.AppVersion. Подробнее →

.Capabilities — встроенный объект: .Capabilities.KubeVersion, .Capabilities.APIVersions.Has. Подробнее →

.Files — встроенный объект для доступа к нешаблонным файлам чарта: .Files.Get "path". Подробнее →

Go templates — синтаксис шаблонизации {{ }} в файлах templates/; не работает в values.yaml. Подробнее →

Sprig-функции — библиотека функций для Go templates в Helm (строковые, математические и др.). Подробнее →

helm template — локальный рендер шаблонов чарта без установки в кластер. Подробнее →

helm lint — проверка синтаксиса и best practices чарта. Подробнее →

.helm/secret-values.yaml — зашифрованный аналог values.yaml; расшифровывается в памяти на стадии Render. Подробнее →

.helm/secret/ — директория зашифрованных произвольных файлов (сертификаты, ключи, крупные конфиги). Подробнее →

NELM_SECRET_KEY — ключ шифрования секретов чарта; без него секреты нельзя расшифровать. Подробнее →

werf_secret_file — шаблонная функция Nelm для встраивания содержимого файла из .helm/secret/. Подробнее →

stringData — поле Kubernetes Secret с открытым текстом; Kubernetes сам кодирует в base64. Подробнее →

b64enc — Sprig-функция base64-кодирования; часто используется с werf_secret_file для поля data:. Подробнее →

quote — Sprig-функция оборачивания значения в кавычки для корректного YAML. Подробнее →

nelm chart secret key create — генерация нового NELM_SECRET_KEY. Подробнее →

nelm chart secret values-file edit — редактирование .helm/secret-values.yaml в расшифрованном виде с автоматическим шифрованием. Подробнее →

Nelm — движок деплоя, спроектированный вокруг Server-Side Apply; заменяет Helm 3 в экосистеме werf/Deckhouse. Подробнее →

3-Way Merge (3WM) — механизм Helm 3: патч вычисляется клиентом из live-состояния, предыдущего манифеста и нового манифеста. Подробнее →

live-состояние — актуальное состояние ресурса в кластере на момент обновления релиза. Подробнее →

client-side merge — вычисление diff на стороне клиента (Helm), а не API-сервера. Подробнее →

kube-apiserver — API-сервер Kubernetes; при SSA сам определяет, какие поля изменились. Подробнее →

field manager — идентификатор управляющего агента в SSA; определяет владение полями ресурса. Подробнее →

nelm release plan install — предпросмотр изменений релиза через dry-run SSA без применения. Подробнее →

dry-run — режим, при котором сервер просчитывает изменения, но не применяет их. Подробнее →

конфликт field managers — ситуация, когда разные агенты управляют одними полями; SSA сигнализирует явно. Подробнее →

Render — первая стадия Nelm: шаблонизация templates/ в YAML-манифесты; расшифровка секретов в памяти. Подробнее →

Plan — вторая стадия Nelm: dry-run SSA для каждого манифеста, построение DAG операций create/update/delete. Подробнее →

Apply — третья стадия Nelm: фактическое выполнение DAG в кластере с параллельностью где возможно. Подробнее →

DAG (directed acyclic graph) — направленный ациклический граф операций деплоя, построенный на стадии Plan. Подробнее →

lookup — шаблонная функция Helm/Nelm, обращающаяся к кластеру во время Render для чтения существующих ресурсов. Подробнее →

nelm chart render — команда, выполняющая только стадию Render без кластера. Подробнее →

nelm release install — команда всех трёх стадий: Render + Plan + Apply. Подробнее →

nelm release uninstall — полное удаление релиза из namespace. Подробнее →

nelm release list — список релизов в указанном namespace. Подробнее →

nelm release history — история ревизий конкретного релиза. Подробнее →

nelm release rollback — откат релиза на указанную ревизию (--revision N). Подробнее →

–auto-rollback — флаг nelm release install: автоматический откат при ошибке деплоя (аналог --atomic у Helm). Подробнее →

nelm chart lint — проверка синтаксиса и best practices чарта. Подробнее →

nelm chart pack — упаковка чарта в .tgz-архив для распространения (-d — директория вывода). Подробнее →

nelm chart upload — публикация упакованного чарта в OCI-реестр. Подробнее →

nelm chart download — скачивание чарта из OCI-реестра (--version). Подробнее →

nelm chart dependency update — пересчёт версий зависимостей и обновление Chart.lock (аналог npm install). Подробнее →

Chart.lock — lock-файл с точными версиями sub-charts; аналог package-lock.json. Подробнее →

nelm repo login — авторизация в OCI-реестре чартов (--username, --password). Подробнее →

secret-values.yaml (мерж в .Values) — значения из secret-values.yaml становятся частью .Values, синтаксически неотличимы от обычных. Подробнее →

правило выбора механизма секретов — отдельные значения → secret-values.yaml + .Values; целые файлы → .helm/secret/ + werf_secret_file. Подробнее →

Модуль 5 — Разработка Application (Package)

Application-пакет — артефакт для публикации в marketplace Deckhouse: расширенный Helm-чарт с package.yaml, OpenAPI-схемами, опциональными Go-хуками и метаданными. Подробнее →

templates/ (обязательная директория) — обязательная директория Helm/Nelm-шаблонов; без хотя бы одного ресурса пакет ничего не устанавливает. Подробнее →

hooks/ (Application) — опциональная директория Go-хуков (hooks/batch/…) для логики сверх JSON Schema (валидация, пост-обработка). Подробнее →

images/ (Application) — опциональная директория с Dockerfile для собственных образов пакета; не нужна, если используются готовые сторонние образы. Подробнее →

docs/README.md — обязательное для marketplace описание пакета (ru/en) для каталога. Подробнее →

docs/icon.svg — обязательная для marketplace иконка пакета в каталоге. Подробнее →

d8 package bootstrap — команда генерации скелета Application-пакета с флагами --hooks, --extended, --werf. Подробнее →

internal.* — служебные helm-values, недоступные пользователю напрямую; заполняются платформой или хуками. Подробнее →

Минимальное ядро пакета — три обязательных элемента любого Application-пакета: package.yaml, templates/, openapi/values.yaml. Подробнее →

apiVersion (package.yaml) — версия схемы самого манифеста package.yaml, не версия пакета и не платформы. Подробнее →

type: Application — явное указание, что манифест описывает Application-пакет (в отличие от module.yaml). Подробнее →

descriptions — обязательные локализованные описания пакета для marketplace: ключи ru и en. Подробнее →

stage — степень зрелости пакета для каталога (например, Preview, General Availability). Подробнее →

category — свободная категория для фильтрации в UI marketplace (Analytics, Databases и т.п.). Подробнее →

requirements — блок из трёх независимых категорий зависимостей: Deckhouse, Kubernetes, Module. Подробнее →

requirements.deckhouse.constraint — минимальная (или диапазон) версия платформы Deckhouse, необходимая пакету. Подробнее →

requirements.kubernetes.constraint — требование к версии Kubernetes кластера. Подробнее →

constraint (semver) — выражение совместимости версий (>= 1.70); предпочтительнее диапазона, чем точного совпадения =. Подробнее →

Политика N-2 Kubernetes — конвенция Deckhouse: пакет должен поддерживать как минимум две предыдущие минорные версии K8s. Подробнее →

Application.spec.settings — пользовательские настройки ресурса Application, валидируемые по openapi/config-values.yaml. Подробнее →

config-values.yaml — JSON Schema контракт пользовательских настроек; альтернативное имя — settings.yaml. Подробнее →

x-extend.schema — директива в values.yaml, расширяющая config-values.yaml без дублирования полей. Подробнее →

internal (values) — служебная секция helm-values, вычисляемая хуками/платформой, недоступная пользователю в spec.settings. Подробнее →

internal.triggers — служебные флаги координации между хуками и шаблонами (например, «настройки БД провалидированы»). Подробнее →

.Application.* — надстройка платформы Deckhouse поверх стандартного Helm-контекста (.Release, .Chart, .Values и др.). Подробнее →

.Application.Instance.Name — имя установленного инстанса (metadata.name ресурса Application); рекомендуемая конвенция вместо .Release.Name. Подробнее →

.Application.Settings.* — провалидированные пользовательские настройки из spec.settings. Подробнее →

.Application.Package.Images “<key>” — полный адрес собранного образа по ключу из werf.yaml (image:-блок). Подробнее →

.Application.Package.Registry.dockercfg — Base64-учётные данные registry установки для imagePullSecrets. Подробнее →

app.kubernetes.io/instance — recommended label для изоляции ресурсов между инстансами одного пакета. Подробнее →

app.kubernetes.io/name — recommended label с именем пакета/приложения. Подробнее →

Только namespaced-ресурсы — Application не может создавать cluster-wide объекты (ClusterRole, Namespace, StorageClass и т.д.). Подробнее →

Запрет CRD (Application) — Application-пакет не может объявлять CustomResourceDefinition ни в crds/, ни в шаблонах. Подробнее →

ObjectPatcher — клиент Go-хука для создания/изменения ресурсов; ограничен namespace инстанса Application. Подробнее →

Namespace isolation guarantee — архитектурная гарантия: хук не может записывать за пределы namespace инстанса. Подробнее →

Мультитенантность — архитектурная причина ограничений: изоляция команд/namespace в одном кластере. Подробнее →

Концепции Application и Module — официальный документ с functional constraints и resource model marketplace. Подробнее →

PackageRepository (CRD, marketplace) — cluster-scoped подключение к registry пакетов и расписание сканирования. Подробнее →

ApplicationPackageVersion (APV) — cluster-scoped обнаруженная конкретная версия пакета с метаданными из package.yaml и requirements. Подробнее →

ApplicationPackage (AP) — cluster-scoped агрегат всех версий одного пакета («карточка каталога»). Подробнее →

Application (CRD) — единственный namespace-scoped CRD из пятёрки; установленный инстанс, управляющий деплоем через Nelm. Подробнее →

applications.deckhouse.io — полное имя CRD Application в API Kubernetes. Подробнее →

spec.packageName — имя пакета при установке Application. Подробнее →

spec.packageRepositoryName — ссылка на PackageRepository, откуда брать пакет. Подробнее →

spec.packageVersion — конкретная версия для установки; должна существовать как ApplicationPackageVersion. Подробнее →

Marketplace resource model — пять CRD: PR → PRO → APV → AP → APP. Подробнее →

Множественные инстансы одного пакета — несколько ресурсов Application с одним packageName/packageVersion в одном или разных namespace. Подробнее →

metadata.name (Application) — уникальный идентификатор инстанса; определяет .Application.Instance.Name и имена ресурсов. Подробнее →

Изоляция ресурсов между инстансами — достигается конвенцией {{ .Application.Instance.Name }}-<component> в шаблонах. Подробнее →

Go-хуки Application — программируемая логика в hooks/batch/…, недоступная в чистом Helm. Подробнее →

applicationhook.Run — точка входа базового хука синхронизации Application. Подробнее →

input.Instance() — метаданные инстанса: Name, Namespace ресурса Application. Подробнее →

input.ObjectPatcher() — клиент записи ресурсов только в namespace инстанса. Подробнее →

settingscheck.Input — вход хука валидации с доступом к Settings.Get("field"). Подробнее →

settingscheck.Reject — блокирующий отказ; ConfigurationApplied=False, reason: ConfigurationFailed. Подробнее →

settingscheck.Allow(warnings…) — разрешение с опциональными предупреждениями, не блокирующими установку. Подробнее →

module-sdk — Go SDK Deckhouse (github.com/deckhouse/module-sdk/pkg/…) для хуков Application. Подробнее →

ConfigurationFailed — reason condition ConfigurationApplied при ошибке JSON Schema или settingscheck. Подробнее →

d8 package — встроенная команда deckhouse-cli для bootstrap/build/verify Application-пакетов (DKP 1.76+). Подробнее →

–hooks / –extended / –werf — флаги d8 package bootstrap, добавляющие каркас хуков, расширенных файлов и werf-сборки. Подробнее →

–version / -v (package build) — флаг build: semver-версия, инжектируемая в package.yaml при сборке. Подробнее →

–repo / -r (package build) — флаг build: адрес registry назначения для публикации пакета. Подробнее →

PACKAGE_BUILD_REPOSITORY — переменная окружения для CI вместо флага --repo. Подробнее →

–remote (verify) — проверка уже опубликованного пакета в registry, а не локальной директории. Подробнее →

Иммутабельность версий пакета — опубликованная версия не должна перезаписываться; аналог семверных Git-тегов. Подробнее →

–sign / –sign-cert / –sign-key — криптографическая подпись пакета при build для цепочки доверия поставки. Подробнее →

Installed — condition: пакет скачан, манифесты и хуки применены (первая установка). Подробнее →

UpdateInstalled — condition: новая версия скачана и применена при обновлении. Подробнее →

Scaled — condition: все реплики Pod’ов в состоянии Ready. Подробнее →

Managed — condition: Application корректно управляется платформой (внутренняя согласованность). Подробнее →

status.summary.state — обобщённое состояние (например, Updating). Подробнее →

status.summary.message — точная причина текущего состояния (ожидание Module, ошибка и т.д.). Подробнее →

status.summary.tip — инструкция пользователю: что происходит и нужно ли вмешательство. Подробнее →

InstallFailed — reason для Installed=False: ошибка установки, проверить логи DKP и настройки. Подробнее →

UpdateFailed — reason: невалидная/несуществующая packageVersion; предыдущая версия остаётся активной. Подробнее →

NotScaled — reason для Scaled=False: проблемы Pod’ов (ImagePullBackOff, ресурсы, probes). Подробнее →

Диагностика «сверху вниз» — порядок: Installed → ConfigurationApplied → Scaled → Managed → Ready. Подробнее →

Модуль 6 — Application ↔ Module ↔ K8s (паттерны зависимостей)

requirements.modules.mandatory — механизм объявления обязательных Module в package.yaml; без них Application не переходит в Ready. Подробнее →

constraint (Module) — версионное ограничение для каждого mandatory-модуля (>= 1.0.0). Подробнее →

DependencyMissing — reason Installed=False: обязательный Module отсутствует или не включён. Подробнее →

DependencyVersionMismatch — reason Installed=False: версия Module не удовлетворяет constraint. Подробнее →

Непрерывная проверка зависимостей — отключение mandatory-модуля после установки переводит Application в Not Ready. Подробнее →

DKP Controller — контроллер платформы, выполняющий проверку Module перед Nelm render/plan/apply. Подробнее →

Цепочка установки (ModuleSource → ModuleConfig → PackageRepository → Application) — типовой порядок подготовки платформенных зависимостей перед установкой Application. Подробнее →

Пошаговая верификация — проверка Module → PackageRepository → Application отдельно для локализации проблемы. Подробнее →

Несколько mandatory Module — список из двух и более элементов в requirements.modules.mandatory; все обязательны одновременно («И», не «ИЛИ»). Подробнее →

Частичная готовность зависимостей — один Ready Module не даёт частичной работоспособности Application. Подробнее →

Паттерн «Job-миграция перед Deployment» — гарантированный порядок: миграция БД до запуска новой версии приложения. Подробнее →

werf.io/delete-policy: before-creation — удаление предыдущего Job перед созданием нового (обход неизменяемости spec.template). Подробнее →

werf.io/deploy-dependency-<id> — семейство аннотаций зависимостей между ресурсами внутри одного Nelm-релиза. Подробнее →

state=ready — ожидание готовности зависимого ресурса; для Job — успешное завершение (Succeeded). Подробнее →

state=present — ожидание только существования ресурса, без готовности. Подробнее →

Неизменяемые поля Job — spec.template нельзя изменить после создания; нужно пересоздание Job. Подробнее →

Nelm-аннотации — официальный справочник аннотаций порядка и зависимостей Nelm. Подробнее →

Паттерн «общий ресурс между релизами» — один Kubernetes-ресурс, используемый несколькими Nelm-релизами/Application-инстансами. Подробнее →

werf.io/ownership: release — дефолт: ресурс принадлежит одному релизу и удаляется при uninstall. Подробнее →

werf.io/ownership: anyone — ресурс переживает uninstall релиза; совместное владение несколькими релизами. Подробнее →

Осиротевшие ресурсы — риск избыточного ownership: anyone на всех ресурсах. Подробнее →

Паттерн «ожидание внешнего оператора» — Nelm ждёт ресурс, созданный сторонним контроллером вне текущего релиза. Подробнее →

<id>.external-dependency.werf.io/resource — аннотация ожидания внешнего ресурса формата <kind>.<version>.<group>/<name>. Подробнее →

cert-manager — типичный внешний оператор; создаёт Certificate и итоговый Secret с TLS. Подробнее →

Certificate (cert-manager.io/v1) — CR запроса сертификата; результат — Secret с готовым TLS. Подробнее →

ClusterIssuer — cluster-scoped issuer cert-manager для выпуска сертификатов. Подробнее →

Двухуровневая защита данных PVC — helm.sh/resource-policy: keep (Nelm/Helm) + reclaimPolicy: Retain (Kubernetes). Подробнее →

helm.sh/resource-policy: keep — PVC не удаляется при nelm release uninstall или удалении из шаблонов чарта. Подробнее →

Released (состояние PV) — PV отвязан от PVC, данные на диске сохранены; требует ручного переиспользования. Подробнее →

Пять уровней паттернов M6 — синтезирующая модель зависимостей и аннотаций: платформенные зависимости → порядок внутри релиза → владение между релизами → внешние операторы → защита данных. Подробнее →

Модуль 7 — Продвинутый Nelm: аннотации

werf.io/deploy-on — единственная аннотация, влияющая на сам факт присутствия ресурса в рендере для конкретной операции (install/upgrade/rollback/uninstall и их pre-/post- варианты). Подробнее →

werf.io/weight — аннотация порядка: ресурсы с одинаковым весом применяются параллельно, с разным — последовательно по возрастанию числа. Подробнее →

werf.io/deploy-dependency-<id> (синтаксис) — <id> — произвольный идентификатор в имени, значение — state, kind, name (и опционально namespace). Подробнее →

state=absent — значение state в deploy-dependency/delete-dependency: ждать исчезновения ресурса из кластера. Подробнее →

werf.io/delete-dependency-<id> — зеркальный механизм deploy-dependency для удаления: ресурс удаляется только после state=absent указанного объекта. Подробнее →

Порядок применения vs порядок готовности — ключевое различие: weight гарантирует только порядок применения, а не завершения/готовности ресурса. Подробнее →

werf.io/deploy-on: pre-install / install / post-install — значения deploy-on для фаз первичной установки релиза. Подробнее →

werf.io/deploy-on: pre-upgrade / upgrade / post-upgrade — значения deploy-on для фаз обновления релиза. Подробнее →

werf.io/deploy-on: pre-rollback / rollback / post-rollback — значения deploy-on для фаз отката релиза. Подробнее →

werf.io/deploy-on: pre-uninstall / uninstall / post-uninstall — значения deploy-on для фаз удаления релиза. Подробнее →

Дефолт deploy-on: install,upgrade,rollback — значение по умолчанию: обычный ресурс рендерится при install/upgrade/rollback, но не при uninstall и не в pre-/post-фазах. Подробнее →

werf.io/delete-policy: before-creation-if-immutable — пересоздание только при ошибке изменения immutable-полей; дефолт для Job. Подробнее →

werf.io/delete-policy: succeeded / failed — удаление ресурса после успешного завершения деплоя или при провале проверки готовности. Подробнее →

werf.io/delete-propagation: Foreground / Background / Orphan — стратегии каскадного удаления Kubernetes, управляемые Nelm-аннотацией. Подробнее →

Immutable-поля Job — поля вроде spec.template, spec.selector, изменение которых через SSA вызывает ошибку и требует пересоздания Job. Подробнее →

deploy-on: install + ownership: anyone — обязательная пара для ресурсов, создаваемых только при первой установке, чтобы они не удалились при upgrade. Подробнее →

werf.io/track-termination-mode — аннотация: блокирует ли ожидание готовности ресурса весь процесс деплоя. Подробнее →

NonBlocking — значение track-termination-mode: ресурс создаётся, но деплой не блокируется ожиданием его готовности. Подробнее →

werf.io/fail-mode — аннотация: что делать при неудаче проверки готовности конкретного ресурса. Подробнее →

FailWholeDeployProcessImmediately — дефолтное значение fail-mode: любая неудача немедленно проваливает весь деплой. Подробнее →

IgnoreAndContinueDeployProcess — значение fail-mode: неудача ресурса не блокирует остальной процесс деплоя. Подробнее →

werf.io/failures-allowed-per-replica — аннотация: число допустимых рестартов на реплику перед провалом деплоя (дефолт 1). Подробнее →

werf.io/no-activity-timeout — аннотация: продление окна ожидания готовности для медленно стартующих ресурсов (формат Go duration, дефолт 4m). Подробнее →

werf.io/show-service-messages — аннотация: включает вывод Kubernetes Events рядом с логами контейнеров в выводе деплоя (дефолт false). Подробнее →

werf.io/skip-logs — полностью подавляет вывод логов всех подов ресурса в выводе команды деплоя. Подробнее →

werf.io/show-logs-only-for-containers — показывает логи только для указанных контейнеров, подавляя остальные. Подробнее →

werf.io/show-logs-only-for-number-of-replicas — ограничивает вывод логов первыми N репликами при большом replicas. Подробнее →

werf.io/log-regex — показывает только строки логов, соответствующие указанному regex. Подробнее →

werf.io/log-regex-skip — подавляет строки логов, соответствующие указанному regex (например, health-check GET /healthz). Подробнее →

werf.io/sensitive: “true” — маркирует весь ресурс как чувствительный: diff полностью скрывается в выводе plan. Подробнее →

werf.io/sensitive-paths — список JSONPath-выражений, скрывающих diff только для указанных полей, оставляя остальной diff видимым. Подробнее →

JSONPath — язык путей к полям в манифесте (например, $.spec.template.spec.containers[*].env[*].value). Подробнее →

dump_debug — debug-функция: печатает полное дерево контекста ($) в debug-лог, не попадая в манифест. Подробнее →

printf_debug — debug-функция: аналог printf с выводом в debug-лог вместо манифеста. Подробнее →

include_debug — debug-функция: аналог include для проверки результата именованного define-блока в debug-логе. Подробнее →

tpl_debug — debug-функция: аналог tpl для отладки рендеринга строки как Go-шаблона в debug-логе. Подробнее →

–log-level debug — флаг CLI (nelm chart render --log-level debug) для активации вывода debug-функций. Подробнее →

Use case: медленно стартующий ресурс — no-activity-timeout: 20m + failures-allowed-per-replica: "3" + show-service-messages: "true". Подробнее →

Комбинация аннотаций — практические задачи решаются 2–3 аннотациями из разных категорий (порядок + владение + tracking), а не одной изолированной. Подробнее →

Server-Side Apply и null-значения — подводный камень: foo: null в манифесте из nil в .Values может вызвать ошибку SSA. Подробнее →

Stale plan — ситуация, когда Plan увидел одно состояние кластера, а к Apply оно уже изменилось из-за lookup. Подробнее →

now (Helm) — недетерминированная функция текущего времени, вызывающая ложные diff при повторных рендерах. Подробнее →

randAlphaNum (Helm) — недетерминированная функция случайной строки, вызывающая «мерцающий» diff. Подробнее →

keys | sortAlpha — решение: явная сортировка ключей map перед range для стабильного рендера. Подробнее →

deploy-dependency между lifecycle-фазами — подводный камень: DAG строится отдельно для каждой фазы (pre-install vs install), зависимость между фазами не работает предсказуемо. Подробнее →

Модуль 8 — Продвинутый Werf

dependencies (image linking, deep) — секция образа, объявляющая зависимости от других образов проекта для передачи build-аргументов. Подробнее →

Паттерн auth+controlplane→app — несколько независимых образов передают ImageName+ImageDigest в общий образ через dependencies/imports. Подробнее →

Мутабельный тег (:latest) — причина предпочитать ImageDigest вместо ImageName там, где нужна гарантия пересборки. Подробнее →

–cache-repo — флаг werf build, указывающий отдельный registry-репозиторий для кэша слоёв образов. Подробнее →

WERF_CACHE_REPO_1 / WERF_CACHE_REPO_2 — переменные окружения для указания нескольких cache-репозиториев без повторения флага. Подробнее →

primary repo (–repo) — основной registry-репозиторий, куда публикуются итоговые образы для деплоя. Подробнее →

Эфемерные CI-раннеры — изолированные контейнеры CI без сохранённого локального Docker-кэша между job’ами. Подробнее →

content-based tag — автоматический тег образа, вычисленный по хэшу финального набора слоёв; одинаковое содержимое всегда даёт один тег. Подробнее →

–add-custom-tag — флаг werf build для добавления человекочитаемых алиасов поверх content-based тега. Подробнее →

%image% — шаблон подстановки имени образа из werf.yaml в custom-тег. Подробнее →

%image_content_based_tag% — шаблон подстановки реального content-based тега в custom-тег или werf export. Подробнее →

werf export — команда экспорта образа с явным content-based тегом в шаблоне --tag. Подробнее →

werf bundle publish — команда: собирает и публикует образы и Helm-чарт как единый самодостаточный OCI-артефакт (бандл). Подробнее →

werf bundle apply — команда: разворачивает ранее опубликованный бандл в кластер только из OCI-репозитория, без git. Подробнее →

Air-gapped деплой — сценарий изолированного контура: publish снаружи, apply внутри без доступа к git и интернету. Подробнее →

werf mirror — инструмент передачи артефактов в registry закрытого контура перед bundle apply. Подробнее →

Детерминированный rollback (bundle) — bundle apply --tag 1.0.0 применяет точно зафиксированный артефакт без риска пересборки из git. Подробнее →

cleanup.keepPolicies — раздел werf.yaml с явными политиками хранения образов по git-тегам и веткам. Подробнее →

imagesPerReference.last / .in / .operator — параметры политики: число сохраняемых версий, временное окно и способ их комбинации (And/Or). Подробнее →

Дефолт keepPolicies — без явной настройки: 10 git-тегов, 2 версии за неделю для 10 активных веток, 2 версии для main/master/staging/production. Подробнее →

werf cleanup –dry-run — предпросмотр очистки без реального удаления образов. Подробнее →

distroless-образ — минимальный контейнер только с бинарником и необходимым рантаймом, без shell, пакетного менеджера и Unix-утилит. Подробнее →

scratch — полностью пустой базовый образ без CA-сертификатов и рантайма. Подробнее →

gcr.io/distroless/static — distroless-образ со встроенными CA-сертификатами для HTTPS-запросов. Подробнее →

Площадь атаки (attack surface) — совокупность потенциальных векторов атаки; в distroless минимальна из-за отсутствия shell и пакетов. Подробнее →

kubectl debug — эфемерные debug-контейнеры (--image=busybox --target=<container>) для отладки distroless-подов. Подробнее →

werf converge (единый entrypoint) — единая команда build+deploy: собирает образы, публикует и применяет Helm/Nelm-чарт в кластер за один вызов. Подробнее →

–require-built-images — флаг werf converge: не собирать образы, требовать предварительный werf build. Подробнее →

Раздельные stage build/deploy — паттерн CI: werf build → werf converge --require-built-images для независимого перезапуска этапов. Подробнее →

Модуль 9 — Публикация и линтеры

registry.deckhouse.io/deckhouse/{ee,se,se-plus,be} — пути registry для разных коммерческих изданий Deckhouse. Подробнее →

…/packages/<name> — «главный образ» пакета: служебный образ-обёртка с метаданными для индексации каталога, не полноценный устанавливаемый чарт. Подробнее →

…/packages/<name>/version/<semver> — версионный образ Package с реальным содержимым релиза (Helm/Nelm-чарт и ссылки на образы приложения). Подробнее →

…/modules/<name>/release — сегмент пути для релизных образов Module по release channels. Подробнее →

extra/<extra-name> — сегмент пути для дополнительных вспомогательных образов пакета (CI, документация, миграции), не входящих в устанавливаемый чарт. Подробнее →

d8 mirror pull — команда зеркалирования артефактов Module и Package в офлайн-бандл. Подробнее →

–include-package — флаг d8 mirror pull для выбора пакетов с версионным ограничением (например, myapp@>=1.0.0). Подробнее →

–hide-warnings — флаг d8 package verify, скрывающий предупреждения и показывающий только ошибки (для строгого CI-гейта). Подробнее →

–show-ignored — флаг, показывающий находки линтера, исключённые через конфигурацию .pkglint.yaml/.dmtlint.yaml. Подробнее →

–lint-config <path> — флаг указания пути к файлу конфигурации линтера, если он не в стандартном месте. Подробнее →

docs (линтер pkglint) — проверяет наличие и корректность документации пакета (docs/, обязательные разделы, локализация). Подробнее →

icon (линтер pkglint) — проверяет наличие, формат и размеры иконки пакета. Подробнее →

images (линтер pkglint) — проверяет практики сборки образов в werf.yaml/Dockerfile (в т.ч. запрет :latest как base image). Подробнее →

layout (линтер pkglint) — проверяет структуру файлов и директорий пакета на соответствие ожидаемому дереву. Подробнее →

oss (линтер pkglint) — проверяет корректность oss.yaml: обязательные поля и формат лицензий. Подробнее →

templates (линтер pkglint) — проверяет корректность Helm/Nelm-шаблонов: синтаксис, обязательные метки, best practices. Подробнее →

SPDX-идентификатор — ожидаемый формат указания лицензии в oss.yaml; несоответствие — находка линтера oss. Подробнее →

DMT (Deckhouse Module Tool) — репозиторий deckhouse/dmt с инструментами разработки Module: линтер, скаффолдинг, рендеринг, тестирование. Подробнее →

dmt bootstrap — команда скаффолдинга нового Module (dmt bootstrap <name> [--pipeline github|gitlab]). Подробнее →

dmt render — команда рендеринга чартов Module с учётом Module-специфичного контекста Deckhouse-платформы. Подробнее →

dmt test conversions — команда проверки корректности миграции настроек между версиями схемы config-values.yaml модуля. Подробнее →

container (линтер dmtlint) — проверяет дубли имён контейнеров, env, securityContext, probes, resources. Подробнее →

hooks (линтер dmtlint) — проверяет синтаксис Go-хуков, ingress-конфигурации, регистрируемые хуками. Подробнее →

module (линтер dmtlint) — проверяет module.yaml, OpenAPI-конверсии, oss.yaml, лицензии зависимостей. Подробнее →

no-cyrillic (линтер dmtlint) — проверяет отсутствие кириллицы там, где ожидается только английский текст. Подробнее →

openapi (линтер dmtlint) — проверяет корректность OpenAPI-схем и конвенции именования CRD. Подробнее →

rbac (линтер dmtlint) — проверяет Role/RoleBinding, ServiceAccount, обнаруживает избыточные wildcard-права. Подробнее →

linters-settings.<linter>.impact — поле конфигурации, управляющее строгостью конкретного линтера (error или warn). Подробнее →

exclude-rules — блок .dmtlint.yaml для точечного исключения находок по kind/name/container. Подробнее →

deckhouse/modules-template — официальный публичный шаблон-репозиторий Module для read-only анализа вывода dmt lint. Подробнее →

wildcards (правило линтера rbac) — правило линтера rbac, обнаруживающее verbs: ["*"] вместо явного перечисления глаголов. Подробнее →

exclude-rules.rbac (точечное исключение) — блок конфигурации для точечного исключения конкретной RBAC-находки по kind и name, вместо понижения строгости всего линтера. Подробнее →

git tag v1.2.0 — стандартная точка начала релизного процесса Application-пакета с семверным тегом. Подробнее →

MAJOR / MINOR / PATCH — три компонента семверного номера версии: несовместимые изменения контракта, новая обратно совместимая функциональность, исправления багов. Подробнее →

when: manual — ключевое слово GitLab CI для ручного подтверждения production-релиза. Подробнее →

rollback (откат версии) — переключение инстансов Application на предыдущую стабильную версию без удаления проблемной из registry. Подробнее →

stages: setup → build → verify → publish — четыре стадии эталонного GitLab CI пайплайна Application-пакета. Подробнее →

publish-dev / publish-prod — job’ы публикации dev-версии по коммиту в main и prod-версии по git-тегу с when: manual. Подробнее →

0.0.0-dev.$CI_COMMIT_SHORT_SHA — формат dev-версии пакета при публикации из ветки main. Подробнее →

Protected+Masked — настройки GitLab CI/CD-переменных для безопасного хранения секретов вне .gitlab-ci.yml. Подробнее →

oss.yaml (обязательные поля элемента) — id, name, description, license, link, и один из version/versions — обязательные поля каждого компонента лицензионной декларации. Подробнее →

AGPL — пример лицензии с юридическими обязательствами раскрытия исходного кода; причина аудита через oss.yaml. Подробнее →

чеклист приёмки Application-пакета — итоговый список из 10 критериев готовности к публикации. Подробнее →

Модуль 10 — Production Operations

PodMonitor — CRD monitoring.coreos.com/v1 для сбора метрик, экспонируемых подами приложения на /metrics. Подробнее →

prometheus: main — обязательный лейбл на PodMonitor/ServiceMonitor/Probe/ScrapeConfig для обнаружения платформенным Prometheus Deckhouse. Подробнее →

metricRelabelings / relabelings — правила изменения лейблов метрик после сбора и фильтрации target’ов до сбора. Подробнее →

ScrapeConfig — CRD monitoring.coreos.com/v1alpha1 для нестандартных target’ов (статические/внешние endpoint’ы). Подробнее →

Probe (мониторинг) — CRD monitoring.coreos.com/v1 для внешней проверки доступности через blackbox-exporter. Подробнее →

blackbox-exporter — компонент для внешних HTTP/TCP-проверок; не входит в Deckhouse по умолчанию, требует отдельной установки. Подробнее →

ServiceMonitor — CRD для сбора метрик через Service; требует лейбл prometheus: main. Подробнее →

GrafanaDashboardDefinition — legacy CRD с JSON-описанием дашборда Grafana, встроенным в YAML-манифест. Подробнее →

модуль observability — современный способ управления дашбордами, правилами метрик и каналами уведомлений в Deckhouse. Подробнее →

ObservabilityMetricsRulesGroup — namespaced CRD правил метрик, доступный Application-разработчику в своём namespace (recording/alerting rules). Подробнее →

record / alert (правила) — recording rule предвычисляет PromQL-запрос; alerting rule определяет условие срабатывания уведомления. Подробнее →

for (alert-правило) — время непрерывного выполнения условия перед переходом алерта из pending в firing. Подробнее →

CustomAlertmanager — CRD deckhouse.io/v1alpha1 для настройки каналов уведомлений (Telegram/Slack/email/webhook). Подробнее →

route (CustomAlertmanager) — секция маршрутизации алертов: groupBy, groupInterval, groupWait, repeatInterval, receiver. Подробнее →

log-shipper — модуль Deckhouse, читающий логи контейнеров с узлов, фильтрующий и отправляющий в назначения. Подробнее →

PodLoggingConfig — CRD deckhouse.io/v1alpha1, namespace-scoped: определяет, какие поды собирать и куда отправлять логи. Подробнее →

ClusterLogDestination — CRD deckhouse.io/v1alpha1, cluster-scoped: конфигурирует назначение логов (Loki, Socket/GELF и др.). Подробнее →

type: Loki — тип ClusterLogDestination для встроенного краткосрочного хранилища логов Deckhouse. Подробнее →

encoding.codec: GELF — кодек Graylog Extended Log Format для отправки логов во внешние системы. Подробнее →

HorizontalPodAutoscaler — CRD autoscaling/v2 для автоматического горизонтального масштабирования числа реплик. Подробнее →

type: Resource / Pods / Object / External — четыре типа метрик HPA: стандартные CPU/память, кастомная метрика по подам, метрика объекта, внешняя метрика. Подробнее →

ServiceMetric — CRD deckhouse.io/v1beta1, регистрирующий PromQL-запрос как метрику, привязанную к Service. Подробнее →

IngressMetric — CRD deckhouse.io/v1beta1, аналог ServiceMetric для метрик Ingress. Подробнее →

rps_1m / rps_5m / rps_15m — готовые метрики prometheus-metrics-adapter: RPS Ingress, усреднённый за 1/5/15 минут. Подробнее →

target.type: Value / AverageValue — сравнение метрики с абсолютным значением или со значением, делённым на текущее число реплик. Подробнее →

VerticalPodAutoscaler — CRD autoscaling.k8s.io/v1 для автоматической корректировки CPU/памяти у существующих реплик. Подробнее →

updatePolicy.updateMode: InPlaceOrRecreate — рекомендуемое значение: обновление ресурсов на месте или пересоздание пода при невозможности. Подробнее →

updatePolicy.updateMode: Initial / Off — VPA устанавливает рекомендации только при создании пода / только вычисляет рекомендации без применения. Подробнее →

resourcePolicy.containerPolicies — секция VPA с политиками (minAllowed, maxAllowed, mode) на уровне отдельных контейнеров. Подробнее →

PodDisruptionBudget — CRD policy/v1, ограничивающий число одновременно эвакуируемых реплик при плановом обслуживании. Подробнее →

minAvailable / maxUnavailable (PDB) — минимальное число доступных реплик или максимальное число недоступных при voluntary disruption. Подробнее →

voluntary disruptions — добровольные нарушения доступности (drain, Eviction API); именно их контролирует PDB. Подробнее →

d8 k drain — команда эвакуации подов с узла перед плановым обслуживанием; PDB ограничивает её поведение. Подробнее →

ReplicatedStorageClass — CRD storage.deckhouse.io/v1alpha1, StorageClass Deckhouse с репликацией данных между узлами. Подробнее →

replication: None / Availability / ConsistencyAndAvailability — три уровня репликации ReplicatedStorageClass: без копирования, для доступности, с кворумной консистентностью. Подробнее →

d8 backup etcd — команда создания снапшота etcd с конфигурацией объектов кластера (не данных внутри PVC). Подробнее →

VolumeSnapshot / VolumeSnapshotClass — CRD snapshot.storage.k8s.io/v1 для создания снапшота PVC через CSI-драйвер и класс параметров снапшота. Подробнее →

pg_dump / mysqldump — утилиты логического дампа БД, переносимого между инфраструктурами, обычно запускаемые через CronJob. Подробнее →

Disaster Recovery Plan (DRP) — план аварийного восстановления с обязательным тестированием восстановления из бэкапа. Подробнее →

d8:use:role:viewer / user / manager / admin — иерархия встроенных ролей Deckhouse для RoleBinding в namespace: от просмотра до полного администрирования. Подробнее →

CiliumClusterwideNetworkPolicy — cluster-wide CRD Cilium с поддержкой L7-политик (HTTP-методы/пути). Подробнее →

policyAuditMode — режим Cilium-политики: логирует нарушения без блокировки трафика для безопасного тестирования. Подробнее →

security.deckhouse.io/pod-policy=restricted — лейбл namespace для применения профиля Pod Security Standards restricted. Подробнее →

Pod Security Standards — стандартные профили безопасности подов Kubernetes (restricted — самый строгий). Подробнее →

алгоритм «от общего к частному» — систематический порядок диагностики: summary.tip → conditions → логи → события. Подробнее →

Upmeter — модуль Deckhouse, измеряющий SLA инфраструктуры кластера в целом, а не конкретного Application. Подробнее →

smoke-mini — пять StatefulSet в Upmeter, проверяющих сетевую связность между узлами и обнаруживающих разделения. Подробнее →

d8 k logs –previous — команда просмотра логов предыдущего (упавшего) экземпляра контейнера. Подробнее →

Модуль 11 — Капстоун (Firefly III)

Капстоун — итоговый модуль курса, в котором не вводится новая теория, а самостоятельно собирается production-ready Application-пакет для нового приложения (Firefly III), применяя весь стек знаний M0–M10. Подробнее →

Firefly III — self-hosted менеджер личных финансов на стеке PHP/Laravel + MySQL/MariaDB (лицензия AGPL-3.0), выбранный как mid-size приложение с незнакомым рантаймом и жёсткой зависимостью от реляционной БД. Подробнее →

managed-mysql — платформенный Module Deckhouse для управляемого MySQL/MariaDB; объявляется единственной mandatory-зависимостью Firefly III (симметрия с managed-postgres). Подробнее →

APP_KEY — 32-байтный ключ шифрования Laravel (сессии, cookie, зашифрованные поля БД), генерируемый один раз при первой установке и не подлежащий смене между обновлениями. Подробнее →

Паттерн одноразового секрета (deploy-on: install + ownership: anyone) — ресурс (Secret с APP_KEY) создаётся только при install и защищается от удаления Nelm при upgrade. Подробнее →

startupProbe для Laravel/Firefly III — обязателен из-за длительного первого старта (миграция, прогрев кэша конфигурации); даёт Pod время на инициализацию. Подробнее →

Двухобразная werf-сборка (app + web) — разделение PHP-FPM (app) и nginx (web) на отдельные образы в одном werf.yaml с передачей статики через import. Подробнее →

Конвенция стадий Stapel для Laravel — beforeInstall (системные пакеты и PHP-расширения) → install (composer install) → beforeSetup (npm ci && npm run build) → setup (composer dump-autoload, php artisan config:cache). Подробнее →

php artisan config:cache (на этапе сборки) — кэширование конфигурации Laravel в образе для ускорения запросов; инстанс-зависимые ENV (APP_URL, DB_HOST) кэшировать нельзя. Подробнее →

FastCGI (nginx ↔ PHP-FPM) — протокол взаимодействия nginx с PHP-FPM через fastcgi_pass (порт 9000), принципиально отличающийся от proxy_pass к HTTP-бэкендам. Подробнее →

Composer build secret — инъекция токена аутентификации Composer через --mount=type=secret (не через ARG/ENV), чтобы не оставлять секреты в истории слоёв образа. Подробнее →

Job db-migrate с php artisan migrate --force — Laravel-специфичная миграция схемы БД в отдельном Job; флаг --force обязателен в production без TTY. Подробнее →

internal.managedMysql.* — внутренний контракт для реквизитов подключения к зависимому Module, не экспонируемый пользователю через config-values.yaml. Подробнее →

Четырёхстадийный пайплайн (setup → build → verify → publish) — эталонная структура CI/CD Application-пакета, переносимая на новое приложение практически без изменений. Подробнее →

Статическая vs динамическая проверка mandatory-зависимости — d8 package verify в CI проверяет синтаксис и существование имени Module; готовность Module в кластере проверяется только при реальной установке Application. Подробнее →

AGPL-3.0 в oss.yaml — copyleft-лицензия с более строгими требованиями к раскрытию кода при сетевом распространении, чем MIT. Подробнее →

Цепочка conditions Application (капстоун) — Installed → ConfigurationApplied → Scaled → Ready; типичная первая ошибка — Installed=False, reason=DependencyMissing при невключённом managed-mysql. Подробнее →

Десятипунктовый чеклист приёмки — адаптация эталонного чеклиста M9.07 к конкретному приложению: структура пакета, package.yaml, контракт настроек, ограничения Application, pkglint, Nelm-аннотации, оптимизация сборки, oss.yaml, CI/CD, Production Operations. Подробнее →

d8 backup etcd не покрывает данные PVC — etcd-бэкап сохраняет объекты кластера (манифесты), но не файлы вложений в PVC; нужен отдельный snapshot или CronJob-дамп. Подробнее →