构建有状态Kubernetes应用程序的方法，都在这里
Posted on 2020-03-06
Kubernetes是发展最快的基础设施项目之一。在短短五年的时间里，它已经成熟，成为现代基础设施的基础。从公有云中的托管容器即服务（CaaS）到数据中心中的企业平台即服务（PaaS），Kubernetes正变得无处不在。在Kubernetes早期，它主要被认为是运行web级无状态服务的平台。有状态的服务（如数据库和分析工作负载）要么在虚拟机中运行，要么作为基于云的托管服务运行。但随着Kubernetes成为最受欢迎的基础设施层，其生态系统努力使有状态应用程序成为Kubernetes领域的重要一份子。在Kubernetes中运行有状态应用程序有多种技术，每种技术都有其优缺点。本文重点介绍在Kubernetes中运行有状态应用程序的关键方法、可用的选择以及与每种方法对应的工作负载类型。你需要熟悉Kubernetes存储基础设施的关键构建块，如持久卷、持久卷声明和存储类。第一种方法是将Kubernetes集群与通过Samba、NFS或GlusterFS公开的传统存储基础设施集成。这种方法可以很容易地扩展到基于云的共享文件系统，如Amazon EFS、Azure Files和Google Cloud Filestore。在这个架构中，存储层与由Kubernetes管理的计算层完全分离。有两种方法可以使用Kubernetes Pods中的共享存储：1） 本机配置：幸运的是，大多数共享文件系统都在上游Kubernetes发行版中内置了卷插件，或者有一个容器存储接口（CSI）驱动程序。这使集群管理员能够使用特定于共享文件系统或托管服务的参数以声明方式定义持久卷（PV）。2） 基于主机的配置：在这种方法中，启动脚本在负责装载共享存储的每个节点上运行。Kubernetes集群中的每个节点都有一个一致的、众所周知的、对工作负载公开的挂载点。持久卷通过hostPath或Local PV指向主机目录。由于底层存储管理耐用性和持久性，因此工作负载与之完全分离。这使得Pod可以在任何节点上得到调度，而无需定义节点关联性，从而确保Pod始终在所选节点上调度。但是，对于需要高I/O吞吐量的有状态工作负载，这种方法并不理想。共享文件系统的设计不是为了提供关系数据库、NoSQL数据库和其他写密集型工作负载所需的IOPS。存储选择：GlusterFS、Samba、NFS、Amazon EFS、Azure Files、Google云文件存储。典型工作负载：内容管理系统、机器学习训练/推理作业和数字资产管理系统。Kubernetes通过控制器维护所需的配置状态。Deployment、ReplicaSet、DaemonSet和StatefulSet是一些常用的控制器。StatefulSet是一种特殊类型的控制器，它使在Kubernetes中运行集群工作负载变得容易。集群工作负载通常可能有一个或多个主服务器和多个从服务器。大多数数据库设计为以集群模式运行，以提供高可用性和容错性。有状态的集群工作负载不断地在主服务器和从服务器之间复制数据。为此，集群基础设施期望参与实体（主实体和从实体），以具有一致且众所周知的端点来可靠地同步状态。但是在Kubernetes中，Pods被设计成暂态的，不能保证它有相同的名称和IP地址。有状态集群工作负载的另一个需求是持久的存储后端——它是容错的，并且能够处理IOPS。为了便于在Kubernetes中运行有状态集群工作负载，引入了StatefulSet。确保属于StatefulSet的Pod具有稳定、唯一的标识符。它们遵循可预测的命名约定，还支持有序、“优雅”的部署和扩展。参与StatefulSet的每个Pod都有一个对应的持久卷声明（PVC），该声明遵循类似的命名约定。当一个Pod被终止并在另一个节点上重新调度时，Kubernetes控制器将确保该Pod与相同的PVC相关联，这将保证状态是完整的。由于StatefulSet中的每个Pod都有一个专用的PVC和PV，因此没有使用共享存储的硬性规定。但StatefulSet需要一个快速、可靠、持久的存储层作为后盾，比如基于SSD的块存储设备。在确保写入完全提交到磁盘之后，可以从块存储设备中获取常规备份和快照。存储选择：SSD、块存储设备（如Amazon EBS、Azure Disks、GCE PD）。典型工作负载：Apache ZooKeeper、Apache Kafka、Percona Server for MySQL、PostgreSQL Automatic Failover和JupyterHub。Kubernetes的崛起创造了一个新的细分市场。由于存储是云原生基础设施的关键组成部分之一，云原生存储市场的一个新细分市场在最近几年迅速发展。云原生存储为Kubernetes带来了传统的存储原语和工作流。与其他服务一样，它是从底层硬件和操作系统中抽象出来的。从供应到退役，工作流遵循与典型Kubernetes资源相同的生命周期。云原生存储是以应用程序为中心的，这意味着它理解工作负载的上下文，而不是集群外部的独立层。与其他资源一样，云原生存储可以根据工作负载条件和特性进行扩展和收缩。它能够将连接到每个节点的单个磁盘集中起来，并将它们作为一个统一的逻辑卷公开给Kubernetes Pod。从安装存储集群到调整卷大小，云原生存储使Kubernetes管理员能够使用由功能强大的kubectl CLI管理的常见YAML构件。云原生存储具有动态资源配置、对多个文件系统的支持、快照、本地和远程备份、动态卷大小调整等功能。云原生存储平台唯一的期望是集群内原始存储的可用性——这些原始存储可以聚合并汇集到一个逻辑卷中。原始存储可以是本地集群的直连存储（DAS），也可以是公有云中运行的托管集群的块存储。云原生存储对于容器就像块存储对于虚拟机一样。两者都是从底层物理存储中分割出来的逻辑存储块。块存储连接到VM，云原生存储则通过容器使用的持久卷可用。
大多数云原生存储平台都带有一个自定义调度程序，以支持存储和计算的超融合。自定义调度程序与Kubernetes的内置调度程序一起工作，以确保Pod始终位于拥有数据的同一节点上。存储选择：NetApp Trident、Maya Data、Portworx、Reduxio、Red Hat OpenShift Container Storage、Robin Systems、Rook、StorageOS。
