Talos Linux 1.14.0 и 1.13.10 — Kubernetes 1.37, native BGP, защищённый DNS и обновление стабильной ветки

Sidero Labs 3 сентября 2026 года выпустила сразу две версии Talos Linux: крупную 1.14.0 и корректирующую 1.13.10. Talos Linux 1.14.0 переходит на Kubernetes 1.37, добавляет native BGP, DoT/DoH, NTS, декларативные LVM и software RAID, Btrfs и новую multi-document модель конфигурации, тогда как 1.13.10 сохраняет прежнюю ветку и сосредоточена на обновлении компонентов и исправлениях стабильности.

Talos Linux 1.14.0 стал крупным инфраструктурным обновлением

Talos Linux 1.14.0 вышел 3 сентября 2026 года и заметно расширяет возможности самой операционной системы вокруг Kubernetes. Это не просто очередное обновление базовых компонентов: в релизе появились встроенная BGP-маршрутизация, шифрованный DNS, защищённая синхронизация времени, декларативное управление LVM и Linux MD RAID, новые механизмы изоляции workload и крупная переработка конфигурационной модели Talos.

Базовый стек также обновлён практически целиком:

Переход на Kubernetes 1.37 делает ветку 1.14 новой основной линией Talos для кластеров, которым нужны актуальные возможности Kubernetes и дальнейшие обновления платформы.

Native BGP теперь встроен в Talos

Одно из наиболее заметных изменений Talos Linux 1.14.0 — встроенная поддержка BGP через embedded GoBGP. Для типовых сценариев подключения Kubernetes-нод к сетевой fabric-инфраструктуре больше не обязательно устанавливать FRR как system extension.

BGP настраивается через новые документы BGPInstanceConfig. Для каждого экземпляра можно определить локальный ASN, router ID, Linux VRF, интерфейсы для анонса, соседей и параметры маршрутов.

Реализация поддерживает:

• обычные и unnumbered BGP-сессии;
• IPv6 link-local peering;
• передачу IPv4-префиксов через IPv6 next hop по RFC 8950;
• BFD для быстрого обнаружения отказов;
• ECMP и multipath-маршрутизацию;
• passive BGP sessions;
• переопределение ASN для отдельных соседей;
• импорт маршрутов между именованными BGP-инстансами;
• работу внутри Linux VRF;
• просмотр состояния соседей через talosctl get bgppeerstatus.

Для bare-metal Kubernetes, leaf-spine сетей и кластеров без отдельного маршрутизатора на каждой ноде это сокращает число дополнительных компонентов на хосте. Talos получает собственный управляемый API-механизм BGP, встроенный в общую модель конфигурации ОС.

Есть ограничение: BFD в текущей реализации поддерживается только BGP-инстансом в основном routing domain, поскольку встроенный BFD listener GoBGP пока не является VRF-aware.

DNS over TLS и DNS over HTTPS появились на уровне хоста

Talos Linux 1.14.0 получил поддержку DNS over TLS и DNS over HTTPS. Протокол можно выбирать отдельно для каждого DNS-сервера в ResolverConfig.

Это означает, что системные DNS-запросы Talos можно передавать в зашифрованном виде без внешнего локального DNS-прокси. Для инфраструктуры, где требуется контролировать конфиденциальность DNS-трафика или исключить его незашифрованную передачу между узлами и резолверами, изменение имеет практический смысл уже на уровне ОС.

Одновременно конфигурация HostDNS переносится из старого поля .machine.features.hostDNS в ResolverConfig. Старый формат пока сохраняется для обратной совместимости, но новые конфигурации следует строить уже вокруг multi-document схемы.

NTS защищает синхронизацию времени

В 1.14 появилась поддержка Network Time Security — NTS. Технология добавляет криптографическую аутентификацию источников времени и защищает NTP-синхронизацию от подмены.

Для стандартного сервера time.cloudflare.com NTS включается по умолчанию, если пользователь не задаёт собственную конфигурацию времени. Для пользовательских NTP-серверов режим включается через поле useNTS в TimeServerConfig.

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

LVM и software RAID получили декларативное управление

Talos Linux 1.14.0 значительно расширяет работу с локальными дисками. Теперь система умеет декларативно создавать и увеличивать LVM Volume Groups и Logical Volumes.

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

