Kubernetes是800磅重的容器编排大猩猩。它为全球一些最大的部署提供支持，但它带有价格标签。
特别是对于规模较小的团队而言，维护并且学习曲线陡峭可能非常耗时。对于我们四人团队想要在trivago实现的目标，它增加了太多的开销。所以我们研究了另类 - 并爱上了 Nomad。
我们的团队运行了许多用于监控和性能分析的典型服务：用Go，Prometheus导出器，Logstash或Gollum等日志解析器以及InfluxDB或Elasticsearch等数据库编写的度量标准的API端点。每个服务都在自己的容器中运行。我们需要一个简单的系统来保持这些工作的运行。
我们从容器编排的要求列表开始：
- 在许多机器上运行一系列服务。
- 提供正在运行的服务的概述。
- 允许服务之间的通信。
- 死机后会自动重启。
- 由小团队管理。
最重要的是，以下事情很好，但并非严格要求：
- 根据功能标记机器（例如，带有快速磁盘的标签机，用于I / O重型服务。）
- 能够独立于任何协调器运行这些服务（例如，在开发中）。
- 有一个共同的地方来分享配置和秘密。
- 为指标和日志记录提供端点。
为什么Kubernetes不适合我们
在使用Kubernetes创建原型时，我们注意到我们开始添加更复杂的逻辑层来运行我们的服务。我们隐含依赖的逻辑。
例如，Kubernetes允许使用ConfigMaps嵌入服务配置 。特别是在合并多个配置文件或向pod添加更多服务时，这可能会很快变得混乱。Kubernetes - 或者 helm, - 允许动态注入外部配置以确保关注点分离。但这可能导致您的项目与Kubernetes之间的紧密，隐含的耦合。Helm和ConfigMaps是可选功能，因此您不必使用它们。您也可以将配置复制到Docker镜像中。然而，沿着这条路走下去并建立不必要的抽象，以后可能会咬你，虽然这很诱人。
最重要的是，Kubernetes生态系统仍在迅速发展。需要花费大量的时间和精力来掌握最新的实践和最新的工具。Kubectl，minikube，kubeadm，helm，tiller，kops，oc - 这个列表一直在继续。并非所有工具都是开始使用Kubernetes所必需的，但很难知道哪些工具是必需的，因此您必须至少了解它们。因此，学习曲线非常陡峭。
何时使用Kubernetes？
特别是在trivago，许多团队使用Kubernetes，并对此非常满意。这些实例由Google或亚马逊管理，但有能力这样做。
Kubernetes具有惊人的功能，使大规模的容器编排更易于管理：
- 细粒度的权限管理
- 自定义控制器允许将逻辑引入群集。这些只是与Kubernetes API对话的程序。
- 自动缩放！Kubernetes可以根据需要上下调整您的服务。它使用服务指标来完成此操作，无需人工干预。
问题是你是否真的需要所有这些功能。你不能依靠这些抽象来工作; 你必须要了解幕后发生了什么。
特别是在我们的团队中，它运行大多数内部服务（因为它与trivago的核心基础设施紧密相连），我们不想负担运行我们自己的Kubernetes集群。我们想要提供服务。
Nomad
Nomad是20％的服务编排，可以让您获得80％的支持。它所做的只是管理部署。它可以处理您的卷展栏并在出现错误时重新启动容器，这就是它。
Nomad的全部意义在于它做得更少：它不包括细粒度的权限管理或高级网络策略，这是设计的。这些组件由第三方提供为企业服务，或者根本不提供。
我认为Nomad在易用性和表现力之间达到了一个甜蜜点。它适用于小型，大多数是独立的服务。如果您需要更多控制，您必须自己构建它或使用不同的方法。Nomad 只是一个协调者。
关于Nomad最好的部分是它易于更换。几乎没有供应商锁定，因为它提供的功能可以很容易地集成到管理服务的任何其他系统中。它只是在集群中的每台机器上作为普通的旧单二进制运行而已！
Nomad生态系统中松散耦合的组件
Nomad 的真正力量在于其生态系统。它与其他 - 完全可选 - 的产品很好地集成，例如Consul（一个键值存储）或 Vault（用于秘密处理）。在Nomad文件中，您可以使用部分从这些服务中获取数据：
template { |
将从Consul service/geo-api/log-verbosity中读取密钥并将其作为工作中的LOG_LEVEL环境变量公开。也暴露来自Vault的secret/geo-api-key作为API_KEY。简单，但功能强大！
因为它非常简单，Nomad也可以通过其API轻松扩展其他服务。例如，可以标记作业以进行服务发现。在trivago，我们标记所有公开指标的服务trv-metrics。这样，Prometheus通过Consul找到服务，并定期搜索/metrics端点以获取新数据。例如，通过集成Loki可以对日志进行相同的操作 。
还有许多其他可扩展性示例：
- 使用webhook和Consul监视触发Jenkins作业，以便在服务配置更改时重新部署Nomad作业。
- 使用Ceph将分布式文件系统添加到Nomad。
- 使用fabio进行负载平衡。
所有这一切使我们能够在没有太多前期承诺的情况下有机地发展我们的基础设施。
公平的警告
没有系统是完美的。我建议你现在不要在生产中使用任何花哨的新功能。当然有缺陷和缺失的功能 - 但Kubernetes也是如此。
与Kubernetes相比，Nomad背后的动力要小得多。到目前为止，Kubernetes已经看到大约75,000个提交和2000个贡献者，而Nomad体育大约14.000个提交和300个贡献者。Nomad很难跟上Kubernetes的速度，但也许它没有必要！范围要窄得多，较小的社区也意味着与Kubernetes相比，接受拉取请求会更容易。
总结
要点是：不要仅仅因为其他人都使用Kubernetes而使用它。仔细评估您的要求并检查哪种工具符合要求。
如果您计划在大型基础架构上部署一系列同质服务，Kubernetes可能就是您的选择。请注意额外的复杂性和运营成本。使用Google Kubernetes Engine或Amazon EKS等托管Kubernetes环境可以避免其中一些成本。
如果你只是在寻找一个易于维护和扩展的可靠的协调器，为什么不试试Nomad呢？你可能会惊讶于它能带给你多远。
如果Kubernetes是一辆汽车，Nomad将成为一辆摩托车。有时你更喜欢一个，有时候另一个。两者都有自己的存在权。