Конфигурация узлов (NCI)

Обзор

NCI (NodeConfigItem) — объект для применения конфигурации к узлам кластера без необходимости ручной настройки каждого узла. Оператор shturval-node-config применяет настройки к узлам согласно настроенному селектору (лейблам). NCI можно переиспользовать в разных кластерах.

Где настраивать: Кластер → Администрирование → Конфигурация узлов или импорт манифеста.

При создании кластера автоматически создаются NCI для подготовки узлов — таким образом оператор готовит узлы для присоединения в кластер, например:

controlplane-init-config — директории, файлы, Linux-пользователи для системных компонентов (например, etcd) на Control Plane узлах;
controlplane-oidc-nci — настройка Kube API Server на Control Plane узлах;
generic-init-config — директории, файлы, настройка параметров Container Runtime, параметры Sysctl, Systemd-юниты, период ротации кубовых сертификатов, доверенные сертификаты, а также устанавливает пакеты для shturvald (containerd) на всех узлах.

Обратите внимание! Название NCI после создания неизменяемое.

Обратите внимание! Удаление NCI и изменение параметров: Удаление объекта NCI не приводит к удалению настроенных параметров. Чтобы изменить параметры, создайте новый объект NCI с нужными значениями и установите для него более высокий приоритет — при конфликте применится конфигурация NCI с большим приоритетом.

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

Страница «Конфигурация узлов»

На странице Конфигурация узлов отображается список объектов NodeConfigItem (NCI) кластера.

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

Скриншот: список NCI

Просмотр и редактирование: нажмите на название NCI. На вкладке Узлы — список узлов, для которых настроен этот NCI, и статус применения. Изменения в разделах сохраняются по кнопке Продолжить (предварительно) и Завершить или Сохранить на странице NCI.

Чтобы изменить перечень настраиваемых разделов, перейдите на вкладку NCI и выберите дополнительные разделы или снимите выделение с ненужных.

Для редактирования через YAML перейдите на вкладку Манифест, внесите изменения и выполните проверку. Результат проверки отображается справа. Если формат манифеста NCI не прошёл валидацию, проверка манифеста недоступна. Несохранённые данные не применяются.

Создание и работа с NCI

Конфигурация узлов → Добавить NCI.
Задайте название и приоритет применения конфигурации (по умолчанию 100). При конфликте значений разных NCI применяется конфигурация с большим приоритетом.
Укажите селектор узлов (список лейблов узлов, к которым будет применена конфигурация).
Выберите один или несколько разделов для настройки:
- NTP;
- Container Runtime;
- Параметры sysctl;
- Репозитории пакетов;
- Пакеты для установки;
- Файлы и директории;
- Системные сертификаты (настройка периода ротации системных сертификатов Kubecerts);
- Доверенные сертификаты;
- Параметры загрузчика ядра (grub);
- Модули ядра (kernel modules);
- Systemd-юниты;
- Kubelet;
- Пользователи;
- Kube API Server.

Часть из этих элементов могут быть только в одном экземпляре (например, NTP), а часть – во множественном (например, директории или файлы).

Нажмите Продолжить и заполните параметры выбранных разделов; по завершении — Завершить.

Скриншот: основные данные NCI (название, приоритет, селектор узлов)

Скриншот: добавление лейбла

Скриншот: выбор разделов конфигурации

Селектор узлов

Механизм лейблов позволяет выбирать узлы, для которых требуется применение NCI. Примеры установки и выбора узлов для применения NCI:

Лейбл	Узлы
`node-role.kubernetes.io/control-plane`	Только Control Plane узлы
`node-role.kubernetes.io/worker`	Только Worker-узлы
`kubernetes.io/os: linux`	Все узлы с ОС linux

Команда для добавления лейбла: kubectl label node <name> node-role.kubernetes.io/worker=""

Команда для просмотра лейблов узлов: kubectl get nodes --show-labels

NCI — кластерный (не неймспейсный) кастомный ресурс (CRD) с типом NodeConfigItem (API-группа node.shturval.tech). При создании и применении NCI неймспейс не указывается. Создание, просмотр и применение выполняются через kubectl в контексте кластера, где установлен оператор shturval-node-config (клиентский кластер или кластер управления — в зависимости от сценария).

Просмотр NCI

# Список всех NCI в кластере
kubectl get nodeconfigitem
kubectl get nci

# Полный манифест NCI
kubectl get nodeconfigitem <name> -o yaml

# Краткий вывод с селектором и приоритетом
kubectl get nodeconfigitem -o wide

Применение манифеста NCI

# Создание или обновление NCI из файла
kubectl apply -f nci.yaml

