当像Kubernetes这样的容器协调器到达时，开发和部署应用程序的方法发生了巨大变化。 微服务已经出现，对于开发人员而言，应用程序逻辑不再与基础架构连接：为自己创建应用程序并提供新功能。
Kubernetes从它控制的物理计算机中抽象出来。 只需告诉他您需要多少内存和处理能力，您就会得到一切。 基础设施？ 不，没有听到。
管理Docker映像，Kubernetes和应用程序使其具有可移植性。 使用Kubernetes开发容器应用程序后，您可以将它们部署到任何地方：本地，开放云或混合环境中-无需更改代码。
我们喜欢Kubernetes的可扩展性，可移植性和可管理性，但它并不存储状态。 但是我们几乎所有有状态的应用程序都需要外部存储。
Kubernetes具有非常动态的架构。 根据开发人员的负载和说明创建和销毁容器。 容器和容器可以自我修复和复制。 它们本质上是短暂的。
对于这种可变性，外部存储太困难了。 它不遵守动态创建和破坏的规则。
只需要在另一个基础架构中部署有状态的应用程序：在本地的另一个云中，在本地还是在混合模型中-它如何存在可移植性问题。 外部存储可以绑定到特定的云。
但是，只有在这些用于云应用程序的存储中，魔鬼自己才能摔断腿。 然后了解Kubernetes中存储术语的虚拟含义和含义。 还有Kubernetes自己的存储库，开源平台，托管或付费服务...
以下是CNCF云存储的一些示例：
似乎在Kubernetes中部署了数据库-您只需要选择适当的解决方案，将其打包在容器中即可在本地磁盘上工作，并将其作为下一个工作负载部署到集群中。 但是数据库具有其自身的特性，因此思考不是一成不变的。
容器-它们拼凑在一起，无法保持其状态。 这就是为什么它们如此容易启动和停止的原因。 并且由于没有要保存和传输的内容，因此群集不会为读取和复制操作所困扰。
您将必须将状态与数据库一起存储。 如果部署到容器中群集上的数据库没有迁移到任何地方并且启动得不太频繁，则数据存储物理将发挥作用。 理想情况下，使用数据的容器应与数据库位于同一炉膛中。
当然，在某些情况下，数据库可以部署到容器中。 在测试环境或数据很少的任务中，数据库可以舒适地存在于群集中。
生产通常需要外部存储。
Kubernetes通过控制平面接口与存储库进行通信。 它们将Kubernetes链接到外部存储。 附加到Kubernetes的外部存储称为卷插件。 有了它们，您可以抽象存储并转移存储。
批量插件曾经使用Kubernetes代码库创建 ，链接，编译和交付。 这极大地限制了开发人员并需要额外的维护：如果要添加新的存储库，请更改Kubernetes代码库。
现在，将批量插件部署到群集中-我不想。 而且您无需深入研究代码库。 感谢CSI和Flexvolume。
Kubernetes本机存储
Kubernetes如何解决存储问题？ 有几种解决方案：临时选项，持久卷中的持久存储，持久卷声明查询，存储类或StatefulSet。 一般来说，去弄清楚。
永久卷（PV）是管理员准备的存储单元。 他们不依赖壁炉和他们短暂的生活。
永久体积声明（PVC）是存储请求，即PV。 使用PVC，您可以将存储绑定到一个节点，该节点将使用它。
您可以静态或动态使用存储。
使用静态方法，管理员可以在请求之前预先准备应该提供的PV，然后使用显式PVC将这些PV手动绑定到特定的Pod。
实际上，专门定义的PV与Kubernetes便携式结构不兼容-存储取决于环境，例如AWS EBS或永久性GCE驱动器。 要手动绑定，您需要指向YAML文件中的特定存储库。
静态方法通常与Kubernetes的哲学相矛盾：CPU和内存没有预先分配，也没有绑定到Pod或容器。 它们是动态发布的。
对于动态配置，我们使用存储类。 集群管理员不需要预先创建PV。 它创建多个存储配置文件，例如模板。 当开发人员发出PVC请求时，在请求时，将创建这些模式之一并将其附加到炉床上。
因此，最笼统地说，Kubernetes与外部存储一起使用。 还有许多其他选择。
CSI-容器存储接口
有这样的东西- 容器存储接口 。 CSI是由CNCF库工作组创建的，该工作组决定定义一个标准的容器存储接口，以便库驱动程序可以与任何管弦乐队一起使用。
CSI规范已经适用于Kubernetes，并且有大量的驱动程序插件可用于Kubernetes集群中的部署。 您必须通过符合CSI的卷驱动程序访问存储库-在Kubernetes中使用csi卷类型 。
使用CSI，可以将存储视为容器化和部署到Kubernetes集群的另一工作量。
有关更多详细信息，请在我们的播客中收听Jie Yu关于CSI的谈话 。
开源项目
云技术的工具和项目迅速增加，并且合乎逻辑的开源项目的合理份额解决了主要的生产问题之一：在云体系结构中使用存储。
其中最受欢迎的是Ceph和Rook。
Ceph是具有水平扩展能力的动态管理的分布式存储集群。 Ceph为存储资源提供了逻辑抽象。 它没有单点故障，它可以自我管理并在软件的基础上工作。 Ceph提供了用于为单个存储集群同时存储块，对象和文件的接口。
Ceph具有非常复杂的体系结构，具有RADOS，librados，RADOSGW，RDB，CRUSH算法和各种组件（监视器，OSD，MDS）。 让我们不深入架构，足以了解Ceph是一个分布式存储群集，可简化可伸缩性，在不牺牲性能的情况下消除单点故障，并提供可访问对象，块和文件的单个存储。
自然，Ceph适用于云。 您可以以不同的方式部署Ceph集群，例如，使用Ansible或通过CSI和PVC将其部署到Kubernetes集群中。
Ceph建筑
Rook是另一个有趣且受欢迎的项目。 它将Kubernetes及其计算与Ceph及其存储库结合在一起，形成一个集群。
Rook是补充Kubernetes的云存储协调器。 他们将Ceph打包到容器中，并使用群集管理逻辑来确保Ceph在Kubernetes中的可靠运行。 Rook自动执行部署，引导，调整，扩展，重新平衡-通常，集群管理员可以执行所有操作。
借助Rook，可以从Yaml部署Kubernetes等Ceph集群。 在此文件中，管理员概述了集群中的需求。 Rook启动了一个集群并开始进行主动监视。 这就像操作员或控制器一样，它可以确保满足Yaml的所有要求。 Rook具有同步周期，可以看到状态并在出现偏差时采取措施。
他没有永久状态，不需要控制。 这是Kubernetes的精神。
Rook将Ceph和Kubernetes结合在一起，是最受欢迎的云存储解决方案之一：在Github上有4,000颗星，1630万次下载和100多个贡献者。
Rook项目已被CNCF接受， 最近又在孵化器中结束 。
巴萨姆·塔巴拉（Bassam Tabara）将在我们的Kubernetes存储库集中为您提供有关Rook 的更多信息 。
如果应用程序有问题，则需要找出要求并创建系统或使用必要的工具。 这也适用于云存储。 尽管问题并非来自简单的问题，但工具和方法却不足。 云技术不断发展，新的解决方案必将等待我们。