你真的需要用到Kubernetes嗎？
Kubernetes是一個十分強大的容器編排系統。它在全球範圍內已廣受使用，支援了一些很大型的部署，但同時它也伴隨著一些代價。
特別是對於規模較小的團隊而言，會因為維護它並且因它的學習曲線陡峭導致大量耗時。相比較於我們一個四人團隊想要在trivago內實現的目標，它增加了太多額外負擔。所以我們研究了其他的選擇，並由衷地喜歡上它，那就是Nomad 。
願望清單
我們的團隊運行了許多用於監控和效能分析的典型服務：用Go寫的一些用於度量指標的API端點，Prometheus exporter，Logstash或Gollum等日誌解析器，以及資料庫服務例如InfluxDB或Elasticsearch。每個服務都執行在它們特定的容器中，我們需要一個簡單的系統來保持這些工作平穩執行。
我們從容器編排的需求開始：
- 在眾多的機器上執行一系列服務
- 提供所有正在執行的服務的概覽
- 允許服務間通訊
- 當服務死掉後能自動重啟
- 適用於小團隊管理
除此之外，以下是一些能錦上添花的需求：
- 根據功能來標記機器（例如將帶有快速硬碟的機器打上標記讓它用於I/O密集型服務）
- 能夠獨立於任何排程器執行這些服務（例如在開發環境）
- 有一個通用的途徑來共享配置以及敏感性資訊
- 為監控指標和日誌記錄提供端點
為什麼Kubernetes不適合我們
在使用Kubernetes建立原型時，我們意識到我們開始添加了些更復雜的邏輯層來執行我們的服務，一些我們隱式依賴的邏輯。
例如，Kubernetes允許使用ConfigMaps 來嵌入服務配置。但這很快就可能變得混亂，特別是在合併多個配置檔案或向Pod新增更多服務的時候。Kubernetes或者是Helm 允許動態注入外部配置以確保關注點分離，但這可能導致你的專案與Kubernetes之間的隱式緊密耦合。Helm和ConfigMaps是可選功能，因此你不一定需要使用它們。你也可以將配置複製到Docker映象中。雖然沿用這種方法很簡單且誘人，但構建這些不必要的抽象可能會在將來給你帶來麻煩。
最重要的是，Kubernetes生態系統仍在迅速發展，我們需要花費大量的時間和精力來掌握最佳實踐和最新的工具才能與時俱進。Kubectl，minikube，kubeadm，helm，tiller，kops，oc，這些工具列表一直在更新。並非所有工具都是入門Kubernetes所必需的，但也很難知道哪些工具是否是必需的，因此你必須至少了解它們。因此，學習曲線非常陡峭。
何時使用Kubernetes
在trivago有許多團隊使用Kubernetes，並對此非常滿意。然而這些例項由Google或Amazon管理，他們具備這種能力。
Kubernetes有很多神奇的功能 ，使得大規模的容器編排更易於管理，例如：
- 細粒度的許可權管理
- 自定義控制器 允許將自定義邏輯控制引入群集，這些程式可跟Kubernetes API通訊。
- 自動伸縮 ！Kubernetes可以根據需求來伸縮擴充套件你的服務。它使用服務指標來完成此操作，無需人工干預。
但是你需要思考你是否真的需要所有這些功能。你不能僅依靠這些抽象來工作，你必須要了解背後是如何運作的 。
特別是在我們的團隊中，有執行著大多數內部服務（因為它與trivago的核心基礎設施緊密相連），我們不想擔負執行我們自己的Kubernetes叢集。我們只想要提供服務。
鬼使神差
Nomad就是20％的服務編排中能讓你獲得80％所需要的支援的那種。它所做的就只是管理部署。它可以處理你的滾動更新並在出現錯誤時重新啟動容器，僅此而已。
Nomad的意義所在就在於它做得更少 ：它不包括細粒度的許可權管理或高階網路策略，這是設計之初就確定的了。這些元件由第三方提供作為企業服務，或者根本就不存在。
我認為Nomad在易用性和表現力之間取得了一個最佳平衡點。它適用於小型，大多數是獨立的服務。如果你需要更多控制，那麼你必須自己構建它或使用其他方法。Nomad僅僅只是 一個排程器。
關於Nomad一個好的地方是它易於替換 ，幾乎沒有廠商鎖定，因為它提供的功能可以很容易地整合到管理服務的任何其他系統中。它僅僅是在叢集中的每臺機器上運行了個二進位制執行檔案而已！
Nomad生態系統中鬆散耦合的元件
Nomad的真正實力在於其生態系統。它很好地與其他的完全可選的產品整合，例如Consul （一個鍵值儲存）或Vault （用於敏感資料處理）。在Nomad的描述檔案中，你可以使用類似部件從這些服務中獲取資料：
```bash
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
的值並在你的作業中將其暴露給LOG_LEVEL
這個環境變數，同時也從Vault中讀取鍵為secret/geo-api-key
的值暴露為API_KEY
。是不是很簡單明瞭強大！
正因為它非常簡單，Nomad也可以通過其API輕鬆擴充套件其他服務。例如可以標記作業以進行服務發現。在trivago，我們使用trv-metrics
標記所有公開指標的服務。這樣，Prometheus可以通過Consul找到服務，並定期從/metrics
端點收集獲取新資料。同樣的例子是通過整合Loki可以對日誌進行操作 。
除此之外還有許多其他可擴充套件性方面的示例：
- 使用webhook來觸發Jenkins作業，Consul監視並在服務配置變更時重新部署Nomad任務。
- 使用Ceph將分散式檔案系統整合到Nomad。
- 使用fabio 做負載平衡。
所有這一切使我們能夠在沒有太多前期承諾的情況下有機地發展我們的基礎設施 。
友情提醒
沒有任何一個系統是完美的。我建議你當前不要在生產中使用任何花哨的新功能，因為他們存在缺陷 以及（可能）功能不全 ，但Kubernetes 也同樣如此。
與Kubernetes相比，Nomad背後的勢頭要小得多。到目前為止，Kubernetes已經有大約75,000個提交和2000個貢獻者，而Nomad大約是14.000個提交和300個貢獻者。Nomad很難跟上Kubernetes的速度，但也許也沒有必要！覆蓋範圍窄，較小的社群同樣意味著與Kubernetes相比，接受PR會更容易些。
總結
不要僅僅因為其他人都使用Kubernetes你就要去用它，仔細評估你的需求並檢查哪些工具能更符合場景。
如果你計劃在大型基礎架構上部署一系列同質服務，Kubernetes可能是一個正確選擇，但請注意額外的複雜性和運營成本。使用Google Kubernetes Engine 或Amazon EKS 等託管Kubernetes環境可以避免其中一些成本。
如果你只是在尋找一個易於維護和擴充套件的可靠的排程器，我覺得你可以嘗試下Nomad，你可能會驚訝於它到底能給你帶來多少驚喜。
如果說Kubernetes是一輛汽車，那麼Nomad就是一輛摩托車。兩者各有千秋，都有自己的存在權。
【原文連結】Maybe You Don't Need Kubernetes 翻譯：馮旭鬆