时至今日，接触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 -X DELETE \
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接口，让服务部署与更新，更简单透明化。