Talos Linux для bare metal Kubernetes: immutable OS для enterprise кластеров

Делимся опытом работы с Talos Linux — immutable операционной системой под Kubernetes: рынок в 2026 году разворачивается к bare metal и уходит от cloud, а Talos попадает точно в эту точку — zero-trust security, API-driven management, automatic updates из коробки. Дальше — production-деплой Talos-кластера на 12 серверах Dell, только то, с чем столкнулись сами.

Почему Talos Linux для Kubernetes в 2026

Чем Talos Linux отличается от обычных дистрибутивов? Это специализированная immutable ОС, собранная исключительно под Kubernetes. Никакого лишнего софта, никакого SSH по умолчанию, минимальная поверхность атаки. Управление — только через API. На нашей практике это сильно сократило количество инцидентов, связанных с ручными правками на узлах.

• Immutable Infrastructure — ОС read-only, обновления через atomic image replacement
• Zero Trust by Design — нет SSH, shell, package manager, minimal attack surface
• API-driven — управление только через gRPC API, Infrastructure as Code
• Kubernetes-native — ОС оптимизирована именно под K8s workloads
• Bare Metal Ready — отличная поддержка железа, UEFI, TPM, GPU

Установка Talos на bare metal серверы

# 1. Скачать talosctl CLI
curl -sL https://talos.dev/install | sh

# 2. Генерация конфигурации кластера
talosctl gen config my-cluster https://k8s.company.local:6443
# Создает: controlplane.yaml, worker.yaml, talosconfig

# 3. Настройка для bare metal
# controlplane.yaml
machine:
  type: controlplane
  network:
    hostname: cp-1.k8s.local
    interfaces:
      - interface: eth0
        dhcp: false
        addresses:
          - 10.0.1.10/24
        routes:
          - network: 0.0.0.0/0
            gateway: 10.0.1.1
    nameservers:
      - 8.8.8.8
      - 1.1.1.1

cluster:
  controlPlane:
    endpoint: https://10.0.1.100:6443
  network:
    cni:
      name: none  # Будем ставить Cilium отдельно
    podSubnets:
      - 10.244.0.0/16
    serviceSubnets:
      - 10.96.0.0/12

Bootstrap Talos кластера

# 1. Apply конфигурации на серверы
talosctl apply-config --insecure   --nodes 10.0.1.10   --file controlplane.yaml

talosctl apply-config --insecure   --nodes 10.0.1.11,10.0.1.12   --file worker.yaml

# 2. Bootstrap первого control plane
talosctl bootstrap --nodes 10.0.1.10

# 3. Получить kubeconfig
talosctl kubeconfig --nodes 10.0.1.10

# 4. Проверка кластера
kubectl get nodes
kubectl get pods -A

# Логи сервисов
talosctl logs kubelet -n 10.0.1.101
talosctl logs etcd -n 10.0.1.101 --tail 100

# Системная информация
talosctl memory -n 10.0.1.101
talosctl cpu -n 10.0.1.101
talosctl disks -n 10.0.1.101
talosctl mounts -n 10.0.1.101

# Сетевая диагностика
talosctl netstat -n 10.0.1.101
talosctl interfaces -n 10.0.1.101
talosctl routes -n 10.0.1.101

# Список запущенных процессов
talosctl processes -n 10.0.1.101

# dmesg
talosctl dmesg -n 10.0.1.101

# Чтение файлов (read-only)
talosctl read /etc/os-release -n 10.0.1.101

# Перезагрузка / выключение
talosctl reboot -n 10.0.1.101
talosctl shutdown -n 10.0.1.101

# Отладка pod через ephemeral container
kubectl debug -it pod/nginx-abc123 --image=nicolaka/netshoot --target=nginx

# Отладка проблем на ноде через debug pod
kubectl debug node/worker-01 -it --image=ubuntu:22.04

Production конфигурация Talos

Для production bare metal кластера мы использовали enterprise-настройки. Не дефолт, не «поставили и забыли» — каждый параметр выверяли под реальную нагрузку. Ниже конфигурация, которую применяем сами.

# machine.yaml для production
machine:
  features:
    rbac: true
    stableHostname: true
  time:
    servers:
      - ntp.company.local
  sysctls:
    net.core.somaxconn: 65535
    net.ipv4.tcp_tw_reuse: 1
  kubelet:
    extraArgs:
      feature-gates: "RotateKubeletServerCertificate=true"
      protect-kernel-defaults: true
    nodeIP:
      validSubnets:
        - 10.0.1.0/24
  disks:
    - device: /dev/sdb  # Отдельный диск для etcd
      partitions:
        - mountpoint: /var/lib/etcd
          size: 100GB

cluster:
  etcd:
    advertisedSubnets:
      - 10.0.1.0/24
  apiServer:
    auditPolicy:
      apiVersion: audit.k8s.io/v1
      kind: Policy
      rules:
        - level: Metadata

Интеграция с Cilium CNI

После bootstrap первым делом ставим Cilium — он закрывает enterprise networking на уровне, который нам нужен в production. eBPF, network policies, observability — всё это Cilium даёт без лишних костылей.

# Установка Cilium для Talos
helm repo add cilium https://helm.cilium.io/
helm install cilium cilium/cilium   --namespace kube-system   --set kubeProxyReplacement=strict   --set k8sServiceHost=10.0.1.100   --set k8sServicePort=6443   --set operator.replicas=2   --set ipam.mode=kubernetes

Обновление Talos кластера

# Rolling update кластера
talosctl upgrade   --nodes 10.0.1.10,10.0.1.11,10.0.1.12   --image ghcr.io/siderolabs/installer:v1.6.0

