Миграция с Debian на Talos Linux

Всем привет! Сегодня мы мигрируем мой кластер K3s, работающий на Debian на Talos Linux и ванильный кубер. А что вообще это за Talos Linux и зачем это все, если и так все работает?

Kubernetes стал стандартом де-факто для оркестрации контейнеров, с различными дистрибутивами, подходящими для разных нужд. K3s, легковесный дистрибутив Kubernetes, приобрел популярность благодаря своей простоте и низким требованиям к ресурсам. Однако по мере роста инфраструктуры и развития их потребностей возникает необходимость в миграции на более надежное решение, такое как Talos Linux и чистый Kubernetes. Я поделюсь своим опытом миграции моего кластера K3s.

Что за Talos Linux?

Talos Linux представляет себя как Linux, заточенный под Kubernetes. Перечислим его преимущества:

Безопасность. Talos использует неизменяемую и минимальную операционную систему на основе Linux, что значительно уменьшает поверхность атаки. Такой подход ограничивает потенциальные уязвимости и делает систему более устойчивой к вмешательствам.
Упрощенное управление. С Talos вся система управляется как кластер Kubernetes. Этот единый подход упрощает операции и снижает сложность управления отдельными слоями ОС и Kubernetes.
Автоматизированные обновления. Talos обеспечивает атомарные обновления как для ОС, так и для компонентов Kubernetes. Эта функция гарантирует, что ваш кластер остается актуальным с минимальным ручным вмешательством, уменьшая накладные расходы на обслуживание.
Улучшенная производительность. Благодаря своему минималистичному дизайну, Talos имеет меньшие накладные расходы на ресурсы по сравнению с традиционными дистрибутивами Linux.
Декларативная конфигурация. Talos использует модель декларативной конфигурации, позволяя определить все состояние кластера в одном файле. Этот подход повышает воспроизводимость и упрощает управление конфигурациями кластера как кодом.
Встроенная высокая доступность. Talos поставляется со встроенной поддержкой конфигураций высокой доступности, что упрощает настройку отказоустойчивых кластеров без дополнительных инструментов или сложных конфигураций.
Ориентация на контейнеры. Как ОС, оптимизированная для контейнеров, Talos спроектирована с нуля для эффективного запуска контейнеризированных рабочих нагрузок.
Управление через API. Все управление системой в Talos осуществляется через API, что позволяет лучше автоматизировать процессы и интегрироваться с существующими инструментами и рабочими процессами.
Уменьшенная сложность. Устраняя ненужные компоненты и фокусируясь исключительно на запуске Kubernetes, Talos уменьшает общую сложность системы. Это может привести к меньшему количеству точек отказа и более легкому устранению неполадок.
Архитектура, ориентированная на будущее. Принципы дизайна Talos хорошо согласуются с направлением облачных вычислений, потенциально делая его более перспективным выбором.

talosctl и talhelper

Поскольку доступа к ОС у нас нет, взаимодейcтвие с Talos важно понимать два ключевых инструмента: talosctl и talhelper. Эти инструменты значительно упрощают управление и настройку кластеров Talos.

talosctl — это основной инструмент командной строки для управления кластерами Talos. Он предоставляет широкий спектр функций для взаимодействия с узлами Talos и управления кластером.

talhelper — это дополнительный инструмент, разработанный сообществом, который упрощает создание и управление конфигурациями Talos. Он особенно полезен для больших и сложных развертываний.

talhelper gensecret > talsecret.yaml
talhelper genconfig
talhelper gencommand apply --extra-flags --insecure
talhelper gencommand bootstrap
talhelper gencommand kubeconfig

# this lines generated
talosctl apply-config --talosconfig=./clusterconfig/talosconfig --nodes=192.168.2.1 --file=./clusterconfig/shady-talos-cluster-vm-talos-master01.yaml --insecure;
talosctl apply-config --talosconfig=./clusterconfig/talosconfig --nodes=192.168.2.2 --file=./clusterconfig/shady-talos-cluster-vm-talos-master02.yaml --insecure;
talosctl apply-config --talosconfig=./clusterconfig/talosconfig --nodes=192.168.2.3 --file=./clusterconfig/shady-talos-cluster-vm-talos-master03.yaml --insecure;
talosctl apply-config --talosconfig=./clusterconfig/talosconfig --nodes=192.168.2.4 --file=./clusterconfig/shady-talos-cluster-vm-talos-worker01.yaml --insecure;
talosctl apply-config --talosconfig=./clusterconfig/talosconfig --nodes=192.168.2.5 --file=./clusterconfig/shady-talos-cluster-vm-talos-worker02.yaml --insecure;
talosctl apply-config --talosconfig=./clusterconfig/talosconfig --nodes=192.168.2.6 --file=./clusterconfig/shady-talos-cluster-vm-talos-worker03.yaml --insecure;

