企业容器云为支持有状态应用的容器应用部署，存储设计时需要考虑哪些因素？

有状态应用的状态可细分指拓扑状态、存储状态。 其中 拓扑状态 指应用的多个实例之间不是对等关系，这些应用实例，必须按照某种顺序启动 。存储状态则是指应用的多个实例分别绑定了不同的存储数据，对于这些应用实例来说。当应用因为某些原因导致了宕机，重启后依旧可以正常的读取到数据。

在容器云上部署的有状态应用，其部署需求有：维持稳定且唯一的网络标识，提供稳定持久的存储
，提供有序和优雅的部署和伸缩能力，提供有序和自动的更新能力。

因此存储设计时，要综合考虑到有状态应用的特征进行设计，譬如在容器云上部署数据库这类有状态应用，和部署日志监控这类有状态应用就有不同的设计维度和优先级。
存储产品的选型优先考察稳定、安全、性能和API能力。

1. 存储系统需要能够良好的运行在各种不同服务商提供的公有云环境或私有云环境，能够很好地和其他云原生基础设施配合，例如云原生数据库，使得云原生数据库可以真正的在公有云和私有云都能够得到一致的用户体验。
2. 存储系统需要为运维人员提供相同接口和运维方式，即运行在 K8s 中，使用 K8s 的工具进行运维和管理，具备容器化部署、自动运维、声明式接口等特征，降低运维团队的负担。

当前有状态应用的容器应用部署，如果有能力应修改应用。使其状态保存在缓存服务器类似 Redis cluster中，相关日志统一进入 elk，或者 kafka 完成持久化。
这样存储设计相对简单，只要保证elk和redis的存储容量和访问速度。
如果无法修改应用，需要挂载一个持久化卷，来持久化数据。使数据可以在不同节点漂移，需要所有主机对存储的访问权限，这个又会出现存储访问风险。
在实际业务场景，把存储分多个区域， 挂载到对应区域的主机，进行区别访问。避免访问风险

数据库、中间件的有状态应用，建议使用本地存储，做好raid。ceph、san等存储，由于通过网络进行传输数据，会造成性能的进一步降低，难以提供最优的存储性能。
本地存储监控和维护，容器云一般是不管，需要传统工具运维。
我们开源的carina本地存储解决方案，各位可以了解一下
https://github.com/carina-io/carina