您想降低噪音嗎？
好吧，Scholar.google.com可以為您提供幫助。
我經常使用研究論文來分析"第一手"比較，而不是"標誌"和" blogskite"帖子。
好，回到主題。
最好在這裡描述調度體系結構概述：
Schwarzkopf，Malte等。 " Omega：適用於大型計算集群的靈活，可擴展的調度程序。" 第八屆ACM歐洲計算機系統會議論文集。 ACM，2013年。
> ( source )
…作為後續，下面的文章將它放在上下文中：
Shav Ravula。 "通過Mesos / Marathon實現不可變容器化微服務的持續交付。" （2017）。
單片調度程序
整體調度程序對所有作業使用單個集中式調度算法。 所有工作負載都通過相同的調度程序和相同的調度邏輯運行。 Swarm，Fleet，Borg和Kubernetes採用單片調度程序。 Kubernetes即興使用Borg和Swarm調度程序的基本整體版本。 這種類型的調度程序不適用於運行異構的現代工作負載，包括Spark作業，容器和其他長時間運行的作業等。
兩級調度程序
兩級調度程序通過將對資源分配和任務放置的關注分開來解決了整體調度程序的缺點。 活躍的資源管理器將計算資源提供給多個並行的獨立"調度程序框架"。 Mesos集群管理器率先採用了這種方法，YARN支持這種方法的有限版本。 在Mesos中，資源提供給應用程序級調度程序。 這允許定製的，特定於工作負載的調度策略。 這種調度體系結構的缺點是應用程序級框架不再能看到所有可能的放置選項。 相反，他們只看到與資源管理器組件提供的（Mesos）或分配的（YARN）資源相對應的那些選項。 這使得優先級搶佔（高優先級任務踢出低優先級任務）變得困難。
共享狀態調度程序
共享狀態調度程序通過刪除中央資源分配器來授予對整個群集資源的完全訪問權限。 每個應用程序級別的調度程序都可以訪問整個集群。 群集的狀態在所有調度程序之間共享。 此類調度程序的一個示例是Omega和Nomad。 通過支持獨立的調度程序實現並公開調度程序的整個分配狀態，該體系結構可以擴展到許多調度程序，並通過自己的調度策略處理不同的工作負載。 這種體系結構的主要缺點是，調度程序必須使用過時的信息（與集中式調度程序不同），並且在高競爭情況下可能會遇到調度程序性能下降的情況。
（資源）
最後將Nomad放置到位，對嗎？
另外，我今天在HashiCorp MeetUp＃15上記錄的Nomad消息轉儲
Nomad UI
· https://github.com/jippi/hashi-ui
· https://github.com/FRosner/cluster-broccoli
Nomad的Rundeck插件
ValFadeev / rundeck-nomad-plugin
rundeck-nomad-plugin-在Nomad群集上運行作業的Rundeck插件。
· 啟動領事代理，以發現遊牧代理的服務（在本地主機上的服務器和客戶端中）
· 啟動nomad代理（使用–dev）
· 打開領事UI
· 啟動hashi UI
· 在本地主機上啟動rundeck（啟動jar可執行文件）
· 安裝插件只需將其放到插件目錄中
· 創建rundeck項目，創建工作，並-執行一些Nomad步驟：
· 一些命令/腳本/對另一個作業的引用，即運行帶有alpine 3.5映像的docker容器，然後睡眠10秒鐘$ {option.sleep}然後再次運行
更多的驚喜，因為我得到更多的動手與Nomad的明天！
(本文翻譯自Arseny Chernov的文章《Nomad vs. Yarn vs. Kubernetes vs. Borg vs. Mesos vs… you name it!》，參考：https://medium.com/@arseny.chernov/nomad-vs-yarn-vs-kubernetes-vs-borg-vs-mesos-vs-you-name-it-7f15a907ece2)
閱讀更多 聞數起舞 的文章
