容器上面可以部署有持久化数据的应用或者数据库吗？
如果是用了容器云，有持久化数据需求的应用应该如何部署，后端是否只能接nas，是否能在容器上部署oracle数据库，升级oracle数据库时能否直接部署一个新版本的数据库再挂载原有的数据升级数据字典即可，如果可以应该如何规划？是否又成功案例？
收起查看其它 3 个回答half_life的回答
K8s已经是现在容器云的事实标准了。
在最开始（K8s 1.0时代），k8s是为无状态应用设计的。无状态应用可以被重启和重新调度，或者快速的扩展出多个副本实例，K8s的优势（自动化、弹性、故障自愈）被充分发挥。这时，虽然说也可以在k8s中运行容器化的数据库实例，但是要管理这些数据库，保障数据的可用性是相当复杂的，这个阶段k8s对数据库是不友好的。
随着K8s 1.5版本开始支持StatefulSet，有状态应用正式成为了k8s的一等公民，通过持久卷（Persistent Volume）可以解决数据库的数据持久性问题。尤其是到K8s 1.10有了CSI之后，企业也可以使用性能更高、可靠性更好的外置存储了，当数据库Pod被调度到其它节点重启的时候，共享的持久卷可以在新的节点上重新挂载给数据库Pod。这些解决了数据库的数据安全性和可用性的基础设施问题，但k8s本身并不理解每个数据库的运维的逻辑，因此数据库的运维部分仍然有很多地方需要管理员来处理，比如数据库状态的监控、主/从数据库的切换、数据备份等。
让数据库能真正在k8s上变得好用的是Operator的出现。Operator使得数据库厂商和第三方可以去扩展K8s API，将数据库运维的能力由Operator来实现出来。这大幅简化了在k8s中运维和管理数据库的操作，把K8s变成一个优质的数据库运行平台。
数据库上容器的好处
- 数据库的安装、配置和维护更简单
特别是有了Operator以后，哪怕进行一个复杂的主从关系型数据库安装，都可以通过一个YAML文件轻松搞定，后续不管是给数据库实例增加资源的Scale-up操作，或者增加实例的Scale-out操作，都非常简单。K8s还可以大幅简化数据库升级和打补丁的操作。 - 跨多云的部署兼容性更好
对于需要在多云环境中进行部署的系统，或者需要经常切换部署环境的场景，托管的数据库服务基本不可行，而物理部署数据库又太复杂，在容器中进行数据库部署就变得非常有优势。因为目前几乎所有公有云和私有云的K8s都具有高度的兼容性，在容器中进行数据库部署可以提供高度的可移植性和跨平台可管理性。 - 应用和数据库可以统一在一个K8s平台上运维，不需要分开部署运维
对于完成同一业务目的的应用系统而言，应用本身和数据库可以同时在K8s上进行部署和运维。相对于混合部署的方式而言，同一个平台可以减少基础架构的复杂性，以及所需要的人员技能，从而降低成本。 - 快速进行大量的数据库实例的部署
对于多租户的SaaS服务，或者大规模并行测试等这类需要同时提供大量数据库实例的场景，在容器中部署数据库不仅仅让整个过程更加简单，而且资源的利用率更高，通过命名空间也可以提供提供网络和运行实例的更好的隔离性。
数据库上容器需要注意的地方
- 相对于虚机，容器的动态性会更强
一方面，单进程的故障、OOM等都可能会导致容器重启，另一方面，K8s的调度器会根据节点的资源状况进行一定的动态调度。 从应对的角度，一方面需要配置数据库应用的调度优先级和资源配给，确保K8s尽可能保证数据库pod的资源；另一方面，对于特定的数据库，可以考虑某些节点只预留给数据库Pod使用。 - 资源的隔离
相对于虚机而言，K8s的资源隔离尚不完善。尤其是对数据库性能非常重要的磁盘IO资源，K8s调度器目前并没有对磁盘IO性能做特殊的考虑，所以如果多个数据库实例在同一个节点上竞争磁盘IO资源的话，可能会对性能造成影响。
应对的角度而言，一方面可以通过节点设置在每个节点上只运行一个数据库实例避免资源冲突，另一方面可以使用CSI的外置存储卷，从而更好的为每个Pod分配存储资源。
数据库上容器的现状
目前主流的开源数据库都已经有了K8s支持，并提供了相应的Operator来方便数据库在k8s上的运维，包括Cassandra、MySQL、PostgreSQL、MongoDB等，以及国产的TiDB。
传统的大型商业化数据库现在也提供了K8s支持，包括微软的SQL Server，IBM的DB2和Oracle。
综上所属，数据库在K8s上运行是大势所趋，并且从开发环境和测试环境的试水，已逐渐走向生产环境的应用。