Глоссарий

Admission-политика

Правило, которое применяется к объектам, например подам и Service, в момент их создания или изменения в кластере на основе их манифестов, но не во время работы.

Admission-политики формализуют параметры, которые разрешены или запрещены в манифестах объектов. Deckhouse Platform реализует их с помощью модуля admission-policy-engine и делит на три категории: Pod Security Standards, операционные политики (OperationPolicy), которые проверяют параметры, не связанные с безопасностью, например разрешённые registry образов, и политики безопасности (SecurityPolicy), которые проверяют параметры безопасности, например привилегированный режим или доступ к неймспейсам хоста.

Политики дополняют друг друга: если к неймспейсу применяется несколько политик, объект должен удовлетворять каждой. При изменении политики существующие поды проверяются при следующем перезапуске, а для работающих объектов, нарушающих политику, Deckhouse Platform создаёт алерт. SecurityPolicyException позволяет задать точечные исключения для отдельных подов или контейнеров.

Подробнее в разделе «Политики безопасности».

ALB (балансировка на уровне приложений)

Балансировка нагрузки на уровне приложений. Анализируются заголовки HTTP(S), пути и домены, поддерживаются SSL-терминация и маршрутизация по содержимому.

Deckhouse Platform предоставляет три реализации ALB: Ingress NGINX Controller (модуль ingress-nginx), Kubernetes Gateway API (модуль alb) и Istio (модуль istio). Балансировка на сетевом уровне — это NLB.

Критерии выбора реализации приведены в разделе «Балансировка входящего трафика».

API Deckhouse Platform

Интерфейс, через который пользователи и компоненты Deckhouse Platform взаимодействуют с кластером. Полностью совместим с API Kubernetes.

Все операции в Deckhouse Platform выполняются через API, что обеспечивает единообразие взаимодействия. API каждого модуля, его кастомные ресурсы и параметры описаны в документации модуля.

Arbiter-узел

Узел, на котором размещается только etcd, без остальных компонентов control plane, для обеспечения кворума etcd в режиме HA с двумя master-узлами.

Режим HA с двумя master-узлами и arbiter-узлом обеспечивает требования высокой доступности при ограниченных ресурсах. Arbiter-узел должен иметь лейбл node.deckhouse.io/etcd-arbiter: "" и taint, который не допускает на него пользовательскую нагрузку. Ему нужны не менее 2 ядер CPU, 4 ГБ оперативной памяти и 8 ГБ дискового пространства для etcd, а также такие же сетевые задержки, как у master-узлов.

Подробнее в разделе «Управление режимом HA».

bashible

Служба, которая работает на каждом узле кластера и выполняет bash-скрипты, также называемые bashible, настраивающие узел в соответствии с его группой узлов.

Скрипты представляют собой Go-шаблоны, объединённые в наборы (bundle). Отдельный скрипт называется шагом (step). Они написаны так, чтобы их можно было безопасно выполнять повторно. Служба повторно выполняет шаги, когда меняется контрольная сумма конфигурации группы узлов. Шаги хранятся на узле в директории /var/lib/bashible/bundle_steps/. NodeGroupConfiguration добавляет в конфигурацию bashible группы пользовательские шаги.

bashible входит в подсистему Cluster & Infrastructure. Он работает на уровне операционной системы как системная служба и не является частью модуля node-manager.

Подробнее в разделе «Bashible».

bashible-api-server

Kubernetes Extension API Server на master-узлах, который генерирует скрипты bashible из шаблонов, хранящихся в кастомных ресурсах.

Хранить все варианты скриптов для поддерживаемых ОС в etcd невозможно из-за ограничения на размер ключа и нагрузки, поэтому kube-apiserver перенаправляет запросы ресурсов с бандлами bashible в bashible-api-server и возвращает сформированный результат. Он отдаёт вторую фазу bootstrap-скрипта, скрипт bashible.sh и отрендеренный бандл группы узлов.

Подробнее в разделе «Bashible».

Bastion-хост

Хост, через который выполняется доступ по SSH к master-узлу, когда у узлов кластера нет публичных IP-адресов.

Bastion-хост нужен в схемах размещения, в которых узлы создаются без публичных IP-адресов. Установщик подключается через него, если запущен с параметрами --ssh-bastion-host, --ssh-bastion-user и, при необходимости, --ssh-bastion-port.

Bootstrap-скрипт

Скрипт bootstrap.sh, который Deckhouse Platform создаёт для каждой NodeGroup, чтобы подключить сервер к кластеру в качестве узла этой группы.

Скрипт хранится в секрете manual-bootstrap-for-<NODE-GROUP> в неймспейсе d8-cloud-instance-manager и доступен в веб-интерфейсе Deckhouse. Для ручного подключения статического узла скопируйте скрипт на сервер и выполните от root. CAPS запускает его по SSH самостоятельно. Скрипт устанавливает и настраивает параметры операционной системы, containerd, kubelet и компонент kubernetes-api-proxy, затем регистрирует узел в кластере.

Подробнее в разделе «Добавление и управление bare-metal-узлами».

bpfLB

Режим BPF Load Balancer модуля cni-cilium, который обрабатывает внешний трафик для сервисов типов NodePort и LoadBalancer. Режим задаётся параметром bpfLBMode.

В режиме SNAT BPF-балансировщик полностью повторяет логику kube-proxy: IP-адрес источника в пакетах, передаваемых подам на других узлах, заменяется на InternalIP узла. В режиме DSR входящий трафик проходит через балансировщик, а исходящий идёт напрямую с узла целевого пода, что увеличивает общую пропускную способность.

Подробнее в разделе «Режимы работы bpfLB».

Bundle пакета

Основной образ версии пакета в хранилище образов. Содержит манифест пакета, дайджесты образов, схемы OpenAPI, Helm-шаблоны, бинарный файл хуков, документацию и changelog.

Bundle публикуется как <REPOSITORY>/<PACKAGE_NAME>:<PACKAGE_VERSION> рядом с образами контейнеров приложения (на них ссылаются по дайджесту), образом метаданных версии и образами каналов обновлений. Deckhouse Platform скачивает bundle нужной версии первым шагом установки экземпляра приложения, затем читает package.yaml, схемы и images_digests.json и обнаруживает хуки.

Подробнее в разделе «Разработка приложений».

Canary-развёртывание

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

В Deckhouse Platform canary-развёртывание реализуется модулем ingress-nginx через аннотации Ingress или модулем istio с помощью объектов VirtualService и DestinationRule (рекомендуемый способ). Новая версия работает как отдельные Deployment и Service рядом со стабильной.

Подробнее в разделе «Настройка Canary deployment».

Cluster API Provider Static (CAPS)

Механизм, который автоматически подключает, настраивает и при необходимости очищает статические узлы на основе объектов StaticInstance и SSHCredentials.

CAPS включается секцией staticInstances в группе узлов с типом Static: count задаёт количество узлов в группе, labelSelector выбирает используемые StaticInstance. CAPS поддерживает количество узлов равным count: подключается к серверу по SSH, выполняет bootstrap-скрипт и добавляет узел в кластер, а при удалении узла очищает сервер и возвращает его StaticInstance в состояние Pending для повторного использования.

Подробнее в разделе «Добавление и управление bare-metal-узлами».

ColdStandby

Механизм, который возвращает виртуальную машину в работу на другом узле после отказа узла, на котором она была запущена.

Для работы механизма политика запуска runPolicy виртуальной машины должна иметь значение AlwaysOnUnlessStoppedManually или AlwaysOn, а на узлах с виртуальными машинами должен быть включён Fencing. Без Fencing недоступная машина не переносится: она остаётся на отказавшем узле и возобновляет работу вместе с ним.

Подробнее в разделе «Отказоустойчивость и балансировка виртуальных машин».

Conformance-тесты Kubernetes

Проверка Deckhouse Platform набором conformance-тестов программы CNCF Certified Kubernetes Conformance Program. Тесты выполняются для каждой поддерживаемой минорной версии Kubernetes.

Тесты запускаются с помощью Sonobuoy в режиме certified-conformance, отчёты JUnit публикуются в справке. Результаты актуальны только при выключенном модуле multitenancy-manager.

Подробнее в разделе «Результаты conformance-тестов Kubernetes».

Control plane

Компоненты Kubernetes, которые управляют кластером, такие как kube-apiserver и etcd. В Deckhouse Platform они работают на master-узлах, а в режиме HA с двумя master-узлами кворум etcd обеспечивает arbiter-узел.

Deckhouse Platform управляет сертификатами control plane, генерирует конфигурацию и манифесты его компонентов, повышает и понижает их версии, управляет кластером etcd и его участниками, выполняет дефрагментацию etcd и поддерживает файлы kubeconfig. Модуль control-plane-manager работает на всех master-узлах.

Control plane работает в режиме с одним master-узлом или в мультимастерном режиме. В режиме HA с двумя master-узлами третий экземпляр etcd работает на arbiter-узле: на нём размещается только etcd, без остальных компонентов control plane, чтобы кластер etcd сохранял кворум.

Подробнее в разделе «Общее управление и настройка control plane».

CSI-драйвер

Плагин, который управляет постоянными томами хранения в Deckhouse Platform. Входит в состав модулей cloud-provider-* и csi-*, и у всех реализаций одна эталонная архитектура.

Container Storage Interface (CSI) — стандартный интерфейс, который унифицирует доступ к хранилищам. У каждого облачного провайдера и внешнего хранилища своя реализация спецификации. Реализации отличаются составом возможностей и компонентов, но не архитектурой.

Подробнее в разделе «CSI-драйвер».

Deckhouse CLI (d8)

Интерфейс командной строки для работы с продуктами экосистемы Deckhouse. Объединяет команды для работы с Kubernetes, администрирования Deckhouse Platform, доставки приложений, копирования образов, резервного копирования, диагностики, виртуализации и других задач.

Начиная с релиза 1.59, d8 устанавливается на все узлы кластера Deckhouse Platform. Его также можно установить через trdl (open-source инструмент безопасной доставки и обновления бинарных файлов) или из исполняемого файла. Команды сгруппированы по назначению: d8 k эквивалентна kubectl, d8 system работает с настройками платформы, модулями, очередями и пакетами, d8 mirror копирует образы платформы, d8 v управляет виртуальными машинами, d8 backup создаёт резервные копии.

Подробнее в разделе «Обзор и установка Deckhouse CLI».

Disruptive-обновление

Обновление узла, которое требует прерывания его работы и может привести к кратковременному простою системных компонентов, например обновление containerd или kubelet через несколько версий. Режим подтверждения задаётся параметром disruptions.approvalMode в NodeGroup.

Обычные обновления узлов всегда применяются автоматически и не приводят к остановке или перезагрузке узла. Секцией disruptions управляются только disruptive-обновления, например обновление ядра или containerd и значительная смена версии kubelet. Одновременно обновляется только один узел группы.

В группе узлов доступны три режима подтверждения. В режиме Manual отображается алерт NodeRequiresDisruptionApprovalForUpdate, а обновление начинается после добавления на узел аннотации update.node.deckhouse.io/disruption-approved=. Узел при этом не освобождается от нагрузки автоматически. В режиме Automatic узел освобождается от нагрузки и обновляется без подтверждения. В режиме RollingUpdate создаётся новый узел с обновлёнными настройками, а старый удаляется. Этот режим применим только к облачным узлам.

Для групп master-узлов используйте режим Manual.

Подробнее в разделе «Основы управления узлами».

DSR (Direct Server Return)

Метод обработки трафика, при котором входящие пакеты проходят через балансировщик нагрузки, а исходящие идут напрямую с серверов, обрабатывающих запрос.

Ответы обычно значительно больше запросов, поэтому DSR разгружает балансировщик и увеличивает общую пропускную способность. В Deckhouse Platform DSR — один из режимов bpfLB модуля cni-cilium, применяется вместо SNAT.

Подробнее в разделе «Режимы работы bpfLB».

DVCR

Внутреннее хранилище образов контейнеров, в котором Deckhouse Platform хранит образы виртуальных машин. Размещается на постоянном томе кластера.

Из DVCR образы попадают на диски виртуальных машин, поэтому от размера тома зависит, сколько образов поместится в кластер. Размер тома и класс хранения задаются в блоке dvcr.storage в ModuleConfig virtualization. После создания тома уменьшить его размер и сменить класс хранения нельзя. Неактуальные данные удалённых образов и дисков удаляет сборка мусора по расписанию, по умолчанию ежедневно в 02:00.

Подробнее в разделе «Хранилище образов виртуальных машин».

Egress-шлюз

Централизованное управление исходящим трафиком кластера и его контроль, включая шифрование, маршрутизацию и мониторинг.

Egress-шлюз предоставляется модулем cni-cilium и настраивается двумя кастомными ресурсами. EgressGateway описывает группу узлов, один из которых выбирается активным шлюзом, а остальные остаются в режиме ожидания. EgressGatewayPolicy описывает, какой трафик подов кластера направляется через этот шлюз.

Доступны два режима: базовый с заранее настроенными IP-адресами на egress-узлах и режим Virtual IP, в котором дополнительные IP-адреса назначаются узлам динамически. Подробнее в разделе «Настройка Egress Gateway».

Fencing

Механизм, который изолирует узел, потерявший связь с кластером. Узел выключается, а при необходимости удаляется его объект Node, чтобы на нём не осталось работающей нагрузки в неопределённом состоянии.

Fencing работает в два этапа: сначала узел помечается как подозрительный на уровне gossip-протокола, затем изолируется. Механизм включается для группы узлов параметром spec.fencing.mode в NodeGroup. Fencing необходим для ColdStandby: без него недоступная виртуальная машина остаётся на отказавшем узле и возобновляет работу вместе с ним.

Подробнее в разделе «Надёжность виртуальных машин».

Frontend-узел

Узел, который балансирует входящий трафик. На frontend-узлах работают Ingress-контроллеры.

В кластере нужно более одного frontend-узла, и узлы должны выдерживать трафик при отказе как минимум одного из них. При двух frontend-узлах каждый должен справляться со всей нагрузкой, при трёх — выдерживать рост нагрузки как минимум в полтора раза. Frontend-узлы обычно образуют группу узлов front, на них запускаются Ingress-контроллеры.

Подробнее в разделе «Рекомендации по настройке узлов кластера».

Host firewall

Режим работы Cilium, в котором сетевые политики применяются не к подам, а к самим узлам кластера.

Host firewall настраивается с помощью объектов CiliumClusterwideNetworkPolicy с полем nodeSelector. Такая политика применяется к host endpoint с лейблом reserved:host и фильтрует трафик, входящий на узел и исходящий с него, включая поды с hostNetwork. Доступен только в кластерах с модулем cni-cilium.

Политики для узлов добавляют слой фильтрации внутри кластера и не заменяют защиту на уровне инфраструктуры: аппаратный файрвол и группы безопасности облака. Ошибка в них может нарушить доступ по SSH, работу control plane, kubelet или etcd, поэтому их сначала включают в режиме аудита. Подробнее в разделе «Host firewall на узлах».

Ingress-контроллер

Контроллер, который маршрутизирует запросы пользователей к приложениям и сервисам по правилам, описанным в объектах Ingress.

В Deckhouse Platform Ingress-контроллер — это Ingress NGINX Controller, которым управляет модуль ingress-nginx через объекты IngressNginxController. В одном кластере могут одновременно работать несколько Ingress NGINX Controller, один из них основной. Kubernetes Gateway API (модуль alb) и Istio Ingress Gateway тоже балансируют трафик на уровне приложений, но работают не с объектами Ingress, а с маршрутами Gateway API и объектами Gateway и VirtualService. Все три решения — реализации ALB.

Ingress-контроллеры обычно размещают на frontend-узлах. Способ поступления трафика в контроллер определяет его инлет. Подробнее в разделе «Балансировка входящего трафика».

IPAM

Механизм управления IP-адресами, который выделяет адреса сетевым интерфейсам подов и виртуальных машин и следит, чтобы один адрес не был выдан дважды. В Deckhouse Platform свой IPAM есть у CNI-модулей, у модуля sdn и у модуля virtualization.

Модули cni-cilium, cni-flannel и cni-simple-bridge назначают подам адреса из диапазона адресов подов, закреплённого за узлом. Этот IPAM не настраивается.

В модуле sdn IPAM выделяет IPv4-адреса из пулов дополнительным сетевым интерфейсам подов и виртуальных машин. Он включается для каждой сети отдельно ссылкой на пул адресов в Network или ClusterNetwork. Для кластерных сетей пулы создаёт администратор, для сетей проекта — пользователи. Если к поду подключено несколько сетей с IPAM, объекты адресов для каждого интерфейса указывают явно.

