title: “K8s 系列 | 第 26 天：集群备份与恢复：etcd 快照 + Velero 方案”
tags:
– Kubernetes
– K8s系列
– DevOps
– 备份恢复
– etcd
– Velero
– 数据保护

第 26/30 天 | 系列目录见文末

K8s 系列 | 第 26 天：集群备份与恢复：etcd 快照 + Velero 方案

引言

在生产环境中，Kubernetes 集群承载着关键业务应用和数据。然而，任何系统都可能面临风险：硬件故障、操作失误、网络分区、勒索软件攻击……如果没有完善的备份恢复策略，一次事故就可能导致整个集群不可用，造成严重后果。

K8s 的备份恢复需要解决两个层面的问题：

控制平面数据——etcd 中存储的集群状态（资源对象、配置、状态）
工作负载数据——PV 中持久化的应用数据

本文将深入讲解 etcd 快照备份机制和 Velero 集群备份恢复方案，帮助你构建生产级的 K8s 数据保护体系。

一、etcd 快照：控制平面的生命线

1.1 为什么要备份 etcd？

etcd 是 K8s 的”大脑”，存储了所有集群资源对象的状态：

Pod、Deployment、Service、ConfigMap、Secret 等 API 对象的定义
集群节点信息、RBAC 配置
所有资源的当前状态和期望状态

etcd 不可用 = 集群不可管理。虽然存量的 Pod 会继续运行，但你无法创建、更新或删除任何资源。

1.2 手动创建 etcd 快照

kubeadm 部署的集群可以通过 etcdctl 工具直接备份：

# 设置 etcd API 版本
export ETCDCTL_API=3

# 使用证书参数创建快照
sudo ETCDCTL_API=3 etcdctl 
  --cacert=/etc/kubernetes/pki/etcd/ca.crt 
  --cert=/etc/kubernetes/pki/etcd/server.crt 
  --key=/etc/kubernetes/pki/etcd/server.key 
  snapshot save /backup/etcd-snapshot-$(date +%Y%m%d-%H%M%S).db

验证快照文件完整性：

# 检查快照状态
sudo ETCDCTL_API=3 etcdctl 
  --cacert=/etc/kubernetes/pki/etcd/ca.crt 
  --cert=/etc/kubernetes/pki/etcd/server.crt 
  --key=/etc/kubernetes/pki/etcd/server.key 
  snapshot status /backup/etcd-snapshot-20260712-080000.db

# 输出示例：
# b512d3c6, 56342, 3.5.0, 36 MB

1.3 etcd 快照恢复流程

当集群完全损坏时，使用快照恢复到某个时间点：

# 1. 停止 etcd 和 API server 相关组件
sudo systemctl stop kubelet
# 如果使用容器化 etcd：
docker stop $(docker ps | grep etcd | awk '{print $1}')
docker stop $(docker ps | grep kube-apiserver | awk '{print $1}')

# 2. 从快照恢复（会在指定目录生成一个新的数据目录）
sudo ETCDCTL_API=3 etcdctl snapshot restore /backup/etcd-snapshot-20260712-080000.db 
  --data-dir /var/lib/etcd-restored 
  --name master 
  --initial-cluster master=https://10.0.0.10:2380 
  --initial-cluster-token etcd-cluster-restore 
  --initial-advertise-peer-urls https://10.0.0.10:2380

# 3. 将恢复的数据目录替换到 etcd 配置中
sudo mv /var/lib/etcd /var/lib/etcd.bak
sudo mv /var/lib/etcd-restored /var/lib/etcd

# 4. 启动 etcd 和 kubelet
sudo systemctl start kubelet

注意：etcd 快照恢复会抹掉恢复时间点之后的所有变更，属于粗粒度的全量恢复方式。高频备份（至少每天一次）是控制恢复时间点窗口的关键。

1.4 定时自动化 etcd 备份

建议配置 cron 作业自动执行 etcd 快照并保留最近 N 份：

#!/bin/bash
# /usr/local/bin/etcd-backup.sh
BACKUP_DIR="/backup/etcd"
RETENTION_DAYS=30
TIMESTAMP=$(date +%Y%m%d-%H%M%S)

mkdir -p $BACKUP_DIR

