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

Служба etcd в кластере представляет собой распределённое хранилище ключ-значение, ответственное за хранение информации о конфигурации кластера. etcd развёрнут на всех узлах управляющей плоскости кластера.

После установки плагина Alauda Container Platform Cluster Enhancer для кластера автоматически создаётся ресурс EtcdBackupConfiguration. Этот ресурс содержит информацию об источниках данных для резервного копирования (узлы управления, пути для бэкапов), местах хранения резервных копий, методах резервного копирования и прочее. Каждое выполнение резервного копирования согласно политике создаёт новую запись, что позволяет выполнять резервное копирование конфигурации кластера по требованию или автоматически с заданной периодичностью.

#Предварительные требования

Для включения резервного копирования etcd:

1. Скачайте Alauda Container Platform Cluster Enhancer с портала клиентов .
2. Загрузите пакет на платформу.
3. Установите плагин в ваш кластер.

После установки ресурс EtcdBackupConfiguration создаётся автоматически.

#Принцип работы

• Резервное копирование etcd обеспечивается Alauda Container Platform Cluster Enhancer.
• Поддерживается локальное хранилище и объектное хранилище, совместимое с S3. По умолчанию резервные копии сохраняются локально в /cpaas. При настройке S3-хранилища создаётся дополнительная копия в S3-бакете; локальные резервные копии продолжают создаваться.
• Для кластеров, работающих на Immutable OS, использование S3-хранилища обязательно (локальное хранилище не поддерживается).

#Справочник по конфигурации

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

#Расписание и хранение

• schedule: Определяет частоту резервного копирования с использованием стандартного синтаксиса cron.
  • Пример: 0 0 * * * (ежедневное выполнение в полночь).
• localStorage: Настройка локального хранилища резервных копий.
  • path: Каталог на хосте для хранения резервных копий. По умолчанию /cpaas.
  • ttl: Время хранения файлов резервных копий в секундах. Резервные копии старше этого срока будут автоматически удалены.
    • Пример: 7776000 (примерно 90 дней).
• paused: Установите в true для временной приостановки автоматического резервного копирования без удаления конфигурации.

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

apiVersion: enhancement.cluster.alauda.io/v1
kind: EtcdBackupConfiguration
metadata:
  name: etcd-backup-default
spec:
  schedule: "0 0 * * *"       # Выполнять ежедневно в 00:00
  paused: false               # Включить резервное копирование
  localStorage:
    path: /cpaas-backup       # Пользовательский путь для резервных копий
    ttl: "7776000"            # Хранить 90 дней
  # ... другие поля

#Просмотр записей резервного копирования

Для просмотра записей резервного копирования etcd можно использовать UI платформы или командную строку.

#Использование UI платформы

1. В левой навигационной панели выберите Operation Center > Monitor > Dashboards.
2. Нажмите Switch в правом верхнем углу страницы.
3. Выберите Cluster → etcd backup для просмотра записей резервного копирования etcd.

#Использование CLI

Проверить статус и историю резервного копирования можно, просмотрев поле status ресурса EtcdBackupConfiguration:

kubectl get etcdbackupconfiguration etcd-backup-default -o yaml

В выводе содержится список status.records с деталями каждого бэкапа, включая:

• backupTimestamp: Время создания резервной копии.
• fileName: Имя файла резервной копии (например, snapshot-etcd-<date>-<time>-<ip>.tar).
• result: Результат операции резервного копирования (например, Success).

#Конфигурация резервного копирования в S3

Для включения хранения резервных копий etcd в S3 выполните следующие шаги:

#Предварительные требования

• Плагин Alauda Container Platform Cluster Enhancer установлен в кластере.

#Шаг 1: Создайте секрет S3

Подготовьте учётные данные доступа к S3 и создайте секрет Kubernetes в пространстве имён cpaas-system:

export ACCESS_KEY="your-access-key"
export SECRET_KEY="your-secret-key"

