Резервное копирование и восстановление 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; локальные резервные копии продолжат создаваться.
• Для кластеров, работающих на 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 и создайте Secret Kubernetes в namespace 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.

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

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

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

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

• Кластер Kubernetes развёрнут с использованием hostname (kubectl get node отображает hostname в качестве имён узлов).
• Доступен снимок резервной копии 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. Проверьте, что pod'ы Kubernetes работают корректно:

   kubectl get po -n kube-system

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

   systemctl restart kubelet

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

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