• LVMVolumeGroupConfig;
• LVMLogicalVolumeConfig.

Physical Volume можно выбирать через CEL-селекторы по обнаруженным дискам. Talos создаёт PV, собирает Volume Group и затем создаёт Logical Volume. Для LV поддерживаются типы linear, raid0, raid1 и raid10, а максимальный размер можно задавать абсолютным значением или процентом от VG.

Модель намеренно ориентирована на безопасное расширение: увеличение тома поддерживается, автоматическое уменьшение — нет. Уменьшение существующего LV отклоняется как потенциально опасная операция.

Параллельно появились отдельные status-ресурсы для LVM Physical Volume, Volume Group и Logical Volume, а очистить LVM-метаданные можно через talosctl wipe lv, talosctl wipe vg и talosctl wipe pv.

Linux MD RAID можно использовать даже для загрузочного диска

Talos теперь умеет декларативно создавать Linux MD software RAID через RAIDArrayConfig. Система может собирать и расширять RAID-массивы и публиковать их через стабильные пути /dev/disk/by-id/md-name-<name>.

Более существенное изменение — возможность установить Talos непосредственно на software RAID и загружаться с него. Для boot volume поддерживается RAID1 с metadata format 1.0: суперблок располагается в конце диска, поэтому таблица разделов остаётся доступной прошивке на каждом участнике массива.

Это делает Talos удобнее для bare-metal систем, где отказоустойчивый системный диск раньше приходилось организовывать внешними средствами или аппаратным RAID-контроллером.

Btrfs, XFS scrub и автоматический TRIM расширяют работу с файловыми системами

Talos Linux 1.14.0 добавляет поддержку Btrfs для пользовательских и существующих томов. Для работы требуется system extension btrfs.

Для XFS появились сразу два изменения. Во-первых, Talos умеет запускать фоновый xfs_scrub по расписанию. Во-вторых, изменена геометрия allocation groups при создании XFS на быстрых накопителях: Talos старается сохранять размер AG не меньше 64 GiB, чтобы снизить вероятность ситуаций с ENOSPC в reflink-heavy workload при наличии свободного пространства на файловой системе.

Настройка действует только для файловых систем, созданных Talos 1.14 или новее. Уже существующие XFS-разделы автоматически не переформатируются.

Добавлен и управляемый filesystem trim. Новый FilesystemTrimConfig задаёт периодический аналог fstrim; в конфигурациях, созданных Talos 1.14+, по умолчанию используется недельный интервал. Для кластеров, обновлённых с более старой версии, trim автоматически не включается, поскольку соответствующего документа в существующей конфигурации нет.

Для зашифрованных томов discard должен быть отдельно разрешён через allowDiscards.

Workload isolation отделяет Kubernetes от системного пространства Talos

В Talos Linux 1.14 появилась новая модель изоляции workload. CRI containerd, kubelet и Kubernetes pods могут работать в отдельном PID и mount namespace, закреплённом за новым сервисом sandboxd.

sandboxd запускается в собственном SELinux domain sandboxd_t. Если сервис завершается, kernel уничтожает соответствующее namespace, после чего Talos пересоздаёт его вместе с CRI, kubelet и pod workload без полного reboot ноды.

Для новых кластеров talosctl gen config генерирует SecurityProfileConfig с workloadIsolation: true, поэтому новая схема включена по умолчанию. При обычном обновлении существующего кластера с более старой версии поведение не меняется: изоляция останется выключенной, пока администратор явно не добавит соответствующий документ.

Есть важное ограничение для старых storage-конфигураций. Deprecated in-tree Kubernetes iSCSI plugin не может работать с включённым workload isolation, поскольку kubelet больше не видит host iscsid через границу PID namespace. Для iSCSI потребуется CSI-драйвер.

TLS 1.3 становится минимальной версией для etcd и kube-apiserver

Talos 1.14 переводит etcd и kube-apiserver на TLS 1.3 как минимально допустимую версию. Настройки cipher suites для этих компонентов удалены, поскольку в TLS 1.3 выбор наборов шифров работает иначе и прежние параметры больше не применялись.

Параллельно Secure Boot images больше не включают lockdown=confidentiality по умолчанию. Вместо него используется стандартный lockdown=integrity, что улучшает совместимость с eBPF-инструментами. Администраторы, которым нужен более строгий режим confidentiality, могут вернуть его через kernel command line в Image Factory.