kubectl create secret generic etcd-backup-s3-secret \
  --from-literal=ACCESS_KEY="$ACCESS_KEY" \
  --from-literal=SECRET_KEY="$SECRET_KEY" \
  --dry-run=client -n cpaas-system -o yaml | kubectl apply -f -

#Шаг 2: Настройте EtcdBackupConfiguration

Измените ресурс EtcdBackupConfiguration, добавив поле remoteStorage с конфигурацией S3:

spec:
  remoteStorage:
    s3:
      endpoint: "your-s3-endpoint"  # например: https://s3.bucket.com
      region: "your-s3-region"
      bucket: "your-s3-bucket"
      dir: "your-s3-bucket-dir"
      skipTLSVerify: false  # Устанавливайте в true только для самоподписанных сертификатов
      secretRef: etcd-backup-s3-secret

#Шаг 3: Проверьте резервное копирование

Запустите ручное резервное копирование etcd для проверки конфигурации:

# Установите переменные окружения
token="your-platform-token"
platform_url="your-platform-url"
cluster_name="your-cluster-name"

# Запуск резервного копирования
curl $platform_url/kubernetes/$cluster_name/apis/enhancement.cluster.alauda.io/v1/etcdbackupconfigurations/etcd-backup-default/exec \
  -k -H "Authorization: Bearer $token"

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

#Восстановление etcd

Внимание:

• Эта операция выполняет катастрофическое восстановление кластера etcd. Она перезапишет существующие данные. Убедитесь, что у вас есть действительный снимок резервной копии перед началом.
• Процедура связана с высокими рисками. Если вы не уверены в своих действиях, обратитесь в техническую поддержку.
• Во время восстановления API Server Kubernetes будет недоступен.

#Предварительные требования

• Kubernetes кластер развернут с использованием имён хостов (в выводе kubectl get node имена узлов — это имена хостов).
• Имеется снимок резервной копии etcd.
• Кластер не работает из-за отказа узлов etcd (например, более половины узлов управляющей плоскости недоступны).
• Эта процедура восстановления предназначена для кластера с 3 узлами управляющей плоскости. Если в вашем кластере 5 и более узлов управляющей плоскости, обратитесь в техническую поддержку.

#Шаг 1: Создайте резервную копию исходных данных и измените конфигурацию etcd

Выполните следующие команды на всех узлах управляющей плоскости:

# Создать каталог для резервных копий
mkdir -p /root/backup_$(date +%Y%m%d%H)/old-etcd/

# Остановить kubelet
systemctl stop kubelet

# Скопировать бинарник etcdctl
cp $(find /var/lib/containerd/ -name etcdctl | tail -1) /root/etcdctl

# Удалить контейнеры etcd
crictl ps -a | grep etcd | awk '{print $1}' | xargs -r crictl rm -f

