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

Известные проблемы в кластере

В развернутом кластере управления и/или клиентском кластере с версией Kubernetes 1.34.x в логах KubeAPI-сервера примерно каждые 10-15 секунд выводятся предупреждения (Warning) (рисунок 189):

W0209 08:34:25.656062       1 logging.go:55] [core] [Channel #621110 SubChannel #621111]grpc:
addrConn.createTransport failed to connect to {Addr: "127.0.0.1:2379", ServerName: "127.0.0.1:2379",
BalancerAttributes: {"<%!p(pickfirstleaf.managedByPickfirstKeyType={})>": "<%!p(bool=true)>" }}. Err:
connection error: desc = "transport: Error while dialing: dial tcp 127.0.0.1:2379: operation was canceled"

Следует обратить внимание, что ошибка не влияет на работу кластера и KubeAPI-сервера.

Рисунок 189 ‒ Предупреждения

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

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

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

В верхней части отображается название кластера. Доступна только вкладка "Кластер".

В левой верхней части вкладки "Кластер" отображается блок "Статус развертывания кластера", на котором по мере развертывания кластера можно отследить готовность инфраструктуры, состояния (conditions) Control Plane-узлов и Worker-узлов, установку сервисов и применение NCI на узлы кластера.

Общая информация о статусной модели развертывания кластеров на странице приведена в п. Статус развертывания кластера.

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

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

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

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

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

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

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

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

• Кнопка Статистика отображается, если установлены и включены сервисы:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Блок "Алертинг" содержит сведения о сработавших алертах в разрезе по уровню важности оповещения.

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

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

Приостановка реконсиляции инфраструктуры

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Вкладка "Логи"

Если в кластере включен сервис локального сбора логов "Vector" (shturval-log-collector) и в кластере управления работает "Компонент управления модуля мониторинга (Victoria Metrics Agent)" (shturval-metrics-collector), то на вкладке "Логи" отображаются собранные логи.

Рисунок 201 ‒ Вкладка "Логи"

Изображение215

В сервисе VLogs под логи создаются соответствующие проекты (ProjectID). В интерфейсе Комплекса доступна фильтрация по ProjectID:

• kube system namespaces ‒ системные логи /var/log/containers/*.log;
• cluster namespace ‒ логи нагрузок неймспейса кластера в кластере управления;
• kube events ‒ логи событий всех объектов кластера;
• kube audit ‒ логи событий безопасности кластера;
• journald ‒ логи shturvald (containerd);
• auditd ‒ системные логи аудита.

Логи в проектах сгруппированы по стримам (stream), которые представляет собой перечень логов с уникальным набором параметров. Параметр состоит из пары "поле:значение" лога. Наименование стрима соответствует значению поля _stream. В интерфейсе доступны счетчики по количеству логов и стримов в проекте.

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

На вкладке "Логи" (рисунок 202) есть возможность:

• Получить сведения по логам:
  • за последние 15 минут;
  • за последние 30 минут;
  • за последний час (выбрано по умолчанию);
  • за весь день;
  • за выбранный диапазон времени.
• Скачать полный log-файл или с учетом настроенных фильтров. Скачивание происходит в файл с расширением .log, название которого предзаполнено и формируется согласно шаблону: Logs<дата_загрузки><количество_записей>.
• Выполнить поиск логов несколькими способами:

Рисунок 202 ‒ Загрузка log-файла

• Поиск по тексту логов. Для поиска используют шаблон "параметр:значение_параметра" через двоеточие и без пробелов, например kubernetes.pod_name:shturval-local-csi-node-6g6nh или kubernetes.pod_name:shturval-local-csi-node. Поддерживается возможность поиска по нескольким ключам, для чего используется разделитель "|", например "message.level:warning | message.id:1". Поиск происходит внутри выбранного ProjectID в выборке, соответствующей временному диапазону.
• Поиск с помощью параметров логов. Для фильтрации по параметрам нужно нажать на + рядом с заголовком "Параметры поиска". В открывшимся окне выбрать из выпадающего списка поле, по которому необходимо отфильтровать логи, оператор и указать значение.

Доступные операторы для фильтра значений поля:

• AND (И) ‒ в выборку попадут логи, у которых есть заданное поле, включающее все перечисленные значения. Если указано только одно значение, оператор работает как "=".
• OR (ИЛИ) ‒ в выборку попадут логи, у которых есть заданное поле, включающее как минимум одно из перечисленных значений. Если указано только одно значение, оператор работает как "=".
• NOT (НЕТ) ‒ исключает логи с заданным полем, содержащим перечисленные значения.
• = (Равно) ‒ в выборку попадут логи с заданным полем и соответствующим значением. Если перечислено несколько значений, оператор работает по принципу логического AND (И).

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

• заданные параметры фильтрации объединены между собой по принципу логического оператора AND (И). Например, если заданы параметры message.level=warning и message.id=1, то отобразятся логи, соответствующие обоим условиям;
• в перечень для настройки параметров попадут поля логов, предварительно отфильтрованные по проекту, временному диапазону и поиску по тексту. В случае если в перечне не нашлось требуемое поле, нужно изменить преднастроенные фильтры;
• поиск по параметрам может осуществляться по частичному совпадению в значениях полей, за исключением специальных параметров. Например, если задан параметр kubernetes.pod_name=kub, в выборку попадут логи, у которых поле kubernetes.pod_name содержит комбинацию kub.

При поиске в соответствии со специальными параметрами игнорируется выбор оператора пользователем. Выполняется поиск по точному, полному совпадению и только по одному (указанному первым) значению (таблица 65).

Также следует обратить внимание, что одновременный поиск по параметрам и тексту работает согласно логическому оператору AND (И).

Если в кластере установлены расширенные настройки безопасности, то в кластере пишутся события безопасности и в VLogs создается соответствующий проект c ProjectID: kube audit. Сведения о событиях соответствуют правилам настроенной политики аудита событий в кластере Kubernetes AuditPolicy.

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

Рисунок 203 ‒ Расширенные настройки безопасности

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

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

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

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

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

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

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

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

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

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

На вкладке "Доступность сервисов" отображаются карточки ключевых системных компонентов (сервисов) кластера (рисунок 206).

Рисунок 206 ‒ Вкладка "Доступность сервисов"

По каждому сервису можно получить данные:

• статус доступности сервиса на текущий момент времени (цветовая индикация);
• процент доступности сервиса: среднее значение доступности за последний час, выраженное в процентах;
• наименование Helm-чарта сервиса;
• неймспейс, в котором установлен экземпляр сервиса.

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

Для клиентских кластеров и кластера управления состав сервисов отличается. Вкладка доступна, если в кластере (клиентском, кластере управления) включен локальный сбор метрик "Модуль мониторинга. Компонент управления модуля мониторинга" (VM Agent) (shturval-metrics-collector) и в кластере управления "Модуль мониторинга. Централизованный сбор метрик" (Victoria Metrics) (shturval-monitoring).

Также отследить статус доступности сервисов на текущий момент времени можно в разделе "Администрирование" на странице "Установленные сервисы".

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Получение kubeconfig

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

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

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

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

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

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

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

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

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

export CLUSTERNAME=my-cluster
export SH_USERNAME="admin"
export SH_PASS="my-password"
export INGRESS="$CLUSTERNAME.ip-x-x-x-x.shturval.link"
export AUTHENDPOINT="https://shturval.$INGRESS/authn"
export BACKENDPOINT="https://shturval.$INGRESS"
export KUBECONFIG_PATH=/tmp/$CLUSTERNAME.conf
В переменную CLIENT_SECRET впишите значение client_secret из секрета с именем backend-<автогенерируемые символы>. Он находится в неймспейсе shturval-backend.
При отсутствии доступа к секрету, запросите данные у администратора платформы
export CLIENT_SECRET=clientsecret
export COOKIE_PATH=/tmp/cookie

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

Выполните аутентификацию к AUTHENDPOINT
curl -k -v -s $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" 2>&1 | grep -E -o "\<code=[A-Z0-9]+")
echo "Got code"
Получите токен доступа (access token) после успешного получения авторизационного кода
token=$(curl -k -s "$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"

3. Отправка запроса на получение 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 kubectl-shturval-plugin для всех кластеров" (рисунок 212).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Можно задать имя группы одним из способов:

• Первый способ ‒ выбрать из каталога, подключенного при интеграции с LDAP (например, AD или openLDAP). Выбор из каталога доступен только в случае настроенной в Комплексе интеграции с LDAP:

1. В поле "Имя группы" начать вводить имя группы. Со второго введенного символа будет выполнен поиск группы по каталогу.
2. В результате поиска будет получен список имен групп, в котором выбрать необходимую группу из списка.
3. Выбрать необходимую группу из списка (поиск по каталогу регистронезависимый). Если каталог не подключен, можно указать название группы вручную.

• Второй способ‒ ввести имя группы вручную, для чего выбрать "Ручной ввод" и в поле "Имя группы" указать имя группы пользователей. Данный способ может быть необходим, когда в Комплексе подключен внешний провайдер аутентификации (например, Keycloak или Blitz). Если имя группы указано вручную, поиск группы по каталогу LDAP не будет выполнен.

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

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

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

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

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

Можно задать имя группы одним из способов:

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

1. В поле "Уникальное имя пользователя" начать вводить имя пользователя. Со второго введенного символа будет выполнен поиск пользователей по каталогу. В результате поиска отобразится список пользователей, имена которых содержат указанные символы.
2. Выбрать имя пользователя из списка (поиск по каталогу регистронезависимый). Если каталог не подключен, можно указать имя пользователя вручную.

• Второй способ ‒ ввести имя пользователя вручную. Для этого выбрать "Ручной ввод" и в поле "Уникальное имя пользователя" указать имя пользователя. Данный способ может быть необходим, если в платформе подключен внешний провайдер аутентификации (например, Keycloak или Blitz). Если имя пользователя указано вручную, поиск пользователя по каталогу LDAP не будет выполнен.

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

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

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

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

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

Audit Policy

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

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

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

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

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

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

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

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

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

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

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

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

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

Настройка 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"]

Аудит-логи

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

Рисунок 218 ‒ Вкладка "Логи"

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

ClusterIssuers

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

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

Создание ClusterIssuers

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

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

• Имя;
• Спецификацию объекта, из выпадающего списка выбрав тип:
• ACME;
• Vault;
• Корпоративный центр сертификации (CA);
• Самоподписной (SelfSigned).

При необходимости можно задать лейблы.

Рисунок 219 ‒ Добавление ClusterIssuers

Настройка ACME

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

1. заполнить сведения о сервере ACME, например https://acme-v02.api.letsencrypt.org/directory;
2. ввести email, который связан с учетной записью ACME;
3. определить, нужно ли пропускать проверку TLS (по умолчанию установлено "Нет").

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

Важно ‒ Если в кластер добавлен сертификат ACME, необходимо мониторить работу ACME-сервера. В случае сбоя на сервере, кластеры с сертификатами ACME будут недоступны.

4. при установлении защищенного TLS-соединения можно указать в поле "CA Bundle" пакет сертификатов центра сертификации. CA Bundle содержит корневой сертификат и промежуточный в формате PEM для проверки подлинности и доверия сертификату сервера ACME. Следует обратить внимание, что данные файла CA Bundle должны содержать ----BEGIN CERTIFICATE---- и ----END CERTIFICATE----. Если CABundle не указан, но проверка TLS-соединения устанавливается, то для проверки соединения используется пакет системных сертификатов внутри контейнера.

В блоке "Ключ учетной записи ACME" необходимо:

1. ввести имя и ключ Secret;
2. добавить solvers, для чего нажать на + рядом с Solvers и выбрать тип: HTTP01 или DNS01;
3. в зависимости от выбранного типа solvers:

• Для HTTP01 заполнить поле "ClassIngress" и нажать кнопку Добавить (рисунок 220);

Рисунок 220 ‒ Добавление solver HTTP01

Может быть использован, если:

• провайдер не блокирует порт 80;
• Ingress-контроллер доступен из интернета по порту 80;
• не используются сертификаты с подстановкой (wildcard-сертификаты).
• ввести класс Ingress (ClassIngress), который должен быть использован для решения Challenge от Let’s Encrypt.

Посмотреть, какие ClassIngress есть в кластере, можно командой:

kubectl get ingressclass -A

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

• Для DNS01/acmeDNS заполнить значение хоста. В AccountSecretRef вписать имя и ключ, затем нажать кнопку Добавить (рисунок 221).

Рисунок 221 ‒ Добавление solver DNS01/acmeDNS

Может быть использован, если:

• используется сертификаты с подстановкой (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 вписать имя и ключ, затем нажать кнопку Добавить (рисунок 222).

Рисунок 222 ‒ Добавление solver DNS01/rfc2136

Может быть использован, если есть:

• сервер 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, затем нажать кнопку Добавить (рисунок 223).

Рисунок 223 ‒ Добавление sover DNS01/webhook

Пример:

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>

Настройка Vault

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

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

1. Для интеграции выбрать ServiceAccount из выпадающего списка (рисунок 224).

Рисунок 224 ‒ Добавление учетной записи в vault

2. ServiceAccount должен быть создан в неймспейсе cert-manager и иметь роль vault-issuer.

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

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

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

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

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

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

Настройка "Корпоративный центр сертификации (CA)"

CA (Certificate Authority) ClusterIssuers должны быть настроены с сертификатом и закрытым ключом центра сертификации, которые хранятся в Secret. Перед добавлением CA ClusterIssuer в неймспейс нужно создать Secret, содержащий сертификат и ключ (рисунок 225).

Рисунок 225 ‒ Добавление Secret

Следует обратить внимание, что для настройки ClusterIssuers необходимо соблюсти ряд условий:

• Secret должен располагаться в неймспейсе cert-manager.
• В Secret наименование полей для сертификата ключа должны быть строго: tls.crt и tls.key. По этим названиям cert-manager получит данные сертификата и ключа центра сертификации.
• Данные в tls.crt и tls.key должны быть закодированы в base64.

Пример Secret:

apiVersion: v1
kind: Secret
metadata:
  name: secretname
  namespace: cert-manager
data:
  tls.crt: LS0tLS1CR…
  tls.key: LS0tLS1CR…

Для ClusterIssuer с типом "Корпоративный центр сертификации" (рисунок 226) нужно:

1. выбрать значение в списке "Имя Secret", содержащие сертификат и ключ центра сертификации;
2. добавить "URL-адреса OCSP серверов" (ocspServers) при необходимости проверки действительности (статуса) сертификата. Если не указан ни один адрес, сертификат будет выпущен без указания OCSP-сервера. Пример URL-адреса сервера: http://ocsp.int-x3.example.org;
3. добавить "URL-адреса сертификатов" (issuingCertificateURLs) для указания в выпускаемых сертификатах. URL-адрес должен использовать HTTP- протокол, чтобы избежать проблем с проверкой домена, например, http://ca.domain.com/ca.crt;
4. при необходимости добавить "Точки распространения CRL" (crlDistributionPoints): адреса со списками отозванных сертификатов (Certificate Revocation List, CRL). По указанным адресам (например, http://example.com) можно проверить статус отзыва выданных сертификатов.

Рисунок 226 ‒ ClusterIssuer "Корпоративный центр сертификации"

Самоподписной (SelfSigned)

Самоподписной (SelfSigned) ClusterIssuers используются для установления быстрого и безопасного соединения, когда нет необходимости в подтверждении подлинности центрами сертификации.

Если выбран тип "Самоподписной" для ClusterIssuer (рисунок 227), при необходимости можно добавить "Точки распространения CRL (CDP)" (crlDistributionPoints). Каждая точка (URL-адрес, например, http://example.com) идентифицирует местоположение списка отозванных сертификатов (Certificate Revocation List, CRL), в котором можно проверить действительность выданных сертификатов.

Рисунок 227 ‒ ClusterIssuer "Самоподписной"

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

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

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

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

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

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

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

Удалить ClusterIssuer можно одним из способов:

• на странице "ClusterIssuers" нажать на пиктограмму с изображением корзины в строке объекта;
• на странице просмотра ClusterIssuer на вкладке "ClusterIssuer" нажать кнопку Удалить;
• на странице просмотра ClusterIssuer перейти на вкладку "Манифест" и нажать на пиктограмму с изображением корзины.

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

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

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

На странице созданной сетевой политики отображается состояние примененной политики (рисунок 228).

Рисунок 228 ‒ Состояние примененной политики

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

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

Также на вкладке "Манифест" можно удалить сетевую политику, нажав на пиктограмму с изображением корзины .

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

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

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

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

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

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

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

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

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

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

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

Для каждого компонента можно настроить правило взаимодействия с неймспейсом. Входящие потоки в конфигурируемый неймспейс регламентируются правилами 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 (рисунок 231):

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

Рисунок 231 ‒ Запрещающая политика 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 (рисунок 232):

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)>

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

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

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

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

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

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:
        ‒ {}

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

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

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

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

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

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

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

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

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

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

Узлы в кластере

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

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

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

• Группы узлов;
• InfraMachineTemplates;
• Неопознанные узлы.

Вкладка "Группы узлов"

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

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

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

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

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

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

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

Рисунок 237 ‒ Вкладка "Группы узлов"

Вкладка "InfraMachineTemplates"

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

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

Вкладка "Неопознанные узлы"

Вкладка "Неопознанные узлы" доступна в случае, если в кластере были выявлены узлы без связи с машинами. Имеется возможность удалить неопознанный узел из кластера.

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

В случае отказа/недоступности узла кластер начинает перераспределять нагрузку с этого узла на другие только спустя 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.

Conditions узлов кластера

Работоспособность узла в кластере можно определить по Node Conditions (состояниям узла), статусы которых приведены в таблице 66.

Если в кластере установлен сервис для мониторинга проблем на узлах (Node Problem Detector, NPD), для узлов кластера могут выводиться дополнительные состояния (таблица 67).

Чтобы перейти к просмотру состояний узла кластера в графическом интерфейсе, нужно:

1. в кластере из бокового меню открытье раздел "Администрирование" и перейти на страницу "Управление узлами";
2. на странице просмотра узла, на вкладке "Узел" в секции "Состояние" приведен перечень состояний узла (рисунок 239).

Рисунок 239 ‒ Состояние узла

Узел

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

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

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

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

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

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

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

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

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

Cordon

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

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

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

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

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

Drain

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

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

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

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

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

Рисунок 247 ‒ Селектор подов

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

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

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

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

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

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

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

Worker-узлы

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

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

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

Рисунок 250 ‒ Удаление узла при ручном масштабировании

При полном (без пересоздания) удалении Worker-узла из кластера с провайдером Shturval v2 по умолчанию выполняется очистка узла. В случае неуспешной очистки узла ShturvalMachine будет удалена принудительно.

Control Plane узлы

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

• удалить полностью Control Plane-узел, если после удаления в кластере останется нечетное количество работающих Control Plane-узлов (например, 3 или 1). Наличие работающих узлов проверяется на момент запроса на удаление. В случае несоблюдения условия запрос на удаление будет недоступен (рисунок 251).
• удалить Control Plane-узел с пересозданием узла при условии, что в результате удаления узла в кластере должно остаться не менее двух работающих Control Plane-узлов. Наличие двух работающих узлов проверяется на момент запроса на удаление. В случае несоблюдения условия запрос на удаление с пересозданием будет недоступен (рисунок 252).

Рисунок 251 ‒ Удаление Control Plane-узла полностью

Рисунок 252 ‒ Удаление Control Plane-узла с пересозданием

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

Рисунок 253 ‒ Ввод названия узла

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

При полном (без пересоздания) удалении Control Plane-узла из кластера с провайдером Shturval v2 по умолчанию выполняется очистка узла. При необходимости можно отменить очистку узла, сняв выбор в поле "С очисткой узла" (рисунок 254).

Важно ‒ При принудительном удалении Machine без очистки узла потребуется ручной сброс хоста и ручное удаление сервисов Комплекса с него. Рекомендуется отменять очистку узла с осторожностью, так как это может привести к трудностям в последующей эксплуатации хоста.

Рисунок 254 ‒ Удаление с очисткой узла

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

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

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

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

• Имя пода (доступна фильтрация). Нажатие на имя открывает страницу просмотра пода.
• Контейнеры. Отношение количества работающих контейнеров к общему количеству контейнеров в поде.
• Количество рестартов пода (доступна сортировка).
• Дата создания (доступна сортировка).
• Неймспейс (доступна фильтрация). Нажатие на имя неймспейса открывает дашборд неймспейса. Можно ввести значение для фильтрации подов по неймспейсам. Для отмены фильтрации по неймспейсам в фильтре нажать Отменить и далее Применить.
• Статус (доступна фильтрация). Возможные значения для выбора в фильтре: Running, Pending, Terminating, CrashLoopBackOff, Completed, Failed, Unknown.
• Какому родительскому объекту подчинен (доступна фильтрация). Когда под подчинен нагрузке, нажатие на имя нагрузки открывает ее страницу просмотра.
• QoS (Quality of Service) пода (доступна фильтрация по: Guaranteed, Burstable, BestEffort). Подробнее о QoS см. в п. Pods.
• Лейблы. По умолчанию колонка не отображается. Чтобы просмотреть лейблы подов, нажать на шестеренку в правом углу таблицы и выбрать колонку "Лейблы" для отображения на экране.

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

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

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

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

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

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

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

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

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

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

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

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

Вкладка "Taints"

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

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

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

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

Пример:

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

# Заданный Taint на узле
spec:
  taints:
  ‒ effect: NoSchedule
    key: key1
    value: value1

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

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

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

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

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

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

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

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

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

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

Создание NCI

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

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

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

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

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

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

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

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

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

Добавление NCI

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

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

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

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

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

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

kubectl get nodes --show-labels

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

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

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

Конфигурация разделов 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

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

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

Пример манифеста NCI для установки chrony и настройки NTP-серверов и таймзоны:

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

Пример манифеста NCI для установки ntp и настройки NTP-серверов и таймзоны:

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

Для настройки NTP-серверов при наличии установленного и включенного сервиса chronyd или ntpd необходимо в блоке "NTP" (рисунок 263):

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

1. В поле "Список серверов NTP" добавить адреса корпоративных серверов: не менее одного сервера NTP, для чего ввести в поле IP-адрес или FDQN сервера. При необходимости можно изменить значение по умолчанию для часового пояса.
2. Задать имя сервиса NTP.

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

Пример:

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

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

Пример:

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

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

Container Runtime

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

1. настроить конфигурацию реестров контейнеров, нажав на +. Реестр контейнеров позволяет хранить образы и управлять ими:

• добавлять новые (push);
• извлекать (pull);
• преобразовывать имя образа в репозитории в его цифровое (digest) представление (resolve).

2. в качестве адреса локального репозитория ввести FQDN репозитория, используемого в качестве зеркала для внешнего репозитория;
3. ввести ключ авторизации в локальном репозитории;
4. ввести адрес внешнего репозитория;
5. нажать кнопку Добавить.

Пример:

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

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

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

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

Параметры sysctl

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

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

1. раскрыть блок "Параметры sysctl";
2. указать список значений 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

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

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

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

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

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

Пример:

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

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

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

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

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

1. раскрыть блок "Пакеты для установки";
2. ввести название пакета;
3. выбрать целевое состояние пакета: Present или Absent;
4. ввести необходимую версию пакета;
5. включить запрет обновления пакета или снятие запрета обновления перед установкой;
6. ввести команды, которые должны быть запущены после установки пакета. При нажатии на + появится строка для ввода команды;
7. определить, есть ли обязательное условие, что команды, запущенные после установки пакета, должны выполниться успешно;
8. ввести команды, которые должны быть запущены перед установкой пакета. При нажатии на + появится строка для ввода команды;
9. определить, есть ли обязательное условие, что команды, запущенные перед установкой пакета, должны выполниться успешно.

Пример:

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

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

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

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

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

1. раскрыть диалоговое окно "Файлы и директории";
2. ввести путь к файлу или директории;
3. выбрать тип: Файл или Директория;
4. ввести значения прав доступа;
5. указать владельца и группу;
6. ввести содержимое файла, если выбран тип "Файл";
7. ввести необходимую версию пакета.

Пример:

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 дней (рисунок 268).

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

Пример:

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

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

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

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

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

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

3. выбрать статус сертификата: "Подтвержден" или "Не подтвержден";
4. ввести имя сертификата.

Использование центрами сертификации корневого сертификата будет возможно, если статус сертификата "Подтвержден". Центры сертификации не смогут использовать корневой сертификат для подписания 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 и перезапускает узел для применения настроек (рисунок 270).

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

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

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

Пример:

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

Модули ядра

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

1. нажать Добавить модуль ядра;
2. задать имя модуля ядра (обязательное поле);
3. задать имя файла с опциями;
4. определить, заблокирован ли модуль ядра (при блокировке модуля ядра включение автозагрузки модуля ядра невозможно);
5. определить, включена ли автозагрузка модуля ядра. (при блокировке модуля ядра включение автозагрузки модуля ядра недоступно).

Пример параметра ядра в загрузчике 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

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

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

Systemd-юниты

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

1. открыть диалоговое окно "Systemd-юниты";
2. включить запуск сервиса, в том числе при запуске ОС;
3. ввести "Название systemd unit";
4. нажать кнопку Добавить.

Пример:

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

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

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

Kubelet

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

Рисунок 273 ‒ 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 в кластере". Для продолжения заполнения разделов нужно нажать Продолжить, по окончании заполнения разделов нажать Завершить.

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

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

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

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

• ввести имя пользователя (обязательное поле) для подключения к узлу по 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

Kube API Server

В этом разделе можно настроить конфигурацию Kube API сервера. Настройка параметров доступна по секциям (рисунок 275):

• Ресурсы Kube API Server;
• Admission Plugins;
• OIDC;
• Feature Gates;
• Audit Policy;
• Secrets Encryption.

Рисунок 275 ‒ Раздел "Kube API Server"

В секции "Ресурсы Kube API Server" вы можете:

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

В секции "Admission Plugins" есть возможность управлять контроллерами доступа. Для добавления нужно нажать на +, выбрать плагин из списка и установить режим использования:

• Чтобы включить плагин, добавить его в список "Admission Plugins" и разрешить использование.
• Чтобы выключить плагин, добавить его в список "Admission Plugins" и запретить использование.
• Если необходимо оставить настройки по умолчанию, плагина не должно быть в списке.

В секции "OIDC" можно настроить параметры:

• Имя пользователя claim (по умолчанию задано sub);
• Префикс имени пользователя;
• Группа claim;
• Префикс группы;
• OIDC Issuer URL;
• ID OIDC клиента;
• указать файл CA (закодированный в base64).

В секции "Feature Gates" возможно управлять дополнительными функциями (Feature Gates). Чтобы добавить, требуется нажать +, установить ключ и выбрать значение:

• true ‒ включить функцию;
• false ‒ отключить функцию.

В секции "Audit Policy" можно определить основные параметры применения политики аудита:

• указать конфигурацию Audit Policy (закодированную в base64);
• задать максимальное количество копий логов. Если необходимо отключить ограничение на количество копий, установить 0;
• задать срок хранения логов (максимальное количество дней хранения логов);
• максимальный размер логов в мегабайтах (Mb).

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

В секции "Secrets Encryption" можно указать конфигурацию шифрования Secrets, закодированную в base64.

Пример:

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

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

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

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

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

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

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

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

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

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

Taints и Tolerations

Taints и Tolerations используются в Kubernetes как один из способов управления распределением подов на узлы. Taints (ограничения) устанавливаются на узлы кластера, чтобы запретить распределения подов (Pods) на них. Для размещения подов на такие узлы подам необходимо присвоить соответствующие Tolerations (допуски). Планировщик Kubernetes по умолчанию учитывает Taints и Tolerations при выборе узла для запуска конкретного пода.

Taints и Tolerations могут быть использованы, например, когда требуется выделить узлы кластера под определенные нагрузки. В этом случае потребуется установить на узел Taint и соответствующие Tolerations на поды.

Из графического интерфейса РОСА Кубис можно управлять Taints на узлах и Tolerations подов.

Taints

На один узел возможно добавить несколько Taints. При этом для размещения подов на таком узле потребуются Tolerations для каждого ограничения.

Taints состоит из:

• ключа (key) и его значения (value). Для одного узла доступно добавление одинаковых пар "ключ:значение" с разными "Эффектами";
• Эффект (effect), определяющего правила ограничений для размещения подов:
• NoSchedule ‒ позволяет строго ограничить размещение подов. Ни один под не будет запланирован на узле без соответствующего Toleration (разрешения);
• PreferNoSchedule ‒ нестрогое ограничение для размещения подов. Поды без соответствующего Toleration (разрешения) могут быть размещены на узле, но предпочтительнее будут поды с Tolerations;
• NoExecute ‒ позволяет вытеснять уже работающие поды на узле. Когда применяется Taint c Эффектом NoExecute, то:
  • поды без соответствующего Toleration немедленно вытесняются;
  • поды с соответствующим Toleration остаются на узле;
  • поды с соответствующим Toleration и заданным периодом разрешения (tolerationSeconds) остаются на узле в течении указанного времени, после чего вытесняются. По умолчанию tolerationSeconds равен 5 минутам.

Taints, устанавливаемые автоматически на узел при выполнении определенных условий, приведены в таблице 68.

Пример установки Taints на узел в графическом интерфейсе Комплекса:

1. В кластере в разделе "Администрирование" открыть страницу "Управления узлами" и нажать на узел, которому требуется добавить Taint (рисунок 276);

Рисунок 276 ‒ Выбор узла для добавления Taints

2. На странице узла перейти на вкладку "Taint" и нажать +;
3. задать "Ключ", выбрать "Эффект", при необходимости указать "Значение" и нажать Добавить (рисунок 277).

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

4. Когда все необходимые Taints добавлены, нажать Сохранить (рисунок 278).

Рисунок 278 ‒ Добавленный Taint

В случае, когда на узле несколько Taints с разными "Эффектами":

• Если у пода есть Tolerations ко всем Taints, кроме Taint с эффектом NoSchedule, то под не будет запланирован на этот узел.
• Если у пода нет Toleration, соответствующего только Taint с эффектом PreferNoSchedule (к остальным Taints есть Tolerations), то возможно под будет размещен на узле.
• Если у пода нет Toleration, соответствующего Taint с эффектом NoExecute (к остальным Taints есть Tolerations), то такой под будет вытеснен с узла (если уже запущен на узле) и не будет запланирован на узле (если еще не запущен).

Tolerations

Чтобы снять ограничение на размещение пода на узле с Taint, необходимо указать в Tolerations:

• Ключ Taint узла (key). Если необходимо, чтобы Toleration распространялся на любые ключи Taints узлов, то ключ должен быть пустым, должен быть установлен оператор Exists и указан соответствующий "Эффект" Taint узла;
• Значение Taint узла (value). Если значение не будет указано, Toleration распространяется на любые значения Taints узла;
• Оператор ‒ Exists (существование), Equal (равенство). Exists указывается, когда необходимо соответствие по ключу Taint узла. Если требуется, чтобы значение соответствовало значению Taint узлов, должно быть установлен Equal.
• "Эффект" Taint узла: NoSchedule, PreferNoSchedule, NoExecute. Отсутствие "Эффекта" соответствует выбору всех эффектов с указанным ключом.

Пример Tolerations пода:

  tolerations:
  ‒ key: "key1"
    operator: "Exists"
    effect: "NoSchedule"
  ‒ key: "key2"
    operator: "Equal"
    value: "value2"
    effect: "NoSchedule"

При необходимости вытеснения подов с узла добавляется Taint c эффектом NoExecute. Например, этот эффект по умолчанию добавляется при недоступности узла. В этом случае по умолчанию в течение 5 минут удаляются все поды с узла.

Возможно увеличить этот период, чтобы сохранить поды на узле до его восстановления. Для этого в Tolerations добавляется tolerationSeconds.

Пример Toleration c установленным периодом размещения подов до вытеснения с узла:

tolerations:
- key: "key1"
  operator: "Equal"
  value: "value1"
  effect: "NoExecute"
  tolerationSeconds: 6000

Пример установки Tolerations поду в графическом интерфейсе РОСА Кубис:

1. в неймспейсе кластера в разделе "Нагрузки" перейти на страницу нагрузки, например Deployment, и нажать Добавить Deployment;
2. в блоке "Шаблон пода" найти Tolerations и нажать +;
3. задать ключ и значение Taint, которому должен соответствовать Toleration, и выбрать "Эффект" (рисунок 279).

Рисунок 279 ‒ Добавление Tolerations

При создании любого вида нагрузки есть возможность добавить Tolerations.

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

О группе Control Plane

Control Plane ‒ это группа управляющих узлов кластера. На них размещается база ETCD и некоторые критические сервисы. Для тестовых кластеров, как правило, в группе достаточно одного узла, в отказоустойчивых ‒ 3. Не рекомендуется создавать более трех узлов, т. к. это может вызывать замедление работы кластера из-за сложного механизма достижения кворума ETCD на узлах. В кластере может быть создана только одна группа Control Plane.

Сведения о группе узлов или ее состоянии можно отслеживать на странице "Управление узлами" просматриваемого кластера, а также в кластере управления в разделе "Администрирование → Кастомные ресурсы" с помощью кастомного ресурса MachineDeployment в API-группе cluster.x-k8s.io.

На странице "Управление узлами" есть возможность изменить конфигурацию группы Control Plane, для чего нужно справа от названия группы ControlPlane-узлов нужно нажать на кнопку Конфигурация группы. К конфигурации относятся: количество узлов, параметры присоединения узла в группу, сайзинг узлов и механизм self-healing (рисунок 280). Управление количеством узлов в группе доступно на вкладке "Конфигурация ClusterAPI".

Рисунок 280 ‒ Конфигурация группы Control Plane

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

• Конфигурация ClusterAPI;
• InfraMachineTemplate;
• MachineHealthCheck.

Конфигурация ClusterAPI

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

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

Детальнее параметры можно настроить в кластере управления в разделе "Администрирование  Кастомные ресурсы" с помощью кастомного ресурса KubeadmControlPlane API-группы controlplane.cluster.x-k8s.io.

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

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

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

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

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

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

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

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

InfraMachineTemplate

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

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

Детальнее параметры можно настроить в кластере управления в разделе "Администрирование → Кастомные ресурсы" с помощью кастомного ресурса соответствующего провайдера в API-группе infrastructure.cluster.x-k8s.io.

Рисунок 282 ‒ Вкладка "InfraMachineTemplate"

OVirtMachineTemplate

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

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

VSphereMachineTemplate

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

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

Рисунок 283 ‒ VSphereMachineTemplate

OpenStackMachineTemplate

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

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

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

Рисунок 284 ‒ OpenStackMachineTemplate

BasisMachineTemplate

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

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

Рисунок 285 ‒ BasisMachineTemplate

ShturvalMachineTemplate

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

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

Рисунок 286 ‒ ShturvalMachineTemplate

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

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

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

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

Важно:

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

YandexMachineTemplate

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

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

Рисунок 287 ‒ YandexMachineTemplate

VCDMachineTemplate

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

• DiskSize ‒ выбрать единицу измерения и задать необходимое значение. Можно задать объем диска в Gi (выбрано по умолчанию) или Mi.
• SizingPolicy ‒ выбрать политику управления ресурсами (CPU, RAM) из доступных в выпадающем списке.
• template (Шаблон ВМ). Подробнее о создании шаблона ВМ см. в п. Шаблоны виртуальных машин.

Поля catalog (каталог образов) и network (подсеть узлов) доступны для просмотра (рисунок 288).

Рисунок 288 ‒ VCDMachineTemplate

MachineHealthCheck

Для Control Plane-узлов на вкладке "MachineHealthCheck" можно (рисунок 289):

Рисунок 289 ‒ MachineHealthCheck

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

Детальнее параметры MachineHealthChecks можно настроить в кластере управления в разделе "Администрирование  Кастомные ресурсы" с помощью кастомного ресурса MachineHealthCheck в API-группе cluster.x-k8s.io.

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

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

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

Примеры:

1. Значение maxUnhealthy ‒ 90%:

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

2. Значение maxUnhealthy ‒ 40%:

В группе три Control Plane-узла, где два узла неработоспособны. Следовательно, количество неработоспособных узлов = 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.

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

Конфигурация Workers-узлов

О группах Workers

Группы Worker-узлов ‒ это группы узлов, на которых запускается рабочая нагрузка кластера. По умолчанию в РОСА Кубис создается две группы Worker-узлов: Infra и Default, а также есть возможность создавать дополнительные группы. Группа инфраструктурных узлов будет предпочтительно использована для развертывания инфраструктурных сервисов кластера. В случае отсутствия свободных узлов в группе сервисы будут разворачиваться на Worker-узлах других групп. Группа по умолчанию Worker-узлов, а также любые дополнительные группы могут быть использованы для разворачивания пользовательских нагрузок.

Сведения о каждой группе узлов/ее состоянии можно отслеживать на странице "Управление узлами" просматриваемого кластера, а также в кластере управления в разделе "Администрирование  Кастомные ресурсы" с помощью кастомного ресурса MachineDeployment в API-группе cluster.x-k8s.io.

На странице "Управление узлами" есть возможность удалить ранее созданную, добавить новую или изменить параметры конфигурации ранее созданных групп Worker-узлов.

Чтобы добавить новую группу Worker-узлов, нужно нажать на Добавить группу Worker-узлов (рисунок 290). На странице создания новой группы узлов доступны вкладки "Конфигурация ClusterAPI" и "InfraMachineTemplate".

Рисунок 290 ‒ Добавление группы Worker-узлов

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

• Конфигурация ClusterAPI;
• InfraMachineTemplate;
• MachineHealthCheck.

Конфигурация ClusterAPI

При создании новой группы в блоке "Конфигурация ClusterAPI" есть возможность указать параметры ClusterAPI, MachineDeployment. Название группы формируется по правилу: название кластера с постфиксом в виде запрашиваемого названия группы (рисунок 291).

Рисунок 291 ‒ Создание группы

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

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

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

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

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

При автоматическом масштабировании минимальное количество узлов может быть 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

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

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

Детальнее параметры шаблонов инфраструктуры можно настроить в кластере управления в разделе "Администрирование  Кастомные ресурсы" с помощью кастомного ресурса соответствующего провайдера в API-группе infrastructure.cluster.x-k8s.io.

OVirtMachineTemplate

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

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

Рисунок 294 ‒ OVirtMachineTemplate

VSphereMachineTemplate

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

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

Рисунок 295 ‒ VSphereMachineTemplate

OpenStackMachineTemplate

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

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

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

Рисунок 296 ‒ OpenStackMachineTemplate

BasisMachineTemplate

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

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

Рисунок 297 ‒ BasisMachineTemplate

ShturvalMachineTemplate

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

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

Рисунок 298 ‒ ShturvalMachineTemplate

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

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

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

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

Рисунок 299 ‒ InfraMachineTemplate

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

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

YandexMachineTemplate

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

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

Рисунок 300 ‒ YandexMachineTemplate

VCDMachineTemplate

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

• DiskSize ‒ выбрать единицу измерения и задать необходимое значение. Можно задать объем диска в Gi (выбрано по умолчанию) или Mi;
• SizingPolicy ‒ выбрать политику управления ресурсами (CPU, RAM) из доступных в выпадающем списке;
• template (Шаблон ВМ). Подробнее о создании шаблона ВМ см. в п. Шаблоны виртуальных машин.

Поля catalog (каталог образов) и network (подсеть узлов) доступны для просмотра.

Рисунок 301 ‒ VCDMachineTemplate

MachineHealthCheck

Для Worker-группы узлов на вкладке "MachineHealthCheck" (рисунок 302) можно:

Рисунок 302 ‒ MachineHealthCheck

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

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

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

Детальнее параметры MachineHealthChecks можно настроить в кластере управления в разделе "Администрирование  Кастомные ресурсы" с помощью кастомного ресурса MachineHealthCheck в API-группе cluster.x-k8s.io.

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

Примеры:

1. Значение maxUnhealthy ‒ 90%:

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

2. Значение 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.

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

Autoscaler в ClusterAPI

Cluster Autoscaler (автоматическое масштабирование кластера) в ClusterAPI представляет собой механизм изменения количества узлов в кластере в зависимости от нагрузки на узлы. Автомасштабирование позволяет оптимизировать ресурсы при переменной нагрузке в кластерах Kubernetes. Основная цель Cluster Autoscaler — предоставить узлы подам (Pods), ожидающих запуска.

Cluster Autoscaler может управлять автомасштабированием только в группах Worker-узлов. Он отслеживает состояние подов, узлов в кластере, а также:

• увеличивает количество узлов в группе, если недостаточно ресурсов (CPU, память) на существующих узлах для запуска новых подов (Pods);
• удаляет неиспользуемые узлы, если ресурсов на узлах становится избыточно. При консолидации Cluster Autoscaler выбирает определенные узлы для удаления.

В кластерах по умолчанию включен Cluster Autoscaler. Автомасштабирование доступно в графическом интерфейсе на странице конфигурации группы узлов, на вкладке "Конфигурация ClusterAPI" (рисунок 303).

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

Аннотации автомасштабирования

Если в группе узлов установлено автоматическое масштабирование, ресурсу MachineDeployment присваиваются аннотации с заданным диапазоном количества узлов в группе:

• Аннотация, устанавливающая минимальное количество узлов:

  cluster.x-k8s.io/cluster-api-autoscaler-node-group-min-size: минимальное количество узлов
  

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

Следует обратить внимание, что автомасштабирование с нуля реплик в группе не включено в Комплексе. Для отказоустойчивости кластера рекомендуется использовать не менее двух Worker-узлов в кластере, поэтому нельзя установить менее двух реплик для диапазона в графическом интерфейсе.

• Аннотация, устанавливающая максимальное количество узлов:

  cluster.x-k8s.io/cluster-api-autoscaler-node-group-max-size: максимальное количество узлов
  

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

Пример MachineDeployment с автомасштабированием:

apiVersion: cluster.x-k8s.io/v1beta1
kind: MachineDeployment
metadata:
annotations:
cluster.x-k8s.io/cluster-api-autoscaler-node-group-max-size: "7"
cluster.x-k8s.io/cluster-api-autoscaler-node-group-min-size: "2"
...

Autoscaler отслеживает значения диапазона в аннотациях MachineDeployment и принимает решение об изменении количества узлов в группе в зависимости от их состояния и нагрузки.

Принцип срабатывания автоскейлинга

Если для группы узлов установлено автомасштабирование, то Cluster Autoscaler каждые 10 секунд:

• проверяет существование незапланированных подов (Pods), которые определяются поды по статусу Pending и состоянию PodScheduled со значением "false" и причиной "unschedulable" соответственно;
• анализирует запросы незапланированных подов (Pods) на vCPU, RAM и GPU;
• проверяет загрузку узлов группы.

По результатам проверки Cluster Autoscaler может изменить количество узлов в кластере:

• Добавить необходимое количество узлов в группу кластера, если есть поды в статусе Pending, и в кластере не хватает свободных ресурсов для их размещения.
• Удалить узел при соблюдении одновременно всех условий:
• Сумма запросов CPU и памяти всех подов на узле составляет менее 50% от выделяемой памяти узла.
• Все поды на узле (за исключением тех, которые по умолчанию работают на всех узлах) могут быть перемещены на другие узлы.
• Узел не имеет аннотации об отключении уменьшения масштаба.

Аннотация об отключении уменьшения масштаба:

cluster-autoscaler.kubernetes.io/scale-down-disabled: "true"

Время подготовки нового узла не зависит от работы Cluster Autoscaler. Cluster Autoscaler ожидает создания запрошенных узлов в течение 15 минут и по истечении времени может попытаться масштабировать другую группу узлов.

Cluster Autoscaler может работать одновременно в нескольких Worker-группах и распределять создаваемые узлы равномерно.

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

При анализе подов Cluster Autoscaler учитывает PodDisruptionBudget (PDB) и установленные правила распределения подов по узлам, такие как:

• nodeSelector;
• nodeAffinity с типом requiredDuringSchedulingIgnoredDuringExecution.

При этом не учитываются предпочтительные правила размещения пода на узел, т. е. nodeAffinity с типом preferredDuringSchedulingIgnoredDuringExecution.

Особенности удаления узла

Cluster Autoscaler не сможет удалить узел, если выполняется хотя бы одно условие:

• поды на узле имеют PDB (PodDisruptionBudget);
• в подах Kube-system нет PDB;
• есть "отдельностоящие" поды (не подчинены нагрузкам: Deployment, ReplicaSet, StatefulSet и т. д.);
• поды с локальным хранилищем (local storage);
• на остальных узлах недостаточно ресурсов для запросов подов;
• другие узлы не соответствуют по nodeSelector, правилам nodeAffinity подов.

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

Аннотация для вытеснения с узла:

cluster-autoscaler.kubernetes.io/safe-to-evict: "true"