ETCDCTL_API=3 etcdctl 
  --cacert=/etc/kubernetes/pki/etcd/ca.crt 
  --cert=/etc/kubernetes/pki/etcd/server.crt 
  --key=/etc/kubernetes/pki/etcd/server.key 
  snapshot save $BACKUP_DIR/snapshot-$TIMESTAMP.db

# 保留最近 30 天的备份
find $BACKUP_DIR -name "snapshot-*.db" -mtime +$RETENTION_DAYS -delete

# 同步到远端存储（如 S3）
aws s3 cp $BACKUP_DIR/snapshot-$TIMESTAMP.db s3://my-cluster-backup/etcd/

Cron 配置（每天凌晨 2 点执行）：

0 2 * * * /usr/local/bin/etcd-backup.sh

二、Velero：集群级备份恢复方案

etcd 快照只能恢复控制平面数据，但生产集群还需要保护 PV 中的持久化数据。Velero 是目前最流行的 K8s 集群备份恢复工具，由 VMware 开源。

2.1 Velero 核心架构

Velero 由两部分组成：

组件	说明
Velero 服务端	运行在集群中的 Deployment，负责执行备份/恢复操作
`velero` CLI	客户端命令行工具，用于管理备份任务
存储后端插件	对接 AWS S3、GCS、Azure Blob、MinIO 等对象存储
Volume 快照插件	对接云厂商存储快照 API 或开源方案（如 restic）

工作流程：

velero backup create → Velero 服务端 → API 对象 → 对象存储
                                    → PV 快照 → 云存储 / restic 备份

2.2 安装 Velero

使用 Helm 安装是推荐方式，这里展示如何对接 MinIO（自建 S3 兼容存储）：

# values.yaml
configuration:
  provider: aws
  backupStorageLocation:
    name: default
    bucket: velero-backups
    config:
      region: us-east-1
      s3ForcePathStyle: "true"
      s3Url: http://minio.minio-system:9000
  volumeSnapshotLocation:
    name: default
    config:
      region: us-east-1
  defaultVolumesToFsBackup: true  # 使用 restic 备份 PV 数据

initContainers:
  - name: velero-plugin-for-aws
    image: velero/velero-plugin-for-aws:v1.9.0
    volumeMounts:
      - mountPath: /target
        name: plugins

credentials:
  useSecret: true
  secretContents:
    cloud: |
      [default]
      aws_access_key_id = minioadmin
      aws_secret_access_key = minioadmin

安装命令：

helm repo add vmware-tanzu https://vmware-tanzu.github.io/helm-charts
helm repo update
helm install velero vmware-tanzu/velero 
  --namespace velero-system 
  --create-namespace 
  -f values.yaml

2.3 创建备份

# 备份所有命名空间下的资源
velero backup create daily-backup-$(date +%Y%m%d) 
  --ttl 720h  # 保留 30 天

# 备份指定命名空间
velero backup create ns-production 
  --include-namespaces production 
  --default-volumes-to-fs-backup

# 按标签选择备份
velero backup create app-myapp 
  --selector app=myapp 
  --include-cluster-resources=false

# 排除特定资源
velero backup create exclude-configmaps 
  --exclude-resources configmaps,secrets

2.4 查看和管理备份

# 查看所有备份
velero backup get

# 查看备份详情
velero backup describe daily-backup-20260712 --details

# 删除备份
velero backup delete daily-backup-20260711

2.5 执行恢复

# 恢复到原集群
velero restore create --from-backup daily-backup-20260712

# 恢复到新集群（迁移场景）
velero restore create 
  --from-backup daily-backup-20260712 
  --namespace-mappings production:staging

# 选择性恢复
velero restore create 
  --from-backup daily-backup-20260712 
  --include-namespaces production 
  --include-resources deployments,services

# 验证恢复结果
velero restore get
velero restore describe <restore-name>

2.6 备份调度器

设置定期自动备份：

# 创建每日凌晨 3 点的备份调度
velero schedule create daily-full 
  --schedule="0 3 * * *" 
  --ttl 720h 
  --default-volumes-to-fs-backup

# 查看调度
velero schedule get

# 暂停调度
velero schedule pause daily-full

# 恢复调度
velero schedule unpause daily-full

