Работа с кластером

Дашборд кластера

Дашборд кластера динамически изменяется. После выбора инициализации создания кластера и до момента завершения развертывания кластера дашборд представляет собой первую версию. По завершении развертывания ‒ вторую.

Дашборд кластера до завершения развертывания кластера

В верхней части отображается название кластера. Под названием расположены дата и время создания кластера.

Доступна только вкладка "Кластер".

В левой верхней части вкладки "Кластер" отображается блок "Группы узлов кластера", на котором по мере развертывания кластера можно отследить готовность узлов кластера. Блок содержит сведения о группах узлов.

В блоке доступна информация:

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

Каждый элемент, помеченный зеленым цветом, представляет сведения об узле в статусе "Ready", каждый красный об узле в статусе "NotReady".

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

В правой части экрана расположен блок "Статус кластера". Данные обновляются автоматически по мере развертывания кластера.

Дашборд развернутого кластера

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

Доступны вкладки (рисунок 111):

Кластер;
Аннотации;
События;
События безопасности;
Сертификаты;
Метеринг.

Рисунок 111 ‒ Дашборд развернутого кластера

Все вкладки дашборда автоматически обновляются для максимально быстрого предоставления актуальных сведений о главных объектах кластера.

Доступны кнопки просмотра статистики, логов, перехода в Argo CD:

По кнопке Статистика открывается интерфейс внешнего модуля мониторинга (Grafana). Происходит SSO-авторизация.
По кнопке Логи открывается интерфейс модуля графического отображения логов (OpenSearch). Происходит SSO-авторизация.
По кнопке Argo CD открывается интерфейс модуля непрерывной доставки приложений (Argo CD). Происходит SSO-авторизация.

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

Кнопка Статистика отображается, если установлены и включены сервисы:
в вашем кластере "Компонент управления модуля мониторинга (Victoria Metrics Agent)" (shturval-metrics-collector) (п. Модуль мониторинга. Централизованный сбор метрик (Victoria Metrics));
в кластере управления "Модуль графического отображения метрик (Grafana)" (shturval-dashboards) (п. Модуль графического отображения метрик (Grafana)) и "Модуль мониторинга. Централизованный сбор метрик (Victoria Metrics)" (shturval-monitoring) (п. Модуль мониторинга. Централизованный сбор метрик (Victoria Metrics)).
Кнопка Логи отображается, если в вашем кластере установлен и включен "Модуль локального сбора логов (Vector)" (shturval-log-collector) (п. Модуль локального сбора логов (Vector)) и в кластере управления установлен и включен "Модуль централизованного хранения логов (OpenSearch)" (shturval-logs-operator) (п. Модуль централизованного хранения логов (OpenSearch)).
Кнопка Argo CD отображается, если в вашем кластере установлен и включен "Модуль непрерывной доставки приложений (ArgoCD)" (shturval-cd) (п. Модуль непрерывной доставки приложений (Argo CD)).

Доступно создание информационного сообщения (баннера), который будет отображаться для всех пользователей при работе с кластером в графическом интерфейсе. Пиктограмма для размещения информационного сообщения доступна в правом верхнем углу страницы "Дашборд" кластера (рисунки 112‒114).

Рисунок 112 ‒ Пиктограмма добавления информационного сообщения (баннера)

Рисунок 113 ‒ Добавление информационного сообщения (баннера)

Рисунок 114 ‒ Отображение информационного сообщения (баннера) для пользователей

Вкладка "Кластер"

Блок "Группы узлов кластера" содержит сведения о группах узлов (п. Группы узлов). При нажатии на название блока произойдет переход на страницу "Управление узлами" (рисунок 115).

Рисунок 115 ‒ Управление узлами

В блоке доступна информация:

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

Каждый элемент, выделенный зеленым цветом, представляет сведения об узле в статусе "Ready", каждый выделенный красным ‒ об узле в статусе "NotReady". Если в группе больше шести узлов, вместо графических элементов будет отображено числовое отношение работоспособных узлов к запрошенному количеству.

Блок "Описание" содержит информацию о кластере, заданной в процессе создания кластера, а также сведения о пользователе, создавшем кластер.

Блок "Обновление кластера" содержит сведения об установленной версии кластера. В кластере доступен ручной и автоматизированный запуск обновления (рисунок 116).

Рисунок 116 ‒ Обновление кластера

Блок "Сервисы" содержит счетчики установленных, включенных и работающих сервисов с разделением на общее количество и количество критических сервисов.

Верхний ряд счетчика кликабелен. При нажатии на название блока или на число счетчика происходит переход на страницу "Установленные сервисы кластера" (рисунок 117).

Рисунок 117 ‒ Установленные сервисы кластера

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

При нажатии на название блока или на числовое значение счетчика происходит переход на страницу "Просмотр оповещений кластера" (рисунок 118). Раздел не отображается, если в кластере не установлен или отключен модуль локального сбора метрик, а в кластере управления не установлен или отключен модуль централизованного хранения метрик.

Рисунок 118 ‒ Просмотр оповещений кластера

Приостановка реконсиляции инфраструктуры (Paused) кластера (рисунок 119) временно останавливает применение изменений и проверок в машинах/узлах кластера. Все запрашиваемые изменения записываются в очередь и будут применены после возобновления реконсиляции.

Рисунок 119 ‒ Приостановка реконсиляции кластера

Приостановка реконсиляции инфраструктуры доступна администратору кластера и администратору Комплекса. Для управления нужно перейти на дашборд кластера.

Приостановка может быть необходима в разных ситуациях.

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

Вкладка "Аннотации"

В списке кластеров на вкладке "Кластеры" доступна сортировка по признаку. Чтобы присвоить признак кластеру, нужно добавить аннотацию с ключом tag.

Для этого следует перейти на страницу "Дашборд" кластера. На вкладке "Аннотации", которая содержит список всех аннотаций кластера, нажать + для добавления аннотации. В появившемся модальном окне ввести "tag" в поле "Ключ" и необходимый признак в поле "Значение". Далее нужно сохранить данные, нажав Сохранить, и признак к кластеру будет добавлен (рисунок 120).

Рисунок 120 ‒ Добавление аннотации

Для удаления аннотации нужно нажать на "крестик" выбранной аннотации и подтвердить действие.

После внесения изменений в перечень аннотаций следует нажать Сохранить.

Например, чтобы сортировать кластеры по признаку окружения со значениями prod или test, при добавлении аннотации кластера необходимо указать в поле "Ключ" ‒ "tag", а в поле "Значение" ‒ prod. Для следующего кластера требуется добавить аннотацию с ключом tag и значением test (рисунок 121). При необходимости можно создать аннотации для всех ваших кластеров.

Рисунок 121 ‒ Сортировка аннотаций

Поддерживаются аннотации на русском и английском языках. В списке кластеров доступна сортировка и фильтрация по присвоенному признаку (аннотации с ключом tag).

Вкладка "События"

Вкладка "События" содержит сведения о событиях всех объектов кластера (дата и время, источник события, объект, индикатор типа события, текст события).

Вкладка "События безопасности"

Вкладка "События безопасности" (рисунок 122) содержит сведения о событиях, соответствующих правилам AuditPolicy (п. Audit Policy) всех объектов кластера согласно настроенной политике безопасности за последний час. События безопасности пишутся в кластере, если в кластере установлены расширенные настройки безопасности.

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

Данные о событиях безопасности могут отсутствовать в случаях, если:

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

Рисунок 122 ‒ Вкладка "События безопасности"

Вкладка "Сертификаты"

Вкладка "Сертификаты" (рисунок 123) содержит сведения обо всех сертификатах кластера, которые формируются на основе данных "Модуля проверки сертификатов API Kubernetes". По каждому сертификату можно просмотреть:

дату истечения срока действия;
количество оставшихся дней действия сертификата.

Рисунок 123 ‒ Вкладка "Сертификаты"

Вкладка "Метеринг"

Метеринг в кластере ‒ это упрощенное представление биллинга в разрезе неймспейсов (рисунок 124). В РОСА Кубис реализовано долгосрочное хранение метрик (до года) неймспейсов для кластеров в отдельном инстансе VictoriaMetrics. Для каждого неймспейса записывается расход CPU/час и RAM/час.

Рисунок 124 ‒ Вкладка "Метеринг"

На вкладке "Метеринг" есть возможность получить сведения об израсходованных ресурсах по неймспейсу:

за последний час;
за последнюю неделю;
за последний месяц;
за последний год;
за выбранный диапазон времени.

Действия в кластере

Импорт манифестов

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

На открывшейся странице нужно ввести, выбрать из файла на компьютере или переместить манифест объекта для импорта. Чтобы импортировать несколько манифестов одновременно, необходимо разместить их в одном файле с разделителем "---" и затем выбрать этот файл для загрузки. Загруженные манифесты проверяются на синтаксис YAML автоматически. Файл, перемещенный или выбранный с устройства, распознается и отображается в окне введения данных. Может быть распознан только валидный YAML.

Пример загрузки файлов показаны на рисунках 125 и 126.

Рисунок 125 ‒ Загрузка файла с одним манифестом

Рисунок 126 ‒ Загрузка файла с двумя манифестами

Запуск проверки приводит к "DRY RUN (server)"-применению манифеста в Kubernetes.

Результат проверки каждого загруженного манифеста будет приведен в правой стороне экрана. Для удобства использования кнопка Загрузить доступна в верхней и нижней частях экрана. Загрузка манифестов доступна только после проверки их в режиме "DRY RUN". Статус результата проверки отображается в строчке объекта. Чтобы просмотреть полный манифест и описание результата проверки, требуется раскрыть строчку с объектом.

Если в результате проверки в режиме "DRY RUN" не выявлено ошибок, отобразится сообщение, что "Манифест объекта может быть применен".

Примеры успешного и ошибочного результата проверки манифеста показаны на рисунках 127 и 128.

Рисунок 127 ‒ Успешный результат проверки манифеста

Рисунок 128 ‒ Результат проверки манифеста с ошибкой

Изменение объектов в виде манифестов можно произвести на страницах объектов на вкладке "Манифест".

Получение kubeconfig

Пользователь может скачать конфигурацию кластера с доступом, соответствующим правам его кластерным разрешениям. Для скачивания kubeconfig из графического интерфейса нужно нажать пиктограмму справа от имени пользователя. В выпадающем списке выбрать пункт "Скачать Kubeconfig" (рисунок 129). Загрузка начнется автоматически.

Рисунок 129 ‒ Получение kubeconfig

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

При необходимости изменения времени действия токена можно выполнить шаги по Инструкции "Как изменить время жизни токена" или указать значение параметра expired при запросе на создание kubeconfig. Время действия токена можно указать в минутах (m) и часах (h). Например, если нужен токен, выписанный на 4 дня, указывают параметр "expired=168".

Для получения kubeconfig в интерфейсе командной строки воспользоваться модулем kubectl-shturval-plugin (п. Загрузка конфигурационного файла для kubectl-shturval-plugin) или следует использовать Client URL.

Применение Client URL

Некоторые случаи применения Client URL:

Экспорт переменных для авторизации и скачивания kubeconfig.

Переменные:

export CLUSTERNAME=my-cluster
export SH_USERNAME="admin"
export SH_PASS="my-password"
export INGRESS="apps.ip-x-x-x-x.shturval.link"
export AUTHENDPOINT="https://auth.$INGRESS"
export BACKENDPOINT="https://back.$INGRESS"
export KUBECONFIG_PATH=/tmp/$CLUSTERNAME.conf
export CLIENT_SECRET=clientsecret
export COOKIE_PATH=/tmp/cookie

Авторизация, при которой в пути авторизации указать параметр "expired=время жизни токена". В примере проставлено время действия токена 48 часов дня (expired=48h).

Команда:

curl -k -v --silent $AUTHENDPOINT/login -c $COOKIE_PATH --data-urlencode "username=$SH_USERNAME" \
--data-urlencode "password=$SH_PASS" &>/dev/null
echo "Got cookie"
code=$(curl -k -b $COOKIE_PATH -v "$AUTHENDPOINT/oauth/authorize?response_type=code&client_id=backend&expired=48h&redirect_uri=localhost/cb" -v 2>&1 | grep -E -o "\<code=[A-Z0-9]+")
echo "Got code"
token=$(curl -k --silent "$AUTHENDPOINT/oauth/token" \
--header 'Content-Type: application/x-www-form-urlencoded' \
-b $COOKIE_PATH \
--data-urlencode 'client_id=backend' \
--data-urlencode "client_secret=$CLIENT_SECRET" \
--data-urlencode 'grant_type=authorization_code' \
--data-urlencode "$code" \
--data-urlencode "redirect_uri=localhost/cb" | jq -r '.access_token')
echo "Got token"

