很多人装机时会考虑电源要不要配UPS，硬盘要不要做RAID。其实在云原生环境里，灾备的思路也类似，只是规模更大，自动化程度更高。
传统灾备 vs 云原生灾备
以前公司服务器出问题，得靠备份磁带恢复，可能一两天都起不来。现在用云原生架构，服务挂了自动重启，节点坏了流量自动切走，就像你家路由器坏了，Wi-Fi自动连上备用线路一样自然。
多副本部署是基础
Kubernetes里一个应用通常不会只跑一个实例。比如部署一个订单服务，一般会设3个副本，分散在不同节点上。哪怕一台宿主机断电，其他副本还在跑。
apiVersion: apps/v1
kind: Deployment
metadata:
name: order-service
spec:
replicas: 3
selector:
matchLabels:
app: order
template:
metadata:
labels:
app: order
spec:
containers:
- name: app
image: order-service:v1.2跨可用区部署防区域性故障
就像你不把所有硬盘插在同一块主板上，云原生应用也会跨可用区（AZ）部署。比如阿里云上海有三个可用区，你的Pod分布在AZ-A、AZ-B、AZ-C，某个机房停电也不影响整体服务。
持久化数据怎么保
容器本身是临时的，但数据库不能丢。像MySQL、Redis这些有状态服务，会用持久卷（PersistentVolume）挂云存储，比如阿里云的NAS或AWS的EBS。即使节点挂了，数据还在云端。
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: mysql-data
spec:
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 50Gi自动恢复机制
K8s的探针就像心跳检测。Liveness Probe发现容器卡死就重启它，Readiness Probe发现服务没准备好就不往它转发流量。这就像你电脑蓝屏后自动重启，而不是一直黑着没人管。
灾难发生时的流量切换
多地多活架构下，用户请求会通过全局负载均衡（GSLB）分发。比如北京机房炸了，DNS自动把域名解析到深圳集群，用户几乎无感。这相当于你家主宽带断了，手机热点自动顶上。
备份不只是“有就行”
定期备份ETCD和数据库很重要。工具像Velero可以定时把整个命名空间的状态备份到对象存储，恢复时一键拉起。别等到删库跑路才想起没做快照。
velero backup create daily-backup --ttl 72h演练才是真保障
某大厂曾做过“混沌工程”：随机杀掉生产环境的Pod，看系统能不能自愈。结果发现两个微服务之间没有重试机制，一杀就断。修完这个问题后，系统稳定性明显提升。就像你装好电脑后跑一遍压力测试，别等用的时候才发现电源带不动。