@cnbeining
2017-07-27T04:59:33.000000Z
字数 1759
阅读 968
Cluster Schedulers
note: 此新闻是几万字原文的总结。全本原文地址:https://medium.com/@cindysridharan/schedulers-kubernetes-and-nomad-b0f2e14a896
原文又臭又长,删节版也没好到哪去。
摘要: Imgix的工程师Cindy Sridharan对使用容器调度器的目的、使用时的挑战等方面进行了深入讨论,并建议使用Nomad作为调度器。
作者: Cindy Sridharan
正文:
Imgix的工程师 Cindy Sridharan撰写了一篇综述,讨论了采用Kubernetes和HashiCorp公司的Nomad等容器调度器(container scheduler)的目的;为了应对在程序打包、部署和生命周期等方面遇见的技术挑战,Imgix决定在架构内加入调度器;Imgix最终选择Nomad作为调度器:作者在文中对Kubernetes和Nomad进行了对比分析,大体描述了最终的技术实践。原文纲要:
- 为何Google当年使用了调度器
- Google当年的探索在多大程度上解决了其他人的问题
- 为什么即使容器数量不多,也应该使用调度器
- 在现有架构上增添调度器的挑战
- 在混合环境上运行调度器
- 为什么Imgix选择了Nomad,而不是Kubernetes
- 还需解决的问题
- 新工具引进的新问题
- 未来的发展方向
Sridharan表示,现在的开发比十年前的复杂许多。即使核心商业逻辑很简单,考虑到高可靠性、高可用性、客户满意度、快速创新、持续交付、快速反馈和持续迭代的问题,可靠的标准化工具变得至关重要。很多组织会学习Google这种业界独角兽的实践。但是局限性在于:
“所有组织都使用Google的架构”这种实践只适用于Google的方案可以解决组织现实中遇见的眼下的问题。
容器调度器由Google Borg的白皮书 发扬光大。十余年来,Google一直将所有服务都放在容器中运行,由Borg管理集群。由于Docker的成功,容器化不再是大型组织的专利,反过来促使了Kubernetes的诞生。
调度器乍一看很吓人,仿佛大大超出大部分组织的工程能力所及:实际上,调度器可以改变游戏规则,大大改变传统的软件生命周期管理手段。调度器带来的灵活性和即时效益数不可估量。
Sridharan表示,Imgix团队在探索调度器技术时,遇见了三个挑战:
虽然在架构内加入调度器的成本不低,imgix最终还是选择了Nomad作为调度器。在选择技术时,由于Kubernetes和Docker关系紧密(如果选用,imgix需要修改现有程序的打包方法)和Kubernetes的网络问题7,imgix最终没有选择Kubernetes。Nomad可以部署多种程序,包括静态连接的二进制包;同时,Nomad与服务发现程序Consul良好兼容(imgix的技术栈依赖Consul)。
在选择新技术,特别是运行技术时的重要原则是选择可以无缝加入现有架构的技术,这样对现有可用架构的修改最少。
Sridharan说,Nomad赢得竞争的原因有:
- 对现有打包方法的修改最小,兼容Consul服务发现;
- 开发者可以制定程序的操作语义;
- "操作民主化",即不同的程序共享类似的工作文件(job file),无论程序使用什么语言,是长时间运行还是批量操作:这样工程师可以迅速理解如何部署。
- 操作简单:例如,每个节点的Nomad仅为一个二进制文件。
Nomad的问题包括缺乏访问控制列表(ACL),这个问题可以用入站防火墙或HAProxy这种反向代理解决。其他问题包括没有配额选项、优先级控制,以及超额请求集群资源等。
本文的全文,集群调度器可在Medium查看,Twitter的讨论串在此。