# Предпросмотр изменений (dry-run)
kubectl apply -f nci.yaml --dry-run=client -o yaml

Удаление NCI

kubectl delete nodeconfigitem <name>
kubectl delete -f nci.yaml

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

Разделы конфигурации NCI

Ниже — назначение каждого блока, поля и примеры.

NTP

Настройка NTP-серверов и часового пояса.

Обратите внимание!

Для настройки NTP с помощью NCI необходимо, чтобы на ОС узлов кластера был установлен сервис ntpd или chronyd. Убедитесь, что один из них включен (active) и добавлен в автозагрузку (enabled). В противном случае установите пакет (в разделе Конфигурация узлов/Пакеты для установки) и запустите необходимый сервис (настраиваемый раздел Systemd-юниты) с помощью NCI.

Кроме NTP может использоваться chrony: работающий сервис определяется автоматически.

Настройки NTP на узлах кластера при инсталляции недоступна. По умолчанию устанавливается Timezone - Europe/Moscow

Настройка NTP-серверов при наличии установленного и включенного сервиса chronyd или ntpd

Поле	Описание
Список серверов NTP	Адреса корпоративных серверов. IP-адрес или FQDN NTP-серверов (не менее одного).
Имя сервиса NTP	Имя сервиса NTP, например, `ntpd` или `chronyd`.
Часовой пояс (timezone)	Часовой пояс, например, `Europe/Moscow`. По умолчанию — Europe/Moscow.

Скриншот: блок NTP

Установка chrony

Устанавливает пакет chrony и включает сервис chronyd.

apiVersion: node.shturval.tech/v1beta2
kind: NodeConfigItem
metadata:
  name: chrony
spec:
  nodeconfigselector:
    kubernetes.io/os: linux
  packages:
  - name: chrony
    state: present
  systemdunits:
  - active: true
    enabled: true
    name: chronyd

Установка ntp

Устанавливает пакет ntp и включает сервис ntpd.

apiVersion: node.shturval.tech/v1beta2
kind: NodeConfigItem
metadata:
  name: ntp
spec:
  nodeconfigselector:
    kubernetes.io/os: linux
  packages:
  - name: ntp
    state: present
  systemdunits:
  - active: true
    enabled: true
    name: ntpd

Установка chrony и настройка NTP

Устанавливает chrony, включает chronyd, задаёт NTP-серверы и часовой пояс.

apiVersion: node.shturval.tech/v1beta2
kind: NodeConfigItem
metadata:
  name: chrony
spec:
  nodeconfigselector:
    kubernetes.io/os: linux
  packages:
  - name: chrony
    state: present
  systemdunits:
  - active: true
    enabled: true
    name: chronyd
  ntp:
    servers:
    - 0.ru.pool.ntp.org
    - 1.ru.pool.ntp.org
    timezone: "Europe/Moscow"

Установка ntp и настройка NTP

Устанавливает ntp, включает ntpd, задаёт NTP-серверы и часовой пояс.

apiVersion: node.shturval.tech/v1beta2
kind: NodeConfigItem
metadata:
  name: ntp
spec:
  nodeconfigselector:
    kubernetes.io/os: linux
  packages:
  - name: ntp
    state: present
  systemdunits:
  - active: true
    enabled: true
    name: ntpd
  ntp:
    servers:
    - 0.ru.pool.ntp.org
    - 1.ru.pool.ntp.org
    timezone: "Europe/Moscow"

Настройка NTP

apiVersion: node.shturval.tech/v1beta2
kind: NodeConfigItem
metadata:
  finalizers:
  - node.shturval.tech/finalizer
  name: ntp-example
spec:
  ntp:
    servers:
    - 0.ru.pool.ntp.org
    - 1.ru.pool.ntp.org
    timezone: "Europe/Moscow"
  nodeconfigselector:
    kubernetes.io/os: linux

Container Runtime

Container Runtime должен быть установлен на каждом узле кластера для обеспечения возможности kubelet запускать поды и контейнеры в них. Настройка конфигурации контейнерного рантайма (containerd): реестры образов (зеркала, авторизация), при необходимости — кастомные секции конфига (например, Nvidia runtime).

Блок «Конфигурация реестров контейнеров»

