在kubernetes (k8s) 上运行各种类型的应用是完全可行的。关键在于根据应用的具体需求选择合适的k8s资源类型。以下是如何在k8s上配置不同类型应用的详细指南：
众所周知，Kubernetes（K8S）更适合运行无状态应用，但除了无状态应用外，我们还会遇到许多其他应用类型，如有状态应用、批处理、监控代理（每台主机上都需要运行）以及更复杂的应用（如Hadoop生态系统）。这些应用如何在K8S上运行呢？如何进行配置？
实际上，K8S为这些不同的应用类型提供了相应的运行方式。您需要做的就是考虑您的应用程序类型如何影响其运行方式。
Kubernetes定义了适用于不同类型应用程序的不同类型的工作负载。要确定适合您的应用程序的工作负载，请根据如下思路来思考您的应用程序：
- 是为了完成任务。 一个典型例子是一个应用程序，启动时会跑一批数据，并在批处理执行完成后退出。该应用程序可能会定期运行（如每月）。对于这种类型的应用程序，合适的Kubernetes（或OpenShift）容器平台对象包括Jobs和CronJob对象。
- 长时间一直运行。 对于长时间运行的应用程序，可以编写Deployment或DeploymentConfig。（当然，最好是无状态的）
-
要求高可用。 如果您的应用程序需要高可用，那么您需要调整部署的数量以具有多个实例。
Deployment或DeploymentConfig资源类型可以包括ReplicaSet。借助ReplicaSet，Pod可以在多个节点上运行，以确保即使其中的一个或某几个程序中断，这个应用程序始终还是可用的。 - 需要在每个节点上运行。 某些类型的Kubernetes应用程序需要在群集中的每个主节点（master）或工作节点（worker）上运行。DNS和监控的应用程序是需要在每个节点上连续运行的应用程序的典型例子。您可以将这种类型的应用程序作为DaemonSet运行。您还可以基于节点标签（node labels）在部分符合条件的节点上运行DaemonSet。
- 复杂的应用，或需要全生命周期管理。 当您要移交应用程序以便其他运维人员可以很方便地使用它时，请考虑创建一个Operator（类似HELM Charts，区别是HELM只负责安装，Operator除了安装，还多了全生命周期管理）。Operator可让您构建智能的应用，因此它可以自动处理备份和升级之类的事情。与Operator Lifecycle Manager（Operator生命周期管理器，简称：OLM）结合使用，集群管理者可以将Operator暴露给特定的namespace，以便集群中的用户可以运行它们。示例有：
WebLogic集群...Redis集群...Elasticsearch集群...Spark集群...MongoDB的副本集，碎片集群...TiDB集群...Prometheus...Istio...Kafka集群...
-
有身份或编号要求。 应用程序可能具有身份要求或编号要求。例如，您可能需要运行该应用程序的不多不少刚好三个实例，并且实例命名为
0，1和2。那么StatefulSet是适合于这种应用。StatefulSet对于需要独立存储的应用程序（例如数据库和Zookeeper群集）最有用。
总结起来，就是有状态的应用就选择StatefulSet。
| 应用类型 | K8S 资源类型 | 备注 |
|---|---|---|
| Job、批处理 | Jobs CronJob | |
| 长时间运行的无状态应用 | Deployment DeploymentConfig | DeploymentConfig是OpenShift特有的 |
| 长时间运行的无状态应用- 高可用 | Deployment里加ReplicaSet字段 | |
| 需要在每个节点上运行的应用 | DaemonSet | |
| 复杂的应用，或需要全生命周期管理的应用 | Operator | Helm Charts也适用于安装复杂应用 |
| 有状态应用 | StatefulSet |
