测验：etcd 的备份与恢复

将 etcd 扩展为 3 个成员以满足法定人数后，这种配置无法防范哪种事故？

• 单个节点网络中断
• 误删命名空间
• 单个成员的进程崩溃
• 一台控制平面机器的磁盘故障

为什么 etcdctl snapshot restore 要接受 --name、--initial-cluster、--initial-cluster-token 等参数？

• 为了让恢复的数据目录重新作为成员加入现有集群
• 因为恢复本质上是在引导一个全新的 etcd 集群
• 为了核对快照文件的哈希值与成员配置是否一致
• 为了按新成员名称和对等地址重新签发 TLS 证书

恢复流程中先停止 kube-apiserver，最合适的原因是什么？

• 为了防止 kubelet 重启静态 Pod
• 因为 apiserver 会锁定 etcd 数据目录
• 为了防止恢复期间传入的新写入与恢复结果混杂
• 因为只有停止 apiserver 才能制作快照

snapshot status 的结果中，totalKey 异常地小。首先应怀疑什么？

• 存放快照的磁盘空间不足，文件尾部被截断
• 快照没有包含全部数据，或从错误的端点获取
• hash 算法变化导致键数统计不同
• etcd 版本太低，部分键空间未被纳入快照

恢复时为什么不能将 --data-dir 指向已有的 /var/lib/etcd？

• restore 要求空目录；指定已有路径会失败或损坏现存数据
• 该路径固定归 root 所有，备份用户没有写权限
• 恢复目录必须与快照文件位于同一文件系统，该路径不满足要求
• etcd 将该路径保留为专用目录，拒绝外部工具写入

定期备份的 CronJob 为什么要同时设置 nodeSelector 和 tolerations？

• 将备份 Pod 平均分散在三台控制平面节点上
• 因为 etcd 仅位于控制平面节点，且这些节点带有污点，两者都需要
• 因为 CronJob 不设置 tolerations 就无法调度到任何节点
• 因为使用 hostPath 卷的 Pod 必须通过 nodeSelector 固定节点

每 6 小时备份一次，最坏情况下会丢失多少数据？

• 6 小时的变更
• 与快照大小相同的数据量
• 不会丢失数据
• 1 小时的变更

如果备份脚本始终只报告成功（OK），最大的问题是什么？

• 无法检测失败，直到事故发生才发现备份不可用
• 跳过验证会让快照文件每次都变大
• 快照的 revision 一直与上一次相同
• 每次都重新计算全部键数，运行时间变长