#Обзор

#Как работает конфигурация машин

Machine Configuration управляет обновлением файлов, управлением unit-файлами systemd и развертыванием открытых SSH-ключей на узлах кластера. Система предоставляет Custom Resource Definition (CRD) MachineConfig для записи конфигурационных файлов на hosts, а также CRD MachineConfigPool для группировки узлов в конфигурационные группы.

Каждый MachineConfigPool управляет набором узлов и связанными с ними MachineConfig. Роли узлов определяют принадлежность к MachineConfigPool — пулы управляют узлами на основе их role labels.

Во время установки кластера система автоматически создает два MachineConfigPool (control plane и worker), а также два пустых MachineConfig (00-master и 00-worker). Пул control plane управляет конфигурацией 00-master, а пул worker — конфигурацией 00-worker.

Вы можете создавать пользовательские MachineConfigPool для worker-узлов, которым требуются специализированные конфигурации. Узлы control plane не могут использовать пользовательские пулы.

Пользовательские MachineConfigPool наследуют все конфигурации от пула worker и добавляют собственные специфические параметры. Любые изменения в пуле worker автоматически распространяются на пользовательские пулы. Machine Configuration не поддерживает пользовательские пулы, которые не наследуют конфигурацию от пула worker.

Кластер включает MachineConfiguration CR с именем "cluster" по умолчанию для задания глобальных политик обновления узлов. Подробности см. в документации Node Disruption Policy.

Иногда конфигурации узлов расходятся с ожидаемым состоянием. machine-config-daemon непрерывно отслеживает такое расхождение конфигурации и помечает затронутые узлы как Degraded до тех пор, пока администратор не устранит проблему. Узлы в состоянии Degraded остаются работоспособными, но не могут получать обновления.

#Основные понятия

Обработка конфигурации
MachineConfig обрабатываются в алфавитном порядке. Первая конфигурация служит базовой, а последующие накладываются поверх нее. Каждый MachineConfigPool преобразует управляемые им конфигурации в единый MachineConfig с именем: render-<pool-name>-<content-hash>, который затем применяется ко всем узлам этого пула.

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

Область управления
Machine Configuration управляет только явно настроенными элементами. Ручные изменения в системе не затрагиваются Machine Configuration Operator.

Формат конфигурации
Все MachineConfig используют формат спецификации Ignition v3.4.0.

Обнаружение расхождения
Если управляемые Machine Configuration файлы изменяются вне системы, machine-config-daemon помечает узел как Degraded, но не перезаписывает измененные файлы.

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

Поддерживаемые изменения

• Обычные файлы (в доступных для записи директориях, не являющихся root)
• unit-файлы systemd и их конфигурации
• Открытые SSH-ключи только для boot user

Machine Configuration не создает пользователей или группы. Перед настройкой SSH-ключей необходимо создать boot user и group.

Важно: Не вносите изменения в узлы вручную — это может привести к конфликтам конфигурации.

#Типы конфигурации

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

Unit-файлы systemd
Определение новых служб systemd или расширение существующих дополнительной конфигурацией.

Открытые SSH-ключи
Настройка доступа по SSH для boot user. Ключи для других пользователей отклоняются как недопустимые.

#Процесс обновления узла

Когда вы применяете MachineConfig, Machine Configuration гарантирует, что все затронутые узлы достигнут целевого состояния. Machine Configuration Operator создает новую сгенерированную конфигурацию, а machine-config-daemon выполняет на каждом узле следующие шаги:

1. Cordon — помечает узел как недоступный для планирования новых workloads
2. Drain — завершает существующие workloads и перераспределяет их на другие узлы
3. Apply — записывает новую конфигурацию на диск
4. Reboot — перезапускает узел для применения изменений
5. Uncordon — снова помечает узел как доступный для планирования

#Проверка состояния MachineConfigPool

Проверьте состояние пула с помощью:

kubectl get machineconfigpool

Пример вывода:

NAME     CONFIG                    UPDATED  UPDATING  DEGRADED  MACHINECOUNT  READYMACHINECOUNT  UPDATEDMACHINECOUNT  DEGRADEDMACHINECOUNT  AGE
master   rendered-master-06c9c4    True     False     False     3             3                  3                    0                     4h42m
worker   rendered-worker-f4b64     False    True      False     3             2                  2                    0                     4h42m

Справка по полям:

• NAME: Идентификатор пула
• CONFIG: Последняя примененная конфигурация для всех узлов пула
• UPDATED: True, когда все узлы имеют текущую конфигурацию; False во время обновления
• UPDATING: True, когда обновляется хотя бы один узел; False, когда все узлы в актуальном состоянии
• DEGRADED: True, когда конфигурация не может быть применена как минимум к одному узлу
• MACHINECOUNT: Общее количество узлов в пуле
• READYMACHINECOUNT: Узлы с текущей конфигурацией в исправном состоянии, доступном для планирования
• UPDATEDMACHINECOUNT: Узлы, применившие текущую конфигурацию
• DEGRADEDMACHINECOUNT: Узлы, помеченные как degraded или не поддающиеся согласованию

В этом примере все три узла control plane имеют актуальное состояние, а пул worker обновляется — два узла уже завершили обновление, и один находится в процессе.

Получить подробную информацию о пуле:

kubectl describe machineconfigpool worker

Просмотреть все MachineConfig:

kubectl get machineconfig

Пример вывода:

NAME                    IGNITIONVERSION  AGE
00-master               3.4.0            3h2m
00-worker               3.4.0            3h2m
rendered-master-ccb     3.4.0            1h12m
rendered-worker-bad     3.4.0            1h20m

Просмотреть конкретную конфигурацию:

kubectl describe machineconfig 00-master

Проверить состояние отдельного узла:

kubectl get node -o custom-columns=NODE:.metadata.name,DESIRED:.metadata.annotations."machineconfiguration\.alauda\.io/desiredConfig",CURRENT:.metadata.annotations."machineconfiguration\.alauda\.io/currentConfig",STATE:.metadata.annotations."machineconfiguration\.alauda\.io/state"

Пример вывода:

NODE              DESIRED                                    CURRENT                                    STATE
192.168.132.216   rendered-master-98db9ca4f4b4cd             rendered-master-98db9ca4f4b4cd             Degraded
192.168.135.83    rendered-worker-05f27341ba49cf86dc4b      rendered-master-e08d9cab50e383             Working
192.168.134.99    rendered-worker-05f27341ba49cf86dc4b      rendered-worker-05f27341ba49cf86dc4b      Done

Справка по состояниям узла:

• NODE: Идентификатор узла
• DESIRED: Целевая конфигурация для узла
• CURRENT: Текущая примененная конфигурация
• STATE: Состояние конфигурации
  • Done: Узел в исправном состоянии, значения desired и current совпадают
  • Working: Узел обновляется (current ≠ desired)
  • Degraded: Обнаружено расхождение конфигурации или сбой применения — проверьте журналы, чтобы определить первопричину