Weaveworks是如何利用Kubernetes來構建多級部署解決方案的？

Weave Scope是Weaveworks公司推出的一個面向容器化App和服務的虛擬化及監測的開源解決方案。本文介紹了通過Kubernetes構建Weave Scope的整個歷程。

今天，我們聽到Peter Bourgon的（Weaveworks公司軟件工程師）介紹，Weaveworks為軟件開發人員提供在Docker容器中的基于微服務的網絡、監測和控制服務。Peter告訴我們這涉及到選擇和部署Kubernetes。

今年的早些時候，Weaveworks發布了Weave Scope，這是一個為容器化App和服務提供虛擬化與監測的開源解決方案。最近我們在早期的訪問程序當中發布了一個托管服務。今天，我們要介紹該服務的最初原型，以及我們怎樣最終選擇和部署Kubernetes作為我們的平臺。

一個原生云架構

• 一個用戶服務，管理和授權用戶帳戶
• 一個供應服務，管理用戶Scope實例的生命周期
• 一個UI服務，托管所有華麗的HTML和JavaScript內容
• 一個前端服務，根據屬性來發送請求
• 一個監測服務，來監測系統其余部分
</ul>
所有的服務從頭開始都被創建為Docker鏡像。我們想要提供至少3個近乎完全相同的開發環境。


• 一個“飛行模式”的本地環境，可以部署在每一個開發者的個人電腦上
• 一個開發或者臨時環境，不同的用戶憑證可以在同一個基礎設施上管理生產
• 生產環境
</ul>
這些是我們應用的約束條件。接下來，我們需要選擇平臺和開發模式。


我們的第一個原型

看起來我們有無數種不同的選擇，并且還有無數種不同的組合，但在2015年年終進行市場調研之后，我們決定使用的技術棧包括：


• Amazon EC2作為云平臺，包括RDS來確保穩定性。
• Docker Swarm作為我們的“調度器”。
• 在引導Swarm時，利用Consul實現服務搜尋。
• Weave Net作為應用自身的網絡和服務搜尋。
• Terraform作為我們的供應者（Provisioner）。
</ul>
這個架構能夠快速定義和快速部署，可以很好的來驗證我們思路的可行性。但是很快我們遇到了問題。


• Terraform對于Docker作為Provisioner的支持是比較薄弱的，當我們利用它來驅動Swarm時發現了一些bug。
• 主要由于上述的原因，通過Terraform管理部署零宕機的Docker容器是非常困難的。
• Swarm的存在理由是為了抽象多節點容器調度的細節（particulars），它是在我們熟知的Docker CLI/API背后完成的。但是我們給出的結論是，這些API不足以表現出在量化生產當中的需求操作能力。
• Swarm沒有提供容錯機制，比如節點故障。
</ul>
我們在設計工作流（workflow）的時候也犯了很多錯誤。


• 在構建時，我們用每個容器的目標環境標識了容器節點，這樣簡化了Terraform的定義，但是實際上妨礙了我們通過鏡像倉庫來管理架構的版本。
• 因此，每一個配置都需要人工的push到所有的宿主機。這會使得配置過程非常緩慢，而且根本無法接受回滾（rollback）。
• Terraform設計的目的是提供基礎設施，而并不是云應用。這個過程比我們想象的更加的緩慢和嚴謹。傳遞一個新的激勵事件版本需要花費30分鐘，并且要全力以赴。
</ul>
當我們清楚的認識到這個服務的前景時，我們著眼于長遠來重新評估部署模型。


重新將重點定于Kubernates上

雖然只經歷了幾個月，但是Kubernetes的景觀已經發生了很多的變化。


• HashiCorp發布了Nomod
• Kubernetes達到了1.0版本
• Swarm也快到了1.0版本
</ul>
目前我們遇到的許多問題可以在不改變原有基礎架構的條件下解決，所以我們想通過加入一個現有的生態系統以及利用貢獻者在該領域的經驗來在工業上應用這些優勢。

經過一些內部審議，我們針對Nomad和Kubernetes做了一個小規模的實驗。我們相對更喜愛Nomad，但是感覺他太簡單了所以難以確信它是否能在我們的量產服務中勝任。而且我們發現Kubernetes開發者在我們的GitHub論題當中表現得比較突出。因此，我們決定使用 Kubernetes。


本地化Kubernetes

首先，我們要用Kubernetes重構飛行模式的本地化環境。因為開發者們有的使用Mac系統，有的使用Linux系統，所以本地化環境容器化是非常有必要的。于是我們希望將Kubernetes組件（kubelet，API server，等等）自身在容器中運行。

我們遇到了兩個主要問題。第一，也是最常見的，從頭開始構建Kubernetes集群比較困難，因為這需要很深的關于Kubernetes工作機理的知識，而且需要相當一段時間才能使各個小的組件全部構建成功。local-cluster-up.sh似乎是Kubernetes開發者的合理工具，而且不需要利用容器和我們找到的第三方解決方案（比如Kubernetes Solo，需要一個專用的VM或者一個特定的平臺）。

