在《解构 H E2E 中的容器技术应用》 一文当中，为大家分析了HE2E项目的代码仓库、编译构建、部署等各环节中对于容器技术的应用。今天，我们将从Kubernetes技术应用的角度解构华为云 DevCloud HE2E D evOps 实践 。

什么是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。

kubectl delete secret regcred

kubectl create secret docker-registry regcred --docker-server=${docker-server} --docker-username=${docker-username} --docker-password=${docker-password} --docker-email=***@***.cn 

kubectl delete -f /root/phoenix-sample-deploy/kompose/

kubectl apply -f /root/phoenix-sample-deploy/kompose/

• 这里先是删除原有的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工程方法、工具平台、最佳实践等干货。

华为伙伴暨开发者大会2022火热来袭，大会采用线上直播+线下80余个分会场联动的形式，聚焦伙伴和开发者最为关切的话题、释放更多潜力，携手伙伴共同成就。干货满满点击了解。

【精彩活动】

勇往直前·做全能开发者→12场技术直播前瞻，8大技术宝典高能输出，还有代码密室、知识竞赛等多轮神秘任务等你来挑战。即刻闯关，开启终极大奖！戳【勇往直前】踏上全能开发者晋级之路吧！

【技术专题】

未来已来，2022技术探秘→聚焦华为各领域的前沿技术、重磅开源项目、创新应用实践。站在智能世界的入口，探索未来如何照进现实，干货满满点击了解！