Адресами виртуальных машин в основной сети кластера по умолчанию управляет модуль virtualization с помощью VirtualMachineIPAddress и VirtualMachineIPAddressLease. Если для основной сети настроен пул в модуле sdn, адресами машин управляет общий IPAM этого модуля: адрес запрашивается автоматически, а существующие машины переходят под его управление без смены адреса и без перезапуска.

Подробнее в разделах «Дополнительные сети для использования в прикладных подах» и «IP-адреса виртуальных машин».

Istio Ingress Gateway

Точка входа балансировщика уровня приложений на базе Istio. Администратор разворачивает её с помощью IngressIstioController, а разработчики публикуют приложения с помощью объектов Gateway и VirtualService.

Публикация средствами Istio настраивается в два слоя: администратор кластера разворачивает IngressIstioController и связанную инфраструктуру, разработчики создают объекты Gateway и VirtualService в своём неймспейсе. Это одна из реализаций ALB в Deckhouse Platform наряду с Ingress NGINX и Gateway API с его управляемым Gateway.

Подробнее в разделе «Публикация приложений средствами Istio».

kubernetes-api-proxy

Прокси-сервер на базе NGINX на каждом узле кластера, который принимает запросы к API Kubernetes по адресу localhost и перенаправляет их на master-узлы, обеспечивая высокую доступность и балансировку нагрузки API.

bashible устанавливает и настраивает прокси и обновляет его список upstream-серверов — master-узлов. На master-узлах он работает как статический под: по умолчанию проксирует запросы к локальному kube-apiserver, а при его недоступности последовательно опрашивает остальные экземпляры. Через него проходят запросы kubelet к localhost.

Подробнее в разделе «Управление control plane».

Manage-роль

Роль гранулярной ролевой модели для администрирования Deckhouse Platform или одной из её подсистем — cluster-wide-ресурсов, модулей подсистемы и их системных неймспейсов.

Manage-роли относятся к гранулярной ролевой модели. Manage-роль даёт доступ к cluster-wide-ресурсам Kubernetes, к ModuleConfig и cluster-wide-ресурсам модулей своей подсистемы, а также к системным неймспейсам, в которых работают эти модули. Доступ к неймспейсам пользовательских приложений она не даёт.

Название manage-роли имеет вид d8:manage:<SUBSYSTEM>:<ACCESS_LEVEL>, например d8:manage:networking:manager. Подсистема all охватывает все модули. Права в неймспейсе назначаются use-ролями.

Подробнее в разделе «Гранулярная модель авторизации».

Managed-сервис

Готовый к использованию прикладной сервис в кластере, например база данных или очередь сообщений, жизненным циклом которого управляет Deckhouse Platform.

Каждый managed-сервис добавляет в кластер собственные ресурсы Kubernetes и контроллеры. Пользователь описывает желаемое состояние сервиса в namespaced-ресурсе, а контроллер создаёт и обновляет связанные объекты: рабочие экземпляры, Service, секреты и снимки. Администратор управляет cluster-wide-ресурсами, например классами сервиса, которые задают допустимые конфигурации и значения по умолчанию для ресурсов пользователей. Администрирование, масштабирование, резервное копирование и обновление сервиса берёт на себя Deckhouse Platform.

Подробнее в разделе «Managed-сервисы».

Marketplace

Система управления пакетами Deckhouse Platform. Администраторы подключают репозитории пакетов, пользователи устанавливают приложения из пакетов в своих неймспейсах.

Администратор кластера подключает репозиторий пакетов с помощью PackageRepository, следит за операциями сканирования, в ходе которых Marketplace обнаруживает доступные пакеты, и выдаёт пользователям права на просмотр версий пакетов и создание объектов Application. Установленное приложение — объект Application в неймспейсе пользователя.

Marketplace доступен в Deckhouse Platform начиная с версии 1.76.

Подробнее в разделе «Marketplace».

Master-узел

Узел, на котором работают компоненты control plane. Master-узлы имеют лейбл node-role.kubernetes.io/control-plane, на них запускается модуль control-plane-manager.

Deckhouse Platform управляет control plane на master-узлах: сертификатами, конфигурацией компонентов, версиями, кластером etcd и файлами kubeconfig. В облачном кластере master-узлы являются узлами CloudPermanent.

Количество master-узлов определяет, является кластер кластером с одним master-узлом или мультимастерным. При нескольких master-узлах режим HA включается автоматически.

Подробнее в разделе «Общее управление и настройка control plane».

NLB (балансировка на сетевом уровне)

Балансировка нагрузки на сетевом уровне. Трафик маршрутизируется по IP-адресам и портам без анализа содержимого запросов.

В Deckhouse Platform NLB реализуется либо внешним балансировщиком нагрузки облачного провайдера, либо встроенным модулем metallb, который работает и в облачных, и в bare-metal-кластерах. Балансировка на уровне приложений — это ALB.

Подробнее в разделе «Балансировка входящего трафика».

Orphan-ресурсы приложения

Объекты, которые остаются в неймспейсе после удаления Helm-релиза приложения, например объекты, созданные нагрузкой или хуками во время работы. Deckhouse Platform удаляет перечисленные типы вместе с объектом Application.

Пакет перечисляет типы orphan-ресурсов в поле orphanResources файла openapi/values.yaml. При удалении Application Deckhouse Platform удаляет объекты этих типов в неймспейсе экземпляра приложения с лейблом packages.deckhouse.io/instance: <INSTANCE_NAME> после удаления Helm-релиза и остановки хуков. Объекты, созданные нагрузкой и хуками, не получают лейбл автоматически.

Orphan-ресурсы удаляются только при удалении Application. При приостановке приложения и при смене версии пакета они остаются в кластере.

Подробнее в разделе «Жизненный цикл и отладка».

Pipeline логов

Цепочка сбора, фильтрации и доставки логов, которую модуль log-shipper формирует из ClusterLoggingConfig, PodLoggingConfig и ClusterLogDestination.

ClusterLoggingConfig описывает источники логов на уровне кластера, PodLoggingConfig — источники в пределах одного неймспейса, а ClusterLogDestination задаёт параметры хранилища логов. По пути pipeline логи можно фильтровать по лейблам и содержимому сообщений, дополнять метаданными Kubernetes, буферизировать и отправлять сразу в несколько хранилищ, например в кратковременное хранилище логов и в Elasticsearch.

Подробнее в разделе «Сбор и доставка логов».

Pod Security Standards

Три уровня политик безопасности подов, privileged, baseline и restricted, которые Deckhouse Platform применяет к неймспейсам с помощью модуля admission-policy-engine.

Pod Security Standards — одна из категорий admission-политик. Уровень privileged не накладывает ограничений, baseline предотвращает самые распространённые способы повышения привилегий, restricted задаёт самые строгие требования к подам. Deckhouse Platform берёт из Kubernetes только описания политик и применяет их средствами Gatekeeper, а не контроллером Pod Security Admission.

Уровень по умолчанию — baseline. Он применяется к неймспейсам без лейбла security.deckhouse.io/pod-policy, кроме системных. Лейбл задаёт уровень для одного неймспейса, а настройка модуля admission-policy-engine меняет уровень по умолчанию.

Подробнее в разделе «Политики безопасности».

Post-bootstrap-скрипт

Пользовательский скрипт, который установщик выполняет на одном из master-узлов после завершения установки кластера.

Скрипт используется для дополнительной настройки кластера, сбора диагностической информации или интеграции с внешними системами. Путь к нему передаётся установщику параметром --post-bootstrap-script-path.

Подробнее в разделе «Установка платформы».

Preflight-проверки

Проверки, которые установщик выполняет перед установкой Deckhouse Platform.

Проверки делятся на общие, проверки для статических кластеров и проверки для облачных кластеров. Отдельная проверка пропускается флагом --preflight-skip-check с её именем, --preflight-skip-all-checks пропускает все, а команда dhctl preflight list выводит полный список. Подсети кластера и шаблон DNS-имён проверяются при загрузке файла конфигурации установки, и эти проверки пропустить нельзя.

Подробнее в разделе «Установка платформы».

Thick-том

Том LVM в thick pool, то есть в пуле типа LVM: место под такой том выделяется целиком при создании. Thick pool даёт производительность, сравнимую с устройством хранения, но не позволяет использовать снимки.

Thick-тома создаются в thick pool локального и реплицируемого хранилищ: режим LVM модуля sds-local-volume и группы томов LVM без определения thin pool в модуле sds-replicated-volume. Для томов, которым нужны снимки, используйте thin-том.

Thin-том

Том LVM в thin pool, то есть в пуле типа LVMThin: место под такой том выделяется по мере заполнения. Thin pool позволяет использовать снимки, но обладает меньшей производительностью.

Thin-тома создаются в thin pool локального и реплицируемого хранилищ: режим LVMThin модуля sds-local-volume и группы томов LVM с определением thin pool в модуле sds-replicated-volume. Там, где снимки не нужны, thick-том даёт более высокую производительность.

Underlay-сеть

Прямое подключение физических функций (PF) и виртуальных функций (VF) сетевых интерфейсов узла к подам через Kubernetes Dynamic Resource Allocation. Нужна нагрузкам с прямым доступом к оборудованию, например DPDK-приложениям.

Физические сетевые интерфейсы подключаются к подам в одном из двух режимов: Shared, когда из Physical Function с помощью SR-IOV создаются Virtual Functions и несколько подов делят оборудование, или Dedicated, когда под получает Physical Function целиком. Администратор создаёт объект UnderlayNetwork модуля sdn и помечает неймспейс, которому разрешено её использовать. Под запрашивает устройство аннотацией.

DPDK, Data Plane Development Kit, — набор библиотек для обработки сетевых пакетов в пространстве пользователя в обход сетевого стека ядра.

Подробнее в разделе «Подключение физических сетевых интерфейсов к подам DPDK-приложений».

Use-роль

Роль гранулярной ролевой модели для назначения прав пользователям в одном неймспейсе, то есть доступа к namespaced-ресурсам модулей и стандартным namespaced-ресурсам Kubernetes.

Use-роли относятся к гранулярной ролевой модели. Они предназначены для пользователей, как правило разработчиков приложений, которые не управляют кластером и его модулями, но создают Ingress-ресурсы, настраивают аутентификацию приложений или собирают логи в своём неймспейсе.

Модуль user-authz создаёт роли d8:use:role:viewer, d8:use:role:user, d8:use:role:manager и d8:use:role:admin. Use-роль назначается только с помощью RoleBinding. Права администраторов назначаются manage-ролями.

Подробнее в разделе «Гранулярная модель авторизации».

Worker-узел

Узел, предназначенный для запуска пользовательских приложений. Его ресурсы определяются нагрузкой, при этом часть ресурсов нужно зарезервировать под kubelet и системные поды.

Worker-узлы есть во всех вариантах размещения, кроме одноузлового кластера, где их роль выполняет единственный узел. В кластере с одним master-узлом на worker-узлах работает и часть компонентов Deckhouse Platform. Фактический размер узла зависит от приложений, запущенных на нём.

Подробнее в разделе «Требования к ресурсам» на странице «Системные требования».

Автомасштабирование группы узлов

Автоматическое изменение количества узлов в группе компонентом Cluster Autoscaler модуля node-manager на основе потребности в CPU и памяти. Срабатывает только тогда, когда поды в состоянии Pending не могут быть размещены на существующих узлах.

Автомасштабирование доступно для узлов CloudEphemeral. Границы задаются в секции cloudInstances группы узлов: minPerZone и maxPerZone ограничивают количество узлов в зоне, maxUnavailablePerZone ограничивает количество недоступных узлов при изменениях, priority определяет, какие группы Cluster Autoscaler масштабирует первыми. Автомасштабирование не распространяется на статические узлы: для них CAPS поддерживает количество, заданное параметром staticInstances.count.

Подробнее в разделе «Добавление и управление облачными узлами».

Автоматический выпуск сертификатов

Автоматическое получение TLS-сертификатов модулем cert-manager либо с помощью объекта Certificate со ссылкой на ClusterIssuer, либо через аннотацию tls-acme на объекте Ingress.

С объектом Certificate модуль cert-manager выполняет проверку владения доменом способом, заданным в ClusterIssuer, например HTTP-01 или DNS-01, при необходимости создаёт временный Ingress для проверки и сохраняет сертификат в Secret. Аннотация tls-acme на Ingress запрашивает сертификат без отдельного объекта Certificate. Deckhouse Platform поддерживает сертификаты от Let’s Encrypt, HashiCorp Vault и Venafi, самоподписанные сертификаты, автоматическое продление и контроль срока действия.

Подробнее в разделе «Настройка использования TLS-сертификатов».

Агент гостевой ОС

QEMU Guest Agent, установленный в гостевую систему, чтобы Deckhouse Platform мог взаимодействовать с операционной системой внутри виртуальной машины.

Агент нужен для трёх вещей: он позволяет создавать консистентные снимки дисков и машин, сообщает сведения о работающей системе в блок .status.guestOSInfo и показывает, что операционная система действительно загрузилась, а не просто запустилась виртуальная машина. Условие AgentReady у работающей машины означает, что агент работает.

Deckhouse Platform работает с qemu-guest-agent версии 5.2.0 и выше. Установить и включить агент можно сценарием начальной инициализации ВМ.

Подробнее в разделе «Начальная инициализация и агент гостевой ОС».

Адреса приложения

Адреса Ingress приложения, которые Deckhouse Platform публикует в поле status.urls объекта Application. Веб-интерфейс показывает их как ссылки на приложение.

Чтобы опубликовать адрес, пакет добавляет Ingress аннотацию packages.deckhouse.io/application-endpoint-description: её значение — описание адреса, "true" добавляет адрес без описания, "false" исключает Ingress. Deckhouse Platform строит URL для каждой пары host и path в правилах Ingress, со схемой https, если хост указан в spec.tls, и обновляет status.urls экземпляра приложения после каждого успешного применения шаблонов.

Подробнее в разделе «Шаблоны».

Алерт

Уведомление системы мониторинга Deckhouse Platform о событии в кластере или его компонентах.

Стандартная поставка включает набор базовых алертов, которые охватывают состояние кластера и его компонентов. Можно добавлять кастомные алерты. Алерты отправляются во внешние системы через Alertmanager: по SMTP, в PagerDuty, Slack, Telegram или через вебхук.

Список всех алертов системы мониторинга приведён в справочнике «Алерты».

Аренда (lease) в Stronghold

Временные права доступа к секретам и ресурсам в хранилище секретов Deckhouse Stronghold, которые идентифицируются по идентификатору аренды.

Арендой управляют в разделе «Leases» веб-интерфейса Stronghold, где аренду находят по её идентификатору. Вместе с политиками контроля доступа, методами аутентификации и сущностями аренда определяет, кто и как долго может пользоваться хранилищем секретов.

Подробнее в разделе «Веб-интерфейс управления секретами».

Артефакты модуля

Три вида артефактов, которые сборка модуля загружает в хранилище образов контейнеров, — образы контейнеров приложений, образ модуля и релиз. Deckhouse Platform загружает и обновляет модуль из них.

Образы контейнеров приложений тегируются content-based тегами и указываются в шаблонах. Образ модуля собирается по werf.yaml и тегируется семантической версией. Релиз — артефакт версии модуля: у него есть тег семантической версии и тег канала обновлений, по его данным Deckhouse Platform решает, обновлять ли модуль в кластере. Хранилище с артефактами служит источником модулей.

Подробнее в разделе «Сборка и публикация».

Архив образов Deckhouse Platform

Архив образов контейнеров Deckhouse Platform, который создаёт команда d8 mirror pull и загружает в приватное хранилище образов команда d8 mirror push. Так образы платформы доставляются в закрытое окружение.

Архив скачивается из публичного хранилища Deckhouse Platform с лицензионным ключом, обычно на bastion-хосте, и переносится в контур любым разрешённым способом, например на съёмном носителе. По его размеру после d8 mirror push оценивают объём диска приватного хранилища. Команды d8 mirror недоступны в редакциях Community Edition и Basic Edition.

Подробнее в разделе «Установка DP в закрытом окружении».

Аудит API Kubernetes

Журналирование обращений к API-серверу Kubernetes по политике аудита. По умолчанию журнал записывается в файл /var/log/kube-audit/audit.log на master-узлах.

Аудит API Kubernetes отслеживает обращения к API-серверу и помогает разбирать неожиданное поведение и соблюдать требования безопасности. Deckhouse Platform по умолчанию настраивает базовую политику аудита: она пропускает частые служебные обновления, например Endpoints, Events и выборы лидера, и записывает изменения подов, узлов, объектов ServiceAccount и операции в системных неймспейсах. Политику можно дополнить собственными правилами.

Журнал аудита служит источником для рантайм-аудита и событий безопасности.

Подробнее в разделе «Аудит событий API Kubernetes».

