特别是对于规模较小的团队而言,会因为维护它并且因它的学习曲线陡峭导致大量耗时。相比较于我们一个四人团队想要在trivago内实现的目标,它增加了太多额外负担。所以我们研究了其他的选择,并由衷地喜欢上它,那就是Nomad[1]。
愿望清单
我们从容器编排的需求开始:
在众多的机器上运行一系列服务
提供所有正在运行的服务的概览
允许服务间通信
当服务死掉后能自动重启
适用于小团队管理
根据功能来标记机器(例如将带有快速硬盘的机器打上标记让它用于I/O密集型服务)
能够独立于任何调度器运行这些服务(例如在开发环境)
有一个通用的途径来共享配置以及敏感性信息
为监控指标和日志记录提供端点
为什么Kubernetes不适合我们
例如,Kubernetes允许使用ConfigMaps来嵌入服务配置。但这很快就可能变得混乱,特别是在合并多个配置文件或向Pod添加更多服务的时候。Kubernetes或者是Helm允许动态注入外部配置以确保关注点分离,但这可能导致你的项目与Kubernetes之间的隐式紧密耦合。Helm和ConfigMaps是可选功能,因此你不一定需要使用它们。你也可以将配置复制到Docker镜像中。虽然沿用这种方法很简单且诱人,但构建这些不必要的抽象可能会在将来给你带来麻烦。
最重要的是,Kubernetes生态系统仍在迅速发展,我们需要花费大量的时间和精力来掌握最佳实践和最新的工具才能与时俱进。Kubectl,minikube,kubeadm,helm,tiller,kops,oc,这些工具列表一直在更新。并非所有工具都是入门Kubernetes所必需的,但也很难知道哪些工具是否是必需的,因此你必须至少了解它们。因此,学习曲线非常陡峭。
何时使用Kubernetes
Kubernetes有很多神奇的功能[3],使得大规模的容器编排更易于管理,例如:
细粒度的权限管理
自定义控制器允许将自定义逻辑控制引入群集,这些程序可跟Kubernetes API通信。
自动伸缩!Kubernetes可以根据需求来伸缩扩展你的服务。它使用服务指标来完成此操作,无需人工干预。
特别是在我们的团队中,有运行着大多数内部服务(因为它与trivago的核心基础设施紧密相连),我们不想担负运行我们自己的Kubernetes集群。我们只想要提供服务。
![640?wx_fmt=jpeg](https://img-blog.csdnimg.cn/img_convert/f5bf7de319773271292a06885cd7a026.png)
鬼使神差
Nomad的意义所在就在于它做得更少:它不包括细粒度的权限管理或高级网络策略,这是设计之初就确定的了。这些组件由第三方提供作为企业服务,或者根本就不存在。
我认为Nomad在易用性和表现力之间取得了一个最佳平衡点。它适用于小型,大多数是独立的服务。如果你需要更多控制,那么你必须自己构建它或使用其他方法。Nomad仅仅只是一个调度器。
关于Nomad一个好的地方是它易于替换,几乎没有厂商锁定,因为它提供的功能可以很容易地集成到管理服务的任何其他系统中。它仅仅是在集群中的每台机器上运行了个二进制执行文件而已!
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的值并在你的job中将其暴露给 LOG_LEVEL这个环境变量,同时也从Vault中读取键为 secret/geo-api-key的值暴露为 API_KEY。是不是很简单明了强大!
正因为它非常简单,Nomad也可以通过其API轻松扩展其他服务。例如可以标记job以进行服务发现。在trivago,我们使用 trv-metrics标记所有公开指标的服务。这样,Prometheus可以通过Consul找到服务,并定期从 /metrics端点收集获取新数据。同样的例子是通过集成Loki可以对日志进行操作。
除此之外还有许多其他可扩展性方面的示例:
使用webhook来触发Jenkins job,Consul监视并在服务配置变更时重新部署Nomad任务。
使用Ceph将分布式文件系统集成到Nomad。
使用fabio做负载平衡。
友情提醒
与Kubernetes相比,Nomad背后的势头要小得多。到目前为止,Kubernetes已经有大约75,000个提交和2000个贡献者,而Nomad大约是14,000个提交和300个贡献者。Nomad很难跟上Kubernetes的速度,但也许也没有必要!覆盖范围窄,较小的社区同样意味着与Kubernetes相比,接受PR会更容易些。
总结
如果你计划在大型基础架构上部署一系列同质服务,Kubernetes可能是一个正确选择,但请注意额外的复杂性和运营成本。使用Google Kubernetes Engine或Amazon EKS等托管Kubernetes环境可以避免其中一些成本。
如果你只是在寻找一个易于维护和扩展的可靠的调度器,我觉得你可以尝试下Nomad,你可能会惊讶于它到底能给你带来多少惊喜。
如果说Kubernetes是一辆汽车,那么Nomad就是一辆摩托车。两者各有千秋,都有自己的存在权。
相关链接:
https://www.nomadproject.io/
https://github.com/trivago/gollum
https://jvns.ca/blog/2017/08/05/how-kubernetes-certificates-work/
https://www.consul.io/
https://www.vaultproject.io/
https://tech.trivago.com/2019/01/25/nomad-our-experiences-and-best-practices/
![640?wx_fmt=png](https://img-blog.csdnimg.cn/img_convert/ab4d245d526441e0d6d962b808717a79.png)