本文發表於一年多前。舊文章可能包含過時內容。請檢查頁面中的資訊自發布以來是否已變得不正確。

Weave 如何使用 Kubernetes 為 Scope 構建多部署解決方案

作者：Peter Bourgon (Weaveworks) |

今年早些時候，Weaveworks 推出了 Weave Scope，這是一個用於容器化應用和服務視覺化和監控的開源解決方案。最近，我們將託管的 Scope 服務釋出到 早期訪問計劃 中。今天，我們想向您介紹我們最初是如何原型化該服務的，以及我們最終如何選擇並部署 Kubernetes 作為我們的平臺。

雲原生架構

Scope 在資料收集和使用者互動之間已經有清晰的內部界限，因此很方便地沿著這條線拆分應用程式，將探測器分發給客戶，並在雲中託管前端。我們根據 12 因素模型 構建了一小組微服務，其中包括：

  • 使用者服務，用於管理和驗證使用者賬戶
  • 供應服務，用於管理客戶 Scope 例項的生命週期
  • UI 服務，託管所有精美的 HTML 和 JavaScript 內容
  • 前端服務，根據請求屬性路由請求
  • 監控服務，用於內省系統的其餘部分

所有服務都構建為 Docker 映象，儘可能 基於 scratch。我們知道我們至少要提供 3 個部署環境，並且這些環境應該儘可能相同。

  • “飛航模式”本地環境，在每個開發人員的筆記型電腦上
  • 開發或暫存環境，與生產環境相同的基礎設施上，但使用不同的使用者憑據
  • 生產環境本身

這些是我們的應用程式不變式。接下來，我們必須選擇我們的平臺和部署模型。

我們的第一個原型

有看似無限的選擇，以及無限的可能性組合。在 2015 年中期對情況進行調查後，我們決定使用以下元件製作一個原型：

  • Amazon EC2 作為我們的雲平臺，包括用於持久化的 RDS
  • Docker Swarm 作為我們的“排程器”
  • Consul 用於引導 Swarm 時的服務發現
  • Weave Net 用於我們的網路和應用程式本身的服務發現
  • Terraform 作為我們的供應器

這個設定定義和部署都很快，所以它是驗證我們想法可行性的好方法。但是我們很快就遇到了問題。

  • Terraform 對 Docker 作為供應器 的支援非常基礎，我們在嘗試使用它來驅動 Swarm 時發現了一些 bug。
  • 很大程度上由於上述原因，使用 Terraform 管理 Docker 容器的零停機部署非常困難。
  • Swarm 的 存在理由 是將多節點容器排程的細節抽象到熟悉的 Docker CLI/API 命令之後。但是我們得出結論，該 API 對於生產規模所需的各種操作來說表達能力不足。
  • Swarm 在節點故障等情況下不提供容錯能力。

我們在設計工作流程時也犯了一些錯誤。

  • 我們在構建時為每個容器標記了其目標環境，這簡化了我們的 Terraform 定義，但實際上迫使我們透過映象倉庫管理版本。這個職責屬於排程器，而不是製品儲存庫。
  • 結果是，每次部署都需要將製品推送到所有主機。這使得部署緩慢，回滾難以忍受。
  • Terraform 旨在供應基礎設施，而不是雲應用程式。這個過程比我們想要的更慢、更刻意。將新版本的東西釋出到生產環境大約需要 30 分鐘，包括所有步驟。

當服務顯示出潛力時，我們重新評估了部署模型，著眼於長期發展。

基於 Kubernetes 重構

僅僅幾個月，情況就發生了很大變化。

  • HashiCorp 釋出了 Nomad
  • Kubernetes 釋出了 1.0 版本
  • Swarm 即將釋出 1.0 版本

雖然我們的大部分問題都可以透過不進行根本性架構更改來解決，但我們希望透過加入現有生態系統，並利用其貢獻者的經驗和辛勤工作，來利用行業進步。

經過內部討論，我們對 Nomad 和 Kubernetes 進行了小規模的試用。我們非常喜歡 Nomad，但覺得現在就將其用於我們的生產服務還為時過早。此外，我們發現 Kubernetes 的開發人員對 GitHub 上的問題響應最積極。因此，我們決定選擇 Kubernetes。

本地 Kubernetes

首先，我們將使用 Kubernetes 複製我們的飛航模式本地環境。因為我們的開發人員使用 Mac 和 Linux 筆記型電腦，所以本地環境必須容器化。因此，我們希望 Kubernetes 元件本身（kubelet、API 伺服器等）在容器中執行。

我們遇到了兩個主要問題。首先，也是最普遍的，從頭開始建立 Kubernetes 叢集很困難，因為它需要對 Kubernetes 的工作原理有深入的瞭解，並且需要相當長的時間才能將各個部分組合在一起。local-cluster-up.sh 看起來更像是 Kubernetes 開發人員的工具，並且沒有利用容器，而我們找到的第三方解決方案，如 Kubernetes Solo，需要專用的虛擬機器或具有平臺特定性。

