Probius+Kubernetes任务系统如虎添翼

小尘哥

共 2114字,需浏览 5分钟

 ·

2021-11-06 03:39

Probius是一款自定义任务引擎,可以灵活方便的处理日常运维中的各种任务,我们所有的CI/CD任务都通过Probius来完成的,这篇文章Probius:一个功能强大的自定义任务系统对其有详细的介绍,之前通过Probius更新Kubernetes的Deployment是通过脚本的方式来完成的,脚本大概像这样

if [ $# != 2 ];then
    echo "USAGE: $0 PROJ ENVT"
    exit 1
fi

PROJ=$1
ENVT=$2

BASE_DIR=/home/data/probius/${PROJ}/${ENVT}
DOCKER_DIR=${BASE_DIR}/docker
IMAGE_NAME=`cat ${BASE_DIR}/cache/image.txt`

if [ ${ENVT} == "qa" ];then
    ENVT='trunk'
elif [ ${ENVT} == "qa2" ];then
    ENVT='trunk2'
fi

cd ${DOCKER_DIR} &&\
export KUBECONFIG=/root/.kube/config &&\
kubectl set image deployment/${ENVT}-${PROJ} ${ENVT}-${PROJ}=${IMAGE_NAME} -n ${ENVT} &&\
exit 0 ||\
exit 1

直接通过kubectl命令来更新,这就需要在Probius服务器上安装kubectl并打通整个集群,这种方式仅是能用但不够优雅,并且对于开发测试环境,在部署完成后有查看日志及登录系统排错的需求,这就需要借助Kubernetes-Dashboard来完成,多个系统相互关联跳转增加了使用成本,同时Dashboard的权限也不好控制,所以我就考虑是否可以让Kubernetes以插件的形式集成进Probius系统,用户在Probius系统内完成部署,同时也可以在Probius系统查看Kubernetes的相关信息甚至通过WebSSH登陆,彻底抛弃掉Kubernetes的Dashboard,看上去很完美,正好最近打算升级下Kubernetes集群版本,于是就趁此机会花了几天时间来实现了

Kubernetes子任务

首先在命令和脚本之外添加了Kubernetes类型的子任务,部署任务只需要关联这个Kubernetes类型的子任务就可以实现Deployment的更新

48091c899b00110c8e78acb85ced11d1.webp

这个子任务的目的主要是为了替换上边的脚本,通过Kubernetes的Python客户端来实现对Deployment的更新,有了这个子任务我们就不需要在Probius服务器上安装kubectl服务来运行kubectl命令了,整个部署流程能够正常跑通

Kubernetes管理

但在部署之前我们需要先新建相关服务,以一个全新的环境为例,需要先创建Kubernetes的namespace,然后在namespace下创建deployment、service、ingress,我们的namespace是根据环境来划分了,例如dev环境的所有容器都跑在名为dev的namespace下

02c9066142177f25d36d7f3c0ac24d29.webp

Namespace创建完成后,可以点击进入查看Namespace下的deployment、service、ingress、configmap

530d954460dc626bf2ba8619046a9800.webp

当前还没有具体deployment/service/ingress,接下来就创建,每个项目都会有deployment、service和ingress,并且他们之间是相互关联的,新建项目的同时就把这些服务给一并创建了是个不错的选择,为此写了个KubeProject服务,在这里可以定义项目的名称、环境、镜像、域名、配置以及关联的configmap

f1922aa3ac555677be95e05bed29adc1.webp

选择保存仅会保存填写的表单信息到数据库,选择保存并创建K8S环境就可以在保存表单信息到数据库的同时创建Kubernetes的deployment、service和ingress了,保存并更新Deployment会在Deployment配置有变化的情况下使用,例如新的资源限制或是configmap绑定

2f507b261769f6f95fb92a3363aeb7c8.webp

当资源创建成功后我们就可以在namespace下看到相应资源了

19748f2c86c3fe222aa06dd89df31e81.webp

我们最为关注的deployment信息也可以通过点击deployment的名字或是在KubProject里点击项目的名字进入,进入之后可以查看deployment下的pod列表,通过webssh进入pod内部,也可以查看每个pod的日志,甚至可以对deployment进行scale伸缩或是重建

603f041720c5803bb94a1c08a85b63e1.webp

WebSSH很好用,想要实现的可以看看这篇文章:Django实现WebSSH操作Kubernetes Pod

a39654ff142e45335e301223baf95585.webp

至此可以摆脱Kubernetes-dashboard了

后记

我们使用Kubernetes有超过4年的时间,借助于Kubernetes不仅提高了资源利用率,更是优化了整个运维的工作流程,受益颇多

cd8083d0d6f3933d6922876f9b489e92.webp

留个截图纪念下这战功赫赫的集群吧,虽然你已老去,但是你把我带进了Kubernetes的大门,从此打开了另一个世界

浏览 45
点赞
评论
收藏
分享

手机扫一扫分享

分享
举报
评论
图片
表情
推荐
点赞
评论
收藏
分享

手机扫一扫分享

分享
举报