随着越来越多的企业对其应用程序进行容器化，他们希望使用Kubernetes来运行关键任务工作负载。业界存在一种误解，认为容器化环境主要用于运行无状态工作负载。然而，随着Kubernetes的成熟，社区正在努力支持有状态工作负载，以满足企业客户的需求。在2018年CNCF调查，三分之一的受访者指出存储是他们面临的挑战之一，但这一数字与之前的调查相比大幅下降，并且自那以后在支持有状态工作负载方面取得了出色的进展。在这篇博文中，我们将讨论在Kubernetes上运行有状态工作负载，以及NetApp Ocean的Spot如何在利用Spot实例的同时支持这种工作负载。
Kubernetes上的有状态工作负载
Kubernetes从1.9版开始就直接支持有状态工作负载，当时StatefulSets是普遍可用的。Kubernetes用户一直在要求对持久卷的支持，现在已经足够成熟，可以支持数据库、大数据和人工智能工作负载等有状态应用程序。Kubernetes对有状态工作负载的支持以StatefulSets的形式出现。
需求
为了让Kubernetes支持有状态工作负载，它必须满足以下要求:
- 支持多个持久存储卷(云和本地)。
- 这些持久卷应该在Pod重启或终止后的新Pod时可用。这意味着存储和网络身份在重新启动后仍然有效。
对后者的支持更为重要。Kubernetes Pods是短暂的，但大多数有状态应用程序需要持久存储，其存储和网络身份在Pod重启后仍然存在。例如，当pod重新启动时，应该保留IP地址，并且这个过程应该在没有任何用户干预的情况下进行无缝管理。随着云提供商和其他存储产品的不断增长，Kubernetes通常支持开箱即用。
看看我们的跑步指南吧Elasticsearch在Kubernetes上
Kubernetes上带有数据库的有状态应用程序
在Kubernetes上运行有状态应用程序所需的数据库主要有三种方法:
使用云服务
在这种方法中，使用云提供商或第三方供应商提供的“数据库即服务”。用户不需要担心管理数据库，他们只需要专注于在Kubernetes上运行应用程序，而不用担心状态。尽管它减少了一些与运行数据库相关的操作开销，但它增加了一些延迟，并且有可能失去对第三方数据的控制。在使用这样的托管服务时，成本通常也较高。
在Kubernetes外部运行数据库
您可以使用相同的云提供商在Kubernetes环境之外运行数据库。您可以使用云提供商的弹性计算服务，并使用虚拟机运行数据库。然后，您就有责任管理卷、HA、规模等。这增加了显著的操作开销。或者，您可以在上面运行数据库由NetApp的托管实例Spot它支持有状态应用程序。由于我们的托管实例解决方案利用了现货实例，因此可以实现相当大的成本节约。
在Kubernetes内部运行数据库
在Kubernetes环境中运行数据库有很多原因，包括性能需求。这就是Kubernetes对有状态应用程序的支持变得重要的原因。Kubernetes中的有状态应用程序可以使用StatefulSets进行部署。
StatefulSets是Kubernetes API对象，它允许用户通过确保Pod重启后相同的网络ID和持久磁盘可用来运行有状态工作负载。即使pod是在其他节点上启动的，这也是有效的。目前只支持远程卷，对本地磁盘的支持还处于测试阶段。statfulset提供了对各种存储类包括各种云提供商提供的持久磁盘。
在运行Kubernetes环境时，可以利用StatefulSets海洋。
Ocean支持Spot实例之上的有状态应用程序，以帮助显著优化云成本，同时简化基础设施管理。Ocean知道附加到pod上的任何持久卷，并且在任何Spot实例终止时，将验证集群是否有足够的资源，以便重新调度pod并将其附加到持久卷。雷竞技rabet官网
Kubernetes上有状态应用的注意事项
基于Kubernetes的平台有助于大规模编排容器，使它们对企业云原生需求具有吸引力。Kubernetes平台为DevOps提供了更大的灵活性，从而使开发人员能够以业务的速度构建应用程序。由于Kubernetes也支持有状态应用程序，因此在评估Kubernetes平台的有状态工作负载时，考虑以下因素非常重要:
- 该平台是否使运行无状态和有状态工作负载变得容易?
- 平台是否提供IP地址在Pod和节点重启中存活的持久卷?
- 该平台是否能够轻松确保有状态应用程序的HA和DR ?
- 平台是否满足SLA需求?
- 这个平台可以跨多个云提供商工作吗
总之，随着Kubernetes成为运行容器化工作负载的事实上的标准，仔细评估您的需求是有意义的，这样您就可以将Kubernetes用于尽可能多的无状态和有状态工作负载。