База данных уязвимостей

Базы известных уязвимостей, которые использует сканирование образов с помощью Trivy. Модуль operator-trivy скачивает их из хранилища образов каждые 6 часов. Они занимают около 5 ГБ на системных узлах.

Для сканирования используются публичные базы уязвимостей и обогащённые данные для Astra Linux, ALT Linux и РЕД ОС. Образы баз имеют фиксированные имена и теги в хранилище образов, поэтому их можно скопировать в закрытое хранилище для изолированного кластера. Базы хранятся на системных узлах. Если их в кластере нет, базы размещаются на worker-узле. См. также сканирование на уязвимости.

Подробнее в разделе «Разметка и объём дисков».

Балансировка active-active

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

При схеме active-active все кластеры мультикластера обрабатывают трафик одновременно. Трафик направляется в ближайший к клиенту или наименее загруженный кластер либо по иным правилам. Общие данные реплицируются между кластерами. При сбое одного кластера трафик автоматически переключается на работающие. Балансировку настраивает администратор кластера в рамках георезервирования. Альтернативная схема — active-standby.

Подробнее в разделе «Георезервирование».

Балансировка active-standby

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

При схеме active-standby активный кластер мультикластера принимает весь трафик, а резервный бездействует до сбоя активного. Переключение трафика на резервный кластер происходит автоматически при обнаружении проблем. Балансировку настраивает администратор кластера в рамках георезервирования. Альтернативная схема — active-active.

Подробнее в разделе «Георезервирование».

Бандл bashible

Набор скриптов bashible. Используются четыре бандла, скрипты установки bashible, скрипты бутстрапа первого узла, скрипты настройки узла для облачного провайдера и основные скрипты. Отдельный скрипт бандла называется шагом (степом).

Скрипты bashible — это Go-шаблоны, поэтому бандл рендерится для конкретной группы узлов, а каждый шаг должен корректно выполняться при повторном запуске после ошибки. Отрендеренные бандлы отдаёт bashible-api-server. Шаги охватывают основные этапы настройки узла: доступ для NodeUser, CA-сертификаты, бинарные файлы в /opt/deckhouse/bin, пакеты, containerd, kubernetes-api-proxy, kubelet и саму службу bashible.

Подробнее в разделе «Bashible».

Биндинг хука

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

Биндинги хука модуля: onStartup, beforeHelm, afterHelm, kubernetes и schedule. У глобальных хуков есть также beforeAll и afterAll. Хуки пакета Marketplace используют те же виды биндингов, а поле Queue задаёт отдельную очередь для биндингов Schedule и Kubernetes. Хуки с одинаковым биндингом выполняются в порядке значения Order.

Подробнее в разделе «Хуки».

Блочное устройство виртуальной машины

Диск или образ, подключённый к виртуальной машине. Образы подключаются только для чтения или как CD-ROM для ISO-образов, диски подключаются для чтения и записи.

Устройства подключаются двумя способами. Список blockDeviceRefs в спецификации виртуальной машины задаёт порядок загрузки по позиции или полем bootOrder и используется при ручной настройке, например для ISO при установке ОС. VirtualMachineBlockDeviceAttachment подключает диск отдельным ресурсом, который не участвует в порядке загрузки, через шину virtio-scsi, и используется для автоматизации и когда у пользователя нет прав на редактирование машины.

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

Подробнее в разделе «Подключение дисков и образов к виртуальной машине».

Буферизация логов

Временное накопление логов в буфере перед отправкой в систему хранения.

Буферизация сохраняет логи при временных проблемах связи с хранилищем и отправляет их после восстановления соединения, сглаживает всплески нагрузки на хранилище и сокращает число сетевых запросов за счёт отправки логов пакетами. Настраивается параметром buffer объекта ClusterLogDestination в pipeline логов.

Подробнее в разделе «Сбор и доставка логов».

Вариант размещения

Конфигурация кластера, которая определяет количество узлов, распределение ролей между ними и устойчивость кластера к отказу узла.

Вариант размещения выбирают перед установкой. Примеры вариантов: одноузловой кластер, кластер с одним master-узлом, отказоустойчивый кластер с тремя master-узлами и кластер с разделением ролей узлов, в котором под компоненты платформы и входящий трафик выделены системные, frontend- и узлы мониторинга. От варианта размещения зависят требования к ресурсам узлов.

Подробнее в разделе «Варианты размещения» на странице «Системные требования».

Веб-интерфейс Deckhouse

Веб-интерфейс Deckhouse Platform для управления кластером, включая мониторинг, настройку параметров, управление узлами и модулями, настройку безопасности и сети.

Большинство операций, доступных из командной строки через Deckhouse CLI или kubectl, можно выполнить и в веб-интерфейсе. Он открывается по адресу console.<CLUSTER_NAME_TEMPLATE>, где шаблон соответствует шаблону DNS-имён кластера, и содержит разделы Deckhouse, управление узлами, мультитенантность, доступ, сеть, хранилище, безопасность, мониторинг и логирование.

Подробнее в разделе «Веб-интерфейс Deckhouse Platform».

Вес модуля

Число из параметра weight файла module.yaml, которое определяет порядок запуска модулей. Модули с меньшим весом запускаются раньше, по умолчанию вес равен 900.

Если файла module.yaml нет, вес берётся из числового префикса директории модуля, например 040-node-manager означает вес 40. Если получить его не удалось, используется 100. Контроллер Deckhouse учитывает вес только для критичных модулей, задачи которых попадают в очередь main по возрастанию веса. На порядок запуска также влияют зависимости модуля.

Подробнее в разделе «Механизм очередей».

Виртуальная машина (ВМ)

Машина, которую Deckhouse Platform создаёт и которой управляет декларативно через модуль virtualization. Она работает в поде на узле кластера под управлением QEMU/KVM, которым управляет KubeVirt.

Машину описывает VirtualMachine в проекте или неймспейсе. Её диски и образы подключаются как блочные устройства, процессор задаётся числом ядер и долей ядра в пределах класса ВМ, а состояние поддерживает политика запуска. Гостевая система настраивается при первом запуске начальной инициализацией, после чего Deckhouse Platform общается с ней через агента гостевой ОС.

Ядро модуля основано на KubeVirt: процесс QEMU, который libvirtd запускает в контейнере compute пода машины, и есть работающая машина. Машины переезжают между узлами живой миграцией, объединяются в пулы и проходят фазы жизненного цикла виртуальной машины.

Подробнее в разделе «Подсистема Virtualization».

Внешнее хранилище

Системы хранения вне узлов кластера, Ceph, NFS, S3, SCSI и СХД производителей, подключаемые к Deckhouse Platform через модули csi-*, в отличие от программно-определяемых хранилищ.

Deckhouse Platform включает готовые интеграции с распределённым хранилищем Ceph, системами хранения HPE, Huawei и TATLIN.UNIFIED (Yadro), NFS, объектным хранилищем S3 и хранилищами на основе протокола SCSI. Каждая интеграция — модуль с CSI-драйвером. Вторая группа типов хранилищ — программно-определяемые хранилища на дисках узлов кластера.

Подробнее в разделе «Хранилища».

Внутрикластерный кеш образов

Хранилище образов контейнеров, развёрнутое на master-узлах кластера, из которого все узлы получают образы компонентов Deckhouse Platform.

Кеш включается параметром storage.cache в ModuleConfig registry в режиме управления registry Managed. Пока кеш наполняется, upstream-хранилище остаётся резервным путём. В изолированном кластере кеш является единственным источником образов и наполняется командой d8 mirror push.

Возможности неймспейса проекта

Ограничение возможностей проекта на уровне отдельного пользовательского неймспейса внутри проекта.

Набор возможностей пользовательского неймспейса не может превышать набор возможностей его проекта.

Возможности проекта

Набор функциональности платформы, доступный в рамках проекта. Возможности определяют, какие API и виды ресурсов можно использовать в проекте.

Возможности проекта не являются частью ролевой модели. Примеры возможностей: Kubernetes, Virtualization. Возможности отдельного неймспейса внутри проекта ограничиваются возможностями неймспейса проекта.

Встроенный модуль

Модуль, входящий в состав Deckhouse Platform. Его релизный цикл привязан к релизному циклу платформы.

Встроенные модули поставляются вместе с релизом Deckhouse Platform и обновляются вместе с ним. Какие из них включены по умолчанию, зависит от набора модулей и редакции. Второй вид модулей — модули из источника, релизы которых не зависят от релизов платформы.

Подробнее в разделе «Разработка модулей Deckhouse Platform».

Высокоуровневая роль

Роль упрощённой ролевой модели Deckhouse Platform, которую модуль user-authz предоставляет поверх RBAC Kubernetes. User, PrivilegedUser, Editor, Admin, ClusterEditor, ClusterAdmin и SuperAdmin.

Высокоуровневые роли относятся к упрощённой ролевой модели. Модуль user-authz создаёт их как набор ClusterRole и назначает пользователям и группам с помощью ClusterAuthorizationRule и AuthorizationRule. Каждая роль расширяет предыдущую: User просматривает поды, логи и Deployment, Admin управляет RBAC в неймспейсе, ClusterAdmin имеет полный доступ к cluster-wide-ресурсам.

Рекомендуемая гранулярная ролевая модель вместо высокоуровневых ролей использует use-роли и manage-роли. Модели не совместимы по ресурсам, автоматическая конвертация невозможна, но их можно использовать одновременно: права обеих моделей суммируются.

Подробнее в разделе «Упрощённая модель авторизации».

Вытеснение ВМ с узла

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

Условие EvictionRequired появляется, когда узел с машиной переводят в режим обслуживания узла. Узел, который только вывели из планирования, его не вызывает. Сообщение условия говорит, что произойдёт: перенос живой миграцией без остановки гостевой ОС, перезапуск силами Deckhouse Platform с разрешения администратора либо ожидание, пока машину не перезапустят. Пока вытеснение не началось, условие носит предупреждающий характер, потому что обслуживание могут отменить.

После перезапуска машина запускается на другом подходящем узле, а без такого узла остаётся в фазе Pending. Пользователь также может вытеснить машину на другой узел командой d8 v evict или операцией VirtualMachineOperation типа Evict.

Подробнее в разделе «Создание виртуальной машины».

Геораспределённость

Подход к катастрофоустойчивости, при котором компоненты кластера распределяются по нескольким зонам доступности (Multi-AZ) или регионам (Multi-Region), чтобы кластер продолжал работать при отказе зоны или региона.

Геораспределённость снижает влияние отказов инфраструктуры на доступность приложений. Распределение узлов по зонам доступности защищает приложения от отказа одной зоны в ЦОДе или облаке. Распределение по регионам позволяет приложениям пережить выход из строя целого ЦОДа или облачного провайдера при условии, что приложение может работать в каждом регионе автономно.

За сетевую связность между узлами кластера, балансировку входящего трафика средствами облачного провайдера или внутреннего балансировщика и организацию хранилищ отвечает администратор платформы. Геораспределённость — один из двух подходов к катастрофоустойчивости в Deckhouse Platform. Второй — георезервирование.

Подробнее в разделе «Геораспределённость».

Георезервирование

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

Для георезервирования в каждом регионе разворачивают по одному кластеру Deckhouse Platform и объединяют их декларативным API в мультикластер: с помощью встроенного сервис-меша на основе Istio или сетевого функционала платформы на базе Cilium. Приложение должно уметь работать параллельно в разных регионах, а между регионами должен существовать стабильный сетевой канал. Правильно настроенная система сохраняет работу приложения даже при выходе из строя целого региона или облака.

Входящий трафик в мультикластере балансирует внешний балансировщик по одной из двух схем: active-active или active-standby. Балансировку и организацию хранилищ настраивает администратор кластера. Георезервирование — один из двух подходов к катастрофоустойчивости. Второй — геораспределённость.

Подробнее в разделе «Георезервирование».

Гибридная группа узлов

Группа узлов, в которую входят как Static-узлы, развёрнутые в облаке, так и серверы в собственном ЦОД, bare metal или виртуальные машины.

В гибридной группе узлов основную нагрузку могут нести серверы bare metal, а облачные инстансы служат масштабируемым дополнением при пиковых нагрузках. Все узлы группы — статические, поэтому модуль node-manager работает так же, как для статических узлов. Единственное требование — L3-связность между ЦОД и облаком. Гибридная группа узлов отличается от гибридного кластера, в котором статические узлы сочетаются с узлами CloudEphemeral.

Подробнее в разделе «Гибридные группы узлов и кластеры».

Гибридный кластер

Статический кластер Deckhouse Platform, расширенный узлами в инфраструктуре поддерживаемого облачного провайдера.

Control plane и первоначальные узлы остаются частью статического кластера. Дополнительные узлы добавляются через модуль облачного провайдера: либо создаются автоматически через API провайдера как узлы CloudEphemeral, либо создаются заранее и подключаются bootstrap-скриптом как узлы CloudStatic.

Гибридному кластеру нужна L3-связность между дата-центром и облаком.

Подробнее в разделе «Гибридные кластеры».

Глобальные настройки

Настройки Deckhouse Platform, которые действуют на весь кластер. Хранятся в ModuleConfig с именем global.

Глобальные настройки можно рассматривать как особый модуль global, который нельзя выключить. Настройки остальных модулей хранятся в отдельных ModuleConfig с именами модулей.

Подробнее в разделе «Глобальные настройки».

Группа узлов

Набор узлов кластера с общими параметрами, описанный в NodeGroup. NodeGroup задаёт тип узлов, их количество и конфигурацию, а Deckhouse Platform приводит узлы в соответствие с ней.

Группы узлов логически разделяют инфраструктуру кластера. Типичные группы: master для control plane, front для frontend-узлов, monitoring для узлов мониторинга, system для системных узлов и worker для пользовательских приложений.

У каждой группы централизованные настройки: версия Kubernetes, ресурсы, taints, лейблы и параметры kubelet. При создании или изменении NodeGroup модуль node-manager приводит узлы группы к заданной конфигурации. Тип узлов один из: Static, CloudEphemeral, CloudPermanent или CloudStatic.

Подробнее в разделе «Основы управления узлами».

Дашборд

Набор графиков и таблиц с данными о состоянии кластера и запущенных в нём приложений. Deckhouse Platform поставляет предустановленные дашборды и позволяет создавать пользовательские.

Дашборды показывают загрузку CPU, потребление памяти, дисковую и сетевую активность, а также состояние подов, контроллеров, узлов и неймспейсов. Они доступны в веб-интерфейсе Deckhouse в разделе «Мониторинг» → «Дашборды».

Предустановленные дашборды поставляются вместе с Deckhouse Platform и не редактируются. Пользовательские дашборды создаются с помощью объекта ObservabilityDashboard модуля observability на уровне неймспейса с управлением доступом или с помощью объекта GrafanaDashboardDefinition на уровне кластера, этот способ считается устаревшим.

Подробнее в разделе «Дашборды мониторинга».

Диск виртуальной машины

Хранилище данных виртуальной машины, включая операционную систему и файлы приложений. Диск описывается параметрами хранения, то есть StorageClass и размером, и источником данных, которым может быть образ, другой диск или снимок.

Диск описывает VirtualDisk. Без источника данных создаётся пустой диск заданного размера. При заданном источнике Deckhouse Platform берёт размер из источника и подбирает по нему класс хранения. Поведение диска зависит от хранилища за StorageClass: на томах файловой системы диск создаётся в формате qcow2, на блочных устройствах данные пишутся напрямую, а режим привязки тома определяет, создаётся диск сразу или только после подключения к виртуальной машине.

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

Подробнее в разделе «Диски виртуальных машин».

Долговременное хранилище метрик

Отдельное хранилище, например VictoriaMetrics, в которое Prometheus отправляет метрики с помощью механизма remote_write.

В Deckhouse Platform отправка метрик в долговременное хранилище настраивается с помощью объекта PrometheusRemoteWrite.

Подробнее в разделе «Запись данных Prometheus в долговременное хранилище».

Доля ядра

Гарантированная доля мощности каждого виртуального ядра виртуальной машины, которую задаёт параметр coreFraction. Без него каждое виртуальное ядро получает 100% физического.

Машине с cores: 2 и coreFraction: 20% гарантированы 0,4 ядра в сумме независимо от загрузки узла, а при свободных ресурсах узла она может занять оба ядра целиком. Такой запас позволяет держать на узле больше машин, чем на нём физических ядер. Так работает переподписка CPU. Гарантированная доля учитывается при выборе узла, поэтому машина не запустится там, где узел не может обеспечить гарантии всем размещённым на нём машинам.

Администратор может ограничить допустимые значения в политике сайзинга класса ВМ. В коммерческих редакциях значение coreFraction: Auto позволяет Deckhouse Platform подбирать долю по фактическому потреблению машины.