talosctl bootstrap --talosconfig=./clusterconfig/talosconfig --nodes=192.168.2.1;
talosctl kubeconfig --talosconfig=./clusterconfig/talosconfig --nodes=192.168.2.1 .;

talhelper gensecret > talsecret.yaml генерирует набор секретов, необходимых для вашего кластера Talos, и сохраняет их в файл с именем talsecret.yaml. Эти секреты используются для обеспечения безопасной связи внутри кластера.
talhelper genconfig генерирует файлы конфигурации для вашего кластера Talos на основе настроек в вашем файле talhelper.yaml и секретов, сгенерированных на шаге 1. Обычно она создает набор YAML-файлов для каждого узла в вашем кластере.
talhelper gencommand apply --extra-flags --insecure генерирует команды talosctl apply-config для каждого узла в вашем кластере.
talhelper gencommand bootstrap генерирует команду talosctl bootstrap, которая используется для начальной загрузки первого узла плоскости управления вашего кластера.
talhelper gencommand kubeconfig генерирует команду talosctl kubeconfig, которая используется для получения файла kubeconfig для доступа к вашему кластеру Kubernetes.

А потом просто выполняем сгенерированные команды:

Команды talosctl apply-config используются для применения сгенерированных конфигураций к каждому узлу в вашем кластере. В примере шесть узлов: три мастер-узла и три рабочих узла.
Команда talosctl bootstrap используется для начальной загрузки первого узла.
Команда talosctl kubeconfig используется для получения файла kubeconfig с первого узла.

Миграция

Примерные шаги такие:

Создал в Proxmox шесть виртуальных машин с одним и тем же образом Talos Linux, нужный образ затем накатывается через talosctl.
Сгенерировал с помощью talhelper и исправил конфигурации для мастер-нод и рабочих нод. Я буду использовать CNI Cilium

talosVersion: v1.7.6
kubernetesVersion: v1.30.3

clusterName: shady-talos-cluster
endpoint: https://192.168.2.1:6443
nodes:
  - hostname: vm-talos-master01
    controlPlane: true
    ipAddress: 192.168.2.1
    installDisk: /dev/sda
    talosImageURL: factory.talos.dev/installer/f683308f6e49ec36d715bd41c90d800910552d8cbc015c8363ec350594535fa1
    networkInterfaces:
      - deviceSelector:
          busPath: "0*"
        dhcp: true
        vip:
          ip: 192.168.2.10
  - hostname: vm-talos-master02
    controlPlane: true
    ipAddress: 192.168.2.2
    installDisk: /dev/sda
    talosImageURL: factory.talos.dev/installer/f683308f6e49ec36d715bd41c90d800910552d8cbc015c8363ec350594535fa1
    networkInterfaces:
      - deviceSelector:
          busPath: "0*"
        dhcp: true
        vip:
          ip: 192.168.2.10
  - hostname: vm-talos-master03
    controlPlane: true
    ipAddress: 192.168.2.3
    installDisk: /dev/sda
    talosImageURL: factory.talos.dev/installer/f683308f6e49ec36d715bd41c90d800910552d8cbc015c8363ec350594535fa1
    networkInterfaces:
      - deviceSelector:
          busPath: "0*"
        dhcp: true
        vip:
          ip: 192.168.2.10
  - hostname: vm-talos-worker01
    controlPlane: false
    ipAddress: 192.168.2.4
    installDisk: /dev/sda
    talosImageURL: factory.talos.dev/installer/4c4acaf75b4a51d6ec95b38dc8b49fb0af5f699e7fbd12fbf246821c649b5312
  - hostname: vm-talos-worker02
    controlPlane: false
    ipAddress: 192.168.2.5
    installDisk: /dev/sda
    talosImageURL: factory.talos.dev/installer/4c4acaf75b4a51d6ec95b38dc8b49fb0af5f699e7fbd12fbf246821c649b5312
  - hostname: vm-talos-worker03
    controlPlane: false
    ipAddress: 192.168.2.6
    installDisk: /dev/sda
    talosImageURL: factory.talos.dev/installer/4c4acaf75b4a51d6ec95b38dc8b49fb0af5f699e7fbd12fbf246821c649b5312

patches:
  # Force nameserver
  - |-
    machine:
      kubelet:
        extraArgs:
          rotate-server-certificates: true
      network:
        nameservers:
          - 8.8.8.8

controlPlane:
  patches:
    # Cluster configuration
    - |-
      cluster:
        # allowSchedulingOnControlPlanes: true
        controllerManager:
          extraArgs:
            bind-address: 0.0.0.0
        proxy:
          disabled: true
        network:
          cni:
            name: none
        scheduler:
          extraArgs:
            bind-address: 0.0.0.0
  schematic:
    customization:
      extraKernelArgs:
        - net.ifnames=0
      systemExtensions:
        officialExtensions:
          - siderolabs/qemu-guest-agent
