基於Python+Django的Kubernetes集羣管理平臺

原文出自【聽雲技術博客】:http://blog.tingyun.com/web/a...
時至今日,接觸kubernetes也有一段時間了,而咱們的大部分業務也已經穩定地運行在不一樣規模的kubernetes集羣上,不得不說,不管是從應用部署、迭代,仍是從資源調度管理等方面都有其難以言喻的優點,可是隨着業務的不斷增加,以及服務的多元化,容器的體量與管理的難度也隨之增加。前端

淺述Kubernetes集羣平常管理維護中的一些痛點:node

1.較爲龐大的集羣規模及容器數量維護管理。web

咱們公司的業務場景屬於典型的多業務線並行。同時爲了便於分類管理,避免端口衝突和資源合理利用。咱們也採起了一些策略,如:docker

標籤 label:經過標籤,一方面能夠標識哪一個產品線的哪一個應用坐落於哪些node之上,也許有人會想爲何要這樣作,假設你有一個數據落盤的應用而該應用老是每次隨着啓動變來變去就很差玩了。一方面經過標籤能夠均衡設備負載,好比將比較耗cpu和比較耗內存的搭配在一塊兒,不但資源充分利用並且還有效的防止同類型(好比高耗cpu)偶然間跑一個node上致使資源爭搶及端口衝突。數據庫

那麼問題來了,如何讓一個運維人員面對茫茫多的標籤並對其維護管理(kubectl get node –show-labels ?),又如何讓一個運維人員,故障發生時,面對茫茫多的nodes/pods,即時快速地定位二者的對應關係,從而解決問題。json

2. 測試環境維護管理問題。 bootstrap

通常的應用部署與上線流程較爲繁瑣api

1.jpg

這種模式下,讓每一個研發人員在每次調試beta環境時,不管是更改配置仍是代碼更新都須要溝通運維人員予以操做,讓每一個運維人員都要用更多的精力額外的維護一套甚至更多系統環境,天天遊走於beta,線上之間。難免有點讓人頭痛。websocket

更但願有這樣的一種模式app

2.jpg

這樣大大減小了部門之間的溝通成本。可是問題來了,如何讓一個研發人員可以獨立的開發維護屬於本身的beta環境,且不須要過多的關心除代碼調試外的一些東西呢?(如怎樣去寫一個基於kubernetes服務的yaml或json)

藉此,因而萌生出了一個嘗試寫一個管理服務的想法,目的在於讓運維人員更加方便的管理本身的kubernetes線下線上集羣,讓研發人員也可以獨立自主的編寫與維護屬於本身的測試環境應用,初期階段,僅供參考,如有不足之處,歡迎你們隨時予以寶貴意見。

Python Admin(測試版)是基於Python+Django與kubernetes Api的運維管理系統。前端採用開源SB(start bootstrap) Admin-2模板(清新,簡約)。

1.版本信息:

Python2.7.5+Django1.8.13+Kubernetes1.2.4+docker1.10.3

2.Kubernetes Api相關:

建立與更新label

curl -X PATCH -i -H \
"Content-Type:application/merge-patch+json" \
http://k8smaster:8080/api/v1/nodes/{ nodename } \
-d  '{"metadata":{"labels":{"標籤":"應用"}}}'

建立configmap

curl -X POST -i -H  \
"Content-Type:application/json" \
http://k8smaster:8080/api/v1/namespaces/default/configmaps/ \
 -d "$(cat configmaptest.json)"

更新configmap

curl -X PATCH -i -H \
"Content-Type:application/merge-patch+json" \
http://k8smaster:8080/api/v1/namespaces/default/configmaps/{ configmapname } \
-d "$(cat configmapupdate.json)"

刪除configmap

curl -X DELETE \
http://k8smaster:8080/api/v1/namespaces/default/configmaps/{ configmapname }

Configmap的基本Json模板

3.jpg

建立daemonset

curl -X POST -i –H \
"Content-Type:application/json" \
http://k8smaster:8080 /apis/extensions/v1beta1/namespaces/default/daemonsets \
-d "$(cat daemonset.json)"

更新daemonset

curl -X PATCH -i -H \
"Content-Type:application/merge-patch+json" \
http://k8smaster:8080/apis/extensions/v1beta1/namespaces/default/daemonsets/{daemonsetname} -d "$(cat daemonsetupdate.json)"

刪除daemonset

curl -X DELETE  \
http://k8smaster:8080/apis/extensions/v1beta1/namespaces/default/daemonsets/{daemonsetname}

daemonset 基本json模板

4.jpg

以上列舉爲部分api操做,其餘相關操做請參考kubernetes官方文檔

http://kubernetes.io/docs/api...

3.平臺操做界面概覽

1..Kubernets集羣資源管理界面(清晰展現集羣資源信息及所屬項目組,便於分類管理)

5.jpg

2.項目應用配置管理界面(配置文件單獨管理,採用數據庫存儲配置文件內容。建立和更新configmap時從新reload,並實時同步配置文件使用狀態。)

6.jpg

7.jpg

3.服務部署與管理界面(應用模板建立,同時增長系統日誌功能,服務啓動後記錄每一個階段的執行狀況,方便錯誤追蹤,具備必定的操做審計功能)

8.jpg

9.jpg

4.Kubernetes容器資源管理界面(每一個集羣全部node,以及每一個node全部pods信息,並採用websocket方式exec進入容器內部避免權限控制不當問題)

10.jpg

若是不確認服務是否能正常啓動,Container創建完畢後,能夠經過debug模式(command: ["sleep", "足夠長時間"])進去容器內部執行./run.sh調節服務,待沒問題後,再已正常模式啓動。

將來優化的一些小想法:

1.kubernets集羣一鍵部署,節點資源即時加入。

2.監控方面,在系統級別監控的基礎上,增長容器服務級別監控及相應告警策略。

3.整合融入jenkins接口,讓服務部署與更新,更簡單透明化。

相關文章
相關標籤/搜索