解构 HE2E 中的 Kubernetes 技术应用
本文分享自华为云社区《解构HE2E中的Kubernetes技术应用》,作者: 敏捷小智 。
在《解构HE2E中的容器技术应用》 一文当中,为大家分析了 HE2E 项目的代码仓库、编译构建、部署等各环节中对于容器技术的应用。今天,我们将从 Kubernetes 技术应用的角度解构华为云 DevCloud HE2E DevOps 实践 。
什么是 Kubernetes?
Kubernetes (也称 K8S)是用于自动部署,扩展和管理容器化应用程序的开源系统。
K8S 与 CCE
在上一篇文章中,大家已经了解了 HE2E 项目中通过 Docker 实现容器化部署,在该实践中通过此方式部署至 ECS 弹性云服务器中,并称之为 ECS 部署。在该实践中,提供了另外一套部署方式,将应用部署至 CCE 集群当中,即 CCE 部署,使用的工具即 K8S。
总之,根据部署目标的不同,HE2E 实践中分别介绍了 ECS 部署与 CCE 部署。根据部署采用的技术工具不同,也可以将这两种方式称为 Docker 部署与 K8S 部署。
为什么选择 K8S
在正式的生产环境中,企业和团队往往会需要将应用部署至多个服务器主机,而 CCE 集群和 K8S 则共同为应用的部署、运行及管理提供了保障。相较而言,HE2E 实践中介绍的 ECS 部署方式更倾向于开发、测试等环境下的单机部署。
K8S 的代码配置
回到项目本身,代码仓库中的./kompose/文件夹下有多个 yaml 文件。可以看出,每个服务都有两个配置文件(*-deployment.yaml 与*-service.yaml)共同进行配置。
此处以 db-deployment.yaml 为例,对 yaml 配置仅作简短的介绍,帮助大家理解配置内容。随着集群版本和产品能力的更迭,也有很多配置信息将发生变化。所以在实践当中,需要调整 yaml 文件配置 。
• apiVersion:此处值为 apps/v1,这个版本号需要根据安装的 K8S 版本和资源类型进行变化。目前实践中对应 v1.19 版本的 K8S 集群。
• kind:此处创建的是 Deployment,根据实际情况,此处资源类型可以是 Pod、Job、Ingress、Service 等。如:在*-service.yaml 文件中,创建的资源类型则是 Service。
• metadata:包含 Deployment 的一些 meta 信息。其中,annotations 的含义是注解。
• spec:你所期望的该对象的状态。包括 replicas、selector、containers 等 Kubernetes 需要的参数。其中,containers 定义了该 deployment 使用的镜像:docker-server/docker-org/postgres:9.4。在上篇文章中提到过,这里的 docker-server、docker-org 都会在构建任务中替换为实际镜像对应的镜像地址和组织。strategy、restartPolicy 等字段共同构成了容器失败时重启的策略。
在*-service.yaml 当中,主体内容与*-deployment.yaml 相差也不算大,主要差异集中于 spec 这部分。*-service.yaml 对应的 spec 主要是定义了集群内访问的方式,使各个服务之间可以互相访问。
可以看出,*-deployment.yaml 与*-service.yaml 共同定义了一个服务*。*-deployment.yaml 主要定义了该服务的镜像源,或者说工作负载是什么。而*-service.yaml 则定义了该服务访问方式。
K8S 的部署配置
在编译构建环节,主体还是制作镜像上传到 SWR 镜像仓库,与上篇文章的没有区别。相关的配置文件也通过构建任务上传到软件发布库了,所以这里就不赘述了。
镜像、配置和集群资源都准备妥当以后,就是使用 K8S 部署的环节了。
代理机配置
我们在 HE2E 实践中采用的是代理机的部署方式,将集群中的一个节点作为代理机进行授信、部署。所以在实践中我们从集群下载 Kubectl 配置文件并配置到节点主机当中(见《配置 Kubectl 》)。通过配置 Kubectl 的操作,我们就可以在节点主机上执行命令进而影响整个 CCE 集群。
CCE 部署任务
HE2E 实践中,phoenix-cd-cce 是我们所需执行的部署任务。该任务将配置文件传输到目标主机,即代理机、集群节点。
而后,通过执行 shell 命令启动 Kubenetes。
• 这里先是删除原有的 secret,这一步主要是为了防止由于使用临时登录命令变化而导致 secret 错误引发的任务执行失败。
• 接着,创建新的 secret。包含 docker-server、docker-username、docker-password 等信息。
• 按配置文件(/root/phoenix-sample-deploy/kompose/)删除资源。
• 按配置文件(/root/phoenix-sample-deploy/kompose/)对资源进行配置。
成功执行该部署任务后,可以在 CCE 集群中看到五个工作负载已经处于“运行中”的状态。
不过目前还需要设置“节点访问”才能正常访问。所以在后续实践中对工作负载 vote 和 result 手动添加访问方式。
节点访问设置完毕后,即可访问项目的用户端与管理端了。
K8S 的模板部署方式
理论上,讲到现在,HE2E 实践中的 K8S 部署就已经讲完了。但是,笔者猜到,肯定有很多人不喜欢这种通过代理机部署集群的方式。不过没关系,下面我就来介绍 DevCloud 当中的 Kubernetes 模板部署。
新建模板时,现在可以选择模板:Kubernetes 部署。
进入模板以后,可以选择集群类型、区域、命名空间、部署方式等信息。
由于本项目通过 10 个 yaml 文件共同配置,所以需要添加相同的“Kubernetes 部署”步骤共计 10 个,每个步骤都对应一个 yaml 文件。
而由于我们在代码仓库中的配置并非我们最终部署时所需的配置(经过编译构建修改 docker-server 等参数),所以我们需要每个步骤都设置软件发布库中对应的 yaml 文件。此时,我们会发现,我们原本的构建任务是将所有 yaml 文件进行了打包压缩后才上传的,没有办法直接选中。所以,我们可以再次创建一个构建任务或者在原有构建任务上进行修改,以使软件发布库中存放有所有的 yaml 文件。
构建任务上传步骤的配置参考:(上传所有 yaml 文件而非打包后上传)
完成以上配置以后,执行 Kubernetes 部署模板任务,即可将服务部署至选定的 CCE 集群当中。此时再添加节点访问方式即可访问用户端与管理端。
当然,我们也可以将节点访问也写入 yaml 文件中,实现进一步的一键部署。这里就暂且留作一个小思考题,感兴趣的小伙伴可以自己尝试一下,将节点访问写入 yaml 当中。
结语
本篇文章一面介绍了 HE2E 实践中的 CCE 部署方式,一面又介绍了该实践中未提到的 Kubernetes 模板部署。两者的主要区别是“CCE 部署”是通过代理机控制集群进行 K8S 部署;Kubernetes 模板部署则是直接在集群中部署。此外,本文也对项目中关于 K8S 的配置进行了一定程度的解析。
希望可以帮助小伙伴们理解 K8S、HE2E,祝大家在技术成长的道路上越走越远。
感谢小伙伴们的阅读。如果觉得还不错,不妨点个赞再走~
此文由 DevSecOps 专家服务团队出品,前往 专家服务 ,获取更多 DevSecOps 工程方法、工具平台、最佳实践等干货。
版权声明: 本文为 InfoQ 作者【华为云开发者社区】的原创文章。
原文链接:【http://xie.infoq.cn/article/4dc683af24897d23cdda4a654】。文章转载请联系作者。
评论