【IT168 编译】Kubernetes是Google开源的一个容器编排引擎，它支持自动化部署、大规模可伸缩、应用容器化管理。对于那些工作负载多样化、不断变化的企业来说，使用Kubernetes是非常有利的。

　　与容器一样，Kubernetes也支持高度动态、无状态的操作，不断地创建和销毁容器，以适应不同的工作负载。不过，Kubernetes的存储可能问题比较会棘手。许多操作都需要数据在容器的生命周期之外保留，这似乎与容器的特性不太一致。

　　经过多年的努力，Kubernetes开发人员已经将卷插件（Volume Plugins）集成到了Kubernetes平台中，以解决持久存储的需求。卷插件是扩展Kubernetes接口的模块，支持与物理存储卷的连接。

　　卷插件可提供一种有效的方法来实现数据在容器生命周期之外的持久化保存，但是它们也带来了一些挑战。为了解决这些挑战，Kubernetes引入了FlexVolume插件，但是FlexVolume也有一些问题。最近，Kubernetes推出了一个符合新的容器存储接口(CSI)标准的插件，该标准可以简化数据保存到各种存储平台的过程。

　　Kubernetes环境

　　Kubernetes是一个可移植和扩展的平台，同时支持自动化和声明性的配置方式。Kubernetes环境包含一组独立的控制流程，用于通过跨Kubernetes集群的计算、网络和存储资源的编排来管理用户工作负载。

　　Kubernetes的优点包括，能够支持几乎任何可以在容器中运行的应用程序，从而能够实现多种多样且不断变动的工作负载。每个容器都有自己的文件系统，并且与其他容器和主机隔离。因此，容器不能看到彼此的进程。此外，由于容器与底层基础设施解耦，所以它们可以跨云和OS发行版进行移植。

　　Kubernetes集群由主系统和节点系统组成。主服务器维护集群，并作为与外部资源通信的主要节点。节点是运行容器工作负载的物理服务器或虚拟机。

　　Kubernetes集群支持以下对象类型来实现容器化工作负载:

　　·Pod：用于管理和运行一组相关容器的逻辑结构。Pod中的所有容器共享存储和网络资源，它是Kubernetes集群中最小的可部署计算单元。

　　·卷：在Pod级别定义的逻辑目录，该目录可由该Pod中的容器访问。卷和Pod的使用寿命相同，这意味着它可以比Pod中的任何容器寿命都长。

　　·Service：一个REST对象，作为访问Pod逻辑集的抽象层，以便将前端客户端与后端操作解耦。

　　·命名空间：一组基于相同物理集群的虚拟集群。命名空间面向支持多个团队或项目的许多用户的环境。

　　Kubernetes提供了基于这些基本对象的控制器，以此来交付额外的功能。Kubernetes还包含一个API，它映射到每个对象类型，以提供使用Kubernetes环境的机制。

　　此外，每个Kubernetes集群都包含一个用于管理环境和自动化操作的控制平面。控制平面是在主系统和节点系统上运行的进程的集合。主进程运行多个进程，用于运行控制器、管理Pod以及公开Kubernetes API。每个节点运行进程以维护网络规则、执行连接转发且确保容器正在运行。

　　Kubernetes中的数据存储

　　Pod提供了部署容器化工作负载的主要构建块。它包含一个或多个容器、共享存储资源和惟一的网络IP地址。Pod还包括了控制容器如何运行的选项。在大多数情况下，Pod只支持应用程序的一个实例，对于其他实例需要添加更多的Pod。

　　Kubernetes的存储发生在Pod级别。一个Pod可以配置一组存储卷，使Pod中的容器能够共享存储并实现数据的持久化保存，在容器重启后也可以存活。Kubernetes提供了非常多的卷类型，如Azure Disk、CephFS、iSCSI、vSphere卷、Portworx卷和Amazon Elastic Block Store等等。

　　Kubernetes提供了一种特殊类型的卷，用于在容器和Pod的生命周期之外持久存储数据。它被称为PersistentVolume (PV)，它抽象了有关存储如何提供给Pod容器或由Pod容器使用的详细信息。

　　Kubernetes将PV实现为卷插件，其生命周期独立于Pod。卷插件扩展了Kubernetes接口，以方便与外部存储的连接。该插件是入树（in-tree）模块构建，并直接编译到核心Kubernetes二进制文件中，这样就可以在需要的时候向容器交付存储。

　　由于插件内置于Kubernetes代码中，添加一个新的存储系统意味着供应商必须直接将插件代码检入主代码库，这可能会给Kubernetes平台带来不稳定和安全问题。这个过程还将供应商与Kubernetes的发布周期联系起来，同时迫使他们向访问Kubernetes代码的任何人开放插件源代码。

　　为了解决这些限制，Kubernetes引入了FlexVolume插件，它提供了一个出树（out-of-tree）插件接口，支持与存储相关的通信。通过这种方式，存储供应商可以开发部署到Kubernetes环境中的驱动程序，在那里，FlexVolume插件可以访问这些驱动程序。

　　虽然Kubernetes的这种存储方法能够使一些供应商受益，但也带来了一些挑战。例如，插件很难部署，并且需要访问每个集群机器上的根文件系统。

　　CSI卷插件

　　最近，Kubernetes推出了一个新的CSI卷插件，可以解决这些问题。它提供了一个符合CSI标准的出树解决方案。CSI将存储系统暴露给容器编排工具(如Kubernetes)管理的容器工作负载。这一新标准使供应商能够开发一个单一驱动程序来支持任何符合CSI的容器编排解决方案。

　　随着1.13版的发布，CSI插件开始对Kubernetes普遍可用。与FlexVolume插件一样，供应商可以开发部署到Kubernetes环境中符合CSI的驱动程序，同时避免了FlexVolume插件带来的许多挑战。供应商不必接触Kubernetes代码，也不必担心Kubernetes是如何实现的。一旦安装了驱动程序，用户就可以使用CSI卷插件执行附加或挂载卷以保存数据等任务。

　　虽然Kubernetes在最初设计之时，仅支持无状态操作，但它在编排容器工作负载方面极具优势。过去，将数据保存到容器或Pod的生命周期之外往往伴随着挑战。随着CSI插件的引入，有望使企业更容易地为其工作负载应用容器技术，特别是随着更多存储供应商提供符合CSI的驱动程序。对于许多IT团队来说，CSI会是他们向Kubernetes过渡时需要的一大动力，能够轻松为Kubernetes实现存储。

　　原文作者：Robert Sheldon