Поле	Описание
Возможности репозитория	Управление и хранение образов: добавлять новые (push); извлекать (pull); преобразовывать имя образа в репозитории в его цифровое (digest) представление (resolve). Доступен множественный выбор.
Исходный реестр	Имя реестра в манифестах нагрузок, например, `docker.io` (Docker Hub). Кластер сопоставляет его с зеркалом, если зеркало задано.
Логин	Имя пользователя приватного исходного реестраЛогин и Пароль задаются только парой.
Пароль	Пароль приватного исходного реестраЛогин и Пароль задаются только парой.
Адрес зеркала реестра	FQDN или адрес локального/зеркала репозитория образов, откуда кластер загружает образы вместо исходного реестра. Пример: mirror-registry.corp.domainПри обращении к docker.io запросы уйдут в это зеркало, а не в Docker Hub.
Авторизация в зеркало	Учётные данные для доступа к зеркалу, если зеркало требует авторизацию. Пример: `Basic base64_string`.

Логин и Пароль записываются в /etc/containerd/config.toml как секция plugins."io.containerd.grpc.v1.cri".registry.configs."<исходный-реестр>".auth (ключи username и password). Адрес зеркала реестра и Авторизация в зеркало попадают в другой файл — hosts.toml этого реестра. Это независимые настройки.

Если логин и пароль не заданы, секция auth не создаётся. Чтобы снять уже записанные учётные данные, очистите оба поля и сохраните: секция уйдёт с exist: false, и демон удалит её из config.toml. Остальные ключи файла, которых нет в configSections, демон не меняет. После применения containerd перезапускается.

Скриншот: окно добавления конфигурации реестров образов

Блок «Плагины»

В блоке Плагины настраиваются секции конфигурации containerd (runtimecfg.configSections[]). После добавления плагин отображается в списке по значению поля Путь.

Поле	Описание
Путь	Полный путь, включая секции и подсекции конфигурации containerd. Пример: `plugins."io.containerd.grpc.v1.cri".containerd.default_runtime`.
Наличие плагина	Присутствует `configSections.exist: true` — секция добавлена в конфигурацию; Отсутствует `configSections.exist: false` — секция должна быть удалёна.
Параметры	Список параметров плагина.
Наличие параметра	Присутствует `configSections.params[].exist: true` — параметр добавлен в плагин; Отсутствует — `configSections.params[].exist: false` — параметр должен быть удалён из плагина.
Ключ	Ключ параметра.
Значение	Значение параметра. Можно указать строковое или числовое значение, а также значения `[]` и `""`.

Обратите внимание! Настройка приватного реестра образов доступна в разделе Конфигурация реестров контейнеров. В блоке Плагины секцию plugins."io.containerd.grpc.v1.cri".registry.configs."<registry-name>".auth создать нельзя; уже заданная секция в этом блоке не отображается.

Пример NCI

apiVersion: node.shturval.tech/v1beta2
kind: NodeConfigItem
metadata:
  name: runtime
spec:
  nodeconfigselector:
    kubernetes.io/os: linux
  runtimecfg:
    registries:
    - capabilities:
      - resolve
      - pull
      host: https://yourhostname:443
      name: r.shturval.tech
  priority: 100

Пример NCI с логином и паролем приватного реестра

apiVersion: node.shturval.tech/v1beta2
kind: NodeConfigItem
metadata:
  name: private-registry
spec:
  nodeconfigselector:
    kubernetes.io/os: linux
  priority: 100
  runtimecfg:
    registries:
    - capabilities:
      - resolve
      - pull
      name: myprivateregistry.domain.ltd
    configSections:
      - exist: true
        path: plugins."io.containerd.grpc.v1.cri".registry.configs."myprivateregistry.domain.ltd".auth
        params:
          - exist: true
            key: username
            value: myLogin
          - exist: true
            key: password
            value: myPassword

Пример NCI с конфигурацией Nvidia Runtime

apiVersion: node.shturval.tech/v1beta2
kind: NodeConfigItem
metadata:
  name: nvidia-runtime
spec:
  nodeconfigselector:
    node-role.kubernetes.io/gpu: ""
  priority: 100
  runtimecfg:
    configSections:
      - exist: true
        params:
          - exist: true
            key: default_runtime_name
            value: nvidia
        path: plugins."io.containerd.grpc.v1.cri".containerd
      - exist: true
        params:
          - exist: true
            key: base_runtime_spec
            value: ""
          - exist: true
            key: cni_conf_dir
            value: ""
          - exist: true
            key: cni_max_conf_num
            value: 0
          - exist: true
            key: container_annotations
            value: []
          - exist: true
            key: pod_annotations
            value: []
          - exist: true
            key: privileged_without_host_devices
            value: false
          - exist: true
            key: runtime_engine
            value: ""
          - exist: true
            key: runtime_path
            value: ""
          - exist: true
            key: runtime_root
            value: ""
          - exist: true
            key: runtime_type
            value: io.containerd.runc.v2
        path: plugins."io.containerd.grpc.v1.cri".containerd.runtimes.nvidia
      - exist: true
        params:
          - exist: true
            key: BinaryName
            value: /usr/bin/nvidia-container-runtime
          - exist: true
            key: CriuImagePath
            value: ""
          - exist: true
            key: CriuPath
            value: ""
          - exist: true
            key: CriuWorkPath
            value: ""
          - exist: true
            key: IoGid
            value: 0
          - exist: true
            key: IoUid
            value: 0
          - exist: true
            key: NoNewKeyring
            value: false
          - exist: true
            key: NoPivotRoot
            value: false
          - exist: true
            key: Root
            value: ""
          - exist: true
            key: ShimCgroup
            value: ""
          - exist: true
            key: SystemdCgroup
            value: true
        path: plugins."io.containerd.grpc.v1.cri".containerd.runtimes.nvidia.options

