拓冰网站定制 
文档/教程【免费下载链接】90DaysOfDevOpsThis repository started out as a learning in public project for myself and has now become a structured learning map for many in the community. We have 3 years under our belt covering all things DevOps, including Principles, Processes, Tooling and Use Cases surrounding this vast topic.项目地址https://gitcode.com/gh_mirrors/90/90DaysOfDevOps点击查看免费下载本文是 #90DaysOfDevOps 挑战第 90 天的技术复盘聚焦于一个真实场景在把 Kubernetes 工作负载从主集群迁移到灾备Disaster Recovery集群的过程中如何在恢复的同时改造目标端应用——更换存储类StorageClass与调整副本数。阅读完本文你将掌握 Kasten K10 的恢复时转换Restore-time Transformations完整操作流程、其背后的 Kubernetes 资源机制以及如何通过 Kubernetes API 将迁移任务自动化。为什么需要数据与应用移动性数据与应用移动性Data Application Mobility指的是把工作负载、应用及其数据从一个位置移动到另一个位置的能力。这个需求在 Kubernetes 生态中正变得越来越普遍它既存在于同一平台内部也存在于不同平台之间。驱动这种移动的原因多种多样成本优化、风险规避或者为业务提供更好的服务。本文讨论的场景正是如此我们不只要把一套 Kubernetes 工作负载从 A 集群搬到 B 集群还要在搬到目标位置的过程中改变应用在目标端的形态——这正是 Kasten K10 恢复时转换能力的核心价值也是它与普通备份-恢复的本质区别。这套流程大量复用了第 89 天灾难恢复Recuperación de desastres所建立的基础设施与机制对象存储中的备份数据、待命standby集群上的 K10 部署、导入策略Import Policy等。可以说移动性是灾备能力的自然延伸——灾备保证数据在别处可恢复移动性则进一步保证恢复的同时还能按需重塑应用。迁移场景需求拆解业务动机假设我们面临如下业务决策当前 Kubernetes 集群已经无法应对业务需求容量瓶颈且成本快速攀升企业决定把生产 Kubernetes 集群迁移到位于另一朵公有云上的灾备位置——那里既能提供扩展空间成本也更低还能利用目标云的原生服务。应用拓扑与迁移目标当前的关键业务应用是Pac-Man其技术栈在仓库中可见于 pacman-stateful-demo.yaml前端NodeJS 编写的 Pac-Man Web 界面由Deployment管理replicas: 1镜像为quay.io/ifont/pacman-nodejs-app:latest通过 Servicetype: LoadBalancerport: 80 - targetPort: 8080对外暴露后端数据库MongoDBbitnami/mongodb:4.4.8由StatefulSet管理replicas: 1数据落在mongo-storage这个PersistentVolumeClaim1Gi、ReadWriteOnce上敏感配置数据库账号密码通过mongodb-users-secretOpaque Secret注入环境变量前端通过MONGO_SERVICE_HOSTmongo等环境变量访问数据库。基于此迁移有两个明确诉求存储升级当前应用运行在较慢的存储层主集群使用csi-hostpath-sc存储类希望迁到目标集群后使用更快、更新的存储层级standard存储类前端扩容当前 Pac-Man 前端NodeJS扩展性不佳希望在目标位置把 Pod 数量从 1 提升到 5。在原文2022/es/Days/day90.md中这两条需求通过 Kasten K10 的恢复时转换在一次恢复操作中同时完成。前置条件一套可用的备份与待命集群要执行带转换的恢复首先需要具备两个前提详细过程在 Día 89 中已完整演练主集群上的备份策略已导出到对象存储在 K10 中创建策略Policy启用通过快照导出进行备份Export via Snapshot将 Pac-Man 应用的备份含 MongoDB 数据推送到 S3 兼容的对象存储并记录下导入详情Import Details字符串供待命集群使用待命集群已就绪使用不同名称创建第二个 minikube 集群并同样安装 K10minikube start --addons volumesnapshots,csi-hostpath-driver --apiserver-port6443 --container-runtimecontainerd -p standby --kubernetes-version1.21.2 helm install k10 kasten/k10 --namespacekasten-io --set auth.tokenAuth.enabledtrue --set injectKanisterSidecar.enabledtrue --set-string injectKanisterSidecar.namespaceSelector.matchLabels.k10/injectKanisterSidecartrue --create-namespace安装完成后在待命集群中创建导入策略Import Policy把对象存储中的备份导入进来即可在 Applications 面板中看到 Pac-Man 的恢复点Restore Point。第一步清理待命集群上的灾备恢复现场在 Día 89 中我们曾把 Pac-Man 恢复到待命集群以验证灾备能力。现在要正式迁移首先需要移除上一次灾备测试的恢复结果为新的迁移恢复腾出命名空间kubectl delete ns pacman在名为standby的 minikube 集群中执行上述命令pacman命名空间及其中的 Pod、PVC 等资源会被整体删除——但对象存储中的备份数据不受影响这正是外部备份的价值所在。第二步从 Kasten K10 选择恢复点清理完成后进入 Kasten K10 控制台Dashboard点击Applications应用卡片在应用列表右上方的下拉菜单中选择Removed已删除——这是 K10 用来标识已被删除、但仍有恢复点可用的应用状态的筛选项此时会列出该应用可用的恢复点Restore Points。选择包含我们关键数据的那一个本示例中只有一个恢复点因为它来自一次备份作业的导出。选中恢复点后K10 会进入恢复向导展示各类恢复选项。在 Día 89 的灾备演示中我们全部使用默认值直接恢复而这次我们需要利用恢复向导中的额外选项来完成应用的变身。第三步理解并配置恢复时转换启用转换选项在恢复向导中勾选Apply transforms to restored resources对恢复的资源应用转换。这一选项的意义在于K10 在把备份数据恢复到目标集群时不再原样重建资源而是允许在恢复前改写被恢复资源的 spec——例如修改 StorageClass、调整副本数、更换容器镜像名等非常适合环境迁移这类需要适配目标环境的场景。内置转换示例K10 控制台在新建转换New Transform中内置了两个高频示例见下图恰好覆盖我们本次的全部需求Change storageClass修改存储类——用于切换存储层级或可用区Scale Deployment扩缩 Deployment 的副本数量。转换一更换 StorageClasscsi-hostpath-sc → standard第一个需求是存储升级。在主集群上Pac-Man 的 PVC 绑定的是 CSI hostpath 驱动提供的csi-hostpath-sc存储类这正是 Día 55/Día 87 中 minikube 集群默认配置的存储类。在目标集群上我们希望使用standard存储类。在转换配置界面中选择 Change storageClass 示例将源存储类设置为csi-hostpath-sc、目标存储类设置为standard确认无误后点击底部的Create Transform创建转换按钮。从实现原理上看这条转换会在恢复时改写被恢复 PVC 的spec.storageClassName字段。Kubernetes 的StorageClass是动态供给Dynamic Provisioning的抽象层每个存储后端都有一个 provisioner如 CSI driverPVC 通过storageClassName声明自己需要哪类存储调度器据此创建对应后端类型的 PV。因此把csi-hostpath-sc换成standard本质上是把数据卷重新供给到另一类存储后端上——这也解释了为什么目标集群需要提前具备名为standard的存储类minikube 默认即提供。转换二扩缩 Deployment1 → 5第二个需求是前端扩容。在 pacman-stateful-demo.yaml 中Pac-Man 前端 Deployment 的spec.replicas初始为 1我们希望恢复后目标集群上运行 5 个前端 Pod。在转换配置界面中选择 Scale Deployment 示例指定目标 DeploymentPac-Man 前端并将其副本数设为5创建该转换。完成两个转换后恢复向导中应能看到两条转换记录changeStorageClass与scaleDeployment如 Día 90 截图 所示每条记录都支持复制、编辑与删除第四步执行带转换的恢复转换配置完成后恢复向导会列出本次将恢复的所有工件Artefacts——包括命名空间、Deployment、StatefulSet、Service、PVC、Secret 等。K10 默认恢复应用的全部资源如果希望更精细化也可以只勾选部分工件。点击Restore恢复按钮后K10 会弹出确认对话框要求再次确认恢复动作这是一个防误操作的二次确认机制同样出现在 Día 89 的恢复流程中。确认后K10 将按以下逻辑执行从对象存储拉取备份数据含 MongoDB 数据重建应用的全部 Kubernetes 资源在重建过程中应用两条转换为新 PVC 绑定standard存储类、将前端 Deployment 扩容到 5 个副本。第五步验证目标集群恢复完成后回到终端查看待命集群的状态kubectl get pods -n pacman kubectl get pvc -n pacman从 Día 90 的终端截图 可以看到迁移结果pacman命名空间下MongoDB 的mongo-0PodStatefulSet运行正常Pac-Man 前端 Pod 已从 1 个扩展为5 个且全部处于 Running/Ready 状态PVCmongo-storage状态为 Bound其 StorageClass 已显示为standard不再是源端的csi-hostpath-sc。两条需求在一次恢复操作中同时达成数据完好MongoDB 卷已重建并绑定新存储类应用拓扑按目标环境重塑前端 5 副本。转换能力的更多应用场景恢复时转换的价值远不止本次迁移演示。同一机制还可以覆盖灾难恢复在待命站点恢复时按待命环境调整资源配置如降副本数、换存储类以节省成本测试与开发从生产备份恢复出开发/测试环境时自动注入不同的镜像 Tag、不同的配置或更小的资源规格多环境漂移治理同一份备份在不同环境本地、云、OpenShift恢复时自动适配各自的基础设施差异存储类、Ingress 类、镜像仓库地址等业务连续性的其他形态克隆、环境拆分、合规性演练等。从仓库中 Día 55Kubernetes 状态与 Ingress对 StorageClass/StatefulSet 的讲解可以看出这些转换点存储类、副本数恰恰是 Kubernetes 应用在不同环境间差异最大的部分——csi-hostpath-sc是本地 minikube 环境特有的存储类而standard是云环境常见的默认存储类。转换机制正是针对这些差异点做恢复即适配。通过 Kubernetes API 自动化K10 的移动性流程同样可以自动化。关于这一点原文明确指出Kasten K10 的一个重要特性是部署时它运行在 Kubernetes 集群内部kasten-io命名空间因此可以通过 Kubernetes API 直接调用。这意味着备份策略、导入策略、恢复、转换等操作都可以通过 K10 暴露的 Kubernetes API 资源如 Policy、Restore、Transform 等 CRD以声明式方式驱动K10 控制台Dashboard的界面中许多操作会提供对应的命令片段breadcrumb / 命令集可以直接复制用于脚本与 CI/CD 流水线结合 GitOps 实践可以把创建备份策略在待命集群导入备份带转换恢复等步骤写成清单文件随集群一起版本化。这也与 Día 88 中 Kanister应用级一致性备份 的设计哲学一脉相承备份与恢复动作均由 Kubernetes 自定义资源Blueprint、ActionSet 等描述天然可审计、可版本化、可自动化。延伸阅读与仓库证据本次迁移演示依赖的完整链条都可以在仓库中逐篇追溯Día 87Kubernetes 备份与恢复实战——minikube 集群的volumesnapshots、csi-hostpath-driver插件启用csi-hostpath-sc与standard存储类的默认类切换命令以及 K10 的 Helm 部署与 Token 认证方式Día 88应用级一致性备份Kanister——Blueprint/ActionSet/Profile 三类自定义资源以及备份-破坏-恢复的完整演练对应 K10 中应用一致备份的高级选项Día 89灾难恢复——对象存储 Profile 配置、备份策略创建、待命集群standby创建、导入策略与恢复是本文的直接前置Pac-Man 有状态应用清单——本次被迁移的 DeploymentPac-Man 前端、StatefulSetMongoDB、PVCmongo-storage与 Secret 的完整定义Día 55Kubernetes 状态与 Ingress——StorageClass、PersistentVolumeClaim、StatefulSet 与 Deployment 差异的基础概念。小结数据与应用移动性Data Application Mobility是 Kubernetes 备份/灾备能力的自然延伸备份解决数据还在不在灾备解决能不能在别处起来而移动性解决起来之后长什么样。本文通过 90DaysOfDevOps 第 90 天的真实演练展示了 Kasten K10 如何让迁移 转换在一次恢复操作中原子完成——把 Pac-Man 从csi-hostpath-sc慢存储迁到standard快存储同时把前端从 1 副本扩展到 5 副本全程无需手工改 YAML、无需停机式的人工重建。这套机制的适用范围远不止集群迁移灾难恢复、测试环境搭建、多云适配都可以复用同一条备份 → 导入 → 转换 → 恢复流水线并通过 Kubernetes API 与既有自动化体系CI/CD、GitOps无缝集成。赞分享文档/教程【免费下载链接】90DaysOfDevOpsThis repository started out as a learning in public project for myself and has now become a structured learning map for many in the community. We have 3 years under our belt covering all things DevOps, including Principles, Processes, Tooling and Use Cases surrounding this vast topic.项目地址https://gitcode.com/gh_mirrors/90/90DaysOfDevOps点击查看免费下载相关推荐90DaysOfDevOps 第 90 天使用 Kasten K10 实现 Kubernetes 应用与数据迁移Data Application Mobility90DaysOfDevOps 第 90 天使用 Kasten K10 实现 Kubernetes 应用与数据迁移Data Application Mob文档/教程90DaysOfDevOps 实战基于 Kasten K10 与 minikube 的 Kubernetes 跨集群灾难恢复DR90DaysOfDevOps 实战基于 Kasten K10 与 minikube 的 Kubernetes 跨集群灾难恢复DR 本篇技术指南是 90Da文档/教程90DaysOfDevOps 实战使用 Kasten K10 在 Kubernetes 中完成有状态应用的备份与恢复90DaysOfDevOps 实战使用 Kasten K10 在 Kubernetes 中完成有状态应用的备份与恢复 本篇技术指南来自 90DaysOfDev文档/教程上一篇3分钟掌握ncmdump终极免费方案解决网易云音乐NCM格式播放限制下一篇终极指南3分钟免费解锁网易云音乐NCM格式让音乐无处不在创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 90DaysOfDevOps 数据与应用移动性：使用 Kasten K10 恢复时转换跨集群迁移 Kubernetes 工作负载
文档/教程【免费下载链接】90DaysOfDevOpsThis repository started out as a learning in public project for myself and has now become a structured learning map for many in the community. We have 3 years under our belt covering all things DevOps, including Principles, Processes, Tooling and Use Cases surrounding this vast topic.项目地址https://gitcode.com/gh_mirrors/90/90DaysOfDevOps点击查看免费下载本文是 #90DaysOfDevOps 挑战第 90 天的技术复盘聚焦于一个真实场景在把 Kubernetes 工作负载从主集群迁移到灾备Disaster Recovery集群的过程中如何在恢复的同时改造目标端应用——更换存储类StorageClass与调整副本数。阅读完本文你将掌握 Kasten K10 的恢复时转换Restore-time Transformations完整操作流程、其背后的 Kubernetes 资源机制以及如何通过 Kubernetes API 将迁移任务自动化。为什么需要数据与应用移动性数据与应用移动性Data Application Mobility指的是把工作负载、应用及其数据从一个位置移动到另一个位置的能力。这个需求在 Kubernetes 生态中正变得越来越普遍它既存在于同一平台内部也存在于不同平台之间。驱动这种移动的原因多种多样成本优化、风险规避或者为业务提供更好的服务。本文讨论的场景正是如此我们不只要把一套 Kubernetes 工作负载从 A 集群搬到 B 集群还要在搬到目标位置的过程中改变应用在目标端的形态——这正是 Kasten K10 恢复时转换能力的核心价值也是它与普通备份-恢复的本质区别。这套流程大量复用了第 89 天灾难恢复Recuperación de desastres所建立的基础设施与机制对象存储中的备份数据、待命standby集群上的 K10 部署、导入策略Import Policy等。可以说移动性是灾备能力的自然延伸——灾备保证数据在别处可恢复移动性则进一步保证恢复的同时还能按需重塑应用。迁移场景需求拆解业务动机假设我们面临如下业务决策当前 Kubernetes 集群已经无法应对业务需求容量瓶颈且成本快速攀升企业决定把生产 Kubernetes 集群迁移到位于另一朵公有云上的灾备位置——那里既能提供扩展空间成本也更低还能利用目标云的原生服务。应用拓扑与迁移目标当前的关键业务应用是Pac-Man其技术栈在仓库中可见于 pacman-stateful-demo.yaml前端NodeJS 编写的 Pac-Man Web 界面由Deployment管理replicas: 1镜像为quay.io/ifont/pacman-nodejs-app:latest通过 Servicetype: LoadBalancerport: 80 - targetPort: 8080对外暴露后端数据库MongoDBbitnami/mongodb:4.4.8由StatefulSet管理replicas: 1数据落在mongo-storage这个PersistentVolumeClaim1Gi、ReadWriteOnce上敏感配置数据库账号密码通过mongodb-users-secretOpaque Secret注入环境变量前端通过MONGO_SERVICE_HOSTmongo等环境变量访问数据库。基于此迁移有两个明确诉求存储升级当前应用运行在较慢的存储层主集群使用csi-hostpath-sc存储类希望迁到目标集群后使用更快、更新的存储层级standard存储类前端扩容当前 Pac-Man 前端NodeJS扩展性不佳希望在目标位置把 Pod 数量从 1 提升到 5。在原文2022/es/Days/day90.md中这两条需求通过 Kasten K10 的恢复时转换在一次恢复操作中同时完成。前置条件一套可用的备份与待命集群要执行带转换的恢复首先需要具备两个前提详细过程在 Día 89 中已完整演练主集群上的备份策略已导出到对象存储在 K10 中创建策略Policy启用通过快照导出进行备份Export via Snapshot将 Pac-Man 应用的备份含 MongoDB 数据推送到 S3 兼容的对象存储并记录下导入详情Import Details字符串供待命集群使用待命集群已就绪使用不同名称创建第二个 minikube 集群并同样安装 K10minikube start --addons volumesnapshots,csi-hostpath-driver --apiserver-port6443 --container-runtimecontainerd -p standby --kubernetes-version1.21.2 helm install k10 kasten/k10 --namespacekasten-io --set auth.tokenAuth.enabledtrue --set injectKanisterSidecar.enabledtrue --set-string injectKanisterSidecar.namespaceSelector.matchLabels.k10/injectKanisterSidecartrue --create-namespace安装完成后在待命集群中创建导入策略Import Policy把对象存储中的备份导入进来即可在 Applications 面板中看到 Pac-Man 的恢复点Restore Point。第一步清理待命集群上的灾备恢复现场在 Día 89 中我们曾把 Pac-Man 恢复到待命集群以验证灾备能力。现在要正式迁移首先需要移除上一次灾备测试的恢复结果为新的迁移恢复腾出命名空间kubectl delete ns pacman在名为standby的 minikube 集群中执行上述命令pacman命名空间及其中的 Pod、PVC 等资源会被整体删除——但对象存储中的备份数据不受影响这正是外部备份的价值所在。第二步从 Kasten K10 选择恢复点清理完成后进入 Kasten K10 控制台Dashboard点击Applications应用卡片在应用列表右上方的下拉菜单中选择Removed已删除——这是 K10 用来标识已被删除、但仍有恢复点可用的应用状态的筛选项此时会列出该应用可用的恢复点Restore Points。选择包含我们关键数据的那一个本示例中只有一个恢复点因为它来自一次备份作业的导出。选中恢复点后K10 会进入恢复向导展示各类恢复选项。在 Día 89 的灾备演示中我们全部使用默认值直接恢复而这次我们需要利用恢复向导中的额外选项来完成应用的变身。第三步理解并配置恢复时转换启用转换选项在恢复向导中勾选Apply transforms to restored resources对恢复的资源应用转换。这一选项的意义在于K10 在把备份数据恢复到目标集群时不再原样重建资源而是允许在恢复前改写被恢复资源的 spec——例如修改 StorageClass、调整副本数、更换容器镜像名等非常适合环境迁移这类需要适配目标环境的场景。内置转换示例K10 控制台在新建转换New Transform中内置了两个高频示例见下图恰好覆盖我们本次的全部需求Change storageClass修改存储类——用于切换存储层级或可用区Scale Deployment扩缩 Deployment 的副本数量。转换一更换 StorageClasscsi-hostpath-sc → standard第一个需求是存储升级。在主集群上Pac-Man 的 PVC 绑定的是 CSI hostpath 驱动提供的csi-hostpath-sc存储类这正是 Día 55/Día 87 中 minikube 集群默认配置的存储类。在目标集群上我们希望使用standard存储类。在转换配置界面中选择 Change storageClass 示例将源存储类设置为csi-hostpath-sc、目标存储类设置为standard确认无误后点击底部的Create Transform创建转换按钮。从实现原理上看这条转换会在恢复时改写被恢复 PVC 的spec.storageClassName字段。Kubernetes 的StorageClass是动态供给Dynamic Provisioning的抽象层每个存储后端都有一个 provisioner如 CSI driverPVC 通过storageClassName声明自己需要哪类存储调度器据此创建对应后端类型的 PV。因此把csi-hostpath-sc换成standard本质上是把数据卷重新供给到另一类存储后端上——这也解释了为什么目标集群需要提前具备名为standard的存储类minikube 默认即提供。转换二扩缩 Deployment1 → 5第二个需求是前端扩容。在 pacman-stateful-demo.yaml 中Pac-Man 前端 Deployment 的spec.replicas初始为 1我们希望恢复后目标集群上运行 5 个前端 Pod。在转换配置界面中选择 Scale Deployment 示例指定目标 DeploymentPac-Man 前端并将其副本数设为5创建该转换。完成两个转换后恢复向导中应能看到两条转换记录changeStorageClass与scaleDeployment如 Día 90 截图 所示每条记录都支持复制、编辑与删除第四步执行带转换的恢复转换配置完成后恢复向导会列出本次将恢复的所有工件Artefacts——包括命名空间、Deployment、StatefulSet、Service、PVC、Secret 等。K10 默认恢复应用的全部资源如果希望更精细化也可以只勾选部分工件。点击Restore恢复按钮后K10 会弹出确认对话框要求再次确认恢复动作这是一个防误操作的二次确认机制同样出现在 Día 89 的恢复流程中。确认后K10 将按以下逻辑执行从对象存储拉取备份数据含 MongoDB 数据重建应用的全部 Kubernetes 资源在重建过程中应用两条转换为新 PVC 绑定standard存储类、将前端 Deployment 扩容到 5 个副本。第五步验证目标集群恢复完成后回到终端查看待命集群的状态kubectl get pods -n pacman kubectl get pvc -n pacman从 Día 90 的终端截图 可以看到迁移结果pacman命名空间下MongoDB 的mongo-0PodStatefulSet运行正常Pac-Man 前端 Pod 已从 1 个扩展为5 个且全部处于 Running/Ready 状态PVCmongo-storage状态为 Bound其 StorageClass 已显示为standard不再是源端的csi-hostpath-sc。两条需求在一次恢复操作中同时达成数据完好MongoDB 卷已重建并绑定新存储类应用拓扑按目标环境重塑前端 5 副本。转换能力的更多应用场景恢复时转换的价值远不止本次迁移演示。同一机制还可以覆盖灾难恢复在待命站点恢复时按待命环境调整资源配置如降副本数、换存储类以节省成本测试与开发从生产备份恢复出开发/测试环境时自动注入不同的镜像 Tag、不同的配置或更小的资源规格多环境漂移治理同一份备份在不同环境本地、云、OpenShift恢复时自动适配各自的基础设施差异存储类、Ingress 类、镜像仓库地址等业务连续性的其他形态克隆、环境拆分、合规性演练等。从仓库中 Día 55Kubernetes 状态与 Ingress对 StorageClass/StatefulSet 的讲解可以看出这些转换点存储类、副本数恰恰是 Kubernetes 应用在不同环境间差异最大的部分——csi-hostpath-sc是本地 minikube 环境特有的存储类而standard是云环境常见的默认存储类。转换机制正是针对这些差异点做恢复即适配。通过 Kubernetes API 自动化K10 的移动性流程同样可以自动化。关于这一点原文明确指出Kasten K10 的一个重要特性是部署时它运行在 Kubernetes 集群内部kasten-io命名空间因此可以通过 Kubernetes API 直接调用。这意味着备份策略、导入策略、恢复、转换等操作都可以通过 K10 暴露的 Kubernetes API 资源如 Policy、Restore、Transform 等 CRD以声明式方式驱动K10 控制台Dashboard的界面中许多操作会提供对应的命令片段breadcrumb / 命令集可以直接复制用于脚本与 CI/CD 流水线结合 GitOps 实践可以把创建备份策略在待命集群导入备份带转换恢复等步骤写成清单文件随集群一起版本化。这也与 Día 88 中 Kanister应用级一致性备份 的设计哲学一脉相承备份与恢复动作均由 Kubernetes 自定义资源Blueprint、ActionSet 等描述天然可审计、可版本化、可自动化。延伸阅读与仓库证据本次迁移演示依赖的完整链条都可以在仓库中逐篇追溯Día 87Kubernetes 备份与恢复实战——minikube 集群的volumesnapshots、csi-hostpath-driver插件启用csi-hostpath-sc与standard存储类的默认类切换命令以及 K10 的 Helm 部署与 Token 认证方式Día 88应用级一致性备份Kanister——Blueprint/ActionSet/Profile 三类自定义资源以及备份-破坏-恢复的完整演练对应 K10 中应用一致备份的高级选项Día 89灾难恢复——对象存储 Profile 配置、备份策略创建、待命集群standby创建、导入策略与恢复是本文的直接前置Pac-Man 有状态应用清单——本次被迁移的 DeploymentPac-Man 前端、StatefulSetMongoDB、PVCmongo-storage与 Secret 的完整定义Día 55Kubernetes 状态与 Ingress——StorageClass、PersistentVolumeClaim、StatefulSet 与 Deployment 差异的基础概念。小结数据与应用移动性Data Application Mobility是 Kubernetes 备份/灾备能力的自然延伸备份解决数据还在不在灾备解决能不能在别处起来而移动性解决起来之后长什么样。本文通过 90DaysOfDevOps 第 90 天的真实演练展示了 Kasten K10 如何让迁移 转换在一次恢复操作中原子完成——把 Pac-Man 从csi-hostpath-sc慢存储迁到standard快存储同时把前端从 1 副本扩展到 5 副本全程无需手工改 YAML、无需停机式的人工重建。这套机制的适用范围远不止集群迁移灾难恢复、测试环境搭建、多云适配都可以复用同一条备份 → 导入 → 转换 → 恢复流水线并通过 Kubernetes API 与既有自动化体系CI/CD、GitOps无缝集成。赞分享文档/教程【免费下载链接】90DaysOfDevOpsThis repository started out as a learning in public project for myself and has now become a structured learning map for many in the community. We have 3 years under our belt covering all things DevOps, including Principles, Processes, Tooling and Use Cases surrounding this vast topic.项目地址https://gitcode.com/gh_mirrors/90/90DaysOfDevOps点击查看免费下载相关推荐90DaysOfDevOps 第 90 天使用 Kasten K10 实现 Kubernetes 应用与数据迁移Data Application Mobility90DaysOfDevOps 第 90 天使用 Kasten K10 实现 Kubernetes 应用与数据迁移Data Application Mob文档/教程90DaysOfDevOps 实战基于 Kasten K10 与 minikube 的 Kubernetes 跨集群灾难恢复DR90DaysOfDevOps 实战基于 Kasten K10 与 minikube 的 Kubernetes 跨集群灾难恢复DR 本篇技术指南是 90Da文档/教程90DaysOfDevOps 实战使用 Kasten K10 在 Kubernetes 中完成有状态应用的备份与恢复90DaysOfDevOps 实战使用 Kasten K10 在 Kubernetes 中完成有状态应用的备份与恢复 本篇技术指南来自 90DaysOfDev文档/教程上一篇3分钟掌握ncmdump终极免费方案解决网易云音乐NCM格式播放限制下一篇终极指南3分钟免费解锁网易云音乐NCM格式让音乐无处不在创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考