其次，容器化的 Kubernetes 仍然缺少幾個重要的部分。遵循 官方 Kubernetes Docker 指南 會產生一個沒有證書或服務發現的裸機叢集。我們還遇到了幾個可用性問題（#16586、#17157），我們透過 提交補丁 並從主分支構建我們自己的 hyperkube 映象 來解決這些問題。

最後，我們透過建立自己的供應指令碼使其正常工作。它需要做一些事情，例如 生成 PKI 金鑰和證書 和 供應 DNS 附加元件，這花了幾次嘗試才弄對。我們還了解到有一個 提交，將證書生成新增到 Docker 構建中，因此在不久的將來情況可能會變得更容易。

AWS 上的 Kubernetes

接下來，我們將 Kubernetes 部署到 AWS，並將其與其他的 AWS 元件連線起來。我們希望快速在生產環境中啟動服務，並且我們只需要支援 Amazon，所以我們決定不使用 Weave Net，而是使用一個預先存在的供應解決方案。但我們肯定會在不久的將來重新審視這個決定，透過 Kubernetes 外掛利用 Weave Net。

理想情況下，我們會使用 Terraform 資源，我們找到了幾個：kraken（使用 Ansible）、kubestack（與 GCE 耦合）、kubernetes-coreos-terraform（過時的 Kubernetes）和 coreos-kubernetes。但它們都基於 CoreOS，這是我們一開始想避免的額外移動部件。（在我們的下一次迭代中，我們可能會試用 CoreOS。）如果您使用 Ansible，主倉庫中提供了 playbooks。還有社群驅動的 Chef cookbooks 和 Puppet modules。我預計社群在這裡會快速發展。

唯一其他可行的選擇似乎是 kube-up，它是一組將 Kubernetes 部署到各種雲提供商的指令碼。預設情況下，kube-up 將主節點和從屬節點部署到 AWS 上的獨立 VPC（虛擬私有云）中。但我們的 RDS 例項是在區域預設 VPC 中部署的，這意味著 Kubernetes 從屬節點與資料庫的通訊只能透過 VPC 對等連線 或手動開啟 RDS VPC 的防火牆規則來實現。

為了讓流量透過 VPC 對等鏈路傳輸，您的目標 IP 需要在目標 VPC 的私有地址範圍內。但 事實證明，從同一個 VPC 之外的任何地方解析 RDS 例項的主機名都會得到公共 IP。執行解析很重要，因為 RDS 保留更改維護 IP 的權利。這在以前的基礎設施中從未成為問題，因為我們的 Terraform 指令碼只是將所有內容放在同一個 VPC 中。所以我嘗試在 Kubernetes 上做同樣的事情；kube-up 指令碼表面上支援透過指定 VPC_ID 環境變數安裝到現有 VPC，所以我嘗試將 Kubernetes 安裝到 RDS VPC。kube-up 似乎成功了，但是 透過 ELB 的服務整合中斷，並且 透過 kube-down 拆除停止工作。一段時間後，我們認為最好讓 kube-up 保持其預設設定，並在 RDS VPC 中開一個口子。

這是我們遇到的幾個小問題之一。每個問題都可以單獨修復，但使用 shell 指令碼來提供遠端狀態固有的脆弱性似乎是實際的根本原因。我們完全期望 Terraform、Ansible、Chef、Puppet 等軟體包繼續成熟，並希望儘快切換。

除了供應之外，Kubernetes/AWS 整合還有很多優點。例如，正確型別的 Kubernetes 服務 會自動生成 ELB，並且 Kubernetes 在生命週期管理方面做得非常出色。此外，Kubernetes 領域模型——服務、Pod、複製控制器、標籤和選擇器模型 等等——是連貫的，並且似乎為使用者提供了恰到好處的表達能力，儘管定義檔案確實 傾向於不必要地重複。kubectl 工具很好用，儘管 乍一看令人望而生畏。特別是 滾動更新 命令非常出色：這正是這種系統我所期望的語義和行為。事實上，一旦 Kubernetes 啟動並執行，它就能正常工作，並且完全符合我的預期。這是一個巨大的進步。

結論

經過幾周與機器的搏鬥，我們解決了所有的整合問題，併成功將一個相當健壯的基於 Kubernetes 的系統部署到生產環境。

  • Kubernetes 的供應很困難，這歸因於複雜的架構和尚處於發展初期的供應方案。這顯示出所有改進的跡象。
  • Kubernetes 的非可選安全模型需要時間才能正確設定。
  • Kubernetes 的領域語言與問題領域非常匹配。
  • 我們對操作應用程式更有信心了（而且速度也快了很多）。
  • 我們非常高興能成為不斷壯大的 Kubernetes 使用者群的一員，儘可能地貢獻問題和補丁，並受益於驅動當今最激動人心的軟體開發的開源良性迴圈。

Weave Scope 是一個用於容器化應用和服務視覺化和監控的開源解決方案。如需託管的 Scope 服務，請訪問 scope.weave.works 申請早期訪問計劃邀請。