Подробнее в разделе «Процессор и память виртуальной машины».

Дополнительная сеть

Программно-определяемая сеть для подов и виртуальных машин поверх основной сети кластера, которую предоставляет модуль sdn. Дополнительные сети делятся на кластерные сети и сети проекта.

Кластерная сеть общедоступна в каждом проекте и управляется администратором. Сеть проекта доступна в пределах одного неймспейса и создаётся пользователем. Поды подключают к дополнительным сетям аннотацией пода, виртуальные машины — списком сетей в спецификации машины. IP-адреса на дополнительных интерфейсах назначает IPAM модуля sdn.

Подробнее в разделе «Дополнительные сети для использования в прикладных подах».

Дополнительный неймспейс проекта

Пользовательский неймспейс, который создаётся в рамках проекта в дополнение к основному. Используется только для запуска полезной нагрузки.

Дополнительные неймспейсы позволяют логически разделить полезную нагрузку внутри проекта и применять к её частям отдельные политики доступа. Как и основной неймспейс проекта, дополнительный неймспейс проекта является пользовательским неймспейсом.

Доступность модуля

Настройки accessibility в module.yaml, которые определяют, в каких редакциях Deckhouse Platform модуль доступен и в каких наборах модулей включён по умолчанию.

Настройки задаются для каждой редакции, блок _default действует для редакций без собственных настроек: available определяет, можно ли использовать модуль в редакции, enabledInBundles перечисляет наборы модулей (Default, Managed, Minimal), в которых модуль включён без ModuleConfig.

Подробнее в разделе «Структура модуля».

Живая миграция

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

Живая миграция используется при балансировке нагрузки, при освобождении узла для обслуживания или обновления и при обновлении прошивки виртуальной машины, которое иначе потребовало бы перезапуска. Узел передаёт память только одной виртуальной машины за раз и принимает только одну входящую миграцию, а скорость передачи одной миграции ограничена 640 МиБ/с. Перебалансировка ВМ также переносит машины живой миграцией.

Подробнее в разделе «Обслуживание узлов с виртуальными машинами».

Жизненный цикл виртуальной машины

Фазы, через которые виртуальная машина проходит от создания до удаления и которые показывает её статус. Условия объясняют, почему машина находится в текущей фазе.

В фазе Pending машина ждёт готовности зависимых ресурсов: дисков, образов, класса ВМ и секрета со сценарием начальной инициализации. В фазе Starting Deckhouse Platform запускает машину на одном из узлов, в Running она работает, в Migrating переезжает на другой узел живой миграцией, фаза Terminating необратима.

Блок .status.conditions отвечает, почему машина в своей фазе: условия, оканчивающиеся на Ready, показывают, что блокирует запуск, Running сообщает причину от планировщика, Migratable показывает, можно ли перенести машину, EvictionRequired предупреждает о вытеснении с узла. Как машина поддерживается в работе, определяет политика запуска.

Подробнее в разделе «Создание виртуальной машины».

Зависимости модуля

Набор условий (требований), которые должны выполняться, чтобы Deckhouse Platform мог запустить модуль. Объявляются в секции requirements файла module.yaml.

Модуль может зависеть от версии Deckhouse Platform, версии Kubernetes и версий других модулей. Зависимости от других модулей вместе с весом модуля влияют на порядок запуска, а зависимость может быть условной. Пакет Marketplace объявляет такие же требования в package.yaml, включая группы альтернативных и несовместимых модулей.

Подробнее в разделе «Зависимости модулей Deckhouse Platform».

Закрытое окружение

Окружение без прямого доступа к публичному хранилищу образов контейнеров Deckhouse Platform и к внешним репозиториям пакетов. Доступ идёт через прокси-сервер или через хранилище образов, развёрнутое внутри периметра.

Параметры прокси-сервера, заданные в конфигурации кластера при установке, транслируются в переменные окружения узлов кластера и компонентов Deckhouse Platform. Пользовательские приложения не получают их автоматически. Взаимодействие с узлами кластера обычно идёт через bastion-хост, а приватное хранилище образов размещается на отдельной машине во внутренней сети. Если доступ к внешним ресурсам отсутствует полностью, прокси не используется, необходимые артефакты доставляются в контур другими способами, а кластер является изолированным.

Подробнее в разделе «Установка DP в закрытом окружении».

Запечатывание хранилища Stronghold

Состояние хранилища секретов Deckhouse Stronghold, в котором оно не может ни читать, ни записывать секреты. Хранилище запечатывают и распечатывают в веб-интерфейсе Stronghold.

Раздел «Seal Stronghold» веб-интерфейса показывает текущее состояние хранилища секретов и кнопку, которая запечатывает или распечатывает его. Пока хранилище запечатано, модуль stronghold не обрабатывает запросы на чтение и запись секретов.

Подробнее в разделе «Веб-интерфейс управления секретами».

Защищённые параметры

Параметры кластера, критичные для его работы, которые по умолчанию нельзя изменить в работающем кластере. podSubnetCIDR, podSubnetNodeCIDRPrefix и serviceSubnetCIDR.

Защищённые параметры входят в конфигурацию кластера. Попытка изменить их блокируется admission-вебхуком с сообщением об ошибке. Порядок их изменения, с помощью установщика или вручную, описан в документации.

Подробнее в разделе «Конфигурация Deckhouse Platform».

Зона доступности

Базовая единица катастрофоустойчивой архитектуры: логическая группа из одного или нескольких ЦОДов, расположенных на расстоянии нескольких километров друг от друга и рассматриваемых как изолированная единица. Зоны доступности входят в состав регионов.

Зона доступности (Availability Zone, AZ) физически является распределённой инфраструктурой, которую можно рассматривать как виртуальный дата-центр. ЦОДы одной зоны разнесены на достаточное расстояние (обычно не более 10 км), чтобы пережить локальные инциденты, например наводнение или пожар, при этом сохраняют низкую сетевую задержку между собой, имеют независимое электроснабжение и используют разных провайдеров и маршруты. Несколько зон образуют регион.

Deckhouse Platform позволяет распределять узлы кластера по зонам доступности (Multi-AZ), чтобы приложения продолжали работать при недоступности одной из зон ЦОДа или облака. В большинстве облачных провайдеров распределение по зонам происходит автоматически. Вне облаков администратор маркирует узлы лейблом зоны. Это одна из форм геораспределённости.

Подробнее в разделе «Геораспределённость».

Изолированный кластер

Кластер без доступа к внешнему хранилищу образов контейнеров. Единственный источник образов для него — внутрикластерный кеш.

В режиме управления registry Managed кластер считается изолированным, если не задан параметр primary.upstream. Внутрикластерный кеш при этом наполняется командой d8 mirror push и выполняет роль хранилища образов компонентов Deckhouse Platform.

Подробнее в разделе «Управление хранилищем образов в кластерах, полностью управляемых DP».

Инлет

Способ поступления входящего трафика в балансировщик уровня приложений — Ingress NGINX Controller или шлюз модуля alb. Задаётся в поле inlet объектов IngressNginxController, ClusterALBInstance и ALBInstance.

Для Ingress-контроллера инлет принимает одно из значений LoadBalancer, LoadBalancerWithProxyProtocol, HostPort или HostWithFailover. Инлеты LoadBalancer и LoadBalancerWithProxyProtocol используют балансировщик нагрузки облачного провайдера или встроенный модуль metallb. Инлет HostPort публикует контроллер на портах узлов, например за внешним балансировщиком нагрузки. Инлет HostWithFailover применяется на bare metal, где контроллер работает на frontend-узлах.

Для шлюзов модуля alb инлет принимает одно из значений LoadBalancer, HostPort или ClusterIP. Для ClusterALBInstance доступны LoadBalancer и HostPort, для ALBInstance — LoadBalancer и ClusterIP. Инлет ClusterIP принимает трафик через сервис с типом ClusterIP, без внешней точки входа.

Примеры для каждого инлета приведены в разделах «ALB средствами Ingress NGINX Controller» и «Инлеты» страницы «ALB средствами Kubernetes Gateway API».

Инстанс-класс

Ресурс конкретного провайдера, например OpenStackInstanceClass или AWSInstanceClass, который описывает параметры виртуальных машин, создаваемых Deckhouse Platform для группы узлов.

Группа узлов с узлами CloudEphemeral ссылается на инстанс-класс в параметре cloudInstances.classReference. Инстанс-класс задаёт тип машины, образ, диски и другие параметры провайдера, а количество узлов и их зоны задаёт группа узлов.

Подробнее в разделе «Добавление и управление облачными узлами».

Инфраструктурный узел

Собирательное название master-, frontend-, системных узлов и узлов мониторинга кластера в отличие от worker-узлов, на которых работают пользовательские приложения.

На инфраструктурных узлах работают control plane кластера и компоненты Deckhouse Platform. Рекомендуемые минимальные ресурсы зависят от роли: master-узлам и узлам мониторинга нужны быстрые диски, frontend-узлам требуется меньше всего ресурсов, а размер системных узлов зависит от того, есть ли в кластере выделенные узлы мониторинга.

Подробнее в разделе «Подготовка к production».

Источник модулей

Хранилище образов контейнеров, из которого Deckhouse Platform получает сведения о модулях, не входящих в состав платформы. Задаётся с помощью объекта ModuleSource с адресом хранилища и параметрами аутентификации.

Модули из источника публикуются в хранилище как артефакты модуля. Deckhouse Platform синхронизируется с источником и создаёт релизы модулей по политике обновления модуля. Затем модуль включается с помощью ModuleConfig. В изолированном кластере источник указывает на внутрикластерное или приватное хранилище.

Подробнее в разделе «Как запустить и проверить модуль в кластере DP».

Канал обновлений

Один из пяти каналов, от Alpha до Rock Solid, по которым каждая новая версия Deckhouse Platform распространяется постепенно. Кластер получает версии, опубликованные на выбранном канале.

Каждая новая версия сначала публикуется на канале Alpha, затем переходит на Beta, Early Access, Stable и Rock Solid. На Early Access версия появляется не раньше чем через 7 дней после выпуска, на Stable — через 14 дней, на Rock Solid — через 30 дней.

Канал кластера задаётся в параметре settings.releaseChannel модуля deckhouse. Как применяется новая версия, зависит от режима обновления и окон обновлений.

Подробнее в разделе «Обновление».

Канал уведомлений

Канал доставки, по которому система мониторинга Deckhouse Platform отправляет алерты получателям, например Telegram, электронная почта или вебхук.

Каналы уведомлений, политики уведомлений и отключение уведомлений настраиваются в модуле observability. Алерты доставляет Alertmanager, который в Deckhouse Platform поддерживает мультитенантность: алерты разделяются на системные (кластерные) и проектные, а каналы и политики доставки настраиваются отдельно в каждом проекте.

Подробнее в разделе «Модуль observability».

Катастрофоустойчивость

Способность инфраструктуры на базе Deckhouse Platform сохранять работоспособность при масштабных отказах. Обеспечивается распределённым развёртыванием, автоматическим переключением трафика и репликацией критически важных компонентов.

В Deckhouse Platform реализовано два подхода к катастрофоустойчивости. Геораспределённость размещает компоненты одного кластера в нескольких зонах доступности или регионах. Георезервирование объединяет несколько независимых кластеров в мультикластер и перенаправляет трафик в другой кластер, когда один из них становится недоступен.

Оба подхода требуют сетевой связности между узлами и регионами, балансировки трафика и подходящей организации хранилищ. Выбор архитектуры зависит от приложений и ограничений инфраструктуры. Избыточность критичных компонентов внутри одного кластера обеспечивает режим HA.

Подробнее в разделе «Катастрофоустойчивость».

Кворум

Большинство участников распределённой системы (больше половины от их общего числа), которые должны быть доступны, чтобы система продолжала работать и принимать изменения.

В Deckhouse Platform кворум важен прежде всего для etcd — хранилища control plane. Кластер etcd принимает изменения, только пока доступно большинство его участников (N/2 + 1): кластер из трёх участников выдерживает отказ одного участника, кластер из пяти — отказ двух. Чётное число участников не повышает отказоустойчивость: при двух участниках отказ любого из них приводит к потере кворума. Поэтому используйте нечётное число master-узлов, как правило три. В конфигурации с двумя master-узлами третий экземпляр etcd может работать на arbiter-узле, который обеспечивает кворум.

Подробнее в разделе «Отказоустойчивость» руководства по восстановлению control plane.

Кеширующий DNS-сервер

DNS-сервер, который модуль node-local-dns запускает на каждом узле кластера. Он кеширует ответы DNS и убирает сетевой обмен с кластерным DNS для повторяющихся запросов.

На каждом узле модуль настраивает интерфейс с IP-адресом сервиса kube-dns, запускает на этом адресе кеширующий CoreDNS и добавляет правило iptables, которое перенаправляет DNS-трафик на него, пока открыт его сокет. Иначе используется стандартная маршрутизация через кластерный DNS. Внешние запросы, которых ещё нет в кеше, по-прежнему сначала разрешаются через цепочку внутренних зон, но под нагрузкой одного кеширования достаточно, чтобы заметно ускорить разрешение имён.

Подробнее в разделе «Кеширующий DNS-сервер в кластере».

Класс приоритета

Один из объектов PriorityClass, которые Deckhouse Platform создаёт в кластере и назначает своим компонентам. При нехватке ресурсов планировщик первыми вытесняет поды с более низким приоритетом.

Приложения используют класс приоритета через параметр priorityClassName. Под без него считается наименее приоритетным. Классы упорядочены от system-node-critical и system-cluster-critical, зарезервированных для критичных компонентов кластера, через production-high, production-medium, production-low и staging до develop, который используется по умолчанию. Дополнительные классы создаются с именем и числовым значением приоритета. Классы приоритета также задают порядок вытеснения при перераспределении подов.

Подробнее в разделе «Классы приоритета».

Кластер

Группа взаимосвязанных узлов под управлением Deckhouse Platform, которая обеспечивает единую среду для развёртывания, масштабирования и обслуживания полезной нагрузки.

Кластер состоит из системы, которая обеспечивает его работу, и полезной нагрузки, которая запускается в кластере.

Кластер с одним master-узлом

Режим работы control plane с одним master-узлом. kube-apiserver использует только локальный экземпляр etcd и слушает только адрес master-узла.

Запросы на localhost обрабатывает прокси-сервер на узле. При добавлении или удалении master-узлов Deckhouse Platform переводит control plane между режимами с одним master-узлом и мультимастерным.

Подробнее в разделе «Масштабирование и изменение master-узлов».

Кластер, полностью управляемый Deckhouse Platform

Кластер, в котором Deckhouse Platform управляет и control plane, и узлами. Противоположность — Managed Kubernetes-кластер, в котором control plane управляет облачный провайдер.

Deckhouse Platform можно установить и в существующий Managed Kubernetes-кластер, например GKE, EKS или AKS. В этом случае Deckhouse Platform не управляет control plane, а часть возможностей ограничена API облачного провайдера: например, управление узлами и модуль registry доступны только в кластерах, полностью управляемых Deckhouse Platform.

Подробнее в разделе «Установка платформы».

Кластерная сеть

Дополнительная программно-определяемая сеть, общедоступная в каждом проекте кластера, которую настраивает администратор и которой он управляет.

Примеры кластерной сети: публичная WAN-сеть или shared-сеть для обмена трафиком между проектами. Администратор создаёт её с помощью объекта ClusterNetwork модуля sdn и при необходимости включает для неё IPAM с пулом адресов в масштабе кластера. Чтобы использовать такую сеть в подах приложений, обратитесь к администратору кластера. Второй вид дополнительной сети — сеть проекта.

Подробнее в разделе «Программно-определяемые сети (SDN)».

Клон виртуальной машины

Копия виртуальной машины, созданная из существующей машины или из её снимка. Клон получает новый IP-адрес и новые MAC-адреса, лейблы на него не копируются.

Поскольку клон копирует машину, ресурсам новой машины нужны уникальные имена: nameReplacements заменяет имена конкретных ресурсов, а customization добавляет префикс или суффикс к именам всех клонируемых ресурсов, например дисков и IP-адресов.

Клон получает новый IP-адрес в кластерной сети и новые MAC-адреса дополнительных интерфейсов, поэтому сетевые параметры гостевой ОС нужно перенастроить. Лейблы не копируются, поэтому клон не получает трафик Service, пока ему не добавят нужные лейблы. Источником клона может быть снимок машины.

Подробнее в разделе «Клонирование виртуальных машин».

Конверсия параметров модуля

Правило в директории openapi/conversions модуля, которое преобразует параметры модуля из одной версии OpenAPI-спецификации в следующую, например при переименовании или переносе параметра.

