解构he2e中的kubernetes技术应用-4008云顶国际网站

在一文当中，为大家分析了he2e项目的代码仓库、编译构建、部署等各环节中对于容器技术的应用。今天，我们将从kubernetes技术应用的角度解构。

kubernetes （也称k8s）是用于自动部署，扩展和管理容器化应用程序的开源系统。

在上一篇文章中，大家已经了解了he2e项目中通过docker实现容器化部署，在该实践中通过此方式部署至ecs弹性云服务器中，并称之为ecs部署。在该实践中，提供了另外一套部署方式，将应用部署至cce集群当中，即cce部署，使用的工具即k8s。

总之，根据部署目标的不同，he2e实践中分别介绍了ecs部署与cce部署。根据部署采用的技术工具不同，也可以将这两种方式称为docker部署与k8s部署。

在正式的生产环境中，企业和团队往往会需要将应用部署至多个服务器主机，而cce集群和k8s则共同为应用的部署、运行及管理提供了保障。相较而言，he2e实践中介绍的ecs部署方式更倾向于开发、测试等环境下的单机部署。

回到项目本身，代码仓库中的./kompose/文件夹下有多个yaml文件。可以看出，每个服务都有两个配置文件（*-deployment.yaml与*-service.yaml）共同进行配置。

此处以db-deployment.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则定义了该服务访问方式。

在编译构建环节，主体还是制作镜像上传到swr镜像仓库，与上篇文章的没有区别。相关的配置文件也通过构建任务上传到软件发布库了，所以这里就不赘述了。

镜像、配置和集群资源都准备妥当以后，就是使用k8s部署的环节了。

• 代理机配置

我们在he2e实践中采用的是代理机的部署方式，将集群中的一个节点作为代理机进行授信、部署。所以在实践中我们从集群下载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手动添加访问方式。

节点访问设置完毕后，即可访问项目的用户端与管理端了。

理论上，讲到现在，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技术探秘→聚焦华为各领域的前沿技术、重磅开源项目、创新应用实践。站在智能世界的入口，探索未来如何照进现实，干货满满！