Kubernetes的采用正在呈现爆炸式增长，撇开炒作的话题，Kubernetes仍然处于非常的发展阶段，而且还有很长的路要走，它极有可能成为大多数IT基础架构的组成部分。
与此同时，即使不是大多数企业和IT商店，当他们进入Kubernetes领域时，也只是想要探索Kubernrtes这个神奇的新领域。在开发人员开始在平台上开展工作之前， 管理员、运营团队或DevOps必须奠定基础，将传统而重要的数据管理组件添加到混合组件中：持久性存储是Kubernetes部署中必要组件的一个很好的示例，但它并不容易实现。
将持久添加到无状态
企业应该具备的关键需求是开发人员能够将数据存储在Kubernetes集群中，而无需担心持久存储在底层如何工作。
“应用程序开发人员和DevOps团队不是数据管理人员。就像我不希望我的DBA去玩应用程序开发人员一样，我真的不希望我的应用程序开发人员在玩DBA。”企业管理协会(EMA)的分析师John L. Myers说。 “我想给应用程序开发人员提供通过API访问持久数据管理层的机会，或者每次部署集装箱化应用程序时都不必从头创建一个。”
但是，Kubernetes的结构使其不适合部署在有状态的卷上。
Constellation Research分析师Holger Mueller表示：“容器从来没有被设计成持久的，但企业需要持久的改变负载，保持状态，为不同的负载使用更多的硬件等。这是企业界容器设计的缺陷，因为对企业来说，所有重要的一切都需要持久。”
不过，Kubernetes提供了多种选项来设置持久性存储。例如，Kubernetes提供了一种方法，可以在安装到容器编排平台的卷上静态和动态地提供数据，MapR产品管理总监Suzy Visvanathan说：“这为用户在需要时消费存储提供了灵活性。”
然而，Kubernetes提供的灵活卷插件使得外部供应商可以与Kubernetes集成，但也有它的问题。 Visvanathan说，在引入容器存储接口(CSI)模型之前，问题就是插件依赖性。使用Apache Mesos，Red Hat，OpenShift，Docker和云解决方案(例如Kubernetes的Amazon Elastic Container Service(EKS)和Google Kubernetes Engine(GKE))，业务流程层显在的与Kubernetes内部集成。
Visvanathan说：“CSI模式在使外部存储解决方案与Kubernetes集成方面变得更加容易。”
扩展
许多企业总是寻求扩展Kubernetes以容纳大量的共享容器资源的用户。但是，如何扩展持久存储组件是一大挑战。例如，传统存储解决方案及其配置不一定是最合适的。
“Kubernetes可以轻松快速地扩大生产中的容器规模。接下来的挑战是提供一个与之一起扩展的数据平台”MapR的Visvanathan说。“传统的存储选项根本无法跟上这一规模。在Kubernetes改造旧式安全措施，进一步恶化了这种状况”
MapR的Visvanathan指出：“新的持久性存储替代方案通常是单节点解决方案，如果集群化，仍然不能提供全球可寻址名称空间或混合/多云移动性。”
“Kubernetes被用于云式弹性和选择您选择的云模型的能力，包括内部部署，混合或多云部署。”Visvanathan说。 “持久存储需要实现相同的目标。”
“与此同时，在具有内部存储的服务器上部署容器可以使扩展更直接”，Diamanti产品营销总监Sean Roth说。
“扩大存储空间可能会造成破坏性，并可能导致巨大且往往意料之外的额外开支，”Roth表示。 “Kubernetes持久存储的主要挑战主要源于缩放。对容器存储基础设施采取自己动手的做法可能会造成破坏性和造成昂贵的成本。“
最终，企业需要在越来越多的服务器之间平衡存储使用。 Roth表示，跨Kubernetes部署共享存储的可用资源可以由网络文件系统(NFS)或开源集群文件系统协议(如Ceph或GlusterFS)组成。
卷集成
尽管存在上述挑战，但Kubernetes确实提供了广泛的存储集成量选项，也在不断地改进。例如，Kubernetes提供了一种在静态和动态调用Kubernetes上的数据时提供数据的方法，Visvanathan说。“这为用户在需要时消费存储提供了灵活性。”
事实上，Kubernetes的卷存储驱动程序选项可以促进持久存储的多种不同机制的使用，CloudPassage的策略工程专家Ash Wilson说，增加一些卷驱动程序是IaaS(基础架构即服务)平台特定的，而有些开发者不了解底层的云基础架构。
“这些卷存储驱动程序选项非常好，但是正确评估和确定哪些最符合应用程序需求花费很长的时间。”Wilson说。 “与保护Kubernetes中的永久存储相关的任务通常是特定于驱动器的特定驱动程序，因此在架构过程中必须考虑安全问题。”
裸机服务器部署
MapR的Visvanathan认为，“Kubernetes虚拟化结构在建立持久性存储时也非常适合裸机服务器部署。这是因为容器虚拟化操作系统，不是虚拟化操作系统下的硬件”。
Visvanathan说：“集装箱就其本质而言是部署裸机应用的理想方式，而Kubernetes则简化了集装箱的创建和管理。” “这是概念的自然延伸，Kubernetes的持久存储也是裸机上的最佳服务。一旦容器弹性化，虚拟化服务器不会提供任何额外的好处，因此，它们只是一个附加层，没有附加价值。”
安全考虑
“在确定ubernetes中运行的应用程序的用户访问权限时，一大障碍就是Kubernetes工作负载的动态和无状态特性。事实上，Kubernetes存储的主要安全问题是维护访问控制和授权特权，以确保只有相关的容器和服务才能访问敏感数据。”Aqua Security营销副总裁Rani Osnat说。
Osnat说：“有几种方法可以实现这一目标，但它们必须与具有应用上下文和与特定服务关联的安全策略绑定在一起。”
提供用于保护Kubernetes持久性存储的安全工具也应该继续发展。换句话说，一切都需要及时改善。
“短期工作负载可能会在捕获适当的安全信息方面面临挑战，尤其是出于审计和合规目的。 这个问题的解决可能需要借助于工具的演变，而不是放慢敏捷过程，”CloudPassage的Wilson说。 “跟踪、审计和保护存储机制存在类似的问题 ----工具必须发展以满足安全需求，而不应该减慢应用交付流程。”
译者介绍：
刘志红，17年IT从业经验。曾在NTT DATA，Oracle，中钞造币集团，中国电信云计算分公司从事云计算等关联IT研发工作。独立拥有软件著作权1件。目前就职于电子工业出版社。
