時至今日，接觸kubernetes也有一段時間了，而我們的大部分業務也已經穩定地運行在不同規模的kubernetes集群上，不得不說，無論是從應用部署、迭代，還是從資源調度管理等方面都有其難以言喻的優勢，但是隨着業務的不斷增長，以及服務的多元化，容器的體量與管理的難度也隨之增長。
淺述Kubernetes集群日常管理維護中的一些痛點：
1.較為龐大的集群規模及容器數量維護管理。
我們公司的業務場景屬於典型的多業務線並行。同時為了便於分類管理，避免端口沖突和資源合理利用。我們也采取了一些策略，如：
標簽 label：通過標簽，一方面可以標識哪個產品線的哪個應用坐落於哪些node之上，也許有人會想為什么要這樣做，假設你有一個數據落盤的應用而該應用總是每次隨着啟動變來變去就不好玩了。一方面通過標簽可以均衡設備負載，比如將比較耗cpu和比較耗內存的搭配在一起，不但資源充分利用而且還有效的防止同類型（比如高耗cpu）偶然間跑一個node上導致資源爭搶及端口沖突。電動叉車
那么問題來了，如何讓一個運維人員面對茫茫多的標簽並對其維護管理（kubectl get node –show-labels ？），又如何讓一個運維人員，故障發生時，面對茫茫多的nodes/pods，即時快速地定位兩者的對應關系，從而解決問題。
2. 測試環境維護管理問題。
一般的應用部署與上線流程較為繁瑣
這種模式下，讓每個研發人員在每次調試beta環境時，無論是更改配置還是代碼更新都需要溝通運維人員予以操作，讓每個運維人員都要用更多的精力額外的維護一套甚至更多系統環境，每天游走於beta，線上之間。不免有點讓人頭痛。
更希望有這樣的一種模式
這樣大大減少了部門之間的溝通成本。但是問題來了，如何讓一個研發人員能夠獨立的開發維護屬於自己的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模板
創建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 -XDELETE\http://k8smaster:8080/apis/extensions/v1beta1/namespaces/default/daemonsets/{daemonsetname}
daemonset 基本json模板
以上列舉為部分api操作，其他相關操作請參考kubernetes官方文檔
http://kubernetes.io/docs/api-reference/v1/operations/
3.平台操作界面概覽
1..Kubernets集群資源管理界面（清晰展示集群資源信息及所屬項目組，便於分類管理）
2.項目應用配置管理界面（配置文件單獨管理，采用數據庫存儲配置文件內容。創建和更新configmap時重新reload，並實時同步配置文件使用狀態。）
3.服務部署與管理界面（應用模板創建，同時增加系統日志功能，服務啟動后記錄每個階段的執行情況，方便錯誤追蹤，具有一定的操作審計功能）
4.Kubernetes容器資源管理界面（每個集群所有node，以及每個node所有pods信息，並采用websocket方式exec進入容器內部避免權限控制不當問題）
如果不確認服務是否能正常啟動，Container建立完畢后，可以通過debug模式（command: ["sleep", "足夠長時間"]）進去容器內部執行./run.sh調節服務，待沒問題后，再已正常模式啟動。
未來優化的一些小想法：
1.kubernets集群一鍵部署，節點資源即時加入。
2.監控方面，在系統級別監控的基礎上，增加容器服務級別監控及相應告警策略。
3.整合融入jenkins接口，讓服務部署與更新，更簡單透明化。