Каждая конверсия работает между двумя смежными версиями и хранится в файле v<N>.yaml вместе с тестами. Цепочка конверсий должна покрывать все версии спецификации параметров без пропусков, чтобы Deckhouse Platform автоматически преобразовывал настройки модуля при смене версии схемы его настроек.

Подробнее в разделе «Структура модуля».

Консистентный снимок

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

Требование консистентного снимка задаёт параметр requiredConsistency, по умолчанию true. У работающей машины файловую систему замораживает агент гостевой ОС. Его скрипты hooks также могут подготовить приложения к снимку без остановки сервисов.

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

Подробнее в разделе «Снимки дисков и виртуальных машин».

Контроллер Deckhouse

Контроллер модуля deckhouse, который реализует операции по управлению платформой и координирует их с помощью механизма очередей. Модуль deckhouse — единственный модуль, без которого Deckhouse Platform не может работать.

Контроллер Deckhouse управляет модулями: запускает их хуки, применяет настройки модулей и устанавливает релизы модулей. Задачи обрабатываются в очередях addon-operator. В режиме HA запускается несколько экземпляров контроллера, которые выбирают лидера через Lease deckhouse-leader-election. Все операции управления выполняет лидер.

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

Подробнее в разделе «Модуль deckhouse».

Контроль целостности

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

В Deckhouse Platform доступны три механизма: проверка подписи образов пользовательской нагрузки на этапе валидации запросов к API Kubernetes, рантайм-аудит работающих контейнеров и защита целостности модулей Deckhouse Platform. Криптографическая проверка подписи образов на уровне контейнерного рантайма (CRI) с защитой распакованных слоёв через DM-Verity доступна только в сертифицированных редакциях.

Начиная с версии 1.74 модули устанавливаются как образы EROFS, смонтированные только для чтения через DM-Verity, что защищает установленный модуль от подмены и изменения на узле. Механизм включается автоматически, если ОС узла поддерживает модуль ядра erofs. Без него Deckhouse Platform продолжает работу и выводит алерт.

Подробнее в разделе «Контроль целостности».

Конфигурация кластера (ClusterConfiguration)

Структура с общими параметрами кластера, такими как версия Kubernetes, сетевые настройки, параметры CRI и тип кластера.

Конфигурация кластера задаётся при установке и редактируется в работающем кластере командой d8 system edit cluster-configuration. После сохранения изменений Deckhouse Platform приводит состояние кластера в соответствие с новой конфигурацией. Часть параметров защищена и по умолчанию не может быть изменена в работающем кластере.

Параметр clusterType определяет, является кластер статическим или облачным.

Подробнее в разделе «Конфигурация Deckhouse Platform».

Кратковременное хранение логов

Встроенное хранилище логов Deckhouse Platform в кластере на базе Grafana Loki. Интегрировано со сбором логов и подключено к Grafana как источник данных.

Хранилище предоставляется модулем loki, в настройках которого задаются размер диска, срок хранения, StorageClass и ресурсы. Логи системных компонентов поступают в него после настройки pipeline логов. Сбор логов пользовательских приложений настраивается отдельно. Хранилище не поддерживает режим высокой доступности, поэтому для длительного хранения важных логов используют внешнее хранилище.

Подробнее в разделе «Кратковременное хранение логов».

Критичность алерта

Параметр Severity (S) алерта, который означает уровень критичности, от S1 для критического сбоя с незамедлительными действиями до S4–S9 для проблемы низкого уровня, не нарушающей работоспособность.

В описании каждого алерта есть параметр Severity со значением от S1 до S9:

• S1 — максимальный уровень, критический сбой, требуются незамедлительные действия;
• S2 — высокий уровень, близкий к максимальному, возможная авария, необходимо быстрое реагирование;
• S3 — средний уровень, потенциально серьёзная проблема, необходима проверка;
• S4–S9 — низкий уровень, проблема есть, но в целом работоспособность не нарушена.

Критичность каждого алерта указана в списке алертов.

Критичный модуль

Модуль с параметром critical, равным true, в module.yaml. Он запускается при начальной инициализации кластера, до того как кластер считается полностью готовым. Остальные модули запускаются только после этого.

Контроллер Deckhouse помещает задачи критичных модулей в очередь main по возрастанию веса модуля. Некритичные модули обрабатываются в параллельных очередях без учёта веса. Если критичные модули можно обработать параллельно, контроллер запускает их пакетом и ждёт завершения, прежде чем продолжить очередь main.

Подробнее в разделе «Механизм очередей».

Лимит подов на узел

Максимальное количество подов, которые могут быть размещены на узле. В Deckhouse Platform он вычисляется из размера подсети узла, задаваемого параметром podSubnetNodeCIDRPrefix при развёртывании кластера.

При префиксе 24 и больше узел вмещает 120 подов, при 23 — 250, при 22 — 500, при 21 и меньше — 1000. Параметр относится к защищённым параметрам кластера, поэтому выбирайте значение при развёртывании, если на узлах ожидается много подов. Компоненты control plane для высокой плотности подов Deckhouse Platform настраивает автоматически.

Подробнее в разделе «Высокая плотность подов».

Лицензионный ключ

Учётные данные, необходимые для использования коммерческих редакций Deckhouse Platform.

Лицензионный ключ нужен, чтобы получать образы коммерческих редакций из registry.deckhouse.ru, например при обновлении кластера в закрытом окружении командой d8 mirror pull.

Подробнее в разделе «Обновление DP в закрытом окружении».

Локальное хранилище

Хранилище на локальных дисках узла. Оно снижает сетевые задержки и даёт более высокую производительность, чем хранилища с доступом по сети.

Локальное хранилище относится к программно-определяемым хранилищам и обеспечивается модулем sds-local-volume, который поддерживает режимы LVM и LVMThin. Оно эффективно в тестовых средах и EDGE-кластерах.

Подробнее в разделе «Настройка локального хранилища на основе LVM».

Механизм секретов Stronghold

Компонент хранилища секретов Deckhouse Stronghold, который хранит и выдаёт секреты одного вида, например пары «ключ — значение» (KV) или сертификаты (PKI).

Механизмами секретов управляют в веб-интерфейсе Stronghold: для каждого механизма показаны список секретов (роли, ключи и другие), его конфигурация и кнопка добавления нового секрета. Веб-интерфейс предоставляет модуль stronghold, он открывается по адресу stronghold.<CLUSTER_NAME_TEMPLATE>.

Подробнее в разделе «Веб-интерфейс управления секретами».

Минорная версия

Релиз Deckhouse Platform с новыми функциями.

Минорная версия — один из двух видов релиза Deckhouse Platform, второй вид — патч-версия. Минорные версии устанавливаются последовательно: если кластер отстаёт от канала обновлений на несколько минорных версий, Deckhouse Platform восстанавливает промежуточные релизы, потому что они содержат миграции, которые должны применяться по порядку. В режиме обновления Manual минорная версия требует подтверждения.

Подробнее в разделе «Обновление».

Модуль

Набор ресурсов и приложений, который добавляет новые возможности в Deckhouse Platform.

Модули выполняют взаимосвязанные функции, например сбор метрик, балансировку трафика или работу с секретами. Документация модуля и его API доступна в библиотеке модулей.

Модуль из источника

Модуль, который Deckhouse Platform получает из источника модулей, а не из собственной поставки. Его релизный цикл не привязан к релизному циклу платформы.

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

Подробнее в разделе «Обновление DP в закрытом окружении».

Мониторинг SLA

Сбор модулем upmeter статистики о доступности компонентов кластера и компонентов Deckhouse Platform для оценки выполнения SLA.

Данные о доступности показываются в веб-интерфейсе, их можно экспортировать по протоколу Prometheus Remote Write с помощью объекта UpmeterRemoteWrite.

Подробнее в разделе «Мониторинг SLA кластера».

Мультикластер

Модель межкластерного взаимодействия, которая тесно объединяет кластеры. Кластеры используют общие неймспейсы, а сервисы одного кластера доступны другим как локальные.

Доступ к сервисам других кластеров можно ограничить политиками авторизации. Модель реализуется средствами Istio через модуль istio и строится на сервис-меше. Модель для независимых кластеров — федерация.

Подробнее в разделе «Межкластерное взаимодействие».

Мультимастерный кластер

Режим работы control plane с несколькими master-узлами. kube-apiserver взаимодействует со всеми экземплярами etcd, а при недоступности локального kube-apiserver запросы перенаправляются на другие узлы.

Мультимастерный режим обеспечивает высокую доступность control plane и масштабирование master-узлов. Если в кластере больше одного master-узла, режим HA включается автоматически. В конфигурации с двумя master-узлами кворум etcd обеспечивает arbiter-узел.

Подробнее в разделе «Масштабирование и изменение master-узлов».

Набор модулей

Именованный набор встроенных модулей Deckhouse Platform, которые включены по умолчанию. Default, Minimal или Managed.

Набор задаётся в параметре bundle модуля deckhouse и не может быть изменён в развёрнутом кластере. Default — рекомендуемый набор для работы кластера: мониторинг, авторизация, сеть и другие базовые модули. Managed — набор для managed-кластеров облачных провайдеров. Minimal — минимальный набор.

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

Подробнее в разделе «Конфигурация Deckhouse Platform».

Начальная инициализация ВМ

Первичная настройка гостевой системы виртуальной машины при первом запуске сценарием инициализации, Cloud-Init для Linux или Sysprep для Windows.

Сценарий инициализации создаёт пользователей, задаёт пароли и SSH-ключи, устанавливает программы, выполняет команды и включает службы, например агент гостевой ОС. Конфигурация Cloud-Init записывается в формате YAML и начинается с заголовка #cloud-config.

Реплики пула виртуальных машин различаются начальной инициализацией, поэтому операционные системы без неё, тип ОС Legacy, в пулах не поддерживаются.

Подробнее в разделе «Начальная инициализация и агент гостевой ОС».

Неймспейс

Механизм логической группировки объектов в Kubernetes.

Примеры объектов Kubernetes, которые можно сгруппировать с помощью неймспейса: Pod, Deployment, Service, Ingress, ConfigMap.

Неймспейсы часто применяются для изоляции, но без дополнительной настройки они её не обеспечивают, в отличие от проектов в Deckhouse Platform.

Неймспейсы делятся на системные и пользовательские.

Облачный кластер

Кластер с типом clusterType: Cloud. Deckhouse Platform имеет доступ к API облачной инфраструктуры и сам создаёт виртуальные машины узлов и управляет ими.

Установщик создаёт все нужные ресурсы, такие как виртуальные машины и сети, по <PROVIDER>ClusterConfiguration облачного провайдера. Master-узлы облачного кластера — это узлы CloudPermanent, рабочие узлы обычно узлы CloudEphemeral.

Подробнее в разделе «Установка платформы».

Облачный провайдер

Облачная платформа или система виртуализации, с которой Deckhouse Platform интегрирован через модуль cloud-provider-*, чтобы создавать виртуальные машины, подключать их к кластеру как узлы и создавать базовые ресурсы инфраструктуры.

Порядок работы одинаков для всех провайдеров, различаются только подготовительные шаги, например создание сервисного аккаунта, и файлы конфигурации. Интеграция позволяет использовать узлы CloudEphemeral, которые Deckhouse Platform создаёт и удаляет через API провайдера, и выбирать схему размещения.

Подробнее в разделе «Интеграция с IaaS».

Образ виртуальной машины

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

Образ описывает VirtualImage. Его источником может быть HTTP-сервер с файлом образа, хранилище образов контейнеров, файл, загруженный из командной строки, другой образ, диск виртуальной машины или снимок диска. Загруженный образ хранится либо в DVCR, либо в PVC. Образ в PVC годится для создания дисков только в том же классе хранения.

Чтобы образ был доступен всем проектам кластера, администратор создаёт кластерный образ ClusterVirtualImage. К виртуальной машине образы подключаются как блочные устройства: только для чтения или как CD-ROM для ISO-образов.

Подробнее в разделе «Образы виртуальных машин».

Образ канала обновлений

Образ release-channel в хранилище образов Deckhouse Platform, тег которого совпадает с названием канала обновлений. Тег указывает на образ конкретной версии Deckhouse Platform и переносится на новый образ при выпуске новой версии.

Образ содержит version.json с текущей версией канала обновлений и changelog.yaml. Когда версия в образе меняется, Deckhouse Platform создаёт объект DeckhouseRelease и начинает обновление. Выкат можно остановить, добавив в образ флаг suspend, тогда релиз становится приостановленным. В закрытом окружении образ копируется в приватное хранилище вместе с архивом образов.

Подробнее в разделе «Обновление DP в закрытом окружении».

Одноузловой кластер

Кластер из одного узла, который выполняет все роли узлов. У него нет отказоустойчивости, он предназначен для ознакомления с продуктом или задач с невысокими требованиями к ресурсам.

После снятия taint с узла на нём запускаются все компоненты кластера из выбранного набора модулей. Требования к ресурсам такого узла зависят от типа нагрузки: контейнеры, виртуальные машины или и то и другое. Не используйте одноузловые кластеры в production-окружениях.

Подробнее в разделе «Требования к ресурсам» на странице «Системные требования».

Окно обновлений

Интервал времени, в который Deckhouse Platform может устанавливать обновления автоматически. Вне окон новые версии не устанавливаются.

Окна обновлений задаются в параметре update.windows модуля deckhouse. Если окна не настроены, обновление применяется сразу после появления новой версии на канале обновлений.

Для disruptive-обновлений узлов есть отдельные окна в параметрах NodeGroup disruptions.automatic.windows и disruptions.rollingUpdate.windows.

Подробнее в разделе «Настройка обновлений».

Основная сеть кластера

Сеть, в которой каждая виртуальная машина получает IP-адрес. Она привязана к основному сетевому интерфейсу пода, в котором работает машина.

В списке сетей виртуальной машины основная сеть кластера имеет тип Main. Указывать её необязательно, но если она указана, она должна быть первой. Добавление или удаление основной сети, в отличие от дополнительных сетей, требует перезагрузки машины, поскольку её нельзя изменить на работающем поде. Подсети, из которых машины получают адреса, задаются в virtualMachineCIDRs модуля virtualization. Если для основной сети настроен пул адресов в модуле sdn, адресами управляет общий IPAM.

Подробнее в разделе «IP-адреса виртуальных машин».

Основной неймспейс проекта

Пользовательский неймспейс, который создаётся вместе с проектом. Используется для управления дополнительными неймспейсами проекта и запуска полезной нагрузки.

Основной неймспейс проекта — это пользовательский неймспейс, который создаётся в рамках проекта. Из него управляют дополнительными неймспейсами проекта.

Очередь addon-operator

Очередь задач контроллера Deckhouse, в которой обрабатываются встроенные модули и модули из источника. Каждая очередь — отдельный конвейер с одним обработчиком, который выполняет задачи с головы очереди до успешного завершения.

Контроллер Deckhouse создаёт три вида очередей:

• очередь main, которая выполняет глобальные хуки при старте, устанавливает критичные модули, настраивает и удаляет модули;
• несколько параллельных очередей parallel_queue_0..N для запуска модулей с учётом зависимостей;
• очереди хуков, имена которых заданы в конфигурации хука.

Задача, завершившаяся ошибкой без allowFailure, блокирует свою очередь, повтор идёт с экспоненциальной задержкой начиная с 5 секунд. Очереди не блокируют друг друга. Посмотреть очереди можно командой d8 system queue list.

Подробнее в разделе «Механизм очередей».

Пакет Marketplace

Абстрактная единица Marketplace: приложение, то есть пользовательская нагрузка в неймспейсе, или модуль, расширяющий возможности кластера.

Пакеты публикуются в хранилищах образов, подключённых к Marketplace как репозитории пакетов. Для каждой обнаруженной версии пакета Deckhouse Platform хранит её метаданные: описание, стадию жизненного цикла, требования, подтверждение удаления, changelog и схемы OpenAPI настроек и values.

Подробнее в разделе «Концепции».

Патч-версия

Релиз Deckhouse Platform с исправлениями. Патч-версии выпускаются по мере необходимости.

Патч-версия — один из двух видов релиза Deckhouse Platform, второй вид — минорная версия. В режиме обновления AutoPatch автоматически устанавливаются только патч-версии. Начиная с Deckhouse Platform 1.70 они применяются с учётом окон обновлений.

Подробнее в разделе «Обновление».

Перебалансировка ВМ

Восстановление равномерного распределения виртуальных машин по узлам переносом их живой миграцией. Выполняется модулем descheduler.

Механизм перебалансировки выравнивает нагрузку: когда узел резервирует больше 80% процессорных ресурсов, часть машин переносится на узлы, где зарезервировано меньше 50%. Она также восстанавливает корректное размещение, когда текущий узел перестаёт отвечать требованиям машины или правилам взаимного расположения. При включённом модуле descheduler Deckhouse Platform создаёт Descheduler с именем virtualization и выбирает в нём только машины, которые можно перенести живой миграцией.

