基于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接口,让服务部署与更新,更简单透明化。

相关文章
相关标签/搜索