Конфигурация узлов (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). Доступен множественный выбор |
| Адрес локального репозитория | FQDN или адрес локального/зеркала репозитория образов. |
| Авторизация для репозитория | Учётные данные для доступа к реестру (если нужна авторизация). |
| Адрес внешнего репозитория | Адрес внешнего репозитория |
Добавление реестра: нажмите + в блоке, заполните поля, нажмите Добавить.
Блок «Плагины»
В блоке Плагины настраиваются секции конфигурации 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 — параметр должен быть удалён из плагина. |
| Ключ | Ключ параметра. |
| Значение | Значение параметра. Можно указать строковое или числовое значение, а также значения [] и "". |
Пример 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 с конфигурацией 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»
| Поле | Описание |
|---|---|
| Имя пользователя 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
Просмотр применения NCI
На странице узла во вкладке Конфигурация узла отображается список NCI, запланированных к применению на этот узел, и статус применения. При ошибке отображается статус Не применено.
Справочная информация
- Объект NCI (NodeConfigItem) — структура и назначение шаблона конфигурации узлов.
- NodeConfig (NC) — экземпляр конфигурации для конкретного узла и статус применения NCI.
- Модуль shturval-node-config — архитектура оператора и демона
std, дрейн, перезагрузка, диагностика.