Параметры sysctl

Параметры ядра Linux в формате ключ–значение. Записываются в файл /etc/sysctl.d/9999-shturval-items.conf и применяются на узле.

Поле	Описание
Список значений sysctl	Список значений sysctl в формате ключ-значение, например, `net.ipv4.ip_forward: "1"`, `vm.max_map_count: "262144"`.

Скриншот: параметры sysctl

Пример NCI: sysctl

apiVersion: node.shturval.tech/v1beta2
kind: NodeConfigItem
metadata:
  name: sysctl
spec:
  nodeconfigselector:
    kubernetes.io/os: linux
  sysctl:
    param:
      kernel.panic: "10"
      kernel.panic_on_oops: "1"
      net.bridge.bridge-nf-call-iptables: "1"
      net.ipv4.ip_forward: "1"
      vm.max_map_count: "262144"
      vm.overcommit_memory: "1"
  priority: 100

Репозитории пакетов

В этом разделе настраивается подключение сетевых репозиториев, которые работают по протоколам HTTP, HTTPS, FTP.

Поле	Описание
Название репозитория	Имя репозитория (обязательное).
Целевое состояние репозитория	Present — репозиторий подключить; Absent — отключить.
Адрес репозитория	URL или адрес репозитория (обязательное).
Значение публичного ключа репозитория	Публичный ключ для проверки пакетов репозитория.
Адрес для получения публичного ключа репозитория	URL для загрузки публичного ключа репозитория.
Проверять публичный ключ репозитория	Да — включить проверку ключа; Нет — отключить.
Использовать SSL соединение для подключения к репозиторию	Да — использовать SSL при подключении к репозиторию; Нет — не использовать.
Описание репозитория	Текстовое описание репозитория.
Файл, в котором был найден репозиторий	Путь к файлу на узле, в котором будет описан репозиторий.

Скриншот: репозитории пакетов

Пример NCI: репозитории пакетов

apiVersion: node.shturval.tech/v1beta2
kind: NodeConfigItem
metadata:
  name: repositories-example
spec:
  repositories:
  - name: corp-repo
    description: "Corp Linux repo"
    address: "https://repo.corp.domain.tld/repository/rpm"
    state: present
  nodeconfigselector:
    kubernetes.io/os: linux

Пакеты для установки

Установка или удаление пакетов на узлах (RPM/DEB в зависимости от ОС).

Поле	Описание
Название пакета	Имя пакета (обязательное).
Целевое состояние пакета	Present — установить; Absent — удалить.
Необходимая версия пакета	Конкретная версия пакета (при необходимости).
Установить запрет обновления пакета	Да — запретить обновление пакета; Нет — разрешить.
Снимать запрет обновления перед установкой	Да — снять запрет обновления перед установкой; Нет — не снимать.
Команды после установки пакета	Команды, выполняемые после установки.
Команды после установки должны выполниться успешно	Да — успешное выполнение обязательно; Нет — не обязательно.
Команды перед установкой пакета	Команды, выполняемые перед установкой.
Команды перед установкой должны выполниться успешно	Да — успешное выполнение обязательно; Нет — не обязательно.

Скриншот: пакеты для установки

Пример NCI: пакеты

apiVersion: node.shturval.tech/v1beta2
kind: NodeConfigItem
metadata:
  name: packages-example
spec:
  nodeconfigselector:
    kubernetes.io/os: linux
  packages:
  - name: jq
    state: present
  - name: mc
    state: absent

Файлы и директории

Создание файлов и директорий на узлах с заданными правами и владельцем.

Поле	Описание
Путь к файлу или директории	Полный путь на узле (обязательное).
Тип файла/директории	Файл или Директория.
Права доступа	В восьмеричном формате, например, `0644`, `0755`.
Владелец	Владелец файла/директории (пользователь).
Группа	Группа-владелец.
Содержимое файла	Содержимое файла.