# Проверка статуса обновления
talosctl version --nodes 10.0.1.10,10.0.1.11,10.0.1.12
kubectl get nodes

Как проходит обновление Talos и что проверяю перед ним

Обновление ОС в Talos — это вызов API: узлу передаётся образ installer, а дальше он всё делает сам. Схема A/B: предыдущее ядро и образ ОС остаются на диске, и если новая версия не загрузилась, загрузчик сам возвращает старую. Если Talos поднялся, но нагрузка на нём работать отказывается, откатываю вручную командой talosctl rollback.

Порядок действий узла при получении команды upgrade описан в документации: он делает cordon, дренирует поды, останавливает свои сервисы, отмонтирует файловые системы, пишет новый образ, один раз загружается в новую версию и только после самопроверки делает её постоянной и снимает cordon. Поэтому для приложений, которые плохо переносят резкую остановку, я заранее прописываю lifecycle.preStop в спецификации пода.

Что держу в голове перед каждым обновлением:

• Прыгать через минорные версии не стоит: миграция конфигурации тестируется только между соседними минорными релизами. С 1.0 на 1.2.4 иду так: последний патч 1.0, затем последний патч 1.1, затем 1.2.4.
• Обновление Talos не обновляет Kubernetes — начиная с v1.0 это отдельная процедура.
• Версия talosctl должна совпадать с версией, которая сейчас работает в кластере.
• Control plane Talos не даст обновить, если это приведёт к потере кворума etcd, и при одновременной команде на несколько узлов обновляет их по одному. Для воркеров такой защиты нет, а Rook/Ceph и другие системы с собственным кворумом могут не пережить перезагрузку нескольких узлов сразу — воркеры обновляю строго по одному.
• Образ беру из Image Factory, а не общий ghcr.io/siderolabs/installer: так в новую версию попадают и установленные системные расширения.

Если upgrade падает из-за процесса, который держит файл на диске, помогает флаг --stage: артефакты кладутся на диск, узел перезагружается и применяет обновление в самом начале загрузки. Ход процесса смотрю через talosctl dmesg -f или talosctl upgrade --wait --debug. По умолчанию --wait включён, таймаут ожидания — 30 минут.

# один воркер за раз, с выводом логов ядра
talosctl upgrade -n 10.0.1.11 --image <образ из Image Factory> --debug

# если узел не может отмонтировать ФС
talosctl upgrade -n 10.0.1.11 --image <образ> --stage

# откат на предыдущую версию
talosctl rollback -n 10.0.1.11

Обновление Kubernetes отдельно от ОС

Версию Kubernetes поднимаю командой talosctl upgrade-k8s. В --nodes указывается один узел control plane, которому уходит вызов, а обновляются все узлы кластера. Сначала всегда запускаю с --dry-run — команда покажет план без изменений.

talosctl -n 10.0.1.10 upgrade-k8s --to <версия> --dry-run
talosctl -n 10.0.1.10 upgrade-k8s --to <версия>

Команда заранее скачивает образы новых компонентов на узлы, патчит конфигурацию control plane, ждёт, пока новые static pod дойдут до API-сервера, обновляет daemonset kube-proxy, затем kubelet на каждом узле и повторно применяет bootstrap-манифесты. Если процесс оборвался, его можно просто запустить снова — он продолжит с места сбоя. Совместимость версий Kubernetes и Talos сверяю по Support Matrix в документации до начала работ.

Резервная копия etcd и восстановление

При трёх узлах control plane кластер переживает потерю одного, но не двух одновременно. Поэтому снапшот etcd снимаю по расписанию, а не «когда вспомнил». Снимать можно с любого здорового узла control plane — данные на всех одинаковые.

# штатный согласованный снапшот
talosctl -n 10.0.1.10 etcd snapshot db.snapshot

# кворум уже потерян — копирую файл базы напрямую
talosctl -n 10.0.1.10 cp /var/lib/etcd/member/snap/db .

# машинная конфигурация узла на случай замены железа
talosctl -n 10.0.1.10 get mc v1alpha1 -o yaml | yq eval '.spec' -

Прямая копия может быть несогласованной, если etcd в этот момент работал, — это вариант на крайний случай. Перед полным восстановлением проверяю, нельзя ли вернуть кворум: сравниваю talosctl -n IP etcd members на всех живых узлах и смотрю talosctl -n IP service etcd. Если нельзя — очищаю раздел EPHEMERAL на узлах, где etcd не поднимается (talosctl -n IP reset --graceful=false --reboot --system-labels-to-wipe=EPHEMERAL), дожидаюсь состояния Preparing у сервиса etcd и выполняю talosctl -n IP bootstrap --recover-from=./db.snapshot на одном узле.

Чек-лист после любых работ с кластером

• talosctl health — встроенная проверка кластера; ждёт готовности до 20 минут по умолчанию (--wait-timeout).
• talosctl dashboard — сводка по узлу, логи и метрики в реальном времени в терминале.
• talosctl -n IP service etcd и talosctl -n IP etcd members — состояние etcd и состав участников.
• kubectl get nodes — все узлы Ready, ни один не остался в SchedulingDisabled после обновления.
• Изменения конфигурации применяю через talosctl apply-config --dry-run, а рискованные — в режиме --mode try: если не подтвердить, конфиг откатится через таймаут, по умолчанию 1 минута.

Похожие статьи

• Talos Linux: минималистичная ОС, созданная только для Kubernetes
• WireGuard VPN-сервер на Linux: готовая инструкция для удалённого доступа в офис
• WireGuard VPN на Linux-сервере: корпоративная настройка под ключ
• Миграция с Windows Server на Linux: рабочий план для офиса 50+ ПК