共计 1653 个字符，预计需要花费 5 分钟才能阅读完成。
有状态利用（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…）。
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 在容器平台上的利用场景和劣势。
