• Русский
  • Обзор

    Как работает Machine Configuration

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

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

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

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

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

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

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

    Ключевые понятия

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

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

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

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

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

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

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

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

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

    Важно: Избегайте ручных изменений узлов — они могут привести к конфликтам конфигураций.

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

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

    systemd Units
    Определение новых сервисов systemd или расширение существующих дополнительными настройками.

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

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

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

    1. Cordon — пометить узел как недоступный для новых задач
    2. Drain — завершить текущие задачи и переназначить их на другие узлы
    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

    Просмотрите все MachineConfigs:

    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: Узел здоров, желаемая и текущая конфигурации совпадают
      • Working: Узел обновляется (текущая ≠ желаемая)
      • Degraded: Обнаружено отклонение конфигурации или ошибка применения — проверьте логи для выяснения причины