Отправка запроса на получение kubeconfig.

Команда:

curl -k --silent "$BACKENDPOINT/api/v1/clusters/$CLUSTERNAME/kubeconfig" -H "Authorization: Bearer $token" -H 'accept: application/json, text/plain, */*' > $KUBECONFIG_PATH
echo "Kubeconfig is ready"
echo "export KUBECONFIG=$KUBECONFIG_PATH"

Загрузка конфигурационного файла для kubectl-shturval-plugin

При авторизации с помощью модуля kubectl-shturval-plugin потребуется указать набор параметров для подключения к Комплексу. Можно запросить параметры напрямую из интерфейса командной строки или скачать конфигурационный файл (shturval-login-plugin.yaml) с параметрами из графического интерфейса.

Доступно скачивание:

конфигурационного файла, настроенного на загрузку всех kubeconfig клиентских кластеров, доступных пользователю. На главной странице РОСА Кубис нажать пиктограмму справа от имени пользователя и выбрать "Скачать config shturval-login-plugin для всех кластеров" (рисунок 130).

Рисунок 130 ‒ Скачивание всех kubeconfig

конфигурационного файла, настроенного на загрузку kubeconfig доступного пользователю одного клиентского кластера. Для этого перейти в кластер, нажать пиктограмму справа от имени пользователя и выбрать "Скачать config для shturval-login-plugin" (рисунок 131).

Рисунок 131 ‒ Скачивание одного kubeconfig

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

Назначение прав доступа пользователям/группе пользователей для кластера управления или клиентского кластера можно произвести со страницы "Управление доступом" в кластере, а также со страницы "Управления ролями" в Комплексе при наличии соответствующих разрешений. Назначение прав доступа уровня "Платформа" доступно только в Комплексе со страницы "Управления ролями".

На странице "Управление доступом" раздела "Администрирование" доступны три вкладки (рисунок 132):

Платформа;
Кластер;
Неймспейс.

Рисунок 133 ‒ Управление доступом

Со страницы "Управление доступом" кластера при наличии соответствующих разрешений можно:

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

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

В блоке "Статус применения в кластере управления" сгруппированы результаты применения назначений в самом кластере управления (см. Сноска 1) в Opensearch.
Блок "Статус применения в клиентских кластерах" отражает успешность применения прав доступа в кластере и применение ролей в ArgoCD. Для уровня "Платформа" приведен количественный показатель, отражающий отношение кластеров, в которых назначение было успешно применено, к общему количеству кластеров. Для остальных уровней приведена цветовая индикация успешности применения назначений.

Сноска 1

Кластер управления отвечает за некоторые объекты клиентских кластеров, например, объекты API-групп: cluster.x-k8s.io, bootstrap.cluster.x-k8s.io, infrastructure.cluster.x-k8s.io, permissions.shturval.tech. Поэтому на каждом уровне доступа в набор доступа для получения таких объектов необходимы платформенные разрешения. Именно поэтому в статусах назначения прав доступа можно увидеть применение назначения в кластер управления, даже если назначенные разрешения относятся к кластеру или неймспейсу.

Согласно цветовой индикации:

зеленый ‒ успешно применено;
красный ‒ в результате применения прав доступа есть ошибки;
серый ‒ применение не требуется. Это может быть в случае, если в наборе доступов не было запрошено выделение прав доступа, например, в Opensearch.

Назначение прав группе пользователей

Для назначения прав доступа группе пользователей нужно перейти на вкладку скоупа, к которому требуется предоставить доступ (вкладка "Кластер" или "Неймспейс"), нажать +. На открывшемся экране (рисунок 134) отобразится форма "Назначение прав доступа" группе, в которой нужно:

В поле "Название группы" начать вводить имя группы. Со второго введенного символа будет выполнен поиск группы по каталогу, подключенному при интеграции с LDAP (например, AD или openLDAP). Если каталог не подключен, нельзя будет указать название группы вручную и назначить права группе пользователей.
В результате поиска будет получен список имен групп, в котором выбрать необходимую группу из списка. Поиск регистрозависимый: если не найдена группа, уточнить введенные данные.

Рисунок 134 ‒ Назначение прав доступа группе

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

Назначение прав пользователю

Для назначения прав доступа пользователю нужно перейти на вкладку скоупа, к которому требуется предоставить доступ (вкладка "Кластер" или "Неймспейс"), и нажать +. На открывшемся экране (рисунок 135) отобразится форма "Назначение прав доступа", в которой нужно:

Примечание ‒ Уникальное имя пользователя возможно задать в соответствии с каталогом, подключенным при интеграции с LDAP (например, AD или openLDAP). Если каталог не подключен, нельзя будет указать пользователя вручную и назначить ему права.

В поле "Уникальное имя пользователя" начать вводить имя пользователя. Со второго введенного символа будет выполнен поиск пользователей по каталогу. В результате поиска отобразится список пользователей, имена которых содержат указанные символы.
Выбрать имя пользователя из списка. Поиск по каталогу регистрозависимый: если пользователь не найден или отсутствует в списке, уточнить введенные данные.

Рисунок 135 ‒ Назначение прав доступа пользователю

Когда "Уникальное имя пользователя" заполнено, выбрать наборы доступов, которые требуется присвоить пользователю, затем нажать кнопку Сохранить. Имя пользователя после создания записи не будет доступно для редактирования. При необходимости изменения имени пользователя можно удалить запись и создать новую.

См. подробнее о наборах доступов (п. Менеджер доступов), доступных для назначения.

Следует обратить внимание, что, если набор доступов включает роль в ArgoCD, то:

при назначении набора доступов на уровне кластера группе/пользователю будет открыт доступ ко всем проектам ArgoCD этого кластера.
при назначении набора доступов на уровне неймспейса группе/пользователю будет открыт доступ к проекту ArgoCD только одного неймспейса.

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

В каждом кластере установлен модуль конфигурации узлов ‒ это такой оператор, который позволяет разместить объекты конфигурации узлов (NCI) на выбранные узлы без необходимости ручной конфигурации каждого узла. Некоторые объекты конфигурации создаются автоматически при создании кластера ‒ таким образом оператор готовит узлы для присоединения в кластер, например:

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

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

На странице "Конфигурация узлов" кластера отображается перечень объектов Node Config Item (NCI) клиентского кластера (рисунок 136).

Рисунок 137 ‒ Конфигурация узлов кластера

По каждому Node Config Item (NCI) отображается:

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

Создание NCI

Для создания необходимо задать название и приоритет NCI (рисунок 138). Приоритет возрастает с увеличением числового значения.

Рисунок 138 ‒ Создание NCI

Для применения NCI для всех Master-узлов в селекторе узлов требуется добавить лейбл с ключом node-role.kubernetes.io/control-plane. Поле "Значение" следует оставить незаполненным (рисунок 139).

Рисунок 139 ‒ Добавление лейбла с ключом

Node Config Item (NCI) включает один или несколько элементов конфигурации. Визуально элементы представлены в виде настраиваемых блоков. Доступны следующие блоки (рисунок 140):

NTP;
Container Runtime;
Параметры sysctl;
Репозитории пакетов;
Пакеты для установки;
Файлы и директории;
Системные сертификаты (настройка периода ротации системных сертификатов Kubecerts);
Доверенные сертификаты;
Параметры загрузчика ядра (grub);
Модули ядра (kernel modules);
Systemd-юниты;
Kubelet;
Пользователи.

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

Рисунок 140 ‒ Настраиваемые разделы

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

Для добавления NCI необходимо выполнить следующие действия:

На вкладке "Узлы кластера" нажать кнопку Добавить NCI. Откроется форма настройки конфигурации.
Ввести название.
Указать список лейблов узлов, к которым будет применена конфигурация.

Для узлов ControlPlane следует прописать в ключ node-role.kubernetes.io/control-plane. Если необходимо создать NCI для Worker-узлов, рекомендуется назначить нужным Worker-узлам лейбл, затем добавить этот лейбл в виде ключа в селекторе узлов конфигурации узлов (NCI). Это можно сделать из интерфейса клиентского кластера на странице "Конфигурация узлов" в разделе "Администрирование" или с помощью командного интерфейса.

Команда для установки лейбла:

kubectl label node node-role.kubernetes.io/worker="

Команда для просмотра лейблов узлов:

kubectl get nodes --show-labels

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

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

Для сохранения всего объекта требуется нажать Завершить. Эта кнопка будет доступна на шаге последнего раздела среди выбранных для изменения.

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

Конфигурация разделов NCI

NTP

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

Пример манифеста NCI для установки пакета chrony и включения сервиса:

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-серверов при наличии установленного и включенного сервиса chronyd или ntpd необходимо в блоке "NTP" (рисунок 141):

Рисунок 141 ‒ Настройка NTP-серверов

в поле "Список серверов NTP" добавить адреса корпоративных серверов: не менее одного сервера NTP, для чего ввести в поле IP-адрес или FDQN сервера. При необходимости можно изменить значение по умолчанию для часового пояса;
задать имя сервиса NTP;
для настройки NTP на узлах кластера при установке (stc) можно указать параметры "--timezone" и "--ntp-servers"

Пример:

--timezone=Europe/Moscow --ntp-servers=10.255.245.2,10.255.245.3

Кроме NTP, также может быть использован chrony. Тогда в конфигурации вместо ntp.conf используется chrony.conf, при этом формат файла остается таким же.

Пример:

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"
ntpconfig: "/etc/ntp.conf"
nodeconfigselector:
kubernetes.io/os: linux

Для продолжения заполнения разделов нажать Продолжить.
По окончании заполнения разделов нажать Завершить.

Container Runtime

Container Runtime должен быть установлен на каждом узле кластера для обеспечения возможности kubelet запускать поды и контейнеры в них. Для конфигурирования нужно выполнить следующие действия (рисунок 142):

Рисунок 142 ‒ Container Runtime

Раскрыть блок "Container Runtime";
Ввести адрес и версию образа контейнера Pause;
Настроить конфигурацию реестров контейнеров:
- Раскрыть блок "Конфигурация реестров контейнеров". Реестр контейнеров позволяет хранить образы и управлять ими:
  - добавлять новые (push);
  - извлекать (pull);
  - преобразовывать имя образа в репозитории в его цифровое (digest) представление (resolve).
В качестве адреса локального репозитория ввести FQDN репозитория, используемого в качестве зеркала для внешнего репозитория;
Ввести ключ авторизации в локальном репозитории;
Ввести адрес внешнего репозитория;
Нажать кнопку Добавить.

Пример:

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

Для продолжения заполнения разделов нужно нажать Продолжить, по окончании заполнение разделов нажать Завершить.

Параметры sysctl

Для настройки нужно выполнить следующие действия (рисунок 143):

Рисунок 144 ‒ Параметры sysctl

раскрыть блок "Параметры sysctl";
указать список значений sysctl в формате "ключ-значение".

Пример:

apiVersion: node.shturval.tech/v1beta2
kind: NodeConfigItem
metadata:
name: sysctl
spec:
nodeconfigselector:
kubernetes.io/os: linux
sysctl:
file: /etc/sysctl.d/90-shturval.conf
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

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

Для настройки нужно выполнить следующие действия (рисунок 145):

Рисунок 145 ‒ Репозитории пакетов

Раскрыть блок "Репозитории пакетов". В этом разделе настраивается подключение сетевых репозиториев, которые работают по протоколам HTTP, HTTPS, FTP.
Выбрать целевое состояние репозитория: Present или Absent.
Ввести URL-адрес репозитория.
Ввести значение публичного ключа репозитория.
Ввести URL-адрес ключа репозитория пакетов для получения публичного ключа.
Включить проверку публичного ключа репозитория и использование SSL соединения для подключения к репозиторию – нажать кнопку Да.
Ввести описание репозитория.
Указать файл, в котором был найден репозиторий.

Пример:

apiVersion: node.shturval.tech/v1beta2
kind: NodeConfigItem
metadata:
finalizers:
‒ node.shturval.tech/finalizer
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

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

Для добавления пакетов для установки нужно выполнить следующие действия (рисунок 146):

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

