Kubernetes 是 container orchestration（容器編排）領域中舉足輕重的霸主。
它驅動著全球一些最大規模的部署，但也伴隨著不小的代價。

尤其對較小的團隊而言，維護它既耗時，學習曲線也相當陡峭。對於我們這個在 trivago 的四人團隊想要達成的目標來說，它帶來了過多的額外負擔。因此我們開始尋找替代方案——並愛上了 Nomad。

願望清單

我們的團隊運行許多用於監控與效能分析的典型服務：以 Go 撰寫的指標用 API 端點、Prometheus exporter、像是 Logstash 或 Gollum 的日誌解析器，以及像是 InfluxDB 或 Elasticsearch 的資料庫。這些服務各自運行在獨立的容器中。我們需要一套簡單的系統來讓這些任務持續運行。

我們首先列出了對 container orchestration 的需求清單：

• 在多台機器上運行一組服務。
• 提供運行中服務的總覽。
• 允許服務之間互相通訊。
• 在服務當機時自動重新啟動。
• 可由小團隊進行管理。

除此之外，以下幾點是加分項，但並非必要：

• 依機器的能力為其加上標籤（例如，為 I/O 密集的服務標記配備高速磁碟的機器）。
• 能夠獨立於任何編排器運行這些服務（例如在開發環境中）。
• 有一個可共用設定與密鑰的集中位置。
• 提供用於指標與日誌的端點。

為什麼 Kubernetes 不適合我們

在用 Kubernetes 建立原型時，我們發現自己開始為了運行服務而不斷疊加愈來愈複雜的邏輯層。而我們也開始隱含地依賴這些邏輯。

舉例來說，Kubernetes 允許使用 ConfigMaps 嵌入服務設定。特別是在合併多個設定檔或在一個 pod 中加入更多服務時，情況很快就會變得相當混亂。Kubernetes——或者說 helm——允許動態注入外部設定，以確保關注點分離。但這可能導致你的專案與 Kubernetes 之間產生緊密、隱含的耦合。Helm 和 ConfigMaps 都是選用功能，你不一定要使用它們。你大可直接把設定檔複製到 Docker image 中。然而，走上這條路並建構不必要的抽象層是很誘人的，日後可能會讓你自食其果。

除此之外，Kubernetes 生態系仍在快速演進。要跟上最佳實務與最新工具，需要花費相當多的時間與精力。Kubectl、minikube、kubeadm、helm、tiller、kops、oc——名單落落長。並非所有工具都是入門 Kubernetes 的必要條件，但很難判斷哪些才是，因此你至少得對它們有所了解。正因如此，學習曲線相當陡峭。

何時該使用 Kubernetes

在 trivago，許多團隊使用 Kubernetes 且對此相當滿意。不過，這些實例是由 Google 或 Amazon 代管的，他們才有能力做到這一點。

Kubernetes 具備許多令人驚豔的功能，讓大規模的 container orchestration 更易於管理：

• 細緻的 rights management（權限管理）
• Custom controllers（自訂控制器）可讓你將邏輯帶入叢集。這些其實就是與 Kubernetes API 溝通的程式。
• Autoscaling（自動擴縮容）！Kubernetes 能依需求自動擴展或縮減你的服務。它利用服務指標在無需人工介入的情況下完成這件事。

問題在於，你是否真的需要所有這些功能。你不能指望這些抽象層就能自動正常運作；你必須了解底層究竟發生了什麼事。

特別是像我們這樣多數服務都運行在地端（on-premise）（因為與 trivago 核心基礎架構緊密相連）的團隊，我們不想負擔自行維運 Kubernetes 叢集的成本；我們只想專注於交付服務。

不含電池

Nomad 僅涵蓋 service orchestration（服務編排）中 20% 的功能，卻能讓你完成 80% 的工作。它所做的只有管理部署。它負責處理你的版本發布，並在出錯時重新啟動容器，僅此而已。

Nomad 的核心精神就在於它做得更少：它不包含細緻的 rights management 或進階的 network policies（網路原則），而這是刻意為之的設計。這些元件由企業服務、第三方提供——或者根本不提供。

我認為 Nomad 在易用性與表達能力之間取得了絕佳的平衡。它非常適合小型、大多相互獨立的服務。如果你需要更多的控制能力，就必須自行打造或採用不同的方法。Nomad 就只是一個編排器。

Nomad 最棒的一點在於它很容易被替換。幾乎沒有 vendor lock-in（廠商鎖定）的問題，因為它提供的功能可以輕易整合到任何其他管理服務的系統中。它只是在叢集中的每台機器上以一個平凡的單一二進位檔執行，僅此而已！

由鬆散耦合元件組成的 Nomad 生態系

Nomad 真正的威力在於其生態系。它與其他——完全選用性的——產品整合得非常好，例如 Consul（一種 key-value store（鍵值儲存））或 Vault（用於密鑰管理）。在你的 Nomad 檔案中，你可以加入用於從這些服務擷取資料的區段：

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 輕鬆地與其他服務擴充。例如，可以為任務加上標籤以進行 service discovery（服務探索）。在 trivago，我們為所有會公開指標的服務加上 trv-metrics 標籤。如此一來，Prometheus 便能透過 Consul 找到這些服務，並定期抓取 /metrics 端點以取得新資料。同樣地，也可以透過整合 Loki 來對日誌做相同的處理。

還有許多其他可擴充性的範例：

• 使用 webhook 與 Consul watches 觸發 Jenkins 任務，以便在服務設定變更時重新部署你的 Nomad 任務。
• 使用 Ceph 為 Nomad 加入分散式檔案系統。
• 使用 fabio 進行 load balancing（負載平衡）。

這一切讓我們得以在無需過多前期投入的情況下，有機地擴展我們的基礎架構。

溫馨提醒

沒有任何系統是完美的。我建議你目前不要在正式環境中使用任何花俏的新功能。當然會有錯誤和缺失的功能——但Kubernetes 也是如此。

相較於 Kubernetes，Nomad 背後的動能要小得多。Kubernetes 至今已累積約 75,000 次提交與 2000 位貢獻者，而 Nomad 則約有 14,000 次提交與 300 位貢獻者。Nomad 要跟上 Kubernetes 的開發速度會很困難，但或許它根本不需要！其範疇要窄得多，而較小的社群也可能意味著，相較於 Kubernetes，你的 pull request 更容易被接受。

總結

重點是：不要只因為大家都在用 Kubernetes，你就跟著用。請仔細評估你的需求，檢視哪種工具最符合要求。

如果你打算在大規模基礎架構上部署一組同質的服務，Kubernetes 或許是正確的選擇。只是要留意額外的複雜度與維運成本。透過使用像 Google Kubernetes Engine 或 Amazon EKS 這類代管式 Kubernetes 環境，可以省去其中部分成本。

如果你只是在尋找一個可靠、易於維護且可擴充的編排器，何不試試 Nomad？你可能會驚訝它能帶你走多遠。

如果把 Kubernetes 比作汽車，Nomad 就像是速克達。有時你會偏好其中一種，有時則是另一種。兩者都有其存在的價值。