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

Kubespray Ansible Playbook 促進協作式 Kubernetes 運維

作者：Rob Hirschfeld (RackN) |

為什麼選擇Kubespray？

讓Kubernetes在操作上強大是一個普遍的優先事項，我一直在跟蹤圍繞該專案的許多部署工作。孵化中的Kubespray專案對我來說特別有意義，因為它利用流行的Ansible工具集在雲和物理目標上構建健壯、可升級的叢集。我相信使用操作人員熟悉的工具可以壯大我們的社群。

我們很高興看到Kubespray所支援的廣泛平臺，以及它如何很好地處理各種選項，例如整合Ceph以實現StatefulSet永續性，以及Helm以簡化應用程式上傳。這些新增功能使我們能夠完全整合OpenStack Helm charts（演示影片）。

透過使用上游原始碼而不是建立不同的安裝指令碼，我們獲得了更大社群的好處。這需要一些額外的開發工作；然而，我們相信幫助分享操作實踐可以使整個社群更加強大。這也是SIG-Cluster Ops的動力。

Kubespray提供了可靠的安裝，我們可以專注於更廣泛的操作問題。

例如，我們現在可以進行並行部署，因此可以同時在開發和測試中充分利用Kubespray啟用的選項。

這有助於在CentOS、Red Hat和Ubuntu上構建-測試-銷燬協調的Kubernetes安裝，作為自動化管道的一部分。我們還可以使用Digital Rebar的提供商、租戶和叢集定義JSON，透過一個命令設定完整的課堂環境。

讓我們探討一下課堂示例

首先，我們像下面的程式碼片段一樣定義JSON中的學生叢集

| {

 "attribs": {

   "k8s-version": "v1.6.0",

   "k8s-kube_network_plugin": "calico",

   "k8s-docker_version": "1.12"

 },

 "name": "cluster01",

 "tenant": "cluster01",

 "public_keys": {

   "cluster01": "ssh-rsa AAAAB..... user@example.com"

 },

 "provider": {

   "name": "google-provider"

 },

 "nodes": [

   {

     "roles": ["etcd","k8s-addons", "k8s-master"],

     "count": 1

   },

   {

     "roles": ["k8s-worker"],

     "count": 3

   }

 ]

} |

然後我們執行Digital Rebar工作負載Multideploy.sh參考指令碼，該指令碼檢查部署檔案以提取關鍵資訊。基本上，它自動化了以下步驟

| rebar provider create {“name”:“google-provider”, [secret stuff]}

rebar tenants create {“name”:“cluster01”}

rebar deployments create [來自cluster01檔案的內容] |

部署建立命令將自動從提供商請求節點。由於我們使用了租戶和SSH金鑰新增，每個學生只能訪問他們自己的叢集。當我們完成時，新增 --destroy 標誌將反轉節點和部署的過程，但保留提供商和租戶。

我們投入到像這個使用Kubespray和Digital Rebar的示例這樣的操作指令碼中，因為如果我們不能以一致的方式管理變體，那麼我們將註定陷入操作碎片化。

我很高興看到並參與社群在雲和本地環境中實現企業級Kubernetes運營的進展。這意味著我看到了可共享/可重用自動化與合理模式的出現。如果您正在部署Kubernetes，即使是實驗規模，我也強烈建議您關注（或更好地，參與協作）這些工作。成為社群的一部分需要更多前期投入，但隨著您獲得共享經驗和改進的好處，回報會非常豐厚。

大規模部署時，您如何設定一個既可重複又多平臺的系統，而又不影響規模或安全性？

有了Kubespray和Digital Rebar作為可重複的基礎，擴充套件變得更快、更容易。更好的是，直接使用上游允許將改進快速迴圈回上游。這意味著我們更接近於建立一個專注於Kubernetes操作方面、具有SRE思維的社群。

如果這讓您感興趣，請與我們聯絡，加入Cluster Ops SIG、Kubespray或Digital Rebar社群。