Talos также отключает net.ipv4.conf.all.send_redirects и net.ipv4.conf.default.send_redirects по умолчанию, приводя сетевое поведение ближе к рекомендациям CIS Benchmark.

etcd меняет порт для metrics и HTTP health

Одно из изменений, которое необходимо проверить перед обновлением production-кластера, касается etcd. В Talos 1.14 HTTP-only endpoints — /metrics, /health и JSON API через gRPC gateway — переводятся на отдельный listener на порту 2383.

Клиентский порт 2379 теперь обслуживает gRPC. Поэтому системы мониторинга, которые собирают etcd metrics через 2379, нужно перенастроить на 2383.

Talos health check и обычные gRPC-клиенты etcd это изменение не затрагивает. Если инфраструктурные firewall-правила ранее специально ограничивали 2379, необходимо проверить и новый 2383. При явно настроенном --listen-metrics-urls поведение может отличаться и автоматически переносить endpoint не требуется.

Multi-document config становится основной моделью Talos

Версия 1.14 продолжает переход от большого монолитного v1alpha1 machine config к набору специализированных документов. Старые поля в большинстве случаев ещё поддерживаются, но получают статус deprecated.

Новые документы охватывают несколько ключевых областей:

• KubeAPIServerConfig, KubeControllerManagerConfig, KubeSchedulerConfig, KubeProxyConfig и другие документы для Kubernetes;
• KubeNodeConfig для kubelet, labels, annotations и taints;
• KubeNetworkConfig и KubeFlannelCNIConfig для сетевой конфигурации Kubernetes;
• SysctlConfig, SysfsConfig и KernelModuleConfig для параметров ядра;
• UdevRulesConfig для udev rules;
• ResolverConfig для DNS и HostDNS;
• ImageCacheConfig для image cache;
• CRIBaseRuntimeSpecConfig и CRICustomizationConfig для CRI/containerd;
• EtcFileConfig для пользовательских файлов внутри /etc;
• UnattendedInstall для установки системы.

UnattendedInstall заменяет секцию .machine.install. Новые конфигурации, создаваемые через talosctl gen config и talosctl cluster create, уже используют новый документ автоматически, хотя старый формат пока остаётся совместимым.

Для командной строки тоже есть изменение: talosctl apply-config --mode=reboot удалён. По умолчанию изменения применяются без перезагрузки, поскольку большинство новых controllers умеют перестраивать конфигурацию динамически. Для параметров, которым reboot действительно необходим, требуется ориентироваться на документацию конкретного config kind.

CRI можно менять без перезагрузки ноды

Новые документы CRIBaseRuntimeSpecConfig и CRICustomizationConfig позволяют управлять базовой OCI runtime specification и конфигурацией CRI containerd без старых machine-file patches.

Несколько TOML-фрагментов CRICustomizationConfig объединяются в лексикографическом порядке по имени. При добавлении, изменении или удалении этих документов Talos автоматически перестраивает CRI-конфигурацию и перезапускает CRI — полный reboot ноды больше не требуется.

Также Talos больше не отключает NRI, Node Resource Interface, в CRI containerd по умолчанию. Если NRI не нужен, старое поведение можно вернуть отдельным CRICustomizationConfig.

Системные тома можно вынести на отдельные разделы

ETCD, CRI, KUBELET и LOG теперь можно размещать на отдельных partitions, задавая provisioning через VolumeConfig. При необходимости такие тома могут быть зашифрованы.

По умолчанию они, как и раньше, остаются каталогами внутри EPHEMERAL. Однако для серверов с несколькими накопителями можно отделить etcd, containerd, kubelet и logs от общего системного тома.

Для ETCD и LOG при secure: true дополнительно применяется noexec. Следует учитывать, что тип backing storage фиксируется при создании кластера: переключить уже существующую ноду с directory-backed volume на dedicated partition простой правкой конфигурации нельзя.

Image Factory становится стандартным источником installer image

В Talos Linux 1.14 стандартный installer image окончательно переводится на Image Factory. Образ ghcr.io/siderolabs/installer больше не публикуется как обычный release asset для ветки 1.14.

