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

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

「作者：Peter Bourgon (Weaveworks) | 」

「今年稍早，Weaveworks 推出了 Weave Scope，這是一個用於視覺化和監控容器化應用程式和服務的開源解決方案。最近，我們將託管的 Scope 服務發布到 Early Access Program 中。今天，我們想帶您了解我們最初如何為該服務建立原型，以及我們最終如何選擇並部署 Kubernetes 作為我們的平台。」

「雲原生架構 」

「Scope 在資料收集和使用者互動之間已經有清晰的內部分界線，因此可以很直接地沿著這條線拆分應用程式，將探針分發給客戶，並在雲端託管前端。我們依照 十二要素應用程式 模型建構了一小組微服務，其中包括」

  • 「使用者服務，用於管理和驗證使用者帳戶 」
  • 「佈建服務，用於管理客戶 Scope 實例的生命週期 」
  • 「UI 服務，託管所有精美的 HTML 和 JavaScript 內容 」
  • 「前端服務，根據請求的屬性路由請求 」
  • 「監控服務，用於檢視系統的其餘部分 」

「所有服務都建構為 Docker 映像檔，盡可能 FROM scratch。我們知道我們想要提供至少 3 個部署環境，這些環境應該盡可能接近相同。」

  • 「「飛航模式」本機環境，在每位開發人員的筆記型電腦上 」
  • 「開發或預備環境，與託管生產環境的基礎設施相同，但具有不同的使用者憑證 」
  • 「生產環境本身 」

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

「我們的第一個原型 」

「選擇似乎有無窮無盡的組合。在 2015 年年中調查了情況後，我們決定製作一個原型，使用」

  • 「Amazon EC2 作為我們的雲平台，包括用於持久性的 RDS 」
  • 「Docker Swarm 作為我們的「排程器」 」
  • 「Consul 用於在引導 Swarm 時進行服務發現 」
  • 「Weave Net 用於我們的網路和應用程式本身的服務發現 」
  • 「Terraform 作為我們的佈建器 」

「此設定易於定義且部署快速，因此是驗證我們想法可行性的絕佳方法。但我們很快就遇到了問題。」

  • 「Terraform 對 Docker 作為佈建器 的支援非常基礎，而且當我們嘗試使用它來驅動 Swarm 時，發現了 一些錯誤。」
  • 「主要是由於上述原因，使用 Terraform 管理 Docker 容器的零停機部署非常困難。」
  • 「Swarm 的 raison d'être 是將多節點容器排程的細節抽象化在熟悉的 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，需要專用的 VM 或特定於平台。」

「其次，容器化的 Kubernetes 仍然缺少幾個重要的部分。遵循 官方 Kubernetes Docker 指南 會產生一個沒有憑證或服務發現的簡陋叢集。我們還遇到了一些可用性問題 (#16586, #17157)，我們透過 提交修補程式 並從 master 建置我們自己的 hyperkube 映像檔 來解決這些問題。」

「最後，我們透過建立我們自己的佈建腳本來使事情正常運作。它需要執行諸如 產生 PKI 金鑰和憑證 以及 佈建 DNS 附加元件 等操作，這花費了一些嘗試才正確。我們還了解到有一個 commit 將憑證產生新增到 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，則主要儲存庫中有 可用的劇本。還有社群驅動的 Chef 食譜 和 Puppet 模組。我預計社群在這裡會快速成長。」

「唯一另一個可行的選擇似乎是 kube-up，它是一組將 Kubernetes 佈建到各種雲端供應商的腳本集合。預設情況下，kube-up 到 AWS 會將 master 和 minion 節點放入它們自己的 VPC 或虛擬私有雲中。但我們的 RDS 實例是在區域預設 VPC 中佈建的，這表示從 Kubernetes minion 到 DB 的通訊只能透過 VPC peering 或手動開啟 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、Replication Controller、標籤和選擇器模型 等 — 是一致的，並且似乎給使用者提供了適當的表達能力，儘管定義檔案確實 傾向於不必要地重複。kubectl 工具很好，儘管 乍看之下令人望而生畏。rolling-update 命令尤其出色：完全符合我對此類系統的語意和行為的期望。實際上，一旦 Kubernetes 啟動並執行，它就能正常運作，而且完全符合我的預期。這是一件大事。」

「結論 」

「在與機器奮鬥了幾個星期後，我們能夠解決我們所有的整合問題，並已將一個相當穩健的基於 Kubernetes 的系統推向生產環境。」

  • 「佈建 Kubernetes 很困難，這是由於複雜的架構和年輕的佈建歷程造成的。這顯示出所有改進的跡象。」
  • 「Kubernetes 的非可選 安全性模型需要時間才能正確設定。」
  • 「Kubernetes 的 網域語言與問題網域非常匹配。」
  • 「我們對操作我們的應用程式更有信心（而且速度也快得多）。」
  • 「而且我們非常高興能成為不斷成長的 Kubernetes 使用者群體的一份子，盡我們所能貢獻問題和修補程式，並從開源開發的良性循環中受益，這推動了當今正在編寫的最令人興奮的軟體。」

「Weave Scope 是一個用於視覺化和監控容器化應用程式和服務的開源解決方案。對於託管的 Scope 服務，請在 scope.weave.works 申請加入 Early Access program。」