Раскрыть блок "Пакеты для установки".
Ввести название пакета.
Выбрать целевое состояние пакета ‒ Present или Absent.
Ввести необходимую версию пакета.
Включить запрет обновления пакета или снятие запрета обновления перед установкой.
Ввести команды, которые должны быть запущены после установки пакета. При нажатии на + появится строка для ввода команды.
Определить, есть ли обязательное условие, что команды, запущенные после установки пакета, должны выполниться успешно.
Ввести команды, которые должны быть запущены перед установкой пакета. При нажатии на + появится строка для ввода команды.
Определить, есть ли обязательное условие, что команды, запущенные перед установкой пакета, должны выполниться успешно.

Пример:

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

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

Для добавления файла или директории выполнить следующие действия (рисунок 147):

Рисунок 147 ‒ Файлы и директории

Раскрыть блок "Файлы и директории".
Ввести путь к файлу или директории.
Выбрать тип ‒ "Файл" или "Директория".
Ввести значения прав доступа.
Указать владельца и группу.
Ввести содержимое файла, если выбран тип "Файл".
Ввести необходимую версию пакета.

Пример:

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

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

Следует обратить внимание, что при размещении AuditPolicy KubeAPI-сервер будет перезапущен автоматически. Перед размещением необходимо проверять валидность YAML-манифеста.

Чтобы настроить seccomp-профиль, следует воспользоваться инструкцией в п.Профиль Seccomp.

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

Для системных сертификатов Kubernetes нужно определить период ротации. Это должно быть целочисленное значение в пределах от 7 до 365, по умолчанию период ротации 30 дней (рисунок 148).

Рисунок 148 ‒ Системные сертификаты

Пример:

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

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

Для добавления доверенного сертификата нужно выполнить следующие действия (рисунок 149):

Рисунок 149 ‒ Доверенные сертификаты

Нажать Добавить доверенный сертификат.
Выбрать один из способов добавления сертификата ‒ "Из источника" или "Ручная загрузка".

Если выбрано "Из источника", загрузить файл сертификата и указать имя.
Если выбрано "Ручная загрузка", указать URL-адрес и имя сертификата. Можно указать URL с указанием протокола (доступен HTTPS) или без прямого указания протокола. Если протокол не указан, указать порт. Если протокол и порт не указаны, будет автоматически добавлен порт 443.

Выбрать статус сертификата ‒ Подтвержден или Не подтвержден.
Ввести имя сертификата.

Использование центрами сертификации корневого сертификата будет возможно, если статус сертификата "Подтвержден". Центры сертификации не смогут использовать корневой сертификат для подписания SSL-сертификатов, если статус корневого сертификата "Не подтвержден".

Пример:

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

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

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

Рисунок 150 ‒ Параметры загрузчика ядра

Для добавления загрузочных параметров ядра нужно выполнить следующие действия:

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

Пример:

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

Модули ядра

Для конфигурации модуля ядра нужно выполнить следующие действия (рисунок 151):

Нажать Добавить модуль ядра.
Задать имя модуля ядра. Это обязательное поле.
Задать имя файла с опциями.
Определить, заблокирован ли модуль ядра.
Определить, включена ли автозагрузка модуля ядра.

Рисунок 151 ‒ Модули ядра

Пример параметра ядра в загрузчике GRUB_DISABLE_RECOVERY:

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

Systemd-юниты

Для добавления настройки systemd-юнитов нужно выполнить следующие действия (рисунок 152):

Раскрыть блок "Systemd-юниты".
Включить запуск сервиса, в том числе при запуске ОС.
Ввести название "systemd unit".
Нажать кнопку Добавить.

Рисунок 152 ‒ Systemd-юниты

Пример:

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

Kubelet

В разделе "Kubelet" доступны следующие поля для заполнения (рисунок 153):

Рисунок 154 ‒ Kubelet

Политика управления CPU. Это поле представляет стратегию, применяемую kubelet для управления распределением ресурсов процессора для запущенных на узле контейнеров.

Например:

none ‒ должен распределять CPU по принципу совместного использования$ CPU может быть использован подами в соответствии с их ограничениями, без каких-либо гарантий привязки CPU.
static ‒ предоставлять уникальные CPU-ядра для подов.
Политика управления RAM. Это поле представляет стратегию, применяемую kubelet для управления распределением ресурсов памяти для запущенных на узле контейнеров.

Например:

none ‒ общий способ управления памятью.
static ‒ гарантирует строгое соответствие адресного пространства памяти.
Параметры управления 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. Включение этого параметра активирует автоматическую ротацию сертификатов для kubelett.

Доступные значения:

Да ‒ Включает ротацию сертификатов для kubelet.
Нет ‒ Отключает ротацию сертификатов для kubelet.
EnableProfilingHandler. При включении этого параметра, профилирование через хост host:port/debug/pprof/ становится доступным.

Доступные значения:

Да ‒ Включает профилирование через хост host:port/debug/pprof/.
Нет ‒ Отключает профилирование.
TLSMinVersion. Это поле определяет минимальную поддерживаемую версию протокола TLS.

Пример:

apiVersion: node.shturval.tech/v1beta2
kind: NodeConfigItem
metadata:
name: cpu-pinning
spec:
kubelet:
cpuManagerPolicy: static
featureGates:
CPUManager: true
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

Чтобы настроить CPU Pinning, следует воспользоваться Инструкцией "Резервирование CPU в кластере".

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

В этом разделе можно создать одного или нескольких пользователей. Нужно нажать + для добавления нового пользователя.

Доступны поля для заполнения (рисунок 155):

Рисунок 155 ‒ Пользователи

Ввести имя пользователя. Это обязательное поле. Здесь запрашивается имя пользователя для подключения к узлу по SSH.
Путь до домашней директории пользователя.
Shell. Определить путь до командной оболочки, например /bin/bash.
Группа. Ввести название локальной группы в Linux.
Добавить публичный SSH ключ пользователя. Поле появляется при нажатии на +. Можно добавить несколько ключей.

Пример:

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

Просмотр и изменение конфигурации узлов (NCI)

Созданные NCI отображаются в виде списка на странице "Конфигурация узлов" в разделе "Кластер → Администрирование".

Для просмотра нужно нажать на название NCI в списке.

Вкладка "NCI" содержит разделы, в которых есть пользовательские настройки и которые отображаются доступными для управления/просмотра. Незаполненные разделы отображаются отключенными. При необходимости изменения данных раздела необходимо нажать Управлять в блоке с названием раздела с переходом на страницу, содержащую сведения о разделах.

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

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

NCI можно изменить с помощью YAML-манифеста. Для этого нужно перейти на вкладку "Манифест" и внести изменения. После изменения манифеста следует выполнить проверку. Результат проверки будет доступен в правой части экрана. Далее необходимо раскрыть блок результата проверки, чтобы увидеть полный манифест. Если валидация формата манифеста NCI не пройдена, проверка манифеста будет недоступна.

Затем нужно сохранить изменения, внесенные в манифест. Несохраненные данные не будут применены.

На вкладке "Узлы" приведен перечень узлов кластера, для которых настроена конфигурация (NCI). Информация на вкладке позволяет убедиться в применении или возникновении ошибок применения NCI на запланированных узлах кластера. По нажатию на имя узла можно перейти на страницу просмотра узла.

Audit Policy

Audit Policy ‒ политика аудита событий в кластере Kubernetes, позволяющая гибко настроить, какие события необходимо отслеживать и на каком уровне. Audit Policy является ресурсом модуля аудита KubeAPI сервера.

Рекомендуемая политика автоматически монтируется при развертывании кластера с расширенными настройками безопасности.

Для удобства настройки политики аудита был разработан графический редактор политик аудита.

Ручная установка Audit Policy

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

Для создания или изменения ранее созданной политики аудита (Audit Policy) в клиентском кластере или кластере управления из интерфейса РОСА Кубис необходимо перейти в раздел "Администрирование → Конфигурация узлов".

Если ранее была создана Audit Policy с помощью объекта конфигурации узлов (NCI), можно отредактировать существующий манифест политики или создать новый объект NCI (рисунок 156).

Рисунок 157 ‒ Редактирование Audit Policy

Если Audit Policy не была установлена в кластер, необходимо создать новый объект конфигурации узлов. Следует обратить внимание, что, если ранее Audit Policy была размещена в конфигурации узлов, то новый объект конфигурации узлов (NCI) должен иметь приоритет выше ранее созданного.

В селекторе узлов из выпадающего списка требуется выбрать ключ лейбла node-role.kubernetes.io/control-plane. Значение для лейбла устанавливать не нужно.

Затем нужно выполнить следующие действия:

В блоке "Настраиваемые разделы" выбрать "Файлы и директории", нажать Управлять.
В открывшемся окне нажать +.
В типе файла/директории должно быть выбрано "Файл". В поле "Путь к файлу или директории" следует прописать /etc/kubernetes/audit_policy.yaml.
В поле "Содержимое файла" вставить содержимое YAML-файла политики, нажать Добавить. Затем нажать Завершить.

Master-узлы будут последовательно перезапущены.

Настройка API-сервера

Для настройки API-сервера нужно перейти в редактирование манифеста kube-apiserver: /etc/kubernetes/manifests/kube-apiserver.yaml.

Затем внести параметры в манифест согласно следующему коду:

spec:
containers:
‒ command:
‒ --audit-policy-file=/etc/kubernetes/audit_policy.yaml
‒ --audit-log-path=/var/log/kube-api-audit/audit.log
‒ --audit-log-maxage=30
‒ --audit-log-maxbackup=10
‒ --audit-log-maxsize=100
‒ --audit-log-mode=batch

В блоке volumeMounts необходимо смонтировать политику и логи:

volumeMounts:
‒ mountPath: /etc/kubernetes/audit_policy.yaml
name: audit-policy
‒ mountPath: /var/log/kube-api-audit/
name: audit-log
readOnly: false

В блоке volumes необходимо указать политику и логи:

volumes:
‒ hostPath:
path: /etc/kubernetes/audit_policy.yaml
type: File
name: audit-policy
‒ hostPath:
path: /var/log/kube-api-audit/
type: DirectoryOrCreate
name: audit-log

Пример манифеста Audit Policy для кластера управления

Audit Policy для кластера управления:

apiVersion: audit.k8s.io/v1
kind: Policy
omitStages:
‒ "RequestReceived"
‒ "ResponseStarted"
omitManagedFields: true
rules:
‒ level: Metadata
verbs: ["delete"]
resources:
‒ group: "controlplane.cluster.x-k8s.io"
resources: ["kubeadmcontrolplanes", "kubeadmcontrolplanetemplates"]
‒ level: Request
verbs: ["create", "update", "patch"]
resources:
‒ group: "controlplane.cluster.x-k8s.io"
resources: ["kubeadmcontrolplanes", "kubeadmcontrolplanetemplates"]
‒ level: Metadata
verbs: ["delete"]
resources:
‒ group: "infrastructure.cluster.x-k8s.io"
resources: ["basisclusters",
"basismachines",
"basismachinetemplates",
"basisproviders",
"ovirtclusters",
"ovirtmachines",
"ovirtmachinetemplates",
"ovirtproviders",
"vsphereclusteridentities",
"vsphereclusters",
"vsphereclustertemplates",
"vspheremachines",
"vspheremachinetemplates"]
‒ group: "ops.shturval.tech"
resources: ["shturvalserviceconfigs"]
‒ group: "node.shturval.tech"
resources: ["nodeconfigitems", "nodeconfigs"]
‒ level: Request
verbs: ["create", "update", "patch"]
resources:
‒ group: "infrastructure.cluster.x-k8s.io"
resources: ["basisclusters",
"basismachines",
"basismachinetemplates",
"basisproviders",
"ovirtclusters",
"ovirtmachines",
"ovirtmachinetemplates",
"ovirtproviders",
"vsphereclusteridentities",
"vsphereclusters",
"vsphereclustertemplates",
"vspheremachines",
"vspheremachinetemplates"]
‒ group: "cluster.x-k8s.io"
resources: ["clusterclasses",
"clusters",
"MachineDeployments",
"machinehealthchecks",
"machinepools",
"machines",
"machinesets"]
‒ level: Request
verbs: ["create", "delete", "update", "patch"]
resources:
‒ group: "rbac.authorization.k8s.io"
resources: ["roles", "clusterroles"]
‒ level: Request
verbs: ["create", "delete"]
resources:
‒ group: "rbac.authorization.k8s.io"
resources: ["clusterrolebindings", "rolebindings"]
‒ level: Request
verbs: ["create", "delete", "update", "patch"]
resources:
‒ group: "permissions.shturval.tech"
resources: ["grouproles", "userroles"]
‒ level: Metadata
verbs: ["create", "delete", "update", "patch", "get"]
resources:
‒ group: "
resources: ["secrets", "configmaps"]