Обратите внимание! при изменении имени директории создаётся новая директория с измененным именем. Директория с прежним именем не будет удалена.

Скриншот: файлы и директории

Пример NCI: директория

apiVersion: node.shturval.tech/v1beta2
kind: NodeConfigItem
metadata:
  name: directory
spec:
  files:
  - group: root
    mode: "0600"
    owner: root
    path: /etc/kubernetes
    type: directory
  nodeconfigselector:
    kubernetes.io/os: linux

Системные сертификаты (Kubecerts)

Период ротации системных сертификатов Kubernetes на узлах.

Поле	Описание
Период ротации системных сертификатов Kubernetes	Целое число от 7 до 365 (дней). По умолчанию 30.

Скриншот: системные сертификаты

Пример NCI: системные сертификаты (Kubecerts)

apiVersion: node.shturval.tech/v1beta2
kind: NodeConfigItem
metadata:
  name: kubecerts
spec:
  kubecerts:
    rotationperiod: 30
  nodeconfigselector:
    kubernetes.io/os: linux
  priority: 100

Доверенные сертификаты

Добавление корневых/доверенных CA-сертификатов на узлы (для проверки соединений, подписи и т.п.). Модальное окно: Добавление доверенного сертификата.

Поле	Описание
Способ добавления	Ручная загрузка — необходимо загрузить файл сертификата и указать имя; Из источника — укажите URL-адрес и имя сертификата. Вы можете указать URL с указанием протокола (доступен https) или без прямого указания протокола. Если протокол не указан, укажите порт. Если протокол и порт не указаны, будет автоматически добавлен порт 443.
Имя сертификата	Идентификатор для отображения и хранения (обязательное).
Статус сертификата	Подтверждён — CA может использоваться для подписания SSL-сертификатов; Не подтверждён — только доверие, без подписания. Использование центрами сертификации корневого сертификата будет возможно, если статус сертификата Подтверждён. Центры сертификации не смогут использовать корневой сертификат для подписания SSL-сертификатов, если статус корневого сертификата Не подтверждён.

Скриншот: доверенные сертификаты

Пример NCI: доверенные сертификаты

apiVersion: node.shturval.tech/v1beta2
kind: NodeConfigItem
metadata:
  name: certs
spec:
  certificates:
  - exist: true
    name: cert.crt
    url: https://example.com
  nodeconfigselector:
    kubernetes.io/os: linux

Параметры загрузчика ядра (GRUB)

Эта конфигурация меняет (добавляя или удаляя параметры) файл /etc/default/grub, генерирует конфигурацию grub и перезапускает узел для применения настроек. Модальное окно: Добавление параметра загрузчика ядра.

Поле	Описание
Наличие или отсутствие параметра	Присутствует — параметр добавлен в загрузчик; Отсутствует — параметр должен быть удалён.
Параметр ядра в загрузчике	Имя параметра (обязательное), например, `GRUB_TIMEOUT`.
Значение параметра ядра	Значение параметра.

Скриншот: параметры загрузчика ядра

Пример NCI: параметры загрузчика ядра (kernelarguments)

apiVersion: node.shturval.tech/v1beta2
kind: NodeConfigItem
metadata:
  name: kernelarg-example
spec:
  kernelarguments:
  - param: "GRUB_TIMEOUT"
    value: "1"
    exist: true
  nodeconfigselector:
    kubernetes.io/os: linux

Модули ядра

Управление модулями ядра Linux. Модальное окно: Добавление модуля ядра.

Поле	Описание
Имя модуля ядра	Имя модуля (обязательное).
Имя файла с опциями	Имя файла с опциями модуля (при необходимости).
Модуль ядра заблокирован	Да — модуль в blacklist, автозагрузка недоступна; Нет — не заблокирован.
Автозагрузка модуля ядра	Да — модуль загружается при загрузке ОС; Нет — не загружается автоматически. Недоступно, если модуль заблокирован.

Скриншот: модули ядра

Пример NCI: модули ядра

apiVersion: node.shturval.tech/v1beta2
kind: NodeConfigItem
metadata:
  name: kernelmodule-example
spec:
  nodeconfigselector:
    kubernetes.io/os: linux
  kernelmodules:
  - name: "br_netfilter"
    autoload: true
  - name: "zram"
    blacklist: true
    autoload: false

Systemd-юниты

Включение и автозагрузка systemd-сервисов на узлах.

Поле	Описание
Запустить сервис?	Да — сервис должен быть в состоянии active (запущен); Нет — не запускать.
Запускать сервис при запуске ОС?	Да — сервис включается при загрузке ОС (enabled); Нет — не включать.
Название systemd unit	Имя systemd-юнита (обязательное), например, `chronyd`, `containerd`, `kubelet`.

