Product SiteDocumentation Site

Альт Оркестрация 11.0

Документация

Руководство администратора

Редакция июль, 2026

Юридическое уведомление

Данный документ распространяется на условиях свободной лицензии FDL (Free Documentation License) версии 1.3.
Данный документ не содержит текста, помещаемого на первой или последней странице обложки. Данный документ не содержит неизменяемого текста.

Аннотация

Названия компаний и продуктов, встречающихся в руководстве, могут являться торговыми знаками соответствующих компаний.
Данное руководство соответствует текущему состоянию сведений, но какие-либо окончательные правки могли не попасть в него. В случае обнаружения ошибок и неточностей в руководство вносятся изменения.
I. Что такое Альт Оркестрация?
1. Что такое Альт Оркестрация
2. Что такое системы Альт
2.1. ALT Linux Team
2.2. Сизиф
2.3. Что такое одиннадцатая платформа
2.3.1. Основные новшества одиннадцатой платформы
II. Развертывание кластера
3. Требования к аппаратному обеспечению
4. Быстрый старт
5. Image Factory (генератор образов ALT Orchestra)
5.1. Веб-интерфейс Image Factory
5.2. Конфигурирование и генерация ссылок на артефакты
5.2.1. Выбор типа разворачивания
5.2.2. Выбор версии ALT Orchestra
5.2.3. Выбор типа архитектуры и secureboot
5.2.4. Выбор системных расширений
5.2.5. Настройка параметров ядра
5.2.6. Генерация образа
5.3. HTTP Frontend API
5.3.1. Создание новой схемы образа
5.3.2. Загрузка образов
5.3.3. Список версий ALT Orchestra
5.3.4. Список системных расширений
5.4. PXE Frontend API
5.5. Реестр контейнеров (OCI Registry Frontend API)
5.5.1. Получение открытого ключа для проверки образов
6. Подготовка среды установки (загрузка с ISO-образов)
6.1. Подготовка рабочего места администратора
6.2. Создание ВМ в PVE
6.3. Создание ВМ в VirtualBox
6.4. Создание ВМ в libvirt
6.5. Установка на физический сервер
6.5.1. Запись ISO на USB-накопитель
6.5.2. Загрузка ALT Orchestra с USB
7. Установка ALT Orchestra с использованием Image Factory по сети (iPXE)
7.1. Настройка сервера вручную
7.1.1. Настройка сервера сетевой загрузки
7.1.2. Конфигурация iPXE-скрипта
7.1.3. Размещение ядра и initramfs
7.2. Начальная загрузка машины с iPXE
8. Развертывание базового кластера
8.1. Запуск узлов
8.1.1. Настройка сети
8.2. Подготовка переменных окружения
8.3. Генерация конфигурации кластера
8.4. Настройка конфигурации узлов
8.4.1. Проверка оборудования узлов
8.4.2. Ручное редактирование конфигурационных файлов
8.4.3. Использование патчей конфигурации
8.4.4. Инициализация узлов
8.4.5. Получение kubeconfig
8.4.6. Проверка работоспособности кластера
8.5. Тестовое развёртывание Deployment nginx
8.6. Сброс машины
9. Проверка и диагностика кластера
9.1. Проверка состояния системных служб
9.2. Комплексная проверка состояния кластера
9.3. Просмотр статистики использования ресурсов
9.4. Проверка соответствия Kubernetes (Conformance)
III. Специальные сценарии развертывания
10. Развертывание кластера в закрытом контуре
10.1. Подготовка инфраструктурного стенда
10.1.1. Установка пакетов
10.1.2. Настройка сетевых интерфейсов
10.1.3. Настройка DHCP-сервера
10.1.4. Настройка DNS
10.1.5. Настройка NTP
10.1.6. Настройка прокси-кешей контейнерных образов
10.1.7. Настройка Discovery Service RS
10.2. Развертывание кластера
10.2.1. Получение дисков и подготовка образов
10.2.2. Подготовка конфигурации кластера
10.2.3. Применение конфигурации и инициализация кластера
10.2.4. Установка Cilium
10.2.5. Проверка кластера
10.3. Ручное обновление кластера
11. Загрузка в режиме Secure Boot на платформах UEFI
11.1. Secure Boot с образами ALT Orchestra
11.2. Настройка среды установки
11.2.1. Особенности установки на PVE
11.3. Загрузка ALT Orchestra в режиме Secure Boot
11.3.1. Проверка состояния Secure Boot
11.3.2. Конфигурация только Secure Boot (без TPM)
11.3.3. Настройка шифрования диска с использованием TPM
11.4. Обновление ALT Orchestra
11.5. Шифрование диска с использованием TPM
11.6. Другие варианты загрузки
11.7. Secure Boot с пользовательскими ключами
11.7.1. Генерация ключей
11.7.2. Генерация загрузочных образов с Secure Boot
12. Отказоустойчивый кластер
12.1. Топология
12.2. Точка доступа Kubernetes API
12.3. Развертывание кластера
12.3.1. Подготовка конфигураций
12.3.2. Применение конфигураций
12.3.3. Настройка talosconfig
12.3.4. Bootstrap etcd
12.3.5. Получение kubeconfig
12.3.6. Проверка кластера
12.4. Работа с отказоустойчивым кластером
12.4.1. Хранение чувствительных файлов
13. Миграция Kubernetes-кластера на ALT Orchestra
13.1. Требования
13.2. Тестовая среда
13.3. Подготовка переменных
13.4. Генерация секретов из PKI существующего кластера
13.5. Генерация конфигураций ALT Orchestra
13.6. Перенос параметров kube-apiserver
13.7. Отключение KubePrism
13.8. Добавление первого узла Control Plane ALT Orchestra
13.9. Переключение endpoint на новый узел Control Plane
13.10. Переключение существующих Worker-узлов
13.11. Вывод существующих узлов Control Plane
13.12. Добавление новых Worker-узлов ALT Orchestra
13.13. Вывод существующих Worker-узлов
13.14. Обновление Kubernetes после миграции
IV. Управление кластером
14. Управление узлами
14.1. Конфигурация и управление
14.2. Добавление узла в кластер ALT Orchestra
14.2.1. Добавление управляющего узла (Control Plane)
14.2.2. Добавление рабочего узла (worker)
14.2.3. Проверка состояния узлов
14.3. Удаление узла из кластера ALT Orchestra
14.4. Выполнение рабочих нагрузок на узлах плоскости управления
14.5. Управление PKI и сроками действия сертификатов
14.5.1. Проверка сертификатов Kubernetes
14.5.2. Генерация нового talosconfig
14.6. Управление конфигурацией узла ALT Orchestra
14.6.1. Применение конфигурации
14.6.2. Редактирование текущей конфигурации
14.6.3. Обновление конфигурации (JSON Patch / YAML Patch)
14.6.4. Восстановление после сбоев загрузки узла
14.7. Системные расширения
14.7.1. Установка системных расширений
14.7.2. Отключение неиспользуемых модулей платформы
14.7.3. Создание системных расширений
14.7.4. Просмотр установленных расширений
14.8. Ядро
14.8.1. Параметры командной строки
14.8.2. Параметры, специфичные для ALT Orchestra
15. Интерактивная панель мониторинга кластера
16. Журналирование и аудит
16.1. Работа с журналами ALT Orchestra
16.1.1. Просмотр журналов
16.1.2. Отправка журналов
16.2. Аудит событий Kubernetes API
16.2.1. Просмотр параметров аудита kube-apiserver
16.2.2. Проверка политики аудита
16.2.3. Проверка записей аудита
16.2.4. Изменение уровня аудита Kubernetes API
16.2.5. Проверка изменений в логах
17. Обновление ALT Orchestra
17.1. Поддерживаемые пути обновления
17.2. Обновление узла
17.3. Последовательность обновления узла
V. CNI (сетевая подсистема Kubernetes)
18. Flannel
19. Cilium
19.1. Подготовка конфигурации машины
19.2. Установка с помощью Helm
19.3. Проверка работы сети
20. Пользовательское развертывание CNI
20.1. Манифест по URL
20.2. Локальный манифест
VI. Управление хранением данных и дисками
21. Шифрование системных дисков на уровне ОС
21.1. Шифрование раздела STATE
21.2. Шифрование раздела EPHEMERAL
21.3. Поддерживаемые методы шифрования
21.4. Конфигурация
21.5. Ключи шифрования
21.6. Ротация ключей
21.7. Переход между зашифрованным и незашифрованным состоянием
21.7.1. Раздел EPHEMERAL
21.7.2. Раздел STATE
22. Управление дисками
22.1. Список дисков
22.2. Обнаружение томов
22.3. Управление томами
22.3.1. Конфигурация
22.3.2. Состояние
22.4. Машинная конфигурация
22.4.1. Выбор диска (Disk Selector)
22.4.2. Минимальный и максимальный размер
VII. Конечная точка доступа Kubernetes API
23. Выделенный балансировщик нагрузки
24. DNS-записи
25. Работа с Virtual (Shared) IP
25.1. Требования
25.2. Добавление VIP
25.3. Проверка работы VIP
25.4. Удаление VIP
25.5. Предостережения
25.6. Отказоустойчивость VIP-адреса
25.7. Влияние на рабочую нагрузку
VIII. Шифрование секретов Kubernetes
26. Механизм Encryption at Rest
27. Настройка шифрования в ALT Orchestra
28. Проверка шифрования секретов
29. Внешние хранилища секретов
IX. Архитектура ALT Orchestra
30. Разделы файловой системы
31. Файловая система ALT Orchestra
32. Компоненты ALT Orchestra
32.1. apid
32.2. containerd
32.3. machined
32.4. kernel
32.5. trustd
32.6. udevd
33. Службы обнаружения узлов
33.1. Конфигурация реестров обнаружения
33.1.1. Реестр Kubernetes
33.1.2. Реестр служб (Service Registry)
33.2. Определения ресурсов
33.2.1. Идентификаторы
33.2.2. Филиалы (Affiliates)
33.2.3. Участник (Member)
X. Жизненный цикл кластера
34. Загрузка начальной системы
35. Инициализация системы
36. Генерация конфигурационных файлов
37. Развёртывание узлов
38. Развёртывание узла с использованием образа installer
39. Ожидание развертывания кластера, генерация файла конфигурации kubeconfig
40. Ожидание подъема Kubernetes-кластера
XI. Техническая поддержка продуктов «Базальт СПО»
41. Покупателям нашей продукции
42. Пользователям нашей продукции

Часть I. Что такое Альт Оркестрация?

Глава 1. Что такое Альт Оркестрация

Альт Оркестрация (ALT Orchestra) — это специализированная операционная система для организации Kubernetes-кластеров и построения контейнерной инфраструктуры.
Архитектура ОС включает только компоненты и службы, необходимые для управления Kubernetes-кластерами. Образ ОС имеет небольшой размер, что обеспечивает низкое потребление системных ресурсов и существенно снижает поверхность атаки.
Минимальный набор компонентов и отсутствие пакетного менеджера уменьшают потенциальную площадь уязвимостей. В системе реализованы интеграция с TPM — аппаратным модулем для обеспечения безопасности данных и защиты системы от несанкционированного доступа, шифрование дисков и безопасная загрузка.
Управление системой осуществляется через API. Традиционный доступ через shell и SSH отсутствует. Такой подход снижает риск компрометации учетных записей и эксплуатации уязвимостей, связанных с удалённым доступом, а также обеспечивает единообразное управление конфигурацией узлов.
Для управления узлами ALT Orchestra используется API-инструмент talosctl, который позволяет выполнять операции настройки, диагностики и обслуживания операционной системы. Управление Kubernetes-кластером выполняется стандартными средствами Kubernetes, включая API Kubernetes и инструменты командной строки, такие как kubectl.
Процесс обновления реализован как единая неделимая операция. Это исключает риск получения частично обновлённой или неработоспособной системы и гарантирует, что состояние любой ноды в кластере всегда будет предсказуемым и соответствующим известному рабочему состоянию.
Основные функциональные возможности:
  • установка:
    • возможность установки на физические среды (bare metal);
    • возможность установки платформы на bare metal с использованием PXE;
    • возможность установки в закрытом контуре без доступа к интернету;
    • возможность установки на виртуальные среды. Поддерживаются VMWare, OpenStack, zVirt, PVE;
    • поддержка загрузки образа платформы на системах UEFI в режиме SecureBoot;
  • управляемость и мониторинг:
    • наблюдение процесса обновления и автоматическая пауза при возникновении ошибок;
    • поддержка единой точки управления несколькими кластерами;
    • наличие собственного CLI для упрощения управления платформой (talosctl);
    • возможность управления обновлением Kubernetes-кластера отдельно от обновления платформы через UI или CLI;
  • безопасность:
    • аудит событий Kubernetes API;
    • фильтрация трафика внутри кластера (поддержка NetworkPolicy);
    • фильтрация трафика на уровне L7 внутри кластера;
    • использование статических групп пользователей в кластере;
    • использование внешнего провайдера аутентификации (LDAP/AD/OIDC);
    • централизованная RBAC для нескольких кластеров;
    • настройка ролевой модели доступа на основе групп и атрибутов пользователя;
    • ограничение доступа пользователей к определенным namespace;
    • использование сервисной учетной записи для установки прикладного ПО в платформу;
    • использование политик безопасности Kubernetes (Pod Security Standards);
    • использование политик безопасности для безопасной работы прикладного ПО;
    • платформа не хранит секреты в базе etcd в открытом виде. Возможна настройка внешнего хранилища (Openbao);
  • автомасштабирование и надежность:
    • балансировка нагрузки контейнеров между узлами кластера;
    • поддержка режима высокой доступности (High Availability, HA) для компонентов кластера. Control Рlane переживает отказ узла без потери API. Master-нода может быть заменена;
    • автоматический перезапуск прикладного ПО при изменении Secret/ConfigMap;
    • поддержка автоматического масштабирования кластера (автоматическое добавление/удаление узлов) при изменении нагрузки (Cluster Autoscaler: при росте нагрузки автоматически добавляет worker-ноды, при снижении — удаляет);
    • поддержка горизонтального автомасштабирования подов (Horizontal Pod Autoscaler): автоматически увеличивает/уменьшает число реплик приложения на основе метрик (CPU, память, кастомные метрики);
    • поддержка вертикального автомасштабирования подов (Vertical Pod Autoscaler): динамически корректирует requests/limits контейнеров. Позволяет сервису получать больше памяти при пиковых нагрузках и возвращать ресурсы после снижения нагрузки;
    • самовосстановление компонентов control plane (платформа автоматически перезапускает упавшие apiserver/etcd);
    • автоматическое переключение при отказе (Node Failover Test).

Глава 2. Что такое системы Альт

2.1. ALT Linux Team