Пример манифеста Audit Policy для клиентского кластера

Audit Policy для клиентского кластера:

apiVersion: audit.k8s.io/v1
kind: Policy
Собирать события только когда система сформировала ответ
omitStages:
‒ "RequestReceived"
‒ "ResponseStarted"
omitManagedFields: true
rules:
‒ level: Metadata
verbs: ["delete"]
resources:
‒ group: "
resources: ["deployments", "statefulsets", "daemonsets", "pods/log", "pods"]
‒ level: RequestResponse
verbs: ["create", "update", "patch"]
resources:
‒ group: "
resources: ["deployments", "statefulsets", "pods"]
‒ level: Request
resources:
‒ group: "
resources: ["pods/exec"]
verbs: ["create", "delete", "update", "patch", "get"]
‒ level: Request
verbs: ["create", "delete", "update", "patch"]
resources:
‒ group: "rbac.authorization.k8s.io"
resources: ["roles", "clusterroles"]
‒ level: Request
verbs: ["create", "delete"]
resources:
‒ group: "rbac.authorization.k8s.io"
resources: ["clusterrolebindings", "rolebindings"]
‒ level: Request
verbs: ["create", "delete", "update", "patch"]
resources:
‒ group: "permissions.shturval.tech"
resources: ["grouproles", "userroles"]
‒ level: Metadata
verbs: ["delete"]
resources:
‒ group: "cilium.io"
resources: ["ciliumnetworkpolicies"]
‒ group: "ops.shturval.tech"
resources: ["shturvalserviceconfigs"]
‒ group: "node.shturval.tech"
resources: ["nodeconfigitems", "nodeconfigs"]
‒ level: Request
verbs: ["create", "update", "patch"]
resources:
‒ group: "cilium.io"
resources: ["ciliumnetworkpolicies"]
‒ level: Metadata
verbs: ["create", "delete", "update", "patch"]
resources:
‒ group: "velero.io"
resources: ["backups", "restores"]
‒ level: Metadata
verbs: ["create", "delete", "update", "patch", "get"]
resources:
‒ group: "
resources: ["secrets", "configmaps"]

Аудит-логи

Если кластер развернут с расширенными настройками информационной безопасности и используются сервисы логирования Комплекса, в OpenSearch будет автоматически создан индекс с типом лога _kaudit для кластера, логи будут перенаправлены автоматически. На вкладке "События безопасности" дашборда кластера будут доступны аудит-логи за последний час (рисунок 158).

Рисунок 158 ‒ События безопасности

В РОСА Кубис по умолчанию используется log-backend, события аудита будут собраны с помощью Vector и перенаправлены в OpenSearch. Политика ротации логов в OpenSearch устанавливается по умолчанию.

Подробнее об индексах и просмотре логов см. в п. Просмотр логов.

Чтобы настроить дашборд по источникам запросов к API-серверу, следует использовать инструкцию в п. Добавление дашборда в Opensearch.

Управление узлами

На странице "Управление узлами" доступно управление группами узлов, конфигурацией групп узлов, а также управлением объектами healthchecks для групп узлов кластера.

На странице присутствуют две вкладки:

Группы узлов;
InfraMachineTemplates.

Группы узлов

Страница разделена на блоки (рисунок 159):

Control Plane, в которую входят Master-узлы;
Workers, в которую входят группы Worker-узлов.

Для группы Master-узлов и каждой группы Worker-узлов отображено:

количество узлов в группе;
количество работающих узлов в группе (узлы со статусом "Ready").

Рисунок 159 ‒ Группы узлов

В таблицах для ControlPlane и Workers можно настроить параметры отображения, для чего нажать на шестеренку в правом верхнем углу таблицы отображения узлов и выбрать необходимые параметры.

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

Конфигурация Control Plane

На странице "Управление узлами" клиентского кластера справа от названия группы ControlPlane узлов нужно нажать на кнопку Конфигурация группы. Количество узлов, параметры присоединения узла в группу, сайзинг узлов и machinehealthcheck доступны в конфигурации группы узлов. На открывшейся странице доступны вкладки:

Конфигурация машин;
InfraMachineTemplate;
MachineHealthCheck.

На вкладке "Конфигурация машин" имеется возможность указать параметры ClusterAPI, KubeadmControlPlane.

ClusterAPI

Название группы формируется по принципу: название кластера и постфикс "-control-plane" (рисунок 160):

Рисунок 160 ‒ ClusterAPI

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

Важно ‒ Не рекомендуется уменьшать количество Master-узлов в кластере управления. Это может привести к поломке кластера управления!

стратегия восстановления ‒ RollingUpdate, т.е. изменения в конфигурации будут применяться последовательно. Для стратегии требуется указать количество дополнительных узлов (MaxSurge). Указать можно в абсолютных (целое) или относительных (в %) значениях.
nodeDeletionTimeout ‒ определяет, как долго capi-controller-manager будет пытаться удалить узел, после того как ресурс Machine будет помечен на удаление. При значении** "0" **попытки удаления будут повторяться бесконечно. Если значение не указано, будет использовано значение по умолчанию (10 секунд) для этого свойства ресурса Machine.
nodeDrainTimeout ‒ общее количество времени, которое контроллер потратит на слив/освобождение узла. Значение по умолчанию равно 0, что означает: время ожидания освобождения узла не ограниченно по времени и может ожидать сколько угодно.

Примечание ‒ NodeDrainTimeout отличается от kubectl drain --timeout.

NodeVolumeDetachTimeout ‒ общее количество времени, которое контроллер потратит на ожидание отсоединения всех томов (volumes). Значение по умолчанию равно 0, это означает, что тома (volumes) будут ожидать отсоединения без какого-либо ограничения по времени и могут ожидать сколько угодно. По умолчанию для ресурса Machine установлено значение 10 секунд.

KubeadmControlPlane

Выбрать стратегию ремедиации, т.е. восстановления узла после идентификации его как неработоспособного. Позволяет детально настроить порядок восстановления для группы ControlPlane. Для управления доступны параметры:

Максимум попыток (maxRetry) ‒ максимальное количество повторных попыток при попытке исправления неисправной машины. Повторная попытка происходит, когда машина, созданная в качестве замены неисправной машины, также выходит из строя. Если не задано (по умолчанию), попытки исправления будут повторяться бесконечно.
Время попытки (retryPeriod) ‒ параметр ожидания времени, которое должно пройти перед началом новой попытки создания машины после неудачной попытки создания машины. По умолчанию не задано, что значит, что новая попытка будет произведена немедленно.
Минимальный период работоспособности (minHealthyPeriod) ‒ период времени, по прошествии которого считать, что машина работоспособна. Приводит к сбрасыванию счетчика количества восстановления машины. Если машина помечена как неработоспособная по истечении minHealthyPeriod (по умолчанию 1 ч) с момента предыдущего исправления, это больше не считается повторной попыткой, поскольку предполагается, что новая проблема не связана с предыдущей.

InfraMachineTemplate

На вкладке "InfraMachineTemplate" (рисунок 161) есть возможность изменить параметры шаблона инфраструктуры, применив новые значения вручную или скопировав значения из другого существующего шаблона. В зависимости от вида провайдера происходит редактирование/создание ресурса:

OvirtMachineTemplate;
VsphereMachineTemplate;
OpenStackMachineTemplate;
BasisMachineTemplate;
ShturvalMachineTemplate;
YandexMachineTemplate.

Для OVirtMachineTemplate доступны для конфигурации следующие параметры:

CPU:
cores;
sockets;
threads;
Объем RAM, МБ (sizemb);
Объем диска, ГБ (osdisksizegb)
nics:
vnicprofile;
Шаблон ВМ (template) ‒ доступны шаблоны ВМ экземпляра провайдера, на котором развернут кластер. Подробнее о создании шаблона ВМ см. в п. Создание шаблонов виртуальных машин.

Рисунок 161 ‒ InfraMachineTemplate

Для VSphereMachineTemplate (рисунок 162) доступны для конфигурации следующие параметры:

datacenter (выпадающий список всех дата-центров, доступных для сервисной учетной записи экземпляра провайдера);
datastore (выпадающий список всех Datastore, доступных для сервисной учетной записи экземпляра провайдера);
Объем диска, ГБ (diskGiB);
Объем RAM, МБ (memoryMiB);
Folder (путь до места создания ВМ);
Количество ядер (numCPUs);
Имя сети (networkName);
Ресурсный пул (resourcePool);
Шаблон ВМ (template) ‒ доступны шаблоны ВМ экземпляра провайдера, на котором развернут кластер. Подробнее о создании шаблона ВМ см. в п. Создание шаблонов виртуальных машин.

Рисунок 162 ‒ VSphereMachineTemplate

Для OpenStackMachineTemplate (рисунок 163) доступны для конфигурации параметры:

cloudName;
flavor (типы ВМ);
sshKeyName;
volumeType;
Объем диска, ГБ;
Шаблон ВМ (template) ‒ доступны шаблоны ВМ экземпляра провайдера, на котором развернут кластер. Подробнее о создании шаблона ВМ см. в п. Создание шаблонов виртуальных машин.

Параметр зоны доступности в OpenStackMachineTemplate доступен только для просмотра. Шаблон ВМ содержит зону доступности, если она была задана в конфигурации Master-узлов на этапе создания кластера.

Рисунок 163 ‒ OpenStackMachineTemplate

Для BasisMachineTemplate (рисунок 164) доступны параметры:

Количество ядер;
Объем RAM, МБ;
Объем диска, ГБ;
Ресурсная группа;
Имя VINS;
Имя ExtNet.

Рисунок 164 ‒ BasisMachineTemplate

Для ShturvalMachineTemplate (рисунок 165) доступны параметры конфигурации в базовом режиме и режиме расширенных настроек. По умолчанию включен базовый режим.

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

Рисунок 165 ‒ ShturvalMachineTemplate

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

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

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

Доступные операторы:

In ‒ будут выбраны хосты с совпадающим ключом и значением. Значение будет заполнено автоматически или предложено на выбор в соответствии с указанным ключом лейбла хоста; без возможности изменения;
NotIn ‒ не выбираются хосты с совпадающим ключом и значением. Значение будет заполнено автоматически или предложено на выбор в соответствии со значением указанного ключа лейбла; без возможности изменения;
Exists ‒ будут выбраны хосты с совпадающим ключом. Указывать значение не требуется;
DoesNotExist ‒ не выбираются хосты с совпадающим ключом. Указывать значение не требуется.

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

Важно:

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

Для YandexMachineTemplate (рисунок 166) доступны для конфигурации параметры:

Тип платформы;
Тип диска;
Объем RAM. Доступен выбор единицы измерения: Gi, Mi;
Объем диска. Доступен выбор единицы измерения: Gi, Mi;
cpuCores;
Шаблон ВМ (template) ‒ доступны шаблоны ВМ экземпляра провайдера, на котором развернут кластер. Подробнее о создании шаблона ВМ см. в п. Создание шаблонов виртуальных машин.

Рисунок 166 ‒ YandexMachineTemplate

MachineHealthCheck

Для Master-узлов на вкладке MachineHealthCheck можно (рисунок 167):

Рисунок 167 ‒ MachineHealthCheck

настроить разные конфигурации MachineHealthCheck для проверки работоспособности машин. При установке клиентского кластера по умолчанию монтируется MachineHealthCheck для групп Master-узлов. Для конфигурации дополнительных MachineHealthChecks нужно нажать + Добавить. Когда создано несколько конфигураций, на вкладке отображается список MachineHealthChecks.
перейти к просмотру и редактированию конфигурации MachineHealthCheck.

Чтобы настроить конфигурацию MachineHealthCheck:

нужно задать название MachineHealthCheck. После сохранения название нельзя изменить.
можно задать maxUnhealthy в %. Параметр определяет максимальный процент неработоспособных узлов в группе.

Следует обратить внимание, что MachineHealthCheck не будет восстанавливать узлы, если количество неработоспособных Master-узлов в группе больше, чем задано в maxUnhealthy.

Примеры:

Значение "maxUnhealthy" ‒ 90%:

В группе три Master-узла, где два узла неработоспособны. Следовательно, количество неработоспособных узлов = 66%, что меньше установленного значения "maxUnhealthy". В этом случае узлы будут восстановлены.

Значение "maxUnhealthy" ‒ 40%:

В группе три Master-узла, где два узла неработоспособны. Следовательно, количество неработоспособных узлов = 66%, что больше установленного значения "maxUnhealthy". В этом случае узлы не будут восстановлены.

можно задать "nodeStartupTimeout" ‒ время ожидания присоединения узла к кластеру. Слишком маленькое значение может привести к тому, что ВМ не хватит времени для создания и присоединения; попытки присоединить узел уйдут в цикл.

Пример:

Значение "nodeStartupTimeout" ‒ 10 мин. В этом случае, прежде чем считать узел неработоспособным, должно пройти 10 минут. Ожидается, что этого времени достаточно для присоединения узла к кластеру.

в блоке "Условия применения (unhealthyConditions)" настроить параметры проверки узлов, при соблюдении которых узел будет считаться неработоспособным:
1. выбрать "Тип" состояния узла. Доступные типы: NetworkUnavailable, DiskPressure, MemoryPressure, PIDPressure, Ready.
2. выбрать "Статус" состояния узла: True, False, Unknown.
3. задать Timeout ‒ время ожидания, по истечению которого статус узла будет считаться действительным. Рекомендуется не устанавливать слишком короткий период Timeout, чтобы не происходило ложного перезапуска, пока узел переходит в исправное состояние. Длительный период Timeout может привести к простоям рабочей нагрузки на неработоспособном узле.

Пример:

Условия применения:

Тип ‒ Ready;
Статус ‒ Unknown;
Timeout ‒ 5 мин;
Тип ‒ Ready;
Статус ‒ False;
Timeout ‒ 5 мин.

MachineHealthCheck сработает, если при проверке выявлено, что по истечении 5 минут наступит хотя бы одно из условий:

узел находится в состоянии Ready-Unknown;
узел будет в состоянии Ready-False.

После создания MachineHealthCheck будет добавлен в список проверок на вкладке "MachineHealthCheck".

Чтобы перейти к просмотру и редактированию, нужно нажать на строчку с названием MachineHealthCheck. В открывшемся окне можно изменить параметры "maxUnhealthy", "nodeStartupTimeout" и "Timeout" в условиях применения MachineHealthCheck.

По завершении внесения изменений необходимо нажать Сохранить.

Конфигурация группы Worker-узлов

На странице есть возможность добавить новую или изменить параметры конфигурации ранее созданных групп Worker-узлов. Название группы формируется по правилу: название клиентского кластера с добавлением запрашиваемого названия группы. Количество узлов, параметры присоединения узла в группу, сайзинг узлов и machinehealthcheck доступны в конфигурации группы узлов.

ClusterAPI

Для конфигурации ClusterAPI задаются следующие параметры:

Выбор способа масштабирования узлов в группе:
Ручное. При этом доступно директивное указание запрашиваемого количества узлов в группе: в поле "Запрошено реплик" указать желаемое количество узлов в группе (рисунок 168).

Рисунок 168 ‒ Ручное масштабирование

Автоматическое. При этом доступно указание диапазона узлов для группы: указать минимальное и максимальное количества узлов в группе. Количество узлов будет увеличиваться или уменьшаться в пределах заданного диапазона в зависимости от нагрузки (рисунок 169).

Рисунок 169 ‒ Автоматическое масштабирование

При автоматическом масштабировании минимальное количество узлов может быть 2. В графическом интерфейсе ограничена возможность задать менее 2-х реплик.

Примечания:

В случае необходимости выведения конкретного хоста с провайдером Shturval v2 из группы узлов следует воспользоваться Инструкцией "Как добавить и удалить хосты в кластер с провайдером Shturval v2".
В случае превышения лимита по количеству Worker-узлов согласно лицензии на всех страницах графического интерфейса отобразится уведомление с просьбой обратится к вендору для изменения пакета лицензии.

Тип восстановления:
OnDelete. При наличии изменений старые узлы удаляются и поднимаются новые.
RollingUpdate. При наличии изменений новые узлы создаются с последовательной заменой старых. Рекомендуемый вариант. При этом требуется указать максимальное количество недоступных и дополнительных узлов.
minReadySeconds ‒ минимальное количество секунд, в течение которых узел для созданной машины должен быть готов, прежде чем считать реплику доступной. По умолчанию ‒ 0 (машина будет считаться доступной, как только узел будет готов).
progressDeadlineSeconds ‒ максимальное время в секундах, необходимое для выполнения развертывания, прежде чем оно будет считаться неудавшимся. Контроллер развертывания продолжит обработку неудавшихся развертываний. В состоянии Cluster API будет отображено условие с причиной ProgressDeadlineExceeded. По умолчанию ‒ 600 с.
revisionHistoryLimit ‒ количество MachineSets, которые нужно сохранить для возможности отката. По умолчанию ‒ 1.
nodeDeletionTimeout ‒ определяет, как долго capi-controller-manager будет пытаться удалить узел, после того как ресурс Machine будет помечен на удаление. При значении 0 попытки удаления будут повторяться бесконечно. Если значение не указано, будет использовано значение по умолчанию (10 секунд) для этого свойства ресурса Machine.
nodeDrainTimeout ‒ общее количество времени, которое контроллер потратит на слив/освобождение узла. Значение по умолчанию равно 0, что означает, время ожидания освобождения узла не ограниченно по времени и может ожидать сколько угодно.

Примечание ‒ NodeDrainTimeout отличается от kubectl drain --timeout.

nodeVolumeDetachTimeout ‒ это общее количество времени, которое контроллер потратит на ожидание отсоединения всех томов (volumes). Значение по умолчанию равно 0 ‒ это означает, что тома (volumes) будут ожидать отсоединения без какого-либо ограничения по времени и могут ожидать сколько угодно. По умолчанию для ресурса Machine установлено значение 10 секунд.
Роли ‒ указать через запятую роли, которые будут назначены группе. Каждая назначенная роль будет прописана в после "/" лейбл узла node-role.kubernetes.io/.

InfraMachineTemplate

На вкладке "InfraMachineTemplate" есть возможность изменить параметры шаблона инфраструктуры, применив новые значения вручную или скопировав значения из другого существующего шаблона. В зависимости от вида провайдера происходит редактирование/создание ресурса:

OvirtMachineTemplate;
VsphereMachineTemplate;
OpenStackMachineTemplate;
BasisMachineTemplate;
ShturvalMachineTemplate;
YandexMachineTemplate.

Для OVirtMachineTemplate (рисунок 170) доступны для конфигурации параметры:

CPU:
- cores;
- sockets;
- threads;
Объем RAM, МБ (sizemb);
Объем диска, ГБ (osdisksizegb);
nics:
- vnicprofile;
Шаблон ВМ (template) ‒ доступны шаблоны ВМ экземпляра провайдера, на котором развернут кластер. Рекомендуется использовать шаблоны ВМ с одной ОС в рамках одного кластера. В случае использования шаблонов ВМ на разных ОС в рамках одного кластера могут возникать ошибки в процессе обновления кластера. Подробнее о создании шаблона ВМ см. в п. Создание шаблонов виртуальных машин.

Рисунок 170 ‒ OVirtMachineTemplate

Для VSphereMachineTemplate (рисунок 171) доступны для конфигурации параметры:

datacenter (выпадающий список всех дата-центров, доступных для сервисной учетной записи экземпляра провайдера);
datastore (выпадающий список всех Datastore, доступных для сервисной учетной записи экземпляра провайдера);
Объем диска, ГБ (diskGiB);
Объем RAM, МБ (memoryMiB);
Folder (путь до места создания ВМ);
Количество ядер (numCPUs);
Имя сети (networkName);
Ресурсный пул (resourcePool);
Шаблон ВМ (template) ‒ доступны шаблоны ВМ экземпляра провайдера, на котором развернут кластер. Рекомендуется использовать шаблоны ВМ с одной ОС в рамках одного кластера. В случае использования шаблонов ВМ на разных ОС в рамках одного кластера могут возникать ошибки в процессе обновления кластера. Подробнее о создании шаблона ВМ см. в п. Создание шаблонов виртуальных машин.

Рисунок 171 ‒ VSphereMachineTemplate

Для OpenStackMachineTemplate (рисунок 172) доступны для конфигурации параметры:

cloudName;
flavor (типы ВМ);
sshKeyName;
volumeType;
Объем диска, ГБ;
Шаблон ВМ (template) ‒ доступны шаблоны ВМ экземпляра провайдера, на котором развернут кластер. Рекомендуется использовать шаблоны ВМ с одной операционной системой в рамках одного кластера. В случае использования шаблонов ВМ на разных ОС в рамках одного кластера могут возникать ошибки в процессе обновления кластера. Подробнее о создании шаблона ВМ см. в п.Создание шаблонов виртуальных машин.

Параметр зоны доступности в OpenStackMachineTemplate доступен только для просмотра. Шаблон ВМ содержит зону доступности, если она была задана в конфигурации Worker-узлов на этапе создания кластера.

Рисунок 173 ‒ OpenStackMachineTemplate

Для BasisMachineTemplate (рисунок 174) доступны параметры:

Количество ядер;
Объем RAM, МБ;
Объем диска, ГБ;
Ресурсная группа;
Имя VINS;
Имя ExtNet.

Рисунок 174 ‒ BasisMachineTemplate

Для ShturvalMachineTemplate (рисунок 175) доступны параметры конфигурации в базовом режиме и режиме расширенных настроек. По умолчанию включен базовый режим.

Рисунок 175 ‒ ShturvalMachineTemplate

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

Доступные операторы:

In ‒ будут выбраны хосты с совпадающим ключом и значением. Значение будет заполнено автоматически или предложено на выбор в соответствии с указанным ключом лейбла хоста; без возможности изменения;
NotIn ‒ не выбираются хосты с совпадающим ключом и значением. Значение будет заполнено автоматически или предложено на выбор в соответствии со значением указанного ключа лейбла; без возможности изменения;
Exists ‒ будут выбраны хосты с совпадающим ключом. Указывать значение не требуется;
DoesNotExist ‒ не выбираются хосты с совпадающим ключом. Указывать значение не требуется;

При указании нескольких совпадающих выражений будут отображены доступные хосты, соответствующие всем выражениям (рисунок 176).

Рисунок 176 ‒ InfraMachineTemplate

Следует обратить внимание:

Изменение конфигурации InfraMachineTemplate в ранее созданной группе узлов приведет к пересозданию узлов.
Лейблы, указанные в селекторе в качестве совпадающих в одной группе узлов, должны быть указаны в совпадающих выражениях в качестве исключения в других группах по принципу:
ключ = выбранный в другой группе ключ лейбла;
оператор = NotIn;
значение = выбранное в другой группе значение лейбла.

Для YandexMachineTemplate доступны для конфигурации параметры:

Тип платформы;
Тип диска;
Объем RAM. Доступен выбор единицы измерения: Gi, Mi;
Объем диска. Доступен выбор единицы измерения: Gi, Mi;
cpuCores;
Шаблон ВМ (template) ‒ доступны шаблоны ВМ экземпляра провайдера, на котором развернут кластер. Подробнее о создании шаблона ВМ см. в п. Создание шаблонов виртуальных машин.

Рисунок 177 ‒ YandexMachineTemplate

MachineHealthCheck

На вкладке "MachineHealthCheck" (рисунок 178) можно:

Рисунок 178 ‒ MachineHealthCheck

настроить разные конфигурации MachineHealthCheck для проверки работоспособности машин. При установке клиентского кластера по умолчанию монтируется MachineHealthCheck для каждой группы Worker-узлов. Для конфигурации дополнительных MachineHealthChecks нужно нажать + Добавить. Когда создано несколько конфигураций, на вкладке отображается список MachineHealthChecks.
перейти к просмотру и редактированию конфигурации MachineHealthCheck.

Чтобы настроить конфигурацию MachineHealthCheck:

нужно задать название "MachineHealthCheck". После сохранения название нельзя изменить.
можно задать "maxUnhealthy" в %. Параметр определяет максимальный процент неработоспособных узлов в группе.

Следует обратить внимание, что MachineHealthCheck не будет восстанавливать узлы, если количество неработоспособных Worker-узлов в группе больше, чем задано в "maxUnhealthy".

Примеры:

Значение "maxUnhealthy" ‒ 90%:

В группе два Worker-узла, где один узел неработоспособен. Следовательно, количество неработоспособных узлов = 50%, что меньше установленного значения maxUnhealthy. В этом случае узел будет восстановлен.

Значение "maxUnhealthy" ‒ 40%:

