滑板车上的女孩。 Freepik的插图，由HashiCorp设计的 Nomad徽标

Kubernetes是用于容器编排的300公斤大猩猩。它可以在世界上一些最大的集装箱系统中使用，但价格昂贵。

对于必须花费大量时间在支持和陡峭的学习曲线上的小型团队而言，这尤其昂贵。对于我们的四人团队来说，这是太多的开销。因此，我们开始寻找替代品-并爱上了Nomad 。

你要什么

我们的团队支持许多用于监视和分析性能的典型服务：Go指标的API端点，Prometheus的导出，Log Parsash和Gollum等日志解析器，以及InfluxDB或Elasticsearch等数据库。这些服务中的每一个都在其自己的容器中运行。我们需要一个简单的系统来保持所有这些操作。

我们从容器编排的要求列表开始：

在多台计算机上启动一组服务。
正在运行的服务概述。
服务之间的通信。
如果服务崩溃，将自动重启。
由小型团队进行基础架构维护。

此外，以下情况会很好，但不是强制性的补充：

根据其功能标记机器（例如，使用快速磁盘标记机器以进行繁重的I / O服务）。
不管管弦乐队如何（例如，在开发过程中）启动服务的能力。
共享配置和机密的常用位置。
指标和日志的端点。

为什么Kubernetes不适合我们

使用Kubernetes创建原型时，我们注意到我们开始添加越来越多的复杂逻辑层，而我们无条件地依赖这些逻辑层。

例如，Kubernetes通过ConfigMaps支持内置服务配置。您可能会很快感到困惑，尤其是在合并多个配置文件或向Pod添加其他服务时。 Kubernetes（在这种情况下为掌舵）允许您动态地实现外部配置以分离兴趣。但这导致您的项目与Kubernetes之间存在隐秘的联系。但是，Helm和ConfigMap是附加选项，因此您不必使用它们。您可以简单地将配置复制到Docker映像。尽管如此，尝试采用这种方式并构建不必要的抽象还是很诱人的，您稍后会后悔。

此外，Kubernetes生态系统正在迅速发展。与最佳实践和最新工具保持同步需要大量时间和精力。 Kubectl，minikube，kubeadm，helm，tiller，kops，oc-清单还在不断增加。在工作开始时，并不是所有这些工具都是必需的，但是您不知道需要什么，因此您需要了解所有内容。因此，学习曲线相当陡峭。

何时使用Kubernetes

在我们公司，许多人使用Kubernetes并对此感到满意。这些实例由Google或Amazon管理，它们有足够的支持资源。

Kubernetes具有惊人的功能，使其更易于管理和大规模的容器编排：

详细的权限管理。
定制控制器将逻辑添加到集群。这些只是与Kubernetes API对话的程序。
自动缩放！ Kubernetes可以使用服务指标按需扩展服务，而无需手动干预。

问题是您是否真的需要所有这些功能。您不能仅仅依靠抽象；您必须找出幕后情况。

我们的团队远程提供大多数服务（由于与主要基础架构的紧密连接），因此我们不想建立自己的Kubernetes集群。我们只是想提供服务。

不含电池

Nomad是业务流程的20％，这提供了必要的80％。他所做的只是管理部署。 Nomad负责部署，在出现错误的情况下重新启动容器……仅此而已。

Nomad的全部意义在于它做到了最低限度 ：没有特别构思出详细的权限管理或高级网络策略。这些组件由提供或根本不提供。

我认为Nomad在易用性和实用性之间找到了完美的折衷方案。这对于小型的独立服务很有用。如果您需要更多的控制权，则必须自己提高或使用其他方法。游牧民族只是一个乐队。

关于Nomad的最好的事情是它很容易更换。由于供应商的功能很容易集成到任何其他管理服务的系统中，因此对供应商几乎没有任何约束。它就像集群中每台计算机上的常规二进制文件一样，就是这样！

零散组件的Nomad生态系统

游牧民族在其生态系统中的真正力量。它与其他（完全可选）的产品（例如Consul （键值存储）或Vault （秘密处理））集成得很好。在Nomad文件中，有一些部分用于从这些服务中提取数据：

template { data = <<EOH LOG_LEVEL="{{key "service/geo-api/log-verbosity"}}" API_KEY="{{with secret "secret/geo-api-key"}}{{.Data.value}}{{end}}" EOH destination = "secrets/file.env" env = true }

在这里，我们从Consul读取了关键service/geo-api/log-verbosity ，在此过程中，我们用环境变量LOG_LEVEL表示它。我们还将Vault中的secret/geo-api-key为API_KEY 。简单但功能强大！

由于其简单性，Nomad可以通过API通过其他服务轻松扩展。例如，支持任务标签。我们使用trv-metrics标签为所有服务添加标签。因此，Prometheus可以通过Consul轻松找到这些服务，并定期检查端点/metrics是否有新数据。例如，对于使用Loki的日志，可以执行相同的操作。

可扩展性还有许多其他示例：

使用挂钩运行Jenkins作业，Consul会在服务配置更改时跟踪Nomad作业的重新部署。
Ceph向Nomad添加了分布式文件系统。
fabio用于负载平衡。

所有这些使您能够有机地开发基础结构，而无需与供应商进行任何特定的绑定。

诚实的警告

没有系统是完美的。我不建议立即将最新功能引入生产环境。当然，这里有bug和缺少的功能，但Kubernetes也是一样。

与Kubernetes相比，Nomad社区没有那么大。 Kubernetes已经有大约75,000个提交和2,000个贡献者，而Nomad有大约14,000个提交和300个贡献者。 Nomad将很难跟上Kubernetes的发展步伐，但是也许这没有必要！这是一个更专业的系统，社区更小也意味着您的请求请求比Kubernetes更有可能被注意和接受。

总结

结论：不要仅仅因为每个人都在使用Kubernetes。仔细评估您的要求，并检查哪种工具更有利可图。

如果您打算在大规模基础架构上部署大量同类服务，那么Kubernetes是一个不错的选择。只要记住增加的复杂性和维护成本。通过使用托管的Kubernetes环境（例如Google Kubernetes Engine或Amazon EKS）可以避免某些成本。

如果您只是在寻找可靠的协调器，易于支持且可扩展的协调器，为什么不尝试Nomad？您可能想知道这将带您走多远。

如果将Kubernetes与汽车进行比较，Nomad将是一辆小型摩托车。有时您需要一个，有时需要另一个。两者都有生存权。

您可能不需要Kubernetes