Подробнее в разделе «Отказоустойчивость и балансировка виртуальных машин».

Переподписка CPU

Выдача виртуальным машинам узла большего числа виртуальных ядер, чем на нём есть физических. Степень переподписки определяется долей ядра, гарантированной виртуальной машине.

Параметр coreFraction виртуальной машины определяет долю мощности ядра, которая ей гарантирована. Допустимые значения задаются в политике сайзинга класса. При coreFraction: 20% машина всегда получает пятую часть ядра, а при наличии свободных ресурсов на узле может занять ядро целиком. При размещении машины Deckhouse Platform суммирует гарантированные доли всех машин узла, и если сумма превышает число физических ядер, машина на этом узле не запускается.

Подробнее в разделе «Переподписка на CPU для виртуальных машин».

Перераспределение подов

Периодическое вытеснение подов, которые соответствуют активным стратегиям планирования, чтобы они были запланированы заново с учётом текущего состояния кластера. Управляется модулем descheduler.

Deckhouse Platform каждые 15 минут анализирует состояние кластера и вытесняет подходящие поды. Вытесненные поды вновь проходят стандартный процесс планирования. Класс приоритета пода задаёт порядок вытеснения, а параметр priorityClassThreshold в Descheduler ограничивает вытеснение подами с приоритетом ниже порога. На этом же механизме построена перебалансировка ВМ.

Подробнее в разделе «Планировщик».

Подсистема

Логическая часть системы, которая объединяет взаимосвязанные модули и их системные компоненты.

Подсистемы группируют компоненты системы и разграничивают доступ к ним. Подсистема состоит из модулей и их системных компонентов.

Подтверждение удаления

Подтверждение, которое пользователь должен дать в веб-интерфейсе перед удалением приложения или отключением модуля. Объявляется в секции disable файла package.yaml или module.yaml вместе с сообщением для пользователя.

Для пакета Marketplace секция disable задаёт confirmation: true и локализованные сообщения, например предупреждение, что удаление приложения удаляет данные в его томах. Deckhouse Platform публикует секцию в поле status.packageMetadata.disableOptions версии пакета, а веб-интерфейс Deckhouse показывает сообщение на языке пользователя. При удалении Application через API Kubernetes подтверждение не проверяется.

Для модуля так же работают параметры disable.confirmation и disable.message файла module.yaml при отключении модуля.

Подробнее в разделе «Разработка приложений».

Полезная нагрузка

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

Полезная нагрузка запускается в пользовательских неймспейсах. Запуск полезной нагрузки в системных неймспейсах запрещён.

Политика reclaim диска пула ВМ

Политика reclaim шаблона диска пула виртуальных машин. Задаёт, что происходит с диском реплики, когда реплику удаляют из пула.

Политика задаётся в блоке virtualDiskTemplates пула виртуальных машин вместе с размером и источником данных диска реплики. При значении Delete, оно действует по умолчанию, диск удаляется вместе с репликой. При значении Retain диск сохраняется и переиспользуется следующей репликой.

Подробнее в разделе «Пулы виртуальных машин».

Политика запуска ВМ

Политика, которая определяет, как Deckhouse Platform поддерживает состояние виртуальной машины. Задаётся параметром runPolicy машины.

Допустимые значения: AlwaysOnUnlessStoppedManually (по умолчанию, машина всегда работает, остановить её можно только вручную), AlwaysOn (машина запускается снова даже после выключения из гостевой ОС), Manual (состоянием управляет пользователь) и AlwaysOff (машина всегда выключена, запустить её нельзя).

Состоянием виртуальной машины управляют через VirtualMachineOperation или командами d8 v start, d8 v stop, d8 v restart и d8 v evict, которые создают такую же операцию.

Подробнее в разделе «Подключение к виртуальной машине».

Политика миграции ВМ

Политика, которая определяет, когда живая миграция виртуальной машины использует механизм AutoConverge, то есть замедление процессора для гарантированного завершения миграции. Задаётся параметром liveMigrationPolicy машины.

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

Допустимые значения: AlwaysSafe (никогда не замедлять), PreferSafe (по умолчанию, без замедления, но миграция с force=true может замедлять), AlwaysForced (всегда использовать AutoConverge) и PreferForced (использовать AutoConverge, но миграция с force=false выполняется без него).

Подробнее в разделе «Живая миграция виртуальных машин».

Политика обновления модуля

Правила, по которым Deckhouse Platform обновляет модуль из источника в кластере. Задаётся с помощью объекта ModuleUpdatePolicy и определяет режим обновления, канал обновлений и окна обновлений модуля.

Политика задаёт режим обновления (автоматический, ручной или обновления отключены), канал обновлений, используемый при обновлении, и окна обновлений, в пределах которых разрешено автоматическое обновление. Если политика для модуля не определена, модуль обновляется по настройкам платформы из параметра update модуля deckhouse. Релиз модуля в статусе Pending ждёт ручного подтверждения.

Подробнее в разделе «Как запустить и проверить модуль в кластере DP».

Политика сайзинга

Блок класса виртуальных машин, который задаёт, какие сочетания ядер, доли ядра и памяти разрешены виртуальным машинам этого класса.

Политика состоит из списка правил, каждое из которых относится к своему диапазону ядер. Диапазоны не должны пересекаться. Изменения политики затрагивают уже существующие виртуальные машины: у машины, которая перестала соответствовать требованиям, условие SizingPolicyMatched принимает статус False. Допустимые значения доли ядра, заданные в политике, определяют степень переподписки CPU.

Подробнее в разделе «Политика сайзинга виртуальных машин».

Пользовательский неймспейс

Неймспейс, в котором запускается полезная нагрузка. Всегда относится к одному проекту.

Пользовательский неймспейс всегда относится к одному проекту и не может иметь префикс системного неймспейса.

Неймспейсы проекта делятся на основной неймспейс проекта и дополнительные неймспейсы проекта.

Правила размещения ВМ

Правила, которые определяют, на каком узле запускается виртуальная машина, от nodeSelector и node affinity до affinity и anti-affinity к другим машинам и подам. Условия бывают жёсткими и мягкими.

Жёсткое условие обязательно: если подходящего узла нет, машина остаётся в фазе Pending. Мягкое условие планировщик учитывает по возможности. Все правила, включая nodeSelector из класса ВМ, применяются вместе. Для узлов с taints машине нужны соответствующие tolerations.

Когда правила работающей машины меняются и её текущий узел им больше не отвечает, коммерческие редакции переносят машину живой миграцией, а в Deckhouse Platform Open изменение применяется после перезагрузки. Правила размещения машины, её дисков и класса проверяются и при подключении блочного устройства. Перебалансировка ВМ восстанавливает корректное размещение, когда узел перестаёт отвечать правилам.

Подробнее в разделе «Размещение виртуальных машин по узлам».

Правило рантайм-аудита

Правило рантайм-аудита, которое описывает критерий подозрительного поведения в виде условия в синтаксисе Falco. Deckhouse Platform поставляет встроенные правила и принимает пользовательские.

К встроенным относятся правила для аудита Kubernetes, которые выявляют проблемы с безопасностью Deckhouse Platform и самого механизма аудита, и нормативные правила fstec, удовлетворяющие требованиям приказа ФСТЭК России № 118 к средствам контейнеризации. Пользовательские правила задают с помощью объекта FalcoAuditRules модуля runtime-audit-engine. Рантайм-аудит сверяет события со всеми правилами и формирует события безопасности.

Подробнее в разделе «Архитектура рантайм-аудита».

Приостановка приложения

Состояние установленного приложения, требования пакета которого перестали выполняться, например отключён обязательный модуль. Deckhouse Platform удаляет Helm-релиз, но сохраняет Application в состоянии Suspended.

Deckhouse Platform проверяет требования пакета постоянно, а не только при создании. Когда они перестают выполняться, выполняются хуки beforeDeleteHelm, удаляется Helm-релиз, а с ним ресурсы экземпляра приложения, затем выполняются хуки afterDeleteHelm. Orphan-ресурсы не удаляются. Когда требования снова выполняются, приложение устанавливается заново с теми же настройками.

Ресурсы удаляются вместе с Helm-релизом, включая PersistentVolumeClaim. Чтобы сохранить данные, добавьте им аннотацию helm.sh/resource-policy: keep.

Подробнее в разделе «Жизненный цикл и отладка».

Приостановленный релиз

Релиз Deckhouse Platform, развёртывание которого на канале обновлений остановлено после публикации. В образ канала обновлений добавляется флаг suspend.

Пока релиз приостановлен, d8 mirror pull отказывается копировать канал обновлений и сообщает, что в исходном хранилище канал приостановлен. Образы платформы по-прежнему можно скачать, указав версию явно флагом --deckhouse-tag.

Подробнее в разделе «Обновление DP в закрытом окружении».

Проба доступности

Проверка, которую модуль upmeter регулярно выполняет для расчёта доступности компонентов Deckhouse Platform. Пробы объединены в группы, группы и отдельные пробы можно отключать.

Компонент upmeter-agent работает на master-узлах и выполняет группы проверок: control-plane (доступность API-сервера и работа контроллеров), deckhouse (состояние кластера и deckhouse-контроллер), extensions, load-balancing, monitoring-and-autoscaling, nginx (у каждого Ingress-контроллера есть под в состоянии Ready), nodegroups и synthetic (сетевое взаимодействие между узлами). Например, группа control-plane создаёт неймспейс, под и StatefulSet и проверяет, что Kubernetes их обрабатывает.

Результаты проб контроллер upmeter хранит без учёта интервалов простоя из объекта Downtime, показывает на странице статуса и дашборде доступности и использует для мониторинга SLA. Пробы и группы проб отключаются параметром модуля disabledProbes.

Подробнее в разделе «Модуль upmeter».

Проброс устройств

Передача виртуальной машине устройства узла, на котором она работает, например USB-устройства, GPU или PCI-устройства.

У каждого типа устройств свои требования к узлу и свой порядок подготовки.

Подробнее в разделе «Виртуализация».

Проверка подписи образов

Проверка целостности и подлинности образов пользовательских приложений на этапе валидации запросов к API Kubernetes, до создания пода, по подписям Cosign и открытым ключам, перечисленным в SecurityPolicy.

На этапе сборки образ подписывается закрытым ключом с помощью Cosign. Подпись публикуется в хранилище образов отдельным тегом и не меняет сам образ. В кластере SecurityPolicy с параметром verifyImageSignatures перечисляет открытые ключи, а модуль admission-policy-engine с Ratify проверяет подпись каждого образа при создании пода. Это часть контроля целостности, доступная во всех редакциях. Проверка на уровне контейнерного рантайма есть только в Certified Core и Certified Pro.

Подробнее в разделе «Контроль целостности».

Проверка соответствия CIS Kubernetes Benchmark

Проверка, которую Deckhouse Platform автоматически выполняет в каждом кластере по рекомендациям CIS Kubernetes Benchmark. Результаты доступны в виде отчётов и на дашборде Security / CIS Kubernetes Benchmark.

Deckhouse Platform соответствует рекомендациям CIS Kubernetes Benchmark как на уровне отдельных компонентов, так и для платформы в целом. Доступ к отчётам, как и к результатам сканирования на уязвимости, выдаётся через ролевую модель модуля operator-trivy.

Подробнее в разделе «Настройка сканирования контейнерных образов на уязвимости».

Программно-определяемая сеть (SDN)

Дополнительный сетевой сегмент для подов и виртуальных машин, который администратор описывает декларативно в кастомных ресурсах, а модуль sdn настраивает на узлах.

Программно-определяемые сети в Deckhouse Platform охватывают настройку сетевых интерфейсов на узлах (агрегацию портов, мосты, VLAN-интерфейсы), дополнительные сети для нагрузки, доступные во всём кластере или в пределах одного неймспейса (сети проекта), управление IP-адресами этих сетей, underlay-сети для проброса физических интерфейсов приложениям и системные сети для служебного трафика на уровне узла.

Подробнее в разделе «Программно-определяемые сети».

Программно-определяемое хранилище

Группа типов хранилищ Deckhouse Platform, которые работают на дисках узлов кластера и управляются модулями sds-*, в отличие от внешних систем хранения.

К программно-определяемым хранилищам (SDS) относятся управление логическими томами на узлах кластера, локальное хранилище на основе Local Path Provisioner или LVM и реплицируемое хранилище на основе DRBD. Вторая группа — внешние хранилища: Ceph, NFS, S3 и системы хранения производителей оборудования.

Подробнее в разделе «Хранилища».

Проект

Механизм изоляции и управления полезной нагрузкой в Deckhouse Platform. Проект логически делит кластер и даёт команде собственную область, в которой она развёртывает приложения, настраивает ресурсы и управляет доступом в рамках назначенных прав.

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

Подробнее в разделе «Мультитенантность».

Пропуск промежуточных релизов модуля

Механизм from-to, который позволяет Deckhouse Platform пропускать пошаговые обновления модуля. Если установленная версия модуля попадает в диапазон from-to из module.yaml, Deckhouse Platform устанавливает последнюю версию в пределах to.

Правила перехода перечисляются в секции update.versions файла module.yaml. Релиз, который их содержит, называется релизом с ограничениями. Правило читается из релиза, на который выполняется переход, и его to должно совпадать с версией этого релиза. Если установленная версия ниже from, обновление идёт последовательно. Если подходят несколько правил, выбирается правило с наибольшим to.

Подробнее в разделе «Разработка и отладка модуля».

Пул виртуальных машин

Набор одинаковых виртуальных машин, реплик из одного шаблона, число которых поддерживает Deckhouse Platform. Пул масштабируется через субресурс scale, HPA или KEDA. Доступен в коммерческих редакциях.

Пул описывает VirtualMachinePool. Его шаблон совпадает с обычной спецификацией виртуальной машины, поэтому реплика ничем не отличается от вручную созданной виртуальной машины. Диски реплик описываются один раз в шаблонах дисков с политикой reclaim, размером и источником данных, а шаблон ссылается на них в порядке загрузки. Общие образы, например единый ISO для всех реплик, подключаются только для чтения.

Реплики различаются начальной инициализацией, поэтому тип ОС Legacy в пуле не поддерживается.

Подробнее в разделе «Пулы виртуальных машин».

Рантайм-аудит

Поиск угроз безопасности в работающем кластере за счёт анализа событий ядра Linux и событий аудита API Kubernetes.

Рантайм-аудит в Deckhouse Platform использует два источника событий: события ядра Linux, получаемые через eBPF-драйвер системы обнаружения угроз Falco, и события аудита API Kubernetes, получаемые через вебхук. Он выявляет попытки применения известных уязвимостей, признаки криптовалютных майнеров и угрозы Kubernetes: оболочки командной строки в контейнерах, привилегированные контейнеры, монтирование небезопасных путей и чтение секретных файлов.

Для перехвата событий ядра требуется ядро Linux версии 5.8 или новее с поддержкой eBPF.

Подробнее в разделе «Рантайм-аудит».

Рантайм-профиль

Модель поведения приложения или контейнера во время работы, включая системные вызовы, запускаемые процессы, доступ к файлам и сетевые взаимодействия, которую строит node-agent модуля operator-trivy с помощью eBPF-программ.

Node-agent — опциональный компонент, который работает на всех узлах кластера в привилегированном режиме, наблюдает за поведением контейнеров с помощью eBPF-программ и сохраняет профили в объектах ApplicationProfile и NetworkNeighborhood. Он работает в режиме профилирования и не выявляет атаки по правилам. Это задача рантайм-аудита. На основе профилей можно генерировать сетевые политики по наблюдаемому трафику.

Подробнее в разделе «Модуль operator-trivy».

Распространение секретов

Автоматическое копирование секретов из неймспейса default с лейблом secret-copier.deckhouse.io/enabled во все неймспейсы кластера.

Deckhouse Platform копирует секреты с этим лейблом в каждый существующий и каждый новый неймспейс, распространяет изменения оригинала, перезаписывает ручные правки копий и удаляет копии при удалении оригинала. Ночная синхронизация поддерживает копии в актуальном состоянии. Это избавляет от ручного копирования секретов в CI/CD-процессах, например учётных данных registry.

Механизм несовместим с режимом мультитенантности: секрет, распространённый во все неймспейсы, может попасть в изолированное окружение проекта. Общие секреты для проектов задаются в шаблоне проекта.

Подробнее в разделе «Автоматическое распространение секретов по неймспейсам».

Расширение планировщика

Расширение (extender) kube-scheduler, которое предоставляет модуль Deckhouse Platform, чтобы размещать поды по собственной логике вместо стандартного планировщика, например по локальным томам, селекторам узлов класса хранения или сетевым интерфейсам.

