有状态应用如何在 Kubernetes 平台上快速迁移和重建

有状态应用（Stateful Application）通常是指有持久化存储需求的各种应用，各种数据库就是最常见的有状态应用。而无状态应用则与有状态应用相对应，常见的无状态应用包括各种页面前端、Httpd、Nginx 中间件等。

在 Docker 刚出现的若干年，容器并不是 Stateful Application Ready 的, 直至后来 Docker 增加了 Volume 机制用以将本地宿主的文件系统暴露给上层的容器，有状态应用才开始逐步地在容器平台上得以实现。有状态应用在容器平台上运行起来之后，容器平台随即面临另一个问题，在应用需要的情况下，容器可以快速地在集群内的任意节点启动，这对于有状态应用来说，必须要能做到持久化数据与容器跟随，否则原有数据将会丢失或无法访问。因此，支持有状态应用在平台内平滑迁移和切换节点，是优秀的容器存储必须具备的能力。（虽然 Kubernetes 也对 Local Persistent Volume 做了支持，但它不是让数据跟随，而是让容器跟随，让容器在数据原来的位置上重建。）

有状态 Pod 在容器平台内不同节点之间进行平滑迁移和重建的实际需求，可以用于应对节点故障等场景，这种需求在实际生产环境的集群中会更加频繁和迫切。当前市场上的一些基于块存储（例如原生的 CephRBD 容器存储方案）提供的容器存储解决方案，在应对 Pod 跨节点迁移和重建时需要完成下面的一系列操作：

• 从受影响的容器中 umount

• 将 volumes 在受影响的计算节点上 detach

• 在新的计算节点上重新 attach volumes

• 将 volumes mount 到新节点的容器上

以上操作是一个相对耗时的过程，且需要在每一个受影响的容器上执行，中间任何一步出现故障和异常（例如在挂载过程中经常会遇到卷已被挂载，无法再挂载的错误），都会使整个 Pod 驱逐的过程受到影响，进而对业务造成影响。且在生产环境中，整个过程是很难通过人工介入的。

焱融 YRCloudFile 作为专业的容器存储，通过 FlexVolume 和 CSI 接口充分支持 Kubernetes 等容器编排平台（https://kubernetes-csi.github.io/docs/drivers.html）。

YRCloudFile 在设计之初就充分考虑到支持有状态容器在 Kubernetes 集群内的平滑迁移场景。对于焱融容器存储卷而言，数据在整个 K8S 平台各个计算节点上，都是随时可用的。当管理员执行 Pod 驱逐操作后，K8S 平台会调用 YRCloudFile 提供的接口，完成 Pod 和存储卷的 umount/mount 操作，Pod 驱逐和重建过程会在数秒内自动完成。从下图可以看出，焱融容器存储卷在 Pod 重建后是立即可用的，不需要任何人为的介入。

我们以运行 MySQL 为例来展示如何使用 YRCloudFile，并完成 Pod 在新节点上的重建。我们用 MySQL yaml 文件创建一个 MySQL 实例，从中我们可以看到，Kubernetes 是利用 CSI driver，通过动态创建的方式获得存储卷，并绑定到数据库的/var/lib/mysql 目录

相关 Pod、PV、PVC 创建完成后如下图所示：

随后我们插入一些测试数据：

下面我们看看如果 MySQL 实例或者所在的节点出现故障后，在其他计算节点上进行重建，效果如何。

我们看到数据库实例在 node3.yr 上被删除，同时在新的节点 node1.yr 上被快速重新启动起来，且原有数据在新的 Pod 实例上可以迅速读取，中间无需任何人工的 umount/detach/attach/mount 操作，极大地降低了运维难度和风险。

如何更好地支持有状态容器 failover、驱逐和重建，缩短操作过程，从而降低运维难度和风险，是云原生容器存储必须解决的重要问题。YRCloudFile 在某运营商的容器云平台中大规模实践了容器驱逐和重建的功能，通过实践验证了该功能的稳定性和可靠性，凸显了 YRCloudFile 容器存储相对于其它存储方案的独特价值。接下来，我们还将在其它方面介绍更多 YRCloudFile 在容器平台上的应用场景和优势。