В группе два Worker-узла, где один узел неработоспособен. Следовательно, количество неработоспособных узлов = 50%, что больше установленного значения "maxUnhealthy". В этом случае узел не будет восстановлен.

можно задать "nodeStartupTimeout" ‒ время ожидания присоединения узла к кластеру. Слишком маленькое значение может привести к тому, что ВМ не хватит времени для создания и присоединения; попытки присоединить узел уйдут в цикл.

Пример:

Значение "nodeStartupTimeout" ‒ 10 мин. В этом случае, прежде чем считать узел неработоспособным, должно пройти 10 минут. Ожидается, что этого времени достаточно для присоединения узла к кластеру.

в блоке "Условия применения (unhealthyConditions)" настроить параметры проверки узлов, при соблюдении которых узел будет считаться неработоспособным:
выбрать "Тип" состояния узла. Доступные типы: NetworkUnavailable, DiskPressure, MemoryPressure, PIDPressure, Ready.
выбрать "Статус" состояния узла: True, False, Unknown.
задать "Timeout" ‒ время ожидания, по истечению которого статус узла будет считаться действительным. Рекомендуется не устанавливать слишком короткий период Timeout, чтобы не происходило ложного перезапуска, пока узел переходит в исправное состояние. Длительный период Timeout может привести к простоям рабочей нагрузки на неработоспособном узле.

Пример:

Условия применения:

Тип ‒ Ready;
Статус ‒ Unknown;
Timeout ‒ 5 мин;
Тип ‒ Ready;
Статус ‒ False;
Timeout ‒ 5 мин.

MachineHealthCheck сработает, если при проверке выявлено, что по истечении 5 минут наступит хотя бы одно из условий:

узел находится в состоянии Ready-Unknown;
узел в состоянии Ready-False.

После создания MachineHealthCheck будет добавлен в список проверок на вкладке "MachineHealthCheck".

Чтобы перейти к просмотру и редактированию, нажать на строчку с названием MachineHealthCheck. В открывшемся окне можно изменить параметры "maxUnhealthy", "nodeStartupTimeout" и "Timeout" в условиях применения MachineHealthCheck.

По завершению внесения изменений необходимо нажать Сохранить.

Узел

Переход на страницу узла доступен по нажатию на имя узла в списке узлов на странице "Управление узлами".

Вкладка "Узел"

На вкладке доступно описание узла, состояние ClusterAPI, инфраструктуры и самого узла. Страница доступна для просмотра с момента запроса на добавление узла и позволяет отследить этапы создания узла (рисунок 179).

Рисунок 179 ‒ Вкладка "Узел"

Когда узел будет доступен, на странице отобразятся вычислительные ресурсы (рисунок 180). Если в клиентском кластере и кластере управления установлен и включен модуль графического отображения метрик, будет доступна кнопка для перехода на дашборд Grafana.

Рисунок 180 ‒ Состояние вычислительных ресурсов

Если в кластере настроен SR-IOV Network Operator и созданы виртуальные машины, то на вкладке "Сетевые интерфейсы" будет доступна информация:

Тип устройства (доступна фильтрация);
Идентификатор устройства (доступна фильтрация);
Имя драйвера (доступна фильтрация);
Имя интерфейса (доступна фильтрация);
Количество интерфейсов (доступна сортировка);
PCI address (доступна фильтрация);
Имя политики (доступна фильтрация). Нажатие на имя политики открывает страницу просмотра Sriov Network Policy.

Рисунок 181 ‒ Вкладка "Сетевые интерфейсы"

Вкладка "Поды"

Вкладка "Поды" (рисунок 182) представляет собой таблицу со списком подов выбранного узла, содержащую колонки:

Имя пода (доступна фильтрация). Нажатие на имя открывает страницу просмотра пода.
Дата создания (доступна сортировка).
Неймспейс (доступна фильтрация). Можно ввести значение для фильтрации подов по неймспейсам. Для отмены фильтрации по неймспейсам в фильтре нажать Отменить и далее Применить.
Статус (доступна фильтрация). Возможные значения для выбора в фильтре: Running, Pending, Terminating, CrashLoopBackOff, Completed, Failed, Unknown.

На вкладке "Поды" можно отследить перераспределение подов при Drain узла.

Рисунок 182 ‒ Вкладка "Поды"

Вкладка "События"

На вкладке "События" отображаются стандартные события Kubernetes для ClusterAPI, инфраструктуры и самого узла. На вкладке отображается индикация количества событий.

Вкладка "Лейблы и аннотации"

На вкладке "Лейблы и аннотации" (рисунок 183) при необходимости можно присвоить лейблы и аннотации для ClusterAPI, инфраструктуры и самого узла.

Рисунок 183 ‒ Вкладка "Лейблы и аннотации"

Вкладка "Конфигурация узла"

Вкладка "Конфигурация узла" (рисунок 184) отображает информацию ресурса Node Config и содержит перечень конфигураций узла (Node Config Item (NCI)) кластера, запланированных к применению на узле. В случае возникновения ошибки применения NCI на узле статус примет значение "Не применено". Также на вкладке доступна информация о статусе перезагрузки узла, когда:

требуется перезагрузка (reboot required);
перезагрузка запланирована (reboot scheduler);
перезагрузка разрешена (reboot allowed).

Рисунок 184 ‒ Вкладка "Конфигурация узла"

Для просмотра настроек конфигурации NCI нужно нажать на название NCI в перечне.

На вкладке "Taints" отображается перечень Taints (ограничения), запрещающих размещения подов на узле. При необходимости можно присвоить новый Taint узлу, изменить или удалить существующий.

Чтобы добавить Taint, необходимо нажать на + и в открывшемся окне (рисунок 185):

задать ключ для Taint (key);
при необходимости указать значение (value);
выбрать "Эффект" для ограничения размещения подов на узле (effect). Чтобы ни один под не был запланирован на узле без соответствующего Toleration (разрешения), выбрать "NoSchedule". Если не требуется строгое ограничение для размещения подов без соответствующего Toleration (разрешения), выбрать "PreferNoSchedule". При необходимости вытеснения уже запущенных подов на узле выбрать "NoExecute", в этом случае:
Поды без соответствующего Toleration немедленно вытесняются.
Поды с соответствующим Toleration остаются на узле навсегда.
Поды с соответствующим Toleration и заданным периодом разрешения (tolerationSeconds) остаются на узле в течение указанного времени, после чего вытесняются.

Рисунок 185 ‒ Добавление Taint

Если необходимо разместить под на узле с Taints, следует задать поду Toleration (разрешение), соответствующее конфигурации Taint.

Пример:

Заданный Taint на узле
spec:
taints:
‒ effect: NoSchedule
key: key1
value: value1
Toleration для размещения пода на узле с Taint
tolerations:
- key: "key1"
operator: "Equal"
value: "value1"
effect: "NoSchedule"

Следует обратить внимание, что, если узел имеет несколько Taints (ограничений), для размещения пода на узле необходимо задать Toleration, соответствующие каждому Taint.

Действия с узлами

Cordon

На странице узла доступна кнопка Cordon (рисунок 186), при нажатии на которую:

Рисунок 186 ‒ Кнопка Cordon

узел блокируется для распределения новых подов;
работа существующих на узле подов не прерывается;
узел, заблокированный для распределения новых подов, помечается в колонке "Scheduling" таблицы узлов на странице "Управление узлами" признаком "Disabled";
название кнопки подменяется на Uncordon, отменяющую действие.

Рисунок 187 ‒ Кнопка Uncordon

После нажатия на кнопку Uncordon признак снимается с узла и не отображается в таблице.

Drain

На странице узла доступна кнопка Drain, нажатие на которую открывает модальное окно с доступными настройками Drain узла (рисунок 188). По умолчанию все настройки отключены. Чтобы запустить Drain узла с настройками по умолчанию, нужно в окне настроек Drain узла нажать Запустить Drain (рисунок 189)

Рисунок 188 ‒ Кнопка Drain

При необходимости возможно задать следующие настройки Drain узла:

Рисунок 189 ‒ Настройки Drain узла

Принудительный запуск Drain узла. Приведет к немедленному завершению подов, игнорируя любые ошибки и предупреждения. Следует обратить внимание, что при принудительном запуске могут быть потеряны данные.
Игнорировать "daemonsets". Чтобы было проигнорировано завершение и перераспределение подов, подчиненных Daemonsets, выбрать Да.
Запретить перераспределение подов. При включении запрета поды не будут перераспределены, ресурс контролируемого завершения работы подов (Eviction) не будет запущен, настройки "PodDisruptionBudget" и "terminationGracePeriodSeconds" будут проигнорированы.
Пропустить ожидание удаления подов. Задать время в секундах, необходимое для ожидания удаления подов. Если период времени после установки DeletionTimestamp превысит заданное время, ожидание удаления будет пропущено. Значение 0 отключает настройку пропуска ожидания.
Игнорировать ошибки. При включении настройки будут проигнорированы ошибки, возникающие между узлами в группе.
Удалять ли поды, использующие EmptyDir. В случае удаления подов, данные EmptyDir также будут удалены.
Удалять ли поды, использующие PV. В случае удаления подов данные PV также будут удалены.
Период ожидания перераспределения подов. По истечению периода ожидания перераспределения подов Drain узла завершится. Значение 0 не ограничивает время ожидания перераспределения подов.
Селектор. Для определения скоупа применения настроек Drain узла можно задать совпадающие выражения, для чего нажать +, указать ключ, выбрать операцию сравнения ("=" и "==" соответствуют "равенству", "!=" соответствует "неравенству"), указать значение ключа.
Селектор подов. Можно добавить лейблы подов, к которым необходимо применить настройки Drain узла, нажав на +, задать ключ и, при необходимости, значение.

При запуске Drain:

узел блокируется для распределения новых подов узла (получает признак "Cordoned");
поды принудительно завершаются и перераспределяются на другие узлы. Все поды, кроме жизненно важных, принудительно завершаются и будут перераспределены на другие узлы кластера (если такие узлы есть);
узел, заблокированный для распределения подов, помечается в колонке "Scheduling" таблицы узлов на странице "Управление узлами" признаком "Disabled".
кнопка Cordon изменяется на Uncordon.

Отследить ход Drain узла можно на вкладке "Поды" узла (рисунок 190).

Рисунок 190 ‒ Вкладка "Поды"

После нажатия на кнопку Uncordon признак снимается с узла и не отображается в таблице.

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

Удаление узла

Для удаления узла на странице Worker-узла нужно нажать на кнопку Удалить узел. В открывшемся окне необходимо выбрать: удалить узел с последующим пересозданием или удалить узел без пересоздания (рисунок 191).

Рисунок 191 ‒ Удаление узла

Полное удаление узла доступно только при ручном масштабировании Worker-узлов. Выбор способа масштабирования находится на странице "Управление узлами → Конфигурация группы" (рисунок 192).

Рисунок 192 ‒ Полное удаление узла

Для узлов группы ControlPlane в интерфейсе можно:

удалить полностью Master-узел, если после удаления в кластере останется нечетное количество работающих Master-узлов (например, три или один). Наличие работающих узлов проверяется на момент запроса на удаление. В случае несоблюдения условия запрос на удаление будет недоступен (рисунок 193).

Рисунок 193 ‒ Полное удаление Master-узла

удалить Master-узел с пересозданием узла при условии, что в результате удаления узла в кластере должно остаться не менее двух работающих Master-узлов. Наличие двух работающих узлов проверяется на момент запроса на удаление. В случае несоблюдения условия запрос на удаление с пересозданием будет недоступен.

При отправке запроса на удаление Master-узла необходимо ввести названием узла в качестве подтверждения намерения.

В случае если узел по какой-либо причине выведен из строя и есть необходимость его оперативно удалить без ожидания завершения подов, отсоединения дисков и т.п., следует добавить такому узлу taint node.kubernetes.io/out-of-service=NoExecute. В этом случае при удалении Комплекс не будет ожидать стандартного завершения работы узла и в срочном порядке переподнимет поды на другом узле.

Исключение из автоскейлинга

Можно защитить узел от удаления в случае автоскейлинга. Для этого на странице узла необходимо нажать на кнопку Исключить из автомасштабирования. Опция доступна только для группы Worker-узлов с включенным автомасштабированием. Исключенные из автоскейлинга узлы будут отмечены на странице "Управление узлами" в колонке "Автомасштабирование" признаком "Запрещено".

Поведение системы при отказе/недоступности узла

В случае отказа/недоступности узла кластер начинает перераспределять нагрузку с этого узла на другие только спустя 30-60 секунд. Это связано с настройками мониторинга работоспособности узлов в kube-controller-manager, а также настройкой kubelet.