worker:
  patches:
    # Machine configuration
    - |-
      machine:
        kubelet:
          extraMounts:
            - destination: /var/mnt/longhorn
              type: bind
              source: /var/mnt/longhorn
              options:
                - bind
                - rshared
                - rw
        disks:
            - device: /dev/sdb
              partitions:
                - mountpoint: /var/mnt/longhorn
  schematic:
    customization:
      extraKernelArgs:
        - net.ifnames=0
      systemExtensions:
        officialExtensions:
          - siderolabs/qemu-guest-agent
          - siderolabs/iscsi-tools
          - siderolabs/util-linux-tools

Накатил конфигурацию на мастер ноду с помощью talctl, bootstrap делается один раз только для нее
Накатил конфигурацию на остальные ноды
После перезагрузки кластер заработает

Миграция полезной нагрузки

Тут меня ожидал сюрприз, ванильный кубер ничего не знает про Helm controller, который в K3s работает из коробки. Там можно сделать вот так:

apiVersion: helm.cattle.io/v1
kind: HelmChart
metadata:
  name: apache
  namespace: kube-system
spec:
  repo: https://charts.bitnami.com/bitnami
  chart: apache
  targetNamespace: web
  valuesContent: |-
    service:
      type: ClusterIP
    ingress:
      enabled: true
      hostname: www.example.com
    metrics:
      enabled: true

Соответственно, вся установка кластера состояла у меня только из файлов манифестов yaml. Поиски Helm контроллера для ванильного кубера не увенчалась успехом, поэтому манифесты пришлось переделывать в скрипты bash.

А некоторые поды и вовсе не захотели запускаться. Чтобы у вас заработали привилегированные поды, нужно добавить аннотации в нужный namespace:

pod-security.kubernetes.io/audit: privileged
pod-security.kubernetes.io/audit-version: latest
pod-security.kubernetes.io/enforce: privileged
pod-security.kubernetes.io/enforce-version: latest
pod-security.kubernetes.io/warn: privileged
pod-security.kubernetes.io/warn-version: latest

Миграция persistent volumes (PV) в новый Longhorn не принесла никаких сложностей, я просто забэкапил все в S3 на старом кластере, а затем восстановил их в новом без проблем.

Еще пару штрихов

Естественно, пришлось обновить статические адреса в DNS и балансировщиков нагрузки, чтобы они указывали на новый кластер. Я использовал Cilium L2 Announcements вместо MetalLB.

Также выяснилось, что metrics-server тоже по дефолту не устанавливается, в отличии от K3s, пришлось накатить руками.

Жизнь после миграции

Больше всего меня расстроило отсутствие Helm контроллера. Мне очень нравилось, что вся моя конфигурация кластера состоит только из манифестов. Если кто-то подумал про Flux CD, то я тоже о нем подумал и решил не использовать.

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

Talos Linux лучше устанавливать с использованием гипервизора, так легче бэкапить и администрировать виртуальные машины. К тому же, Talos Linux забирает весь первый диск себе, поэтому, если решите ставить на голое железо, нужно иметь два диска - один поменьше для файлов Talos, второй для данных.

Так зачем все это? Я хотел отказаться от необходимости администрировать и настраивать ОС — и это отлично получилось. Создание новой ноды теперь делается в две команды и это не может не радовать.

Ну и для эксперимента конечно, хотелось знать, как сильно урезан K3s. В итоге оказалось, что он упрощал мне жизнь и заботился обо мне, а я и не догадывался. Метрики? какие еще метрики? Поставь сам. Helm контроллер? Какой еще Helm контроллер, ты чего-то странного захотел. Привилегированный под? Нет, такое мы здесь не запускаем (прописываем аннотации). Поэтому, если вы думаете с чего начать — для новичков K3s крайне рекомендую.

Что наша жизнь? Игра!

Ссылки

Proxmox Server Solutions

Proxmox develops powerful and efficient open-source server solutions like the Proxmox VE platform, Proxmox Backup Server, and Proxmox Mail Gateway.

Proxmox

Automating Talos Installation on Proxmox with Packer and Terraform, Integrating Cilium and Longhorn

I recently migrated my home kubernetes cluster from K3s to Talos. While K3s was an excellent lightweight option for my home server, it required installing, hardening and maintaining a base operating system (Debian, in my case). As someone who frequently builds and destroys Kubernetes clusters - both intentionally and accidentally - my priority has always been to restore my services with minimal effort after a disaster. Talos, a minimalistic Linux distribution specifically designed for Kubernetes, tailored for automation, reliability and simplicity, seems to be a perfect fit for my needs. In this blog, I am documenting the steps I followed to install a six-node Talos cluster, serving as a future reference for myself and potentially helping others with similar projects.

Suraj Remanan

Talos - An Immutable OS for Kubernetes

Talos is an operating system for Kubernetes. It is designed to be lightweight, secure, and easy to use. In this article, I will introduce Talos and its features.

A cup of coffeeQuentin JOLY

Cilium - Cloud Native, eBPF-based Networking, Observability, and Security