# Создать резервную копию данных etcd и конфигурации kubernetes
cp -a /var/lib/etcd/* /root/backup_$(date +%Y%m%d%H)/old-etcd/
rm -rf /var/lib/etcd/*
cp -r /etc/kubernetes/ /root/backup_$(date +%Y%m%d%H)/old-etcd/

# Изменить etcd.yaml для использования существующего состояния кластера
sed -i /initial-cluster-state=/d /etc/kubernetes/manifests/etcd.yaml
sed -i '/initial-cluster=/a\    - --initial-cluster-state=existing' /etc/kubernetes/manifests/etcd.yaml

Примечание: Проверьте отступ у строки --initial-cluster-state=existing в файле /etc/kubernetes/manifests/etcd.yaml.

#Шаг 2: Скопируйте снимок резервной копии

Скопируйте последний снимок резервной копии etcd в каталог /tmp на первом узле управляющей плоскости и переименуйте его в snapshot.db.

#Шаг 3: Восстановите etcd

Выполните следующий скрипт на первом узле управляющей плоскости для восстановления снимка.

Примечание: Скрипт рассчитан на кластер с 3 узлами управляющей плоскости. Если у вас 5 и более узлов, обратитесь в техническую поддержку.

#!/usr/bin/env bash

# Задайте IP-адреса узлов etcd (замените на реальные IP)
export ETCD_1=1.1.1.1
export ETCD_2=2.2.2.2
export ETCD_3=3.3.3.3

# Задайте соответствующие имена хостов узлов (замените на реальные имена)
export ETCD_1_HOSTNAME=etcd-1
export ETCD_2_HOSTNAME=etcd-2
export ETCD_3_HOSTNAME=etcd-3

export ETCDCTL_API=3

# Цикл по 3 узлам. Измените '1 2 3', если число узлов другое.
for n in 1 2 3; do
  ip_var=ETCD_${n}
  host_var=ETCD_${n}_HOSTNAME

  ip=${!ip_var}
  host=${!host_var}

  echo "Восстановление для узла: ${host} (${ip})..."

  rm -rf /tmp/etcd
  /root/etcdctl snapshot restore /tmp/snapshot.db \
    --cert=/etc/kubernetes/pki/etcd/server.crt \
    --key=/etc/kubernetes/pki/etcd/server.key \
    --cacert=/etc/kubernetes/pki/etcd/ca.crt \
    --skip-hash-check=true \
    --data-dir=/tmp/etcd \
    --name "${host}" \
    --initial-cluster \
      ${ETCD_1_HOSTNAME}=https://${ETCD_1}:2380,\
${ETCD_2_HOSTNAME}=https://${ETCD_2}:2380,\
${ETCD_3_HOSTNAME}=https://${ETCD_3}:2380 \
    --initial-advertise-peer-urls https://"${ip}":2380 && \
    mv /tmp/etcd /root/etcd_"${host}"

  echo "Восстановление для ${host} завершено. Каталог данных: /root/etcd_${host}"
done

После выполнения скрипта в каталоге /root появятся три директории (etcd_$host).

#Шаг 4: Распространите восстановленные данные

1. Передайте каталоги с восстановленными данными соответствующим узлам управляющей плоскости. Используйте scp или аналогичный инструмент для копирования директорий, созданных на шаге 3 (/root/etcd_<hostname>) с первого узла на остальные.

   Например, передача на etcd-2 и etcd-3:

   # Замените <etcd-2-ip> и <etcd-3-ip> на реальные IP
   scp -r /root/etcd_etcd-2 root@<etcd-2-ip>:/root/
   scp -r /root/etcd_etcd-3 root@<etcd-3-ip>:/root/

2. Восстановите данные в каталог данных etcd (/var/lib/etcd) на каждом узле управляющей плоскости.

   # На etcd-1:
   cp -r /root/etcd_etcd-1/member/* /var/lib/etcd/
   
   # На etcd-2:
   cp -r /root/etcd_etcd-2/member/* /var/lib/etcd/
   
   # На etcd-3:
   cp -r /root/etcd_etcd-3/member/* /var/lib/etcd/

#Шаг 5: Перезапустите компоненты кластера

Выполните следующие команды на всех узлах управляющей плоскости:

# Удалить контейнеры управляющей плоскости Kubernetes
crictl ps -a | grep -E "kube-api|kube-sche|kube-contro" | awk '{print $1}' | xargs -r crictl rm -f

# Перезапустить kubelet
systemctl restart kubelet

#Шаг 6: Проверьте восстановление

1. Проверьте состояние кластера etcd. Выполните команду внутри любого пода etcd или используя бинарник etcdctl на хосте:

   # Использование etcdctl на хосте
   export ETCDCTL_API=3
   /root/etcdctl --cacert=/etc/kubernetes/pki/etcd/ca.crt \
     --cert=/etc/kubernetes/pki/etcd/server.crt \
     --key=/etc/kubernetes/pki/etcd/server.key \
     --endpoints=https://127.0.0.1:2379 \
     endpoint health

2. Проверьте, что поды Kubernetes работают корректно:

   kubectl get po -n kube-system

3. Перезапустите kubelet на всех узлах (как управляющей плоскости, так и рабочих), чтобы все компоненты переподключились к восстановленному etcd:

   systemctl restart kubelet

#Управление конфигурацией

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