Kubelet периодически уведомляет Kube-APIserver о своем статусе с интервалом, заданным в параметре "--node-status-update-frequency". Значение по умолчанию ‒ 10 секунд.

Controller manager проверяет статус Kubelet каждые "--node-monitor-period". Значение по умолчанию ‒ 5 секунд.

Если Kubelet сообщит статус в пределах "--node-monitor-grace-period", то Controller manager считает, что узел исправен

В случае отказа узла кластера действия происходят по следующему алгоритму:

Kubelet отправляет свой статус Kube-APIserver в соответствии с параметром "--nodeStatusUpdateFrequency" равным 10 сек.
При допустимом выходе узла из строя Controller manager будет пытаться проверить статус узла (от Kubelet) каждые 5 сек (согласно параметру "--node-monitor-period").
Controller manager определит, что узел не отвечает, и даст ему тайм-аут "–node-monitor-grace-period" в 40 сек. Если за это время Controller manager не сочтет узел исправным, он установит статус NotReady.

В этом сценарии будут возможны ошибки при обращении к подам, работающим на этом узле, потому что модули будут продолжать получать трафик до тех пор, пока узел не будет считаться неработающим (NotReady) через 45 сек.

Чтобы увеличить скорость реакции Комплекса на отказ узлов кластера, можно изменить параметры:

--nodeStatusUpdateFrequency (по умолчанию ‒ 10 сек) в конфигурационном файле Kubelet /var/lib/kubelet/config.yaml;
--node-monitor-period (по умолчанию ‒ 5 сек )
--node-monitor-grace-period (по умолчанию ‒ 40 сек)

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

Подробнее см. в официальной документации Kubernetes.

InfraMachineTemplates

При изменении инфраструктурного шаблона в конфигурации группы узлов кластера происходит создание нового инфраструктурного шаблона. Все инфраструктурные шаблоны для этого кластера доступны на вкладке "InfraMachineTemplates" страницы "Управление узлами" (рисунок 194). Доступно удаление шаблонов, не привязанных к группам узлов.

Рисунок 194 ‒ Вкладка "InfraMachineTemplates"

Cluster Issuers

Cluster Issuers ‒ ресурсы РОСА Кубис, представляющие центры сертификации в кластере, которые могут генерировать подлинные сертификаты, выполняя запросы на подпись сертификатов.

На странице "ClusterIssuers" можно создать, отредактировать, удалить или просмотреть ранее созданные менеджеры сертификатов (ClusterIssuers).

Чтобы добавить менеджер сертификатов, нужно нажать на кнопку + Добавить ClusterIssuers.

В открывшемся окне необходимо заполнить:

Имя;
Спецификацию объекта. Из выпадающего списка выбрать тип. На текущий момент доступны "ACME" и "Vault". При необходимости задать лейблы.

Просмотр и изменение Cluster Issuers

Созданные Cluster Issuers отображаются в виде списка на странице "ClusterIssuers" в разделе "Администрирование" кластера.

Для просмотра нужно нажать на название Cluster Issuer в списке.

При необходимости изменения Cluster Issuer следует обновить сведения спецификации объекта и нажать Сохранить.

Также Cluster Issuer можно изменить с помощью YAML-манифеста. перейдя на вкладку "Манифест". После изменения манифеста требуется выполнить проверку. Результат проверки будет доступен в правой части экрана. Далее нужно раскрыть блок результата проверки, чтобы увидеть полный манифест. Если валидация формата манифеста Cluster Issuer не пройдена, недоступна и проверка манифеста.

Далее необходимо сохранить изменения, внесенные в манифест. Несохраненные данные не будут применены.

Настройка ACME

Для настройки необходима учетная запись в ACME (Automated Certificate Management Environment) и выполнение следующих действий:

Заполнить сведения о сервере ACME, например https://acme-v02.api.letsencrypt.org/directory.
Ввести "email", который связан с учетной записью ACME.
Определить, нужно ли пропускать проверку TLS.

Важно ‒ Если пропустить проверку TLS, то запросы к серверу ACME не будут подтверждены сертификатом TLS (т.е будут разрешены небезопасные соединения). Следует включать этот параметр только в средах разработки.

При установлении защищенного TLS-соединения можно указать в поле "CA Bundle" пакет сертификатов центра сертификации. CA Bundle содержит корневой сертификат и промежуточный в формате PEM для проверки подлинности и доверия сертификату сервера ACME. Следует обратить внимание, что данные файла CA Bundle должны содержать ----BEGIN CERTIFICATE---- и ----END CERTIFICATE----. Если CABundle не указан, но проверка TLS-соединения устанавливается, то для проверки соединения используется пакет системных сертификатов внутри контейнера.
В части "Ключ учетной записи ACME" необходимо ввести имя и ключ Secret.
Обозначить solvers ‒ выбрать тип солвера ‒ "HTTP01" или "DNS01".
Для "HTTP01" заполнить поле "ClassIngress" и нажать кнопку Добавить. Может быть использован, если:

провайдер не блокирует порт 80;
Ingress-контроллер доступен из интернета по порту 80;
не используются сертификаты с подстановкой (wildcard-сертификаты).

Ввести класс Ingress (ClassIngress), который должен быть использован для решения Challenge от Let’s Encrypt.
Посмотреть, какие ClassIngress есть в кластере:

kubectl get ingressclass -A

Если не указать ClassIngress, будет использован класс по умолчанию.

Для DNS01/acmeDNS заполнить значение хоста. В AccountSecretRef вписать имя и ключ, затем нажать кнопку Добавить. Может быть использован, если:

используется сертификаты с подстановкой (wildcard-сертификаты);
есть несколько web-серверов.

Пример:

apiVersion: cert-manager.io/v1
kind: Issuer
metadata:
name: example-issuer
spec:
acme:
solvers:
‒ dns01:
acmeDNS:
host: https://acme.example.com
accountSecretRef:
name: acme-dns
key: acmedns.json

Для DNS01/rfc2136 заполнить значение "Nameserver" и "TsigAlgorithm". В "TsigSecretSecretRef" вписать имя и ключ, затем нажать кнопку Добавить. Может быть использован, если есть:

Сервер DNS, настроенный с поддержкой протокола RFC2136;
Доступ к данным (ключи TSIG) для авторизации обновлений DNS.

Пример:

rfc2136:
nameserver: 1.2.3.4:53
tsigKeyName: example-com-secret
tsigAlgorithm: HMACSHA512
tsigSecretSecretRef:
name: tsig-secret
key: tsig-secret-key
где:

tsigKeyName ‒ имя ключа TSIG-аутентификации (например, example-key).
tsigAlgorithm ‒ алгоритм, используемый для создания ключа TSIG (например, hmac-md5).
tsigSecretSecretRef.name ‒ секрет, содержащий секретный ключ для TSIG-аутентификации.

Для DNS01/webhook заполнить данные Cert-Manager, подставляя в поля значение "GroupName", "SolverName" и "Config", затем нажать кнопку Добавить.

Пример:

apiVersion: cert-manager.io/v1
kind: Issuer
metadata:
name: example-issuer
spec:
acme:
...
solvers:
‒ dns01:
webhook:
groupName: $WEBHOOK_GROUP_NAME
solverName: $WEBHOOK_SOLVER_NAME
config:
...
<webhook-specific-configuration>

См. подробнее о настройке TLS в п. Настройка TLS.

Настройка Vault

Для настройки необходима учетная запись в vault. Согласно официальной документации Cert Manager рекомендуемый способ интеграции для текущей версии ‒ ServiceAccountRef.

Для настройки выполняются следующие действия:

для интеграции выбрать "ServiceAccount" из выпадающего списка.
ServiceAccount должен быть создан в неймспейсе cert-manager и иметь роль vault-issuer.

Права для роли vault-issuer:

rules:
‒ apiGroups: ['']
resources: ['serviceaccounts/token']
resourceNames: ['vault-issuer']
verbs: ['create']

После выбора ServiceAccount в поле "mountPath" заполнить путь монтирования "Vault" для использования при аутентификации в Vault, например /v1/auth/kubernetes.
В поле "Роль" прописать роль пользователя на стороне Vault, например my-app-1.
В поле "Path" прописать путь к монтируемому пути конечной точки подписи PKI-backend Vault, например my_pki_mount/sign/my-role-name.
В поле "Сервер" прописать адрес подключения к серверу Vault, например https://vault.local.
С целью проверки подлинности и доверия сертификатам сервера Vault, можно указать "CA Bundle", содержащий корневой и промежуточный сертификаты в формате PEM. Доступно два способа включения CA Bundle в Cluster Issuers:

Выбрать "Файл" в блоке "CA Bundle", чтобы ввести данные файла CA Bundle. Следует обратить внимание, что данные файла CA Bundle должны содержать ----BEGIN CERTIFICATE---- и ----END CERTIFICATE----.
Выбрать "Ключ к CA Bundle" в блоке "CA Bundle", чтобы загрузить CA Bundle с указанием ссылки на Secret в вашем кластере. Выбрать Secret, который содержит CA Bundle, и указать ключ доступа к нему.

Если CABundle не указан в Cluster Issuer, пакет сертификатов cert-manager используется для проверки TLS-соединения.

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

Чтобы удалить элемент, можно нажать в строке элемента.

Сетевые политики Cilium

Страница "Сетевые политики Cilium" содержит две вкладки: кластерные (ClusterwideCiliumNetworkPolicy) и неймспейсные (CiliumNetworkPolicy) сетевые политики.

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

Созданную сетевую политику можно изменить в графическом редакторе или с помощью YAML-манифеста, перейдя на вкладку "Манифест" и внеся изменения. После изменения манифеста нужно нажать Применить, и в правой части экрана отобразится результат проверки. Далее следует раскрыть блок результата проверки, чтобы увидеть полный манифест.

Затем необходимо сохранить изменения, внесенные в манифест. Несохраненные данные не будут применены.

Кластерные сетевые политики

При добавлении кластерных сетевых политик есть два уровня компонентов (рисунок 195):

вне кластера;
внутри кластера.

Рисунок 195 ‒ Кластерные сетевые политики

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

Неймспейсные сетевые политики

При добавлении неймспейсной сетевой политики есть три уровня компонентов (рисунок 196):

вне кластера;
внутри кластера;
внутри неймспейса.

Рисунок 196 ‒ Неймспейсные сетевые политики

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

Правила сетевых политик

Для каждого компонента можно настроить правило взаимодействия с неймспейсом. Входящие потоки в конфигурируемый неймспейс регламентируются правилами Ingress, исходящие ‒ правилами Egress. Для создания правила нужно нажать на + в блоке компонента и выбрать параметры. Добавленные правила будут отображаться в нижней части блока компонента. Для удаления правила следует нажать на правило, затем на значок корзины в открывшемся окне. От каждого созданного правила отображается связь до конфигурируемого неймспейса.

Правила могут быть:

запрещающими (запрещает обращение одного объекта к другому по указанному порту);
разрешающими (разрешает обращение одного объекта к другому по указанному порту);
отключенными (правило неактивно, не выполняет разрешения или запреты).

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

Ingress-правила (Входящий трафик)

Вне кластера можно определить правила входящего в неймспейс кластера трафика:

Из любого endpoint. При установлении запрещающего правила трафик из любых endpoints вне кластера к указанным портам объектов в конфигурируемом неймспейсе будет отбрасываться.
Из CIDR. При установлении правила исключения для CIDR трафик из этого CIDR вне кластера будет отбрасываться.

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

разрешить входящий трафик с любых endpoints;
разрешить входящий трафик с любых endpoints, но только к определенному порту(-ам) (например, к порту 80);
разрешить входящий трафик с определенного CIDR;
разрешить входящий трафик с определенного CIDR, но только к определенному порту(-ам) (например, к порту 80).

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

Если подам конфигурируемого неймспейса требуется получать входящий трафик от других подов в кластере, следует рассмотреть один из следующих вариантов:

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

Типы правил:

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

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

Типы правил:

из любого пода;
из некоторых подов.

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

разрешить входящий трафик любым подам;
разрешить входящий трафик любым подам, но только к определенному порту(-ам) (например, к порту 80);
разрешить входящий трафик некоторым подам;
разрешить входящий трафик некоторым подам, но только к определенному порту(-ам) (например, к порту 80).
разрешить входящий трафик только к любому поду конфигурируемого неймспейса с любых endpoints.

Egress-правила (Исходящий трафик)

