Kubeasz 集群备份与恢复实战基于 etcd 快照的完整容灾方案【免费下载链接】kubeasz使用Ansible脚本安装K8S集群介绍组件交互原理方便直接不受国内网络环境影响项目地址: https://gitcode.com/GitHub_Trending/ku/kubeaszkubeasz 使用 Ansible 脚本部署 Kubernetes 集群其备份与恢复能力围绕 etcd 集群状态快照展开ezctl backup将运行中的 etcd 数据导出为磁盘快照文件ezctl restore基于快照将集群恢复到备份时点状态。本文以 kubeasz 仓库中 cluster_restore.md 操作文档为主线结合 94.backup.yml、95.restore.yml 两个 playbook 与 cluster-restore 角色的源码实现完整讲解备份、恢复与灾难重建三条实战路径读完后可独立为 kubeasz 部署的集群建立可验证的备份与容灾流程。为什么集群备份与恢复的重点是 etcdKubernetes 集群采用多主多节点的高可用部署后计算节点故障可以通过重新调度自愈但集群的状态本身需要持久化保护。etcd 作为 Kubernetes 唯一的状态存储保存了全部 API 对象的最终一致数据——包括 Deployment、Service、ConfigMap、RBAC 规则、Pod 调度结果等。一旦 etcd 数据丢失或损坏即便所有 master/node 节点进程健康集群也会退化为有计算能力、无状态认知的空壳。因此 kubeasz 的备份与恢复方案核心只有两条备份从运行中的 etcd 集群导出快照数据到磁盘文件恢复从 etcd 快照文件恢复数据使集群回到备份时点状态。这一设计在 kubeasz 中由两个独立 playbook 支撑备份走playbooks/94.backup.yml恢复走playbooks/95.restore.yml并统一封装为ezctl backup/restore 集群名命令见 ezctl 脚本中 backup/restore 与两个 playbook 的映射关系。第一步搭建测试集群并执行备份操作文档建议先搭建一个测试集群部署若干测试 Deployment 验证各项功能正常后再进行首次备份下文以集群名k8s-01为例。$ ezctl backup k8s-01如果希望跳过 ezctl 封装直接调用 Ansible等效命令为$ ansible-playbook -i clusters/k8s-01/hosts -e clusters/k8s-01/config.yml playbooks/94.backup.yml备份 playbook 的源码执行逻辑ezctl backup实际调度的是 94.backup.yml该 playbook 在localhostAnsible 控制端执行包含两个关键步骤步骤一探测 etcd 集群中健康节点。遍历 inventory 中etcd组的所有节点使用 v3 API 逐一执行endpoint health健康检查ETCDCTL_API3 {{ base_dir }}/bin/etcdctl \ --endpointshttps://$ip:2379 \ --cacert{{ cluster_dir }}/ssl/ca.pem \ --cert{{ cluster_dir }}/ssl/etcd.pem \ --key{{ cluster_dir }}/ssl/etcd-key.pem \ endpoint health随后从输出中 grepis healthy关键字解析出第一个健康节点的地址作为快照数据源RUNNING_NODE.stdout。这一步保证了备份操作在任一 etcd 成员故障时依然可以从存活成员取数提高了备份的鲁棒性。健康检查与快照均通过 TLS 认证访问证书即集群部署时生成的ca.pem、etcd.pem、etcd-key.pem与 etcd role 证书分发 中ca_dir下证书一致。步骤二执行 etcd 快照备份。以当前时间戳命名快照文件mkdir -p {{ cluster_dir }}/backup cd {{ cluster_dir }}/backup \ ETCDCTL_API3 {{ base_dir }}/bin/etcdctl \ --endpointshttps://{{ RUNNING_NODE.stdout }}:2379 \ --cacert{{ cluster_dir }}/ssl/ca.pem \ --cert{{ cluster_dir }}/ssl/etcd.pem \ --key{{ cluster_dir }}/ssl/etcd-key.pem \ snapshot save snapshot_{{ timestamp.stdout }}.db备份完成后playbook 会将本次快照复制为固定文件名snapshot.db作为最近一次备份的稳定入口cd {{ cluster_dir }}/backup/ /bin/cp -f snapshot_{{ timestamp.stdout }}.db snapshot.db备份产物与目录结构备份文件统一存放在部署主机Ansible 控制端上对应集群的 backup 目录中/etc/kubeasz/clusters/k8s-01/backup/ ├── snapshot_202106201205.db ├── snapshot_202106211406.db └── snapshot.db其中snapshot.db始终指向最近一次备份文件带时间戳的历史快照则按日期累计留存便于回溯多个恢复点。该路径即cluster_dir变量指向的集群配置目录kubeasz 安装后的默认根路径为/etc/kubeasz对应 ansible.cfg 中的roles_path /etc/kubeasz/roles部署布局。第二步模拟误删除并验证备份有效性备份完成后可以在测试集群中模拟误删除操作如删除业务命名空间、误删某个 Deployment确认集群确实受损后再进入恢复流程验证快照能否完整还原。这一步是整个演练中验证备份是否可用的关键切忌跳过——只有真正执行过恢复演练的备份才是可信的容灾资产。第三步从快照恢复集群恢复操作通过ezctl restore触发等效手动命令为$ ezctl restore k8s-01 # 或手动执行 # ansible-playbook -i clusters/k8s-01/hosts -e clusters/k8s-01/config.yml playbooks/95.restore.yml指定恢复版本恢复使用哪个快照文件由 roles/cluster-restore/defaults/main.yml 中的db_to_restore变量决定# 指定需要恢复的 etcd 数据备份默认使用最近的一次备份 # 在ansible 控制端查看备份目录/etc/kubeasz/clusters/_cluster_name_/backup db_to_restore: snapshot.db默认取snapshot.db最近一次备份如需回滚到历史时点可将其改为备份目录中的具体文件名例如snapshot_202106201205.db。恢复 playbook 的完整执行时序95.restore.yml 通过多段 play 严格编排了先停、再恢复、后启的顺序保证恢复期间不会有任何组件向 etcd 写入或读取半成品数据停止 master 控制面组件在kube_master组上依次停止kube-apiserver、kube-controller-manager、kube-scheduler停止节点组件在kube_master与kube_node组上依次停止kubelet、kube-proxy执行 etcd 数据恢复对etcd组执行cluster-restore角色重启 master 控制面组件按同样顺序启动三个 master 服务并设置enabledyes开机自启重启节点组件在 master 与 node 组上启动kubelet、kube-proxy。cluster-restore 角色内部的恢复实现roles/cluster-restore/tasks/main.yml 是恢复动作的核心逐任务执行如下停止 etcd 服务service: nameetcd statestopped清除 etcd 数据目录删除{{ ETCD_DATA_DIR }}/member目录仅清 member 数据保留目录本身清理并重建临时恢复目录/etcd_backup拷贝指定备份将{{ cluster_dir }}/backup/{{ db_to_restore }}复制为/etcd_backup/snapshot.dbetcdutl 快照还原关键命令如下cd /etcd_backup \ ETCDCTL_API3 {{ bin_dir }}/etcdutl snapshot restore snapshot.db \ --name etcd-{{ inventory_hostname }} \ --initial-cluster {{ ETCD_NODES }} \ --initial-cluster-token etcd-cluster-0 \ --initial-advertise-peer-urls https://{{ inventory_hostname }}:2380这里值得注意的细节是备份使用etcdctl snapshot save恢复使用etcdutl snapshot restore二者职责分离etcdutl 面向数据管理场景。--initial-cluster与--initial-cluster-token etcd-cluster-0必须与集群部署时 etcd systemd unit 中的配置完全一致才能让还原出的各成员重新组成同一个集群——这些参数由 cluster-restore/defaults/main.yml 中的ETCD_NODES根据 inventory 的 etcd 组自动生成TMP_NODES: {% for h in groups[etcd] %}etcd-{{ h }}https://{{ h }}:2380,{% endfor %} ETCD_NODES: {{ TMP_NODES.rstrip(,) }}对照正常部署时 etcd.service.j2 模板中的--initial-cluster{{ ETCD_NODES }}与--initial-cluster-tokenetcd-cluster-0可以看到恢复参数与初始部署参数完全对应这正是还原后集群成员关系正确的保证数据落位将还原产物cp -rf /etcd_backup/etcd-{{ inventory_hostname }}.etcd/member {{ ETCD_DATA_DIR }}/复制回 etcd 数据目录重启 etcd 服务service: nameetcd staterestarted轮询等待同步完成循环执行systemctl is-active etcd.service直到输出包含activeretries: 8, delay: 8最长约 64 秒。恢复后的状态观察恢复 playbook 全部执行完毕后etcd 数据已回滚到备份时点但工作负载对象需要时间重建。此时应等待 Pod/Service 等资源被重新调度并进入就绪状态再通过kubectl get pods -A、kubectl get deploy -A等命令核对数据是否与备份时点一致。由于恢复的是 etcd 整体状态备份之后新建的、未被持久化的对象会丢失这是基于快照的恢复方案的固有语义规划恢复点RPO时需要纳入考量。灾难场景组件不可恢复时的完整重建流程如果集群主要组件master/etcd/node出现不可恢复的故障如系统盘损坏、机器报废、机房事故仅靠restore无法修复——因为restore假定运行环境仍然可用。此时需要走清理 → 创建 → 恢复三段式流程$ ezctl clean k8s-01 # 或手动执行 # ansible-playbook -i clusters/k8s-01/hosts -e clusters/k8s-01/config.yml playbooks/99.clean.yml $ ezctl setup k8s-01 01 $ ezctl setup k8s-01 02 $ ezctl setup k8s-01 03 $ ezctl setup k8s-01 04 $ ezctl setup k8s-01 05 ... $ ezctl restore k8s-01 # ansible-playbook -i clusters/k8s-01/hosts -e clusters/k8s-01/config.yml playbooks/95.restore.yml各步骤含义如下清理ezctl clean k8s-01调度 99.clean.yml清理节点上的 etcd、master、node、LB 等残留组件与数据使环境回到未部署的干净状态注意清理动作不会删除clusters/k8s-01/backup/中的备份文件这是容灾重建的前提——备份目录应独立于集群运行环境妥善保存创建ezctl setup k8s-01 NN按阶段重建集群0105 分别对应 01.prepare.yml系统准备、02.etcd.ymletcd 集群、03.runtime.yml容器运行时、04.kube-master.yml控制面、05.kube-node.yml工作节点等步骤06/07 为网络插件与集群插件可视需要补齐。重建时 etcd 以CLUSTER_STATE: new见 etcd defaults全新初始化生成一套空的状态存储恢复ezctl restore k8s-01再基于备份快照将新 etcd 覆盖为备份时点状态从而在全新环境上还原出完整业务集群。这条路径本质上回答了机器全毁、只有备份文件幸存的极端场景是备份方案真正闭环的最后一环。备份恢复方案设计要点与运维建议结合 kubeasz 的 playbook 实现可归纳出以下设计要点证书是访问 etcd 的唯一凭据备份与恢复全程依赖ca.pem / etcd.pem / etcd-key.pem完成 TLS 认证。这些证书同时用于部署时 etcd 成员间通信etcd.service.j2 中的--peer-cert-file、--trusted-ca-file等备份恢复后无需重新签发——集群身份没有变化数据目录与 WAL 分离etcd 服务模板中配置了--data-dir{{ ETCD_DATA_DIR }}与--wal-dir{{ ETCD_WAL_DIR }}恢复任务只重建member数据并依赖 etcd 自行恢复 WAL因此在生产环境为数据与 WAL 分配独立磁盘或至少独立挂载点能显著提升恢复可靠性快照不是实时复制ezctl backup是手动触发的点对点快照两次备份之间的数据变更只存在于运行中的 etcd 内。对关键业务集群应通过 cron 周期性执行ezctl backup或直接调度 94.backup.yml并定期将/etc/kubeasz/clusters/集群名/backup/目录同步到异地存储演练优先于灾备快照只有经过真实恢复验证才是可信的。建议按部署测试集群 → 注入业务数据 → 备份 → 误删 → 恢复 → 比对数据的闭环定期演练确保ezctl restore的每一步停服务顺序、etcdutl 参数、轮询等待在团队中都形成肌肉记忆手动命令与 ezctl 等价所有备份、恢复、清理、重建操作均有对应的 ansible-playbook 手动命令二者行为完全一致便于在 CI/CD 或自定义脚本中按需编排。kubeasz 的这套方案以 etcd 快照为唯一数据源通过两个精简 playbook 覆盖日常备份、时点恢复、灾难重建三类场景是理解 Kubernetes 控制面数据持久化与容灾设计的一条清晰的实践路径。相关实现细节可继续查阅 备份 playbook、恢复 playbook、cluster-restore 角色 与 etcd 服务模板。【免费下载链接】kubeasz使用Ansible脚本安装K8S集群介绍组件交互原理方便直接不受国内网络环境影响项目地址: https://gitcode.com/GitHub_Trending/ku/kubeasz创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
Kubeasz 集群备份与恢复实战：基于 etcd 快照的完整容灾方案
Kubeasz 集群备份与恢复实战基于 etcd 快照的完整容灾方案【免费下载链接】kubeasz使用Ansible脚本安装K8S集群介绍组件交互原理方便直接不受国内网络环境影响项目地址: https://gitcode.com/GitHub_Trending/ku/kubeaszkubeasz 使用 Ansible 脚本部署 Kubernetes 集群其备份与恢复能力围绕 etcd 集群状态快照展开ezctl backup将运行中的 etcd 数据导出为磁盘快照文件ezctl restore基于快照将集群恢复到备份时点状态。本文以 kubeasz 仓库中 cluster_restore.md 操作文档为主线结合 94.backup.yml、95.restore.yml 两个 playbook 与 cluster-restore 角色的源码实现完整讲解备份、恢复与灾难重建三条实战路径读完后可独立为 kubeasz 部署的集群建立可验证的备份与容灾流程。为什么集群备份与恢复的重点是 etcdKubernetes 集群采用多主多节点的高可用部署后计算节点故障可以通过重新调度自愈但集群的状态本身需要持久化保护。etcd 作为 Kubernetes 唯一的状态存储保存了全部 API 对象的最终一致数据——包括 Deployment、Service、ConfigMap、RBAC 规则、Pod 调度结果等。一旦 etcd 数据丢失或损坏即便所有 master/node 节点进程健康集群也会退化为有计算能力、无状态认知的空壳。因此 kubeasz 的备份与恢复方案核心只有两条备份从运行中的 etcd 集群导出快照数据到磁盘文件恢复从 etcd 快照文件恢复数据使集群回到备份时点状态。这一设计在 kubeasz 中由两个独立 playbook 支撑备份走playbooks/94.backup.yml恢复走playbooks/95.restore.yml并统一封装为ezctl backup/restore 集群名命令见 ezctl 脚本中 backup/restore 与两个 playbook 的映射关系。第一步搭建测试集群并执行备份操作文档建议先搭建一个测试集群部署若干测试 Deployment 验证各项功能正常后再进行首次备份下文以集群名k8s-01为例。$ ezctl backup k8s-01如果希望跳过 ezctl 封装直接调用 Ansible等效命令为$ ansible-playbook -i clusters/k8s-01/hosts -e clusters/k8s-01/config.yml playbooks/94.backup.yml备份 playbook 的源码执行逻辑ezctl backup实际调度的是 94.backup.yml该 playbook 在localhostAnsible 控制端执行包含两个关键步骤步骤一探测 etcd 集群中健康节点。遍历 inventory 中etcd组的所有节点使用 v3 API 逐一执行endpoint health健康检查ETCDCTL_API3 {{ base_dir }}/bin/etcdctl \ --endpointshttps://$ip:2379 \ --cacert{{ cluster_dir }}/ssl/ca.pem \ --cert{{ cluster_dir }}/ssl/etcd.pem \ --key{{ cluster_dir }}/ssl/etcd-key.pem \ endpoint health随后从输出中 grepis healthy关键字解析出第一个健康节点的地址作为快照数据源RUNNING_NODE.stdout。这一步保证了备份操作在任一 etcd 成员故障时依然可以从存活成员取数提高了备份的鲁棒性。健康检查与快照均通过 TLS 认证访问证书即集群部署时生成的ca.pem、etcd.pem、etcd-key.pem与 etcd role 证书分发 中ca_dir下证书一致。步骤二执行 etcd 快照备份。以当前时间戳命名快照文件mkdir -p {{ cluster_dir }}/backup cd {{ cluster_dir }}/backup \ ETCDCTL_API3 {{ base_dir }}/bin/etcdctl \ --endpointshttps://{{ RUNNING_NODE.stdout }}:2379 \ --cacert{{ cluster_dir }}/ssl/ca.pem \ --cert{{ cluster_dir }}/ssl/etcd.pem \ --key{{ cluster_dir }}/ssl/etcd-key.pem \ snapshot save snapshot_{{ timestamp.stdout }}.db备份完成后playbook 会将本次快照复制为固定文件名snapshot.db作为最近一次备份的稳定入口cd {{ cluster_dir }}/backup/ /bin/cp -f snapshot_{{ timestamp.stdout }}.db snapshot.db备份产物与目录结构备份文件统一存放在部署主机Ansible 控制端上对应集群的 backup 目录中/etc/kubeasz/clusters/k8s-01/backup/ ├── snapshot_202106201205.db ├── snapshot_202106211406.db └── snapshot.db其中snapshot.db始终指向最近一次备份文件带时间戳的历史快照则按日期累计留存便于回溯多个恢复点。该路径即cluster_dir变量指向的集群配置目录kubeasz 安装后的默认根路径为/etc/kubeasz对应 ansible.cfg 中的roles_path /etc/kubeasz/roles部署布局。第二步模拟误删除并验证备份有效性备份完成后可以在测试集群中模拟误删除操作如删除业务命名空间、误删某个 Deployment确认集群确实受损后再进入恢复流程验证快照能否完整还原。这一步是整个演练中验证备份是否可用的关键切忌跳过——只有真正执行过恢复演练的备份才是可信的容灾资产。第三步从快照恢复集群恢复操作通过ezctl restore触发等效手动命令为$ ezctl restore k8s-01 # 或手动执行 # ansible-playbook -i clusters/k8s-01/hosts -e clusters/k8s-01/config.yml playbooks/95.restore.yml指定恢复版本恢复使用哪个快照文件由 roles/cluster-restore/defaults/main.yml 中的db_to_restore变量决定# 指定需要恢复的 etcd 数据备份默认使用最近的一次备份 # 在ansible 控制端查看备份目录/etc/kubeasz/clusters/_cluster_name_/backup db_to_restore: snapshot.db默认取snapshot.db最近一次备份如需回滚到历史时点可将其改为备份目录中的具体文件名例如snapshot_202106201205.db。恢复 playbook 的完整执行时序95.restore.yml 通过多段 play 严格编排了先停、再恢复、后启的顺序保证恢复期间不会有任何组件向 etcd 写入或读取半成品数据停止 master 控制面组件在kube_master组上依次停止kube-apiserver、kube-controller-manager、kube-scheduler停止节点组件在kube_master与kube_node组上依次停止kubelet、kube-proxy执行 etcd 数据恢复对etcd组执行cluster-restore角色重启 master 控制面组件按同样顺序启动三个 master 服务并设置enabledyes开机自启重启节点组件在 master 与 node 组上启动kubelet、kube-proxy。cluster-restore 角色内部的恢复实现roles/cluster-restore/tasks/main.yml 是恢复动作的核心逐任务执行如下停止 etcd 服务service: nameetcd statestopped清除 etcd 数据目录删除{{ ETCD_DATA_DIR }}/member目录仅清 member 数据保留目录本身清理并重建临时恢复目录/etcd_backup拷贝指定备份将{{ cluster_dir }}/backup/{{ db_to_restore }}复制为/etcd_backup/snapshot.dbetcdutl 快照还原关键命令如下cd /etcd_backup \ ETCDCTL_API3 {{ bin_dir }}/etcdutl snapshot restore snapshot.db \ --name etcd-{{ inventory_hostname }} \ --initial-cluster {{ ETCD_NODES }} \ --initial-cluster-token etcd-cluster-0 \ --initial-advertise-peer-urls https://{{ inventory_hostname }}:2380这里值得注意的细节是备份使用etcdctl snapshot save恢复使用etcdutl snapshot restore二者职责分离etcdutl 面向数据管理场景。--initial-cluster与--initial-cluster-token etcd-cluster-0必须与集群部署时 etcd systemd unit 中的配置完全一致才能让还原出的各成员重新组成同一个集群——这些参数由 cluster-restore/defaults/main.yml 中的ETCD_NODES根据 inventory 的 etcd 组自动生成TMP_NODES: {% for h in groups[etcd] %}etcd-{{ h }}https://{{ h }}:2380,{% endfor %} ETCD_NODES: {{ TMP_NODES.rstrip(,) }}对照正常部署时 etcd.service.j2 模板中的--initial-cluster{{ ETCD_NODES }}与--initial-cluster-tokenetcd-cluster-0可以看到恢复参数与初始部署参数完全对应这正是还原后集群成员关系正确的保证数据落位将还原产物cp -rf /etcd_backup/etcd-{{ inventory_hostname }}.etcd/member {{ ETCD_DATA_DIR }}/复制回 etcd 数据目录重启 etcd 服务service: nameetcd staterestarted轮询等待同步完成循环执行systemctl is-active etcd.service直到输出包含activeretries: 8, delay: 8最长约 64 秒。恢复后的状态观察恢复 playbook 全部执行完毕后etcd 数据已回滚到备份时点但工作负载对象需要时间重建。此时应等待 Pod/Service 等资源被重新调度并进入就绪状态再通过kubectl get pods -A、kubectl get deploy -A等命令核对数据是否与备份时点一致。由于恢复的是 etcd 整体状态备份之后新建的、未被持久化的对象会丢失这是基于快照的恢复方案的固有语义规划恢复点RPO时需要纳入考量。灾难场景组件不可恢复时的完整重建流程如果集群主要组件master/etcd/node出现不可恢复的故障如系统盘损坏、机器报废、机房事故仅靠restore无法修复——因为restore假定运行环境仍然可用。此时需要走清理 → 创建 → 恢复三段式流程$ ezctl clean k8s-01 # 或手动执行 # ansible-playbook -i clusters/k8s-01/hosts -e clusters/k8s-01/config.yml playbooks/99.clean.yml $ ezctl setup k8s-01 01 $ ezctl setup k8s-01 02 $ ezctl setup k8s-01 03 $ ezctl setup k8s-01 04 $ ezctl setup k8s-01 05 ... $ ezctl restore k8s-01 # ansible-playbook -i clusters/k8s-01/hosts -e clusters/k8s-01/config.yml playbooks/95.restore.yml各步骤含义如下清理ezctl clean k8s-01调度 99.clean.yml清理节点上的 etcd、master、node、LB 等残留组件与数据使环境回到未部署的干净状态注意清理动作不会删除clusters/k8s-01/backup/中的备份文件这是容灾重建的前提——备份目录应独立于集群运行环境妥善保存创建ezctl setup k8s-01 NN按阶段重建集群0105 分别对应 01.prepare.yml系统准备、02.etcd.ymletcd 集群、03.runtime.yml容器运行时、04.kube-master.yml控制面、05.kube-node.yml工作节点等步骤06/07 为网络插件与集群插件可视需要补齐。重建时 etcd 以CLUSTER_STATE: new见 etcd defaults全新初始化生成一套空的状态存储恢复ezctl restore k8s-01再基于备份快照将新 etcd 覆盖为备份时点状态从而在全新环境上还原出完整业务集群。这条路径本质上回答了机器全毁、只有备份文件幸存的极端场景是备份方案真正闭环的最后一环。备份恢复方案设计要点与运维建议结合 kubeasz 的 playbook 实现可归纳出以下设计要点证书是访问 etcd 的唯一凭据备份与恢复全程依赖ca.pem / etcd.pem / etcd-key.pem完成 TLS 认证。这些证书同时用于部署时 etcd 成员间通信etcd.service.j2 中的--peer-cert-file、--trusted-ca-file等备份恢复后无需重新签发——集群身份没有变化数据目录与 WAL 分离etcd 服务模板中配置了--data-dir{{ ETCD_DATA_DIR }}与--wal-dir{{ ETCD_WAL_DIR }}恢复任务只重建member数据并依赖 etcd 自行恢复 WAL因此在生产环境为数据与 WAL 分配独立磁盘或至少独立挂载点能显著提升恢复可靠性快照不是实时复制ezctl backup是手动触发的点对点快照两次备份之间的数据变更只存在于运行中的 etcd 内。对关键业务集群应通过 cron 周期性执行ezctl backup或直接调度 94.backup.yml并定期将/etc/kubeasz/clusters/集群名/backup/目录同步到异地存储演练优先于灾备快照只有经过真实恢复验证才是可信的。建议按部署测试集群 → 注入业务数据 → 备份 → 误删 → 恢复 → 比对数据的闭环定期演练确保ezctl restore的每一步停服务顺序、etcdutl 参数、轮询等待在团队中都形成肌肉记忆手动命令与 ezctl 等价所有备份、恢复、清理、重建操作均有对应的 ansible-playbook 手动命令二者行为完全一致便于在 CI/CD 或自定义脚本中按需编排。kubeasz 的这套方案以 etcd 快照为唯一数据源通过两个精简 playbook 覆盖日常备份、时点恢复、灾难重建三类场景是理解 Kubernetes 控制面数据持久化与容灾设计的一条清晰的实践路径。相关实现细节可继续查阅 备份 playbook、恢复 playbook、cluster-restore 角色 与 etcd 服务模板。【免费下载链接】kubeasz使用Ansible脚本安装K8S集群介绍组件交互原理方便直接不受国内网络环境影响项目地址: https://gitcode.com/GitHub_Trending/ku/kubeasz创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考