容器崩溃了，别慌
早上刚到公司，咖啡还没来得及泡，运维同事就在群里喊：“订单服务挂了！”你点开监控一看，Kubernetes 集群里的几个 Pod 状态变成了 CrashLoopBackOff。这时候你不会想从头部署一遍应用，更不想让用户一直看到“系统繁忙”。容器技术恢复方案，就是这个时候的救命稻草。
备份镜像只是第一步
很多人觉得，只要 Docker 镜像还在 registry 里，丢了也能重建。这话没错，但忽略了运行时状态。比如某个中间件容器正在处理临时任务，或者有未持久化的缓存数据，光靠镜像拉起来的新容器，可能根本接不上之前的活。
真正的恢复不只是重启容器，而是尽量还原出事前的状态。这就需要结合配置管理、持久化存储和编排策略一起设计。
利用持久卷保留关键数据
数据库容器最怕丢数据。用 Kubernetes 的 PersistentVolume（PV）和 PersistentVolumeClaim（PVC），能把数据目录挂载到外部存储上。哪怕 Pod 被删了重建，新容器一启动，还是能读到老数据。
apiVersion: v1
kind: Pod
metadata:
name: mysql-pod
spec:
containers:
- name: mysql
image: mysql:8.0
volumeMounts:
- name: mysql-data
mountPath: /var/lib/mysql
volumes:
- name: mysql-data
persistentVolumeClaim:
claimName: mysql-pvc这样即使节点宕机，只要 PVC 不删，换台机器照样把数据库拉起来。
配置与环境分离
硬编码在镜像里的配置一旦出问题，改起来费劲。用 ConfigMap 和 Secret 把配置抽出去，恢复时可以直接复用原有设置。
apiVersion: v1
kind: ConfigMap
metadata:
name: app-config
data:
LOG_LEVEL: "debug"
DB_HOST: "mysql-service"
---
apiVersion: v1
kind: Pod
metadata:
name: app-pod
spec:
containers:
- name: app
image: myapp:v1
envFrom:
- configMapRef:
name: app-config哪怕整个命名空间被误删，只要这些配置资源提前做了导出备份，恢复速度能快一大截。
自动恢复靠的是编排逻辑
Kubernetes 自带的控制器如 Deployment、StatefulSet，本身就具备自愈能力。Pod 挂了会自动重建，健康检查失败也会触发替换。
但要注意策略设置。比如 restartPolicy 设成 Always，确保容器异常退出后能立刻重启；readinessProbe 和 livenessProbe 写得合理，避免恢复后服务卡在“假活”状态。
灾难恢复演练不能省
某次上线后，Redis 容器因为配置错误频繁重启，结果发现备份脚本居然一个月没跑成功。等真出事才意识到，恢复方案不是写在文档里就行，得定期验证。
建议每个月搞一次“破坏性测试”：手动删掉生产环境某个非核心服务的 Pod 和 PVC，看团队能不能在十分钟内恢复正常。这种压力测试能暴露出很多隐藏问题。
日志和快照配合使用
容器本身是临时的，但日志不能跟着一起消失。把日志输出重定向到 ELK 或 Loki 这类集中式系统，出了问题可以回溯时间线。
对于有状态服务，比如 Kafka 或 etcd，定期做快照也很关键。Kubernetes 提供 Velero 这样的工具，能对整个命名空间做备份，包括 PV 数据、Service、Ingress 等资源。
velero backup create full-ns-backup --include-namespaces=myapp-prod万一集群整体故障，可以用这条命令快速在另一个地方还原现场。