Вне кластера исходящий трафик к любому endpoint вне кластера будет запрещен, если его не разрешают другие правила.

Если поды в конфигурируемом неймспейсе должны иметь возможность передавать трафик в endpoints за пределами кластера, следует рассмотреть одну из следующих опций:

разрешить трафик к конкретным CIDR;
разрешить трафик к конкретным FQDN;
разрешить трафик к любому endpoint вне кластера.

Типы правил:

к любому endpoint;
до CIDR;
до FQDN.

Чтобы разрешить трафик до FQDN, должен быть разрешен трафик до Kubernetes DNS. Без соблюдения этого условия правило добавить можно, но оно не будет работать. Такая связь будет отображаться серым цветом. DNS proxy будет включен, когда будет разрешен трафик до Kubernetes DNS.

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

Если необходимо отправлять исходящий трафик к другим подам в других неймспейсах внутри кластера, следует рассмотреть один из следующих вариантов:

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

Типы правил:

ко всем ресурсам кластера (по умолчанию);
Kubernetes DNS (если разрешена, разрешает потоки Egress в Kubernetes DNS; если запрещена, текущая политика не допускает передачу трафика на DNS Kubernetes. В результате запросы DNS от подов конфигурируемого неймспейса будут игнорироваться внутри кластера, если не будет разрешено другими правилами). Когда Kubernetes DNS разрешен, DNS proxy включен по умолчанию. Когда отключен, нельзя будет включить DNS proxy.
к некоторым неймспейсам;
к некоторым подам;
к сервисам;
к хостам (выбирает локальный хост и все контейнеры, запущенные на этом хосте);
к удаленным узлам (любой узел в любом из подключенных кластеров, кроме локального хоста; также выбирает все контейнеры, работающие в режиме сети хоста на удаленных узлах).

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

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

Типы правил:

к любому поду;
к сервисам;
к некоторым подам.

Примеры сетевых политик

Доступ к KubeAPI-серверу allow-kube-apiserver:

apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
name: allow-kube-apiserver
namespace: yournamespacename
spec:
description: "For endpoints in this namespace, allow egress to kube-apiserver"
endpointSelector: {}
egress:
‒ toEntities:
‒ kube-apiserver

Запрещающая политика deny-all (рисунок 197):

apiVersion: "cilium.io/v2"
kind: CiliumNetworkPolicy
metadata:
name: deny-all
namespace: yournamespacename
spec:
description: "Deny all traffic in this namespace"
endpointSelector: {}
ingress:
‒ {}
egress:
‒ {}

Рисунок 197 ‒ Запрещающая политика deny-all

Исходящий трафик к KubeDNS и NodeLocalDNS allow-dns:

apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
name: allow-dns
namespace: yournamespacename
spec:
description: "For endpoints in this namespace, allow egress to kube-dns and shturval-caching-dns"
endpointSelector: {}
egress:
‒ toEndpoints:
‒ matchLabels:
io.kubernetes.pod.namespace: kube-system
k8s-app: kube-dns
toPorts:
‒ ports:
‒ port: "53"
protocol: UDP
‒ port: "53"
protocol: TCP
‒ port: "9153"
protocol: TCP
‒ toEndpoints:
‒ matchLabels:
io.kubernetes.pod.namespace: kube-system
app.kubernetes.io/name: shturval-caching-dns
toPorts:
‒ ports:
‒ port: "53"
protocol: UDP
‒ port: "9253"
protocol: TCP

Исходящий трафик к определенному приложению allow-egress (рисунок 198):

apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
name: allow-egress
namespace: yournamespacename
spec:
description: "For endpoints in this namespace, allow to target app"
endpointSelector: {}
egress:
‒ toEndpoints:
‒ matchLabels:
io.kubernetes.pod.namespace: <TARGET NAMESPACE>
app.kubernetes.io/name: <TARGET APP NAME>
toPorts:
‒ ports:
‒ port: "<TARGET APP PORT>"
protocol: <TARGET APP PORT PROTOCOL(TCP/UDP)>

Рисунок 198 ‒ Исходящий трафик к определенному приложению allow-egress

Входящий трафик из Ingress-контроллера allow-ingress (рисунок 199):

apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
name: allow-ingress
namespace: yournamespacename
spec:
description: "For endpoints in this namespace, allow ingress from ingress-controller"
endpointSelector: {}
ingress:
‒ fromEndpoints:
‒ matchLabels:
app.kubernetes.io/name: shturval-ingress-controller
io.kubernetes.pod.namespace: ingress

Рисунок 199 ‒ Входящий трафик из Ingress-контроллера allow-ingress

Трафик внутри неймспейса allow-in-namespace (рисунок 200):

apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
name: allow-in-namespace
namespace: yournamespacename
spec:
description: "For endpoints in this namespace, allow all in this namespace"
endpointSelector: {}
ingress:
‒ fromEndpoints:
‒ {}
egress:
‒ toEndpoints:
‒ {}

Рисунок 200 ‒ Трафик внутри неймспейса allow-in-namespace

Persistent Volumes

Страница "Persistent Volumes" (рисунок 201) содержит список постоянных томов. В текущей реализации графический интерфейс РОСА Кубис не позволяет создавать вручную постоянные тома. PV создаются с помощью PVC и не могут быть изменены после создания.

Рисунок 201 ‒ Страница "Persistent Volumes"

На странице "Persistent Volume (PV)" (рисунок 202) можно просмотреть спецификацию, с которой создан постоянный том, а также какой PersistentVolumeClaim создал этот объект.

Рисунок 202 ‒ Просмотр спецификации

Если администратор удаляет PV, который связан с PVC, PV не удаляется немедленно. Удаление PV откладывается до тех пор, пока PV не перестанет быть связан с PVC.

Storage Classes

Страница "StorageClasses" содержит список классов хранилища.

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

Создание StorageClass

Чтобы добавить StorageClass, нужно нажать на кнопку + Добавить StorageClass.

Каждый StorageClass содержит поля provisioner, parameters, reclaimPolicy, volumeBindingMode, которые используются, если необходимо динамически выделить PersistentVolume, принадлежащий классу, для удовлетворения запроса PersistentVolumeClaim (PVC).

При конфигурировании StorageClass (рисунок 203):

требуется задать имя StorageClass;
возможно добавить лейблы и аннотации;
необходимо выбрать тип провижинера (Provisioner Type). В графическом интерфейсе понятие типа провижинера введено для упрощения конфигурации StorageClass. Доступные типы: oVirt, vSphere, NFS, Rawfile, CephFS, CephRBD, Иной.
значение провижинера (Provisioner) будет задано автоматически для всех типов (кроме типа "Иной"):
- vSphere ‒ csi.vsphere.vmware.com;
- NFS ‒ nfs.csi.k8s.io;
- oVirt ‒ csi.ovirt.org;
- Rawfile ‒ rawfile.csi.openebs.io;
- CephFS ‒ cephfs.csi.ceph.com;
- CephRBD ‒ bd.csi.ceph.com.
возможно выбрать политику возврата PersistentVolume (PV) создаваемого StorageClass; выбрать "Retain", если необходимо вручную управлять данными PV в случае удаления PVC; указать "Delete", чтобы после удаления PVC соответствующий PV также был удален. По умолчанию ‒ Delete;
возможно выбрать режим привязки PV. Если необходимо предоставлять PV сразу после создания PVC, выбрать режим "Immediate". Если требуется предоставление PV только после создания пода, использующего PVC, задать режим "WaitForFirstConsumer". По умолчанию ‒ Immediate.
возможно управлять набором параметров StorageClass.

Рисунок 203 ‒ Конфигурирование StorageClass

Можно установить типы провижинеров, совместимые с Kubernetes. По умолчанию в РОСА Кубис доступны следующие типы провижинеров:

СephFS Provisioner;
CephRBD Provisioner;
OpenEBS Rawfile Provisioner;
oVirt Provisioner;
vSphere Provisioner;
NFS Provisioner.

Настройка параметров

Чтобы добавить параметр для провижинеров СephFS, CephRBD, OpenEBS Rawfile или при выборе типа иного провижинера, нужно нажать на + в блоке "Параметры". В открывшемся окне следует задать имя параметра, его значение и нажать Добавить (рисунок 204).

Рисунок 204 ‒ Настройка параметров

Для настройки NFS, vSphere, oVirt по умолчанию предложены параметры:

для NFS (рисунок 205);

Рисунок 205 ‒ Параметры для NFS

Допустимые значения для параметра "onDelete": delete, retain, archive.

По умолчанию в параметре mountPermissions установлено значение 0. При необходимости назначения разрешений для файлов и папок следует изменить значение.

для oVirt (рисунок 206);

Рисунок 206 ‒ Параметры для oVirt

Для параметра выделения пространства хранения не сразу при создании диска, а по мере возникновения в нем потребности, "thinProvisioning" допустимые значения: true, false.

Для параметра типа файловой системы ovirtFstype допустимые значения: ext4, xfs.

для vSphere (рисунок 207).

Рисунок 207 ‒ Параметры для vSphere

Для параметра типа файловой системы vsphereFstype допустимые значения: ext4, xfs.

Чтобы задать значение для параметра, нужно нажать на строку выбранного параметра и в открывшемся окне внести данные в поле "Значение", затем нажать Изменить (рисунок 208).

Рисунок 208 ‒ Значение для параметра

Если набор параметров не подходит, можно:

добавить новый параметр (рисунок 209). Нажать на + в блоке "Параметры", в открывшемся окне задать имя параметра, его значение. Нажать Добавить;

Рисунок 209 ‒ Добавление нового параметра

изменить существующий параметр (рисунок 210). Нажать на строку с названием интересующего параметра и внести изменения, нажав Изменить;

Рисунок 210 ‒ Изменение существующего параметра

удалить существующий параметр (рисунок 211). Нажать на строку с названием интересующего параметра нажать на пиктограмму ;

Рисунок 211 ‒ Удаление существующего параметра

выбрать тип провижинера "Иной" и сконфигурировать требуемые параметры (рисунок 212).

Рисунок 212 ‒ Конфигурирование параметра

Просмотр и изменение StorageClass

На странице созданного StorageClass есть возможность:

просмотреть данные класса хранилища на вкладке "StorageClass" (рисунок 213);
увидеть список PersistentVolumes, использующих этот класс хранилища на вкладке "PersistentVolumes". По нажатию на строку с названием PersistentVolume можно перейти на страницу просмотра PersistentVolume;
скорректировать перечень лейблов и аннотаций на вкладке "Лейблы и аннотации";
просмотреть манифест StorageClass, а также скорректировать перечень лейблов и аннотаций в манифесте StorageClass.

Рисунок 213 ‒ Просмотр StorageClass

Чтобы скорректировать перечень лейблов и аннотаций в манифесте StorageClass, нужно перейти на вкладку "Манифест" и внести изменения. После изменения манифеста необходимо нажать Применить. В правой части экрана отобразится результат проверки. Можно раскрыть блок результата проверки, чтобы увидеть полный манифест.

Далее следует сохранить изменения, внесенные в манифест. Несохраненные изменения не будут применены.

Кастомные ресурсы

CRD (Custom Resource Definition) ‒ специальный ресурс, который позволяет создавать новые типы ресурсов для расширения функционала (рисунок 214).

Рисунок 214 ‒ Кастомные ресурсы

Страница "Кастомные ресурсы" отображает список всех CRD: кубовых и созданных в кластере. CRD сгруппированы по API-группам. По умолчанию ресурсы отсортированы по алфавиту. Есть переключатель, позволяющий скрыть CRD, в которых нет кастомных ресурсов (Custom Resource). В списке для удобства отображено количество созданных кастомных ресурсов каждого CRD.

По нажатию на название CRD можно перейти на страницу со списком кастомных ресурсов этой CRD. На странице просмотра кастомного ресурса возможно внести изменения в манифест, а также скопировать его.

При необходимости изменения кастомного ресурса с помощью YAML-манифеста можно перейти на страницу кастомного ресурса и скорректировать данные манифеста (рисунок 215). После изменения манифеста необходимо выполнить проверку. Результат проверки будет доступен в правой части экрана. Можно раскрыть блок результата проверки, чтобы увидеть полный манифест. Если валидация формата манифеста кастомного ресурса не пройдена, будет недоступна проверка манифеста.

Рисунок 215 ‒ Изменение манифеста кастомного ресурса

Далее следует сохранить внесенные изменения в манифест кастомного ресурса. Изменения не применятся без сохранения.