Для инфраструктуры с собственными автоматизированными pipeline установки и обновления это требует проверки шаблонов image URL. Особенно это касается конфигураций, где installer image был жёстко прописан на старый GitHub Container Registry path.

Что исправлено в Talos Linux 1.13.10

Talos Linux 1.13.10 вышел в тот же день, 3 сентября 2026 года, но решает другую задачу. Это поддерживающий релиз ветки 1.13 для кластеров, которые пока не готовы переходить на 1.14 и новую конфигурационную модель.

Основные обновления компонентов:

Таким образом, ядро Linux и CoreDNS у 1.13.10 совпадают с 1.14.0, но Kubernetes и etcd остаются на предыдущей линии.

Исправления kubelet, API и image verification

В 1.13.10 усилена обработка клиентского сертификата kubelet и добавлена валидация получаемого kubeconfig. Также исправлена нормализация image reference перед передачей в механизм проверки образов.

В Talos API исправлена фильтрация передаваемых metadata, а пустой список требуемых ролей теперь считается ошибкой. Это относится к security-sensitive частям API, хотя разработчики не маркируют 1.13.10 как отдельный CVE-релиз.

Исправления etcd

etcd обновлён до 3.6.14. Помимо самого обновления компонента, Talos теперь атомарно записывает загружаемый etcd snapshot и уменьшает задержки в цикле promotion нового etcd member.

Для control-plane кластеров это снижает риск проблем во время восстановления snapshot и присоединения новых участников etcd.

Сеть и CSI

Обновлена DHCP-библиотека, исправлен постоянный churn при создании маршрутов и добавлено корректное отслеживание изменений IPv6 routes в RouteSpecController.

Для CSI исправлено монтирование volumes с SELinux context. Отдельное исправление пропускает SELinux label для read-only, detached и external mounts, где применение метки было некорректным.

Работа с файлами и system extensions

В 1.13.10 исправлена обработка распаковки файлов через talosctl: используются более безопасные операции через os.Root, сохраняются специальные mode bits и создаются недостающие parent directories при распаковке tar-архивов.

Также исправлено усечение файлов, заменяемых system extensions, и сохранение in-memory metadata при fresh install.

В пакеты ветки 1.13 дополнительно backport-нута поддержка AES256K для Ceph, а kernel последовательно обновлён до Linux 6.18.48.

Talos Linux 1.14.0 и 1.13.10 — какую ветку выбирать

Talos Linux 1.14.0 и 1.13.10 предназначены для разных сценариев. Версия 1.14 становится новой функциональной веткой, а 1.13.10 — безопасной точкой обновления для инфраструктуры, которая должна остаться на 1.13.

При переходе на 1.14 особенно стоит проверить четыре области: scraping etcd metrics на порту 2383, старые ссылки на ghcr.io/siderolabs/installer, использование deprecated in-tree iSCSI plugin и автоматизацию вокруг apply-config --mode=reboot.

Отдельно следует учитывать, что часть новых defaults применяется только к новым конфигурациям. Workload isolation и периодический filesystem trim не включаются автоматически только из-за обновления существующей ноды с 1.13 — для них нужны соответствующие новые config documents.

Что в итоге

Talos Linux 1.14.0 — одно из наиболее содержательных обновлений платформы за последние циклы: оно расширяет Talos за пределы минимальной Kubernetes OS и добавляет встроенные сетевые, storage и security-механизмы, которые раньше часто требовали system extensions или внешней автоматизации. Наиболее практичными изменениями выглядят native BGP, Kubernetes 1.37, DoT/DoH, NTS, декларативные LVM и RAID, workload isolation и переход к специализированным multi-document конфигурациям.

Talos Linux 1.13.10, напротив, не требует архитектурной миграции и подходит как промежуточное обновление для действующих кластеров 1.13. В ней обновлены Linux до 6.18.48, CoreDNS до 1.14.7 и etcd до 3.6.14, а также исправлены kubelet certificates, CSI/SELinux, маршрутизация, etcd snapshot и ряд операций с файлами и system extensions.

Для новых развёртываний логичнее ориентироваться на 1.14.0. Для production-кластеров на 1.13, где переход на Kubernetes 1.37 и новая конфигурационная модель требуют отдельного окна тестирования, 1.13.10 остаётся актуальной точкой обслуживания перед последующей миграцией.