本篇文章已發布超過一年。較舊的文章可能包含過時的內容。請確認本頁面中的資訊自發布以來未變得不正確。

Kubespray Ansible Playbook 促進協作 Kubernetes 運維

為何選擇 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 workloads Multideploy.sh 參考腳本,該腳本會檢查部署檔案以提取關鍵資訊。 基本上,它會自動執行以下步驟

| rebar provider create {“name”:“google-provider”, [機密內容]}

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

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

deployments create 命令將自動向供應商請求節點。由於我們使用租戶和 SSH 金鑰新增,因此每位學生只能存取自己的叢集。完成後,新增 --destroy 標誌將反轉節點和部署的程序,但保留供應商和租戶。

我們投入使用 Kubespray 和 Digital Rebar 等操作腳本,因為如果我們無法以一致的方式管理變異,那麼我們注定會面臨運作上的碎片化。 

我很高興看到並參與社群朝向企業級 Kubernetes 運作在雲端和地端部署方面的進展。這表示我看到合理的模式隨著可共享/可重複使用的自動化而出現。如果您正在部署 Kubernetes,即使是實驗規模,我也強烈建議關注 (或更好的是,參與) 這些努力。成為社群的一份子需要更多的前期投入,但當您獲得共享經驗和改進的好處時,就會獲得回報。

在大規模部署時,如何在不影響規模或安全性的情況下,設定一個可重複且跨平台的系統?

以 Kubespray 和 Digital Rebar 作為可重複的基礎,擴展變得更快更輕鬆。更好的是,直接使用上游允許將改進快速循環回上游。這表示我們更接近建立一個社群,專注於 Kubernetes 的運作方面,並具有 SRE 思維模式

如果您對此感興趣,請加入我們的 Cluster Ops SIGKubespray 或 Digital Rebar 社群。