許多開發者已經求助于Docker容器來實現云端和本地的新應用迭代時的一致性，而且很多應用都要依賴多個Docker容器的編排。而圍繞著容器集的啟動以及為了讓它們能夠協作而連帶的相關設置和配置又引發了一系列新的挑戰。

為了彌補這一差距，軟件產業一直在向容器管理系統Kubernetes靠攏，它承擔了生態體系的職能，實現對容器集的自動化部署。在舊金山舉行的KubeCon會議上，專家們討論了其中一些基于Kubernetes的集群自動化部署的***實踐和工具。

Univa工程總監Cameron Brunner說創建Kubernetes有很多很好的工具，但對一致的集群自動化部署卻沒有好的路徑。“我們喜歡把硬件當作家畜來看待，” Brunner說：“這個我們在app上面一直都是這么聽說的。但把你的硬件當作寵物會導致令人不快的內部管理問題。”

Univa內部大約有5個集群在跑Kubernetes，每一個都包括多個節點。有一條可靠的工具鏈有助于快速生成符合一致性的Kubernetes集群，快到能夠在數分鐘內開發和啟動。

Brunner說組織需要應對一下問題才能生成一個一致可靠的Kubernetes集群：

1. 從什么樣的基礎操作系統開始?
2. 該操作系統是怎么部署和配置的?
3. Kubernetes打算怎樣安裝和配置?

幸運的是，環境中有許多工具支持這一過程，Brunner說。像Atomic和CoreOS這樣的不變操作系統已經變得相當穩定。預引導執行環境(PXE boot)未來啟動技術可以簡化部署。Cloud-Init是一個很好的啟動時配置工具。

建立一致性

Brunner建議要一直通過網絡啟動你的硬件。這可以在機器出問題或需要升級時快速進行服務開通的再次準備。PXE啟動有助于簡化這一過程。理想情況下，好的做法是有一個工具去動態生成PXE，而這個東西不是跟PXE一起的。

安裝不變的操作系統也是一個好的做法。這可以在數據中心做出一致的軟件集和一致的環境。Brunner說：“這降低了總體的管理復雜性，理解集群中發生的事情更容易。”

在本地托管容器鏡像也是好想法。Brunner建議要有一個本地庫。另一個好做法是用Cloud-Init管理配置。這樣把所有東西放在一個地方會更簡單，同時還能有一個不變的OS。這可以用Systemd來集成，完成證書登記、密鑰提取等輔助操作，從而建立一條系統啟動操作的流水化的工作流。

AWS自動化Kubernetes

舊金山的程序員Jimmy Cuadra說，在AWS上面以一致的方式部署Kubernetes集群是個挑戰。他說，“操作生產集群這個東西我不敢信任，哪怕我尊重Kubernetes團隊的艱苦工作。對于我們這些需要管理自己集群的人來說，我們需要更健壯的東西。”

Cuadra說，對于在托管應用上面運行來說，Google Container Engine是個好的選擇。但在AWS上面進行集群的自動化部署需要更健壯的辦法。該問題部分在于與集群的聲明式配置工具相關的大多數信息已經過時或包含有失效鏈接。Cuadra希望能夠利用聲明式配置文件，在Git上登記生成集群。

Cuadra建議用Hashicorp的Terraform。它允許組織使用聲明式配置語言去買搜狐資源以及云基礎設施的狀態，從而匹配Git庫里面的東西。

控制配置復雜性

部署Kubernetes集群方面有很多服務開通問題，這些不是Terraform容易解決的。需要有特別的配置設置來描述容器間相互對話的不同。還要有其他的設置來指定如何對Kubernetes API進行鑒權，給團隊不同的人提供分布式訪問證書。保持多個Kubernetes實現的狀態的工作流也需要管理。

為了填補這一差距，Cuadra開發了一個名為KAWS的開源工具，它可以更容易地指定基礎設施為代碼，且內置一個域名系統。它還生成Kubernetes訪問證書，并可以安全地把它分發出去。KAWS是用Rust編程語言開發的。

自動化Kubernetes部署的過程從KAWS庫(基本上就是一個創建狀態的Git庫)的創建開始。它還包括了一個密鑰導出命令，可以管理團隊成員的公鑰。這樣就可以無需暴露各人私鑰的情況下管理用戶訪問了。Cuadra說此類自動化辦法使得在10分鐘內籌劃和部署一個新的Kubernetes集群成為可能。

原文鏈接：http://www.searchsoa.com.cn/showcontent_91719.htm