3同行回答
容器的特性决定了容器本身是非持久化的，容器被删除，其上的数据也一并删除。而其上承载的应用分为有状态和无状态。容器更倾向于无状态化应用，可水平扩展的，但并不意味所有的应用都是无状态的，特别是银行的应用，一些服务的状态需要保存比如日志等相关信息，因此需要持久化存储。容器存储大致有三种存储方案：
（1）原生云存储方案：按照纯粹的原生云的设计模式，持久化数据并不是存储在容器中，而是作为后端服务，例如对象存储和数据库即服务。这个方案可以确保容器和它们的数据持久化支持服务松耦合，同时也不需要那些会限制扩展的依赖。
（2）把容器作为虚拟机：利用容器带来的便携性的优点，一些用户将容器作为轻量虚拟机来使用。如果便携性是迁移到容器的原因之一，那么采用容器替代虚拟机来安装遗留应用是这种便携性的反模式。由于大卷中存储数据是紧耦合在容器上，便携性难以实现。
（3）容器持久化数据卷：在容器中运行的应用，应用真正需要保存的数据，可以写入持久化的Volume数据卷。在这个方案中，持久层产生价值，不是通过弹性，而是通过灵活可编程，例如通过设计的API来扩展存储。这个方案结合了持久层和或纯云原生设计模式。
Docker发布了容器卷插件规范，允许第三方厂商的数据卷在Docker引擎中提供数据服务。这种机制意味着外置存储可以超过容器的生命周期而独立存在。而且各种存储设备只要满足接口API标准，就可接入Docker容器的运行平台中。现有的各种存储可以通过简单的驱动程序封装，从而实现和Docker容器的对接。可以说，驱动程序实现了和容器引擎的北向接口，底层则调用后端存储的功能完成数据存取等任务。目前已经实现的Docker Volume Plugin中，后端存储包括常见的NFS，GlusterFS和块设备等。
部署于容器平台上的服务,第一,尽可能考虑实现无状态服务,比如日志,打印到标准输出,通过filebeat等采集处理
如果涉及session, 可以考虑使用API gateway层来处理, 尽可能不要放到业务服务层。
数据库，至少到目前为止，不建议部署于容器平台
服务间通信，建议考虑事件驱动机制
如果需要有状态服务，存储需求建议具体问题具体分析，很难说有普适的道理，不同的场景不同的需求对存储的要求也不同，通常没有大量分布式存储需求，可以不用配置ceph、glusterfs等。 NFS、NAS等也可以。
收起理解的不深，大致描述下，等高手来补充.
K8S中的持久性存储主要还是通过PV、PVC和StorageClass来实现。
对于无状态服务，存储可能是不必要的，但是对于由状态服务，需要各种类型的存储来保持状态。在K8S中，PV提供存储资源，PVC使用存储资源，二者是供应者和消费者的关系，那么服务是如何把数据存储到PV上的呢？
我们知道K8S中服务运行在POD中，因此在POD的YAML定义文件中，就需要定义PVC，并指定要关联的PVC名称，然后PVC会根据自身的YAML文件定义绑定合适的PV，流程就是：POD->PVC->PV,当然，这是静态供给方式，静态供给的特定就是先有PV再有PVC。
对于动态供给方式，就需要定义storageclass，并在存储类的YAML文件中声明存储卷供应者，如aws-ebs、ceph-rbd和cinder等，当POD需要存储的时候，再动态创建PV，其特点就是先PVC再PV；
当然，存储这块本身有很多需要考虑的地方，最佳答案还是官网：https://kubernetes.io/docs/concepts/storage/persistent-volumes/
这里有两个扩阅读，关于容器原生存储：
https://www.linuxfoundation.org/press-release/opensds-aruba-release-unifies-sds-control-for-kubernetes-and-openstack/
https://github.com/openebs/openebs