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

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

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

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

Чтобы включить резервное копирование etcd:

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

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

#Как это работает

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

#Справочник по настройке

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

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

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

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

apiVersion: enhancement.cluster.alauda.io/v1
kind: EtcdBackupConfiguration
metadata:
  name: etcd-backup-default
spec:
  schedule: "0 0 * * *"       # Run daily at 00:00
  paused: false               # Enable backups
  localStorage:
    path: /mnt/etcd-backup    # A directory on a dedicated, mounted backup disk
    ttl: "7776000"            # Retain for 90 days
  # ... other fields

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

Чтобы просмотреть записи резервного копирования 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

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

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

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

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

Подготовьте учетные данные для доступа к S3 и создайте secret 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"  # e.g.: https://s3.bucket.com
      region: "your-s3-region"
      bucket: "your-s3-bucket"
      dir: "your-s3-bucket-dir"
      skipTLSVerify: false  # Set to true only for self-signed certificates
      secretRef: etcd-backup-s3-secret

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

Запустите резервное копирование etcd вручную, чтобы проверить конфигурацию:

# Set environment variables
token="your-platform-token"
platform_url="your-platform-url"
cluster_name="your-cluster-name"

# Trigger backup
curl $platform_url/kubernetes/$cluster_name/apis/enhancement.cluster.alauda.io/v1/etcdbackupconfigurations/etcd-backup-default/exec \
  -k -H "Authorization: Bearer $token"

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

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

Предупреждение:

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

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

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

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

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

# Create backup directory
mkdir -p /root/backup_$(date +%Y%m%d%H)/old-etcd/

# Stop kubelet
systemctl stop kubelet

# Backup etcdctl binary
cp $(find /var/lib/containerd/ -name etcdctl | tail -1) /root/etcdctl

# Remove etcd containers
crictl ps -a | grep etcd | awk '{print $1}' | xargs -r crictl rm -f

# Backup etcd data and kubernetes configuration
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/

# Modify etcd.yaml to use existing cluster state
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 на первом узле control plane и назовите его snapshot.db.

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

Выполните следующий сценарий на первом узле control plane, чтобы восстановить снимок.

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

#!/usr/bin/env bash

# Set etcd node IPs (Replace with actual IPs)
export ETCD_1=1.1.1.1
export ETCD_2=2.2.2.2
export ETCD_3=3.3.3.3

# Set corresponding node hostnames (Replace with actual hostnames)
export ETCD_1_HOSTNAME=etcd-1
export ETCD_2_HOSTNAME=etcd-2
export ETCD_3_HOSTNAME=etcd-3

export ETCDCTL_API=3

# Loop for 3 nodes. Adjust '1 2 3' if you have a different number of nodes.
for n in 1 2 3; do
  ip_var=ETCD_${n}
  host_var=ETCD_${n}_HOSTNAME

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

  echo "Restoring for node: ${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 "Restoration for ${host} completed. Data directory: /root/etcd_${host}"
done

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

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

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

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

   # Replace <etcd-2-ip> and <etcd-3-ip> with actual IPs
   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) на каждом узле control plane.

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

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

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

# Remove Kubernetes control plane containers
crictl ps -a | grep -E "kube-api|kube-sche|kube-contro" | awk '{print $1}' | xargs -r crictl rm -f

# Restart kubelet
systemctl restart kubelet

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

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

   # Using etcdctl on the host
   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. Проверьте, что pods Kubernetes работают корректно:

   kubectl get po -n kube-system

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

   systemctl restart kubelet

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

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