Модуль sds-local-volume размещает поды с локальными томами с учётом свободного места на узлах и места, которое нужно зарезервировать под тома. Его вебхук задаёт таким подам spec.schedulerName со значением sds-local-volume. Модуль csi-nfs размещает поды по селекторам узлов из NFSStorageClass, а модуль sdn предлагает узлы в соответствии с настройками сетевых интерфейсов подов, использующих программно-определяемые сети. kube-scheduler отправляет запросы на планирование таких подов на вебхук расширения.

Подробнее в разделе «Архитектура хранилищ».

Расширенный балансировщик

Балансировщик модуля service-with-healthchecks, который выполняет активные пробы отдельных TCP-портов вместо readiness-проб контейнеров, поэтому каждый балансировщик, обслуживающий один и тот же под, работает независимо от других.

Расширенный балансировщик реализован на объектах ServiceWithHealthchecks. Он состоит из контроллера, который работает на master-узлах и управляет этими объектами, и агентов на каждом узле, которые выполняют пробы и публикуют только проверенные адреса. Стандартный балансировщик, сервис Kubernetes, остаётся доступен для нагрузок, которым отдельные пробы не нужны.

Подробнее в разделе «Внутрикластерное взаимодействие».

Расширенный мониторинг

Режим мониторинга модуля extended-monitoring, который добавляет мониторинг секретов и срока действия TLS-сертификатов, сбор событий кластера в виде метрик, проверку доступности образов в registry и мониторинг объектов в неймспейсах с лейблом.

Объекты отслеживаются в неймспейсах с лейблом extended-monitoring.deckhouse.io/enabled="". Доступность образов проверяется для образов, которые используют Deployment, StatefulSet, DaemonSet и CronJob.

Подробнее в разделе «Мониторинг в Deckhouse Platform».

Регион

Независимая географическая область, включающая несколько, обычно не менее трёх, изолированных зон доступности, которые объединены в единую логическую инфраструктурную единицу с общими сервисами управления.

Регион (Region) — ключевой элемент глобальной распределённой архитектуры облачных провайдеров. Регионы существенно удалены друг от друга географически, размещаются вне зон сейсмической или политической нестабильности и подключаются к нескольким энергосетям. Задержка между зонами доступности одного региона составляет около 5 мс, между регионами — от 50 до 200 мс.

Deckhouse Platform поддерживает распределение узлов кластера по регионам (Multi-Region), чтобы приложения продолжали работать даже при выходе из строя целого ЦОДа или облачного провайдера. Из-за задержки между регионами такой вариант подходит только приложениям, которые работают в каждом регионе автономно, например кеширующим серверам CDN или распределённым узлам мониторинга. Администратор маркирует каждый узел лейблом региона и обеспечивает стабильные каналы связи между регионами.

Подробнее в разделе «Геораспределённость».

Редакция

Вариант поставки Deckhouse Platform, например Open, Core, Ultimate, или CSE Pro, который определяет набор доступных модулей и функций.

Редакция выбирается при установке кластера. Работающий кластер можно переключить на другую редакцию.

Подробнее в разделе «Переключение между редакциями DP».

Режим HA

Режим, в котором критически важные компоненты Deckhouse Platform запускаются с избыточностью, чтобы отказ отдельного экземпляра не останавливал сервис.

Режим HA включается автоматически, если в кластере больше одного master-узла, как при первичном развёртывании, так и при последующем добавлении узлов. Им также можно управлять вручную.

Подробнее в разделе «Высокая надёжность и доступность».

Режим обновления

Настройка, которая определяет, как Deckhouse Platform применяет новые версии.

В режиме Auto автоматически применяются и патч-версии, и минорные версии, в режиме AutoPatch — только патч-версии в рамках текущей минорной версии. В режиме Manual версия применяется только после того, как администратор подтвердит соответствующий DeckhouseRelease.

Режим задаётся в параметре settings.update.mode модуля deckhouse. В автоматических режимах обновления применяются с учётом окон обновлений.

Подробнее в разделе «Настройка обновлений».

Режим обслуживания модуля или приложения

Режим, в котором Deckhouse Platform перестаёт применять шаблоны и восстанавливать ресурсы модуля или приложения, чтобы их можно было менять вручную. Включается полем spec.maintenance: NoResourceReconciliation и не связан с режимом обслуживания узла.

В этом режиме изменения настроек и values не отражаются в ресурсах, удалённые ресурсы не восстанавливаются, хуки продолжают работать. Ресурсы, отрендеренные из шаблонов, получают лейбл maintenance.deckhouse.io/no-resource-reconciliation, и admission-политики перестают их защищать. У экземпляра приложения условие Managed становится False, срабатывает алерт ApplicationIsInMaintenanceMode. Чтобы вернуть обычный режим, удалите поле spec.maintenance.

Поле задаётся в ModuleConfig для модуля и в Application для приложения. Режим предназначен для отладки и разработки, а не для production-кластеров. Режим обслуживания узла — другой механизм.

Подробнее в разделе «Жизненный цикл и отладка».

Режим обслуживания узла

Состояние узла, в котором Deckhouse Platform переносит виртуальные машины на другие узлы и не запускает на нём новые, чтобы работы на узле не нарушали их работу.

Узел переводится в режим обслуживания командой d8 k drain или действием Cordon + Drain в веб-интерфейсе, а возвращается в работу командой d8 k uncordon. Виртуальные машины, которые можно перенести, переносятся живой миграцией. Машина, которую перенести нельзя, например привязанная к узлу или использующая проброшенное устройство, удерживает узел до перезапуска. Перезапуск разрешается аннотацией virtualization.deckhouse.io/virtualmachines-restart-approved на узле.

Подробнее в разделе «Обслуживание узлов с виртуальными машинами».

Режим управления registry

Режим, в котором модуль registry управляет путями загрузки образов компонентов Deckhouse Platform, Unmanaged или Managed.

Режим задаётся параметром mode в ModuleConfig registry:

• Unmanaged (по умолчанию). Модуль registry не управляет путями загрузки: кластер загружает образы из того хранилища, с которым был установлен.
• Managed. Модуль registry управляет путями загрузки. Параметр primary.upstream задаёт upstream-хранилище, а storage.cache включает внутрикластерный кеш образов на master-узлах. Без primary.upstream кластер считается изолированным.

Подробнее в разделе «Управление хранилищем образов в кластерах, полностью управляемых DP».

Резервный узел

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

Резервные узлы доступны для узлов CloudEphemeral. Количество задаётся абсолютным значением или процентом от максимального количества узлов в группе узлов. В группе уже должен работать хотя бы один узел. Долю ресурсов узла, занятую служебными компонентами вне Deckhouse Platform, задаёт параметр standbyHolder.overprovisioningRate. Резервные узлы увеличивают затраты на инфраструктуру.

Подробнее в разделе «Добавление и управление облачными узлами».

Релиз Deckhouse Platform

Любая опубликованная версия Deckhouse Platform. Релизы распространяются по каналам обновлений с заданными задержками и бывают двух видов — патч-версия и минорная версия.

Патч-версия содержит исправления ошибок, минорная версия — новые функции. Каждый новый релиз сначала появляется на канале обновлений Alpha и затем переходит на более стабильные каналы. В кластере релиз представлен объектом DeckhouseRelease, который применяется согласно режиму обновления и окнам обновлений. Минорные релизы нельзя пропускать, потому что они содержат миграции, которые должны применяться по порядку.

Подробнее в разделе «Обновление».

Реплицируемое хранилище

Хранилище, в котором данные реплицируются между несколькими узлами и остаются доступными при отказе одного из них.

Реплицируемые блочные StorageClass создаются модулем sds-replicated-volume, который основан на Distributed Replicated Block Device (DRBD). Реплицируемое хранилище относится к программно-определяемым хранилищам. Его пулы создаются на группах томов LVM как thick или thin pool.

Подробнее в разделе «Настройка реплицируемого хранилища на основе DRBD».

Ресурс кластера, доступный проекту

Cluster-wide-ресурс, например StorageClass, который модуль multitenancy-manager делает доступным проекту по гранту. Настройки приложения, связанные с таким ресурсом, получают значение по умолчанию проекта и проверяются по списку доступных проекту ресурсов.

Поле settings типа string связывается с доступным по гранту ресурсом расширением x-deckhouse-grantable-resource, в котором указано имя ресурса, доступного проекту, например storageclasses. Если пользователь оставил поле пустым, в values подставляется имя ресурса, заданное как значение по умолчанию проекта. Значение, которого нет в списке доступных проекту ресурсов, отклоняется. Группа, версия и вид ресурса определяются грантом.

Подробнее в разделе «Настройки приложения».

Ролевая модель

Механизм управления доступом на основе ролей (RBAC, Role-Based Access Control), который определяет, какие пользователи или сервисы могут выполнять конкретные действия в рамках проектов или системы.

Deckhouse Platform поддерживает две ролевые модели: гранулярную, которая рекомендуется к использованию и строится на use-ролях и manage-ролях, и упрощённую с высокоуровневыми ролями. Обе модели поддерживаются модулем user-authz и могут использоваться одновременно: права, которые они предоставляют, суммируются.

Подробнее в разделе «Авторизация».

Сервис-меш

Инфраструктурный слой, который управляет сетевым взаимодействием между сервисами приложения. Шифрование, контроль доступа, маршрутизация, повторы запросов и сбор метрик настраиваются централизованно, без изменения кода сервисов.

Сервисы приложения обмениваются запросами по сети, и без сервис-меша каждый из них должен сам реализовывать шифрование, проверку прав, повторы и тайм-ауты. Сервис-меш берёт эти задачи на себя: трафик между сервисами проходит через прокси, которые настраиваются из одной точки. Обычно прокси добавляется в под приложения как сайдкар-контейнер. В экспериментальном режиме ambient прокси работает на уровне узла, и сайдкары в подах не нужны.

В Deckhouse Platform сервис-меш предоставляет модуль istio. Внутри одного кластера он используется, например, для Canary-развёртывания и автоматического отключения сбойного сервиса (Circuit Breaker). На его основе строятся федерация и мультикластер.

Подробнее в разделе «Межкластерное взаимодействие».

Сетевая политика

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

Реализация сетевых политик в Deckhouse Platform зависит от включённого CNI-модуля. С cni-cilium политики применяет Cilium в трёх форматах: стандартный NetworkPolicy на уровнях L3 и L4, сетевые политики Cilium с правилами L3–L7 в пределах неймспейса и CiliumClusterwideNetworkPolicy для всего кластера, который также защищает узлы как host firewall. С cni-flannel или другим CNI без поддержки политик стандартный NetworkPolicy на уровнях L3 и L4 применяет модуль network-policy-engine через правила iptables и ipset на каждом узле.

Подробнее в разделе «Сетевые политики».

Сеть проекта

Дополнительная программно-определяемая сеть, доступная в пределах одного неймспейса. Пользователь создаёт её и управляет ею на основе NetworkClass, предоставленного администратором. Другое название — пользовательская сеть.

Администратор задаёт в NetworkClass диапазон VLAN-тегов и сетевые интерфейсы узлов, на основе которых пользователи могут создавать собственные сети. Пользователь создаёт сеть с помощью объекта Network в неймспейсе проекта. Пользователи могут выделить для сети проекта пул адресов и назначать адреса интерфейсам подов через IPAM. Второй вид дополнительной сети — кластерная сеть.

Подробнее в разделе «Дополнительные сети для использования в прикладных подах».

Система

Часть кластера, которая обеспечивает его работоспособность, управляет ресурсами и автоматизирует процессы.

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

Система работает преимущественно в системных неймспейсах. Части системы, которые обслуживают нагрузку конкретного проекта, могут работать в пользовательских неймспейсах.

Системная сеть

Дополнительная сервисная сеть на узлах кластера, которую модуль sdn создаёт поверх существующей underlay-сети для служебного трафика на уровне узла.

Системную сеть создают с помощью объекта SystemNetwork. Интерфейсы, подключённые к системной сети, получают адреса в масштабе кластера через ClusterIPAddress, как и интерфейсы кластерных сетей. Она относится к функциям программно-определяемых сетей уровня узла, вместе с настройкой интерфейсов узлов и underlay-сетями.

Подробнее в разделе «Программно-определяемые сети (SDN)».

Системный компонент

Процесс или группа процессов, которые запущены в контейнере или как служба systemd на узле и обеспечивают работу платформы и её модулей.

Примеры системных компонентов: kubelet, containerd.

Некоторые системные компоненты запускаются в пользовательских неймспейсах. Например, когда пользователь создаёт виртуальную машину или managed-сервис, в пользовательском неймспейсе запускаются поды, которые поддерживают работу этого объекта.

Системный неймспейс

Неймспейс, в котором работает система, то есть модули и системные компоненты. Запуск полезной нагрузки в системных неймспейсах запрещён.

Системные неймспейсы Deckhouse Platform имеют префиксы d8- и kube-. В них работает система, её модули и системные компоненты.

Системный пользователь deckhouse

Локальный пользователь и группа с UID и GID 64535, под которыми компоненты Deckhouse Platform запускают непривилегированные процессы на узлах. Имя и идентификаторы зарезервированы и не настраиваются.

Если учётной записи нет, bashible создаёт её без пароля, прав sudo и командной оболочки. Учётная запись не должна предоставляться через AD или LDAP. Процессы пользователя deckhouse в выводе ps или top принадлежат компонентам Deckhouse Platform. Preflight-проверка допускает отсутствие пользователя и группы либо существующую пару с зарезервированными идентификаторами и без прав sudo. Установка завершается ошибкой, если имя занято с другими идентификаторами или идентификаторы принадлежат другой учётной записи.

Подробнее в разделе «Установка платформы».

Системный узел

Узел, выделенный для запуска модулей Deckhouse Platform, чтобы они не пересекались с пользовательскими приложениями.

Системные узлы изолируются лейблами и taints, чтобы на них не планировались пользовательские поды. Рекомендуется выделить два системных узла. Системные узлы могут быть статическими или облачными и обычно образуют группу узлов system. Если в кластере нет выделенных узлов мониторинга, компоненты мониторинга тоже работают на системных узлах.

Подробнее в разделе «Рекомендации по настройке узлов кластера».

Сканирование на уязвимости

Автоматический поиск известных уязвимостей (CVE) и проверка на соответствие CIS для контейнерных образов, используемых подами кластера, на основе Trivy.

Deckhouse Platform сканирует контейнерные образы всех ресурсов в неймспейсах с лейблом security-scanning.deckhouse.io/enabled="". Без таких лейблов сканируется только неймспейс default. Сканирование запускается каждые 24 часа и при развёртывании компонентов с новыми образами. Результат сканирования каждого образа сохраняется в неймспейсе проверенного ресурса.

Подробнее в разделе «Сканирование контейнерных образов на уязвимости».

Сквозная аутентификация

Аутентификация, реализованная в Deckhouse Platform так, что пользователь проверяется при доступе к любому интерфейсу платформы и к ресурсам кластера. Пользователи могут включить её и для собственных приложений.

В зависимости от настройки аутентификация использует внутреннюю базу пользователей (статических пользователей) или внешних провайдеров аутентификации, например LDAP, GitLab или GitHub. Внешний провайдер позволяет использовать существующие учётные данные и применять их сразу в нескольких кластерах Deckhouse Platform. Для пользователя кластера и разработчика приложения интерфейс и методы аутентификации приложений не зависят от того, как администратор настроил аутентификацию.

Подробнее в разделе «Настройка аутентификации для приложений».

Снимок виртуальной машины

Зафиксированное состояние диска или виртуальной машины целиком на определённый момент, которое хранится для восстановления или клонирования. Снимок диска сохраняет только данные выбранного диска, снимок ВМ включает параметры ВМ и состояние всех её дисков.

Снимок диска описывает VirtualDiskSnapshot, он служит источником для новых дисков и образов. Снимок виртуальной машины описывает VirtualMachineSnapshot, это сохранённое состояние машины в определённый момент. Подключённые образы вместе с ним не сохраняются, поэтому при восстановлении они должны быть в кластере.

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

Подробнее в разделе «Снимки дисков и виртуальных машин».

Событие безопасности

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

Deckhouse Platform собирает события безопасности из контейнерных источников, то есть логов приложений в подах, и из кластерных источников, например журнала аудита API Kubernetes и логов аутентификации на узлах. Модуль log-shipper выполняет предварительный отбор записей, а модуль security-events-manager разбирает их, приводит к единому формату с обязательным набором атрибутов, обогащает контекстом и доставляет в системы хранения и аналитики, например Loki, Elasticsearch, Kafka или Splunk.

Подробнее в разделе «События безопасности».

Стадия жизненного цикла модуля