Скриншот: Systemd-юниты

Пример NCI: Systemd-юниты

apiVersion: node.shturval.tech/v1beta2
kind: NodeConfigItem
metadata:
  name: systemd-units
spec:
  nodeconfigselector:
    kubernetes.io/os: linux
  systemdunits:
  - active: true
    enabled: true
    name: containerd
  - active: true
    enabled: true
    name: kubelet

Kubelet

Параметры kubelet: политики CPU/RAM, лимиты подов, частоты обновления, TLS, пути к статическим подам и др.

Поле	Описание
Политика управления CPU	Это поле представляет стратегию, применяемую kubelet для управления распределением ресурсов процессора для запущенных на узле контейнеров. Например: none — должен распределять CPU по принципу совместного использования, CPU может быть использован подами в соответствии с их ограничениями, без каких-либо гарантий привязки CPU; static — предоставлять уникальные CPU-ядра для подов.
Политика управления RAM	Это поле представляет стратегию, применяемую kubelet для управления распределением ресурсов памяти для запущенных на узле контейнеров. Например: none — общий способ управления памятью; static — гарантирует строгое соответствие адресного пространства памяти.
Перечень резервируемых CPU	Список CPU, резервируемых для системных компонентов (например, `0-1`).
Параметры управления CPU	Это поле позволяет установить дополнительные параметры для управления процессором, например, использование определенных ядер. Например: “cpu_hard_limit” : “2” — устанавливает жесткое ограничение на использование CPU в 2; “cpu_soft_limit” : “1” — устанавливает мягкое ограничение на использование CPU в 1. Здесь левая часть вводится в виде ключа, правая в виде значения. Использование кавычек не требуется.
HairpinMode	Это поле определяет, как Kubelet настроит контейнерный мост для обработки hairpin-пакетов, которые идут между двумя подами на одном и том же узле. Доступные значения: HairpinVeth — hairpin мод канала включается; HairpinNone — hairpin мод канала выключен; PromiscuousBridge — все внутренние трафик устройства помещается в promiscuous mode (Включено по умолчанию).
MaxPods	Это поле задает максимальное количество подов, которые могут быть запущены с этой настройкой Kubelet. Например: 150 — Максимальное количество подов — 150; 200 — Максимальное количество подов — 200.
NodeStatusUpdateFrequency	Это поле определяет частоту, с которой kubelet вычисляет и обновляет состояние узла. Например: 10 s — обновление статуса узла каждые 10 секунд; 1 m — обновление статуса узла каждую минуту.
HTTPCheckFrequency	Это поле определяет период между проверками http для получения новых данных. Например: 30 s — Период между проверками http для получения новых данных — 30 секунд; 1 m — Период между проверками http для получения новых данных — 1 минута.
StaticPodURL	URL для доступа к настройкам статических подов. Например: http://example.com/static_pods.
ProtectKernelDefaults	Если этот параметр включен, Kubelet выдаст ошибку, если флаги ядра не соответствуют ожиданиям. Доступные значения: да — ошибка Kubelet, если флаги ядра не соответствуют ожиданиям; нет — нет проверки флагов ядра.
ServerTLSBootstrap	При включении этого параметра kubelet будет автоматически запускать серверные сертификаты. Включение этого параметра приведет к включению параметра RotateCertificates. Доступные значения: да — включает автозапуск сертификата сервера; нет — отключает автозапуск сертификата сервера.
Способ управления	Это поле определяет стратегию, которую Kubelet должен применять при принятии решений о привязке ресурсов. Доступные значения: restricted — нестандартные поды будут отклонены, которые не могут удовлетворить правильное выполнения карты вычислений топологии, если таковой имеется; best-effort — нестандартные поды будут запущены в режиме best-effort, они будут ограничены в ресурсах, если их не хватит для удовлетворения распределения по узлам kubelet; none — топология ресурсов не будет учитываться при запуске подов; single-numa-node — поды будут размещены так, чтобы их ресурсы были распределены внутри одного NUMA узла.
Стратегия обнаружения изменения ресурсов	Это поле определяет стратегию для отслеживания изменений в ConfigMaps и Secrets. Доступные значения: Get — настройка считывает ресурсы при каждом событии обновления; Cache — ресурсы кэшируются при обновлении ресурса для дальнейшего использования; Watch — сервер APIServer Kubernetes шлет уведомления о доступных обновлениях.
EnableServer	При включении этого параметра Kubelet будет работать в безопасном режиме сервера. Доступные значения: Да — включает защищенный сервер Kubelet; Нет — отключает защищенный сервер Kubelet.
StaticPodPath	Это поле задает путь к статическому поду или репозиторию со статическим подом. Например: /мой/путь/к/static/pod — определяет путь к каталогу, где располагаются манифесты статических подов; /home/user/my_static_pods — указывает каталог, в котором хранятся манифесты статических подов.
SyncFrequency	Это поле определяет максимальное время между синхронизацией контейнеров и конфигураций. Например: 30 s — время между синхронизаций контейнеров и конфигураций составляет 30 секунд; 2 m — время между синхронизаций контейнеров и конфигураций составляет 2 минуты.
FileCheckFrequency	Это поле задает время между проверками файлов конфигурации на наличие изменений. Например: 10 s — время между проверками файлов конфигураций на наличие изменений составляет 10 секунд; 1 m — время между проверками файлов конфигураций на наличие изменений составляет 1 минуту.
StaticPodURLHeader	Это поле позволяет настроить заголовки HTTP, используемые для доступа к URL статического пода. Например: {“X-Api-Key”: “123xyz” } — заголовки HTTP для доступа к URL статического пода содержат ключ API; {“Authorization”: “Basic QWxhZGRpbjpPcGVuU2VzYW1l”} — заголовки HTTP для доступа к URL статического пода содержат базовую авторизацию.
Address	Это поле определяет IP-адрес, на котором должен работать Kubelet. Например: 192.168.1.1 — Kubelet будет работать на IP-адресе 192.168.1.1; 10.0.0.1 — Kubelet будет работать на IP-адресе 10.0.0.1.
CgroupDriver	Это поле определяет, какой драйвер CGroups должен использовать Kubelet. systemd — Kubelet использует систему systemd для управления группами; cgroupfs — Kubelet использует файловую систему cgroupfs для управления группами.
RotateCertificates	Включение этого параметра активирует автоматическую ротацию сертификатов для Kubelet. Доступные значения: Да — включает ротацию сертификатов для Kubelet; Нет — отключает ротацию сертификатов для Kubelet.
EnableProfilingHandler	При включении этого параметра, профилирование через хост host:port/debug/pprof/ становится доступным. Доступные значения: Да — включает профилирование через хост host:port/debug/pprof/; Нет — отключает профилирование.
TLSMinVersion	Это поле определяет минимальную поддерживаемую версию протокола TLS.
Feature Gates	Включение или отключение функций (ключ и значение true/false).

