其他分享
首页 > 其他分享> > 拥抱云原生,如何将开源项目用k8s部署?

拥抱云原生,如何将开源项目用k8s部署?

作者:互联网

k8s以及云原生相关概念近年来一直比较火热,阿丸最近搞了个相关项目,小结一下。
在这里插入图片描述

本文将重点分享阿里开源项目otter适配k8s部署的改造过程,其中的改造过程和技巧应该适用于将大多数开源项目改造到k8s进行部署。

1.背景

otter是阿里开源的分布式数据库同步系统,基于数据库增量日志解析,并准实时同步到本机房或异地机房的mysql/oracle数据库(相关内容可以参考https://github.com/alibaba/otter,本文不做过多赘述)。

为了充分利用物理资源、快速扩容同步节点、拥抱云原生,决定使用k8s部署otter。

otter的项目整体上自成一体,出于改造成本考虑,尽量在项目已有基础上,做一些适配,不改动源代码。

本文将重点分享对于otter适配k8s部署的改造过程,有不当之处,还请多多指教。

涉及到几个核心内容:

2.otter的基本架构

在这里插入图片描述

典型管理系统架构,manager(web管理)+node(工作节点)

基于以上部署架构,我们只需要将otter-manager和otter-node部署到k8s上。

尤其是otter-node,需要利用k8s实现节点快速水平扩展、计算性能弹性扩缩容。

2.Dockerfile编写

2.1 otter-manager的Dockerfile

otter-manager比较简单,包括几个步骤:

具体如下所示:
在这里插入图片描述

2.2 otter-node的Dockerfile

otter-node稍微有所不同,根据官方文档说明,需要安装aria2来做文件传输。

注意注意,由于aria2安装非常慢,因此,我们需要先安装aria2作为一个新的基础镜像,然后在新的基础镜像上构建otter-node镜像,能大大提高后续镜像构建速度。

新的基础镜像如下,命名为 registry.xxx.com/xxx/otter-node-base:1.0。
在这里插入图片描述

然后在此基础上构建新的otter-node镜像。
在这里插入图片描述

注意,otter-node的配置方式比较特殊,需要先在otter-admin上获取一个nid,然后才能运行一个otter-node。

所以,我们在dockerfile中以ARG 声明一个nid,然后在后续构建镜像的时候,通过 --docker-arg 传入nid具体的值。

当然,如果把nid看作一个配置文件的话,也可以用下文提到的configmap的形式在Deployment中挂载进去

3.Deployment编写

什么是Deployment?

k8s的一个Deployment控制器为 Pods 和 ReplicaSets 提供声明式的更新能力。我们通过编写Deployment描述期望的目标状态,然后 Deployment 控制器更改Pods或者ReplicaSets的实际状态, 使其变为期望状态。

具体关于Deployment的知识不展开说明,可以参考k8s官方文档。

我们需要部署测试环境与生产环境两套集群,而无论是otter-manager还是otter-node,都依赖于读取 conf/otter.properties 作为配置。

因此,我们需要根据环境,修改不同的otter.properties。

那么,对于k8s部署来说,可以采用同一份镜像,然后在不同环境(k8s的不同namespace)中将otter.properties作为configmap写入,最后通过volume的形式挂载到pod的指定路径上。

这里对几个名词做简单介绍,详细内容可以参考k8s官方文档。

所以,首先在指定环境(namespace中)创建configmap,以otter.properties作为key,以文件内容作为value。

具体命令如下

kubectl create configmap otter-manager-dev-config --from-file=otter.properties=conf/otter-dev.properties -n otter-system

产生的configmap如下图所示
在这里插入图片描述

然后,将这个configmap在Deployment中用volume进行引用,然后通过volumeMounts挂载到指定目录,Deployment具体如下所示。
在这里插入图片描述

这里需要特别注意volumeMounts的路径覆盖问题,需要在volumeMounts中配置subPath为具体文件名。

4.启动脚本改造

Otter包括两个部分,管理控制台manager和工作运行节点node,正常情况下都是用各自的启动脚本startup.sh启动的。

为了适配k8s,我们需要对启动脚本做改造,本文以otter-manager的启动脚本为例,otter-node也是类似。

将启动脚本startup.sh改造为 startup-moon.sh,重点解决两个问题

4.1 前台进程保持运行

由于容器中用entrypoint启动的进程为1号进程,一旦1号进程执行结束,容器就会退出了。

而原本的startup.sh中,用java启动后,使用 “&” 将java进程转换为后台进程,所以startup.sh作为1号进程会很快执行结束,容器就会自动退出了。

所以我们需要将1号进程保持住,不要退出。

这里考虑了两个方案:

后来考虑了一下,还是选择了方案二。主要原因是为了利用pod自动重启的特性

如果Java进程意外退出了,那么方案二就能使得1号进程也结束,然后pod就能自动重启了。而方案一的话,由于startup.sh脚本仍然在执行tail,所以即使java进程退出,1号进程也不会结束。

具体修改如下:
在这里插入图片描述

最终pod中的进程如图所示
在这里插入图片描述

4.2 虚拟机大小自定义配置

由于otter项目中,将jvm的启动参数配置在了start.sh中,不方便进行手动配置。

因此,将start.sh的配置jvm参数的逻辑注释掉,采用自己配置的环境变量JAVA_OPTIONS进行注入。
在这里插入图片描述

这个环境变量的注入方式也比较简单,就是在上面的Deployment中的env配置的(蓝色框部分),方便以后手动修改jvm参数大小而不用修改镜像。
在这里插入图片描述

5.k8s上固定IP/Port访问

otter-node的部署中,有个比较特殊的地方。

不同于普通的微服务的无状态扩展,otter-node的部署必须指定nid、ip、port,这种设计据说是为解决单机部署多实例而设计的,允许单机多node指定不同的端口(具体可以参考官方wiki,https://github.com/alibaba/otter/wiki/Node_Quickstart,这里不展开说明)。

还是直接看看如何在k8s上进行适配吧。

这里采用了k8s的NodePort进行处理。

NodePort 服务是引导外部流量到你的服务的最原始方式。NodePort,正如这个名字所示,在所有节点(虚拟机)上开放一个特定端口,任何发送到该端口的流量都被转发到对应服务。如下图所示。
在这里插入图片描述

在上面的配置中,可以使用IP1:3000 或者 IP2:3000 或者 IP3:3000 访问service。

当然,为了保证不绑定特定KVM的IP,我们在前面挂一个SLB服务,通过访问SLB的 虚拟IP:PORT 的形式访问。

对于otter部署来说,otter-manager需要两组 IP:PORT、每个node需要三组 IP:PORT。

注意,由于otter部署中,每个node需要暴露的port都是不同的,所以每次新增一个otter-node,都需要新增三组 IP:PORT。

我们以otter-node为例,来看下NodePort类型的Service的yml文件吧。
在这里插入图片描述

6.总结

经过这样的改造,我们就能用k8s的部署otter-manager和otter-node了,并且能够快速扩容节点、弹性使用机器资源。

我们回顾一下其中的关键问题和技巧:

其他开源项目如果有需要上k8s的,这些技巧应该都能用上。

如果你有更好的一些方式和技巧分享,欢迎留言交流~~~

看到这里了,原创不易,来个三连吧!!!你最好看了~

知识碎片重新梳理,构建Java知识图谱:https://github.com/saigu/JavaKnowledgeGraph (历史文章查阅非常方便)

标签:原生,node,manager,开源,Deployment,进程,k8s,otter
来源: https://blog.csdn.net/u014730658/article/details/111472613