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

Эта инструкция описывает создание отказоустойчивого кластера ALT Orchestra с несколькими управляющими узлами.

Минимальная рекомендуемая топология:

• 3 узла control plane;
• 2 узла worker;
• внешняя точка доступа Kubernetes API: балансировщик нагрузки или DNS-имя;
• доступ с рабочего места администратора к узлам ALT Orchestra по сети.

Нечётное количество control plane-узлов необходимо для кворума etcd. Минимум для отказоустойчивого control plane — 3 узла. Один отказавший управляющий узел в такой схеме не приводит к потере кворума.

Минимум из 2 узлов worker даёт уверенность, что если один узел откажет, поды при правильной настройке и наличии достаточного ресурса оставшегося worker-узла перезапустятся/активируются на нём.

Предварительная подготовка

Перед началом:

• проверьте системные требования;
• установите talosctl и kubectl на рабочее место администратора согласно разделу talosctl;
• подготовьте образ ALT Orchestra через генератор образов или используйте подходящий ISO/iPXE-образ;
• выберите способ загрузки узлов: ISO или iPXE;
• выберите точку доступа Kubernetes API согласно разделу Конечная точка доступа Kubernetes API.

Для среды без доступа в интернет используйте инструкции по подготовке закрытого контура и установке в закрытом контуре.

Особенности этой главы

Эта глава не заменяет быстрый старт. Она описывает отличия отказоустойчивого развертывания:

• используется 3 control plane-узла вместо одного;
• endpoint Kubernetes API должен вести на все управляющие узлы;
• talosctl настраивается на несколько endpoints;
• talosctl bootstrap выполняется один раз на одном control plane-узле;
• проверки и обновления выполняются поэтапно, без потери кворума etcd;
• обновление установленного дистрибутива ALT Orchestra выполняется через образ установщика ALT Orchestra, а обновление Kubernetes выполняется отдельной командой talosctl upgrade-k8s.

Топология

В примерах ниже используется 5 узлов:

Роль	Количество	Назначение
control plane	3	Kubernetes API, etcd, управляющие компоненты
worker	2	запуск пользовательских рабочих нагрузок

Пример адресов:

CONTROL_PLANE_IP=("192.168.1.2" "192.168.1.3" "192.168.1.4")
WORKER_IP=("192.168.1.5" "192.168.1.6")
CLUSTER_ENDPOINT="kube.example.com"
CLUSTER_NAME="ha-cluster"

CLUSTER_ENDPOINT должен указывать на балансировщик нагрузки или DNS-имя, через которое доступен Kubernetes API на 6443/tcp.

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

Отказоустойчивый кластер требует устойчивого endpoint для Kubernetes API. Подробно варианты с TCP-балансировщиком нагрузки и DNS-записями описаны в разделе Конечная точка доступа Kubernetes API.

В HA-сценарии важно, чтобы CLUSTER_ENDPOINT указывал не на один управляющий узел, а на адрес, который может направить трафик на все 3 control plane-узла. Например, DNS-имя может иметь несколько A-записей:

kube.example.com  IN  A  192.168.1.2
kube.example.com  IN  A  192.168.1.3
kube.example.com  IN  A  192.168.1.4

Тогда endpoint кластера:

https://kube.example.com:6443

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

Выполните шаги из быстрого старта для подготовки образов, запуска узлов, получения информации о дисках и сетевых интерфейсах, генерации 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"

Если диски, сетевые интерфейсы или hostname различаются между узлами, подготовьте отдельные конфигурации по схеме из быстрого старта: 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.

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

Примените конфигурацию на все 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 <node-ip-address>

Настройка talosconfig

Объедините созданный talosconfig с конфигурацией на рабочем месте администратора:

talosctl config merge ./talosconfig

Переключите talosctl на контекст создаваемого кластера:

talosctl config context "$CLUSTER_NAME"

Укажите все control plane-узлы как endpoints для talosctl:

talosctl config endpoint "${CONTROL_PLANE_IP[@]}"

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

Bootstrap etcd

Выполните bootstrap один раз и только на одном control plane-узле:

talosctl bootstrap \
  --nodes "${CONTROL_PLANE_IP[0]}" \
  --endpoints "${CONTROL_PLANE_IP[0]}"

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

Получение kubeconfig

Получите конфигурацию Kubernetes:

talosctl kubeconfig \
  --nodes "${CONTROL_PLANE_IP[0]}" \
  --endpoints "${CONTROL_PLANE_IP[0]}"

Проверьте текущий контекст:

kubectl config current-context

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

Убедитесь, что все узлы зарегистрированы в Kubernetes:

kubectl get nodes -o wide

Ожидаемый результат: 3 узла с ролью control-plane и 2 worker-узла в состоянии Ready.

Проверьте состояние компонентов ALT Orchestra и Kubernetes:

talosctl health \
  --nodes "${CONTROL_PLANE_IP[0]}" \
  --endpoints "${CONTROL_PLANE_IP[0]}"

Дополнительные проверки описаны в разделе Работоспособность.

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

В штатной эксплуатации:

• не уменьшайте количество здоровых control plane-узлов ниже большинства etcd;
• перед обслуживанием worker-узла выводите с него пользовательские нагрузки через kubectl drain;
• перед обслуживанием control plane-узла проверяйте здоровье etcd и Kubernetes API;
• храните talosconfig, kubeconfig и secrets.yaml в защищённом месте, пример шифрования приведён ниже;
• для добавления новых управляющих узлов используйте раздел Добавление Controlplane узла;
• для добавления новых worker-узлов используйте раздел Добавление Worker Узла;
• для удаления worker-узлов используйте раздел Удаление Worker узла.

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

Файлы 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.

---

После выполнения данной инструкции у вас появится отказоустойчивый кластер c тремя control plane-узлами, двумя worker-узлами, которые могут подстраховывать друг друга на случай выхода из строя соседних нод в кластере. Шифрование чувствительной информации через связку sops и age даст вам дополнительные гарантии в безопасности кластера.