Скриншот: раздел Kubelet

Подробнее о настройке CPU Pinning см. Резервирование CPU для etcd.

Пример NCI: Kubelet (CPU Pinning)

apiVersion: node.shturval.tech/v1beta2
kind: NodeConfigItem
metadata:
  name: cpu-pinning
spec:
  kubelet:
    cpuManagerPolicy: static
    featureGates:
      CPUManagerPolicyOptions: true
      CPUManagerPolicyAlphaOptions: true
      CPUManagerPolicyBetaOptions: true
    cpuManagerPolicyOptions:
      align-by-socket: "true"
      distribute-cpus-across-numa: "true"
      full-pcpus-only: "true"
    reservedSystemCPUs: 0-1
  nodeconfigselector:
    node-role.kubernetes.io/control-plane: ""
  priority: 100

Пользователи

Создание локальных пользователей на узлах (имя, домашняя директория, shell, группа, SSH-ключи).

Поле	Описание
Имя пользователя	Имя пользователя для подключения к узлу по SSH(обязательное).
Shell	Путь до командной оболочки., например, `/bin/bash` или `/sbin/nologin`.
Путь до домашней директории пользователя	Путь к домашней директории пользователя.
Группа	Локальная группа Linux для пользователя (обязательное).
SSH ключи	Публичные SSH-ключи.

Скриншот: пользователи

Пример NCI: пользователь

apiVersion: node.shturval.tech/v1beta2
kind: NodeConfigItem
metadata:
  name: users
spec:
  nodeconfigselector:
    node-role.kubernetes.io/control-plane: ""
  users:
  - group: etcd
    homedir: ""
    shell: /sbin/nologin
    username: etcd
  priority: 100

Kube API Server

Настройка kube-apiserver на Control Plane: ресурсы (requests/limits), Admission Plugins, OIDC, Feature Gates, Audit Policy, шифрование Secrets.

Блок «Ресурсы Kube API Server»

Поле	Описание
Requests / Limits	Requests и Limits для контейнера kube-apiserver. По умолчанию есть возможность установить запросы и лимиты на память (Memory) и CPU.
Priority class и приоритет	priorityClassName и priority пода kube-apiserver (по умолчанию `system-node-critical`, priority 2000001000). Под с данными значениями никогда не будет удален с узла.