Команда ALT Linux (https://www.altlinux.org/ALT_Linux_Team) — это интернациональное сообщество, насчитывающее более 300 разработчиков свободного программного обеспечения.

2.2. Сизиф

Sisyphus (https://packages.altlinux.org) — наш ежедневно обновляемый банк программ (часто называемый репозиторием). Поддерживаемая ALT Linux Team целостность Sisyphus, оригинальная технология сборки программ и утилита apt-get позволяют пользователям легко обновлять свои системы и быть в курсе актуальных новинок мира свободных программ.
Ежедневно изменяющийся репозиторий содержит самое новое программное обеспечение со всеми его преимуществами и недостатками (иногда ещё неизвестными). Поэтому, перед обновлением вашей системы из Sisyphus, мы советуем взвесить преимущества новых возможностей, реализованных в последних версиях программ, и вероятность возникновения неожиданностей в работе с ними (https://www.altlinux.org/Sisyphus_changes).
Разработка Sisyphus полностью открыта. У нас нет секретных изменений кода и закрытого тестирования с подписками о неразглашении. Всё, что мы сделали сегодня, завтра вы найдёте в сети. По сравнению с другими аналогичными банками программ (Debian unstable, Mandriva Cooker, PLD, Fedora), в Sisyphus есть немало самобытного. Особое внимание уделяется защите системы, локализации на русский язык, полноте и корректности зависимостей.
Название Sisyphus (Сизиф) заимствовано из греческой мифологии. С кропотливым Сизифом, непрерывно закатывающим в гору камни, команду ALT Linux Team объединяет постоянная работа над усовершенствованием технологий, заложенных в репозиторий.
Sisyphus, в первую очередь, — открытая лаборатория решений. Если вам это интересно, если вы хотите дополнить Sisyphus новыми решениями, если вы считаете, что можете собрать какую-то программу лучше — присоединяйтесь к проекту ALT Linux Team (https://www.altlinux.org/Join).

2.3. Что такое одиннадцатая платформа

Как уже говорилось ранее, Sisyphus является часто обновляемым репозиторием, скорее предназначенным для разработчиков. Решением для тех пользователей, которым стабильность и предсказуемость работы системы важнее расширенной функциональности (а это в первую очередь начинающие и корпоративные пользователи), являются дистрибутивы Альт. Такие дистрибутивы базируются на стабильном срезе репозитория Sisyphus. Эти срезы называются платформами.
Одиннадцатая платформа (p11) была создана в июне 2024 года и её поддержка продлится до июля 2027 года.

2.3.1. Основные новшества одиннадцатой платформы

  • Одиннадцатая платформа основана на ядре Linux 6.12 (LTS) с расширенной поддержкой современного оборудования: процессорных архитектур Intel, включая Intel Meteor Lake, Intel Xeon Sapphire Rapids, AMD Ryzen 7000 (Zen 4) и EPYC Genoa; аппаратных интерфейсов — PCI Express Gen5, USB4, Thunderbolt 4, Wi-Fi 6/6E, NVMe 1.4/2.0; улучшенной поддержкой виртуализации;
  • Программное обеспечение на одиннадцатой платформе использует обновленный OpenSSL 3.1. Платформа сохраняет поддержку OpenSSL 1.1 для совместимости с устаревшим ПО;
  • Произошел переход на Python 3.12;
  • Добавлены PHP 8.3 и 8.4;
  • Системный интерпретатор сценариев /bin/sh теперь основан на Bash 5.2;
  • Обновлены основные системные библиотеки и компиляторы: glibc 2.38, компилятор GCC 13 и LLVM/Clang 19;
  • Пакет systemd обновлён до версии 255;
  • Подсистема начальной загрузки установщика propagator заменена на altboot;
  • Основным фрэймворком приложений графической подсистемы стал Qt6, с поддержкой Qt5 для обратной совместимости приложений. Qt6 в качестве основного стека также использует системный установщик;
  • Включена поддержка нового Kerberos 1.21, полностью совместимого с Samba 4.20+. В дистрибутивах 11 платформы также доступны и ключевые изменения Samba 4.20+;
  • Существенно обновлён Альтератор в качестве Центра Управления Системой — новый интерфейс, взаимодействие с D-Bus, модульная архитектура. Новый Альтератор поддерживает модули предыдущих версий;
  • ALT Diagnostic Tool — графическая утилита диагностики ОС. ADT использует заранее подготовленный набор проверок, предоставляет возможность пользователю выполнить тесты без дополнительных привилегий и единый вид отчета по проверкам;
  • Копидел — средство тиражирования установленной системы (alterator-kopidel);
  • Платформа доступна для архитектур x86_64 и ARM64.

Часть II. Развертывание кластера

Содержание

3. Требования к аппаратному обеспечению
4. Быстрый старт
5. Image Factory (генератор образов ALT Orchestra)
5.1. Веб-интерфейс Image Factory
5.2. Конфигурирование и генерация ссылок на артефакты
5.2.1. Выбор типа разворачивания
5.2.2. Выбор версии ALT Orchestra
5.2.3. Выбор типа архитектуры и secureboot
5.2.4. Выбор системных расширений
5.2.5. Настройка параметров ядра
5.2.6. Генерация образа
5.3. HTTP Frontend API
5.3.1. Создание новой схемы образа
5.3.2. Загрузка образов
5.3.3. Список версий ALT Orchestra
5.3.4. Список системных расширений
5.4. PXE Frontend API
5.5. Реестр контейнеров (OCI Registry Frontend API)
5.5.1. Получение открытого ключа для проверки образов
6. Подготовка среды установки (загрузка с ISO-образов)
6.1. Подготовка рабочего места администратора
6.2. Создание ВМ в PVE
6.3. Создание ВМ в VirtualBox
6.4. Создание ВМ в libvirt
6.5. Установка на физический сервер
6.5.1. Запись ISO на USB-накопитель
6.5.2. Загрузка ALT Orchestra с USB
7. Установка ALT Orchestra с использованием Image Factory по сети (iPXE)
7.1. Настройка сервера вручную
7.1.1. Настройка сервера сетевой загрузки
7.1.2. Конфигурация iPXE-скрипта
7.1.3. Размещение ядра и initramfs
7.2. Начальная загрузка машины с iPXE
8. Развертывание базового кластера
8.1. Запуск узлов
8.1.1. Настройка сети
8.2. Подготовка переменных окружения
8.3. Генерация конфигурации кластера
8.4. Настройка конфигурации узлов
8.4.1. Проверка оборудования узлов
8.4.2. Ручное редактирование конфигурационных файлов
8.4.3. Использование патчей конфигурации
8.4.4. Инициализация узлов
8.4.5. Получение kubeconfig
8.4.6. Проверка работоспособности кластера
8.5. Тестовое развёртывание Deployment nginx
8.6. Сброс машины
9. Проверка и диагностика кластера
9.1. Проверка состояния системных служб
9.2. Комплексная проверка состояния кластера
9.3. Просмотр статистики использования ресурсов
9.4. Проверка соответствия Kubernetes (Conformance)

Глава 3. Требования к аппаратному обеспечению

В таблице Минимальные требования представлены минимальные системные требования, а в таблице Рекомендуемые требования — рекомедуемые. Эти требования аналогичны требованиям Kubernetes.

Таблица 3.1. Минимальные требования

Роль ноды
ОЗУ
ЦП
Системный диск
Control Plane
2 ГБ
2
10 ГБ
Worker
2 ГБ
1
10 ГБ

Таблица 3.2. Рекомендуемые требования

Роль ноды
ОЗУ
ЦП
Системный диск
Control Plane
4 ГБ
4
100 ГБ
Worker
2 ГБ
2
100 ГБ

Примечание

Для ОС требуется менее 100 МБ дискового пространства, однако раздел EPHEMERAL используется для хранения извлеченных образов, рабочих каталогов контейнеров и т.д. Поэтому минимальный размер диска должен составлять не менее 10 ГБ (рекомендуется 100 ГБ). Следует отметить, что ОС полностью контролирует диск, на котором она установлена, включая управление таблицей разделов для обновлений на основе образов. В связи с этим нельзя использовать оставшуюся часть диска для создания отдельных разделов под рабочие нагрузки.
Рекомендуется устанавливать ОС на отдельный небольшой диск и использовать другие диски для хранения данных.

Глава 4. Быстрый старт

Развертывание кластера ALT Orchestra включает подготовку загрузочных образов, генерацию конфигурации, применение её к узлам и последующую инициализацию Kubernetes-кластера.
Независимо от платформы развертывания (физические серверы, виртуальные машины или облачная инфраструктура), настройка кластера выполняется по единой схеме:
  1. Загрузка узлов с образом ALT Orchestra.
  2. Генерация конфигурации и секретов.
  3. Применение конфигурации к узлам.
  4. Настройка клиента talosctl.
  5. Инициализация Kubernetes-кластера.
  6. Получение kubeconfig для работы с Kubernetes.
Общая последовательность действий при развертывании кластера:
  1. Установить утилиту talosctl на рабочую станцию администратора.
  2. Загрузить образ ALT Orchestra из Image Factory.
  3. Запустить узлы с использованием ISO-образа или PXE-загрузки.
  4. Подготовить конфигурацию кластера:
    • сгенерировать секреты;
    • сгенерировать базовые конфигурационные файлы;
    • при необходимости создать patch-файлы для настройки сети, hostname и дисков.
  5. Применить конфигурацию к control-plane и worker-узлам.
  6. Настроить локальный клиент talosctl:
    • указать endpoint;
    • указать node;
    • сохранить talosconfig.
  7. Выполнить bootstrap control-plane-узла и инициализировать Kubernetes-кластер.
  8. Получить kubeconfig для управления Kubernetes.
  9. При необходимости установить CNI-плагин (например, Cilium) и дополнительные компоненты кластера.
После завершения этих действий кластер ALT Orchestra будет готов к эксплуатации.
Подробное описание каждого этапа приведено в следующих разделах документации.
В таблице Матрица поддержки приведены поддерживаемые версии ALT Orchestra, talosctl, Kubernetes, а также поддерживаемые аппаратные архитектуры. Перед развертыванием кластера рекомендуется убедиться, что используемые версии компонентов соответствуют поддерживаемой матрице.

Таблица 4.1. Матрица поддержки

Версия ALT Orchestra
Версия Talos
Kubernetes
Архитектура
11.0
1.12
1.35, 1.34, 1.33, 1.32, 1.31, 1.30
amd64, arm64

Примечание

Для кластеров Kubernetes версий 1.32, 1.31, 1.30 необходимо использовать образы kube-proxy из официального репозитория Kubernetes (upstream), так как образы этого компонента из registry.altlinux.org несовместимы с ядром версии 6.18, используемым в $DISTRO;.

Примечание

Актуальные версии образа imager и доступные версии ALT Orchestra можно посмотреть:

Глава 5. Image Factory (генератор образов ALT Orchestra)

Генератор образов (Image Factory) — это сервис для генерации кастомизированных образов ALT Orchestra на основе заданных схем. Он поддерживает различные форматы образов (ISO, дисковые образы, UKI, контейнеры установщика) и интерфейсы (HTTP, PXE, OCI-реестр).
Предоставляются следующие ресурсы (артефакты):
  • ISO;
  • ядро, initramfs и командная строка ядра;
  • UKI;
  • образы дисков в различных форматах (например, AWS, GCP, VMware и т. д.);
  • OCI-образы установщика (контейнеры для Docker/Podman).
Ссылки на различные модели доступны в пользовательском интерфейсе Image Factory. Веб-интерфейс Image Factory доступен по адресу https://factory.altlinux.space.
Генератор образов ALT Orchestra
Сервер Image Factory (https://factory.altlinux.space/) предоставляет загрузочные образы. Эти образы можно дополнительно настроить для конкретного варианта использования:
  • добавление системных расширений (extensions);
  • настройка параметров загрузки (параметры ядра);
  • использование настраиваемого содержимого META, например, для конфигурации сети Metal;
  • генерация образов Secure Boot, подписанных настраиваемым ключом.
Каждый вариант развёртывания имеет собственный идентификатор (schematicID), который определяет состав и параметры образа.
Минимальный вариант (без расширений) имеет стандартный (встроенный) идентификатор 376567988ad370138ad8b2698212367b8edcb69b5fd68c80be1f2ec7d603b4ba.
Image Factory всегда добавляет «виртуальное» системное расширение с версией, соответствующей идентификатору схемы, используемой для генерации образа. Таким образом, для любого работающего экземпляра ALT Orchestra идентификатор схемы можно определить, просмотрев список системных расширений:
$ talosctl get extensions
Ожидаемый вывод:
NODE           NAMESPACE  TYPE            ID  VERSION   NAME               VERSION
192.168.0.200  runtime    ExtensionStatus  0   1         intel-ucode        20250512
192.168.0.200  runtime    ExtensionStatus  1   1         util-linux-tools   v2.39.2
192.168.0.200  runtime    ExtensionStatus  2   1         schematic          80d5f9d0991e825b84617b4f2ce25b840050e3ee6a83647ac1bc0a559cf90962
Ожидаемый вывод для базового образа:
NODE           NAMESPACE  TYPE             ID   VERSION   NAME        VERSION
192.168.0.200  runtime    ExtensionStatus  0    1         schematic   376567988ad370138ad8b2698212367b8edcb69b5fd68c80be1f2ec7d603b4ba
Интерфейсы Image Factory:
  • HTTP — используется для загрузки готовых образов (например, ISO или образов дисков);
  • PXE — используется для загрузки машин без ОС (PXE-скрипт ссылается на ядро и initramfs из HTTP-интерфейса);
  • реестр контейнеров — используется для получения настроенных образов установщика (для первоначальной установки и обновлений ALT Orchestra).
Существует два способа создания загрузочных ресурсов ALT Orchestra:
  • использование сервиса Image Factory (рекомендуется);
  • ручная сборка с использованием утилиты создания образов (imager).
Image Factory проще в использовании, но он позволяет создавать образы только для официальных выпусков ALT Orchestra.

5.1. Веб-интерфейс Image Factory

Image Factory предоставляет интерактивный веб-интерфейс для упрощённой генерации кастомизированных образов ALT Orchestra. Все операции в UI эквивалентны операциям API (см. HTTP Frontend API).

5.2. Конфигурирование и генерация ссылок на артефакты

5.2.1. Выбор типа разворачивания

Генератор образов ALT Orchestra
На главной (корневой) странице Image Factory доступны следующие варианты типов развёртывания:
  • Физический сервер — подходит для физических машин x86-64 и arm64, а также для виртуальных машин;
  • Облачный сервер — совместим с AWS, GCP, Azure, VMWare, Equinix Metal и другими платформами, включая домашние кластеры, такие как PVE.

5.2.2. Выбор версии ALT Orchestra

На следующем этапе можно выбрать версию:
Выбор версии ALT Orchestra

Примечание

Настоятельно рекомендуется использовать стабильную версию ALT Orchestra (например, 11.0). Предрелизные версии подходят для тестирования, но не рекомендуются для промышленной эксплуатации.

5.2.3. Выбор типа архитектуры и secureboot

На следующем шаге необходимо указать архитектуру. Доступные следующие варианты:
  • amd64 (x86-64);
  • arm64 (ARMv8).
Архитектура машины
На этом шаге также можно указать, что нужно получить образы ALT Orchestra, подписанные официальным ключом «Базальт СПО». Для этого в окне выбора архитектуры необходимо включить переключатель SecureBoot (далее нужно будет выбрать тип загрузчика с поддержкой UEFI).
Переключатель SecureBoot

Примечание

Подробнее о загрузке в режиме Secure Boot см. в разделе Загрузка в режиме Secure Boot на платформах UEFI.

5.2.4. Выбор системных расширений

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

Таблица 5.1. Системные расширения

Расширение
Описание
crun
Альтернативная среда выполнения контейнеров, совместимая с OCI (обеспечивает запуск crun с использованием обработчика среды выполнения containerd)
util-linux-tools
Дополнительные системные утилиты из набора util-linux
intel-ucode
Микрокоды процессоров Intel для обновления CPU на этапе загрузки
btrfs
Поддержка файловой системы Btrfs и связанные утилиты
nvidia-container-toolkit
Набор инструментов для запуска контейнеров с поддержкой GPU NVIDIA
drbd
Распределённое блочное устройство для репликации данных между узлами
nonfree-kmod-nvidia
Проприетарные модули ядра NVIDIA для работы графических ускорителей
qemu-guest-agent
Гостевой агент QEMU (удобен при использовании облачных серверов или виртуальных сред)

5.2.5. Настройка параметров ядра

На данном этапе можно:
  • указать дополнительные параметры загрузки ядра (например, параметры конфигурации сетевых интерфейсов);
  • выбрать тип загрузчика.
Настройка параметров ядра
Допустимый синтаксис параметров загрузки ядра аналогичен синтаксису стандартной командной строки ядра Linux, например:
console=ttyS0,115200
Знак «-» перед параметром удаляет его из строки параметров по умолчанию (например, -console).
Следует учитывать, что данные настройки применяются только к начальному образу (ISO, PXE, дисковому образу) и игнорируются для installer-образов. Для изменения параметров командной строки ядра при установке или обновлении необходимо использовать поле machine.install.extraKernelArgs в конфигурации машины.
Доступны следующие типы загрузчика:
  • Авто — автоматически выбирает тип загрузчика на основе типа образа и архитектуры (рекомендуется);
  • Только UEFI — поддерживает современное оборудование с прошивкой UEFI (используется systemd-boot);
  • Только BIOS — поддерживает устаревшее оборудование и некоторые виртуальные машины (используется GRUB);
  • Двойная загрузка — универсальный образ с поддержкой BIOS и UEFI.

5.2.6. Генерация образа

После завершения конфигурации Image Factory генерирует уникальный schematicID, который представляет собой идентификатор конфигурации (customization) и сохраняется во внутреннем хранилище Image Factory.
Образы включают:
  • ISO-образы;
  • kernel;
  • initramfs;
  • подписи артефактов.
В веб-интерфейсе Image Factory отображается список ссылок для получения необходимых артефактов:
Список ссылок для получения артефактов
На момент отображения интерфейса генерация артефактов не выполняется — они создаются по запросу и кешируются.
При переходе по ссылке или обращении к Docker-образу installer (например, при развертывании кластера ALT Orchestra) Image Factory:
  • генерирует запрашиваемый артефакт;
  • размещает сгенерированный артефакт в одном из тегов образа;
  • передает его клиенту.
При повторных обращениях ранее сгенерированные артефакты извлекаются из кеша и повторно передаются клиенту.

5.3. HTTP Frontend API

5.3.1. Создание новой схемы образа

Конечная точка:
POST /schematics
создает новую схему образа на основе предоставленной конфигурации.
Тело запроса должно содержать YAML- или JSON-конфигурацию с опциональными разделами, представленными в таблице Основные параметры (customization).

Таблица 5.2. Основные параметры (customization)

Параметр
Тип
Описание
extraKernelArgs
[]string
Дополнительные аргументы ядра (например, console=ttyS0,115200)
meta
[]Meta
Метаданные для инициализации ALT Orchestra (пары ключ-значение в hex-формате)
systemExtensions
object
Системные расширения, включаемые в образ
secureboot
object
Настройки Secure Boot (только для совместимых образов)
Пример запроса:
  1. Создать конфигурацию (файл custom.yaml):
    customization:
        extraKernelArgs:
          - console=ttyS0,115200
        systemExtensions:
            officialExtensions:
                - alt-orchestra/intel-ucode
                - alt-orchestra/util-linux-tools
    

    Примечание

    Все поля опциональны. Пустой запрос ({}) создаст схему по умолчанию.
  2. Отправить запрос в Image Factory, чтобы получить ее идентификатор:
    $ curl -X POST --data-binary @custom.yaml  \
     https://factory.altlinux.space/schematics
    
    Ответ:
        {"id":"60686148f84df043380005f117452c396347e3405e856aa70ba02318a9ab2a99"}
    
    Возвращаемый id — уникальный хеш схемы, используемый для загрузки образов.
    Известные идентификаторы схем:
    • 376567988ad370138ad8b2698212367b8edcb69b5fd68c80be1f2ec7d603b4ba — схема по умолчанию (без кастомизации).

5.3.2. Загрузка образов

Конечная точка получения образов:
GET /image/:schematic/:version/:path
Загружает загрузочный образ ALT Orchestra с указанной схемой и версией.
Параметры запроса:
  • :schematic — идентификатор схемы, возвращаемый запросом POST /schematics;
  • :version — версия ALT Orchestra (например, v11.0);
  • :path — путь к образу, определяющий тип и формат загружаемого артефакта.
Формирование :path (см. таблицу Поддерживаемые значения :path):
  • <arch> — архитектура системы (amd64 или arm64);
  • <platform> — платформа ALT Orchestra (например, metal или aws);
  • <version> — версия продукта (используется в имени файлов);
  • secureboot — опциональный суффикс для образов с поддержкой Secure Boot.
Общий формат имени файлов:
alt-orchestra-<version>-<platform>-<arch>[-secureboot].<format>

Примечание

Имя файла включает префикс продукта (например, alt-orchestra-<version>), платформу и архитектуру.

Таблица 5.3. Поддерживаемые значения :path

Формат
Тип образа
Пример
kernel-<arch>
Необработанный образ ядра
kernel-amd64
cmdline-<platform>-<arch>[-secureboot]
Командная строка ядра
cmdline-metal-amd64
initramfs-<arch>.xz
Образ initramfs (включая системные расширения, если они настроены)
initramfs-amd64.xz
<platform>-<arch>[-secureboot].iso
ISO-образ
metal-amd64.iso
<platform>-<arch>[-secureboot]-uki.efi
Образ UEFI UKI (совместим с Secure Boot)
metal-amd64-secureboot-uki.efi
installer-<arch>[-secureboot].tar
Образ установщика ALT Orchestra для платформы metal (включая системные расширения, если они настроены)
installer-amd64.tar
metal-<arch>[-secureboot].raw.xz
Дисковый образ (XZ)
metal-amd64.raw.xz
metal-<arch>[-secureboot].raw.qcow2
Дисковый образ (QCOW2)
metal-amd64.raw.qcow2
Примеры запросов:
  • загрузка дискового образа:
    $ curl -LO https://factory.altlinux.space/image/376567988ad370138ad8b2698212367b8edcb69b5fd68c80be1f2ec7d603b4ba/v11.0/alt-orchestra-11.0-metal-amd64.qcow2
    
  • загрузка ISO-образа:
    $ curl -LO https://factory.altlinux.space/image/376567988ad370138ad8b2698212367b8edcb69b5fd68c80be1f2ec7d603b4ba/v11.0/alt-orchestra-11.0-metal-amd64.iso
    

5.3.3. Список версий ALT Orchestra

Конечная точка:
GET /versions
Возвращает список версий ALT Orchestra, доступных для создания образа.
Пример запроса:
$ curl -X GET https://factory.altlinux.space/versions
Пример ответа:
["v11.0"]

5.3.4. Список системных расширений

Конечная точка:
GET /version/:version/extensions/official
Возвращает список официальных системных расширений, доступных для указанной версии ALT Orchestra.
Параметры:
  • :version — версия ALT Orchestra, например v11.0.
Пример запроса:
$ curl -X GET https://factory.altlinux.space/version/v11.0/extensions/official | jq .
Пример вывода:
[
  {
    "name": "alt-orchestra/crun",
    "ref": "altlinux.space/alt-orchestra/crun:1.27",
    "digest": "sha256:6a71e16de2b55ea03e4ef60dc1e2620f808facdbb948a4a87fc57a2cf1290127",
    "author": "Basealt LLC",
    "description": "containerd's runtime handler crun\n"
  },
  {
    "name": "alt-orchestra/util-linux-tools",
    "ref": "altlinux.space/alt-orchestra/util-linux-tools:2.39.2",
    "digest": "sha256:d8d76085b5144655baee9a55ab9b1c7583de6eabaaedd5954c8c3c1499de2ecd",
    "author": "Basealt LLC",
    "description": "minimal util-linux package\n"
  },
  {
    "name": "alt-orchestra/intel-ucode",
    "ref": "altlinux.space/alt-orchestra/intel-ucode:20251111",
    "digest": "sha256:459538bdeb0564fa0ccc86232f8dc0ba82e6937e7cbd1a12df04c0092740330e",
    "author": "Basealt LLC",
    "description": "intel-ucode module\n"
  },
  {
    "name": "alt-orchestra/btrfs",
    "ref": "altlinux.space/alt-orchestra/btrfs:v11.0",
    "digest": "sha256:f5b98bc2cec6bce4b539a204e74b1bac4926c4c27364279a74514d25b85cd34a",
    "author": "Basealt LLC",
    "description": "btrfs filesystem\n"
  },
  {
    "name": "alt-orchestra/nvidia-container-toolkit",
    "ref": "altlinux.space/alt-orchestra/nvidia-container-toolkit:580.142.0-1.17.8",
    "digest": "sha256:6acf10587343018528744e712187668e85258bdee739f77236f0e7c031f3064f",
    "author": "Basealt LLC",
    "description": "nvidia runtime and it's dependencies using NVIDIA's runtime handler.\n"
  },
  {
    "name": "alt-orchestra/drbd",
    "ref": "altlinux.space/alt-orchestra/drbd:9.3.0-v11.0",
    "digest": "sha256:592f5a83c78d1c17333d406449b2953a903ccbe1342950a67605703016a96d13",
    "author": "Basealt LLC",
    "description": "system extension provides kernel module driver for DRBD\n"
  },
  {
    "name": "alt-orchestra/qemu-guest-agent",
    "ref": "altlinux.space/alt-orchestra/qemu-guest-agent:9.1.2",
    "digest": "sha256:fe82cf46923b1ce7f3b6ea07cee04a29d8d3ea5a2fbba1ec79fdb2c467b68a1f",
    "author": "Basealt LLC",
    "description": "qemu-guest-agent service\n"
  },
  {
    "name": "alt-orchestra/nonfree-kmod-nvidia",
    "ref": "altlinux.space/alt-orchestra/nonfree-kmod-nvidia:580.142.0-v11.0",
    "digest": "sha256:b966fbea6ad241f4d28f12b08a6068385226ef00bcd729e0339ab9a7d537795f",
    "author": "Basealt LLC",
    "description": "nvidia proprietary kernel modules\n"
  }
]

5.4. PXE Frontend API

PXE frontend предоставляет iPXE-скрипт, который автоматически загружает ALT Orchestra. Машина без устанволенной ОС должна быть настроена на загрузку по URL, предоставленному этим API, например:
https://factory.altlinux.space/pxe/376567988ad370138ad8b2698212367b8edcb69b5fd68c80be1f2ec7d603b4ba/v11.0/alt-orchestra-11.0-metal-amd64
Конечная точка:
GET /pxe/:schematic/:version/:path
Возвращает iPXE-скрипт, который загружает ALT Orchestra с указанной схемой, версией, архитектурой и платформой.
Параметры:
  • :schematic — идентификатор схемы, возвращаемый запросом POST /schematics;
  • :version — версия ALT Orchestra, например v11.0;
  • :path — путь в формате <platform>-<arch>[-secureboot] (например, metal-amd64).
Для схемы без Secure Boot возвращается следующий iPXE-скрипт:
#!ipxe
kernel http://factory.altlinux.space/image/:schematic/:version/kernel-<arch> <kernel-cmdline>
initrd http://factory.altlinux.space/image/:schematic/:version/initramfs-<arch>.xz
boot
Пример:
$ curl -X GET https://factory.altlinux.space/pxe/376567988ad370138ad8b2698212367b8edcb69b5fd68c80be1f2ec7d603b4ba/v11.0/alt-orchestra-11.0-metal-amd64
Ответ:
#!ipxe

imgfree
kernel https://factory.altlinux.space/image/376567988ad370138ad8b2698212367b8edcb69b5fd68c80be1f2ec7d603b4ba/v11.0/kernel-amd64 talos.platform=metal console=tty0 init_on_alloc=1 slab_nomerge pti=on consoleblank=0 nvme_core.io_timeout=4294967295 printk.devkmsg=on selinux=1
initrd https://factory.altlinux.space/image/376567988ad370138ad8b2698212367b8edcb69b5fd68c80be1f2ec7d603b4ba/v11.0/initramfs-amd64.xz
boot

5.5. Реестр контейнеров (OCI Registry Frontend API)

Образ установщика ALT Orchestra используется для первоначальной установки и обновлений. Он хранится в реестре OCI Image Factory и автоматически генерируется при первом запросе, если еще не существует.
Синтаксис:
$ podman pull <registry>/<platform>-installer[-secureboot]/<schematic>:<version>
Параметры:
  • <platform> — платформа;
  • secureboot — опциональный суффикс, указывающий на поддержку Secure Boot;
  • <schematic> — идентификатор схемы, возвращаемый запросом POST /schematics;
  • <version> — версия ALT Orchestra.
Эта команда извлекает образ установщика ALT Orchestra с указанной схемой и версией. Архитектура образа (amd64, arm64 и др.) определяется архитектурой системы, на которой выполняется команда podman docker pull.
Примеры:
  • для bare metal (физических серверов):
    $ podman pull \
      factory.altlinux.space/alt-orchestra-metal-installer/376567988ad370138ad8b2698212367b8edcb69b5fd68c80be1f2ec7d603b4ba:v11.0
    
  • для AWS:
    $ podman pull \
      factory.altlinux.space/alt-orchestra-aws-installer/376567988ad370138ad8b2698212367b8edcb69b5fd68c80be1f2ec7d603b4ba:v11.0
    

5.5.1. Получение открытого ключа для проверки образов

Конечная точка:
GET /oci/cosign/signing-key.pub
Возвращает открытый ключ в формате PEM, используемый для цифровой подписи официальных образов установщика ALT Orchestra.
Пример получения ключа:
$ curl -X GET https://factory.altlinux.space/oci/cosign/signing-key.pub
Ответ:
-----BEGIN PUBLIC KEY-----
MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEq2DB1eviFoHEcqKk+5wOXJ104XDP
P6sF7X9ddibyerutMvRY5zjxqVCZPRcTwVOZV49WmEIXia81JPgcEshkLA==
-----END PUBLIC KEY-----
Ключ можно использовать для проверки образов установщика с помощью cosign (пакет cosign должен быть установлен):
$ cosign verify --offline  \
  --insecure-ignore-tlog \
  --insecure-ignore-sct \
  --key signing-key.pub \
  factory.altlinux.space/<image>
Пример проверки образа::
$ wget https://factory.altlinux.space/oci/cosign/signing-key.pub

$ cosign verify --offline \
 --insecure-ignore-tlog \
 --insecure-ignore-sct \
 --key signing-key.pub \
factory.altlinux.space/alt-orchestra-metal-installer/376567988ad370138ad8b2698212367b8edcb69b5fd68c80be1f2ec7d603b4ba:v11.0
Ответ:
Verification for factory.altlinux.space/alt-orchestra-metal-installer/376567988ad370138ad8b2698212367b8edcb69b5fd68c80be1f2ec7d603b4ba:v11.0 --
The following checks were performed on each of these signatures:
  - The cosign claims were validated
  - The signatures were verified against the specified public key

[{"critical":{"identity":{"docker-reference":"127.0.0.1:5001/image-factory/metal-installer/376567988ad370138ad8b2698212367b8edcb69b5fd68c80be1f2ec7d603b4ba"},"image":{"docker-manifest-digest":"sha256:b4639acde912d59dda83427e47f83acf75cd5bf95ef59c38271cb2cf7c15366f"},"type":"cosign container image signature"},"optional":null}]
Подпись успешно проверена.

Глава 6. Подготовка среды установки (загрузка с ISO-образов)

Данный раздел содержит инструкции по подготовке рабочего места администратора и ВМ (физического сервера) к установке.

6.1. Подготовка рабочего места администратора

Примечание

Рабочее место администратора должно быть настроено на машине вне кластера, у которой будет доступ к нодам по IP, так как сами ноды не предоставляют доступ к системе по SSH.
Пакет с клиентской утилитой управления ОС ALT Orchestra установливается и обновляется на рабочей машине пользователя через пакетный менеджер.
На рабочем месте администратора установите пакет talosctl и дополнительную утилиту curl:
# apt-get install talosctl curl

Примечание

Для возможности выполнения команды kubectl должен быть установлен пакет kubernetes<Версия>-client, например kubernetes1.35-client.
Получите последнюю версию ISO из Image Factory: https://factory.altlinux.space (подробнее о Image Factory см. в разделе Image Factory (генератор образов ALT Orchestra)).
Загрузите полученный образ, например:
$ curl -OJ  \
 https://factory.altlinux.space/image/376567988ad370138ad8b2698212367b8edcb69b5fd68c80be1f2ec7d603b4ba/v11.0/alt-orchestra-11.0-metal-amd64.iso

6.2. Создание ВМ в PVE

Загрузите скачанный ISO-образ в хранилище:
Загрузка локального ISO-образа в хранилище
Или загрузите в хранилище ISO-образ непосредственно с https://factory.altlinux.space:
Загрузка образа с factory.altlinux.space
Далее необходимо создать одну ВМ в качестве узла управления и (при необходимости) дополнительные машины в качестве рабочих узлов.
Для создания ВМ нажмите кнопку Создать ВМ, расположенную в правом верхнем углу веб-интерфейса PVE.
Ресурсы ВМ следует назначить в соответствии с минимальными требованиями (см. табл. Минимальные требования).
На вкладке Общее укажите имя ВМ:
Вкладка Общее
На вкладке ОС выберите загруженный ISO-образ:
Вкладка ОС
На вкладке Система можно оставить значения по умолчанию.
Чтобы консоль работала в более высоком разрешении, на вкладке Система в выпадающем списке Видеокарта можно выбрать значение VirtIO-GPU:
Вкладка Система
На вкладке Диски укажите размер диска, остальные параметры можно оставить по умолчанию:
Вкладка Диски
На вкладке Процессор необходимо указать не менее 2 ядер и выбрать тип процессора:
Вкладка Процессор

Примечание

Для корректной работы ALT Orchestra в PVE требуется поддержка микроархитектуры x86-64-v2. В PVE v7 загрузка с типом процессора по умолчанию (kvm64) не работает. Для обеспечения совместимости можно:
  • добавить необходимые флаги процессора вручную после создания ВМ, добавив строку в файл конфигурации /etc/pve/qemu-server/<VMID>.conf:
    args: -cpu kvm64,+cx16,+lahf_lm,+popcnt,+sse3,+ssse3,+sse4.1,+sse4.2
  • установить в поле Тип значение host, если узел PVE поддерживает эти функции. В этом случае живая миграция ВМ будет недоступна.
На вкладке Память укажите не менее 2ГБ ОЗУ:
Вкладка Память
На вкладке Сеть можно оставить значения по умолчанию, убедившись, что используется мост:
Вкладка Сеть
Завершите создание ВМ, нажав кнопку Завершить на вкладке Подтвердить.
Повторите процесс создания ВМ для рабочих узлов (при необходимости).
Далее можно развернуть кластер (см. раздел Развертывание базового кластера).

6.3. Создание ВМ в VirtualBox

Создайте в VirtualBox три виртуальные машины: один управляющий и два рабочих узла. В качестве установочного образа следует указать, скачанный ранее образ:
VirtualBox. Операционная система ВМ
Ресурсы ВМ следует назначить в соответствии с минимальными требованиями (см. табл. Минимальные требования).
VirtualBox. Оборудование ВМ
VirtualBox. Жесткий диск ВМ
После создания ВМ, необходимо указать настройкти сети, для этого выберите ВМ и нажмите кнопку Настроить.
VirtualBox. Настройки ВМ
В открывшемся окне перейдите в раздел Сеть, в выпадающем списке Тип подключения выберите Сетевой мост, а в списке Имя — имя сетевого интерфейса и нажмите кнопку ОК для сохранения настроек.
VirtualBox. Настройки сети ВМ
Далее можно развернуть кластер (см. раздел Развертывание базового кластера).

6.4. Создание ВМ в libvirt

Скопируйте ISO-образ на сервер libvit, например:
$ scp alt-orchestara-11.0-metal-amd64.iso root@libvirt:/var/lib/libvirt/images/
Создайте в virt-manager (менеджере виртуальных машин) три виртуальные машины: один управляющий и два рабочих узла. В качестве установочного образа следует указать загруженный образ:
Выбор ISO-образа
Ресурсы ВМ следует назначить в соответствии с минимальными требованиями (см. табл. Минимальные требования).
virt-manager. Параметры памяти и процессора
virt-manager. Параметры диска
virt-manager. Название ВМ и сеть
Далее можно развернуть кластер (см. раздел Развертывание базового кластера).

6.5. Установка на физический сервер

ALT Orchestra можно установить на физический сервер (bare metal), используя ISO-образ.

6.5.1. Запись ISO на USB-накопитель

Для записи ISO-образа на USB-накопитель можно воспользоваться командой:
# dd oflag=direct if=<файл-образа.iso> of=/dev/sdX bs=1M status=progress;sync
где:
  • <файл-образа.iso> — ISO-образ установочного диска с дистрибутивом;
  • /dev/sdX — устройство, соответствующее flash-диску.
Для удобства показа прогресса записи можно установить пакет pv и использовать команду:
# pv <файл-образа.iso> | dd oflag=direct of=/dev/sdX bs=1M;sync
где:
  • <файл-образа.iso> — ISO-образ установочного диска с дистрибутивом;
  • /dev/sdX — устройство, соответствующее flash-диску.
Пример записи образа на диск /dev/sdd (следует убедиться, что выбрано правильное устройство):
# pv alt-orchestra-11.0-metal-amd64.iso | dd of=/dev/sdd bs=1M oflag=direct; sync

6.5.2. Загрузка ALT Orchestra с USB

При загрузке с ISO ALT Orchestra не устанавливается автоматически на диск, пока не будет применена конфигурация машины (apply-config через talosctl).

Примечание

Если ALT Orchestra уже установлен на диск, система загрузится с него. Поэтому рекомендуется установить приоритет загрузки: сначала диск, затем USB/ISO. Также можно просто извлечь USB-накопитель после установки.
Далее можно развернуть кластер (см. раздел Развертывание базового кластера).

Глава 7. Установка ALT Orchestra с использованием Image Factory по сети (iPXE)

PXE-загрузка (Preboot Execution Environment) позволяет запускать ALT Orchestra без предварительной записи ISO-образа на USB-накопитель или диск. Этот способ особенно полезен при массовом развёртывании.
Для успешной сетевой установки требуются:
  • на целевой машине — сетевой интерфейс с поддержкой PXE;
  • DHCP-сервер с поддержкой BOOTP/PXE;
  • TFTP-сервер (для начальной загрузки iPXE);
  • HTTP-сервер (для передачи ядра, initramfs и конфигурации).
Для загрузки ALT Orchestra по сети нужны два файла:
  • kernel-amd64 (alt-orchestra-11.0-kernel-amd64) — ядро Linux;
  • initramfs-amd64.xz (alt-orchestra-11.0-initramfs-amd64.xz) — сжатый образ начальной загрузки (initramfs).

Примечание

Может потребоваться распаковать initramfs (некоторые старые PXE-прошивки могут требовать несжатый initramfs).
ALT Orchestra требует указания следующих параметров ядра:
talos.platform=metal
slab_nomerge
pti=on
Конфигурация машины также может быть передана через параметр:
talos.config=https://<metadata-service>/talos/config?mac=${mac}
Альтернативно, PXE-загрузку можно настроить через Image Factory (см. PXE Frontend API).
Стенд включает:
  • сервер сетевой загрузки;
  • управляющий узел;
  • рабочий узел.
Характеристики сервера сетевой загрузки:
  • CPU: 2 ядра;
  • RAM: 3072 МБ;
  • диск: 25 ГБ.
Требования:
  • все машины должны находиться в одной сети;
  • в сети не должно быть других устройств, выполняющих функции DHCP-сервера;
  • сервер сетевой загрузки должен иметь доступ в Интернет.

7.1. Настройка сервера вручную

7.1.1. Настройка сервера сетевой загрузки

Примечание

На интерфейсе хоста, на котором разворачивается DHCP-сервер, должен быть настроен статический IP-адрес. В примере серверу назначен IP-адрес 192.168.0.224.
Подготовка DHCP-сервера:
  1. Установить DHCP-сервер:
    # apt-get install dhcp-server
    
  2. Настроить файл конфигурации DHCP (/etc/dhcp/dhcpd.conf):
    authoritative;
    ddns-update-style none;
    
    option arch code 93 = unsigned integer 16;
    option space ipxe;
    option ipxe.no-pxedhcp code 176 = unsigned integer 8;
    
    subnet 192.168.0.0 netmask 255.255.255.0 {
        range 192.168.0.200 192.168.0.250;
        option domain-name              "test.alt";
        option domain-name-servers    192.168.0.1;
        option routers                192.168.0.1;
        option broadcast-address        192.168.0.255;
        option subnet-mask              255.255.255.0;
    
        default-lease-time              1800;
        max-lease-time                  3600;
    
        option ipxe.no-pxedhcp          1;
    
        # Указание используемого TFTP-сервера
        next-server 192.168.0.224;
    
        # Если это уже iPXE
        if exists user-class and option user-class = "iPXE" {
            filename "http://192.168.0.224/talos/script-amd64.ipxe";
        } else {
            # PXE Выбор загрузчика в зависимости от архитектуры клиента
            if option arch = 00:00 {
                filename "undionly.kpxe"; # Legacy BIOS
            } else {
                filename "ipxe-x86_64.efi"; # UEFI
            }
        }
    }
    
  3. Включить автозапуск и запустить DHCP-сервер:
    # systemctl enable --now dhcpd
    
Настройка TFTP-сервера:
  1. Установить пакеты:
    # apt-get install ipxe-bootimgs tftp tftp-server-xinetd
    
  2. Разместить необходимые файлы (iPXE) для первоначальной загрузки по TFTP в корневой каталог TFTP:
    # mkdir -p /srv/boot
    # cp /usr/share/ipxe/{ipxe-x86_64.efi,undionly.kpxe} /srv/boot/
    
  3. Включить TFTP-сервер, установив в файле /etc/xinetd.d/tftp значение disable = no. В параметре server_args необходимо указать IP-адрес и корневой каталог TFTP-сервера:
    service tftp
    {
        disable       = no
        socket_type   = dgram
        protocol      = udp
        wait          = yes
        user          = root
        server        = /usr/sbin/in.tftpd
        server_args   = -4 -a 192.168.0.224 -u tftp -s /srv/boot
    }
    
  4. Внести изменения в файл /etc/sysconfig/xinetd:
    # Add extra options here
    EXTRAOPTIONS='-remlock'
    
  5. Разрешить внешние подключения, удалив или закомментировав следующую строку в файле /etc/xinetd.conf:
    only_from = 127.0.0.1
  6. Запустить сервис xinetd:
    # systemctl enable --now xinetd.service
    
Настройка HTTP-сервера (nginx):
  1. Установить nginx:
    # apt-get install nginx
    
  2. Создать файл конфигурации /etc/nginx/sites-available.d/netboot.conf:
    server {
        listen 192.168.0.224:80;
        server_name 192.168.0.224;
    
        location / {
            root /srv;
        }
        access_log /var/log/nginx/access.log;
    }
    
    где 192.168.0.224 — IP-адрес сервера сетевой установки.
  3. Создать каталог, доступ к которому будет предоставлять nginx:
    # mkdir -p /srv/talos
    
  4. Включить сайт:
    # ln -s /etc/nginx/sites-available.d/netboot.conf /etc/nginx/sites-enabled.d/netboot.conf
    
  5. Запустить службу nginx:
    # systemctl enable --now nginx.service
    

7.1.2. Конфигурация iPXE-скрипта

Создать файл /srv/talos/script-amd64.ipxe:
#!ipxe

imgfree
kernel http://192.168.0.224/talos/alt-orchestra-11.0-kernel-amd64 initrd=initramfs-amd64.xz talos.platform=metal console=tty0 init_on_alloc=1 slab_nomerge pti=on consoleblank=0 nvme_core.io_timeout=4294967295 printk.devkmsg=on ima_template=ima-ng ima_appraise=fix ima_hash=sha512 selinux=1
initrd http://192.168.0.224/talos/alt-orchestra-11.0-initramfs-amd64.xz
boot

Примечание

В файле /srv/talos/script-amd64.ipxe можно также использовать прямые ссылки на Image Factory — в этом случае локальное хранение ядра не требуется (см. PXE Frontend API):
#!ipxe

imgfree
kernel http://factory.altlinux.space/image/376567988ad370138ad8b2698212367b8edcb69b5fd68c80be1f2ec7d603b4ba/v11.0/alt-orchestra-11.0-kernel-amd64 talos.platform=metal console=tty0 init_on_alloc=1 slab_nomerge pti=on consoleblank=0 nvme_core.io_timeout=4294967295 printk.devkmsg=on ima_template=ima-ng ima_appraise=fix ima_hash=sha512 selinux=1
initrd http://factory.altlinux.space/image/376567988ad370138ad8b2698212367b8edcb69b5fd68c80be1f2ec7d603b4ba/v11.0/alt-orchestra-11.0-initramfs-amd64.xz
boot
При использовании прямых ссылок следующий пункт настройки можно пропустить.

7.1.3. Размещение ядра и initramfs

Скачать с factory.altlinux.space файлы (см. Конфигурирование и генерация ссылок на артефакты):
  • alt-orchestra-11.0-kernel-amd64)
  • alt-orchestra-11.0-initramfs-amd64.xz)
И разместить их в каталоге /srv/talos/:
# apt-get install wget
# cd /srv/talos
# wget https://factory.altlinux.space/image/376567988ad370138ad8b2698212367b8edcb69b5fd68c80be1f2ec7d603b4ba/v11.0/alt-orchestra-11.0-kernel-amd64
# wget http://factory.altlinux.space/image/376567988ad370138ad8b2698212367b8edcb69b5fd68c80be1f2ec7d603b4ba/v11.0/alt-orchestra-11.0-initramfs-amd64.xz

7.2. Начальная загрузка машины с iPXE

После настройки сервера необходимо включить PXE-загрузку на bare metal машине или ВМ.
Устройство должно:
  1. Загрузиться по PXE и загрузить iPXE.
  2. С помощью iPXE загрузить ядро и initramfs ALT Orchestra.
Пример настройки начальной загрузки в virt-manager:
  1. Создать ВМ для управляющего и рабочего узлов, настроить загрузку сетевую загрузку:
    virt-manager. Источники загрузки ВМ
  2. Запустить ВМ.
    При корректной конфигурации система загрузится автоматически:
    • загрузка системы по сети (EFI):
      Загрузка системы по сети (EFI)
    • загрузка системы по сети (Legacy BIOS):
      Загрузка системы по сети (Legacy BIOS)
    Загруженная система:
    Загруженная система
  3. Дальнейшие шаги аналогичны процессу установки с ISO-образа (см. раздел Развертывание базового кластера).

Примечание

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

Глава 8. Развертывание базового кластера

Данный раздел содержит инструкции по развертыванию Kubernetes-кластера на ALT Orchestra.

8.1. Запуск узлов

При запуске ВМ загрузит указанный ранее образ ISO и перейдет в «режим обслуживания» (maintenance mode).
Установка. Загрузка с установочного диска (UEFI)

Примечание

Загрузка в режиме Legacy:
Установка. Загрузка с установочного диска (Legacy BIOS)
После запуска ВМ, через какое-то время должен появиться экран, отображающий dashboard talosctl:
Режим обслуживания

Примечание

Загрузка с ISO происходит в режиме live (в RAM), и изменения на диск не записываются, пока не будет применена конфигурация через talosctl apply-config.
На этом этапе уже можно размонтировать диски с ISO-образом, вытащить флешки, чтобы в дальнейшем случайно не установить систему на USB-диск и сделать процесс инициализации нод более прозрачным.

Примечание

IP должен быть указан, а значение Stage должно быть Maintenance.

8.1.1. Настройка сети

По умолчанию ALT Orchestra использует DHCP на всех активных интерфейсах. Однако в ряде случаев может потребоваться задать параметры сети вручную — до получения основной конфигурации.
После загрузки с ISO на платформе на платформе bare metal параметры сети можно настроить в панели мониторинга, открыв вкладку Конфигурация сети (F3). Этот способ позволяет задать параметры сетевых интерфейсов без использования параметров командной строки ядра.
Кроме того, параметры сети можно передать через командную строку ядра, например в загрузчике GRUB или при запуске ISO.
Пример простого параметра ip:
ip=192.168.0.100::192.168.0.1:255.255.255.0::ens19:off
Формат параметра:
ip=<client-ip>:<server-ip>:<gw-ip>:<netmask>:<hostname>:<device>:<autoconf>
где:
  • client-ip — статический IP-адрес машины;
  • server-ip — IP-адрес сервера, который используется для дополнительных сетевых задач на раннем этапе загрузки системы (например, для загрузки с сервера TFTP или NFS). Для загрузки с локального диска можно не указывать;
  • gw-ip — IP-адрес шлюза по умолчанию;
  • netmask — сетевая маска;
  • hostname — имя хоста (можно не указывать);
  • device — сетевой интерфейс (актуальное имя: ens19, enp0s3 и т.д.);
  • autoconf — режим автоматической настройки сети (dhcp — использовать DHCP; off — отключить автоматическую настройку).
Пример с VLAN:
ip=172.20.0.2::172.20.0.1:255.255.255.0::eth0.100:::::
Пример с VLAN через параметр vlan=:
vlan=eth0.100:eth0
Пример с bonding (bond=):
bond=bond0:eth0,eth1:balance-rr

Примечание

Параметры ядра не сохраняются после установки. После установки настройка сети должна быть зафиксирована в конфигурации ALT Orchestra (controlplane.yaml или worker.yaml).

8.1.1.1. Загрузка с DHCP-сервером

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

8.1.1.2. Загрузка без DHCP-сервера

Если в сети отсутствует DHCP-сервер, параметры сети можно задать вручную одним из следующих способов::
  • для платформы bare metal — через экран Конфигурация сети (F3) на панели мониторинга;
  • через параметры командной строки ядра.
8.1.1.2.1. Для платформы bare metal
После загрузки с ISO-образа нажмите F3, после чего в открывшемся окне задайте параметры сетевого интерфейса (IP-адрес с маской сети, шлюз и другие необходимые параметры):
Интерактивная панель мониторинга. Настройка статического IP-адреса
Нажмите кнопку Save (Сохранить) для применения изменений.

Примечание

8.1.1.2.2. Через параметры командной строки ядра
В режиме UEFI:
  1. В меню загрузки выберите пункт ALT Orchestra ISO и нажмите клавишу E для вызова редактора параметров загрузки:
    Установка. Загрузка с установочного диска (UEFI)
  2. В открывшемся редакторе добавьте параметры IP, например:
    ip=192.168.0.140::192.168.0.1:255.255.255.0::ens19:off
    Установка. Параметры загрузки (UEFI)
  3. Сохраните настройки, нажав Enter.
В режиме Legacy BIOS:
  1. В меню загрузки выберите пункт ALT Orchestra ISO и нажмите клавишу E для вызова редактора параметров загрузки:
    Установка. Загрузка с установочного диска (Legacy BIOS)
  2. В открывшемся редакторе найдите строку, начинающуюся с linux /boot/vmlinuz, и добавьте в её конец параметры IP, например:
    ip=192.168.0.140::192.168.0.1:255.255.255.0::ens19:off
    Установка. Параметры загрузки (BIOS)
  3. Сохраните настройки, нажав F10 или Ctrl+X.

Примечание

Если настройки не применились, проверьте имя сетевого интерфейса.

8.2. Подготовка переменных окружения

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

Примечание

Если используется один Control Plane узел, значение CLUSTER_ENDPOINT может совпадать с его IP-адресом. В остальных случаях возможны два варианта:
  1. Доступ к кластеру через балансировщик нагрузки (отдельный IP-адрес).
  2. Доступ через DNS, при котором все адреса мастер-нод сопоставляются одному DNS-имени.
Отказоустойчивые варианты настройки рассмотрены в разделе Конечная точка доступа Kubernetes API.
Для задания переменных создайте файл .env:
# IP-адреса ВМ
CONTROL_PLANE_IP=<control-plane-ip-1> # или массив: ("ip1" "ip2" ...)
WORKER_IP=("<worker-ip-1>" "<worker-ip-2>" "<worker-ip-3>"…)
# IP-адрес API кластера
CLUSTER_ENDPOINT=<endpoint-ip>
# Название кластера
CLUSTER_NAME=<имя кластера>
BASE_REGISTRY="factory.altlinux.space"
INSTALLERIMAGE=<образ>
Пример:
CONTROL_PLANE_IP=192.168.0.140
WORKER_IP=("192.168.0.145" "192.168.0.146" "192.168.0.147")
CLUSTER_ENDPOINT=192.168.0.140
CLUSTER_NAME="pve-cluster"
BASE_REGISTRY="factory.altlinux.space"
INSTALLERIMAGE="$BASE_REGISTRY/alt-orchestra-metal-installer/376567988ad370138ad8b2698212367b8edcb69b5fd68c80be1f2ec7d603b4ba:v11.0"
Примените переменные из .env-файла:
$ source .env

8.3. Генерация конфигурации кластера

Сгенерируйте секреты:
$ talosctl gen secrets -o secrets.yaml
Сгенерируйте базовую конфигурацию кластера:
$ talosctl gen config <имя кластера> https://$CONTROL_PLANE_IP:6443 \
  --output-dir <каталог>\
  --install-image <образ> \
  --with-secrets <файл> \
  --talos-version <TALOS_VERSION> \
  --kubernetes-version <KUBE_VERSION>
где:
  • имя кластера — произвольное название;
  • каталог — каталог, в который будут сохранены сконфигурированные файлы конфигурации;
  • образ — сгенерированная на начальном этапе ссылка на образ инсталлятора (по умолчанию altlinux.space/alt-orchestra/installer:v11.0);
  • TALOS_VERSION — версия пакета talos, в соответствии с которой будет сгенерирован актуальный конфиг. Если версия talosctl совпадает с версией пакета talos в устанавливаемом образе на узле (можно проверить в таблице Матрица поддержки или командой talosctl get version -i -n <IP-адрес-узла>), данный параметр можно опустить, иначе укажите соответствующую версию пакета (по умолчанию будет указана версия talosctl);
  • KUBE_VERSION — версия kubernetes из списка удовлетворяющих в таблице Матрица поддержки.

Таблица 8.1. Параметры команды talosctl gen config

Параметр
Описание
--additional-sans
Дополнительные имена в поле Subject Alternative Name (SAN) для сертификата API-сервера Kubernetes (например, IP-адреса или доменные имена)
--config-patch
Патч, применяемый ко всем типам машин (init, controlplane, worker). Поддерживает чтение из файла @filename.yaml
--config-patch-control-plane
Патч, применяемый только к узлам типа Control Plane (init и controlplane)
--config-patch-worker
Патч, применяемый только к узлам типа Worker
--dns-domain
DNS-домен кластера (по умолчанию: cluster.local)
--help, -h
Показать справку по команде
--install-disk
Диск, на который будет установлена система (по умолчанию: /dev/sda)
--install-image
Образ установщика, используемый при первой загрузке (по умолчанию: altlinux.space/alt-orchestra/installer:v11.0)
--kubernetes-version
Версия Kubernetes, которую следует развернуть (по умолчанию: 1.35)
--output, -o
Путь для сохранения сгенерированных файлов. Если указано несколько типов вывода — должен быть каталог. Для одного типа — может быть файлом или «-» (вывод в stdout)
--output-types, -f
Типы генерируемых файлов. Возможные значения: controlplane, worker, talosconfig (по умолчанию: все три)
--persist, -p
Сохранять ли конфигурацию на диске после перезагрузки (по умолчанию: true)
--registry-mirror
Список зеркал контейнерных реестров в формате: <реестр>=<зеркало> (например, docker.io=http://mirror.local)
--talos-version
Версия формата машинной конфигурации (по умолчанию: v1alpha1)
--with-cluster-discovery
Включить функцию автоматического обнаружения узлов в кластере (по умолчанию: true)
--with-docs
Добавить в конфигурацию комментарии с описанием каждого поля (по умолчанию: true)
--with-examples
Включить в конфигурацию закомментированные примеры использования (по умолчанию: true)
--with-kubespan
Включить функцию KubeSpan (межсетевое взаимодействие узлов через WireGuard)
--with-secrets
Использовать файл секретов, созданный командой talosctl gen secrets
В каталоге orchestra будут созданы файлы:
  • controlplane.yaml — конфигурация управляющего узла (Control Plane);
  • worker.yaml — конфигурация для рабочих узлов (Worker Node);
  • talosconfig — настройки подключения к API.
Пример:
$ talosctl gen config $CLUSTER_NAME https://$CONTROL_PLANE_IP:6443  \
  --output-dir orchestra \
  --install-image $INSTALLERIMAGE \
  --with-secrets secrets.yaml
Ожидаемый вывод:
generating PKI and tokens
Created orchestra/controlplane.yaml
Created orchestra/worker.yaml
Created orchestra/talosconfig

Примечание

Конфигурация будет сгенерирована для версии, соответствующей установленному talosctl (см. табл. Матрица поддержки). Если необходима другая версия, следует указать параметр --talos-version.
Если планируемые настройки не будут отличаться для каждого Control Plane и Worker узла (диски, интефейсы, кастомные hostname и т.д.), внесите нужные изменения в controlplane.yaml и worker.yaml и перейдите к шагу инициализаии узлов (см. раздел Инициализация узлов).

8.4. Настройка конфигурации узлов

После генерации конфигурации необходимо:
  • задать уникальные имена узлов (hostname);
  • указать сетевые интерфейсы;
  • выбрать диск для установки;
  • при необходимости настроить статические IP-адреса, DNS и маршруты.
Существует два подхода:
  • ручное редактирование конфигурационных файлов;
  • применение патчей.

8.4.1. Проверка оборудования узлов

Параметры disk и interface в конфигурации должны соответствовать реальному оборудованию сервера.

8.4.1.1. Проверка дисков

По умолчанию используется диск /dev/sda. Однако он может называться иначе (например, /dev/vda).
Проверить можно командой:
$ talosctl get disks --insecure --nodes <IP-адрес-узла>
Пример вывода:
NODE  NAMESPACE  TYPE  ID     SIZE    READ ONLY  TRANSPORT   MODEL
      runtime    Disk  loop0  4.1 kB  true
      runtime    Disk  loop1  98 MB   true
      runtime    Disk  sda    11 GB   false       virtio     QEMU HARDDISK
      runtime    Disk  sr0    375 MB  false       sata       QEMU DVD-ROM
Зафиксируйте имя диска для каждой ноды.

Примечание

Если имя диска отличается от /dev/sda, его можно указать его при создании конфигурации, например:
$ export DISK_NAME=/dev/vda
$ talosctl gen config $CLUSTER_NAME https://$CONTROL_PLANE_IP:6443 --install-disk $DISK_NAME
Или изменить в уже сгенерированных файлах.

8.4.1.2. Проверка сетевых интерфейсов

Узнать сетевой интерфейс можно, выполнив команду:
$ talosctl get links --insecure --nodes <IP-адрес-узла>
Пример вывода:
NODE NAMESPACE TYPE ID VERSION TYPE KIND HW ADDR OPER STATE LINK STATE
network LinkStatus bond0 1 ether bond 2a:83:c2:4e:b2:b6 down false
network LinkStatus dummy0 1 ether dummy 3e:11:cf:ae:2a:6f down false
network LinkStatus enp0s3 3 ether 08:00:27:87:04:28 up true
network LinkStatus ip6tnl0 1 tunnel6 ip6tnl 00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00 down false
network LinkStatus lo 2 loopback 00:00:00:00:00:00 unknown true
network LinkStatus sit0 1 sit sit 00:00:00:00 down false
network LinkStatus teql0 1 void down false
network LinkStatus tunl0 1 ipip ipip 00:00:00:00 down false
Зафиксируйте имя интерфейса для каждой ноды (например: enp0s3, eth0, ens19).

8.4.2. Ручное редактирование конфигурационных файлов

Если конфигурации узлов существенно отличаются, можно создать отдельные файлы для каждой ноды.
Создайте структуру каталогов:
$ mkdir -p orchestra/controlplanes
$ mkdir -p orchestra/workers
$ cd talos
Скопируйте базовые шаблоны и создайте файлы для каждой ноды:
├── orchestra/
│   ├── controlplanes/
│   │   └── controlplane-01.yaml
│   └── workers/
│       ├── worker-01.yaml
│       ├── worker-02.yaml
│       └── worker-03.yaml
В сгенерированных файлах найдите раздел:
machine:
  network: {}
Задайте имя сетевого интерфейса:
  network:
    interfaces:
    - interface: ens19
При необходимости настройте диск установки:
    install:
        disk: /dev/sda # Диск для установки системы
Задайте hostname с учетом уникальности для каждого узла в конце файла. Можно оставить автоматическое присвоение имени, либо убрать настройку auto и указать hostname:
kind: HostnameConfig
# auto: stable # A method to automatically generate a hostname for the machine.

# # A static hostname to set for the machine.
hostname: controlplane-01

Примечание

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

8.4.3. Использование патчей конфигурации

Альтернативный способ — использование патчей конфигурации.
Пример патча для DHCP:
machine:
  network:
    interfaces:
      - interface: <interface>
        dhcp: true
  install:
    disk: /dev/<disk>
Пример патча со статической адресацией:
#controlplane-patch-01.yaml
machine:
  network:
    interfaces:
      - interface: ens19
        addresses:
          - 192.168.0.140/24
        routes:
          - network: 0.0.0.0/0
            gateway: 192.168.0.1
    nameservers:
      - 192.168.0.1
  install:
    disk: /dev/sda
Пример патча с настройкой имени хоста и статической адресацией:
apiVersion: v1alpha1
auto: off
kind: HostnameConfig
hostname: worker-01
---
machine:
  network:
    interfaces:
      - interface: ens19
        addresses:
          - 192.168.0.145/24
        routes:
          - network: 0.0.0.0/0
            gateway: 192.168.0.1
    nameservers:
      - 192.168.0.1
  install:
    disk: /dev/sda

8.4.3.1. Генерация конфигураций с помощью патчей

Если узлы имеют различающуюся конфигурацию, можно заранее сгенерировать отдельные файлы конфигурации на основе патчей.
Control Plane:
$ talosctl machineconfig patch controlplane.yaml \
  --patch @controlplane-patch-01.yaml \
  --output controlplanes/controlplane-01.yaml
Worker:
$ talosctl machineconfig patch worker.yaml \
  --patch @worker-patch-01.yaml \
  --output workers/worker-01.yaml

$ talosctl machineconfig patch worker.yaml \
  --patch @worker-patch-02.yaml \
  --output workers/worker-02.yaml

$ talosctl machineconfig patch worker.yaml \
  --patch @worker-patch-03.yaml
  --output workers/worker-03.yaml
Результирующие файлы будут размещены в каталогах orchestra/controlplanes и orchestra/workers.
В результирующих файлах проверьте и отредактируйте при необходимости нужные поля:
  • задайте hostname с учетом уникальности для каждого узла в конце файла. Можно оставить автоматическое присвоение имени, либо убрать настройку auto и указать hostname:
    kind: HostnameConfig
    # auto: stable # A method to automatically generate a hostname for the machine.
    
    # # A static hostname to set for the machine.
    hostname: controlplane-01
    
Для Control Plane дополнительно проверьте:
  • ссылку на образ инсталлятора, она должна совпадать с раннее сгенерированной на первом шаге:
    install:
            image: factory.altlinux.space/alt-orchestra-metal-installer/376567988ad370138ad8b2698212367b8edcb69b5fd68c80be1f2ec7d603b4ba:v11.0
    
  • правильность образа, ветки и версии kubernetes с учетом табл. Матрица поддержки:
    kubelet:
            image: registry.altlinux.org/p11/kubelet:<KUBE_VERSION>
    
    apiServer:
            image: registry.altlinux.org/p11/kube-apiserver:<KUBE_VERSION>
    
    controllerManager:
            image: registry.altlinux.org/p11/kube-controller-manager:<KUBE_VERSION>
    proxy:
            image: registry.altlinux.org/p11/kube-proxy:<KUBE_VERSION>
    scheduler:
            image: registry.altlinux.org/p11/kube-scheduler:<KUBE_VERSION>
    

8.4.3.2. Применение патчей при развёртывании узлов

Можно также применять патчи непосредственно во время развёртывания узлов без генерации отдельных конфигурационных файлов.
Поддерживаются следующие параметры:
  • --config-patch — патч для всех узлов;
  • --config-patch-control-plane — патч только для control-plane;
  • --config-patch-worker — патч только для worker-узлов.
Такой подход особенно удобен, если узлы однотипны и отличаются минимально. В этом случае достаточно использовать базовые файлы controlplane.yaml и worker.yaml, а изменения передавать через патчи при выполнении команды apply-config.
Пример применения конфигурации с патчем:
$ talosctl apply-config --insecure \
  --nodes 192.168.0.140 \
  --file orchestra/controlplane.yaml \
  --config-patch @controlplane-patch-01.yaml

$ talosctl apply-config --insecure \
  --nodes 192.168.0.145 \
  --file orchestra/worker.yaml \
  --config-patch @worker-patch-01.yaml

8.4.3.3. Использование общих патчей

Если все control-plane- или worker-узлы имеют одинаковую конфигурацию, можно использовать общие патчи:
$ talosctl apply-config --insecure \
  --nodes 192.168.0.140 \
  --file orchestra/controlplane.yaml \
  --config-patch-control-plane @controlplane-common.yaml

$ talosctl apply-config --insecure \
  --nodes 192.168.0.145 \
  --file orchestra/worker.yaml \
  --config-patch-worker @worker-common.yaml

8.4.3.4. Комбинирование патчей

Допускается одновременное использование нескольких патчей:
$ talosctl apply-config --insecure \
  --nodes 192.168.0.145 \
  --file orchestra/worker.yaml \
  --config-patch @worker-network.yaml \
  --config-patch @worker-hostname-01.yaml
Это позволяет разделять настройки по назначению (например: сеть, диски, Kubernetes-параметры, CNI и т.д.) и упрощает сопровождение конфигурации.

8.4.4. Инициализация узлов

8.4.4.1. Инициализация управляющего узла (Control Plane)

Примените сгенерированную конфигурацию controlplane.yaml к управляющему узлу, используя talosctl:
$ talosctl apply-config --insecure \
  --nodes $CONTROL_PLANE_IP \
  --file controlplanes/controlplane-01.yaml
После этого:
  • ALT Orchestra устанавливается на диск управляющего узла:
    Установка ОС на диск
  • виртуальная машина автоматически перезагружается;
  • запускается настройка плоскости управления Kubernetes.
Статус должен измениться на Booting:
Стадия «Booting»

Примечание

Этот процесс можно повторить для нескольких узлов, чтобы создать отказоустойчивую (HA) конфигурацию Control Plane.

Примечание

Если в конфигурационных файлах для нод указана неверная ссылка на инсталлятор (см. machine.install.image), система не сможет установиться на жёсткий диск. Поэтому, после применения конфигов, подождите немного, а затем зайдите на ноды. Тревожными звонками будет сброс конфигурации (если вы устанавливали её на экране f3), невозможность посмотреть на ноды через команду:
$ talosctl get addresses -n <IP-адрес-узла>

8.4.4.2. Инициализация рабочих узлов (Worker Node)

Примените конфигурацию worker к каждому рабочему узлу:
$ talosctl apply-config --insecure \
  --nodes 192.168.0.145 \
  --file workers/worker-01.yaml

$ talosctl apply-config --insecure \
  --nodes 192.168.0.146 \
  --file workers/worker-02.yaml

$ talosctl apply-config --insecure \
  --nodes 192.168.0.147 \
  --file workers/worker-03.yaml
В результате:
  • ALT Orchestra устанавливается на диск;
  • виртуальная машина автоматически перезагружается;
  • узел подключается к плоскости управления.

8.4.4.3. Настройка доступа и инициализация кластера

Настройте talosctl для работы с кластером:
$ export TALOSCONFIG="$HOME/.talos/config"

$ talosctl config merge orchestra/talosconfig

$ talosctl --talosconfig $TALOSCONFIG config endpoint $CONTROL_PLANE_IP

$ talosctl --talosconfig $TALOSCONFIG config node $CONTROL_PLANE_IP
Пример содержимого .talos/config:
context: pve-cluster
contexts:
    pve-cluster:
        endpoints:
            - 192.168.0.140
        nodes:
            - 192.168.0.140
        ca: LS0tL...
        crt: LS0tLS1CR...
        key: LS0tLS1CRUd...
Инициализируйте кластер Kubernetes (etcd):
$ talosctl bootstrap --nodes $CONTROL_PLANE_IP --talosconfig $TALOSCONFIG

Примечание

Эту команду необходимо выполнить один раз на одном узле управления. При наличии нескольких управляющих узлов выберите любой из них.
Статус Stage должен измениться на Running:
Стадия «Running»
Дождитесь, пока узел перейдет в состояние Ready=True:
  • управляющий узел подготовлен:
    Управляющий узел подготовлен
  • рабочий узел подготовлен:
    Рабочий узел подготовлен
Логи процесса можно отслуживать непосредственно на панели управления узла или получить логи на рабочем месте администратора командой:
$ talosctl dmesg -n <NODE_IP>

8.4.5. Получение kubeconfig

После запуска кластера загрузите файл конфигурации kubeconfig для работы с kubectl.
Файл можно получить двумя способами:
  • объединить с текущей конфигурацией Kubernetes:
    $ talosctl --nodes $CONTROL_PLANE_IP \
      --talosconfig $TALOSCONFIG  kubeconfig .
    
  • сохранить отдельно:
    $ talosctl kubeconfig alternative-kubeconfig \
      --nodes $CONTROL_PLANE_IP \
      --talosconfig $TALOSCONFIG
    $ export KUBECONFIG=./alternative-kubeconfig
    
Пример использования kubectl с альтернативным файлом:
$ kubectl --kubeconfig ./alternative-kubeconfig get pods -A

Примечание

Для возможности выполнения команды kubectl должен быть установлен пакет kubernetes<Версия>-client, например kubernetes1.35-client.

8.4.6. Проверка работоспособности кластера

После завершения развертывания кластера необходимо проверить доступность control plane и состояние узлов Kubernetes.

8.4.6.1. Проверка состояния узлов через API

Проверка состояния узлов выполняется с помощью talosctl:
$ talosctl --nodes $CONTROL_PLANE_IP --talosconfig $TALOSCONFIG health
Команда выполняет проверку состояния control plane и базовых сервисов.
Если используется несколько кластеров, можно просмотреть доступные контексты:
$ talosctl config contexts
Пример вывода:
CURRENT   NAME                 ENDPOINTS       NODES
*         pve-cluster          192.168.0.140   192.168.0.140
          security-cluster     192.168.0.222   192.168.0.222

Примечание

Контекст talosctl определяет, к какому кластеру выполняются запросы управления.
Команда переключения активного контекста:
$ talosctl config context <имя контекста>

8.4.6.2. Проверка состояния Kubernetes-узлов

Проверка доступности узлов Kubernetes выполняется через kubectl:
$ kubectl --kubeconfig ./kubeconfig get nodes
Пример вывода:
NAME             STATUS  ROLES          AGE  VERSION
controlplane-01  Ready   control-plane  18h  v1.35.0
worker-01        Ready    <none>        18h  v1.35.0
worker-02        Ready    <none>        18h  v1.35.0
worker-03        Ready    <none>        18h  v1.35.0
Все узлы должны находиться в состоянии Ready.
Дополнительная информация о состоянии узлов:
$ kubectl --kubeconfig kubeconfig get nodes -o wide
Пример вывода:
NAME             ROLES          INTERNAL-IP    OS-IMAGE       KERNEL-VERSION
controlplane-01  control-plane  192.168.0.140  ALT Orchestra  6.18.18-talos-alt1
worker-01        <none>         192.168.0.145  ALT Orchestra  6.18.18-talos-alt1
worker-02        <none>         192.168.0.146  ALT Orchestra  6.18.18-talos-alt1
Просмотр узлов
Просмотр доступных контекстов Kubernetes:
    $ kubectl config get-contexts --kubeconfig kubeconfig
Пример вывода:
CURRENT  NAME                     CLUSTER            AUTHINFO               NAMESPACE
         admin@libvirt-cluster    libvirt-cluster    admin@libvirt-cluster   default
*        admin@libvirt-cluster-1  libvirt-cluster-1  admin@libvirt-cluster-1 default
         admin@pve-cluster        pve-cluster        admin@pve-cluster       default
Переключение контекста Kubernetes:
$ kubectl --kubeconfig kubeconfig config use-context <имя контекста>

Примечание

Переключение контекста требуется только в том случае, если в файле kubeconfig настроено несколько контекстов. Если используется один контекст, выполнять данную команду не требуется.
Просмотр системных подов Kubernetes:
$ kubectl --kubeconfig kubeconfig get pods --namespace kube-system
Пример вывода:
NAME                                          READY   STATUS     RESTARTS      AGE
coredns-5966c6bdcd-978cs                      1/1     Running    0             18m
coredns-5966c6bdcd-fk9xl                      0/1     Completed  0             2d21h
coredns-5966c6bdcd-jbrnk                      1/1     Running    1 (2d18h ago) 2d21h
kube-apiserver-alt-orchestra-38k-guy          1/1     Running    0             18m
kube-controller-manager-alt-orchestra-38k-guy 1/1     Running    2 (19m ago)   18m
kube-flannel-8rhrg                            1/1     Running    1 (2d18h ago) 2d21h
kube-flannel-gn8x4                            1/1     Running    0             2d18h
kube-flannel-t6k6t                            1/1     Running    0             18m
kube-proxy-4hmfp                              1/1     Running    1 (2d18h ago) 2d21h
kube-proxy-b85mh                              1/1     Running    0             18m
kube-proxy-m2wrb                              1/1     Running    0             18m
kube-scheduler-alt-orchestra-38k-guy          1/1     Running    2 (19m ago)   18m

8.5. Тестовое развёртывание Deployment nginx

Создать Deployment с nginx:
$ kubectl --kubeconfig kubeconfig apply \
  -f https://k8s.io/examples/application/deployment.yaml
Пример вывода:
deployment.apps/nginx-deployment created
Убедиться, что Deployment создан:
$ kubectl --kubeconfig kubeconfig get deploy

NAME               READY   UP-TO-DATE   AVAILABLE   AGE
nginx-deployment   2/2     2            2           28s

$ kubectl --kubeconfig kubeconfig get rs

NAME                          DESIRED   CURRENT   READY   AGE
nginx-deployment-647677fc66   2         2         2       43s

$ kubectl --kubeconfig kubeconfig get pod

NAME                                READY   STATUS    RESTARTS   AGE
nginx-deployment-647677fc66-kzxn9   1/1     Running   0          54s
nginx-deployment-647677fc66-snfhq   1/1     Running   0          54s
Создать сервис, с помощью которого можно получить доступ к приложению из внешней сети. Для этого создайте файл nginx-service.yaml со следующим содержимым:
apiVersion: v1
kind: Service
metadata:
  name: nginx
  labels:
    app: nginx
spec:
  type: NodePort
  ports:
  - port: 80
    targetPort: 80
  selector:
    app: nginx
Запустите сервис:
$ kubectl --kubeconfig kubeconfig apply -f nginx-service.yaml
Пример вывода:
service/nginx created
Просмотреть порт сервиса nginx:
$ kubectl --kubeconfig kubeconfig get svc nginx
Пример вывода:
NAME    TYPE       CLUSTER-IP      EXTERNAL-IP   PORT(S)        AGE
nginx   NodePort   10.106.76.186   <none>        80:30576/TCP   24m
Проверить работу nginx, выполнив команду (сервер должен вернуть код 200):
$ curl -I <IP-адрес>:<порт>
где:
  • <IP-адрес> — IP-адрес любой ноды (не управляющей);
  • <порт> — порт сервиса, полученный на предыдущем шаге.
В данном кластере возможна команда:
$ curl -I 192.168.0.145:30576
Пример вывода:
HTTP/1.1 200 OK
Server: nginx/1.14.2
Date: Tue, 19 May 2026 19:41:36 GMT
Content-Type: text/html
Content-Length: 612
Last-Modified: Tue, 04 Dec 2018 14:44:49 GMT
Connection: keep-alive
ETag: "5c0692e1-264"
Accept-Ranges: bytes
Остановка (удаление) сервиса:
$ kubectl --kubeconfig kubeconfig delete svc nginx
Удаление подов:
$ kubectl --kubeconfig kubeconfig delete deployment nginx-deployment
Проверка удаления:
$ kubectl --kubeconfig kubeconfig get pod

8.6. Сброс машины

Ниже описаны возможные способы сброса машины ALT Orchestra в исходное состояние.
В некоторых случаях требуется вернуть машину ALT Orchestra в исходное состояние. Эта операция является разрушительной: она удаляет узел из Kubernetes и etcd (если применимо), а также очищает все данные, которые обычно сохраняются после перезагрузки.
Для сброса машины используется команда talosctl reset:
$ talosctl reset --nodes <IP-адрес-узла>

Примечание

Запуск команды talosctl reset на облачных ВМ может привести к невозможности загрузки, поскольку команда стирает весь диск. В таких случаях рекомендуется очищать только системные разделы:
$ talosctl reset --system-labels-to-wipe STATE --system-labels-to-wipe EPHEMERAL

Таблица 8.2. Параметры команды talosctl reset

Параметр
Описание
-n, --nodes
IP-адреса или имена узлов, которые необходимо сбросить
--graceful
Попытаться корректно вывести узел из кластера и покинуть etcd (по умолчанию true)
--reboot
Перезагрузить узел после сброса вместо выключения
--system-labels-to-wipe
Очистить только указанные системные разделы (например, STATE, EPHEMERAL), оставив остальные без изменений
--user-disks-to-wipe
Список устройств (например, /dev/sdb), которые будут полностью стёрты
--wipe-mode
Режим очистки диска:
  • all — стереть всё (по умолчанию);
  • system-disk — только системный диск;
  • user-disks — только пользовательские диски
--insecure
Использовать незащищённый режим обслуживания (без аутентификации, только шифрование). Требуется при работе в режиме maintenance
--endpoints, -e
Переопределить адреса endpoints из конфигурации ALT Orchestra
--talosconfig
Путь к файлу конфигурации ALT Orchestra (по умолчанию $HOME/.talos/config)
--context
Контекст подключения (например, при использовании прокси или SideroV1)
--debug
Включить отладочный вывод (в том числе из журналов ядра). Автоматически включает --wait
--wait
Ожидать завершения операции и отслеживать её прогресс (по умолчанию true)
--timeout
Максимальное время ожидания завершения операции (по умолчанию 30m)

Примечание

Особенности HA-кластеров: в отказоустойчивом (HA) кластере можно использовать --graceful=true. В одноузловом кластере (например, для тестирования) невозможно корректно вывести узел из состава кластера etcd, поэтому следует использовать --graceful=false.
Альтернативный способ сброса машины — указание параметра ядра при загрузке:
talos.experimental.wipe=system
Если машина застряла в цикле загрузки и при этом есть доступ к консоли, можно использовать загрузчик (например, GRUB) для указания этого параметра ядра. При следующей загрузке ALT Orchestra очистит системный диск и перезагрузится.
После сброса можно заново установить ALT Orchestra с использованием PXE или ISO-образа.

Глава 9. Проверка и диагностика кластера

После развертывания кластера ALT Orchestra рекомендуется проверить состояние системных служб, компонентов Kubernetes и основных сервисов кластера. Для этого можно использовать утилиту talosctl.

9.1. Проверка состояния системных служб

Проверка состояния системных служб на Control Plane-узле:
$ talosctl --talosconfig=./talosconfig -e ${endPoint} -n ${endPoint} service
Ожидаемый вывод:
NODE            SERVICE      STATE     HEALTH   LAST CHANGE     LAST EVENT
192.168.0.140   apid         Running   OK       34h16m51s ago   Health check successful
192.168.0.140   containerd   Running   OK       22h27m21s ago   Health check successful
192.168.0.140   cri          Running   OK       6m17s ago       Health check successful
192.168.0.140   dashboard    Running   ?        34h16m57s ago   Process Process(["/sbin/dashboard"]) started with PID 2117
192.168.0.140   etcd         Running   OK       34h15m53s ago   Health check successful
192.168.0.140   kubelet      Running   OK       6m6s ago        Health check successful
192.168.0.140   machined     Running   OK       34h16m59s ago   Health check successful
192.168.0.140   syslogd      Running   OK       34h16m58s ago   Health check successful
192.168.0.140   trustd       Running   OK       34h16m53s ago   Health check successful
192.168.0.140   udevd        Running   OK       34h16m58s ago   Health check successful
Проверка состояния системных служб на Worker-узле:
$ talosctl --talosconfig=./talosconfig -e ${endPoint} -n ${workerIP} service
Ожидаемый вывод:
NODE            SERVICE      STATE     HEALTH   LAST CHANGE     LAST EVENT
192.168.0.145   apid         Running   OK       34h19m8s ago    Health check successful
192.168.0.145   containerd   Running   OK       34h19m13s ago   Health check successful
192.168.0.145   cri          Running   OK       14m1s ago       Health check successful
192.168.0.145   dashboard    Running   ?        34h19m11s ago   Process Process(["/sbin/dashboard"]) started with PID 2122
192.168.0.145   kubelet      Running   OK       34h17m38s ago   Health check successful
192.168.0.145   machined     Running   OK       34h19m13s ago   Health check successful
192.168.0.145   syslogd      Running   OK       34h19m12s ago   Health check successful
192.168.0.145   udevd        Running   OK       34h19m12s ago   Health check successful
Службы должны находиться в состоянии Running, а их состояние здоровья (HEALTH) должно быть OK.

9.2. Комплексная проверка состояния кластера

Проверка состояния всех основных компонентов кластера:
$ talosctl --talosconfig=./talosconfig -e ${endPoint} -n ${endPoint} health
Ожидаемый вывод:
discovered nodes: ["192.168.0.145" "192.168.0.140"]
waiting for etcd to be healthy: ...
waiting for etcd to be healthy: OK
waiting for etcd members to be consistent across nodes: ...
waiting for etcd members to be consistent across nodes: OK
waiting for etcd members to be control plane nodes: ...
waiting for etcd members to be control plane nodes: OK
waiting for apid to be ready: ...
waiting for apid to be ready: OK
waiting for all nodes memory sizes: ...
waiting for all nodes memory sizes: OK
waiting for all nodes disk sizes: ...
waiting for all nodes disk sizes: OK
waiting for no diagnostics: ...
waiting for no diagnostics: OK
waiting for kubelet to be healthy: ...
waiting for kubelet to be healthy: OK
waiting for all nodes to finish boot sequence: ...
waiting for all nodes to finish boot sequence: OK
waiting for all k8s nodes to report: ...
waiting for all k8s nodes to report: OK
waiting for all control plane static pods to be running: ...
waiting for all control plane static pods to be running: OK
waiting for all control plane components to be ready: ...
waiting for all control plane components to be ready: OK
waiting for all k8s nodes to report ready: ...
waiting for all k8s nodes to report ready: OK
waiting for kube-proxy to report ready: ...
waiting for kube-proxy to report ready: OK
waiting for coredns to report ready: ...
waiting for coredns to report ready: OK
waiting for all k8s nodes to report schedulable: ...
waiting for all k8s nodes to report schedulable: OK
Все проверки должны завершиться со статусом OK.

9.3. Просмотр статистики использования ресурсов

Просмотр статистики использования ресурсов системными службами talos:
$ talosctl --talosconfig=./talosconfig -e ${endPoint} -n ${endPoint} stats
Пример вывода:
NODE            NAMESPACE   ID       MEMORY(MB)   CPU
192.168.0.140   system      apid     17.66        12755669000
192.168.0.140   system      trustd   10.76        11336251000
ППросмотр статистики использования ресурсов компонентами Kubernetes:
$ talosctl --talosconfig=./talosconfig -e ${endPoint} -n ${endPoint} stats -k
Пример вывода:
NODE           NAMESPACE  ID                                                                    MEMORY(MB)   CPU
192.168.0.140  k8s.io     kube-system/coredns-5c584f8977-nctvv                                  0.00         0
192.168.0.140  k8s.io     └─ kube-system/coredns-5c584f8977-nctvv:coredns:7b0dd9383da7          23.88        7867830000
192.168.0.140  k8s.io     kube-system/coredns-5c584f8977-t55cr                                  0.00         0
192.168.0.140  k8s.io     └─ kube-system/coredns-5c584f8977-t55cr:coredns:c34642e2a12c          23.55        7406138000
192.168.0.140  k8s.io     kube-system/kube-apiserver-talos-vt1-w8a                              0.00         0
192.168.0.140  k8s.io     └─ kube-system/kube-apiserver-talos-vt1-w8a:kube-apiserver:…          356.34       12322845633000
192.168.0.140  k8s.io     kube-system/kube-controller-manager-talos-vt1-w8a                     0.00         0
192.168.0.140  k8s.io     └─ kube-system/kube-controller-manager-talos-vt1-w8a:…                0.00         0
192.168.0.140   k8s.io      └─ kube-system/kube-controller-manager-talos-vt1-w8a:…              93.95        40557624000
192.168.0.140  k8s.io     kube-system/kube-flannel-vzvzx                                        0.00         0
192.168.0.140  k8s.io     └─ kube-system/kube-flannel-vzvzx:install-config:494eaa3616eb         0.00         0
192.168.0.140  k8s.io     └─ kube-system/kube-flannel-vzvzx:kube-flannel:518979a3ecfb           19.67        859609411000
192.168.0.140  k8s.io     kube-system/kube-proxy-9rmz2                                          0.00         0
192.168.0.140  k8s.io     └─ kube-system/kube-proxy-9rmz2:kube-proxy:…                          25.46        38185553000
192.168.0.140  k8s.io     kube-system/kube-scheduler-talos-vt1-w8a                              0.00         0
192.168.0.140  k8s.io     └─ kube-system/kube-scheduler-talos-vt1-w8a:kube-scheduler:…          30.48        8256563000
192.168.0.140  k8s.io     └─ kube-system/kube-scheduler-talos-vt1-w8a:kube-scheduler:…          0.00         0

9.4. Проверка соответствия Kubernetes (Conformance)

Проверка соответствия Kubernetes (Conformance) требует, чтобы в кластере было как минимум два узла, способных запускать пользовательские Pod'ы. Если в кластере используется только один Worker-узел, предварительно необходимо снять taint с Control Plane-узлов.
Запуск комплексного теста:
$ talosctl --talosconfig=./talosconfig -e ${endPoint} -n ${endPoint} conformance kubernetes
Пример вывода:
running conformance tests version 1.31.1
running tests: \[Conformance\]
2025/01/29 13:34:23 Running command:
Command env: []
Run from directory:
Executable path: /usr/local/bin/ginkgo
Args (comma-delimited): /usr/local/bin/ginkgo,--focus=\[Conformance\],--skip=,--no-color=true,--procs=4,--timeout=24h,/usr/local/bin/e2e.test,--,--disable-log-dump,--repo-root=/kubernetes,--provider=skeleton,--report-dir=/tmp/results,--kubeconfig=
2025/01/29 13:34:23 Now listening for interrupts
Running Suite: Kubernetes e2e suite - /usr/local/bin
====================================================
Random Seed: 1738157663 - will randomize all specs

Will run 404 of 6603 specs
....
Summarizing 2 Failures:
  [FAIL] [sig-scheduling] SchedulerPredicates [Serial] [It] validates resource limits of pods that are allowed to run [Conformance] [sig-scheduling, Serial, Conformance]
  k8s.io/kubernetes/test/e2e/scheduling/predicates.go:414
  [FAIL] [sig-apps] Daemon set [Serial] [It] should rollback without unnecessary restarts [Conformance] [sig-apps, Serial, Conformance]
  k8s.io/kubernetes/test/e2e/apps/daemon_set.go:446

Ran 404 of 6603 Specs in 2842.641 seconds
FAIL! -- 402 Passed | 2 Failed | 0 Pending | 6199 Skipped


Ginkgo ran 1 suite in 47m26.014915675s
tests finished after 47m26s.
После завершения проверки отображается сводка с количеством успешно пройденных и неуспешных тестов.

Часть III. Специальные сценарии развертывания

Содержание

10. Развертывание кластера в закрытом контуре
10.1. Подготовка инфраструктурного стенда
10.1.1. Установка пакетов
10.1.2. Настройка сетевых интерфейсов
10.1.3. Настройка DHCP-сервера
10.1.4. Настройка DNS
10.1.5. Настройка NTP
10.1.6. Настройка прокси-кешей контейнерных образов
10.1.7. Настройка Discovery Service RS
10.2. Развертывание кластера
10.2.1. Получение дисков и подготовка образов
10.2.2. Подготовка конфигурации кластера
10.2.3. Применение конфигурации и инициализация кластера
10.2.4. Установка Cilium
10.2.5. Проверка кластера
10.3. Ручное обновление кластера
11. Загрузка в режиме Secure Boot на платформах UEFI
11.1. Secure Boot с образами ALT Orchestra
11.2. Настройка среды установки
11.2.1. Особенности установки на PVE
11.3. Загрузка ALT Orchestra в режиме Secure Boot
11.3.1. Проверка состояния Secure Boot
11.3.2. Конфигурация только Secure Boot (без TPM)
11.3.3. Настройка шифрования диска с использованием TPM
11.4. Обновление ALT Orchestra
11.5. Шифрование диска с использованием TPM
11.6. Другие варианты загрузки
11.7. Secure Boot с пользовательскими ключами
11.7.1. Генерация ключей
11.7.2. Генерация загрузочных образов с Secure Boot
12. Отказоустойчивый кластер
12.1. Топология
12.2. Точка доступа Kubernetes API
12.3. Развертывание кластера
12.3.1. Подготовка конфигураций
12.3.2. Применение конфигураций
12.3.3. Настройка talosconfig
12.3.4. Bootstrap etcd
12.3.5. Получение kubeconfig
12.3.6. Проверка кластера
12.4. Работа с отказоустойчивым кластером
12.4.1. Хранение чувствительных файлов
13. Миграция Kubernetes-кластера на ALT Orchestra
13.1. Требования
13.2. Тестовая среда
13.3. Подготовка переменных
13.4. Генерация секретов из PKI существующего кластера
13.5. Генерация конфигураций ALT Orchestra
13.6. Перенос параметров kube-apiserver
13.7. Отключение KubePrism
13.8. Добавление первого узла Control Plane ALT Orchestra
13.9. Переключение endpoint на новый узел Control Plane
13.10. Переключение существующих Worker-узлов
13.11. Вывод существующих узлов Control Plane
13.12. Добавление новых Worker-узлов ALT Orchestra
13.13. Вывод существующих Worker-узлов
13.14. Обновление Kubernetes после миграции

Глава 10. Развертывание кластера в закрытом контуре

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

Таблица 10.1. Службы и программные компоненты инфраструктурного сервера для развёртывания ALT Orchestra в закрытом контуре

Функция
Программное обеспечение
Необходимость
Выдача IP-адресов (DHCP)
dhcp-server
Нет: возможно использование статических адресов
Разрешение имён (DNS)
bind
Нет: можно использовать IP-адреса
Синхронизация времени (NTP)
chrony
Да: kubelet и etcd ожидают синхронизации времени перед запуском
Реестр-прокси с кешем для доступа к образам контейнеров
docker-registry
Да
Обнаружение узлов (Discovery Service RS)
discovery-service-rs
Нет: требуется только для использования KubeSpan и KubePrism
Сетевая загрузка по iPXE
dnsmasq
Нет: возможна загрузка с ISO
Доступ реестра в интернет
-
Нет: используется только для первоначальной загрузки образов
KubeSpan и KubePrism — функции Talos Linux:
  • KubeSpan — механизм защищённого соединения узлов Talos между различными сетями;
  • KubePrism — локальный прокси Kubernetes API-сервера, обеспечивающий доступ к API внутри кластера.

Примечание

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

Примечание

Все команды этого раздела выполняются на инфраструктурном сервере от имени пользователя root.

10.1. Подготовка инфраструктурного стенда

10.1.1. Установка пакетов

Установить необходимые пакеты:
# apt-get install dhcp-server \
bind \
bind-utils \
chrony \
podman \
docker-registry \
containers-common \
net-tools \
curl \
jq \
grpcurl \
git \
talosctl \
wget \
kubernetes1.35-client \
discovery-service-rs \
helm

10.1.2. Настройка сетевых интерфейсов

Инфраструктурный сервер и узлы кластера должны находиться в одной подсети (например, 192.168.0.0/24) и быть доступны друг другу.
Узлы кластера получают адреса по DHCP (см. раздел Настройка DHCP-сервера), а инфраструктурному серверу необходимо назначить стабильный статический адрес.
В примере используется адрес 192.168.0.1. По этому адресу узлы кластера обращаются к службам инфраструктурного сервера: DHCP, DNS, NTP, реестру контейнеров и Discovery Service. Этот адрес используется далее во всех конфигурационных файлах.
Способ назначения статического адреса зависит от используемой системы управления сетью:
  • etcnet — используется по умолчанию в некоторых дистрибутивах ALT;
  • systemd-networkd — используется в других системах и может быть включён вручную.

Примечание

Имя интерфейса в примерах (ens20) необходимо заменить на фактическое имя интерфейса. Получить список интерфейсов можно командой:
$ ip link

10.1.2.1. Настройка etcnet

Для настройки сетевого интерфейса необходимо:
  1. Создать каталог конфигурации интерфейса:
    # IFACE="ens20" && mkdir -p /etc/net/ifaces/${IFACE}
    
  2. Назначить статический IPv4-адрес и маску подсети:
    # echo 192.168.0.1/24 > /etc/net/ifaces/${IFACE}/ipv4address
    
  3. Настроить параметры интерфейса (тип, протокол, автозагрузка):
    # cat > /etc/net/ifaces/${IFACE}/options <<EOF
    TYPE=eth
    CONFIG_WIRELESS=no
    BOOTPROTO=static
    CONFIG_IPV4=yes
    DISABLED=no
    NM_CONTROLLED=no
    SYSTEMD_CONTROLLED=no
    ONBOOT=yes
    EOF
    
  4. Перезапустить сетевую службу и проверить назначенный адрес:
    # systemctl restart network && ip a
    

10.1.2.2. Настройка systemd-networkd

Для настройки сетевого интерфейса необходимо:
  1. Создать каталог конфигурации:
    # mkdir -p /etc/systemd/network
    
  2. Создать файл .network со статическим IPv4-адресом:
    # cat > /etc/systemd/network/20-${IFACE}.network <<EOF
    [Match]
    Name=${IFACE}
    
    [Network]
    Address=192.168.0.1/24
    EOF
    
  3. Перечитать конфигурацию:
    # networkctl reload
    
  4. Проверить состояние интерфейса:
    # networkctl status ${IFACE} && ip a
    

10.1.3. Настройка DHCP-сервера

Примечание

На интерфейсе инфраструктурного сервера, через который обслуживаются DHCP-запросы, должен быть настроен статический IP-адрес. В примере используется адрес 192.168.0.1.
Подготовка DHCP-сервера:
  1. Создать конфигурацию DHCP-сервера с диапазоном адресов и параметрами (/etc/dhcp/dhcpd.conf):
    option space altlinux;
    option altlinux.keydata code 2 = string;
    vendor-option-space altlinux;
    
    subnet 192.168.0.0 netmask 255.255.255.0 {
        range 192.168.0.2 192.168.0.100;
        option domain-name-servers     192.168.0.1;
        option routers                 192.168.0.1;
        option broadcast-address       192.168.0.255;
        option ntp-servers             192.168.0.1;
        option subnet-mask              255.255.255.0;
    
        default-lease-time              3600;
        max-lease-time                  3600;
    
        next-server 192.168.0.1;
    }
    
  2. Включить автозапуск и запустить DHCP-сервер:
    # systemctl enable --now dhcpd
    

Примечание

Если на сервере есть интерфейсы с адресами вне подсети 192.168.0.0/24 (например, интернет-интерфейс), dhcpd может вывести предупреждение «No subnet declaration for eth0» и не будет обслуживать запросы через эти интерфейсы. Это является нормальным поведением, если DHCP-сервер используется только для закрытого контура.

10.1.4. Настройка DNS

Настроить интерфейсы и подсети, на которых BIND будет принимать DNS-запросы:
# sed -i 's|listen-on {.*|listen-on { 127.0.0.1; 192.168.0.1; };|g' \ 
  /etc/bind/options.conf
Добавить зоны прямого и обратного просмотра в конфигурацию BIND:
# cat >> /etc/bind/local.conf <<'EOF'
zone "internal.local" {
    type master;
    file "/etc/bind/zone/db.internal.local";
    allow-update { 192.168.0.0/24; };
};

zone "0.168.192.in-addr.arpa" {
    type master;
    file "/etc/bind/zone/db.192.168.0";
    allow-update { 192.168.0.0/24; };
};
EOF
Создать файл зоны прямого просмотра (A-записи):
# cat > /etc/bind/zone/db.internal.local <<'EOF'
$TTL 604800
@       IN      SOA     ns1.internal.local. admin.internal.local. (
                                2025010101 ; Serial
                                604800     ; Refresh
                                86400      ; Retry
                                2419200    ; Expire
                                604800     ; Negative Cache TTL
                                )
        IN      NS      ns1.internal.local.
ns1     IN      A       192.168.0.1
EOF
Создать файл зоны обратного просмотра (PTR-записи):
# cat > /etc/bind/zone/db.192.168.0 <<'EOF'
$TTL 604800
@       IN      SOA     ns1.internal.local. admin.internal.local. (
                                2025010101 ; Serial
                                604800     ; Refresh
                                86400      ; Retry
                                2419200    ; Expire
                                604800     ; Negative Cache TTL
                                )
        IN      NS      ns1.internal.local.
1       IN      PTR     ns1.internal.local.
EOF
Включить автозапуск и запустить службу BIND:
# systemctl enable --now bind

10.1.5. Настройка NTP

Настроить разрешение доступа для всех клиентов и указать NTP-пулы:
# cat >> /etc/chrony.conf <<'EOF'
allow all
pool pool.ntp.org iburst
EOF
Включить автозапуск службы Chrony:
# systemctl enable chronyd
Перезапустить службу Chrony:
# systemctl restart chronyd

10.1.6. Настройка прокси-кешей контейнерных образов

Примечание

Настройка прокси-кеша для всех перечисленных реестров не является обязательной. Следует настроить только те реестры контейнерных образов, которые используются в конкретном сценарии развёртывания ALT Orchestra и связанных компонентов.
Для каждого внешнего реестра создаётся отдельный экземпляр Docker Registry, работающий в режиме pull-through cache (прокси-кеш).

Таблица 10.2. Экземпляры Docker Registry

Реестр
Удалённый адрес
Порт
registry.altlinux.org
https://altlinux.space
5000
altlinux.space
https://altlinux.space
5001
При необходимости зеркалирования других реестров (например, для образов пользовательских нагрузок) необходимо добавить соответствующий экземпляр Docker Registry аналогичным образом.

Таблица 10.3. Значения для распространённых реестров

Реестр
Удалённый адрес
Порт
factory.altlinux.space
https://factory.altlinux.space
5002
ghcr.io
https://ghcr.io
5003
registry.k8s.io
https://registry.k8s.io
5004
docker.io
https://registry-1.docker.io
5005
Определить функцию, которая настраивает клиент Podman, сервер Docker Registry и systemd-службу для одного реестра:
setup_registry() {
    local registry_name="$1"
    local remote_url="$2"
    local registry_port="$3"

    # Настроить клиент Podman на использование прокси-кеша
    cat >> /etc/containers/registries.conf <<EOF
[[registry]]
location = "${registry_name}"

[[registry.mirror]]
location = "localhost:${registry_port}"
insecure = true
EOF

    # Создать конфигурацию сервера Docker Registry
    cat > /etc/docker-registry/config-${registry_name}.yml <<EOF
version: 0.1
log:
  fields:
    service: registry
storage:
  cache:
    blobdescriptor: inmemory
  filesystem:
    rootdirectory: /var/lib/docker-registry/${registry_name}
http:
  addr: ":${registry_port}"
  headers:
    X-Content-Type-Options: [nosniff]
proxy:
  remoteurl: ${remote_url}
EOF

    # Создать и включить systemd-службу
    cp /lib/systemd/system/docker-registry.service \
        /etc/systemd/system/docker-registry-${registry_name}.service
    sed -i "s|config.yml|config-${registry_name}.yml|g" \
        /etc/systemd/system/docker-registry-${registry_name}.service
    systemctl daemon-reload
    systemctl enable --now docker-registry-${registry_name}.service && \
    sleep 5 && \
    systemctl status docker-registry-${registry_name}.service --no-pager -l
}
Настроить прокси-кеши для всех реестров из таблицы Экземпляры Docker Registry :
# setup_registry registry.altlinux.org https://registry.altlinux.org 5000
# setup_registry altlinux.space https://altlinux.space 5001
После настройки прокси-кеша клиент Podman может обращаться к образам по исходному имени реестра. Например, запрос к registry.altlinux.org сначала направляется в локальный экземпляр Docker Registry (localhost:<порт>), который при отсутствии образа в кеше загружает его из внешнего реестра.
Данная конфигурация используется только программами, основанными на библиотеке containers/image (podman, skopeo, buildah, cri-o). Она не применяется автоматически к другим механизмам загрузки образов:
  • containerd использует собственную настройку зеркал через hosts.toml;
  • Docker использует настройку зеркал через daemon.json.
После настройки необходимо проверить, что все экземпляры Docker Registry запущены и прослушивают назначенные порты:
# netstat -nlpt | grep -E ':(500[0-5])'
Проверить содержимое реестров можно запросом к API Docker Registry:
# for port in 5000 5001; do
    curl -s http://localhost:${port}/v2/_catalog | jq
done
Для дополнительной проверки работы прокси-кеша рекомендуется:
  1. Загрузить образ через Podman.
  2. Проверить наличие образа в локальном реестре.
  3. Выполнить загрузку того же образа непосредственно через локальный адрес реестра.
Пример проверки работы прокси-кеша:
$ podman pull registry.altlinux.org/p11/kube-apiserver && \
curl http://localhost:5000/v2/_catalog | jq && \
curl http://localhost:5000/v2/p11/kube-apiserver/tags/list | jq && \
podman pull localhost:5000/p11/kube-apiserver

10.1.7. Настройка Discovery Service RS

Discovery Service RS используется компонентами ALT Orchestra для обнаружения узлов и обмена служебной информацией.
Запустить службу:
# systemctl enable --now discovery-service-rs.service
Сервис должен прослушивать порты:
  • 2000 — HTTP API;
  • 3000 — gRPC API.
Проверить, что служба прослушивает необходимые порты:
$ netstat -tulnp | grep '[32]000'
Ожидаемый вывод:
tcp    0    0 0.0.0.0:2000     0.0.0.0:*     LISTEN    1790/discovery-serv
tcp    0    0 0.0.0.0:3000     0.0.0.0:*     LISTEN    1790/discovery-serv

10.1.7.1. Проверка работы Discovery Service RS

Для проверки корректности работы сервиса используется gRPC-запрос Hello.
Перед выполнением запроса необходимо включить обработку заголовка X-Real-IP, чтобы адрес клиента в ответе соответствовал значению этого заголовка, а не адресу узла, подключившегося непосредственно к сервису:
# sed -i 's|# read_real_ip = false|read_real_ip = true|' \
    /etc/discovery-service-rs/discovery-service-rs.ini
После изменения конфигурации необходимо перезапустить службу:
# systemctl restart discovery-service-rs
Создать файл описания gRPC-интерфейса и выполнить запрос:
# mkdir -p proto
# cat > proto/cluster_grpc.proto << 'EOF'
syntax = "proto3";
package sidero.discovery.server;
import "google/protobuf/duration.proto";

service Cluster {
    rpc Hello(HelloRequest) returns (HelloResponse);
    rpc AffiliateUpdate(AffiliateUpdateRequest) returns (AffiliateUpdateResponse);
    rpc AffiliateDelete(AffiliateDeleteRequest) returns (AffiliateDeleteResponse);
    rpc List(ListRequest) returns (ListResponse);
    rpc Watch(WatchRequest) returns (stream WatchResponse);
}

message Affiliate {
    string id = 1;
    bytes data = 2;
    repeated bytes endpoints = 3;
}

message HelloRequest {
    string cluster_id = 1;
    string client_version = 2;
}

message RedirectMessage {
    string endpoint = 1;
}

message HelloResponse {
    optional RedirectMessage redirect = 1;
    bytes client_ip = 2;
}

message AffiliateUpdateRequest {
    string cluster_id = 1;
    string affiliate_id = 2;
    optional bytes affiliate_data = 3;
    repeated bytes affiliate_endpoints = 4;
    google.protobuf.Duration ttl = 5;
}

message AffiliateUpdateResponse {
}

message AffiliateDeleteRequest {
    string cluster_id = 1;
    string affiliate_id = 2;
}

message AffiliateDeleteResponse {
}

message ListRequest {
    string cluster_id = 1;
}

message ListResponse {
    repeated Affiliate affiliates = 1;
}

message WatchRequest {
    string cluster_id = 1;
}

message WatchResponse {
    repeated Affiliate affiliates = 1;
    bool deleted = 2;
}
EOF

# grpcurl -proto cluster_grpc.proto -import-path ./proto -plaintext \
  -d '{"clusterId": "abc", "clientVersion": "11.0"}' \
  -H 'X-Real-IP: 1.2.3.4' 192.168.0.1:3000 \
  sidero.discovery.server.Cluster/Hello
Примерный вывод:
{
"redirect": {},
"clientIp": "AQIDBA=="
}

10.2. Развертывание кластера

Загрузочный ISO-образ для узлов можно получить с помощью генератора образов.

10.2.1. Получение дисков и подготовка образов

Для каждого узла ALT Orchestra необходимо получить имя свободного диска, на который будет установлен дистрибутив:
$ for i in 2 3 4 5 6; do 
    talosctl -e 192.168.0.$i -n 192.168.0.$i get disks --insecure
done
Примерный вывод:
NODE  NAMESPACE TYPE   ID    VERSION SIZE   READ ONLY TRANSPORT ROTATIONAL WWID MODEL       SERIAL
      runtime   Disk   loop0 2       4.1 kB true
      runtime   Disk   loop1 2       98 MB  true
      runtime   Disk   sda   2        6 GB  false     virtio    true            QEMU HARDDISK
      runtime   Disk   sr0   2       377 MB false     sata                      QEMU DVD-ROM
Получить версии контейнерных образов:
REPO=p11 && \
KUBELET_VERSION="v1.34.8" && \
COREDNS_VERSION="$(curl -ks "https://registry.altlinux.org/v2/${REPO}/coredns/tags/list" | jq -r  '.tags | sort | .[]' | tail -1)" && \
ETCD_VERSION="$(curl -ks "https://registry.altlinux.org/v2/${REPO}/etcd/tags/list" | jq -r  '.tags | sort | .[]' | tail -1)" && \
PAUSE_VERSION="$(curl -ks "https://registry.altlinux.org/v2/${REPO}/pause/tags/list" | jq -r  '.tags | sort | .[]' | tail -1)"
Задать основные переменные:
DEVICE="/dev/sda" && \
INSTALLERIMAGE="altlinux.space/alt-orchestra/installer:v11.0"
Значение /dev/sda необходимо заменить на имя диска из вывода команды talosctl get disks (например, /dev/vda для дисков типа VirtIO).
Образ установщика также можно получить с помощью генератора образов. При необходимости его можно собрать вручную.
Если требуется установить системные расширения, необходимо использовать образ установщика со встроенными расширениями.
Получить имена образов основных компонентов Kubernetes:
KUBELETIMAGE="registry.altlinux.org/${REPO}/kubelet:${KUBELET_VERSION}" && \
APISERVERIMAGE="registry.altlinux.org/${REPO}/kube-apiserver:${KUBELET_VERSION}" && \
CONTROLMANAGERIMAGE="registry.altlinux.org/${REPO}/kube-controller-manager:${KUBELET_VERSION}" && \
SCHEDULERIMAGE="registry.altlinux.org/${REPO}/kube-scheduler:${KUBELET_VERSION}" && \
COREDNSIMAGE="registry.altlinux.org/${REPO}/coredns:${COREDNS_VERSION}" && \
ETCDIMAGE="registry.altlinux.org/${REPO}/etcd:${ETCD_VERSION}" && \
PAUSEIMAGE="registry.altlinux.org/${REPO}/pause:${PAUSE_VERSION}"
Загрузить контейнерные образы:
$ for image in \
  ${KUBELETIMAGE} \
  ${APISERVERIMAGE} \
  ${CONTROLMANAGERIMAGE} \
  ${SCHEDULERIMAGE} \
  ${COREDNSIMAGE} \
  ${ETCDIMAGE} \
  ${PAUSEIMAGE} \
  ${INSTALLERIMAGE};
do
  podman pull $image;
done

Примечание

Предварительная загрузка образов с помощью podman pull не является обязательной. Если настроен прокси-кеш реестров, необходимые образы будут автоматически загружены при первом обращении.
Проверить наличие образов в локальном кеше:
$ curl http://localhost:5000/v2/_catalog | jq
$ curl http://localhost:5001/v2/_catalog | jq

10.2.2. Подготовка конфигурации кластера

Создать общий патч конфигурации:
$ cat > patch_common.yaml << PATCH
cluster:
  network:
    cni:
      name: none
  proxy:
    disabled: true
  discovery:
    enabled: true
    registries:
      kubernetes:
        disabled: true
      service:
        endpoint: http://192.168.0.1:3000
machine:
  time:
    servers:
      - 192.168.0.1
  network:
    nameservers:
      - 192.168.0.1
  install:
    disk: ${DEVICE}
    image: ${INSTALLERIMAGE}
  kubelet:
    image: ${KUBELETIMAGE}
  registries:
    mirrors:
      registry.altlinux.org:
        endpoints:
          - http://192.168.0.1:5000
      altlinux.space:
        endpoints:
          - http://192.168.0.1:5001
PATCH
Создать патч конфигурации для узлов Control Plane:
$ cat > patch_controlplane.yaml << PATCH
machine:
  network:
    interfaces:
      - deviceSelector:
          physical: true
        dhcp: true
        vip:
          ip: 192.168.0.200
cluster:
  apiServer:
    image: ${APISERVERIMAGE}
  controllerManager:
    image: ${CONTROLMANAGERIMAGE}
  scheduler:
    image: ${SCHEDULERIMAGE}
  etcd:
    image: ${ETCDIMAGE}
  coreDNS:
    image: ${COREDNSIMAGE}
PATCH
Сгенерировать конфигурацию ALT Orchestra с отключённым kube-proxy (патчи применяются при генерации):
$ talosctl gen config talos https://192.168.0.200:6443 \
    --config-patch @patch_common.yaml \
    --config-patch-control-plane @patch_controlplane.yaml
Endpoint Kubernetes API — виртуальный IP-адрес 192.168.0.200 (подробнее см. Работа с Virtual (Shared) IP). Для доступа к API Talos (talosctl) виртуальный IP-адрес не используется.
Объединить talosconfig с конфигурацией по умолчанию:
$ talosctl config merge talosconfig
Установить текущий контекст talos и проверить конфигурацию:
$ talosctl config context talos
$ talosctl config info

10.2.3. Применение конфигурации и инициализация кластера

Применить конфигурацию к каждому узлу Control Plane:
$ talosctl apply-config --insecure -n 192.168.0.2 --file controlplane.yaml
$ talosctl apply-config --insecure -n 192.168.0.3 --file controlplane.yaml
$ talosctl apply-config --insecure -n 192.168.0.4 --file controlplane.yaml
Применить конфигурацию к каждому узлу Worker:
$ talosctl apply-config --insecure -n 192.168.0.5 --file worker.yaml
$ talosctl apply-config --insecure -n 192.168.0.6 --file worker.yaml
Выполнить bootstrap для инициализации кластера etcd:
$ talosctl -e 192.168.0.2 -n 192.168.0.2 bootstrap
Команду bootstrap необходимо выполнить только на одном узле Control Plane.
Получить kubeconfig для доступа к Kubernetes:
$ talosctl -e 192.168.0.2 -n 192.168.0.2 kubeconfig

10.2.4. Установка Cilium

Установить Cilium через Helm:
$ curl https://altlinux.space/cloud/charts/raw/branch/master/cilium/sisyphus/1.18.2/values.yaml -o cilium-values.yaml

$ sed -i '/genericDigest: "sha256:a573bf42c0199aef9c68b657b2ea53cc31293a0a6eb2e812604cc8c31f846db0"/d' cilium-values.yaml

$ sed -i "s|useDigest: true|useDigest: false|g" cilium-values.yaml
$ helm repo add cilium https://helm.cilium.io
$ helm repo update
$ helm install \
  cilium \
  cilium/cilium \
  --version 1.18.2 \
  --namespace kube-system \
  --set ipam.mode=kubernetes \
  --set kubeProxyReplacement=true \
  --set securityContext.capabilities.ciliumAgent="{CHOWN,KILL,NET_ADMIN,NET_RAW,IPC_LOCK,SYS_ADMIN,SYS_RESOURCE,DAC_OVERRIDE,FOWNER,SETGID,SETUID}" \
  --set securityContext.capabilities.cleanCiliumState="{NET_ADMIN,SYS_ADMIN,SYS_RESOURCE}" \
  --set cgroup.autoMount.enabled=false \
  --set cgroup.hostRoot=/sys/fs/cgroup \
  --set k8sServiceHost=localhost \
  --set k8sServicePort=7445 \
  -f cilium-values.yaml

10.2.5. Проверка кластера

Проверить готовность узлов:
$ kubectl get nodes
Примерный вывод:
NAME                    STATUS   ROLES           AGE   VERSION
alt-orchestra-2n9-fm5   Ready    <none>          69s   v1.34.8
alt-orchestra-4ty-xyj   Ready    control-plane   70s   v1.34.8
alt-orchestra-861-o83   Ready    <none>          61s   v1.34.8
alt-orchestra-9v7-0p2   Ready    control-plane   63s   v1.34.8
alt-orchestra-kus-sds   Ready    control-plane   67s   v1.34.8
Получить список всех подов в кластере:
$ kubectl get pods -A
Примерный вывод:
NAMESPACE     NAME                                            READY   STATUS    RESTARTS       AGE
kube-system   cilium-2jvb4                                    1/1     Running   0              112s
kube-system   cilium-4xrlg                                    1/1     Running   1 (52s ago)    112s
kube-system   cilium-9nspx                                    1/1     Running   0              112s
kube-system   cilium-9zb6v                                    1/1     Running   0              113s
kube-system   cilium-cp96k                                    1/1     Running   0              113s
kube-system   cilium-envoy-2m8wp                              1/1     Running   0              112s
kube-system   cilium-envoy-4mx5h                              1/1     Running   0              113s
kube-system   cilium-envoy-g8qh5                              1/1     Running   0              112s
kube-system   cilium-envoy-xffdn                              1/1     Running   0              113s
kube-system   cilium-envoy-z8xw6                              1/1     Running   0              113s
kube-system   cilium-operator-67f4b4f5fd-9djtg                1/1     Running   1 (82s ago)    112s
kube-system   cilium-operator-67f4b4f5fd-wkjdq                1/1     Running   1 (69s ago)    113s
kube-system   coredns-5966c6bdcd-2gxvq                        1/1     Running   0              3m43s
kube-system   coredns-5966c6bdcd-qfmn2                        1/1     Running   0              3m43s
kube-system   kube-apiserver-alt-orchestra-27m-03d            1/1     Running   0              3m30s
kube-system   kube-apiserver-alt-orchestra-gpg-qkl            1/1     Running   0              3m36s
kube-system   kube-apiserver-alt-orchestra-urk-gud            1/1     Running   0              2m59s
kube-system   kube-controller-manager-alt-orchestra-27m-03d   1/1     Running   0              3m30s
kube-system   kube-controller-manager-alt-orchestra-gpg-qkl   1/1     Running   1 (96s ago)    3m36s
kube-system   kube-controller-manager-alt-orchestra-urk-gud   1/1     Running   2 (4m3s ago)   2m59s
kube-system   kube-scheduler-alt-orchestra-27m-03d            1/1     Running   0              3m30s
kube-system   kube-scheduler-alt-orchestra-gpg-qkl            1/1     Running   0              3m36s
kube-system   kube-scheduler-alt-orchestra-urk-gud            1/1     Running   4 (58s ago)    2m58s
Вывести список всех ресурсов во всех пространствах имён кластера Kubernetes:
$ kubectl get all -A
Примерный вывод:
NAMESPACE     NAME                                                READY   STATUS    RESTARTS        AGE
kube-system   pod/cilium-2jvb4                                    1/1     Running   0               2m11s
kube-system   pod/cilium-4xrlg                                    1/1     Running   1 (71s ago)     2m11s
kube-system   pod/cilium-9nspx                                    1/1     Running   0               2m11s
kube-system   pod/cilium-9zb6v                                    1/1     Running   0               2m12s
kube-system   pod/cilium-cp96k                                    1/1     Running   0               2m12s
kube-system   pod/cilium-envoy-2m8wp                              1/1     Running   0               2m11s
kube-system   pod/cilium-envoy-4mx5h                              1/1     Running   0               2m12s
kube-system   pod/cilium-envoy-g8qh5                              1/1     Running   0               2m11s
kube-system   pod/cilium-envoy-xffdn                              1/1     Running   0               2m12s
kube-system   pod/cilium-envoy-z8xw6                              1/1     Running   0               2m12s
kube-system   pod/cilium-operator-67f4b4f5fd-9djtg                1/1     Running   1 (101s ago)    2m11s
kube-system   pod/cilium-operator-67f4b4f5fd-wkjdq                1/1     Running   1 (88s ago)     2m12s
kube-system   pod/coredns-5966c6bdcd-2gxvq                        1/1     Running   0               4m2s
kube-system   pod/coredns-5966c6bdcd-qfmn2                        1/1     Running   0               4m2s
kube-system   pod/kube-apiserver-alt-orchestra-27m-03d            1/1     Running   0               3m49s
kube-system   pod/kube-apiserver-alt-orchestra-gpg-qkl            1/1     Running   0               3m55s
kube-system   pod/kube-apiserver-alt-orchestra-urk-gud            1/1     Running   0               3m18s
kube-system   pod/kube-controller-manager-alt-orchestra-27m-03d   1/1     Running   0               3m49s
kube-system   pod/kube-controller-manager-alt-orchestra-gpg-qkl   1/1     Running   1 (115s ago)    3m55s
kube-system   pod/kube-controller-manager-alt-orchestra-urk-gud   1/1     Running   2 (4m22s ago)   3m18s
kube-system   pod/kube-scheduler-alt-orchestra-27m-03d            1/1     Running   0               3m49s
kube-system   pod/kube-scheduler-alt-orchestra-gpg-qkl            1/1     Running   0               3m55s
kube-system   pod/kube-scheduler-alt-orchestra-urk-gud            1/1     Running   4 (77s ago)     3m17s

NAMESPACE     NAME                   TYPE        CLUSTER-IP     EXTERNAL-IP   PORT(S)                  AGE
default       service/kubernetes     ClusterIP   10.96.0.1      <none>        443/TCP                  5m32s
kube-system   service/cilium-envoy   ClusterIP   None           <none>        9964/TCP                 2m12s
kube-system   service/hubble-peer    ClusterIP   10.110.143.8   <none>        443/TCP                  2m12s
kube-system   service/kube-dns       ClusterIP   10.96.0.10     <none>        53/UDP,53/TCP,9153/TCP   4m16s

NAMESPACE     NAME                          DESIRED   CURRENT   READY   UP-TO-DATE   AVAILABLE   NODE SELECTOR            AGE
kube-system   daemonset.apps/cilium         5         5         5       5            5           kubernetes.io/os=linux   2m12s
kube-system   daemonset.apps/cilium-envoy   5         5         5       5            5           kubernetes.io/os=linux   2m12s

NAMESPACE     NAME                              READY   UP-TO-DATE   AVAILABLE   AGE
kube-system   deployment.apps/cilium-operator   2/2     2            2           2m12s
kube-system   deployment.apps/coredns           2/2     2            2           4m16s

NAMESPACE     NAME                                         DESIRED   CURRENT   READY   AGE
kube-system   replicaset.apps/cilium-operator-67f4b4f5fd   2         2         2       2m12s
kube-system   replicaset.apps/coredns-5966c6bdcd           2         2         2       4m2s
Получить список сервисов (services) во всех пространствах имён (namespaces) в кластере Kubernetes:
$ kubectl get svc -A
Примерный вывод:
NAMESPACE    NAME         TYPE        CLUSTER-IP   EXTERNAL-IP  PORT(S)                  AGE
default      kubernetes   ClusterIP   10.96.0.1    <none>       443/TCP                  6m2s
kube-system  cilium-envoy ClusterIP   None         <none>       9964/TCP                 2m42s
kube-system  hubble-peer  ClusterIP   10.110.143.8 <none>       443/TCP                  2m42s
kube-system  kube-dns     ClusterIP   10.96.0.10   <none>       53/UDP,53/TCP,9153/TCP   4m46s
kube-system  hubble-relay ClusterIP   10.109.3.163 <none>       80/TCP                   2m42s
kube-system  hubble-ui    ClusterIP   10.97.174.183 <none>      80/TCP                   2m42s
Изменить конфигурацию endpoint:
$ talosctl config endpoint 192.168.0.2 192.168.0.3 192.168.0.4
Вывести информацию о сервисах, работающих на узлах ALT Orchestra, включая их имена, состояние и конфигурацию:
$ talosctl -n 192.168.0.2 service
$ talosctl -n 192.168.0.3 service
$ talosctl -n 192.168.0.4 service
$ talosctl -n 192.168.0.5 service
$ talosctl -n 192.168.0.6 service
Примерный вывод для Control Plane:
NODE          SERVICE     STATE     HEALTH  LAST CHANGE   LAST EVENT
192.168.0.4   apid       Running  OK      5m41s ago   Health check successful
192.168.0.4   auditd     Running  OK      5m52s ago   Health check successful
192.168.0.4   containerd Running  OK      5m52s ago   Health check successful
192.168.0.4   cri        Running  OK      5m41s ago   Health check successful
192.168.0.4   dashboard  Running  ?       5m42s ago   Process Process(["/sbin/dashboard"]) started with PID 2204
192.168.0.4   etcd       Running  OK      3m37s ago   Health check successful
192.168.0.4   kubelet    Running  OK      5m35s ago   Health check successful
192.168.0.4   machined   Running  OK      5m52s ago   Health check successful
192.168.0.4   syslogd    Running  OK      5m51s ago   Health check successful
192.168.0.4   trustd     Running  OK      5m41s ago   Health check successful
192.168.0.4   udevd      Running  OK      5m43s ago   Health check successful
Примерный вывод для Control Worker:
NODE          SERVICE     STATE     HEALTH  LAST CHANGE  LAST EVENT
192.168.0.5   apid        Running  OK     5m40s ago    Health check successful
192.168.0.5   auditd      Running  OK     5m48s ago    Health check successful
192.168.0.5   containerd  Running  OK     5m48s ago    Health check successful
192.168.0.5   cri         Running  OK     5m39s ago    Health check successful
192.168.0.5   dashboard   Running  ?      5m41s ago    Process Process(["/sbin/dashboard"]) started with PID 2094
192.168.0.5   kubelet     Running  OK     5m34s ago    Health check successful
192.168.0.5   machined    Running  OK     5m48s ago    Health check successful
192.168.0.5   syslogd     Running  OK     5m47s ago    Health check successful
192.168.0.5   udevd       Running  OK     5m42s ago    Health check successful
Получить информацию о членах кластера ALT Orchestra:
$ talosctl get members -n 192.168.0.2 -e 192.168.0.2
$ talosctl get members -n 192.168.0.3 -e 192.168.0.3
$ talosctl get members -n 192.168.0.4 -e 192.168.0.4
$ talosctl get members -n 192.168.0.5 -e 192.168.0.5
$ talosctl get members -n 192.168.0.6 -e 192.168.0.6
Присутствуют все узлы кластера:
NODE          NAMESPACE   TYPE     ID                      VERSION  HOSTNAME               MACHINE TYPE   OS                      ADDRESSES
192.168.0.2   cluster   Member   alt-orchestra-4nl-pux   1        alt-orchestra-4nl-pux  controlplane   ALT Orchestra (v11.0)   ["192.168.0.2"]
192.168.0.2   cluster   Member   alt-orchestra-8vo-85l   1        alt-orchestra-8vo-85l  controlplane   ALT Orchestra (v11.0)   ["192.168.0.3"]
192.168.0.2   cluster   Member   alt-orchestra-hku-1uk   1        alt-orchestra-hku-1uk  worker         ALT Orchestra (v11.0)   ["192.168.0.5"]
192.168.0.2   cluster   Member   alt-orchestra-tab-x0d   1        alt-orchestra-tab-x0d  worker         ALT Orchestra (v11.0)   ["192.168.0.6"]
192.168.0.2   cluster   Member   alt-orchestra-y3q-ik2   1        alt-orchestra-y3q-ik2  controlplane   ALT Orchestra (v11.0)   ["192.168.0.4"]
Выполнить healthcheck для узлов Control Plane:
$ talosctl health -n 192.168.0.2
$ talosctl health -n 192.168.0.3
$ talosctl health -n 192.168.0.4

10.3. Ручное обновление кластера

Получить текущую версию Kubernetes:
$ kubectl get nodes -o jsonpath='{.items[0].status.nodeInfo.kubeletVersion}'
Вывод:
v1.34.8
Загрузить в прокси-кеш образы целевой версии Kubernetes (узлы в закрытом контуре скачивают образы только через прокси-кеш):
REPO=p11 && \
KUBELET_VERSION="v1.35.5" && \
KUBELETIMAGE="registry.altlinux.org/${REPO}/kubelet:${KUBELET_VERSION}" && \
APISERVERIMAGE="registry.altlinux.org/${REPO}/kube-apiserver:${KUBELET_VERSION}" && \
CONTROLMANAGERIMAGE="registry.altlinux.org/${REPO}/kube-controller-manager:${KUBELET_VERSION}" && \
SCHEDULERIMAGE="registry.altlinux.org/${REPO}/kube-scheduler:${KUBELET_VERSION}"

$ for image in ${KUBELETIMAGE} ${APISERVERIMAGE} ${CONTROLMANAGERIMAGE} ${SCHEDULERIMAGE}
do
    podman pull "$image"
done
Проверить наличие загруженных образов в кеше:
$ podman images
Обновить кластер Kubernetes до версии 1.35.5 (upgrade-k8s выполняет переход на одну минорную версию за раз):
$ talosctl --nodes 192.168.0.2 upgrade-k8s --to 1.35.5

Примечание

Поддерживаемые версии Kubernetes перечислены в матрице поддержки.
Примерный вывод во время обновления одной машины:
…
 > "192.168.0.4": starting update
 > update kube-scheduler: v1.35.0 -> 1.35.5
 > "192.168.0.4": machine configuration patched
 > "192.168.0.4": waiting for kube-scheduler pod update
 > "192.168.0.4": kube-scheduler: waiting, config version mismatch: got "1", expected "2"
 > "192.168.0.4": kube-scheduler: waiting, config version mismatch: got "1", expected "2"
 > "192.168.0.4": kube-scheduler: waiting, config version mismatch: got "1", expected "2"
 > "192.168.0.4": kube-scheduler: waiting, config version mismatch: got "1", expected "2"
 > "192.168.0.4": kube-scheduler: pod is not ready, waiting
 > "192.168.0.4": kube-scheduler: pod is not ready, waiting
 > "192.168.0.4": kube-scheduler: pod is not ready, waiting
 < "192.168.0.4": successfully updated
…
Кластер успешно обновился до версии Kubernetes v1.35.5:
…
 > processing manifest v1.Secret/kube-system/bootstrap-token-u8gr7g
 < no changes
 > processing manifest rbac.authorization.k8s.io/v1.ClusterRoleBinding/system-bootstrap-approve-node-client-csr
 < no changes
 > processing manifest rbac.authorization.k8s.io/v1.ClusterRoleBinding/system-bootstrap-node-bootstrapper
 < no changes
 > processing manifest rbac.authorization.k8s.io/v1.ClusterRoleBinding/system-bootstrap-node-renewal
 < no changes
. . . . .
 < applied successfully
 > processing manifest v1.ServiceAccount/kube-system/coredns
 < no changes
 > processing manifest rbac.authorization.k8s.io/v1.ClusterRoleBinding/system:coredns
 < no changes
 > processing manifest rbac.authorization.k8s.io/v1.ClusterRole/system:coredns
 < no changes
 > processing manifest v1.ConfigMap/kube-system/coredns
 < no changes
 > processing manifest apps/v1.Deployment/kube-system/coredns
 < no changes
 > processing manifest v1.Service/kube-system/kube-dns
 < no changes
 > processing manifest v1.ConfigMap/kube-system/kubeconfig-in-cluster
 < no changes
waiting for all manifests to be applied

Получить текущую версию кластера:
$ kubectl get nodes -o jsonpath='{.items[0].status.nodeInfo.kubeletVersion}'
Вывод:
v1.35.5
Убедиться, что все узлы обновлены до версии v1.35.5:
$ kubectl get nodes
Вывести список всех ресурсов во всех пространствах имён кластера Kubernetes:
$ kubectl get all -A
Все рабочие поды должны находиться в состоянии Running.
Выполнить healthcheck для узлов Control Plane:
$ talosctl health --nodes 192.168.0.2
$ talosctl health --nodes 192.168.0.3
$ talosctl health --nodes 192.168.0.4

Глава 11. Загрузка в режиме Secure Boot на платформах UEFI

ALT Orchestra поддерживает загрузку на системах UEFI в режиме Secure Boot. В сочетании с шифрованием диска на основе TPM это обеспечивает доверенную загрузку.

Примечание

Secure Boot не поддерживается на x86-платформах в режиме BIOS.
Реализация использует systemd-boot в качестве интерфейса загрузочного меню. Ядро ALT Orchestra, его аргументы и initramfs объединены в единый образ — Unified Kernel Image (UKI). Прошивка UEFI загружает загрузчик systemd-boot, который, в свою очередь, загружает UKI-образ. И systemd-boot, и UKI-образ ALT Orchestra подписываются ключом, который предварительно добавляется (enrolled) в прошивку UEFI.
Поскольку ОС ALT Orchestra полностью содержится в UKI-образе, её целостность проверяется на этапе загрузки, а запуск выполняется непосредственно прошивкой UEFI.
Образы ALT Orchestra подписываются собственным ключом компании, поэтому полезным свойством среды установки будет Enroll Secure Boot keys: auto.
Общие требования для загрузки в режиме Secure Boot:
  • образ ALT Orchestra с поддержкой Secure Boot;
  • среда установки поддерживает функции Secure Boot;;
  • среда установки поддерживает UEFI;
  • наличие в среде установки чипа TPM 2.0 (в случае необходимости шифрования диска).

Примечание

Обновление существующей установки ALT Orchestra, использующей GRUB (без UKI), до режима UKI/Secure Boot в настоящий момент не поддерживается. Требуется чистая установка.

11.1. Secure Boot с образами ALT Orchestra

Образы ALT Orchestra, подписанные официальным ключом «Базальт СПО», можно получить с помощью генератора образов (factory.altlinux.space). Для этого в окне выбора архитектуры необходимо включить переключатель SecureBoot и далее выбрать тип загрузчика с поддержкой UEFI:
Переключатель SecureBoot
В результате будут сгенерированы ссылки на образы вида:
  • дистрибутив alt-orchestra-<VERSION>-metal-amd64-secureboot.iso
  • установщик factory.altlinux.space/alt-orchestra-metal-installer-secureboot/…:<VERSION>
Самый простой способ начать работу с Secure Boot — скачать ISO-образ и загрузить его на системе с включённым UEFI и активированным Secure Boot.
Для первой загрузки прошивка UEFI должна находиться в режиме настройки (setup mode), чтобы ключи могли быть автоматически добавлены.
Если прошивка не поддерживает автоматическое добавление ключей, может потребоваться нажать Esc, чтобы вызвать меню загрузки, и выбрать опцию:
Enroll Secure Boot keys: auto
Загрузчик ISO автоматически добавит необходимые ключи в прошивку UEFI и запустит ALT Orchestra в режиме Secure Boot.
Установку следует выполнять с использованием специального установщика для Secure Boot:
factory.altlinux.space/alt-orchestra-metal-installer-secureboot/376567988ad370138ad8b2698212367b8edcb69b5fd68c80be1f2ec7d603b4ba:v11.0

Примечание

Образы Secure Boot также можно генерировать с использованием пользовательских ключей.

11.2. Настройка среды установки

Среда установки должна поддерживать режимы установки UEFI и SecureBoot, а также (при необходимости) содержать чип TPM.
Для виртуальных машин следует подключить микропрограмму UEFI и выбрать чипсет Q35. При необходимости следует добавить эмуляцию чипа TPM. Далее можно запускать установку образа.
Для запуска виртуальной машины с помощью qemu или virt-manager необходимо использовать /usr/share/OVMF/OVMF_CODE_4M.secboot.qcow2 в режиме readonly и скопированный в рабочий каталог /usr/share/OVMF/OVMF_VARS_4M.qcow2. Необходимо использовать именно копию файла OVMF_VARS_4M.qcow2, поскольку переменные UEFI изменяются во время работы виртуальной машины.
Пример запуска с помощью qemu:
$ cp /usr/share/OVMF/OVMF_VARS_4M.qcow2 /tmp/my_vm_ovmf_vars_4m.qcow2
$ qemu-system-x86_64 \
  ... \
  -machine q35 \
  -drive if=pflash,format=qcow2,readonly=on,file=/usr/share/OVMF/OVMF_CODE_4M.secboot.qcow2 \
  -drive if=pflash,format=qcow2,file=/tmp/my_vm_ovmf_vars_4m.qcow2
Если в системе отсутствует функция автоматической загрузки ключей Secure Boot (Autoenroll Secure Boot Keys), загрузчик предложит вручную импортировать ключи.
Для ручной загрузки ключей необходимо перейти: Boot Manager MenuEFI Firmware SetupDevice ManagerSecure Boot Configuration. Если параметр Current Secure Boot State имеет значение Enabled, необходимо выполнить команду Reset Secure Boot Keys.
Далее необходимо:
  1. Установить параметр Secure Boot Mode в значение Custom Mode.
  2. Перейти в раздел Custom Secure Boot Options.
  3. Для ключей PK, KEK и DB выполнить:
    Enroll ... Using File -> EFI -> <EFI>/<keys>/uki-signing-cert.der
    
  4. Выбрать Commit Changes and Exit.
После этого можно сохранить изменения клавишей F10 и продолжить установку.

11.2.1. Особенности установки на PVE

В настройках системы (Создать: Виртуальная машинаСистема) для корректной загрузки в режиме Secure Boot требуется указать:
  • Машина = q35
  • BIOS = OVMF (UEFI)
  • установить отметку Добавить диск EFI;
  • выбрать Хранилище EFI;
  • снять отметку Предварительная загрузка ключей;
  • установить отметку Добавить доверенный платформенный модуль и выбрать Хранилище доверенного платформенного модуля (при необходимости шифрования диска).
Создание ВМ с Secure Boot и TPM
Также по аналогии можно отредактировать настройки ранее созданной виртуальной машины в разделе Оборудование.

11.3. Загрузка ALT Orchestra в режиме Secure Boot

В данном разделе используется ISO-образ для загрузки ALT Orchestra в режиме Secure Boot, после чего конфигурация передаётся машине, работающей в режиме обслуживания (maintenance mode).
Рассматривается один из вариантов генерации и применения конфигурации.

11.3.1. Проверка состояния Secure Boot

После загрузки ALT Orchestra в режиме обслуживания убедитесь, что Secure Boot активен:
$ talosctl -n <IP-адрес-узла> get securitystate --insecure
Пример:
$ talosctl -n 192.168.0.222 get securitystate --insecure
Ожидаемый вывод:
NODE  NAMESPACE  TYPE           ID             SECUREBOOT
runtime    SecurityState  securitystate  true
На панели управления узла ALT Orchestra также будет отображаться, что SecureBoot включен:
SecureBoot включен

11.3.2. Конфигурация только Secure Boot (без TPM)

Этот сценарий используется для проверки загрузки системы в режиме Secure Boot без шифрования диска.
На этапе генерации конфигурации необходимо указать верную ссылку на установщик:
$ talosctl gen config <cluster-name> https://<endpoint>:6443 \
  --install-image=<secureboot-image> \
  --install-disk=/dev/sda
Пример:
$ CONTROL_PLANE_IP=192.168.0.222
$ export CLUSTER_NAME=security-cluster
$ export BASE_REGISTRY="factory.altlinux.space"
$ export INSTALLERIMAGE="$BASE_REGISTRY/alt-orchestra-metal-installer-secureboot/376567988ad370138ad8b2698212367b8edcb69b5fd68c80be1f2ec7d603b4ba:v11.0"
$ export DISK_NAME=/dev/vda

$ talosctl gen config $CLUSTER_NAME https://$CONTROL_PLANE_IP:6443 \
  --output-dir _security \
  --install-image $INSTALLERIMAGE \
  --install-disk=$DISK_NAME
Применение конфигурации:
$ talosctl -n <IP-адрес-узла> apply-config --insecure -f controlplane.yaml
Пример:
$ talosctl apply-config --insecure \
  --nodes $CONTROL_PLANE_IP \
  --file _security/controlplane.yaml
После применения конфигурации система установится на диск и перезагрузится.
После установки проверьте, что узел работает в режиме Secure Boot:
$ talosctl -n <IP-адрес-узла> --talosconfig=<talosconfig> get securitystate
Пример:
$ talosctl -n $CONTROL_PLANE_IP \
  --talosconfig=_security/talosconfig get securitystate
Ожидаемый вывод:
NODE           NAMESPACE  TYPE           ID             SECUREBOOT
192.168.0.222  runtime    SecurityState  securitystate  true
Узел работает в режиме Secure Boot

Примечание

Команду talosctl get securitystate следует выполнять после того, как узел полностью загрузился и стал доступен по сети, то есть после перезагрузки, вызванной apply-config. Ошибка failed to determine endpoints означает, что:
  • узел ещё не завершил начальную загрузку;
  • talosconfig не содержит корректных endpoint'ов (IP-адресов узлов).

11.3.3. Настройка шифрования диска с использованием TPM

Этот сценарий обеспечивает полноценный Trusted Boot за счёт использования TPM для защиты ключей шифрования.

Примечание

Требуется TPM версии 2.0.

Примечание

При использовании TPM потеря ключей подписи (UKI или PCR) приведёт к невозможности загрузки системы и расшифровки данных.
Для настройки шифрования сгенерируйте конфигурацию с образом installer-secureboot и примените патч для включения TPM-шифрования диска.
Файл tpm-disk-encryption.yaml:
machine:
  systemDiskEncryption:
    ephemeral:
      provider: luks2
      keys:
        - slot: 0
          tpm: {}
    state:
      provider: luks2
      keys:
        - slot: 0
          tpm: {}
Генерация конфигурации:
$ talosctl gen config <cluster-name> https://<endpoint>:6443 \
  --install-image=<secureboot-image> \
  --install-disk=/dev/sda \
  --config-patch @tpm-disk-encryption.yaml
Пример:
$ CONTROL_PLANE_IP=192.168.0.194
$ export CLUSTER_NAME=security-cluster
$ export BASE_REGISTRY="factory.altlinux.space"
$ export INSTALLERIMAGE="$BASE_REGISTRY/alt-orchestra-metal-installer-secureboot/376567988ad370138ad8b2698212367b8edcb69b5fd68c80be1f2ec7d603b4ba:v11.0"
$ export DISK_NAME=/dev/vda

$ talosctl gen config $CLUSTER_NAME https://$CONTROL_PLANE_IP:6443 \
  --output-dir _tpm \
  --install-image $INSTALLERIMAGE \
  --config-patch @tpm-disk-encryption.yaml  \
  --install-disk=$DISK_NAME
Применение конфигурации:
$ talosctl -n <IP-адрес-узла> apply-config --insecure -f controlplane.yaml
Пример:
$ talosctl apply-config --insecure \
  --nodes $CONTROL_PLANE_IP \
  --file _tpm/controlplane.yaml
После применения конфигурации система установится на диск и перезагрузится.
После установки проверьте, что узел работает в режиме Secure Boot:
$ talosctl -n <IP-адрес-узла> --talosconfig=<talosconfig> get securitystate

11.4. Обновление ALT Orchestra

Любое изменение загрузочных компонентов (ядро, initramfs, параметры командной строки) требует пересборки UKI-образа и нового образа установщика.
После размещения нового образа в реестре выполните обновление узла с его использованием.

Важно

Необходимо сохранять:
  • ключ подписи UKI;
  • ключ подписи PCR.
Иначе узел не сможет загрузиться и расшифровать зашифрованные разделы.

11.5. Шифрование диска с использованием TPM

При первом шифровании раздела ALT Orchestra генерирует случайный ключ шифрования и «запечатывает» (seals) его с помощью устройства TPM. Политика расшифровки настраивается так, чтобы доверять ожидаемой политике, подписанной ключом подписи PCR.
Таким образом, расшифровка не зависит от точных значений PCR-регистров, а основывается на:
  • подписанной политике;
  • состоянии Secure Boot (измерения в PCR7, включая статус Secure Boot и список добавленных ключей).
При генерации UKI-образа его хеш и ожидаемые значения PCR объединяются в политику расшифровки и подписываются ключом PCR. Во время загрузки компонент systemd-stub записывает измерения секций UKI в TPM. ALT Orchestra дополняет регистры PCR измерениями этапов загрузки, и при монтировании зашифрованного раздела сравнивает подписанную политику с фактическими измерениями. При совпадении TPM распечатывает ключ шифрования, который используется для расшифровки диска.
При обновлении, если новый UKI подписан тем же ключом PCR и состояние Secure Boot не изменилось, раздел будет успешно расшифрован.
Шифрование также привязано к состоянию PCR7, поэтому расшифровка возможна только если:
  • Secure Boot включён;
  • набор добавленных ключей не изменился.

11.6. Другие варианты загрузки

Unified Kernel Image (UKI) — это образ, пригодный для прямой загрузки прошивкой UEFI без использования systemd-boot. В сетевой загрузке (PXE) UKI также может использоваться напрямую, так как содержит все необходимые компоненты для запуска ALT Orchestra.

Важно

При включённом Secure Boot UKI игнорирует внешние параметры командной строки ядра и использует только те, что встроены в сам образ. Для изменения параметров требуется пересборка UKI.

11.7. Secure Boot с пользовательскими ключами

11.7.1. Генерация ключей

Для работы Secure Boot в ALT Orchestra требуются два набора ключей:
  • ключ Secure Boot — используется для подписи загрузочных компонентов и добавляется в UEFI;
  • ключ подписи PCR — используется для подписи политики TPM, применяемой при расшифровке диска.
Хотя для обеих целей можно использовать один и тот же ключ, рекомендуется применять раздельные ключи.
Генерация ключа Secure Boot (можно также использовать существующую PKI):
$ talosctl gen secureboot uki --common-name "SecureBoot Key"
Результат:
  writing _out/uki-signing-cert.pem
  writing _out/uki-signing-cert.der
  writing _out/uki-signing-key.pem
В результате генерируются:
  • сертификат и закрытый ключ в формате PEM (RSA, 4096 бит);
  • сертификат в формате DER (для совместимости).
Генерация ключа PCR:
$ talosctl gen secureboot pcr
Результат:
  writing _out/pcr-signing-key.pem
В результате генерируется ключ RSA, 2048 бит, в формате PEM.
Опционально можно сгенерировать базу данных UEFI для автоматического добавления ключей:
$ talosctl gen secureboot database
Результат:
  writing _out/db.auth
  writing _out/KEK.auth
  writing _out/PK.auth
Эти файлы используются при загрузке с ISO-образа в режиме настройки UEFI.

Примечание

По умолчанию talosctl gen secureboot создаёт самоподписанный сертификат. При необходимости его можно заменить сертификатом, соответствующим корпоративной PKI.

11.7.2. Генерация загрузочных образов с Secure Boot

После генерации ключей их можно использовать для подписи компонентов ALT Orchestra и создания ISO-образов, PXE-образов, установщиков и т.д.
Генерация ISO-образа:
$ podman run --rm -t \
  -v $PWD/_out:/secureboot:ro \
  -v $PWD/_out:/out \
  altlinux.space/alt-orchestra/imager:v11.0 secureboot-iso
Результат:
_out/alt-orchestra-11.0-metal-amd64-secureboot.iso
Генерация установщика:
$ podman run --rm -t \
  -v $PWD/_out:/secureboot:ro \
  -v $PWD/_out:/out \
  altlinux.space/alt-orchestra/imager:v11.0 \
  secureboot-installer \
  --base-installer-image altlinux.space/alt-orchestra/installer-base:v11.0
Результат:
_out/alt-orchestra-11.0-installer-amd64-secureboot.tar
Полученный образ установщика необходимо загрузить в контейнерный реестр.
Образы можно дополнительно настраивать: добавлять системные расширения, изменять параметры ядра и т. д.

Глава 12. Отказоустойчивый кластер

В данном разделе описывается создание отказоустойчивого кластера ALT Orchestra с несколькими управляющими узлами.
Минимальная рекомендуемая топология включает:
  • 3 узла Control Plane;
  • 2 узла Worker;
  • внешнюю точку доступа к Kubernetes API (балансировщик нагрузки или DNS-имя);
  • доступ с рабочего места администратора к узлам ALT Orchestra по сети.
Для обеспечения кворума etcd необходимо использовать нечётное количество узлов Control Plane. Минимальная отказоустойчивая конфигурация включает три управляющих узла. В этом случае отказ одного управляющего узла не приводит к потере кворума.
Использование как минимум двух узлов Worker позволяет обеспечить непрерывную работу рабочих нагрузок. При отказе одного узла поды, при наличии достаточных ресурсов и соответствующей настройки, будут автоматически перезапущены (или запланированы) на оставшемся узле.
Перед началом установки необходимо:

Примечание

Для установки в среде без доступа к сети Интернет используйте инструкции из разделов, посвящённых подготовке и установке в закрытом контуре.
Отказоустойчивое развертывание отличается от развертывания кластера с одним управляющим узлом следующими особенностями:
  • используется три узла Control Plane вместо одного;
  • конечная точка Kubernetes API должна обеспечивать доступ ко всем управляющим узлам;
  • talosctl настраивается на несколько endpoint-узлов;
  • команда talosctl bootstrap выполняется только один раз на одном из узлов Control Plane;
  • проверки состояния кластера и обновления выполняются поэтапно, без потери кворума etcd;
  • обновление ALT Orchestra выполняется с использованием образа установщика ALT Orchestra, а обновление Kubernetes — отдельной командой talosctl upgrade-k8s.

12.1. Топология

В приведённых ниже примерах используется кластер из пяти узлов.

Таблица 12.1. Топология

Роль узла
Количество
Назначение
Control Plane
3
Kubernetes API, etcd, управляющие компоненты
Worker
2
Выполнение пользовательских рабочих нагрузок
Пример переменных окружения:
CONTROL_PLANE_IP=("192.168.0.2" "192.168.0.3" "192.168.0.4")
WORKER_IP=("192.168.0.5" "192.168.0.6")
CLUSTER_ENDPOINT="kube.example.com"
CLUSTER_NAME="ha-cluster"
Переменная CLUSTER_ENDPOINT должна указывать на балансировщик нагрузки или DNS-имя, через которое доступен Kubernetes API по порту 6443/tcp.

12.2. Точка доступа Kubernetes API

Отказоустойчивый кластер требует использования отказоустойчивой конечной точки доступа к Kubernetes API. Подробное описание вариантов использования TCP-балансировщика нагрузки и DNS-записей приведено в разделе Конечная точка доступа Kubernetes API.
В HA-сценарии важно, чтобы CLUSTER_ENDPOINT указывал не на один управляющий узел, а на адрес, обеспечивающий доступ ко всем трём узлам Control Plane. Например, DNS-имя может содержать несколько A-записей:
kube.example.com  IN  A  192.168.0.2
kube.example.com  IN  A  192.168.0.3
kube.example.com  IN  A  192.168.0.4
Тогда конечная точка кластера будет иметь вид:
https://kube.example.com:6443

12.3. Развертывание кластера

12.3.1. Подготовка конфигураций

Для развертывания отказоустойчивого кластера выполните действия, описанные в разделе Быстрый старт, чтобы:
  • подготовить образы;
  • загрузить узлы;
  • определить параметры дисков и сетевых интерфейсов;
  • сгенерировать файлы secrets.yaml, controlplane.yaml, worker.yaml и talosconfig.
При создании HA-кластера используйте параметры, приведённые в данной главе.
Создайте каталог для файлов конфигурации:
$ mkdir -p ~/ha-cluster
$ cd ~/ha-cluster
Сгенерируйте секреты:
$ talosctl gen secrets -o secrets.yaml
Сгенерируйте конфигурации узлов:
$ talosctl gen config \
  --with-secrets secrets.yaml \
  "$CLUSTER_NAME" \
  "https://$CLUSTER_ENDPOINT:6443"
Если диски, сетевые интерфейсы или имена узлов различаются, подготовьте отдельные конфигурационные файлы по схеме, приведённой в разделе Настройка конфигурации узлов: talos/controlplanes/controlplane-1.yaml, talos/controlplanes/controlplane-2.yaml, talos/controlplanes/controlplane-3.yaml, talos/workers/worker-1.yaml, talos/workers/worker-2.yaml.
По умолчанию сборка ALT Orchestra уже содержит сведения о реестре образов, образах компонентов Kubernetes, версии Kubernetes и образе установщика. Переопределять эти параметры следует только при необходимости, например при установке в закрытом контуре или использовании собственного образа. Подробнее см. раздел Подготовка среды установки (загрузка с ISO-образов).

12.3.2. Применение конфигураций

Примените конфигурацию ко всем узлам Control Plane. Если для каждого узла подготовлен отдельный файл конфигурации, укажите его явно для соответствующего IP-адреса:
$ talosctl apply-config --insecure \
  --nodes "${CONTROL_PLANE_IP[0]}" \
  --file talos/controlplanes/controlplane-1.yaml

$ talosctl apply-config --insecure \
  --nodes "${CONTROL_PLANE_IP[1]}" \
  --file talos/controlplanes/controlplane-2.yaml

$ talosctl apply-config --insecure \
  --nodes "${CONTROL_PLANE_IP[2]}" \
  --file talos/controlplanes/controlplane-3.yaml
Аналогично примените конфигурацию ко всем узлам Worker:
$ talosctl apply-config --insecure \
  --nodes "${WORKER_IP[0]}" \
  --file talos/workers/worker-1.yaml

$ talosctl apply-config --insecure \
  --nodes "${WORKER_IP[1]}" \
  --file talos/workers/worker-2.yaml
Если параметры одинаковы для всех узлов одной роли, можно использовать общие файлы controlplane.yaml и worker.yaml.
Дождитесь завершения установки на всех узлах.
Просмотреть журналы можно в консоли узла или с помощью talosctl:
$ talosctl dmesg --nodes <IP-адрес_узла>

12.3.3. Настройка talosconfig

Объедините созданный файл talosconfig с локальной конфигурацией рабочего места администратора:
$ talosctl config merge ./talosconfig
Переключите talosctl на контекст создаваемого кластера:
$ talosctl config context "$CLUSTER_NAME"
Укажите все узлы Control Plane в качестве endpoint-узлов:
$ talosctl config endpoint "${CONTROL_PLANE_IP[@]}"
Это позволит talosctl автоматически использовать доступный управляющий узел при недоступности одного из endpoint.

12.3.4. Bootstrap etcd

Выполните bootstrap один раз и только на одном узле Control Plane:
$ talosctl bootstrap \
  --nodes "${CONTROL_PLANE_IP[0]}" \
  --endpoints "${CONTROL_PLANE_IP[0]}"

Важно

Команду talosctl bootstrap нельзя выполнять повторно на остальных управляющих узлах. После выполнения bootstrap остальные узлы Control Plane автоматически присоединятся к кластеру etcd с использованием общей конфигурации.

12.3.5. Получение kubeconfig

Получите конфигурацию Kubernetes:
$ talosctl kubeconfig \
  --nodes "${CONTROL_PLANE_IP[0]}" \
  --endpoints "${CONTROL_PLANE_IP[0]}"
Проверьте текущий контекст:
$ kubectl config current-context

12.3.6. Проверка кластера

Убедитесь, что все узлы зарегистрированы в Kubernetes:
$ kubectl get nodes -o wide
Ожидаемый результат — три узла Control Plane и два узла Worker в состоянии Ready.
Проверьте состояние компонентов ALT Orchestra и Kubernetes:
$ talosctl health \
  --nodes "${CONTROL_PLANE_IP[0]}" \
  --endpoints "${CONTROL_PLANE_IP[0]}"

12.4. Работа с отказоустойчивым кластером

При штатной эксплуатации рекомендуется соблюдать следующие правила:
  • не уменьшать количество работоспособных узлов Control Plan ниже большинства, необходимого для сохранения кворума etcd;
  • перед обслуживанием Worker-узла выводить с него пользовательские нагрузки с помощью команды kubectl drain;
  • перед обслуживанием узла Control Plane проверять состояние etcd и доступность Kubernetes API;
  • хранить файлы talosconfig, kubeconfig и secrets.yaml в защищённом месте (пример шифрования приведён ниже);
  • для добавления новых управляющих узлов использовать раздел Добавление управляющего узла (Control Plane);
  • для добавления новых рабочих узлов использовать раздел Добавление рабочего узла (worker);
  • для удаления рабочих узлов использовать раздел Удаление узла из кластера ALT Orchestra.

12.4.1. Хранение чувствительных файлов

Файлы talosconfig, kubeconfig и secrets.yaml предоставляют доступ к управлению кластером или содержат конфиденциальные данные. Не рекомендуется хранить их в открытом виде в Git-репозиториях, общих каталогах или резервных копиях без шифрования.
Для защищённого хранения можно использовать шифрование с помощью sops и ключей age.
Установите необходимые пакеты:
# apt-get install sops age
Создайте каталог для хранения ключей и сгенерируйте пару ключей:
$ mkdir -p ~/.config/sops/age
$ age-keygen -o ~/.config/sops/age/keys.txt
Получите публичный ключ получателя в формате age1… и сохраните его в переменную:
$ AGE_RECIPIENT=$(age-keygen -y ~/.config/sops/age/keys.txt)
Зашифруйте файлы:
$ sops encrypt --age "$AGE_RECIPIENT" secrets.yaml > secrets.sops.yaml

$ sops encrypt \
  --input-type binary \
  --output-type binary \
  --age "$AGE_RECIPIENT" \
  talosconfig > talosconfig.sops

$ sops encrypt \
  --input-type binary \
  --output-type binary \
  --age "$AGE_RECIPIENT" \
  kubeconfig > kubeconfig.sops
После проверки зашифрованных копий рекомендуется удалить незашифрованные файлы из постоянного хранилища.
Для временного восстановления используйте команды:
$ sops decrypt secrets.sops.yaml > secrets.yaml

$ sops decrypt \
  --input-type binary \
  --output-type binary \
  talosconfig.sops > talosconfig

$ sops decrypt \
  --input-type binary \
  --output-type binary \
  kubeconfig.sops > kubeconfig
Приватный ключ age, расположенный в файле ~/.config/sops/age/keys.txt, необходимо хранить отдельно от зашифрованных файлов. При необходимости можно использовать другой путь к ключу, задав переменную окружения SOPS_AGE_KEY_FILE.

Глава 13. Миграция Kubernetes-кластера на ALT Orchestra

В данном разделе описана миграция существующего Kubernetes-кластера, установленного на обычной системе ALT, на узлы ALT Orchestra.
Сценарий предполагает, что администратор постепенно добавляет в существующий кластер новые узлы Control Plane и Worker на базе ALT Orchestra, переводит Kubernetes API на новый endpoint, а затем выводит старые узлы из эксплуатации.

13.1. Требования

Перед началом миграции необходимо убедиться в наличии:
  • полного административного доступа к существующему кластеру;
  • полного доступа к инфраструктуре PKI существующего кластера. Стандартный путь на обычной системе: /etc/kubernetes/pki;
  • доступа к рабочему месту администратора с установленными kubectl и talosctl;
  • резервной копии etcd и критически важных данных кластера;
  • тестового кластера или стенда, на котором можно предварительно проверить процедуру миграции с аналогичной сетевой инфраструктурой и рабочими нагрузками.
Версия Kubernetes существующего кластера должна входить в матрицу поддержки ALT Orchestra (замечание по kube-proxy также очень важно для миграции). Если версия не поддерживается, сначала обновите существующий кластер до поддерживаемой версии, а затем выполните миграцию.

Важно

Не выполняйте миграцию на production-кластере без предварительной проверки на тестовом стенде. Инструкция рассчитана на сценарий с полным административным доступом к существующему кластеру и его PKI.

13.2. Тестовая среда

Инструкция проверялась на следующем стенде:
  • существующий кластер —Kubernetes v1.33.12 с Flannel;
  • новый кластер —ALT Orchestra 11.0.

13.3. Подготовка переменных

Зафиксируйте параметры нового кластера в переменных окружения:
CONTROL_PLANE_IP=<control-plane-ip>
WORKER_IP=("<worker-ip-1>" "<worker-ip-2>" "<worker-ip-3>")
CLUSTER_ENDPOINT=<endpoint-ip>
CLUSTER_NAME="myOldClusterName"
CLUSTER_ENDPOINT — IP-адрес или DNS-имя, по которому после миграции будет доступен Kubernetes API. Варианты настройки отказоустойчивой точки доступа описаны в разделе Конечная точка доступа Kubernetes API.
CLUSTER_NAME должен совпадать с именем существующего Kubernetes-кластера.

13.4. Генерация секретов из PKI существующего кластера

Сгенерируйте файл secrets.yaml на основе PKI существующего кластера:
$ talosctl gen secrets \
  --from-kubernetes-pki /etc/kubernetes/pki \
  --output-file secrets.yaml
Команду необязательно выполнять на существующем узле Control Plane. Достаточно скопировать каталог /etc/kubernetes/pki на машину с установленным talosctl и выполнить команду там.

13.5. Генерация конфигураций ALT Orchestra

Сгенерируйте конфигурационные файлы для узлов ALT Orchestra:
$ talosctl gen config \
  --with-secrets secrets.yaml \
  "$CLUSTER_NAME" \
  "https://$CLUSTER_ENDPOINT:6443"
Подробно процесс генерации конфигураций описан в разделе Подготовка среды установки (загрузка с ISO-образов). Однако при миграции не выполняйте шаги talosctl bootstrap и talosctl kubeconfig, описанные в этой инструкции.
В сценарии миграции Kubernetes-кластер уже существует, поэтому первый узел Control Plane ALT Orchestra должен присоединиться к нему с использованием PKI существующего кластера.
Для миграции необходимо изменить сгенерированные манифесты:
  • имя кластера должно совпадать с именем существующего кластера;
  • поле cluster.network.cni должно быть установлено в none, чтобы ALT Orchestra не разворачивала новую CNI-сеть поверх существующей (подробнее этот режим описан в разделе Пользовательское развертывание CNI):
    cluster:
      network:
        cni:
          name: none
    

13.6. Перенос параметров kube-apiserver

На существующем узле Control Plane проверьте параметры kube-apiserver, связанные с Service Account:
$ grep -E 'service-account-issuer|api-audiences|service-account-key-file|service-account-signing-key-file' \
  /etc/kubernetes/manifests/kube-apiserver.yaml
В манифестах новых узлов Control Plane ALT Orchestra явно задайте те же значения service-account-issuer и api-audiences:
cluster:
  apiServer:
    extraArgs:
      service-account-issuer: https://kubernetes.default.svc.cluster.local
      api-audiences: https://kubernetes.default.svc.cluster.local

13.7. Отключение KubePrism

На время миграции отключите KubePrism, чтобы kubelet и остальные компоненты узла обращались к Kubernetes API напрямую через cluster.controlPlane.endpoint.
Это важно на переходном этапе, когда первый узел Control Plane ALT Orchestra присоединяется к уже существующему кластеру, а endpoint ещё указывает на прежний Kubernetes API.
После завершения миграции KubePrism можно снова включить отдельным изменением конфигурации, если он используется в выбранной схеме эксплуатации:
machine:
  features:
    diskQuotaSupport: true
    kubePrism:
      enabled: false

13.8. Добавление первого узла Control Plane ALT Orchestra

Перед применением конфигурации первого нового узла Control Plane временно укажите в поле cluster.controlPlane.endpoint endpoint существующего Kubernetes API:
cluster:
  controlPlane:
    endpoint: https://<старый-endpoint>:6443
Примените конфигурацию:
$ talosctl apply-config \
  -n "$CONTROL_PLANE_IP" \
  --endpoints <старый-endpoint> \
  -f <path-to-controlplane.yaml> \
  --insecure
Во время установки на узел будут загружены образы компонентов Kubernetes и установщик ALT Orchestra.
Предупреждения вида:
Get https://localhost:6443/... dial tcp [::1]:6443: connect: connection refused
на данном этапе можно игнорировать.
Дождитесь, пока новый узел перейдёт в состояние Ready:
$ kubectl get nodes -o wide
Проверьте состояние системных компонентов:
$ kubectl get pods -n kube-system \
  --field-selector=status.phase!=Running
Также рекомендуется проверить работоспособность сетевой инфраструктуры и критически важных namespace приложений.

13.9. Переключение endpoint на новый узел Control Plane

На рабочем месте администратора обновите endpoint Kubernetes API в kubeconfig:
$ kubectl config set-cluster "$CLUSTER_NAME" \
  --server="https://$CLUSTER_ENDPOINT:6443"
После этого измените значение cluster.controlPlane.endpoint в конфигурации нового узла Control Plane, указав новый постоянный endpoint:
cluster:
  controlPlane:
    endpoint: https://<новый-endpoint>:6443
Повторно примените конфигурацию, уже без параметра --insecure:
$ talosctl --talosconfig <path-to-talosconfig> apply-config \
  -n "$CONTROL_PLANE_IP" \
  --endpoints "$CONTROL_PLANE_IP" \
  -f <path-to-controlplane.yaml>

13.10. Переключение существующих Worker-узлов

На всех существующих Worker-узлах измените endpoint Control Plane в файле /etc/kubernetes/kubelet.conf.
Найдите поле server и укажите новый endpoint Kubernetes API.
После этого перезапустите kubelet:
# systemctl restart kubelet
Если используется kube-proxy, обновите endpoint Kubernetes API в его ConfigMap:
$ kubectl -n kube-system edit cm kube-proxy
В блоке kubeconfig.conf замените значение параметрастроку server:
kubeconfig.conf: |-
  clusters:
  - cluster:
      server: https://<новый-endpoint>:6443
Перезапустите kube-proxy:
$ kubectl -n kube-system rollout restart ds kube-proxy
$ kubectl -n kube-system rollout status ds kube-proxy
Проверьте состояние узлов:
$ kubectl get nodes -o wide
Убедитесь, что kube-proxy успешно перезапустился на всех узлах:
$ kubectl -n kube-system get pods -l k8s-app=kube-proxy -o wide

13.11. Вывод существующих узлов Control Plane

Если существующий кластер содержит только один узел Control Plane, перед его удалением необходимо добавить как минимум ещё один узел Control Plane на базе ALT Orchestra. Это позволит сохранить кворум etcd после удаления старого узла.
Альтернативный вариант — удалить старый узел из состава etcd вручную с помощью etcdctl.
После этого выведите старый узел из Kubernetes:
$ kubectl cordon <node-name>
$ kubectl delete node <node-name>
Затем при необходимости добавьте остальные узлы Control Plane ALT Orchestra.

13.12. Добавление новых Worker-узлов ALT Orchestra

Примените конфигурации новых Worker-узлов:
$ talosctl apply-config \
  -n <worker-ip> \
  --endpoints "$CONTROL_PLANE_IP" \
  -f <path-to-worker.yaml> \
  --insecure
Проверьте, что новые Worker-узлы успешно присоединились к кластеру:
$ kubectl get nodes -o wide

13.13. Вывод существующих Worker-узлов

Для каждого существующего Worker-узла выполните:
$ kubectl cordon <node-name>

$ kubectl drain <node-name> \
  --ignore-daemonsets \
  --delete-emptydir-data

$ kubectl delete node <node-name>

13.14. Обновление Kubernetes после миграции

После завершения миграции обновите Kubernetes средствами talosctl.
Базовая процедура обновления приведена в разделе Обновление ALT Orchestra.

Часть IV. Управление кластером

Содержание

14. Управление узлами
14.1. Конфигурация и управление
14.2. Добавление узла в кластер ALT Orchestra
14.2.1. Добавление управляющего узла (Control Plane)
14.2.2. Добавление рабочего узла (worker)
14.2.3. Проверка состояния узлов
14.3. Удаление узла из кластера ALT Orchestra
14.4. Выполнение рабочих нагрузок на узлах плоскости управления
14.5. Управление PKI и сроками действия сертификатов
14.5.1. Проверка сертификатов Kubernetes
14.5.2. Генерация нового talosconfig
14.6. Управление конфигурацией узла ALT Orchestra
14.6.1. Применение конфигурации
14.6.2. Редактирование текущей конфигурации
14.6.3. Обновление конфигурации (JSON Patch / YAML Patch)
14.6.4. Восстановление после сбоев загрузки узла
14.7. Системные расширения
14.7.1. Установка системных расширений
14.7.2. Отключение неиспользуемых модулей платформы
14.7.3. Создание системных расширений
14.7.4. Просмотр установленных расширений
14.8. Ядро
14.8.1. Параметры командной строки
14.8.2. Параметры, специфичные для ALT Orchestra
15. Интерактивная панель мониторинга кластера
16. Журналирование и аудит
16.1. Работа с журналами ALT Orchestra
16.1.1. Просмотр журналов
16.1.2. Отправка журналов
16.2. Аудит событий Kubernetes API
16.2.1. Просмотр параметров аудита kube-apiserver
16.2.2. Проверка политики аудита
16.2.3. Проверка записей аудита
16.2.4. Изменение уровня аудита Kubernetes API
16.2.5. Проверка изменений в логах
17. Обновление ALT Orchestra
17.1. Поддерживаемые пути обновления
17.2. Обновление узла
17.3. Последовательность обновления узла

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

14.1. Конфигурация и управление
14.2. Добавление узла в кластер ALT Orchestra
14.2.1. Добавление управляющего узла (Control Plane)
14.2.2. Добавление рабочего узла (worker)
14.2.3. Проверка состояния узлов
14.3. Удаление узла из кластера ALT Orchestra
14.4. Выполнение рабочих нагрузок на узлах плоскости управления
14.5. Управление PKI и сроками действия сертификатов
14.5.1. Проверка сертификатов Kubernetes
14.5.2. Генерация нового talosconfig
14.6. Управление конфигурацией узла ALT Orchestra
14.6.1. Применение конфигурации
14.6.2. Редактирование текущей конфигурации
14.6.3. Обновление конфигурации (JSON Patch / YAML Patch)
14.6.4. Восстановление после сбоев загрузки узла
14.7. Системные расширения
14.7.1. Установка системных расширений
14.7.2. Отключение неиспользуемых модулей платформы
14.7.3. Создание системных расширений
14.7.4. Просмотр установленных расширений
14.8. Ядро
14.8.1. Параметры командной строки
14.8.2. Параметры, специфичные для ALT Orchestra

14.1. Конфигурация и управление

После успешной установки ALT Orchestra на диск управление узлами осуществляется с помощью утилиты talosctl.
Получение информации о состоянии узла:
$ talosctl --nodes <IP-адрес-узла> health
Просмотр системного журнала (dmesg):
$ talosctl --nodes <IP-адрес-узла> dmesg
Просмотр журналов сервисов:
$ talosctl --nodes <IP-адрес-узла> logs <сервис>
Например:
$ talosctl --nodes 192.168.0.140 logs kubelet
Получение списка запущенных сервисов:
$ talosctl --nodes <IP-адрес-узла> services
Просмотр информации о сетевых интерфейсах:
$ talosctl --nodes <IP-адрес-узла> get links
Просмотр дисков:
$ talosctl --nodes <IP-адрес-узла> get disks
Просмотр системных ресурсов и состояния сервисов в интерактивном режиме:
$ talosctl dashboard
Либо для конкретного узла:
$ talosctl --nodes <IP-адрес-узла> dashboard
Получение kubeconfig для доступа к Kubernetes API:
$ talosctl kubeconfig .
Перезагрузка узла:
$ talosctl --nodes <IP-адрес-узла> reboot
Выключение узла:
$ talosctl --nodes <IP-адрес-узла> shutdown

Примечание

Большинство команд требует корректно настроенного файла talosconfig и доступности API на целевом узле.

14.2. Добавление узла в кластер ALT Orchestra

Чтобы добавить новый узел в уже развернутый кластер ALT Orchestra, необходимо выполнить процедуру, аналогичную первоначальному созданию кластера:
  • загрузить новую машину с ALT Orchestra (через ISO, PXE или образ диска);
  • применить конфигурационный файл worker.yaml или controlplane.yaml, в зависимости от роли узла.
Следует использовать те же конфигурационные файлы (controlplane.yaml, worker.yaml), которые были сгенерированы при первоначальном развертывании кластера, так как они содержат необходимые сертификаты для аутентификации узлов.
После получения IP-адреса нового узла можно применить соответствующий конфигурационный файл:
$ talosctl apply-config --insecure \
 --nodes <IP-адрес-узла> \
 --file controlplane.yaml # или worker.yaml
Параметр --insecure используется, так как на данном этапе инфраструктура PKI (сертификаты и шифрование) на узле ещё не настроена.
После выполнения команды узел автоматически присоединится к кластеру в соответствии со своей ролью.

14.2.1. Добавление управляющего узла (Control Plane)

Пример добавления управляющего узла:
$ talosctl apply-config --insecure \
 --nodes 192.168.0.141 \
 --file _pve/controlplane.yaml

Примечание

При необходимости можно обновить параметры установки, например диск или образ:
  1. Задайте новые значения:
    DEVICE="/dev/sda"
    INSTALLERIMAGE="factory.altlinux.space/alt-orchestra-metal-installer/376567988ad370138ad8b2698212367b8edcb69b5fd68c80be1f2ec7d603b4ba:v11.0"
    
  2. Создайте patch-файл:
    $ cat > new_controlplane.patch << PATCH
        .machine.install.disk="$DEVICE" |
        .machine.install.image|="$INSTALLERIMAGE"
    PATCH
    
  3. Сгенерируйте обновлённую конфигурацию:
    $ cat _pve/controlplane.yaml | yq -y "$(cat new_controlplane.patch)" > _pve/new_controlplane.yaml
    

14.2.2. Добавление рабочего узла (worker)

Пример добавления рабочего узла:
$ talosctl apply-config --insecure \
 --nodes 192.168.0.147 \
 --file _pve/worker.yaml
Пример вывода:
$ talosctl apply-config --insecure \
 --nodes 192.168.0.147 \
 --file _pve/worker.yaml

Примечание

При необходимости можно обновить параметры установки, например диск или образ:
  1. Задайте новые значения:
    DEVICE="/dev/sda"
    INSTALLERIMAGE="factory.altlinux.space/alt-orchestra-metal-installer/376567988ad370138ad8b2698212367b8edcb69b5fd68c80be1f2ec7d603b4ba:v11.0"
    
  2. Создайте patch-файл:
    $ cat > new_worker.patch << PATCH
        .machine.install.disk="$DEVICE" |
        .machine.install.image|="$INSTALLERIMAGE"
    PATCH
    
  3. Сгенерируйте обновлённую конфигурацию:
    $ cat _pve/worker.yaml | yq -y "$(cat new_worker.patch)" > _pve/new_worker.yaml
    

14.2.3. Проверка состояния узлов

После добавления убедитесь, что добавленные узлы в состоянии Ready:
$ kubectl --kubeconfig ./kubeconfig get nodes
Пример вывода:
NAME                    STATUS   ROLES           AGE   VERSION
alt-orchestra-40p-byh   Ready      <none>          5m16s   v1.35.0
alt-orchestra-6ub-m6m   Ready      <none>          26m     v1.35.0
alt-orchestra-9hf-ozu   Ready      control-plane   26m     v1.35.0
alt-orchestra-bob-f6v   NotReady   control-plane   17s     v1.35.0
alt-orchestra-ezp-gxw   Ready      <none>          26m     v1.35.0
Выполните проверку состояния узлов Control Plane:
$ talosctl health -n 192.168.0.140
$ talosctl health -n 192.168.0.141
Выведите список всех ресурсов во всех пространствах имён:
$ kubectl --kubeconfig ./kubeconfig get all -A
Все поды должны находиться в состоянии Running. Допускается наличие подов в состоянии Completed или ContainerStatusUnknown (например, для cilium-operator).

14.3. Удаление узла из кластера ALT Orchestra

Чтобы удалить узел из кластера ALT Orchestra, необходимо выполнить следующие шаги:
  1. Сбросить состояние ALT Orchestra на удаляемом узле:
    $ talosctl --nodes <IP-адрес-узла> reset
    
    Эта команда:
    • блокирует и очищает узел;
    • удаляет его из внутреннего реестра ALT Orchestra (службы обнаружения);
    • при необходимости сохраняет данные etcd;
    • очищает диски и выключает машину.
  2. Удалить узел из Kubernetes:
    $ kubectl delete node <имя_узла>
    
    Операция reset не удаляет узел из Kubernetes — это необходимо выполнить отдельно с помощью kubectl.
После выполнения этих шагов узел полностью исключается из кластера ALT Orchestra.
После получения IP-адреса нового узла можно применить соответствующий конфигурационный файл:
$ talosctl apply-config --insecure \
 --nodes <IP-адрес-узла> \
 --file controlplane.yaml # или worker.yaml

Примечание

Перед выполнением talosctl reset рекомендуется сначала корректно вывести узел из кластера Kubernetes с помощью команды:
$ kubectl drain <узел> --ignore-daemonsets --delete-emptydir-data
Пример удаления рабочего узла (worker):
  1. Сброс состояния узла:
    $ talosctl -n 192.168.0.141 reset
    
    Пример вывода:
    watching nodes: [192.168.0.141]
        * 192.168.0.197: events check condition met
    
  2. Получение имени узла:
    $ DELETED_NODE="$(kubectl --kubeconfig ./kubeconfig get nodes -o wide | grep 192.168.0.197 | awk '{print $1}')"
    
  3. Удаление узла из Kubernetes:
    $ kubectl --kubeconfig ./kubeconfig delete node $DELETED_NODE;
    
    Пример вывода:
    node "alt-orchestra-40p-byh" deleted
    
  4. Проверка, что узел удалён (вывод команды должен быть пустым):
    $ kubectl --kubeconfig ./kubeconfig get nodes -o wide | grep 192.168.0.141
    
  5. Проверка состояния узлов Control Plane:
    $ talosctl health -n 192.168.0.140
    $ talosctl health -n 192.168.0.141
    
Выведите список всех ресурсов во всех пространствах имён:
$ kubectl --kubeconfig ./kubeconfig get all -A
Все поды должны находиться в состоянии Running. Допускается наличие подов в состоянии Completed или ContainerStatusUnknown (например, для cilium-operator).

14.4. Выполнение рабочих нагрузок на узлах плоскости управления

По умолчанию ALT Orchestra не позволяет планировать рабочие нагрузки (поды) на узлах плоскости управления (Control Plane). Это делается для изоляции компонентов управления от пользовательских нагрузок.
Однако в некоторых сценариях — например, в одиночных кластерах, непроизводственных средах или временных инсталляциях — требуется разрешить выполнение пользовательских подов на этих узлах.
Чтобы разрешить выполнение рабочих нагрузок на узлах плоскости управления до применения конфигурации (controlplane.yaml) необходимо:
  1. Открыть файл controlplane.yaml.
  2. Вставить или изменить следующий параметр:
    cluster:
      allowSchedulingOnControlPlanes: true
    
  3. Установить ALT Orchestra на узел с этой конфигурацией:
    $ talosctl apply-config --insecure \
      --nodes <IP-адрес-узла> \
      --file controlplane.yaml
    
Для уже работающего узла:
  1. Получить IP-адрес одного из узлов управления:
    $ talosctl get nodes
    
  2. Выполнить команду редактирования конфигурации:
    $ talosctl edit machineconfig -n <IP-адрес-узла>
    
  3. В открывшемся YAML найти или добавить секцию cluster с параметром:
    cluster:
      allowSchedulingOnControlPlanes: true
    
  4. Сохранить изменения.
    ALT Orchestra автоматически применит обновлённую конфигурацию.
Даже при включённой настройке allowSchedulingOnControlPlanes, Kubernetes по умолчанию добавляет taint NoSchedule на управляющие узлы.
Чтобы разрешить планирование подов, необходимо удалить этот taint:
$ kubectl taint nodes <имя_ноды> \
 node-role.kubernetes.io/control-plane:NoSchedule-

Примечание

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

14.5. Управление PKI и сроками действия сертификатов

ALT Orchestra автоматически управляет и ротирует все серверные сертификаты, используемые компонентами:
  • etcd
  • Kubernetes
  • Talos API
Дополнительных действий от пользователя не требуется. Однако для ротации клиентских сертификатов kubelet необходимо перезапускать узлы не реже одного раза в год. Любая плановая перезагрузка или обновление ALT Orchestra обеспечивает это автоматически.

14.5.1. Проверка сертификатов Kubernetes

Для проверки текущих сертификатов Kubernetes на узлах управления можно использовать команду:
$ talosctl get KubernetesDynamicCerts -o yaml \
 --nodes <controlplane-ip>
Клиентские сертификаты (talosconfig и kubeconfig) являются ответственностью пользователя. Каждый раз при получении kubeconfig из кластера ALT Orchestra клиентский сертификат в нём создаётся заново и будет действовать в течение одного года. После истечения срока действия потребуется сгенерировать kubeconfig заново.
Файл talosconfig (для работы с talosctl) также имеет срок действия, который обычно составляет 1 год. Необходимо обновлять его вручную.

14.5.2. Генерация нового talosconfig

При наличии действительного (не просроченного) talosconfig с ролью os:admin, можно сгенерировать новый файл клиентской конфигурации:
$ talosctl -n <controlplane-ip> config new talosconfig-reader \
  --roles os:reader \
  --crt-ttl 24h
Можно указать другие роли (os:admin, k8s:admin) и срок действия (--crt-ttl).
Если ранее был сохранён файл secrets.yaml, его можно использовать для генерации talosconfig:
$ talosctl gen config \
  --with-secrets secrets.yaml \
  --output-types talosconfig \
  -o talosconfig \
  <cluster-name> https://<cluster-endpoint>

Примечание

Аргументы cluster-name и cluster-endpoint не используются при генерации talosconfig, но их всё равно нужно указать.
Если файл controlplane.yaml всё ещё доступен, можно извлечь CA и сгенерировать сертификат вручную:
  1. Извлечь корневой CA:
    $ yq 'select(.machine) | .machine.ca.crt | @base64d' controlplane.yaml > ca.crt
    $ yq 'select(.machine) | .machine.ca.key | @base64d' controlplane.yaml > ca.key
    

    Примечание

    В команде используется команда yq из пакета yq-go.
  2. Cгенерировать ключи и сертификаты:
    $ talosctl gen key --name admin
    $ talosctl gen csr --key admin.key --ip 127.0.0.1
    $ talosctl gen crt --ca ca --csr admin.csr --name admin
    
  3. Поместить файлы в кодировке base64 в соответствующее место в talosconfig:
    context: mycluster
    contexts:
      mycluster:
        endpoints:
          - <controlplane-ip-1>
          - <controlplane-ip-2>
        ca: <base64-encoded ca.crt>
        crt: <base64-encoded admin.crt>
        key: <base64-encoded admin.key>
    

14.6. Управление конфигурацией узла ALT Orchestra

Состояние узла ALT Orchestra полностью определяется конфигурацией машины. Начальная конфигурация передаётся на узел во время загрузки, однако её можно изменять и во время работы узла.
Основные команды управления конфигурацией:
  • talosctl apply-config — применение конфигурации из файла;
  • talosctl edit machineconfig — редактирование текущей конфигурации в интерактивном редакторе с последующим применением;
  • talosctl patch machineconfig — применение изменений к конфигурации в формате JSON Patch.
Каждая из указанных команд может работать в одном из следующих режимов:
  • default — автоматическое применение: изменения применяются немедленно; при необходимости выполняется перезагрузка;
  • --mode=reboot — применение после перезагрузки узла (узел перезагружается автоматически);
  • --mode=no-reboot — немедленное применение без перезагрузки; команда завершится ошибкой, если изменения требуют перезагрузки;
  • --mode=staged — изменения подготавливаются и применяются при следующей перезагрузке (узел не перезагружается автоматически);
  • --mode=try — временное применение: если изменения не будут подтверждены в течение одной минуты, они автоматически отменяются;
  • --mode=interactive — интерактивный режим (TUI; доступен только для talosctl apply-config).

Примечание

Режим --mode=staged не изменяет текущую конфигурацию узла. Повторный вызов talosctl edit machineconfig --mode=staged не отобразит подготовленные изменения.
Для извлечения текущей конфигурации машины в формате JSON можно использовать команду:
$ talosctl get machineconfig v1alpha1 -o jsonpath='{.spec}'
Полученную конфигурацию можно изменить локально и затем применить обратно с помощью talosctl apply-config.
Список параметров, изменения которых могут применяться без перезагрузки узла:
  • .debug
  • .cluster
  • .machine.time
  • .machine.ca
  • .machine.acceptedCAs
  • .machine.certSANs
  • .machine.install (применяется только во время установки/обновления)
  • .machine.network
  • .machine.nodeAnnotations
  • .machine.nodeLabels
  • .machine.nodeTaints
  • .machine.sysfs
  • .machine.sysctls
  • .machine.logging
  • .machine.controlplane
  • .machine.kubelet
  • .machine.pods
  • .machine.kernel
  • .machine.registries (требует перезапуска containerd для применения настроек аутентификации)
  • .machine.features.kubernetesTalosAPIAccess
  • .machine.features.hostDNS
  • .machine.features.kubePrism

14.6.1. Применение конфигурации

Команда talosctl apply-config обычно используется для отправки начальной конфигурации, сгенерированной с помощью talosctl gen config, на узел.
Её также можно использовать для обновления конфигурации работающих узлов. Начальный YAML-файл обычно формируется командой:
$ talosctl get machineconfig v1alpha1 -o jsonpath='{.spec}' > machineconfig.yaml
Пример применения:
$ talosctl -n <IP-адрес-узла> apply-config -f config.yaml
Команда apply-config также может быть вызвана в альтернативной форме:
$ talosctl -n <IP-адрес-узла> apply machineconfig -f config.yaml
Немедленное применение конфигурации (без перезагрузки):
$ talosctl -n <IP-адрес-узла> apply machineconfig -f config.yaml --mode=no-reboot
Интерактивный режим (TUI):
$ talosctl -n <IP-адрес-узла> apply machineconfig --mode=interactive

Примечание

Если узел работает в режиме обслуживания (maintenance mode), необходимо использовать флаг --insecure (-i) для подключения к API и применения конфигурации.

14.6.2. Редактирование текущей конфигурации

Команда talosctl edit machineconfig загружает текущую конфигурацию с узла и открывает её в редакторе. Если конфигурация не была изменена (или результат пустой), обновление не применяется.

Примечание

ALT Orchestra использует переменные окружения TALOS_EDITOR и EDITOR для выбора редактора. Если они не заданы, по умолчанию используется vim.
Пример:
$ talosctl -n <IP-адрес-узла> edit machineconfig
Конфигурацию можно редактировать для нескольких узлов:
$ talosctl -n <IP1>,<IP2>… edit machineconfig
Немедленное применение изменения конфигурации машины (без перезагрузки):
$ talosctl -n <IP-адрес-узла> edit machineconfig --mode=no-reboot

14.6.3. Обновление конфигурации (JSON Patch / YAML Patch)

Команда talosctl patch machineconfig работает аналогично команде edit — она загружает текущую конфигурацию машины, но вместо интерактивного редактирования применяет набор изменений (patch) к конфигурации.
Пример обновления версии kubelet (в автоматическом режиме):
$ talosctl -n <IP-адрес-узла> patch machineconfig -p '[{"op": "replace", "path": "/machine/kubelet/image", "value": "registry.altlinux.org/p11/kubelet:v1.35"}]'
Обновление kube-apiserver без перезагрузки:
$ talosctl -n <IP-адрес-узла> patch machineconfig --mode=no-reboot -p '[{"op": "replace", "path": "/cluster/apiServer/image", "value": "registry.altlinux.org/p11/kube-apiserver:v1.35"}]'
Обновление может быть применено к нескольким узлам:
$ talosctl -n <IP1>,<IP2>… patch machineconfig -p '[{...}]'
Патчи можно загружать из файлов с помощью синтаксиса @file:
$ talosctl -n <IP-адрес-узла> patch machineconfig \
  -p @kubelet-patch.json -p @manifest-patch.json
Также поддерживается формат YAML. Пример kubelet-patch.yaml:
- op: replace
  path: /machine/kubelet/image
  value: registry.altlinux.org/p11/kubelet:v1.35
Применение патча:
$ talosctl -n <IP-адрес-узла> patch machineconfig -p @kubelet-patch.yaml

14.6.4. Восстановление после сбоев загрузки узла

Если узел ALT Orchestra не загружается из-за некорректной конфигурации (например, указана неверная конечная точка Control Plane), конфигурацию можно исправить и повторно применить.

14.7. Системные расширения

Системные расширения (System Extensions) позволяют расширять функциональность корневой файловой системы. Они используются, например, для добавления пользовательских сред выполнения контейнеров, загрузки дополнительных драйверов, прошивок и выполнения других задач.
Системные расширения активируются только во время установки или обновления ALT Orchestra. При этом корневая файловая система остается неизменяемой и доступной только для чтения.

Примечание

Список системных расширений приведен в таблице Системные расширения.

14.7.1. Установка системных расширений

ALT Orchestra поддерживает генерацию загрузочных носителей с включёнными системными расширениями. Поддерживаются два основных типа загрузочных ресурсов:
  • начальные загрузочные образы (ISO, PXE и др.) — используются для первичной загрузки машины;
  • образы дисков и контейнерные образы установщика — применяются для установки или обновления ALT Orchestra (установка выполняется при загрузке с ISO или PXE).
В зависимости от типа системного расширения (например, драйвер устройства или плагин containerd) его необходимо включать:
  • либо только в образ установщика;
  • либо одновременно в начальный загрузочный образ и образ установщика.

14.7.1.1. Пример: загрузка с ISO

Допустим, требуется добавить расширение NVIDIA на bare metal машине, загружаемой с ISO. Поскольку это расширение не требуется на этапе загрузки или установки, его достаточно добавить только в образ установщика.
Порядок действий:
  1. Загрузить машину с универсального ISO-образа ALT Orchestra.
  2. Подготовить контейнерный образ установщика с включенным расширением NVIDIA.
  3. Опубликовать образ установщика в реестре.
  4. Указать образ установщика в конфигурации узла (поле .machine.install.image).
  5. Применить конфигурацию к узлу.
После загрузки с ISO ALT Orchestra загрузит указанный образ установщика, выполнит установку с учётом расширения и перезагрузит узел.
При обновлении ALT Orchestra необходимо повторить те же шаги, указав новый образ установщика.

14.7.1.2. Пример: образ диска (AWS)

Допустим, требуется использовать расширение NVIDIA в виртуальной машине AWS.
Порядок действий:
  1. Cоздать образ диска AWS с включённым расширением NVIDIA.
  2. Загрузить образ в AWS и зарегистрировать его как AMI.
  3. Запустить виртуальную машину с использованием данного AMI.
  4. ALT Orchestra автоматически загрузится с включённым расширением.
При обновлении можно либо повторить шаги 1-4 с новым образом AMI, либо, как в предыдущем примере, использовать образ установщика и выполнить обновление на месте.

14.7.1.3. Обновление набора системных расширений

Для изменения набора системных расширений (добавление или удаление) необходимо сформировать новый образ установщика и обновить узел до него.
Общий вид команды:
$ talosctl upgrade -n <IP-адрес-узла> \
  --image factory.altlinux.space/metal-installer/<идентификатор-схемы>:<версия>
Текущее состояние:
$ talosctl -n 192.168.0.147 get extensions
Вывод:
NODE           NAMESPACE  TYPE             ID   VERSION   NAME        VERSION
192.168.0.147  runtime    ExtensionStatus  0    1         schematic   376567988ad370138ad8b2698212367b8edcb69b5fd68c80be1f2ec7d603b4ba
Обновление:
$ talosctl upgrade -n 192.168.0.147 \
  --image factory.altlinux.space/alt-orchestra-metal-installer/80d5f9d0991e825b84617b4f2ce25b840050e3ee6a83647ac1bc0a559cf90962:v11.0
После обновления:
$ talosctl -n 192.168.0.147 get extensions
Вывод:
NODE           NAMESPACE TYPE            ID  VERSION  NAME             VERSION
192.168.0.147  runtime   ExtensionStatus 0   1        intel-ucode      20251111
192.168.0.147  runtime   ExtensionStatus 1   1        util-linux-tools   2.39.2
192.168.0.147  runtime   ExtensionStatus 2   1        schematic 80d5f9d0991e825b84617b4f2ce25b840050e3ee6a83647ac1bc0a559cf90962
В процессе обновления узел перезагружается и загружается с новым набором расширений.

14.7.2. Отключение неиспользуемых модулей платформы

Отключение неиспользуемых модулей платформы (системных расширений) выполняется путём формирования нового образа установщика без соответствующих расширений и последующего обновления узла.
Системные расширения не могут быть удалены «на лету», так как они являются частью корневой файловой системы и применяются только на этапе установки или обновления.
Порядок действий:
  1. Подготовить контейнерный образ установщика без отключаемого расширения.
  2. Опубликовать образ установщика в реестре.
  3. Выполнить обновление узла:
    $ talosctl upgrade -n 192.168.0.147 \
      --image factory.altlinux.space/alt-orchestra-metal-installer/b8a905a80cb59e5cb28d30420b3d14b62b1ff4c75ee906657d3ed8c3b0b087d5:v11.0
    
    В процессе обновления узел перезагружается и загружается с новым образом, в котором отсутствует отключённое расширение.
  4. После перезагрузки проверить список установленных расширений:
    $ talosctl -n 192.168.0.147 get extensions
    
    Пример вывода:
    NODE          NAMESPACE TYPE            ID   VERSION  NAME              VERSION
    192.168.0.147 runtime   ExtensionStatus 0    1        util-linux-tools  2.39.2
    192.168.0.147 runtime   ExtensionStatus 1    1        schematic          b8a905a80cb59e5cb28d30420b3d14b62b1ff4c75ee906657d3ed8c3b0b087d5
    

14.7.3. Создание системных расширений

Системное расширение ALT Orchestra представляет собой контейнерный образ с определённой структурой каталогов.
Его можно создать с помощью стандартных инструментов для сборки контейнерных образов, например:
docker build -t my-extension:latest .

14.7.4. Просмотр установленных расширений

Чтобы просмотреть список активных системных расширений на узле, можно воспользоваться командой talosctl get extensions:
$ talosctl -n 192.168.0.147 get extensions
Пример вывода:
NODE          NAMESPACE  TYPE            ID VERSION  NAME               VERSION
192.168.0.147 runtime    ExtensionStatus 0  1        intel-ucode        20251111
192.168.0.147 runtime    ExtensionStatus 1  1        util-linux-tools   2.39.2
192.168.0.147 runtime    ExtensionStatus    1        schematic          80d5f9d0991e825b84617b4f2ce25b840050e3ee6a83647ac1bc0a559cf90962
Пример получения информации в формате YAML:
$ talosctl -n 192.168.0.147 get extensions 0 -o yaml
Пример вывода:
node: 192.168.0.147
metadata:
    namespace: runtime
    type: ExtensionStatuses.runtime.talos.dev
    id: 0
    version: 1
    owner: runtime.ExtensionStatusController
    phase: running
    created: 2026-04-23T11:21:14Z
    updated: 2026-04-23T11:21:14Z
spec:
    image: 0.sqsh
    metadata:
        name: intel-ucode
        version: "20251111"
        author: Basealt LLC
        description: |
            intel-ucode module
        compatibility:
            talos:
                version: '>= v1.0.0'
Пример получения информации в формате JSON:
$ talosctl -n 192.168.0.147 get extensions 1 -o yaml
Пример вывода:
{
    "metadata": {
        "created": "2026-04-23T11:21:14Z",
        "id": 1,
        "namespace": "runtime",
        "owner": "runtime.ExtensionStatusController",
        "phase": "running",
        "type": "ExtensionStatuses.runtime.talos.dev",
        "updated": "2026-04-23T11:21:14Z",
        "version": 1
    },
    "node": "192.168.0.147",
    "spec": {
        "image": "1.sqsh",
        "metadata": {
            "author": "Basealt LLC",
            "compatibility": {
                "talos": {
                    "version": "\u003e= v1.0.0"
                }
            },
            "description": "minimal util-linux package\n",
            "name": "util-linux-tools",
            "version": "2.39.2"
        }
    }
}

14.8. Ядро

14.8.1. Параметры командной строки

ALT Orchestra поддерживает ряд параметров командной строки ядра Linux. Некоторые параметры обязательны, другие — опциональны и используются в определённых сценариях.
Обязательные параметры:
  • talos.platform — определяет платформу развертывания. Возможные значения: akamai, aws, azure, container, digitalocean, equinixMetal, gcp, hcloud, metal, nocloud, openstack, oracle, scaleway, upcloud, vmware, vultr;
  • slab_nomerge — рекомендуется в соответствии с требованиями Kernel Self Protection Project (KSPP);
  • pti=on — включает Kernel Page Table Isolation и рекомендуется KSPP.
Дополнительные параметры:
  • init_on_alloc=1/0 — рекомендуется KSPP. По умолчанию включён в конфигурации ядра, но может быть отключён для повышения производительности за счёт снижения уровня безопасности;
  • init_on_free=0/1 — рекомендуется KSPP. По умолчанию отключён, но может быть включён для повышения безопасности за счёт производительности.

14.8.2. Параметры, специфичные для ALT Orchestra

14.8.2.1. Параметр ip

Параметр ip используется для начальной настройки сети: IP-адресов, маршрутов, DNS- и NTP-серверов.
По умолчанию ALT Orchestra использует DHCP на всех активных сетевых интерфейсах. Однако в некоторых случаях требуется задать параметры сети вручную ещё до получения основной конфигурации узла.
ALT Orchestra использует параметры, переданные через ip, в качестве начальной конфигурации сети. Это особенно полезно:
  • если DHCP отсутствует;
  • если требуется переопределить DNS- или NTP-серверы;
  • при PXE-загрузке;
  • при работе в изолированных сетях.
Можно передать параметры сети через командную строку ядра, например в загрузчике GRUB или при запуске ISO:
Установка. Параметры загрузки (BIOS)
Формат параметра:
ip=<client-ip>:<server-ip>:<gw-ip>:<netmask>:<hostname>:<device>:<autoconf>:<dns0-ip>:<dns1-ip>:<ntp0-ip>
где:
  • client-ip — статический IP-адрес машины;
  • server-ip — IP-адрес сервера, который используется для дополнительных сетевых задач на раннем этапе загрузки системы (например, для загрузки с сервера TFTP или NFS). Для загрузки с локального диска можно не указывать;
  • gw-ip — IP-адрес шлюза по умолчанию;
  • netmask — сетевая маска;
  • hostname — имя хоста (можно не указывать);
  • device — сетевой интерфейс (актуальное имя: ens19, enp0s3 и т.д.);
  • autoconf — режим автоматической настройки сети (dhcp — использовать DHCP; off — отключить автоматическую настройку);
  • dns0-ip, dns1-ip — адрес DNS-сервера;
  • ntp0-ip — адрес NTP-сервера.
Пример простого параметра ip:
ip=192.168.0.100::192.168.0.1:255.255.255.0::ens19:off
Пример с VLAN:
ip=172.20.0.2::172.20.0.1:255.255.255.0::eth0.100:::::
Можно задать только DNS- и NTP-серверы:
ip=:::::::<dns0-ip>:<dns1-ip>:<ntp0-ip>
IPv6-адреса можно указать, заключив их в квадратные скобки:
ip=[2001:db8::a]:[2001:db8::b]:[fe80::1]::controlplane1:eth1::[2001:4860:4860::6464]:[2001:4860:4860::64]:[2001:4860:4806::]
Параметр <netmask> можно задавать:
  • в виде маски (255.255.255.0);
  • в CIDR-формате (24).
Для IPv6 допускается использование полной маски:
[ffff:ffff:ffff:ffff::0]
Параметр <device> может содержать:
  • классические имена интерфейсов (eth0, eth1);
  • предсказуемые имена (ens19, enp0s3);
  • MAC-ориентированные имена (enx78e7d1ea46da).
Включение DHCP:
ip=:::::eth0.3:dhcp
Альтернативный синтаксис:
ip=eth0.3:dhcp

14.8.2.2. Параметр bond

Параметр bond используется для начальной настройки bonding-интерфейсов.
Полная документация доступна в документации dracut.
Формат:
bond=<bondname>:<bondslaves>:<options>:<mtu>
Если указано только имя bond-интерфейса, ALT Orchestra:
  • создаст bond с интерфейсами eth0 и eth1;
  • установит режим balance-rr.
Следующие варианты эквивалентны:
bond=bond0
bond=bond0:
bond=bond0::
bond=bond0:::
bond=bond0:eth0,eth1
bond=bond0:eth0,eth1:balance-rr
Пример полной конфигурации:
bond=bond1:eth3,eth4:mode=802.3ad,xmit_hash_policy=layer2+3:1450
Будет создан bond:
  • bond1;
  • с интерфейсами eth3 и eth4;
  • в режиме 802.3ad (LACP);
  • с MTU 1450.

14.8.2.3. Параметр vlan

Параметр vlan используется для создания VLAN-интерфейса на раннем этапе загрузки.
Поддерживается настройка только одного VLAN-интерфейса.
Пример:
vlan=eth0.100:eth0 ip=172.20.0.2::172.20.0.1:255.255.255.0::eth0.100:::::
Этот пример:
  • создаёт VLAN-интерфейс eth0.100;
  • использует eth0 как базовый интерфейс;
  • задаёт VLAN ID 100;
  • назначает IP-адрес 172.20.0.2/24;
  • устанавливает шлюз 172.20.0.1.

14.8.2.4. net.ifnames=0

Параметр net.ifnames=0 отключает предсказуемые имена сетевых интерфейсов.
Пример:
net.ifnames=0
После этого интерфейсы будут именоваться в классическом стиле (eth0, eth1).

14.8.2.5. panic

Параметр panic определяет задержку перед автоматической перезагрузкой после критической ошибки ядра.
Пример:
panic=10
где 10 — задержка в секундах.
Значение 0 полностью отключает автоматическую перезагрузку.

14.8.2.6. talos.config

Параметр talos.config указывает URL конфигурации машины.
Поддерживается только с параметром:
talos.platform=metal
Поддерживаются подстановки:
  • ${uuid} — SMBIOS UUID;
  • ${serial} — серийный номер SMBIOS;
  • ${mac} — MAC-адрес первого активного интерфейса;
  • ${hostname} — имя хоста.
Пример:
http://test.alt/metadata?h=${hostname}&m=${mac}&s=${serial}&u=${uuid}
После подстановки:
http://test.alt/metadata?h=myTestHostname&m=52%3A2f%3Afd%3Adf%3Afc%3Ac0&s=0OCZJ19N65&u=40dcbd19-3b10-444e-bfff-aaee44a51fda
Для обеспечения обратной совместимости в параметр запроса uuid добавляется UUID системы, если его значение пустое. Например:
http://test.alt/metadata?uuid -> http:/test.alt/metadata?uuid=40dcbd19-3b10-444e-bfff-aaee44a51fda

14.8.2.7. talos.hostname

Параметр talos.hostname устанавливает имя хоста на раннем этапе загрузки.
Обычно hostname задаётся в machine configuration, однако этот параметр полезен, если DHCP-сервер требует hostname до получения конфигурации узла.

14.8.2.8. talos.shutdown

Параметр talos.shutdown определяет тип завершения работы системы.
Поддерживаемые значения:
  • halt;
  • poweroff.

14.8.2.9. talos.network.interface.ignore

Параметр talos.network.interface.ignore позволяет исключить интерфейс из автоматической настройки.
По умолчанию ALT Orchestra пытается настроить все активные интерфейсы через DHCP. Если DHCP отсутствует, это может замедлить загрузку системы.
Параметр можно указывать несколько раз:
talos.network.interface.ignore=eth2
talos.network.interface.ignore=eth3

14.8.2.10. talos.auditd.disabled

По умолчанию:
  • журналы ядра выводятся в /dev/tty1;
  • панель управления запускается в /dev/tty2.
Для отключения панели управления:
talos.dashboard.disabled=1
После этого:
  • dashboard не запускается;
  • сообщения ядра выводятся в текущую активную консоль.

14.8.2.11. talos.dashboard.disabled

По умолчанию ALT Orchestra запускает службу auditd, которая обрабатывает события аудита ядра Linux.
Для отключения:
talos.auditd.disabled=1
После этого можно использовать собственную службу аудита.

14.8.2.12. talos.environment

Параметр talos.environment позволяет задать переменные окружения.
Формат:
talos.environment=<key>=<value>
Пример:
talos.environment=http_proxy=http://proxy.example.com:8080
talos.environment=https_proxy=http://proxy.example.com:8080

Глава 15. Интерактивная панель мониторинга кластера

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

Примечание

Панель мониторинга можно отключить с помощью параметра ядра talos.dashboard.disabled=1.
Панель мониторинга работает только на физической видеоконсоли (не на последовательной консоли) на второй виртуальной TTY. На первой виртуальной TTY выводятся журналы ядра. Переключение между виртуальными консолями выполняется с помощью клавиш Alt+F1 и Alt+F2.
Клавиши F1Fn используются для переключения между экранами панели мониторинга. Доступны следующие экраны:
  • Сводная информация;
  • Монитор ресурсов;
  • Конфигурация сети.
Панель мониторинга использует либо буфер кадров UEFI (для современных систем), либо VGA/VESA (для legacy BIOS).

Примечание

Для legacy BIOS разрешение экрана можно задать с помощью параметра ядра vga=.
В верхней части экрана сводной информации (F1) отображается краткая информация об узле:
  • имя узла;
  • версия ALT Orchestra;
  • время работы;
  • данные о CPU и памяти;
  • текущая загрузка CPU и памяти, количество процессов.
Интерактивная панель мониторинга. Сводная информация
Под строкой краткой информации в табличном виде представлена сводная информация о машине:
  • UUID (из данных SMBIOS);
  • имя кластера (если задано);
  • этап работы (STAGE): установка, обновление, загрузка, обслуживание, запуск, перезагрузка, выключение и т. д.;
  • статус готовности (READY): состояние служб, статических подов (на этапе выполнения) и т. д.;
  • тип машины: controlplane или worker;
  • количество обнаруженных участников кластера;
  • версия Kubernetes;
  • состояние компонентов Kubernetes:
    • kubelet;
    • компоненты controlplane (только для управляющих узлов);
  • сетевая информация: имя узла, IP-адрес, шлюз, состояние подключения, DNS- и NTP-серверы.
В нижней части экрана выводятся журналы ядра (аналогично первой виртуальной консоли).
Экран Монитор ресурсов (F2) представляет собой графический интерфейс для отслеживания в реальном времени ресурсов машины:
  • загрузки CPU;
  • использования памяти;
  • дисковых операций;
  • сетевой активности;
  • списка процессов.
Интерактивная панель мониторинга. Монитор ресурсов
Экран Конфигурация сети (F3) позволяет настраивать сетевые параметры для физического оборудования (bare metal). Экран разделен на три секции:
  • левая часть — настройка параметров сетевой конфигурации: имя узла, DNS- и NTP-серверы, выбор режима (DHCP или статический IP-адрес) и т. д.;
  • центральная часть — текущая конфигурация сети;
  • правая часть — предварительный просмотр новой конфигурации перед сохранением.
Интерактивная панель мониторинга. Конфигурация сети
После нажатия кнопки Save (Сохранить) изменения применяются немедленно.

Примечание

Экран конфигурации сети доступен только на физическом оборудовании (bare metal).

Глава 16. Журналирование и аудит

16.1. Работа с журналами ALT Orchestra

16.1.1. Просмотр журналов

Сообщения ядра можно получить с помощью команды talosctl dmesg:
$ talosctl -n 192.168.0.140 dmesg
Пример вывода:
…
192.168.0.140: kern:    info: [2026-05-20T09:04:32.286426442Z]: cni0: port 2(vethfc8629cd) entered disabled state
192.168.0.140: kern:    info: [2026-05-20T09:04:32.286454534Z]: vethfc8629cd: entered allmulticast mode
192.168.0.140: kern:    info: [2026-05-20T09:04:32.286520294Z]: vethfc8629cd: entered promiscuous mode
192.168.0.140: kern:    info: [2026-05-20T09:04:32.29266636Z]: cni0: port 2(vethfc8629cd) entered blocking state
192.168.0.140: kern:    info: [2026-05-20T09:04:32.292682238Z]: cni0: port 2(vethfc8629cd) entered forwarding state
Журналы служб можно получить с помощью команды talosctl logs:
$ talosctl -n 192.168.0.140 services
Пример вывода:
NODE          SERVICE     STATE    HEALTH  LAST CHANGE   LAST EVENT
192.168.0.140 apid        Running  OK      1h27m45s ago  Health check successful
192.168.0.140 auditd      Running  OK      1h27m58s ago  Health check successful
192.168.0.140 containerd  Running  OK      1h27m58s ago  Health check successful
192.168.0.140 cri         Running  OK      1h27m41s ago  Health check successful
192.168.0.140 dashboard   Running  ?       1h27m46s ago  Process Process(["/sbin/dashboard"]) started with PID 2143
192.168.0.140 etcd        Running  OK      1h27m30s ago  Health check successful
192.168.0.140 kubelet     Running  OK      1h27m26s ago  Health check successful
192.168.0.140 machined    Running  OK      1h27m58s ago  Health check successful
192.168.0.140 syslogd      Running   OK    1h27m57s ago  Health check successful
192.168.0.140 trustd      Running  OK      1h27m42s ago  Health check successful
192.168.0.140 udevd       Running  OK      1h27m48s ago  Health check successful
Журнал службы machined:
$ talosctl -n 192.168.0.140 logs machined
Пример вывода:
192.168.0.140: uthorized ([os:admin os:operator os:reader] includes [os:admin])
192.168.0.140: 2026/05/20 10:08:42.674116 machined OK [/machine.MachineService/LoadAvg] 684.822µs unary Success (:authority=localhost;content-type=application/grpc;grpc-accept-encoding=gzip;runtime=Talos;talos-role=os:admin;user-agent=grpc-go/1.79.3)
192.168.0.140: 2026/05/20 10:08:42.674139 machined/authz/authorizer authorized ([os:admin os:operator os:reader] includes [os:admin])
192.168.0.140: 2026/05/20 10:08:42.674196 machined OK [/machine.MachineService/Version] 61.501µs unary Success (:authority=localhost;content-type=application/grpc;grpc-accept-encoding=gzip;runtime=Talos;talos-role=os:admin;user-agent=grpc-go/1.79.3)
Журналы контейнеров (например, компонентов Kubernetes) можно получить с помощью команды:
$ talosctl -n 192.168.0.140 containers -k
Пример вывода:
NODE             NAMESPACE   ID                                                                                          IMAGE                                                            PID    STATUS

192.168.0.140   k8s.io      kube-system/coredns-5d988558b4-bprr7                                                          registry.altlinux.org/p11/pause:latest                      3706   SANDBOX_READY
192.168.0.140   k8s.io      └─ kube-system/coredns-5d988558b4-bprr7:coredns:12d271240d6a                                  registry.altlinux.org/p11/coredns:v1.13.1                   3729   CONTAINER_RUNNING
192.168.0.140   k8s.io      kube-system/coredns-5d988558b4-lcqkq                                                          registry.altlinux.org/p11/pause:latest                      3546   SANDBOX_READY
192.168.0.140   k8s.io      └─ kube-system/coredns-5d988558b4-lcqkq:coredns:e8d4666636d8                                  registry.altlinux.org/p11/coredns:v1.13.1                   3570   CONTAINER_RUNNING
192.168.0.140   k8s.io      kube-system/kube-apiserver-controlplane-01                                                    registry.altlinux.org/p11/pause:latest                      2534   SANDBOX_READY
192.168.0.140   k8s.io      └─ kube-system/kube-apiserver-controlplane-01:kube-apiserver:22ba4d5e9dc7                     registry.altlinux.org/p11/kube-apiserver:v1.35.0            2628   CONTAINER_RUNNING
…
Если некоторые рабочие нагрузки узла (например, системные расширения) отправляют сообщения в syslog, их можно получить с помощью команды:
$ talosctl -n 192.168.0.140 logs syslogd

16.1.2. Отправка журналов

16.1.2.1. Журналы служб

Отправку журналов можно включить в конфигурации машины:
machine:
  logging:
    destinations:
      - endpoint: "udp://127.0.0.1:12345/"
        format: "json_lines"
      - endpoint: "tcp://<IP_сервера>:5044/"
        format: "json_lines"
Допустим, требуется добавить расширение NVIDIA на bare metal машине, загружаемой с ISO. Поскольку это расширение не требуется на этапе загрузки или установки, его достаточно добавить только в образ установщика.
Можно указать несколько адресов назначения. Поддерживаемые протоколы: UDP и TCP. Единственный поддерживаемый формат — json_lines:
{
  "msg": "2026/04/22 10:53:06.280578 [talos] apply config request: mode auto(no_reboot)",
  "talos-level": "info",
  "talos-service": "machined",
  "talos-time": "2026-04-22T10:53:06.280622837Z"
}
Сообщения разделяются символом новой строки при отправке по протоколу TCP. При использовании UDP каждое сообщение отправляется отдельным пакетом.
Поля msg, talos-level, talos-service и talos-time присутствуют всегда; также могут добавляться дополнительные поля.
Каждое отправляемое сообщение можно расширить дополнительными полями, используя параметр extraTags в конфигурации машины:
machine:
  logging:
    destinations:
      - endpoint: "udp://127.0.0.1:12345/"
        format: "json_lines"
        extraTags:
          cluster: "prod-k8s-01"
          role: "controlplane"
Указанные extraTags добавляются к каждому отправляемому сообщению без изменений.
Syslog рассматривается как служба в ALT Orchestraпоэтому сообщения, отправляемые в syslog (например, системными расширениями), считаются журналами служб и пересылаются всем настроенным удаленным получателям без дополнительной настройки.
Пример настройки отправки журналов служб на сервер rsyslog:
  1. Cоздайте файл logging-patch.yaml с конфигурацией:
    $ cat > logging-patch.yaml << 'EOF'
    machine:
      logging:
        destinations:
          - endpoint: "tcp://192.168.0.100:5044/"
            format: "json_lines"
    EOF
    
  2. Примените конфигурацию к ноде:
    $ talosctl patch machineconfig -n <IP_узла> --patch @logging-patch.yaml
    
    или сразу ко всем нодам в кластере:
    $ talosctl patch machineconfig --patch @logging-patch.yaml
    

16.1.2.2. Журналы ядра

Отправка журнала ядра может быть включена с помощью аргумента командной строки ядра talos.logging.kernel, который указывается в machine.installer.extraKernelArgs:
machine:
  install:
    extraKernelArgs:
    - talos.logging.kernel=tcp://host:5044/
Также отправку журналов ядра можно настроить с помощью отдельного документа в конфигурации машины:
apiVersion: v1alpha1
kind: KmsgLogConfig
name: remote-log
url: tcp://host:5044/
Адрес назначения журнала ядра задаётся аналогично конечной точке журналов служб. Единственный поддерживаемый формат — json_lines.
Пример сообщения:
{
  "clock":19686864,
  "facility":"user",
  "msg":"[talos] task startAllServices (1/1): done, 4.607407038s\n",
  "priority":"warning",
  "seq":880,
  "talos-level":"warn",
  "talos-time":"2026-04-22T12:43:48.747807524Z"
}
Поля:
  • clock — время относительно момента загрузки ядра;
  • talos-level — уровень логирования;
  • talos-time — метка времени, вычисленная н а основе clock.
Параметры extraKernelArgs в конфигурации машины применяются только при обновлении ALT Orchestra, а не при обычном применении конфигурации (при этом обновление до той же версии допускается).
Пример настройки отправки журналов ядра на сервер rsyslog:
  1. Cоздайте файл kernel-logging-patch.yaml с конфигурацией:
    $ cat > kernel-logging-patch.yaml << 'EOF'
    machine:
      install:
        extraKernelArgs:
          - talos.logging.kernel=tcp://192.168.0.100:5044/
    EOF
    
  2. Примените конфигурацию к ноде:
    $ talosctl patch machineconfig -n <IP_узла> --patch @kernel-logging-patch.yaml
    
  3. Выполните обновление ноды (даже до той же версии), чтобы применить параметры ядра:
    $ talosctl upgrade -n <IP_узла> \
      -image factory.altlinux.space/alt-orchestra-metal-installer/376567988ad370138ad8b2698212367b8edcb69b5fd68c80be1f2ec7d603b4ba:v11.0
    

16.2. Аудит событий Kubernetes API

Аудит событий Kubernetes API в ALT Orchestra включён по умолчанию.

16.2.1. Просмотр параметров аудита kube-apiserver

Получить параметры аудита процесса kube-apiserver:
$ talosctl -n 192.168.0.140 processes | sed 's| |\n|g' | grep -E "(audit-policy|audit-log)"
Пример вывода:
--audit-log-maxage=30
--audit-log-maxbackup=10
--audit-log-maxsize=100
--audit-log-path=/var/log/audit/kube/kube-apiserver.log
--audit-policy-file=/system/config/kubernetes/kube-apiserver/auditpolicy.yaml

16.2.2. Проверка политики аудита

Проверить политику аудита через файловую систему:
$ talosctl -n 192.168.0.140 cat /system/config/kubernetes/kube-apiserver/auditpolicy.yaml
Пример вывода:
apiVersion: audit.k8s.io/v1
kind: Policy
metadata:
  creationTimestamp: null
rules:
- level: Metadata
Проверить политику аудита через машинную конфигурацию (machine configuration):
$ talosctl get mc -n 192.168.0.140 v1alpha1 \
   -o jsonpath='{.spec}' 2>/dev/null | \
   yq '.cluster.apiServer.auditPolicy'
Пример вывода:
{
  "apiVersion": "audit.k8s.io/v1",
  "kind": "Policy",
  "rules": [
    {
      "level": "Metadata"
    }
  ]
}

16.2.3. Проверка записей аудита

Проверить последнюю запись в журнале аудита:
$ talosctl -n 192.168.0.140 cat /var/log/audit/kube/kube-apiserver.log | \
  tail -n 1 | jq
Пример вывода:
{
  "kind": "Event",
  "apiVersion": "audit.k8s.io/v1",
  "level": "Metadata",
  "auditID": "35da1bd4-458d-4ae3-8d94-48a43f191b6a",
  "stage": "ResponseComplete",
  "requestURI": "/apis/coordination.k8s.io/v1/namespaces/kube-system/leases/kube-scheduler?timeout=5s",
  "verb": "get",
  "user": {
    "username": "system:kube-scheduler",
    "groups": [
      "system:kube-scheduler",
      "system:authenticated"
    ],
    "extra": {
      "authentication.kubernetes.io/credential-id": [
        "X509SHA256=1c78e3fa4db5aa8c23483a739b010dde1e044a80a7b03afa108f90ab00913b16"
      ]
    }
  },
  "sourceIPs": [
    "fdda:e7b2:9f17:0:a00:27ff:fee4:406d"
  ],
  "userAgent": "kube-scheduler/v1.33.6 (linux/amd64) kubernetes/1e09fec/leader-election",
  "objectRef": {
    "resource": "leases",
    "namespace": "kube-system",
    "name": "kube-scheduler",
    "apiGroup": "coordination.k8s.io",
    "apiVersion": "v1"
  },
  "responseStatus": {
    "metadata": {},
    "code": 200
  },
  "requestReceivedTimestamp": "2026-04-16T15:58:38.860528Z",
  "stageTimestamp": "2026-04-16T15:58:38.863596Z",
  "annotations": {
    "authorization.k8s.io/decision": "allow",
    "authorization.k8s.io/reason": "RBAC: allowed by ClusterRoleBinding \"system:kube-scheduler\" of ClusterRole \"system:kube-scheduler\" to User \"system:kube-scheduler\""
  }
}

16.2.4. Изменение уровня аудита Kubernetes API

Пример patch-запроса:
[
    {
        "op": "replace",
        "path": "/cluster/apiServer/auditPolicy/rules/0/level",
        "value": "RequestResponse"
    }
]
Применить patch ко всем управляющим узлам:
$ talosctl -n 192.168.0.140 patch machineconfig \
  -p '[{"op":"replace","path":"/cluster/apiServer/auditPolicy/rules/0/level","value":"RequestResponse"}]'

$ talosctl -n 192.168.0.141 patch machineconfig \
  -p '[{"op":"replace","path":"/cluster/apiServer/auditPolicy/rules/0/level","value":"RequestResponse"}]'

Проверить политику аудита через файловую систему:
$ talosctl -n 192.168.0.140 cat /system/config/kubernetes/kube-apiserver/auditpolicy.yaml
Пример вывода:
apiVersion: audit.k8s.io/v1
kind: Policy
metadata:
  creationTimestamp: null
rules:
- level: RequestResponse
Проверить политику аудита через машинную конфигурацию:
$ talosctl get mc -n 192.168.0.140 v1alpha1 \
   -o jsonpath='{.spec}' 2>/dev/null | yq '.cluster.apiServer.auditPolicy'
Пример вывода:
{
  "apiVersion": "audit.k8s.io/v1",
  "kind": "Policy",
  "rules": [
    {
      "level": "RequestResponse"
    }
  ]
}

16.2.5. Проверка изменений в логах

Интерактивная панель мониторинга Service Account:
$ kubectl --kubeconfig ./kubeconfig create sa test
Проверить последнюю запись в журнале аудита:
$ talosctl -n 192.168.0.140 cat /var/log/audit/kube/kube-apiserver.log | \
  tail -n 1 | jq

Пример вывода:
{
  "kind": "Event",
  "apiVersion": "audit.k8s.io/v1",
  "level": "RequestResponse",
  "auditID": "4fe3c9a3-76e7-445a-a8f3-db0e31761652",
  "stage": "ResponseComplete",
  "requestURI": "...",
  "verb": "..."
...
}

Глава 17. Обновление ALT Orchestra

Для обновления машины с ALT Orchestra необходимо использовать CLI-инструмент talosctl, который взаимодействует с API узла.
Обновление выполняется путём передачи узлу образа установщика соответствующей версии. Каждый релиз ALT Orchestra сопровождается собственным образом установщика.
ALT Orchestra использует схему A/B загрузки, при которой:
  • предыдущее ядро и образ ОС сохраняются после каждого обновления;
  • при неудачной загрузке новая версия автоматически откатывается;
  • также возможен ручной откат с помощью команды talosctl rollback либо соответствующего API-вызова (смена записи загрузки с последующей перезагрузкой).

Примечание

Обновление ALT Orchestra не включает автоматическое обновление Kubernetes. Обновление компонентов Kubernetes (control-plane, kubelet и т. д.) должно выполняться отдельно, в рамках обновления кластера Kubernetes.

17.1. Поддерживаемые пути обновления

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

17.2. Обновление узла

Для обновления узла используется команда talosctl upgrade.

Таблица 17.1. Параметры команды talosctl upgrade

Параметр
Описание
-n, --nodes
IP-адреса или имена узлов, которые необходимо обновить
--image, -i
Образ установщика ALT Orchestra, используемый для обновления (по умолчанию: altlinux.space/alt-orchestra/installer:<LAST_VERSION>)
--stage, -s
Отложить применение обновления до следующей перезагрузки (артефакты сохраняются на диск, обновление выполняется на раннем этапе загрузки)
--force, -f
Принудительно выполнить обновление, пропустив проверки состояния etcd (может привести к потере данных)
--reboot-mode, -m
Режим перезагрузки:
  • default — использовать kexec (быстрая перезагрузка);
  • powercycle — полный цикл питания (обход kexec)
--insecure
Выполнить обновление через незащищённый режим обслуживания (без аутентификации, только шифрование). Требуется при работе в режиме maintenance
--endpoints, -e
Переопределить адреса endpoints из конфигурации ALT Orchestra
--talosconfig
Путь к файлу конфигурации ALT Orchestra (по умолчанию $HOME/.talos/config)
--context
Контекст подключения (например, при использовании прокси или SideroV1)
--debug
Включить отладочный вывод (в том числе из журналов ядра). Автоматически включает --wait
--wait
Ожидать завершения операции и отслеживать её прогресс (по умолчанию true)
--timeout
Максимальное время ожидания завершения операции (по умолчанию 30m)
Чтобы обновить узел ALT Orchestra, необходимо указать IP-адрес узла и образ контейнера установщика той версии ALT Orchestra, до которой требуется обновление:
$ talosctl -n <IP-адрес-узла> upgrade --image <новый-образ>
Данную команду можно использовать для обновления до новой версии ALT Orchestra, указав соответствующий образ установщика:
$ talosctl upgrade -n <IP-адрес-узла> \
  --image factory.altlinux.space/alt-orchestra-metal-installer/<идентификатор>:<новая версия>
Пример:
$ talosctl upgrade -n 192.168.0.140 \
  --image factory.altlinux.space/alt-orchestra-metal-installer/376567988ad370138ad8b2698212367b8edcb69b5fd68c80be1f2ec7d603b4ba:v11.0
Обновление узла
Аналогичным образом можно использовать процесс обновления для перехода на новый набор системных расширений: сгенерировать новую схему с требуемым набором расширений системы и обновить узел до нового идентификатора схемы:
$ talosctl upgrade -n <IP-адрес-узла> \
  --image factory.altlinux.space/alt-orchestra-metal-installer/<новый идентификатор>:v11.0
Пример:
$ talosctl -n 192.168.0.146 get extensions
NODE           NAMESPACE  TYPE             ID   VERSION   NAME        VERSION
192.168.0.147  runtime    ExtensionStatus  0    1         schematic   376567988ad370138ad8b2698212367b8edcb69b5fd68c80be1f2ec7d603b4ba


$ talosctl upgrade -n 192.168.0.146 \
  --image factory.altlinux.space/alt-orchestra-metal-installer/ea2358d7be66761ea85e66f01f11936df9c93b7647ddc9cd89c0e5e5131c4080:v11.0

$ talosctl -n 192.168.0.146 get extensions
NODE           NAMESPACE   TYPE              ID   VERSION   NAME               VERSION
192.168.0.146  runtime     ExtensionStatus   0    1         qemu-guest-agent   9.1.2
192.168.0.146  runtime     ExtensionStatus   1    1         util-linux-tools   2.39.2
192.168.0.146  runtime     ExtensionStatus   2    1         schematic          ea2358d7be66761ea85e66f01f11936df9c93b7647ddc9cd89c0e5e5131c4080
Проверка версии после обновления:
$ talosctl -n <IP-адрес-узла> version
Также необходимо убедиться, что kubelet, контейнеры и сетевые службы работают корректно:
$ talosctl -n <IP-адрес-узла> health
Иногда команда обновления может завершиться неудачей из-за того, что какой-либо процесс удерживает файл на диске. В таких случаях используйте флаг --stage.
Этот флаг размещает артефакты обновления на диске и записывает метаданные в специальный раздел, который проверяется на самых ранних этапах загрузки. После этого узел перезагружается. При следующей загрузке ALT Orchestra обнаруживает необходимость применения обновления и выполняет его автоматически.
Поскольку система только что перезагрузилась, конфликты с открытыми файлами отсутствуют. После завершения обновления узел перезагружается повторно, чтобы загрузиться с новой версией.

Примечание

Поскольку ALT Orchestra использует системный вызов kexec для перезагрузки, дополнительная перезагрузка занимает минимальное время.

17.3. Последовательность обновления узла

Процесс обновления ALT Orchestra спроектирован таким образом, чтобы минимизировать влияние на кластер и обеспечить атомарность перехода на новую версию.
Последовательность обновления:
  1. Блокировка узла в Kubernetes. Узел помечает себя как недоступный для новых подов, чтобы предотвратить размещение новой рабочей нагрузки.
  2. Освобождение текущей нагрузки. Выполняется постепенное завершение текущих подов.
  3. Завершение внутренних служб. После удаления подов ALT Orchestra завершает работу собственных процессов.
  4. Размонтирование файловых систем. Выполняется полное размонтирование всех файловых систем, чтобы минимизировать побочные эффекты обновления и приблизить процесс к «чистой» установке.
  5. Проверка и запись образа. Выполняется проверка диска, затем загружается и записывается новый образ ALT Orchestra.
  6. Настройка загрузчика. ALT Orchestra настраивает загрузчик для однократной загрузки в новую версию и инициирует перезагрузку.
  7. Проверка и завершение. После загрузки система проверяет целостность, делает новую загрузочную запись постоянной и повторно присоединяется к кластеру.
  8. Снятие блокировки. Узел снова становится доступен для размещения рабочих нагрузок.
Этот механизм обеспечивает надёжный, контролируемый и обратимый процесс обновления с минимальным вмешательством пользователя.

Примечание

Если какая-либо рабочая нагрузка чувствительна к некорректному завершению работы, необходимо использовать спецификацию lifecycle.preStop подa в её манифесте.

Часть V. CNI (сетевая подсистема Kubernetes)

Container Network Interface (CNI) — это стандартный механизм настройки сетевого взаимодействия контейнеров в Kubernetes. CNI-плагин отвечает за подключение подов к сети, маршрутизацию трафика, назначение IP-адресов и применение сетевых политик.
По умолчанию ALT Orchestra автоматически устанавливает Flannel. При необходимости можно использовать другой CNI-плагин, например Cilium, либо развернуть собственный CNI-манифест.

Глава 18. Flannel

Flannel — это популярный плагин интерфейса контейнерной сети (CNI), предоставляющий простой и эффективный способ создания оверлейной сети для кластеров Kubernetes. Flannel используется в качестве CNI-плагина по умолчанию в ALT Orchestra, однако при необходимости может быть заменён другой реализацией CNI.
Проверить наличие Flannel в кластере можно, выполнив команду:
$ kubectl get pods -n kube-system
NAME                                 READY   STATUS    RESTARTS        AGE
…
kube-flannel-k4mw5                   1/1     Running   0               19h
kube-flannel-szd6s                   1/1     Running   2 (4h37m ago)   5h58m
kube-flannel-t5hsc                   1/1     Running   0               6h28m
…
Наличие подов с именем kube-flannel в пространстве имён kube-system указывает на использование Flannel в качестве сетевого плагина.
В сгенерированном конфигурационном файле отсутствие явного указания CNI означает использование значения по умолчанию. В явном виде, если необходимо добавить дополнительные параметры для Flannel, настройка будет выглядеть следующим образом:
cluster:
  network:
    cni:
      name: flannel
      flannel:
        # extraArgs — список строк ([]string), дополнительные аргументы для «flanneld»
        extraArgs:
          - --iface-can-reach=192.168.0.1
Адрес 192.168.0.1 в параметре --iface-can-reach приведён для примера. Его необходимо заменить на доступный из вашей сети адрес. При запуске flanneld будет определён IP-адрес узла и сетевой интерфейс, используемый для маршрута к указанному адресу.
ALT Orchestra поставляется с необходимым набором CNI-плагинов для работы Flannel, поэтому стандартную установку Flannel, выполняемую ALT Orchestra, при необходимости можно заменить пользовательской установкой.
Flannel инкапсулирует сетевой трафик между подами с помощью VXLAN (по умолчанию в ALT Orchestra). Это обеспечивает взаимодействие между подами, расположенными на разных узлах кластера, без необходимости дополнительной настройки базовой сетевой инфраструктуры.
В данной конфигурации kube-proxy отвечает за маршрутизацию трафика между подами и сервисами, а Flannel управляет оверлейной сетью и обеспечивает взаимодействие подов независимо от их физического расположения в кластере.

Примечание

Штатный Flannel в ALT Orchestra не обеспечивает применение (enforcement) ресурсов NetworkPolicy. Объекты NetworkPolicy будут успешно созданы в Kubernetes API, но фактическое ограничение сетевого трафика выполняться не будет. Для работы сетевых политик используйте CNI с поддержкой NetworkPolicy, например Cilium .

Глава 19. Cilium

Cilium — решение для организации сетевого взаимодействия, мониторинга и обеспечения безопасности на основе eBPF. Оно реализует плоскость данных Kubernetes и обеспечивает простую плоскую сеть уровня L3 с возможностью работы как в режиме нативной маршрутизации, так и в режиме оверлейной сети, включая поддержку нескольких кластеров.
Cilium поддерживает сетевые политики уровней L3–L7 и использует модель безопасности на основе идентификации, не зависящую от IP-адресации. Поддержка протоколов уровня L7 позволяет применять расширенные политики фильтрации и контроля трафика.
Cilium реализует распределённую балансировку нагрузки для трафика между подами и внешними сервисами, а также способен полностью заменить kube-proxy за счёт использования eBPF. Применение эффективных хеш-таблиц eBPF обеспечивает высокую производительность и масштабируемость.
Дополнительно Cilium поддерживает расширенные возможности, включая встроенный ingress- и egress-шлюзы, управление пропускной способностью, Service Mesh, а также предоставляет средства глубокой сетевой наблюдаемости и мониторинга безопасности.

19.1. Подготовка конфигурации машины

При создании конфигурации машины для узла необходимо установить для параметра CNI значение none. Например, с помощью патча конфигурации:
$ cat <<EOF > patch.yaml
cluster:
  network:
    cni:
      name: none
  proxy: #если вместо kube-proxy будет использоваться cilium-envoy
    disabled: true
EOF
Генерация конфигурации:
$ talosctl gen config $CLUSTER_NAME https://$CONTROL_PLANE_IP:6443 \
  --output-dir orchestra \
  --install-image $INSTALLERIMAGE \
  --with-secrets secrets.yaml \
  --config-patch @patch.yaml

Примечание

Далее необходимо развернуть кластер (подробнее см. в разделе Развертывание базового кластера):
  1. Применить конфигурацию к узлам:
    $ talosctl apply-config --insecure \
      --nodes 192.168.0.140 \
      --file orchestra/controlplane.yaml
    $ talosctl apply-config --insecure \
      --nodes 192.168.0.145 \
      --file orchestra/worker.yaml
    
  2. Настроить talosctl (после того как Control Plane станет доступен по API Talos):
    $ export TALOSCONFIG="$HOME/.talos/config"
    $ talosctl config merge orchestra/talosconfig
    $ talosctl --talosconfig $TALOSCONFIG config endpoint $CONTROL_PLANE_IP
    $ talosctl --talosconfig $TALOSCONFIG config node $CONTROL_PLANE_IP
    $ talosctl bootstrap \
      --nodes $CONTROL_PLANE_IP \
      --talosconfig $TALOSCONFIG
    
  3. После запуска Control Plane получить kubeconfig:
    $ talosctl kubeconfig .
    $ export KUBECONFIG=./kubeconfig
    

19.2. Установка с помощью Helm

Установка пакета helm:
# apt-get install helm
Предварительно необходимо добавить Helm-репозиторий для Cilium:
$ helm repo add cilium https://helm.cilium.io/
$ helm repo update
После применения конфигурации машины и начальной загрузки ALT Orchestra процесс может остановиться на этапе 18/19 с сообщением о том, что узел не готов (node not ready). Это происходит потому, что Kubernetes помечает узлы как готовые только после запуска CNI. Поскольку CNI ещё не установлен, процесс загрузки переходит в состояние ожидания, а узел через 10 минут будет автоматически перезагружен для повторной попытки. Такое поведение является ожидаемым.
В течение этого времени можно вручную установить Cilium, выполнив следующую команду:
$ helm install \
  cilium \
  cilium/cilium \
  --version VERSION \
  --namespace kube-system \
  --set ipam.mode=kubernetes \
  --set kubeProxyReplacement=false \
  --set securityContext.capabilities.ciliumAgent="{CHOWN,KILL,NET_ADMIN,NET_RAW,IPC_LOCK,SYS_ADMIN,SYS_RESOURCE,DAC_OVERRIDE,FOWNER,SETGID,SETUID}" \
  --set securityContext.capabilities.cleanCiliumState="{NET_ADMIN,SYS_ADMIN,SYS_RESOURCE}" \
  --set cgroup.autoMount.enabled=false \
  --set cgroup.hostRoot=/sys/fs/cgroup
Если требуется развернуть Cilium без kube-proxy, необходимо дополнительно указать следующие параметры:
$ helm install \
  cilium \
  cilium/cilium \
  --version VERSION \
  --namespace kube-system \
  --set ipam.mode=kubernetes \
  --set kubeProxyReplacement=true \
  --set securityContext.capabilities.ciliumAgent="{CHOWN,KILL,NET_ADMIN,NET_RAW,IPC_LOCK,SYS_ADMIN,SYS_RESOURCE,DAC_OVERRIDE,FOWNER,SETGID,SETUID}" \
  --set securityContext.capabilities.cleanCiliumState="{NET_ADMIN,SYS_ADMIN,SYS_RESOURCE}" \
  --set cgroup.autoMount.enabled=false \
  --set cgroup.hostRoot=/sys/fs/cgroup \
  --set k8sServiceHost=localhost \
  --set k8sServicePort=7445
Для включения поддержки Gateway API необходимо дополнительно указать параметры:
…
  --set gatewayAPI.enabled=true \
  --set gatewayAPI.enableAlpn=true \
  --set gatewayAPI.enableAppProtocol=true
Для установки Cilium на базе ALT Linux можно использовать файл values.yaml:
-f https://altlinux.space/cloud/charts/raw/branch/master/cilium/<branch>/<version>/values.yaml
Например:
-f https://altlinux.space/cloud/charts/src/branch/master/cilium/sisyphus/1.18.2/values.yaml
Список доступных версий cilium можно получить с помощью команды:
$ helm search repo cilium/cilium –versions
Рекомендуется использовать последнюю стабильную версию, совместимую с используемой версией Kubernetes.

Примечание

Команда helm install выполняется с рабочей станции администратора, на которой настроен kubeconfig. Helm использует текущий kubeconfig для подключения к Kubernetes API. После этого Kubernetes автоматически развернёт компоненты Cilium на соответствующих узлах с помощью DaemonSet.
Пример вывода после развертывания Cilium:
NAME: cilium
LAST DEPLOYED: Mon May 25 12:35:04 2026
NAMESPACE: kube-system
STATUS: deployed
REVISION: 1
TEST SUITE: None
NOTES:
You have successfully installed Cilium with Hubble.

Your release version is 1.19.3.
После установки Cilium процесс загрузки узлов должен продолжиться и успешно завершиться.

19.3. Проверка работы сети

После установки Cilium на рабочем месте администратора можно установить утилиту cilium-cli и проверить работоспособность сети с помощью встроенной команды тестирования.
При необходимости можно дополнительно активировать веб-интерфейс Hubble, встроенный в конфигурацию Cilium и предназначенный для мониторинга сетевого трафика.
Установка cilium-cli:
# apt-get install cilium-cli
Проверка статуса:
$ cilium status
Ожидаемый вывод:
    /¯¯\
 /¯¯\__/¯¯\    Cilium:             OK
 \__/¯¯\__/    Operator:           OK
 /¯¯\__/¯¯\    Envoy DaemonSet:    OK
 \__/¯¯\__/    Hubble Relay:       disabled
    \__/       ClusterMesh:        disabled

DaemonSet              cilium                   Desired: 2, Ready: 2/2, Available: 2/2
DaemonSet              cilium-envoy             Desired: 2, Ready: 2/2, Available: 2/2
Deployment             cilium-operator          Desired: 2, Ready: 2/2, Available: 2/2
Containers:            cilium                   Running: 2
                       cilium-envoy             Running: 2
                       cilium-operator          Running: 2
                       clustermesh-apiserver
                       hubble-relay
Cluster Pods:          2/2 managed by Cilium
Helm chart version:    1.19.3
Image versions         cilium             quay.io/cilium/cilium:v1.19.3@sha256:2e61680593cddca8b6c055f6d4c849d87a26a1c91c7e3b8b56c7fb76ab7b7b10: 2
                       cilium-envoy       quay.io/cilium/cilium-envoy:v1.36.6-1776000132-2437d2edeaf4d9b56ef279bd0d71127440c067aa@sha256:ba0ab8adac082d50d525fd2c5ba096c8facea3a471561b7c61c7a5b9c2e0de0d: 2
                       cilium-operator    quay.io/cilium/operator-generic:v1.19.3@sha256:205b09b0ed6accbf9fe688d312a9f0fcfc6a316fc081c23fbffb472af5dd62cd
Автоматическая проверка сетевого взаимодействия в Kubernetes-кластере:
$ cilium connectivity test
Данная команда запускает набор встроенных тестов в пространстве имён default.
Однако проверка сети может завершиться ошибкой или зависнуть с сообщением, аналогичным следующему:
Error creating: pods "client-69748f45d8-9b9jg" is forbidden: violates PodSecurity "baseline:latest": non-default capabilities (container "client" must not include "NET_RAW" in securityContext.capabilities.add)
Такое поведение является ожидаемым. Для обхода ограничения необходимо добавить метку pod-security.kubernetes.io/enforce=privileged для пространства имён, в котором выполняются тесты. Например:
$ kubectl label namespace cilium-test \
  pod-security.kubernetes.io/enforce=privileged
После этого команду cilium connectivity test можно выполнить повторно.

Глава 20. Пользовательское развертывание CNI

По умолчанию ALT Orchestra автоматически устанавливает Flannel. Если требуется изменить параметры Flannel или использовать другой CNI-плагин, можно развернуть пользовательский манифест.

20.1. Манифест по URL

Установите тип CNI custom и укажите URL-адреса манифестов в параметре urls:
cluster:
  network:
    cni:
      name: custom
      urls:
        - <URL_TO_MANIFEST>
        - …
где:
  • name: custom — включает пользовательский CNI;
  • urls — список URL-адресов манифестов Kubernetes, которые будут автоматически применены при загрузке кластера.

20.2. Локальный манифест

Установите тип CNI none и укажите содержимое манифеста в параметре inlineManifests:
cluster:
  network:
    cni:
      name: none
  inlineManifests:
    - name: namespace-ci
      contents: |
        <MANIFEST_DATA>
        …
где:
  • name: none — отключает автоматическую установку встроенного CNI;
  • inlineManifests — список локальных Kubernetes-манифестов, которые будут применены при запуске кластера;
  • contents — содержимое Kubernetes-манифеста в формате YAML.

Часть VI. Управление хранением данных и дисками

Глава 21. Шифрование системных дисков на уровне ОС

В ALT Orchestra можно включить шифрование системных разделов на уровне операционной системы. На данный момент поддерживаются два раздела: STATE и EPHEMERAL:
  • STATE содержит наиболее чувствительные данные узла: секреты и сертификаты;
  • EPHEMERAL может содержать конфиденциальные данные рабочих нагрузок.
Шифрование реализуется с использованием LUKS2, предоставляемого модулями ядра Linux и утилитой cryptsetup. При включении шифрования система выполняет дополнительные этапы инициализации.

21.1. Шифрование раздела STATE

Если включено шифрование для раздела STATE, система:
  1. Сохраняет конфигурацию шифрования в формате JSON в разделе META.
  2. Перед монтированием STATE загружает конфигурацию шифрования либо из машинной конфигурации, либо из раздела META (приоритет имеет машинная конфигурация).
  3. Форматирует и шифрует раздел только в том случае, если он пуст и не содержит файловой системы.

21.2. Шифрование раздела EPHEMERAL

Если включено шифрование для раздела EPHEMERAL, система:
  1. Получает конфигурацию шифрования из машинной конфигурации.
  2. Шифрует и форматирует раздел только в том случае, если он пуст и не содержит файловой системы.

21.3. Поддерживаемые методы шифрования

ALT Orchestra поддерживает четыре метода шифрования, которые можно комбинировать для одного раздела.

Таблица 21.1. Поддерживаемые методы шифрования

Метод
Описание
static
Шифрование с использованием статического пароля (наименее защищённый способ). Для раздела STATE пароль хранится в незашифрованном разделе META
nodeID
Ключ генерируется на основе UUID узла (обеспечивает базовую защиту, не предназначен для защиты от атак с физическим доступом)
kms
Ключ запечатывается с использованием сетевого KMS (надёжно, но требует сетевого доступа до расшифровки)
tpm
Ключ запечатывается с использованием TPM (наиболее надёжный вариант, особенно в сочетании с Secure Boot)

Примечание

Метод nodeID не защищает от атак с физическим доступом к машине и диску. Диск, извлечённый из системы или перемещённый в другую ВМ, остаётся зашифрованным, но может быть расшифрован при наличии достаточной информации о параметрах узла.

Примечание

При использовании kms для раздела STATE нельзя указывать сетевые настройки в машинной конфигурации, так как KMS требует сетевого подключения до расшифровки STATE. Также нельзя использовать пользовательские CA-сертификаты для KMS, так как они хранятся в разделе STATE и недоступны на этапе расшифровки.

21.4. Конфигурация

По умолчанию шифрование отключено. Чтобы его включить, добавьте в машинную конфигурацию:
machine:
  systemDiskEncryption:
    ephemeral:
      provider: luks2
      keys:
        - nodeID: {}
          slot: 0
    state:
      provider: luks2
      keys:
        - nodeID: {}
          slot: 0

21.5. Ключи шифрования

Примечание

В терминологии LUKS2 «ключи» фактически являются паролями. При добавлении пароля LUKS2 использует Argon2 для генерации криптографического ключа.
LUKS2 поддерживает до 32 ключей. ALT Orchestra автоматически синхронизирует список ключей из конфигурации с фактическими ключами в разделе. При изменении списка необходимо сохранять хотя бы один неизменный ключ.
Каждый ключ должен иметь явно указанный slot (позицию):
state:
  keys:
    - nodeID: {}     # тип ключа
      slot: 1        # слот

ephemeral:
  keys:
    - static:
        passphrase: supersecret
      slot: 0
Порядок ключей в списке не влияет на выбор слота — каждый ключ должен иметь поле slot.

Таблица 21.2. Типы ключей

Тип
Описание
nodeID
Генерируется из UUID узла и метки раздела
static
Указывается напрямую в конфигурации
kms
Получается через сетевой KMS
tpm
Запечатывается с использованием TPM (с учётом состояния Secure Boot)

Примечание

Не рекомендуется использовать static для раздела STATE, так как пароль сохраняется в незашифрованном разделе META.

21.6. Ротация ключей

Полная замена ключей требует двух применений конфигурации, чтобы на каждом этапе оставался хотя бы один действующий ключ.
Шаг 1. Добавление нового ключа:
ephemeral:
  keys:
    - static:
        passphrase: oldkey
      slot: 0
    - static:
        passphrase: newkey
      slot: 1

$ talosctl apply-config -n <IP-адрес-узла> -f config.yaml
Шаг 2. Удаление старого ключа:
ephemeral:
  keys:
    - static:
        passphrase: newkey
      slot: 1

$ talosctl apply-config -n <IP-адрес-узла> -f config.yaml

21.7. Переход между зашифрованным и незашифрованным состоянием

21.7.1. Раздел EPHEMERAL

Прямое шифрование «на лету» не поддерживается: шифрование возможно только для пустых разделов.
Процедура перехода к шифрованию:
  1. Добавьте конфигурацию шифрования в config.yaml.
  2. Примените её в режиме staged:
    $ talosctl apply-config -n <IP-адрес-узла> -f config.yaml --mode=staged
    
  3. Очистите раздел перед перезагрузкой:
    $ talosctl reset --system-labels-to-wipe EPHEMERAL -n <IP-адрес-узла> --reboot=true
    
После перезагрузки система автоматически зашифрует раздел.

21.7.2. Раздел STATE

Очистка раздела STATE приводит к потере конфигурации, поэтому стандартная процедура не применяется.
Порядок действий:
  1. Очистите раздел STATE:
    $ talosctl reset --system-labels-to-wipe STATE -n <IP-адрес-узла> --reboot=true
    
  2. После перезагрузки узел перейдёт в режим обслуживания (maintenance mode).
  3. Примените новую конфигурацию с флагом --insecure:
    $ talosctl apply-config --insecure -n <IP-адрес-узла> -f config.yaml
    
После установки раздел STATE будет зашифрован.

Глава 22. Управление дисками

22.1. Список дисков

Для получения списка всех доступных блочных устройств (дисков) на машине используется команда:
$ talosctl get disks
Пример вывода:
NODE           NAMESPACE TYPE  ID    VERSION  SIZE    READ ONLY  TRANSPORT
192.168.0.140  runtime   Disk  loop0 2        4.1 kB  true
192.168.0.140  runtime   Disk  loop1 2        98 MB   true
192.168.0.140  runtime   Disk  sda            11 GB   false      virtio
Для получения подробной информации о конкретном диске можно выполнить команду:
$ talosctl get disk sda -o yaml
Пример вывода:
node: 192.168.0.140
metadata:
    namespace: runtime
    type: Disks.block.talos.dev
    id: sda
    version: 2
    owner: block.DisksController
    phase: running
    created: 2026-04-22T08:25:37Z
    updated: 2026-04-22T08:25:48Z
spec:
    dev_path: /dev/sda
    size: 10737418240
    pretty_size: 11 GB
    io_size: 512
    sector_size: 512
    readonly: false
    cdrom: false
    model: QEMU HARDDISK
    modalias: scsi:t-0x00
    bus_path: /pci0000:00/0000:00:05.0/0000:01:01.0/virtio4/host2/target2:0:0/2:0:0:0
    sub_system: /sys/class/block
    transport: virtio
    rotational: true
    symlinks:
        - /dev/disk/by-diskseq/11
        - /dev/disk/by-id/scsi-0QEMU_QEMU_HARDDISK_drive-scsi0
        - /dev/disk/by-path/pci-0000:01:01.0-scsi-0:0:0:0

22.2. Обнаружение томов

ALT Orchestra отслеживает все блочные устройства и разделы на машине. Подробная информация об этих устройствах, включая их тип, содержатся в ресурсе DiscoveredVolume:
$ talosctl get discoveredvolumes
Пример вывода:
NODE          ID     TYPE      SIZE    DISCOVERED  LABEL      PARTITIONLABEL
192.168.0.140 loop1  disk      98 MB   squashfs
192.168.0.140 sda    disk      11 GB   gpt
192.168.0.140 sda1   partition 105 MB  vfat        EFI         EFI
192.168.0.140 sda2   partition 1.0 MB                          BIOS
192.168.0.140 sda3   partition 1.0 GB  xfs         BOOT        BOOT
192.168.0.140 sda4   partition 1.0 MB  talosmeta               META
192.168.0.140 sda5   partition 105 MB  xfs         STATE       STATE
192.168.0.140 sda6   partition 9.5 GB  xfs         EPHEMERAL   EPHEMERAL
ALT Orchestra автоматически распознаёт различные типы файловых систем и таблицы разделов (GPT). В настоящее время поддерживаются следующие файловые системы:
  • bluestore (Ceph)
  • ext2, ext3, ext4
  • iso9660
  • luks (шифрованный раздел LUKS)
  • lvm2
  • squashfs
  • swap
  • talosmeta (системный раздел META)
  • vfat
  • xfs
  • ext2, ext3, ext4
  • zfs
Обнаруженные тома могут включать как управляемые ALT Orchestra тома, так и любые другие тома на машине (например, тома Ceph).

22.3. Управление томами

Управление дисками в ALT Orchestra реализовано через понятие тома (volume). Том представляет собой сущность, которая может быть:
  • подготовлена к использованию;
  • обнаружена на диске;
  • смонтирована или размонтирована (например, раздел или файловая система tmpfs).
Конфигурация томов задаётся через ресурс VolumeConfig, а текущее состояние хранится в ресурсе VolumeStatus.

22.3.1. Конфигурация

Конфигурация томов управляется ALT Orchestra на основе машинной конфигурации.
Просмотреть настроенные тома можно с помощью команды:
$ talosctl get volumeconfigs
Пример вывода:
NODE           NAMESPACE  TYPE          ID                            VERSION
192.168.0.140  runtime    VolumeConfig  /etc/cni                           2
192.168.0.140  runtime    VolumeConfig  /etc/kubernetes                    2
192.168.0.140  runtime    VolumeConfig  /opt                               2
192.168.0.140  runtime    VolumeConfig  /usr/libexec/kubernetes            2
192.168.0.140  runtime    VolumeConfig  /var/lib                           2
..
192.168.0.140  runtime    VolumeConfig  /var/run/lock                      2
192.168.0.140  runtime    VolumeConfig  EPHEMERAL                          2
192.168.0.140  runtime    VolumeConfig  ETCD                               2
192.168.0.140  runtime    VolumeConfig  META                               2
192.168.0.140  runtime    VolumeConfig  STATE                              3
В выводе тома EPHEMERAL, META и STATE являются системными и управляются ALT Orchestra автоматически. Остальные тома определяются в разделе machine.disks машинной конфигурации.
Для просмотра деталей конкретного тома используется команда:
$ talosctl get volumeconfig STATE -o yaml
Пример вывода:
node: 192.168.0.140
metadata:
    namespace: runtime
    type: VolumeConfigs.block.talos.dev
    id: STATE
    version: 3
    owner: block.VolumeConfigController
    phase: running
    created: 2026-04-22T08:25:36Z
    updated: 2026-04-22T08:25:49Z
    finalizers:
        - block.VolumeManagerController
spec:
    type: partition
    provisioning:
        wave: -1
        diskSelector:
            match: system_disk
        partitionSpec:
            minSize: 104857600
            maxSize: 104857600
            grow: false
            label: STATE
            typeUUID: 0FC63DAF-8483-4772-8E79-3D69D8477DE4
        filesystemSpec:
            type: xfs
            label: STATE
    locator:
        match: volume.partition_label == "STATE"
    mount:
        targetPath: /system/state
        selinuxLabel: system_u:object_r:system_state_t:s0
        projectQuotaSupport: false
        fileMode: 448

22.3.2. Состояние

Текущее состояние томов можно получить командой:
$ talosctl get volumestatus
Пример вывода:
NODE            ID               VERSION  TYPE        PHASE   LOCATION   SIZE
192.168.0.140   /etc/cni         3        overlay     ready
192.168.0.140   /etc/kubernetes  3        overlay     ready
192.168.0.140   /var/lib         2        directory   ready
...
192.168.0.140   EPHEMERAL        6        partition   ready   /dev/sda6  9.5 GB
192.168.0.140   ETCD             2        directory   ready
192.168.0.140   META             3        partition   ready   /dev/sda4  1.0 MB
192.168.0.140   STATE            6        partition   ready   /dev/sda5  105 MB
Каждый том проходит несколько этапов жизненного цикла.

Таблица 22.1. Этапы жизненного цикла тома

Состояние
Описание
waiting
Том ожидает подготовки
missing
Диски обнаружены, но том не найден
located
Том найден без предварительной подготовки
provisioned
Том подготовлен (разделён, при необходимости изменён размер)
prepared
Зашифрованный том открыт
ready
Том отформатирован и готов к монтированию
closed
Зашифрованный том закрыт

22.4. Машинная конфигурация

Примечание

Через машинную конфигурацию можно управлять только системным томом EPHEMERAL.

Примечание

Настройки применяются только в том случае, если том ещё не был подготовлен. Изменения после первоначальной настройки не вступают в силу.
Чтобы настроить том EPHEMERAL (/var), необходимо добавить в машинную конфигурацию:
apiVersion: v1alpha1
kind: VolumeConfig
name: EPHEMERAL
provisioning:
  diskSelector:
    match: disk.transport == 'nvme'
  minSize: 2GB
  maxSize: 40GB
  grow: false
Все поля в VolumeConfig являются необязательными. Если поле не указано, используется значение по умолчанию:
provisioning:
  diskSelector:
    match: system_disk
  minSize: 2GiB
  grow: true
По умолчанию том EPHEMERAL создаётся на системном диске (диске, на который установлена ALT Orchestra), имеет минимальный размер 2 ГиБ и автоматически расширяется до максимально доступного размера.

22.4.1. Выбор диска (Disk Selector)

Поле diskSelector позволяет выбрать диск для размещения тома. Это выражение на языке Common Expression Language (CEL), которое вычисляется для каждого доступного диска.
Контекст вычисления:
  • system_disk (bool) — является ли диск системным;
  • disk — объект диска.
Для дискового ресурса можно использовать любые поля, доступные в спецификации (см. talosctl get disks -o yaml):
dev_path: /dev/sda
size: 10737418240
pretty_size: 11 GB
io_size: 512
sector_size: 512
readonly: false
…
Доступные константы для размеров:
  • бинарные: KiB, MiB, GiB, TiB, PiB, EiB (основание 1024);
  • десятичные: kB, MB, GB, TB, PB, EB (основание 1000).

Примечание

Размеры дисков — беззнаковые целые числа. Используйте суффикс u для констант:
disk.size > 10u * GiB
Выражение выбора диска должно возвращать true или false. Если результат — true, диск выбирается для размещения тома.
Примеры выражений:
  • disk.transport == 'nvme' — только NVMe-диски;
  • disk.transport == 'scsi' && disk.size < 2u * TiB — SCSI-диски меньше 2 ТиБ;
  • disk.serial.startsWith('abcd') && !cdrom — диски с заданным серийным номером, кроме CD-ROM.
Том будет создан на первом подходящем диске с достаточным объёмом свободного места.

22.4.2. Минимальный и максимальный размер

Поля minSize и maxSize задают границы размера тома:
  • том будет не меньше minSize;
  • если maxSize не задан, том займёт всё доступное место;
  • при grow: true том будет автоматически расширяться при каждой загрузке.
Если на диске недостаточно свободного места для выполнения условия minSize, он не будет выбран для размещения тома.

Часть VII. Конечная точка доступа Kubernetes API

При наличии нескольких узлов Control Plane (управляющих узлов) возникает вопрос обеспечения высокой доступности, при которой конечная точка Kubernetes API может взаимодействовать со всеми узлами плоскости управления. Для production-сред обычно используются два распространённых способа настройки:
  • выделенный балансировщик нагрузки, направляющий трафик на узлы на Control Plane;
  • создание нескольких DNS-записей, указывающих на все Control Plane.
С помощью этих механизмов можно указать единый IP-адрес или DNS-имя при настройке кластера, которое будет маршрутизировать трафик ко всем управляющим узлам.

Глава 23. Выделенный балансировщик нагрузки

Если используется облачный провайдер или собственный балансировщик нагрузки (например, HAProxy, обратный прокси NGINX или балансировщик нагрузки F5), то настройка выделенного балансировщика нагрузки является естественным выбором. Необходимо настроить интерфейс для прослушивания TCP-порта 6443 и перенаправления трафика на адреса управляющих узлов. В качестве конечной точки Kubernetes используется IP-адрес или DNS-имя интерфейса балансировщика нагрузки с указанием порта, например:
https://myK8s.mydomain.io:6443

Примечание

Не следует использовать HTTP-балансировщик нагрузки, поскольку Kubernetes API Server самостоятельно выполняет завершение TLS-соединения и взаимную TLS-аутентификацию.

Глава 24. DNS-записи

Конечную точку доступа Kubernetes также можно настроить с использованием DNS-имени. Для этого необходимо добавить несколько записей типа A или AAAA — по одной для каждого управляющего узла. Например:
kube.cluster1.mydomain.com IN A 192.168.0.10
kube.cluster1.mydomain.com IN A 192.168.0.11
kube.cluster1.mydomain.com IN A 192.168.0.12
В этом случае конечной точкой Kubernetes будет:
https://kube.cluster1.mydomain.com:6443

Примечание

Аналогичную задачу можно решить с помощью виртуального IP-адреса (VIP) (см. раздел Работа с Virtual (Shared) IP), однако такой вариант чаще применяется в test- и dev-кластерах.

Глава 25. Работа с Virtual (Shared) IP

Для упрощения создания кластера поддерживается «виртуальный» IP-адрес (VIP) для доступа к Kubernetes API, обеспечивающий высокую доступность без необходимости использования дополнительных ресурсов. В этом случае управляющие узлы конкурируют за владение общим IP-адресом с помощью механизма выборов в etcd. В каждый момент времени виртуальным IP-адресом может владеть только один управляющий узел. Если текущий владелец становится недоступен, выбирается новый владелец, который принимает IP-адрес на себя.

25.1. Требования

Узлы Control Plane должны находиться в одной общей подсети уровня L2. Виртуальный IP-адрес должен быть зарезервированным и неиспользуемым IP-адресом в той же подсети, что и управляющие узлы. VIP не должен назначаться DHCP-сервером. На практике это означает, что все управляющие узлы должны быть подключены через коммутатор, без промежуточных маршрутизаторов.
Следует обратить внимание, что для назначения и управления виртуальным IP-адресом используется etcd, который должен находиться в работоспособном состоянии. Виртуальный IP-адрес не ограничен только Kubernetes API — через него можно получить доступ к любым портам, доступным на управляющих узлах.
Таким образом, VIP можно использовать в качестве конечной точки Kubernetes API, однако не рекомендуется использовать его в качестве конечной точки API кластера ALT Orchestra (endpoint), поскольку при недоступности etcd доступ к VIP также будет потерян, что затруднит восстановление etcd через API.

25.2. Добавление VIP

Патч для создания VIP:
[
  {
    "op": "add",
    "path": "/machine/network/interfaces",
    "value": [
      {
        "deviceSelector": {
          "physical": true
        },
        "dhcp": true,
        "vip": {
          "ip": "192.168.0.100"
        }
      }
    ]
  }
]
Выполнить патч для всех узлов Control Plane:
$ talosctl -n 192.168.0.140 patch machineconfig \
-p '[{"op":"add","path":"/machine/network/interfaces","value":[{"deviceSelector":{"physical":true},"dhcp":true,"vip":{"ip":"192.168.0.100"}}]}]'

$ talosctl -n 192.168.0.141 patch machineconfig \
-p '[{"op":"add","path":"/machine/network/interfaces","value":[{"deviceSelector":{"physical":true},"dhcp":true,"vip":{"ip":"192.168.0.100"}}]}]'

$ talosctl -n 192.168.0.142 patch machineconfig \
-p '[{"op":"add","path":"/machine/network/interfaces","value":[{"deviceSelector":{"physical":true},"dhcp":true,"vip":{"ip":"192.168.0.100"}}]}]'
Примерный вывод:
patched MachineConfigs.config.talos.dev/v1alpha1 at the node 192.168.0.140
Applied configuration without a reboot
Убедиться, что виртуальный IP-адрес назначен:
$ talosctl get addresses 2>/dev/null | grep 192.168.0.100
Примерный вывод:
192.168.0.140   network     AddressStatus   ens19/192.168.0.100/32                     1         192.168.0.100/32               ens19

25.3. Проверка работы VIP

Скопировать конфигурацию k8s:
$ cp ~/.kube/config ~/vipk8sconfig
Заменить IP-адрес на виртуальный:
$ sed -i 's|192.168.1.2|192.168.1.100|g' ~/vipk8sconfig
Создать скрипт для отслеживания виртуального IP-адреса:
$ echo 'talosctl get addresses -e <Адреса Control Plane, кроме узла с VIP> | \
  grep 192.168.0.100' > get.sh
Запустить отслеживание в разных терминалах:
$ watch -n 5 ./get.sh

$ watch KUBECONFIG=~/vipk8sconfig kubectl get nodes -o wide
Остановить узел, владеющий VIP-адресом.
Проверить, что виртуальный IP-адрес сменился на другой узел (например, с 192.168.0.140 на 192.168.0.141).
При использовании kubectl через виртуальный IP-адрес наблюдается следующее:
  1. После отключения узла доступ к API на некоторое время пропадает:
    Unable to connect to the server: dial tcp 192.168.1.100:6443: i/o timeout
    
  2. Спустя некоторое время доступ восстанавливается.
  3. Отключённый узел отображается в статусе NotReady.
После включения отключённого узла необходимо убедиться, что его статус в Kubernetes изменился на Ready.

25.4. Удаление VIP

Патч для удаления VIP:
[
  {
    "op": "remove",
    "path": "/machine/network/interfaces"
  }
]
Выполнить патч для всех узлов Control Plane:
$ talosctl -n 192.168.0.140 patch machineconfig \
-p '[{"op":"remove","path":"/machine/network/interfaces"}]'

$ talosctl -n 192.168.0.141 patch machineconfig \
-p '[{"op":"remove","path":"/machine/network/interfaces"}]'

$ talosctl -n 192.168.0.142 patch machineconfig \
-p '[{"op":"remove","path":"/machine/network/interfaces"}]'
Убедиться, что виртуальный IP-адрес отсутствует:
$ talosctl get addresses 2>/dev/null | grep 192.168.0.100
Убедиться, что все узлы доступны:
$ talosctl -n 192.168.0.140 health

$ talosctl -n 192.168.0.141 health

$ talosctl -n 192.168.0.142 health

$ kubectl get nodes

25.5. Предостережения

Так как VIP зависит от etcd, его функциональность будет недоступна до запуска Kubernetes. Не рекомендуется использовать VIP в качестве конечной точки API в talosconfig, поскольку для управления VIP требуются работающие etcd и kube-apiserver. В случае сбоя одного из этих компонентов восстановление через API может оказаться невозможным.

25.6. Отказоустойчивость VIP-адреса

Когда управляющий узел, владеющий VIP-адресом, корректно завершает работу, IP-адрес переназначается практически мгновенно, обеспечивая непрерывный доступ.
Если же узел неожиданно выходит из строя (например, из-за отключения питания или аппаратного сбоя), переключение на резервный узел занимает больше времени — обычно до одной минуты. Такое поведение является штатным, поскольку ALT Orchestraкоординирует владение VIP-адресом через механизм выборов etcd, который обеспечивает баланс между скоростью переключения и безопасностью.
Задержка необходима для предотвращения ситуации split-brain, при которой несколько узлов одновременно считают себя владельцами одного и того же VIP-адреса. Ожидание завершения таймаута выборов гарантирует, что общий IP-адрес будет объявлен только одним узлом, даже если это приводит к более медленному переключению при внезапных отказах.

25.7. Влияние на рабочую нагрузку

Переключение VIP-адреса на резервный узел влияет только на внешний доступ к кластеру, например, при выполнении команд kubectl к к Kubernetes API.
Внутри кластера рабочие нагрузки продолжают функционировать штатно. Однако для внешних клиентов переключение VIP-адреса может кратковременно прервать соединение. Длительные соединения, например HTTP/2-сессии, могут быть разорваны при переносе виртуального IP-адреса на другой узел, поэтому клиенты должны поддерживать автоматическое повторное подключение после завершения переключения.

Часть VIII. Шифрование секретов Kubernetes

По умолчанию Kubernetes хранит объекты Secret в etcd в виде данных, закодированных в Base64. Это не является шифрованием: любой, кто имеет доступ к каталогу данных etcd или возможность чтения данных через API etcd, может получить секреты в открытом виде. Включение шифрования данных «на диске» (encryption at rest) обеспечивает шифрование секретов перед их записью в etcd и повышает уровень защиты конфиденциальной информации.
ALT Orchestra позволяет декларативно настраивать шифрование секретов через конфигурацию Talos.

Глава 26. Механизм Encryption at Rest

Kubernetes поддерживает шифрование ресурсов, хранящихся в etcd, с помощью механизма EncryptionConfiguration. В конфигурации указывается:
  • какие ресурсы должны шифроваться;
  • какие провайдеры шифрования необходимо использовать.
Поддерживаются следующие провайдеры:
  • aescbc — шифрование AES-CBC с дополнением PKCS#7. Надёжный вариант для большинства сценариев;
  • aesgcm — шифрование AES-GCM. Работает быстрее, чем aescbc, но требует аккуратной ротации ключей;
  • secretbox — использует алгоритмы XSalsa20 и Poly1305. Современный и производительный вариант;
  • identity — отключает шифрование.
Если указано несколько провайдеров, первый используется для шифрования, а все перечисленные — для расшифровки. Такой механизм применяется при ротации ключей: новый ключ добавляется первым, затем выполняется перешифрование данных, после чего старый ключ удаляется.

Глава 27. Настройка шифрования в ALT Orchestra

ALT Orchestra предоставляет встроенную поддержку шифрования секретов Kubernetes через параметры верхнего уровня:
  • cluster.aescbcEncryptionSecret;
  • cluster.secretboxEncryptionSecret.
Оба параметра принимают один 32-байтовый ключ, закодированный в Base64. ALT Orchestra автоматически формирует EncryptionConfiguration и подключает его к kube-apiserver.

Примечание

Параметры cluster.aescbcEncryptionSecret и cluster.secretboxEncryptionSecret:
  • поддерживают только один ключ;
  • шифруют только ресурс Secret.

Глава 28. Проверка шифрования секретов

В ALT Orchestra шифрование секретов Kubernetes включено по умолчанию и использует провайдер secretbox.
Убедитесь, что ключ шифрования присутствует в конфигурации:
$ talosctl -n 192.168.0.140 get machineconfig v1alpha1 -o yaml | \
  yq -r .spec | yq .cluster | grep secretboxEncryptionSecret
Ожидаемый вывод:
grep encryption-provider
                - --encryption-provider-config=/system/secrets/kubernetes/kube-apiserver/encryptionconfig.yaml
Проверьте содержимое EncryptionConfiguration:
$ talosctl -n 192.168.0.140 read \
  /system/secrets/kubernetes/kube-apiserver/encryptionconfig.yaml
Ожидаемый вывод:
apiVersion: v1
kind: EncryptionConfig
resources:
- providers:
  - secretbox:
      keys:
      - name: key2
        secret: ghq0LEtxJEa6AnyYYwNEypSNYHWLYPVrZA8JvH6zlKk=
  - identity: {}
  resources:
  - secrets
Создайте тестовый секрет:
$ kubectl create secret generic my-secret \
  --from-literal=key1=supersecret \
  --from-literal=key2=topsecret
Получите сертификаты etcd:
$ talosctl -n 192.168.0.140 read /system/secrets/etcd/ca.crt > ca.crt

$ talosctl -n 192.168.0.140 read /system/secrets/etcd/server.crt > server.crt

$ talosctl -n 192.168.0.140 read /system/secrets/etcd/server.key > server.key

Примечание

Для выполнения следующей команды должен быть установлен пакет etcd:
# apt-get install etcd
Прочитайте секрет напрямую из etcd:
$ ETCDCTL_API=3 etcdctl \
  --endpoints=https://192.168.0.140:2379 \
  --cacert=./ca.crt \
  --cert=./server.crt \
  --key=./server.key \
  get /registry/secrets/default/my-secret
При включённом шифровании вывод будет содержать префикс:
k8s:enc:secretbox:v1:
Если шифрование отключено, содержимое секрета будет отображаться в открытом виде.

Глава 29. Внешние хранилища секретов

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

Часть IX. Архитектура ALT Orchestra

ALT Orchestra разработана с учётом атомарности развертывания и модульности архитектуры.
Атомарность заключается в том, что ALT Orchestra распространяется как единый самодостаточный образ, имеющий версионирование, цифровую подпись и являющийся неизменяемым.
Модульность заключается в том, что система состоит из множества отдельных компонентов, имеющих чётко определённые gRPC-интерфейсы, обеспечивающие внутреннюю гибкость и внешние гарантии совместимости.
Все основные компоненты ALT Orchestra взаимодействуют друг с другом через gRPC посредством локального Unix-сокета. Это обеспечивает чёткое разделение ответственности и гарантирует, что изменения, влияющие на взаимодействие компонентов, фиксируются и отражаются в репозитории Git.
Преимущество такого подхода заключается в том, что каждый компонент может развиваться и изменяться независимо, при условии сохранения стабильности внешнего API. Это ключевой принцип, обеспечивающий снижение связности и поддержку модульности системы.

Глава 30. Разделы файловой системы

ALT Orchestra использует следующие разделы:
  • EFI — содержит данные загрузки UEFI;
  • BIOS — используется для второй стадии загрузки (GRUB или совместимый загрузчик);
  • BOOT — содержит загрузчик, initramfs и образы ядра;
  • META — хранит метаданные узла (идентификаторы, параметры регистрации);
  • STATE — хранит конфигурацию машины, идентификационные данные узла для кластера и информацию KubeSpan;
  • EPHEMERAL — хранит временные данные и монтируется в /var.

Глава 31. Файловая система ALT Orchestra

Корневая файловая система ALT Orchestra состоит из трёх слоев:
  • rootfs — базовый слой, представляющий собой squashfs, работающий в режиме только для чтения. Он монтируется как loop-устройство в оперативную память, что исключает возможность его изменения;
  • tmpfs — слой временных файловых систем для стандартных псевдофайловых систем, таких как /dev, /proc, /run, /sys и /tmp;
  • /system — слой для поддержки изменяемых файлов, таких как /etc/hosts и /etc/resolv.conf. Он монтируется поверх стандартных путей и обеспечивает возможность записи только для ограниченного набора файлов. Например, при загрузке ALT Orchestra формирует /system/etc/hosts, а затем монтирует его поверх /etc/hosts. Это означает, что вместо предоставления записи во весь каталог /etc, доступными для записи становятся только отдельные файлы.
Слои корневой файловой системы
Содержимое каталога /system полностью пересоздаётся при каждой загрузке. Для данных, которые должны сохраняться между загрузками (например, /etc/kubernetes), ALT Orchestra использует файловые системы overlayfs. Такие каталоги размещаются в /var/ на разделе EPHEMERAL с файловой системой XFS.
Владельцем большинства файлов каталога /var/ является пользователь kubernetes, за исключением каталогов, использующих overlayfs. Этот каталог доступен для записи и используется такими сервисами, как etcd, kubelet и CRI. Его содержимое сохраняется между перезагрузками и обновлениями.
Каталог /system на управляющих узлах содержит следующие подкаталоги:
drwxr-xr-x   0     0     60        Jan 26 15:06:30           config/kubernetes/...
drwx------   0     0     160       Jan 26 15:06:30           etc/...
drwx--x--x   0     0     80        Jan 26 15:06:30           libexec/apid/...
drwxr-xr-x   0     0     80        Jan 26 15:06:23           overlays/...
drwxr-xr-x   0     0     60        Jan 26 15:06:23           resolved/resolv.conf
drwxr-x--x   0     0     140       Jan 26 15:06:30           run/...
drwx------   0     0     80        Jan 26 15:06:30           secrets/...
drwxr-xr-x   0     0     80        Jan 26 15:06:17           state/...
drwx------   0     0     60        Jan 26 15:06:24           var/lib/containerd/...
На рабочих узлах отсутствуют подкаталоги config/ и secrets/.
Каталог /system/state монтируется на раздел STATE и содержит следующие файлы:
config.yaml
node-identity.yaml
platform-network.yaml
Назначение файлов:
  • config.yaml — содержит конфигурацию узла (<type>.yaml), полученную сервисом apid при выполнении команды talosctl apply-config;
  • node-identity.yaml — содержит уникальный идентификатор узла:
    nodeId: xxx…
  • platform-network.yaml — содержит сведения о платформе и сетевых параметрах узла, например:
    addresses: []
    links: []
    routes: []
    hostnames: []
    resolvers: []
    timeServers: []
    operators: []
    externalIPs: []
    metadata:
        platform: metal
        instanceId: <UUID>
    
Каталог /system/var, смонтированный на раздел EPHEMERAL, содержит слои загруженных образов и выполняемых контейнеров.

Глава 32. Компоненты ALT Orchestra

ALT Orchestra и Kubernetes тесно интегрированы друг с другом.

Таблица 32.1. Компоненты, специфичные для ALT Orchestra

Компонент
Описание
apid
При взаимодействии с ALT Orchestra пользователь напрямую работает с gRPC API, предоставляемым компонентом apid. Он выступает шлюзом для взаимодействия со всеми компонентами системы и перенаправляет запросы в machined
containerd
Стандартная в отрасли среда выполнения контейнеров, ориентированная на простоту, надёжность и переносимость
machined
Замена традиционного процесса init в Linux, разработанная специально для запуска Kubernetes и не позволяющая запускать произвольные пользовательские сервисы
kernel
Ядро Linux, поставляемое с ALT Orchestra, настроенное в соответствии с рекомендациями проекта Kernel Self Protection Project (KSPP)
trustd
Для запуска и эксплуатации кластера Kubernetes требуется определённый уровень доверия между узлами. Основанный на концепции «корня доверия» (Root of Trust), trustd отвечает за установление доверия внутри системы
udevd
Управляет файлами устройств в /dev и обрабатывает действия в пользовательском пространстве при подключении и отключении устройств

32.1. apid

При взаимодействии с ALT Orchestra пользователь напрямую обращается к gRPC API, предоставляемому компонентом apid.
apid выступает шлюзом для взаимодействия между всеми компонентами системы. На управляющих узлах он также обеспечивает маршрутизацию запросов к нужному узлу.
При взаимодействии с компонентами ALT Orchestra через talosctl поведение apid определяется двумя параметрами:
  • -e или --endpoints — указывает узел ALT Orchestra (точнее, его apid), который будет обрабатывать соединение. Обычно это публично доступный сервер;
  • -n или --nodes — указывает узел(ы) ALT Orchestra, которые должны ответить на запрос.
Если параметр --nodes не указан, используется первый endpoint.

Примечание

Обычно endpoint уже определён в файле конфигурации ALT Orchestra. При необходимости там же можно определить и nodes.
Например, для получения информации о памяти через API machined, можно выполнить команду:
$ talosctl -e 192.168.0.202 memory
NODE                 TOTAL   USED   FREE   SHARED   BUFFERS   CACHE   AVAILABLE
192.168.0.202        7938    1768   2390   145      53        3724    6571
В этом случае talosctl подключается apid на узле 192.168.0.202, который затем перенаправляет запрос в API machined.
Если нужно получить информацию о памяти другого узла кластера:
$ talosctl -e 192.168.0.202 -n node02 memory
NODE    TOTAL   USED   FREE   SHARED   BUFFERS   CACHE   AVAILABLE
node02  7938    1768   2390   145      53        3724    6571
В этом случае apid на узле 192.168.0.202 получает запрос и пересылает его экземпляру apid на узле node02, который уже обращается к локальному API machined.
Можно запросить данные сразу у нескольких узлов, добавив несколько параметров -n или перечислив узлы через запятую:
$ talosctl -e 192.168.0.202 -n node01 -n node02 -n node03 memory
NODE     TOTAL    USED    FREE     SHARED   BUFFERS   CACHE   AVAILABLE
node01   7938     871     4071     137      49        2945    7042
node02   257844   14408   190796   18138    49        52589   227492
node03   257844   1830    255186   125      49        777     254556
В этом случае apid на 192.168.0.202 пересылает запросы узлам node01, node02 и node03, а их локальные экземпляры apid обращаются к своим экземплярам machined.

32.2. containerd

Containerd обеспечивает среду выполнения контейнеров для запуска рабочих нагрузок в ALT Orchestra и Kubernetes.
Сервисы ALT Orchestra размещаются в пространстве имён system, тогда как сервисы Kubernetes работают в пространстве имён k8s.io.

32.3. machined

В ALT Orchestra процесса init выполняет компонент machined.
Цель — создать специализированный init, выполняющий одну задачу — запуск Kubernetes. Поэтому machined является достаточно статичным компонентом и не позволяет запускать произвольные пользовательские сервисы.
Доступны только сервисы, необходимые для работы Kubernetes и управления узлом:
  • containerd
  • etcd
  • kubelet
  • networkd
  • trustd
  • udevd
Процесс machined отвечает за:
  • применение конфигурации машины;
  • обработку API-запросов;
  • управление ресурсами;
  • управление контроллерами системы.

32.4. kernel

Ядро Linux, входящее в состав ALT Orchestra, настроено в соответствии с рекомендациями проекта Kernel Self Protection Project (KSPP).
Цель KSPP — повышение защищённости ядра Linux путём включения дополнительных механизмов безопасности и усиления существующих защит.

32.5. trustd

Для работы кластера Kubernetes требуется определённый уровень доверия между узлами. Например, при начальной настройке высокодоступного control plane необходимо безопасно распространять чувствительные данные инфраструктуры открытых ключей (PKI).
Эту задачу выполняет компонент trustd.
Основанный на концепции Root of Trust («корень доверия»), trustd представляет собой демон, отвечающий за установление доверительных отношений внутри системы.
После установления доверия узел может выполнять доверенные операции, например принимать от другого узла запрос на запись файла на локальный диск.

32.6. udevd

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

Глава 33. Службы обнаружения узлов

ALT Orchestra включает встроенные механизмы обнаружения узлов, позволяющие видеть всех участников кластера и связанные с ними IP-адреса. Эти механизмы основаны на использовании одного или нескольких реестров обнаружения.
В настоящее время ALT Orchestra поддерживает два типа реестров обнаружения:
  1. Служба реестра (Service Registry):
    • включена по умолчанию;
    • не зависит от работы etcd или Kubernetes;
    • используется во всех типовых сценариях (в том числе когда Kubernetes не работает);
    • доступна публичная реализация от Sidero Labs;
  2. Реестр Kubernetes:
    • использует аннотации объектов узлов Kubernetes;
    • отключен по умолчанию;
    • устарел — несовместим с Kubernetes 1.32+ в стандартной конфигурации.

33.1. Конфигурация реестров обнаружения

Настройки реестров задаются в секции cluster.discovery конфигурации ALT Orchestra:
cluster:
  discovery:
    enabled: true
    registries:
      service:
        disabled: true # Отключает службу реестра
      kubernetes:
        disabled: false # Включает реестр Kubernetes (при необходимости)
Отключение всех реестров приведёт к полной потере возможности обнаружения узлов.

33.1.1. Реестр Kubernetes

Реестр Kubernetes использует аннотации, добавляемые на объекты узлов:
$ kubectl --kubeconfig ./kubeconfig describe node <имя узла>
Annotations:
 extensions.talos.dev/schematic: 376567988ad370138ad8b2698212367b8edcb69b5fd68c80be1f2ec7d603b4ba
 flannel.alpha.coreos.com/backend-data: {"VNI":1,"VtepMAC":"fa:50:25:ae:1f:89"}
 flannel.alpha.coreos.com/backend-type: vxlan
 flannel.alpha.coreos.com/kube-subnet-manager: true
 flannel.alpha.coreos.com/public-ip: 192.168.0.145
 node.alpha.kubernetes.io/ttl: 0
 talos.dev/owned-annotations: ["extensions.talos.dev/schematic"]
 volumes.kubernetes.io/controller-managed-attach-detach: true
Эти данные используются ALT Orchestra для определения уникальности и сетевых характеристик каждого узла.

33.1.2. Реестр служб (Service Registry)

Реестр служб — это механизм обнаружения узлов кластера, работающий через внешнюю распределённую службу, доступную по адресу:
https://discovery.altlinux.space/
Каждый узел передаёт зашифрованную информацию о себе и других узлах в эту службу, а затем получает агрегированные данные о кластере.
Каждый узел кластера:
  • отправляет зашифрованные данные о себе и известных ему конечных точках (IP:порт) в сервис;
  • получает агрегированную и дедуплицированную информацию обо всех узлах от сервиса;
  • использует полученные данные для:
    • обнаружения других участников кластера;
    • поддержки и настройки KubeSpan (шифрованной сетевой связности на основе WireGuard).
Безопасность:
  • все данные, передаваемые в сервис, шифруются:
    • AES-GCM — для общей информации;
    • AES-ECB — для дедупликации IP-адресов и конечных точек;
  • данные шифруются и расшифровываются непосредственно на узлах;
  • служба не имеет доступа к ключам шифрования;
  • информация о кластере (например, IP-адреса, hostname и т.п.) недоступна для сервиса;
  • KubeSpan использует обмен открытыми ключами WireGuard.
Данные хранятся только в оперативной памяти (или временно — в зашифрованном виде на диске для восстановления после перезапуска).
Уникальный идентификатор кластера используется как ключ сегментации (чтобы разные кластеры не пересекались).
ALT Orchestra может работать без службы, однако в этом случае:
  • некоторые функции (например, автоконфигурация или KubeSpan) будут ограничены;
  • устранение неполадок и восстановление кластера после сбоев значительно усложняются.

33.2. Определения ресурсов

ALT Orchestra предоставляет ресурсы, которые можно использовать для интроспекции механизмов обнаружения и работы KubeSpan.

33.2.1. Идентификаторы

Уникальный идентификатор узла можно получить с помощью команды:
$ talosctl get identities -o yaml
Пример вывода:
node: 192.168.0.140
metadata:
    namespace: cluster
    type: Identities.cluster.talos.dev
    id: local
    version: 1
    owner: cluster.NodeIdentityController
    phase: running
    created: 2026-05-20T09:02:08Z
    updated: 2026-05-20T09:02:08Z
spec:
    nodeId: yMCuCL2m2rLfDm6TdKCzjYxEd7rYbjRa3gbwx6LYsRT
nodeId — уникальный идентификатор узла (32 байта, кодированные в base62).
Ресурс идентификации узла сохраняется в разделе STATE (файл node-identity.yaml). Идентификатор сохраняется при перезагрузках и обновлениях, и сбрасывается только при выполнении команды talosctl reset.

33.2.2. Филиалы (Affiliates)

Филиал (affiliate) — это потенциальный участник кластера, то есть узел, который:
  • имеет тот же идентификатор кластера (Cluster ID);
  • использует тот же секрет обнаружения;
  • был обнаружен через один из реестров, но еще не одобрен как участник кластера.
Получение списка филиалов:
$ talosctl get affiliates
Филиалы
Каждый узел отображает известные ему филиалы, полученные через механизмы обнаружения.
Подробную информацию о данных, поступающих из каждого реестра, можно получить из пространства имен cluster-raw:
$ talosctl get affiliates --namespace=cluster-raw
Пространство имен cluster-raw
Каждый идентификатор имеет соответствующий префикс:
  • service/… — данные из службы обнаружения (https://discovery.altlinux.space);
  • k8s/… — данные из реестра Kubernetes (если он включён).

33.2.3. Участник (Member)

Участник (member) — это филиал, который успешно присоединился к кластеру (автоматически или вручную). Участник является полноценным элементом кластера и может участвовать в работе etcd (для Control Plane) и Kubernetes.
Список участников кластера можно получить с помощью команды:
$ talosctl get members
Участники кластера

Примечание

Каждый участник является филиалом, но не каждый филиал является участником.

Часть X. Жизненный цикл кластера

Глава 34. Загрузка начальной системы

На первом этапе происходит загрузка начальной системы (Linux-ядра) с ISO-, QCOW2-образа или через iPXE:
Загрузка начальной системы

Глава 35. Инициализация системы

После загрузки машины с ISO-образа в консоли автоматически запускается текстовый интерфейс dashboard.
Интерактивная панель мониторинга. Сводная информация
Помимо запуска dashboard, выполняются следующие действия:
  • запускается сервис apid, прослушивающий порт 50000. Он обеспечивает взаимодействие с командой talosctl, выполняемой на рабочем компьютере администратора;
  • разворачивается минимальная runtime-среда для запуска контейнеров;
  • инициализируются базовые системные компоненты управления узлом.
Состояние системы после загрузки

Примечание

Система, загруженная с ISO-образа, работает в оперативной памяти. Диски, предназначенные для установки ALT Orchestra и развёртывания кластера, на данном этапе не инициализированы.
После завершения инициализации узел становится доступен через API и ожидает дальнейших действий по развертыванию кластера.

Глава 36. Генерация конфигурационных файлов

Далее на компьютере администратора, выполняющего развёртывание кластера, запускается команда генерации конфигурационных файлов:
$ talosctl gen config <clusterName> https://<endpoint>:6443
Команда сгенерирует три конфигурационных файла:
  • controlplane.yaml — конфигурация управляющего узла (Control Plane);
  • worker.yaml — конфигурация рабочих узлов (Worker Node);
  • talosconfig — настройки подключения к API.
Генерация конфигурационных файлов
В файл talosconfig записываются параметры доступа к кластеру (включая сертификаты).
В файл controlplane.yaml — данные для развёртывания управляющих узлов.
В файл worker.yaml — данные для развёртывания рабочих узлов.
В двух последних файлах по умолчанию:
  • указываются образы ALT Orchestra для установки системы;
  • в качестве устройства установки задаётся диск /dev/sda.

Глава 37. Развёртывание узлов

После формирования конфигурационных файлов для каждого управляющего узла выполняется команда:
$ talosctl apply-config --insecure --nodes $CONTROL_PLANE_IP \
  --talosconfig=./talosconfig  --file ./controlplane.yaml
Для рабочих узлов используется команда:
$ talosctl apply-config --insecure --nodes $WORKER_IP \
  --talosconfig=./talosconfig  --file ./worker.yaml
Команда talosctl apply-config устанавливают соединение с сервисом apid по порту 50000 и передаёт ему конфигурационный YAML-файл узла.
Команды разворачивания узлов
Файл talosconfig при этом не передаётся в apid — он используется только утилитой talosctl для аутентификации и установления соединения с узлом ALT Orchestra.
Сервис apid:
  • принимает запрос на применение конфигурации;
  • передаёт полученный запрос в сервис machined, который выполняет дальнейшие действия по установке.

Глава 38. Развёртывание узла с использованием образа installer

После получения запроса сервис apid передаёт его в сервис machined. Сервис machined, в свою очередь, загружает образ installer, указанный в поле .machine.install.image конфигурационного файла и выполняет установку системы.
Загрузка образа
Образ installer выполняет разбиение диска на разделы.
Установка системы

Таблица 38.1. Разделы диска

Номер
Начало
Размер
Файловая система
Имя
Флаги
1
1049kB
105MB
fat32
EFI
загрузочный, esp
2
106MB
1049kB
BIOS
bios_grub, legacy_boot
3
107MB
1049MB
xfs
BOOT
4
1156MB
1049kB
META
5
1157MB
105MB
xfs
STATE
6
1261MB
xxxGB
xfs
EPHEMERAL
Раздел EPHEMERAL занимает всё оставшееся пространство на диске.
Разделы EFI, BIOS, BOOT и EPHEMERAL инициализируются данными, включёнными в образ. После этого настраивается загрузка ядра операционной системы.
Конфигурационный YAML-файл сохраняется в разделе STATE под именем config.yaml.
Раздел EPHEMERAL монтируется в каталог /var, куда загружаются образы, указанные в конфигурации. Из образов (например, kubelet и etcd) извлекаются бинарные файлы и конфигурации, необходимые для запуска компонентов как системных сервисов.
Также выполняется генерация и настройка Kubernetes-манифестов.
После завершения установки узел перезагружается.

Глава 39. Ожидание развертывания кластера, генерация файла конфигурации kubeconfig

При перезагрузке система загружается с инициализированного диска, после чего на узлах запускаются соответствующие компоненты.
Запуск компонентов
На управляющих узлах автоматически запускаются:
  • kubelet;
  • etcd;
  • kube-apiserver;
  • kube-controller-manager;
  • kube-scheduler;
  • kube-proxy;
  • kube-flannel (используется как CNI по умолчанию).
На endpoint-узле (если используется выделенный управляющий узел для endpoint) запускаются поды CoreDNS.
На рабочих узлах запускаются:
  • kubelet;
  • kube-proxy;
  • kube-flannel (CNI по умолчанию).
Все перечисленныее компоненты запускаются в контейнерах в рамках системы ALT Orchestra.
Инициализация кластера etcd выполняется на одном из управляющих узлов командой:
$ talosctl -e <endpoint> -n <endpoint> --talosconfig=./talosconfig bootstrap
После запуска etcd внутри Kubernetes-кластера формируется файл kubeconfig, содержащий параметры подключение к кластеру. Он создаётся командой:
$ talosctl --talosconfig $TALOSCONFIG kubeconfig .
Полученный файл используется Kubernetes-клиентами (например, kubectl) для доступа к кластеру.
На этом этапе развертывание кластера считается завершённым.
Формирование описания кластера

Глава 40. Ожидание подъема Kubernetes-кластера

После запуска etcd и формирования файла kubeconfig можно наблюдать за процессом инициализации кластера с помощью команды:
$ kubectl --kubeconfig kubeconfig get all -A
Данная команда позволяет отслеживать состояние всех ресурсов Kubernetes во всех пространствах имён (namespace).

Примечание

Для возможности выполнения команды kubectl должен быть установлен пакет kubernetes<Версия>-client, например kubernetes1.35-client.
В списке подов в состоянии 1/1 должны присутствовать:
  • два пода с именем coredns;
  • по одному поду на каждый Control plane-узел:
    • kube-apiserver
    • kube-controller-manager
    • kube-scheduler
  • по одному поду на каждый узел:
    • kube-flannel
    • kube-proxy
Список узлов можно получить командой:
$ kubectl get nodes --kubeconfig kubeconfig
Пример вывода:
NAME                    STATUS   ROLES           AGE     VERSION
alt-orchestra-b76-zal   Ready    <none>          3m52s   v1.35.0
alt-orchestra-gtm-tnz   Ready    control-plane   4m6s    v1.35.0
Список подов можно получить командой:
$ kubectl --kubeconfig kubeconfig get pods --namespace kube-system
Пример вывода:
NAME                                      READY   STATUS    RESTARTS        AGE
coredns-5966c6bdcd-dv275                  1/1     Running   0               17h
coredns-5966c6bdcd-rzldw                  1/1     Running   0               17h
kube-apiserver-controlplane-01            1/1     Running   0               8m48s
kube-controller-manager-controlplane-01   1/1     Running   2 (9m10s ago)   8m46s
kube-flannel-9zqwx                        1/1     Running   2 (17h ago)     2d
kube-flannel-hpvbq                        1/1     Running   2 (21h ago)     23h
kube-flannel-rkszh                        1/1     Running   2 (17h ago)     2d15h
kube-flannel-rqsn8                        1/1     Running   1 (17h ago)     41h
kube-proxy-gxfvm                          1/1     Running   0               7m56s
kube-proxy-m2bjx                          1/1     Running   0               17h
kube-proxy-sdz7k                          0/1     Pending   0               17h
kube-proxy-sz9tf                          1/1     Running   0               17h
kube-scheduler-controlplane-01            1/1     Running   3 (8m58s ago)   8m48s

Часть XI. Техническая поддержка продуктов «Базальт СПО»

Глава 41. Покупателям нашей продукции

«Базальт СПО» предоставляет следующие виды технической поддержки:
  • Поддержка продукта входит в стоимость лицензии и включает регулярный выпуск обновлений, исправление ошибок, устранение уязвимостей в течение всего срока жизни дистрибутива.
  • Поддержка пользователей обеспечивает качественную эксплуатацию продукта. Техническая поддержка эксплуатации продуктов «Базальт СПО» оказывается в объеме SLA. Доступны три уровня SLA («Базовый», «Стандартный» и «Расширенный»).
Право на получение консультационной и технической поддержки вы приобретаете при покупке большинства продуктов торговой марки Альт. Сроки и объём помощи указаны в сертификате технической поддержки.
Условия технической поддержки можно найти на странице сайта «Базальт СПО»: http://www.basealt.ru/support.

Глава 42. Пользователям нашей продукции

Вне зависимости от того, скачали вы или же приобрели наш дистрибутив, задавать вопросы или обсуждать их с сообществом пользователей дистрибутивов «Альт» вы можете на форуме или в списках рассылки.
Помощь сообщества:
Ресурсы компании «Базальт СПО»:
Форум и списки рассылки читают опытные пользователи, профессиональные системные администраторы и разработчики «Базальт СПО». Сообщество пользователей и специалистов окажет содействие в поиске ответа на ваш вопрос или посоветует выход из сложной ситуации. При обращении к данному виду помощи у вас нет гарантии на полноту и своевременность ответа, но мы стараемся не оставлять без ответа вопросы, задаваемые в списках.