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

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

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

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

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

1. Скачайте Alauda Container Platform Cluster Enhancer с Customer Portal.
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 обратитесь в техническую поддержку для получения подробной информации о параметрах конфигурации и расширенных настройках.