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

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

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

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

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

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

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

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

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

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

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: Создайте Secret S3

Подготовьте учетные данные для доступа к S3 и создайте Kubernetes Secret в пространстве имен 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"

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

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

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

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

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

• Kubernetes-кластер развернут с использованием hostname (kubectl get node показывает hostname в качестве имен узлов).
• Доступен snapshot резервной копии 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: Скопируйте snapshot резервной копии

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

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

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

Примечание: Следующий сценарий предполагает кластер с 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 находится в рабочем состоянии. Вы можете выполнить эту команду внутри любого пода 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. Проверьте, что поды Kubernetes работают корректно:

   kubectl get po -n kube-system

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

   systemctl restart kubelet

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

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