众所周知, Kubernetes(K8S)更适合运行无状态应用, 但是除了无状态应用. 我们还会有很多其他应用类型, 如: 有状态应用, 批处理, 监控代理(每台主机上都得跑), 更复杂的应用(如:hadoop 生态…). 那么这些应用可以在 K8S 上运行么? 如何配置?

其实, K8S 针对这些都有对应的不同的运行方式. 您要做的, 就是考虑您的应用程序类型会如何影响其运行方式.

Kubernetes 定义了适用于不同类型应用程序的不同类型的工作负载。要确定适合您的应用程序的工作负载，请根据如下思路来思考您的应用程序：

• 是为了完成任务。一个典型例子是一个应用程序，启动时会跑一批数据，并在批处理执行完成后退出。该应用程序可能会定期运行(如每月)。对于这种类型的应用程序，合适的 Kubernetes (或 OpenShift) 容器平台对象包括 Jobs 和 CronJob  对象。

• 长时间一直运行. 对于长时间运行的应用程序，可以编写 Deployment。(当然啦, 最好是无状态的)

• 需要在每个节点上运行。某些类型的 Kubernetes 应用程序需要在群集中的每个主节点(master)或工作节点(worker)上运行。DNS 和监控的应用程序是需要在每个节点上连续运行的应用程序的典型例子。您可以将这种类型的应用程序作为 DaemonSet 运行。您还可以基于节点标签(node labels)在部分符合条件的节点上运行 DaemonSet。

• 复杂的应用, 或需要全生命周期管理。当您要移交应用程序以便其他运维人员可以很方便地使用它时，请考虑创建一个**Operator** (类似 HELM Charts, 区别是 HELM 只负责安装, Operator 除了安装, 还多了全生命周期管理)。Operator 可让您构建智能的应用，因此它可以自动处理备份和升级之类的事情。与 Operator Lifecycle Manager(Operator 生命周期管理器, 简称:OLM)结合使用，集群管理者可以将 Operator 暴露给特定的 namespace，以便集群中的用户可以运行它们。示例有:

• 有身份或编号要求。应用程序可能具有身份要求或编号要求。例如，您可能需要运行该应用程序的不多不少刚好三个实例, 并且实例命名为0，1和2。那么**StatefulSet**是适合于这种应用。StatefulSet 对于需要独立存储的应用程序（例如数据库和 Zookeeper 群集）最有用。总结起来, 就是有状态的应用就选择 StatefulSet .

{% note success %}
🧠思考：

现在的趋势是一些企业级的、复杂、高级的有状态软件开始偏向于采用 Operator 而不是 Helm。因为 Operator 提供更多「自愈」、「自洽」的能力，可以实现更高级、更高级别的自动化甚至是无人托管。
{% endnote %}

总结

本文由东风微鸣技术博客 EWhisper.cn 编写！