也許你不需要Kubernetes？-matthias

banq發表於2019-03-27

Kubernetes是800磅重的容器編排大猩猩。它為全球一些最大的部署提供支援，但它帶有價格標籤。
特別是對於規模較小的團隊而言，維護並且學習曲線陡峭可能非常耗時。對於我們四人團隊想要在trivago實現的目標，它增加了太多的開銷。所以我們研究了另類 - 並愛上了 Nomad。

我們的團隊執行了許多用於監控和效能分析的典型服務：用Go，Prometheus匯出器，Logstash或Gollum等日誌解析器以及InfluxDB或Elasticsearch等資料庫編寫的度量標準的API端點。每個服務都在自己的容器中執行。我們需要一個簡單的系統來保持這些工作的執行。

我們從容器編排的要求列表開始：
  • 在許多機器上執行一系列服務。
  • 提供正在執行的服務的概述。
  • 允許服務之間的通訊。
  • 當機後會自動重啟。
  • 由小團隊管理。

最重要的是，以下事情很好，但並非嚴格要求：
  • 根據功能標記機器（例如，帶有快速磁碟的標籤機，用於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或亞馬遜管理，但有能力這樣做。
Kubernetes具有驚人的功能，使大規模的容器編排更易於管理：

  • 細粒度的許可權管理
  • 自定義控制器允許將邏輯引入群集。這些只是與Kubernetes API對話的程式。
  • 自動縮放！Kubernetes可以根據需要上下調整您的服務。它使用服務指標來完成此操作，無需人工干預。

問題是你是否真的需要所有這些功能。你不能依靠這些抽象來工作; 你必須要了解幕後發生了什麼。
特別是在我們的團隊中，它執行大多數內部服務（因為它與trivago的核心基礎設施緊密相連），我們不想負擔執行我們自己的Kubernetes叢集。我們想要提供服務。

Nomad
Nomad是20％的服務編排，可以讓您獲得80％的支援。它所做的只是管理部署。它可以處理您的卷展欄並在出現錯誤時重新啟動容器，這就是它。
Nomad的全部意義在於它做得更少：它不包括細粒度的許可權管理或高階網路策略，這是設計的。這些元件由第三方提供為企業服務，或者根本不提供。
我認為Nomad在易用性和表現力之間達到了一個甜蜜點。它適用於小型，大多數是獨立的服務。如果您需要更多控制，您必須自己構建它或使用不同的方法。Nomad 只是一個協調者。
關於Nomad最好的部分是它易於更換。幾乎沒有供應商鎖定，因為它提供的功能可以很容易地整合到管理服務的任何其他系統中。它只是在叢集中的每臺機器上作為普通的舊單二進位制執行而已！

Nomad生態系統中鬆散耦合的元件
Nomad 的真正力量在於其生態系統。它與其他 - 完全可選 - 的產品很好地整合，例如Consul（一個鍵值儲存）或 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輕鬆擴充套件其他服務。例如，可以標記作業以進行服務發現。在trivago，我們標記所有公開指標的服務trv-metrics。這樣，Prometheus透過Consul找到服務，並定期搜尋/metrics端點以獲取新資料。例如，透過整合Loki可以對日誌進行相同的操作 。
還有許多其他可擴充套件性示例：
  • 使用webhook和Consul監視觸發Jenkins作業，以便在服務配置更改時重新部署Nomad作業。
  • 使用Ceph將分散式檔案系統新增到Nomad。
  • 使用fabio進行負載平衡。

所有這一切使我們能夠在沒有太多前期承諾的情況下有機地發展我們的基礎設施。

公平的警告
沒有系統是完美的。我建議你現在不要在生產中使用任何花哨的新功能。當然有缺陷和缺失的功能 - 但Kubernetes也是如此。
與Kubernetes相比，Nomad背後的動力要小得多。到目前為止，Kubernetes已經看到大約75,000個提交和2000個貢獻者，而Nomad體育大約14.000個提交和300個貢獻者。Nomad很難跟上Kubernetes的速度，但也許它沒有必要！範圍要窄得多，較小的社群也意味著與Kubernetes相比，接受拉取請求會更容易。

總結
要點是：不要僅僅因為其他人都使用Kubernetes而使用它。仔細評估您的要求並檢查哪種工具符合要求。
如果您計劃在大型基礎架構上部署一系列同質服務，Kubernetes可能就是您的選擇。請注意額外的複雜性和運營成本。使用Google Kubernetes Engine或Amazon EKS等託管Kubernetes環境可以避免其中一些成本。
如果你只是在尋找一個易於維護和擴充套件的可靠的協調器，為什麼不試試Nomad呢？你可能會驚訝於它能帶給你多遠。
如果Kubernetes是一輛汽車，Nomad將成為一輛摩托車。有時你更喜歡一個，有時候另一個。兩者都有自己的存在權。

相關文章