Блок «Admission Plugins»

Действие	Описание
Включить плагин	Добавить в список и разрешить использование.
Выключить плагин	Добавить в список и запретить использование.
По умолчанию	Не добавлять плагин в список — остаются настройки по умолчанию.

Блок «OIDC»

В интерфейсе возможно настроить один OIDC-провайдер. Несколько JWT-issuer и файл AuthenticationConfiguration — в манифесте NCI, см. OIDC и AuthenticationConfiguration.

Поле	Описание
Имя пользователя claim (usernameclaim)	Claim для имени пользователя (по умолчанию `sub`).
Префикс имени пользователя	Префикс к имени из OIDC.
Группа claim (groupsclaim)	Claim для групп.
Префикс группы	Префикс к группам.
OIDC Issuer URL	URL издателя OIDC. Доступен только https протокол для подключения.
ID OIDC клиента (clientid)	Идентификатор клиента.
Файл CA (cafile)	CA-сертификат в base64 (опционально).

Блок «Feature Gates»

Ключ и значение (true/false) для включения или отключения функций Kubernetes.

Блок «Audit Policy»

Поле	Описание
Audit Policy	Политика аудита в base64.
Максимальное количество копий логов	Если необходимо отключить ограничение на количество копий, установите 0.
Срок хранения логов (дни)	Максимальное количество дней.
Максимальный размер логов, Mb	Размер в мегабайтах.

Блок «Secrets Encryption»

Конфигурация шифрования Secrets (в base64).

Обратите внимание! при размещении Audit Policy kube-apiserver перезапускается. Проверьте валидность YAML перед применением.

Скриншот: Kube API Server в NCI

Пример NCI: Kube API Server (OIDC)

apiVersion: node.shturval.tech/v1beta2
kind: NodeConfigItem
metadata:
  name: oidc-nci
spec:
  nodeconfigselector:
    node-role.kubernetes.io/control-plane: ""
  kubeapi:
    oidc:
      cafile: LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tClvQtNCw0L3QvdGL0LUg0LIg0LrQvtC00LjRgNC+0LLQutC1IGJhc2U2NF0KLS0tLS1FTkQgQ0VSVElGSUNBVEUtLS0tLQ==
      clientid: backend
      groupsclaim: claims
      groupsprefix: "shturval:"
      issuerurl: https://shturval.clustername.ip-10-11-12-13.shturval.link
      usernameclaim: sub
      usernameprefix: "shturval:"
  priority: 100

Несколько JWT-issuer задаются в spec.kubeapi.authenticationConfiguration.jwt. Пример и правила merge — в OIDC и AuthenticationConfiguration.

Просмотр применения NCI

На странице узла во вкладке Конфигурация узла отображается список NCI, запланированных к применению на этот узел, и статус применения. При ошибке отображается статус Не применено.

Справочная информация

Объект NCI (NodeConfigItem) — структура и назначение шаблона конфигурации узлов.
NodeConfig (NC) — экземпляр конфигурации для конкретного узла и статус применения NCI.
Модуль shturval-node-config — архитектура оператора и демона std, дрейн, перезагрузка, диагностика.

Изменено 2026-09-16 в 17:07

Конфигурация узлов (NCI)

Обзор #

Страница «Конфигурация узлов» #

Создание и работа с NCI #

Селектор узлов #

Просмотр NCI #

Применение манифеста NCI #

Удаление NCI #

Разделы конфигурации NCI #

NTP #

Установка chrony #

Установка ntp #

Установка chrony и настройка NTP #

Установка ntp и настройка NTP #

Настройка NTP #

Container Runtime #

Пример NCI #

Пример NCI с логином и паролем приватного реестра #

Пример NCI с конфигурацией Nvidia Runtime #

Параметры sysctl #

Пример NCI: sysctl #

Репозитории пакетов #

Пример NCI: репозитории пакетов #

Пакеты для установки #

Пример NCI: пакеты #

Файлы и директории #

Пример NCI: директория #

Системные сертификаты (Kubecerts) #

Пример NCI: системные сертификаты (Kubecerts) #

Доверенные сертификаты #

Пример NCI: доверенные сертификаты #

Параметры загрузчика ядра (GRUB) #

Пример NCI: параметры загрузчика ядра (kernelarguments) #

Модули ядра #

Пример NCI: модули ядра #

Systemd-юниты #

Пример NCI: Systemd-юниты #

Kubelet #

Пример NCI: Kubelet (CPU Pinning) #

Пользователи #

Пример NCI: пользователь #

Kube API Server #

Пример NCI: Kube API Server (OIDC) #

Просмотр применения NCI #

Справочная информация #