Стадия зрелости модуля или пакета Marketplace — Experimental, Preview, General Availability или Deprecated. Объявляется в module.yaml или package.yaml и вместе с каналом обновлений определяет стабильность версии.

• Experimental — функциональность может сильно измениться, совместимость с будущими версиями не гарантируется. Такие модули нельзя включить, пока параметр allowExperimentalModules модуля deckhouse не установлен в true.
• Preview — предварительная версия. Основные возможности сохранятся, совместимость обеспечивается, но может потребоваться миграция.
• General Availability — модуль готов к использованию в production-средах.
• Deprecated — разработка и поддержка прекращены.

Стадия пакета Marketplace публикуется в метаданных пакета при сканировании репозитория Deckhouse Platform.

Подробнее в разделе «Версионирование модулей».

Статический кластер

Кластер с типом clusterType: Static. Его узлы — физические серверы или виртуальные машины, которые Deckhouse Platform не создаёт и не управляет ими через API облака.

Администратор готовит серверы, а установщик настраивает их, развёртывает Kubernetes и устанавливает Deckhouse Platform. Узлы такого кластера — статические узлы. Статический кластер можно расширить узлами облачного провайдера до гибридного кластера.

Подробнее в разделе «Установка платформы».

Статический под

Под, который kubelet запускает напрямую из манифеста в директории /etc/kubernetes/manifests узла, без участия API Kubernetes. Так в Deckhouse Platform работают компоненты control plane и kubernetes-api-proxy.

В Deckhouse Platform kubelet обрабатывает в этой директории только файлы с расширением .yaml или .yml. Резервные копии, swap-файлы редакторов и другие временные файлы игнорируются. Статическими подами являются компоненты control plane kube-apiserver, etcd, kube-controller-manager и kube-scheduler, а также kubernetes-api-proxy.

Подробнее в разделе «Kubelet».

Статический пользователь

Пользователь, созданный в кластере как объект User локальной аутентификации, с email и хешем пароля, без внешнего провайдера аутентификации.

Статические пользователи и группы лежат в основе локальной аутентификации в Deckhouse Platform. Объект User хранит данные пользователя и хеш пароля, сам пароль в открытом виде не хранится. Объект Group задаёт список пользователей. Локальная аутентификация поддерживает парольные политики и временных пользователей с TTL. Доступна также двухфакторная аутентификация.

Рекомендуемый способ создать статического пользователя — команда d8 iam user create.

Подробнее в разделе «Локальная аутентификация».

Статический узел

Узел на bare-metal-сервере или виртуальной машине, который создан вне автоматизации Deckhouse Platform и подключён к кластеру вручную или через CAPS. Описывается в NodeGroup с типом узлов Static.

Статические узлы не поддерживают автоматическое масштабирование и обновление: обновление kubelet, перезагрузки и замены выполняются вручную или внешними инструментами. Узел подключается либо запуском bootstrap-скрипта на сервере, либо автоматически через CAPS. В облачной среде cloud-controller-manager не управляет статическим узлом, даже если включён модуль облачного провайдера.

Группа узлов может объединять статические узлы с узлами CloudStatic, на этом основан гибридный кластер.

Подробнее в разделе «Добавление и управление bare-metal-узлами».

Схема размещения

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

Схема размещения задаётся в параметре layout ModuleConfig модуля облачного провайдера. Доступные схемы зависят от провайдера, например Standard, WithoutNAT и WithNATInstance в Yandex Cloud.

В некоторых схемах узлы не имеют публичных IP-адресов, и доступ к master-узлу выполняется через bastion-хост.

Подробнее в разделе «Интеграция с облачными провайдерами».

Топология CPU виртуальной машины

Распределение ядер процессора виртуальной машины по сокетам. Пользователь задаёт только общее число ядер, а число сокетов рассчитывает Deckhouse Platform.

Чем больше ядер, тем на большее число сокетов они делятся и тем крупнее шаг, с которым можно менять их количество: до 16 ядер используют один сокет, до 32 — два, до 64 — четыре, до 248 — восемь. Общее число ядер должно быть кратно числу сокетов. Топология важна для приложений, чувствительных к конфигурации процессора.

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

Подробнее в разделе «Процессор и память виртуальной машины».

Узел CloudEphemeral

Временный облачный узел, который Deckhouse Platform заказывает, создаёт и удаляет автоматически через API облачного провайдера. Описывается в NodeGroup с типом узлов CloudEphemeral.

Параметры виртуальных машин берутся из инстанс-класса, количество узлов и их зоны — из секции cloudInstances группы узлов. Узлы создаёт Machine Controller Manager или Cluster API, входящие в модуль node-manager.

Для групп CloudEphemeral доступны автомасштабирование группы узлов, резервные узлы и хаос-инжиниринг.

Подробнее в разделе «Добавление и управление облачными узлами».

Узел CloudPermanent

Постоянный облачный узел, конфигурация которого берётся из конфигурации кластера провайдера, а не из NodeGroup. Master-узлы облачного кластера являются узлами CloudPermanent.

Узлы CloudPermanent описываются в секции nodeGroups структуры <PROVIDER>ClusterConfiguration, их количество задаётся параметром replicas. Узлами управляет Terraform, встроенный в Deckhouse Platform, а изменения конфигурации применяются запуском установщика с командой dhctl converge.

Подробнее в разделе «Добавление и управление облачными узлами».

Узел CloudStatic

Узел, созданный вручную или внешними инструментами в облаке, для которого настроена интеграция с провайдером, и подключённый к кластеру bootstrap-скриптом. На нём работает CSI, а объектом Node управляет cloud-controller-manager.

Объект Node узла CloudStatic автоматически получает зону и регион из данных провайдера. Если машина удалена из облака, её объект Node удаляется из кластера. Как и статический узел, узел CloudStatic не поддерживает автоматическое масштабирование и обновление.

Подробнее в разделе «Добавление и управление облачными узлами».

Узел мониторинга

Выделенный узел для Grafana, Prometheus и других компонентов мониторинга. Без таких узлов компоненты мониторинга работают на системных узлах.

Выделенные узлы мониторинга рекомендуются в нагруженных кластерах с множеством алертов и большими объёмами метрик. Им нужны быстрые диски, не менее 400 IOPS. Узлы мониторинга обычно образуют группу узлов monitoring.

Подробнее в разделе «Рекомендации по настройке узлов кластера».

Управляемый Gateway

Объект Gateway, который модуль alb создаёт из ClusterALBInstance или ALBInstance. Через него публикуют приложения с помощью ListenerSet и маршрутов Kubernetes Gateway API.

Общекластерный шлюз создаёт администратор кластера из ClusterALBInstance, обычно в неймспейсе d8-alb. Отдельный шлюз в неймспейсе приложения создаётся из ALBInstance. Имя управляемого Gateway публикуется в поле status.gateway инстанса. Администратор неймспейса привязывает к нему ListenerSet с именами хостов, TLS и портами, разработчики — HTTPRoute и другие маршруты. Слушатели d8-http и d8-https предназначены для служебных задач, например проверки доступности, и не используются для маршрутов приложений.

Подробнее в разделе «Публикация приложений средствами Kubernetes Gateway API».

Управляемый кластер

Кластер Deckhouse Platform с установленным модулем commander-agent. Его конфигурацией и жизненным циклом управляют из управляющего кластера.

Модуль commander-agent подключает кластер к модулю commander управляющего кластера. Не путайте с Managed Kubernetes-кластером, в котором control plane предоставляет облачный провайдер: см. кластер под управлением Deckhouse Platform.

Подробнее в разделе «Управление кластерами».

Управляющий кластер

Кластер Deckhouse Platform с установленным модулем commander. Он создаёт однотипные кластеры Deckhouse Platform и управляет их конфигурацией и жизненным циклом.

Модуль commander реализует веб-приложение для управления кластерами, ему нужен экземпляр PostgreSQL, развёрнутый внутри или вне кластера. Кластеры под его управлением работают с модулем commander-agent и называются управляемыми.

Подробнее в разделе «Управление кластерами».

Условная зависимость модуля

Зависимость от другого модуля, которая действует, только если этот модуль включён. Модуль работает самостоятельно, но при наличии другого модуля его версия должна соответствовать ограничению.

Условная зависимость — вид зависимости модуля, доступна в Deckhouse Platform начиная с версии 1.73. Она может влиять на возможность включения, отключения и обновления обоих модулей: зависимого и того, от которого он зависит. Пакет Marketplace перечисляет такие модули в requirements.modules.conditional.

Подробнее в разделе «Зависимости модулей Deckhouse Platform».

Установка в существующий кластер

Режим установки, в котором Deckhouse Platform работает поверх готового кластера Kubernetes, устанавливает и обновляет платформенные модули, но не управляет операционной системой, control plane и жизненным циклом узлов.

В этом режиме существующая инфраструктура продолжает управлять ОС, kubelet, containerd, etcd, control plane и обновлением Kubernetes, существующий CNI отвечает за сеть подов, а машины создаёт и удаляет внешний провайдер или пользователь. Набор модулей Managed выбирается при установке и впоследствии не меняется. ClusterConfiguration в файле конфигурации установки не требуется.

Подробнее в разделе «Установка Deckhouse Platform в существующий кластер Talos».

Установщик

Инструмент, который развёртывает кластер Kubernetes и устанавливает в него Deckhouse Platform. Доступен как CLI-установщик dhctl в образе контейнера и как графический установщик.

CLI-установщик dhctl развёртывает кластер в поддерживаемом облаке, на bare-metal-серверах, включая гибридные кластеры, или устанавливает Deckhouse Platform в существующий кластер Kubernetes. В облачном кластере он создаёт нужную инфраструктуру: виртуальные машины, сети и другие ресурсы. В работающем кластере команда dhctl converge применяет изменения конфигурации узлов CloudPermanent и изменения защищённых параметров.

Второй вариант — графический установщик, доступный на сайте Deckhouse Platform.

Подробнее в разделе «Установка платформы».

Файл конфигурации установки

Набор YAML-документов с настройками Deckhouse Platform и манифестами объектов кластера, которые создаются после установки. Передаётся CLI-установщику параметром –config.

Файл содержит InitConfiguration (обязательно), ClusterConfiguration (обязательно, кроме установки в существующий кластер), StaticClusterConfiguration или конфигурацию кластера провайдера, а также при необходимости ModuleConfig, NodeGroup и другие объекты. CLI-установщик читает его при preflight-проверках и бутстрапе кластера.

Подробнее в разделе «Установка платформы».

Федерация

Модель межкластерного взаимодействия, которая объединяет независимые кластеры. У каждого кластера собственные неймспейсы и сервисы, а доступ между кластерами настраивается явно.

В федерации администратор указывает, какие сервисы доступны извне кластера. Модель реализуется средствами Istio через модуль istio и строится на сервис-меше. Модель для тесно связанных кластеров — мультикластер.

Подробнее в разделе «Межкластерное взаимодействие».

Хаос-инжиниринг

Управляемый или случайный вывод из строя компонентов кластера для проверки его устойчивости. В Deckhouse Platform включается для группы узлов параметром spec.chaos, только для узлов CloudEphemeral.

Параметр spec.chaos группы узлов с узлами CloudEphemeral задаёт режим и период. В режиме DrainAndDelete Chaos Monkey раз в интервал period освобождает от нагрузки и удаляет один узел группы. Режим Disabled пропускает группу. Режим также включается в веб-интерфейсе в настройках группы узлов.

Подробнее в разделе «Хаос-инжиниринг».

Хранилище образов компонентов Deckhouse Platform

Хранилище образов контейнеров, из которого кластер загружает образы компонентов Deckhouse Platform.

Хранилище указывается при развёртывании кластера в параметре deckhouse в InitConfiguration. Управление его настройками в работающем кластере зависит от способа управления кластером: в кластере под управлением Deckhouse Platform используется модуль registry, а режим управления registry задаётся в его ModuleConfig. В Managed Kubernetes-кластере используется helper change-registry.

Подробнее в разделе «Хранилище образов компонентов DP».

Хранилище секретов

Внешнее хранилище, совместимое с API HashiCorp Vault, или встроенный Deckhouse Stronghold, из которого модуль secrets-store-integration доставляет секреты приложениям, не сохраняя их в etcd.

Модуль secrets-store-integration доставляет секреты в поды в виде смонтированных файлов или переменных окружения, обновляет смонтированные секреты каждые две минуты при изменении значения в хранилище и внедряет entrypoint для приложений, которые не могут читать секреты из хранилища самостоятельно. К внутреннему экземпляру Deckhouse Stronghold модуль подключается автоматически в режиме DiscoverLocalStronghold, с любым Vault-совместимым хранилищем работает в режиме Manual.

Подробнее в разделе «Модуль secrets-store-integration».

Хук модуля

Исполняемый файл модуля или пакета Marketplace, который Deckhouse Platform запускает в ответ на событие. Хуки подготавливают values для шаблонов, создают и изменяют объекты в кластере и проверяют настройки.

Хук запускается, когда срабатывает один из его биндингов: при старте, до или после применения Helm-шаблонов, по расписанию или при изменении отслеживаемых объектов Kubernetes. Хуки модуля находятся в директории /hooks/batch. Хуки пакета Marketplace пишутся на Go с module-sdk и собираются в один бинарный файл. Существуют хуки модулей и глобальные хуки. Контроллер Deckhouse выполняет их как задачи очередей addon-operator.

Подробнее в разделе «Структура модуля».

Цикл согласования приложения

Шаги конфигурации, инициализации хуков и применения, которые Deckhouse Platform выполняет для экземпляра приложения. Новый цикл запускается при изменении настроек.

Deckhouse Platform обрабатывает каждый экземпляр приложения в отдельной очереди: скачивает bundle пакета, загружает его, ждёт выполнения требований пакета, проверяет и применяет настройки, включает привязки хуков и выполняет хуки onStartup, затем выполняет хуки beforeHelm, рендерит шаблоны и применяет их через Nelm, после чего выполняет хуки afterHelm. Последние три шага составляют цикл согласования. Helm-релиз обновляется только при необходимости: при первой установке, если отрендеренные манифесты изменились или в кластере не хватает ресурсов.

Новый цикл запускается, когда меняется spec.settings или spec.maintenance объекта Application либо когда хук schedule или хук с привязкой Kubernetes меняет values.

Подробнее в разделе «Жизненный цикл и отладка».

Шаблон DNS-имён

Шаблон DNS-имён кластера из параметра modules.publicDomainTemplate объекта ModuleConfig global. Модули Deckhouse Platform подставляют вместо %s зарезервированное имя и получают DNS-имена своих служебных веб-интерфейсов.

Если шаблон не задан, модули не создают Ingress-ресурсы. Домен в шаблоне не должен совпадать с доменом кластера из clusterDomain или быть его поддоменом. При wildcard-записи DNS одна запись покрывает все имена. При обычном шаблоне, например %s-kube.company.my, для каждого зарезервированного имени нужна A- или CNAME-запись с публичным IP-адресом Ingress-контроллера. Шаблон входит в глобальные настройки.

Подробнее в разделе «Список зарезервированных DNS-имён Deckhouse Platform».

Экземпляр приложения

Приложение, установленное из пакета Marketplace как объект Application в неймспейсе. Один пакет можно установить несколько раз с отдельными именами и настройками, а имя экземпляра входит в имена всех объектов приложения.

Каждый экземпляр полностью независим: два экземпляра Redis, для кеширования и для сессий, могут работать в одном неймспейсе. Deckhouse Platform обрабатывает каждый экземпляр в отдельной очереди. Объекты экземпляра называются d8a-<INSTANCE_NAME>-<SUFFIX>, поэтому имя экземпляра не длиннее 24 символов, а каждый отрендеренный объект получает лейбл packages.deckhouse.io/instance.

Подробнее в разделе «Установка и управление приложениями».

Эксклюзивная группа модулей

Группа модулей с одним и тем же значением параметра exclusiveGroup в module.yaml. В кластере одновременно может быть активен только один модуль группы.

Эксклюзивные группы предотвращают конфликты между модулями, которые выполняют схожие или несовместимые задачи. Включить второй модуль той же группы нельзя, пока активен первый.

Подробнее в разделе «Структура модуля».

Экспорт данных диска ВМ

Выгрузка содержимого диска виртуальной машины или его снимка в файл, чтобы перенести данные за пределы кластера.

Для экспорта нужен включённый модуль storage-volume-data-manager, а в командной строке утилита d8 версии 0.20.7 и выше. Экспорт выполняет команда d8 data export download. Диск не должен использоваться в момент экспорта, поэтому машину, к которой он подключён, сначала останавливают. Вместо диска можно выгрузить его снимок.

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

Подробнее в разделе «Экспорт данных диска виртуальной машины».