第二個問題，容器化的Kubernetes仍然缺少幾個重要的組件。根據官方的Kubernetes Docker指南構建的是不完善的集群，沒有認證或者服務搜尋。我們還遇到了一些可用性問題(#16586, #17157)，這些問題可以通過提交補丁解決，或者是我們自己在主節點構建hyperkube image來解決。

最后，我們通過構建自己的供應腳本來使得這些應用能夠正常工作。這需要嘗試做很多工作，像生成PKI keys和certificates，以及提供DNS擴展等等。我們還學到了如何將證書生成提交到Docker構建當中，所以下一個階段會更簡單。


Kubernetes on AWS

接下來，我們要將Kubernetes部署到AWS上，并且接通其他的AWS組件。為了讓這個服務快速的在生產環境上實現，而且我們僅僅需要該服務支持Amazon就可以了，因此我們決定不利用Weave Net，而用我們已有的供應方案。但是在不久的將來我們肯定會再次回顧這個方案上，通過Kubernetes插件使用Weave Net。

理想上我們是要用到Terraform資源，而且我們發現了幾個地方有用到：karaken(利用Ansible)，kubestack(耦合的GCE)，kubernetes-coreos-terraform（過時的Kubernetes）以及coreos-kubernetes。但是他們都構建在CoreOS上，而我們從一開始就希望避免這一部分額外的變動。（在我們的下一次實驗當中，我們可能會測試CoreOS。）如果你使用Ansible，你會在主repo上看到應用指南。另外會有開源社區發布的cookbooks和Puppet modules。我希望這些社區能夠快速的成長起來。

其他可行的選擇似乎只有是kube-up，這是一個收集腳本，提供Kubernetes到各種各樣的云供應商。默認情況下，kube-up在 AWS上將主、從節點放在他們自身的VPC當中，或者放在虛擬私有云上。但是我們的RDS實例被提供到默認域的VPC上，這意味著從Kubernetes 從屬節點到DB的通信將有可能僅僅通過VPC peering或者是人工的通過開放的RDS VPC防火墻規則來實現。

為了讓信息通過VPC點鏈接，你的目地IP需要在目標VPC的主地址范圍之內。但是事實上，從相同的VPC外部的任何地方解析RDS實例主機名都將屈從于公共IP。而且這個問題能夠解決是非常重要的，因為RDS為了維護而保留了修改IP的權利。我們之前的基礎架構根本不涉及這個問題，因為Terraform腳本簡單的將所有東西都放在同一個VPC當中。因此，我試著用Kubernetes效仿，kube-up支持通過指定一個VPC_ID環境變量來安裝現有的VPC，于是我試著將Kuberbetes安裝到RDS VPC。kube-up成功的實現了，但是通過ELB的服務集成掛掉了，而且經由kube-down的服務停止工作了。之后，我們認為讓kube-up保持默認方式是最好的選擇，進而將問題轉移到RDS VPC上 。

這成為我們遇到的問題中的一個障礙。每一個問題都可以通過隔離來修復，但是利用shell腳本提供遠程狀態（remote state）這個固有的脆弱性貌似是問題存在的實際根本原因。我們希望Terraform，Ansible，Chef，Puppet等等packages 不斷的成熟，迅速的轉換。

除了供應，還有好多關于Kubernetes/AWS融合的事情要做。比如，正確類型的Kubernetes 服務自動生成ELB，Kubernetes的確在生命周期的管理上做了很多工作。進一步，Kubernetes的模型領域——服務，pods，replication controller，標簽選擇器模型等等都是耦合的，而且看起來給了用戶適量的表現性，雖然定義文件確實很啰嗦沒什么必要。kubectl這個工具很不錯，盡管乍一看令人生畏。其中rolling-update命令尤其是絕妙的：精確的語義和表現是我希望系統能具備的。確實，一旦Kubernetes啟動運行，它就開始工作，這恰恰是我期望的。這是一件偉大的事情。


結論

經過幾周與機器的戰役，我們解決了所有的關于Kubernetes/AWS融合的問題，而且我們推出了用于生產的一個合理健壯的基于Kubernetes的系統。


• Kubernetes供應是非常艱難的，因為復雜的自身架構和不足的供應歷練。這顯示出了我們需要改善的地方。
• Kubernetes的非選擇性安全模式需要很長時間才能準確完成。
• Kubernetes領域語言的發展能夠跟得上問題的產生。
• 我們在操作我們的應用方面非常的有自信（而且會變得更快）。
• 我們非常高興來提高Kubernets的廣泛使用性，貢獻論題以及補丁，而且得益于開源開發的良性循環，我們才能寫出如此令人興奮的軟件。
</ul>
——Peter Bourgon，Weaveworks公司軟件工程師

Weave Scope是一個面向容器化App和服務的虛擬化及監測的開源解決方案。對于一個Scope服務宿主機，可以在早期的訪問程序中從scope.weave.works申請一個服務邀請。

原文鏈接： How Weave built a multi-deployment solution for Scope using Kubernetes（翻譯：edge_dawn）

來自：http://dockone.io/article/907