为什么Imgix择了Nomad而非Kubernetes？
极客时间编辑部
讲述：杜力大小：1.23M时长：02:41
近日，Imgix 的工程师辛迪·斯里达兰（Cindy Sridharan）发表文章，讨论了容器调度器的意义，以及 Imgix 为什么在 Kubernetes 和 Nomad 中选择了 Nomad。
她的文中写道，为了应对在程序打包、部署和生命周期等方面遇到的技术挑战，Imgix 决定在架构中加入调度器，而在对 Kubernetes 和 Nomad 进行了对比分析之后，Imgix 最终选择 Nomad 作为调度器。
辛迪表示，现在的开发比十年前要复杂许多。即使核心商业逻辑很简单，但考虑到高可靠性、高可用性、客户满意度、快速创新、持续交付、快速反馈和持续迭代等问题，可靠的标准化工具变得至关重要。
容器调度器最初由谷歌的 Borg 系统发扬光大。十余年来，谷歌一直将所有的服务都放在容器中运行，由 Borg 管理集群。由于 Docker 的成功，容器化不再是大型组织的专利，反过来促使了 Kubernetes 的诞生。
调度器乍一看很吓人，仿佛大大超出了大部分组织的工程能力，但实际上，调度器可以改变游戏规则，大大改变传统软件生命周期的管理手段。调度器带来的灵活性和即时效益不可估量。
辛迪表示，Imgix 团队在探索调度器技术时，遇见了三个挑战：
打包：为了打包用不同语言编写的程序，调度器需要支持类 POSIX 标准，虽然 Docker 容器接近 POSIX，但仍有局限性；
部署：并不存在一种标准的、与语言无关的方式，来部署那些通过静态链接的二进制包或一系列更为复杂的软件包；
生命周期：构建分布式系统时需要考虑单点失效、功能降级、服务级别目标（SLO）和服务级别协议（SLA）等方面内容。
最终，Imgix 选择了 Nomad 作为调度器。原因主要在于：
Kubernetes 和 Docker 关系紧密，如果选用，Imgix 就需要修改现有程序的打包方法；
Nomad 可以部署多种程序，包括静态连接的二进制包；
Nomad 对现有打包方法的修改最小，并与服务发现程序 Consul 兼容良好，而 Imgix 的技术栈依赖 Consul；
在 Nomad 中，开发者可以制定程序的操作语义；
“运维大众化”，在 Nomad 中，不同的程序共享类似的作业文件，无论程序使用什么语言，是长时间运行还是批量操作，工程师都可以迅速了解部署的细节；
操作简单，例如，部署在每个节点上的 Nomad 仅为一个二进制文件。
辛迪在文章最后强调，在选择新工具时，特别是在选择运维工具时，很重要的一点，就是要选择可以无缝加入到现有基础设施中的工具，尽量避免修改现有的东西。
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线笔记
复制
AI
- 深入了解
- 翻译
- 解释
- 总结
该免费文章来自《极客视点》，如需阅读全部文章，
请先领取课程
请先领取课程
免费领取
© 版权归极客邦科技所有，未经许可不得传播售卖。 页面已增加防盗追踪，如有侵权极客邦将依法追究其法律责任。
登录 后留言
精选留言
由作者筛选后的优质留言将会公开显示，欢迎踊跃留言。
收起评论