对应的 YAML 配置：

apiVersion: velero.io/v1
kind: Schedule
metadata:
  name: daily-full
  namespace: velero-system
spec:
  schedule: "0 3 * * *"
  template:
    ttl: 720h
    defaultVolumesToFsBackup: true

三、生产环境备份策略建议

3.1 分层备份架构

推荐采用三层备份策略，兼顾控制面和数据面：

层级	内容	工具	频率	RPO
L1 – etcd 快照	集群状态、资源对象	etcdctl	每 2-4 小时	≤ 4h
L2 – Velero 备份	API 对象 + PV 数据	Velero + restic	每天	≤ 24h
L3 – 异地容灾	全部备份同步到异地	rsync / Velero 多存储	实时/每天	≤ 24h

3.2 备份验证

备份没有验证等于没有备份！定期执行恢复演练：

# 在测试集群中验证备份的可恢复性
velero restore create 
  --from-backup daily-backup-20260712 
  --namespace-mappings production:test-restore

3.3 常见备份场景配置

# 生产环境完整备份调度
apiVersion: velero.io/v1
kind: Schedule
metadata:
  name: production-full-backup
  namespace: velero-system
spec:
  schedule: "0 2 * * *"
  template:
    includedNamespaces:          # 备份所有业务命名空间
      - production
      - staging
      - monitoring
    excludedNamespaces:          # 排除系统组件
      - velero-system
      - kube-system
    defaultVolumesToFsBackup: true
    ttl: 744h                    # 保留 31 天
    snapshotMoveData: true       # 使用 Data Mover 提高 PV 备份效率

四、常见问题

Q1：etcd 快照恢复后，Velero 备份还能用吗？

可以。两者相互独立：etcd 快照恢复的是集群状态，Velero 备份可以覆盖更细粒度的恢复。建议先恢复 etcd 快照让集群可用，再用 Velero 恢复特定命名空间的应用和数据。

Q2：restic 备份 PV 会影响应用性能吗？

restic 使用文件系统级别的快照，通过 hostPath 挂载的方式读取 PV 数据，对运行中的应用影响较小。但备份期间会有 I/O 开销，建议在业务低峰期执行备份。

Q3：大规模集群（1000+ 节点）备份需要注意什么？

etcd 快照会变大（可能 > 1GB），确保备份路径有足够磁盘空间
Velero 备份大量资源时可能超时，使用 --parallel 参数调整并发数
考虑拆分备份策略：按命名空间或应用分组分时段备份

Q4：Velero 能跨 K8s 版本恢复吗？

一般建议在相同或相近的 K8s 版本间恢复。跨大版本（如 1.24 → 1.28）恢复可能遇到 API 资源版本兼容性问题，建议先在测试集群验证。

总结

备份方案	保护范围	适用场景
etcd snapshot	集群控制平面	灾难恢复、集群重建
Velero（对象）	API 资源对象	细粒度恢复、迁移
Velero + restic	API 资源 + PV 数据	全量备份恢复

核心原则：
– 所有备份必须定期验证可恢复性
– 保留多地、多份备份（3-2-1 原则）
– 备份不仅是技术问题，更是运维规范——文档化恢复流程

下期预告

第 27 天：滚动更新与回滚策略：实现零停机发布

应用更新最怕的是什么？服务中断！下期我们将深入 Deployment 的滚动更新机制、健康检查探针配置、蓝绿部署和金丝雀发布策略，教你如何在不影响用户的情况下安全发布应用。

📚 系列目录

阶段	文章
第 1 周：基础入门	第 1-7 天：概念 → 集群搭建 → Pod → Deployment → Service → Namespace → ConfigMap/Secret
第 2 周：存储与网络	第 8-14 天：Volume → StorageClass → StatefulSet → Ingress → NetworkPolicy → Headless Service → CSI
第 3 周：调度与资源	第 15-21 天：Taint/Toleration → Affinity → HPA → VPA → Job/CronJob → PriorityClass → LimitRange
第 4 周：生产运维	第 22-28 天：监控 → 日志 → RBAC → Helm → 备份恢复(本篇) → 滚动更新 → 集群升级
第 5 周：进阶	第 29-30 天：多集群管理 → 踩坑实录