构建Kubernetes有状态应用程序的不同方法

Kubernetes是计算历史上增长最快的基础设施项目之一。在短短的五年内，它已经达到了成为现代基础设施基础的成熟水平。从公共云中的托管容器即服务（CaaS）到数据中心中的企业平台即服务（PaaS）到边缘计算，Kubernetes变得无处不在。

在Kubernetes的早期，它主要被视为运行Web规模的无状态服务的平台。数据库和分析工作负载等有状态服务既可以在虚拟机中运行，也可以作为基于云的托管服务运行。但是随着Kubernetes成为最受青睐的基础架构层，生态系统努力使有状态应用程序成为Kubernetes宇宙中的一等公民。

在Kubernetes中有多种运行状态应用程序的技术，每种技术各有优缺点。

本文试图重点介绍在Kubernetes中运行有状态应用程序的关键方法，可用的选择以及与每种方法一致的工作负载类型。我假设读者熟悉Kubernetes存储基础结构的关键组成部分，例如持久卷，持久卷声明和存储类。

共享存储

第一种方法是将Kubernetes集群与通过Samba，NFS或GlusterFS公开的传统存储基础架构集成在一起。这种方法可以轻松扩展到基于云的共享文件系统，例如Amazon EFS，Azure文件和Google Cloud Filestore。

在这种架构中，存储层与Kubernetes管理的计算层完全脱钩。在Kubernetes Pods中有两种使用共享存储的方式：

1) Native Provisioning： 幸运的是，大多数共享文件系统都具有内置在上游Kubernetes发行版中的卷插件，或者具有容器存储接口（CSI）驱动程序。这使集群管理员可以使用特定于共享文件系统或托管服务的参数声明性地定义持久卷（PV）。

2) Host-based Provisioning：通过这种方法，引导脚本在负责安装共享存储的每个节点上运行。 Kubernetes集群中的每个节点将具有一个一致的，众所周知的挂载点，该挂载点会暴露给工作负载。持久卷通过hostPath或Local PV指向主机目录。

由于底层存储管理持久性和持久性，因此工作负载完全与其分离。这使Pod可以在任何节点上进行调度，而无需定义节点亲和力，从而确保Pod始终在所选节点上进行调度。

但是，这种方法对于需要高I/O吞吐量的有状态工作负载并不理想。共享文件系统并非旨在提供关系数据库，NoSQL数据库和其他写密集型工作负载所需的IOPS。

存储选择：GlusterFS,Samba,NFS,Amazon EFS,Azure Files,Google Cloud Filestore

典型工作负载类型：内容管理系统，机器学习训练任务和数字资产管理系统。

StatefulSets

Kubernetes通过控制器维护所需的配置状态。Deployment，ReplicaSet，DaemonSet和StatefulSet是一些常用的控制器。

StatefulSet是一种特殊的控制器，可以轻松地在Kubernetes中运行集群工作负载。集群工作负载通常可以具有一个或多个主服务器和多个从服务器。大多数数据库都设计为在集群模式下运行，以提供高可用性和容错能力。

有状态的集群工作负载连续在主服务器和从服务器之间复制数据。为此，集群基础结构希望参与的实体（主节点和从节点）具有一致且众所周知的端点，以可靠地同步状态。但是在Kubernetes中，Pod被设计为临时的，不能保证具有相同的名称和IP地址。

有状态集群工作负载的另一个要求是持久的存储后端，该后端具有容错能力并且能够处理IOPS。

为了轻松在Kubernetes中运行有状态集群工作负载，引入了StatefulSets。保证属于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, andJupyterHub

云原生存储

Kubernetes的兴起创造了与云原生计算计划保持一致的新细分市场。由于存储是云原生基础架构的关键部分之一，因此在最近的几年中，云原生存储市场的新细分市场迅速发展。

云原生存储将传统的存储原语和工作流程引入了Kubernetes。像其他服务一样，它是从底层硬件和操作系统中抽象出来的。从提供到销毁，工作流程遵循典型Kubernetes资源的相同生命周期。云原生存储以应用程序为中心，这意味着它了解工作负载的上下文，而不是作为集群外部的独立层。与其他资源一样，云原生存储可以根据工作负载条件和特征进行扩展和收缩。它能够合并连接到每个节点的单个磁盘，并将它们作为单个统一逻辑卷公开给Kubernetes Pods。

从安装存储集群到调整卷大小，云原生存储使Kubernetes管理员能够使用功能强大的kubectl CLI去管理。云原生存储具有动态配置，支持多个文件系统，快照，本地和远程备份，动态卷大小调整等优势。

云原生存储平台唯一期望的是集群内原始存储的可用性，可以将其聚合并合并到一个逻辑卷中。原始存储可以采用针对本地集群的直接附加存储（DAS）的形式，以及针对在公共云中运行的托管群集的块存储的形式。

云原生存储是针对容器的，而块存储则是针对虚拟机的。两者都是从底层物理存储中划出的逻辑存储块。在将块存储连接到VM时，可以通过容器使用的持久卷来使用云原生存储。

大多数云原生存储平台都带有自定义调度程序，以支持存储和计算的超融合。自定义调度程序与Kubernetes的内置调度程序一起使用，以确保Pod始终位于具有数据的同一节点上。

存储选择：NetApp Trident,Maya Data,Portworx,Reduxio,Red Hat OpenShift Container Storage,Robin Systems,Rook,StorageOS

工作负载类型：任何需要持久性和持久性的工作负载。