Imgix的工程師Cindy Sridharan撰寫了一篇綜述，討論了采用Kubernetes和HashiCorp公司的Nomad等容器調度器（container scheduler）的目的；為了應對在程序打包、部署和生命周期等方面遇到的技術挑戰，Imgix決定在架構中加入調度器；Imgix最終選擇Nomad作為調度器：作者在文中對Kubernetes和Nomad進行了對比分析，大體描述了最終的技術實踐。原文綱要：
為何Google當年使用了調度器Google當年的探索在多大程度上解決了其他人的問題為什么即使容器數量不多，也應該使用調度器在現有架構上增添調度器的挑戰在混合環境上運行調度器為什么Imgix選擇了Nomad，而不是Kubernetes還需解決的問題新工具引進的新問題未來的發展方向Sridharan表示，現在的開發比十年前要復雜許多。即使核心商業邏輯很簡單，考慮到高可靠性、高可用性、客戶滿意度、快速創新、持續交付、快速反饋和持續迭代的問題，可靠的標準化工具變得至關重要。很多組織會學習Google這種業界獨角獸的實踐。但其局限性在于：
“人人都可用的Google架構”只是指那些能夠解決組織眼下問題的技術。
容器調度器最初由Google的Borg（白皮書）發揚光大。十余年來，Google一直將所有服務都放在容器中運行，由Borg管理集群。由于Docker的成功，容器化不再是大型組織的專利，反過來促使了Kubernetes的誕生。
調度器乍一看很嚇人，仿佛大大超出大部分組織的工程能力：實際上，調度器可以改變游戲規則，大大改變傳統的軟件生命周期管理手段。調度器帶來的靈活性和即時效益不可估量。
Sridharan表示，Imgix團隊在探索調度器技術時，遇見了三個挑戰：
打包——為了打包不同語言寫作的程序，調度器需要支持類POSIX標準（雖然Docker容器接近POSIX，但仍有局限性）部署——不存在標準的與語言無關的方式來部署那些通過靜態鏈接的二進制包或一系列更為復雜的軟件包生命周期——構建分布式系統時需要考慮單點失效、功能降級（degraded application functionality）、服務級別目標（service level objective, SLO）和服務級別協議（SLA）雖然在架構中加入調度器的成本不低，imgix最終還是選擇了Nomad作為調度器。在選擇技術時，由于Kubernetes和Docker關系緊密（如果選用，imgix需要修改現有程序的打包方法）和Kubernetes的網絡問題，imgix最終沒有選擇Kubernetes。Nomad可以部署多種程序，包括靜態連接的二進制包；同時，Nomad與服務發現程序Consul良好兼容（imgix的技術棧依賴Consul）。
在選擇新工具時，特別是在選擇運維工具時，很重要的一點是要選擇可以無縫加入到現有基礎設施的工具，盡量避免修改現有的東西。
Sridharan說，Nomad贏得競爭的原因有：
對現有打包方法的修改最小，兼容Consul服務發現開發者可以制定程序的操作語義“運維大眾化”，即不同的程序共享類似的作業文件，無論程序使用什么語言，不管是長時間運行還是批量操作，工程師都可以迅速了解部署的細節操作簡單：例如，部署在每個節點上的Nomad僅為一個二進制文件。不過Nomad目前還存在一些問題，包括缺乏訪問控制列表（ACL），這個問題可以通過使用入口網關或HAProxy反向代理來解決。其他問題還包括沒有配額選項、優先級控制，以及超額請求集群資源等本文的全文集群調度器可在Medium中查看，Twitter上的討論可以在這里找到。
查看英文原文：“Cluster Schedulers”: Cindy Sridharan on the Purpose of Schedulers, and Why imgix Chose Nomad
京公網安備 11010502049343號