转载

解读与部署（三）：基于 Kubernetes 的微服务部署即代码

在基于 Kubernetes 的基础设施即代码一文中，我概要地介绍了基于 Kubernetes 的 .NET Core 微服务和 CI/CD 动手实践工作坊使用的基础设施是如何使用代码描述的，以及它的自动化执行过程。

如果要查看基于 Kubernetes 的基础设施即代码架构全图，以及实现代码，请回到文章基于 Kubernetes 的基础设施即代码。

本文，我们深入探讨其中微服务部署部分的“基础设施即代码”的实现原理。

一般来说，在一个团队，CI/CD 软件不会经常部署。与此不同，时常处于开发之中的微服务的则会经常部署。此外，在部署到集群之前，通常开发人员还需要在某个“本机”环境对其所开发的微服务进行预先测试和调试。于是，在工作坊的环境中，我们在设计微服务的“持续部署即代码”时，也模拟正常的微服务开发情景进行了相关设计。

大体上，工作坊在部署微服务时，有如下几个方面协同工作：

•微服务所需的公用基础设施

•微服务本身在 Kubernetes 上的部署配置

•微服务的 CI/CD 过程

其中“微服务公用基础设施”部分的自动化原理在我们第一篇文章中已有介绍，这里主要介绍后两者。

微服务的 Kubernetes 部署

之前介绍过，在需要部署微服务时，调用 dev-services 项目根目录的 provision-services.sh 脚本文件将触发微服务的部署。脚本中的实际过程，还是会使用微服务项目根目录的 k8s.yaml 来完成部署。部署时，脚本还是会利用之前介绍过的模板引擎传入变量文件。

也就是说，用于部署工作坊中的微服务的 Kubernetes 资源文件都是以单个 k8s.yaml 文件的形式在各个微服务自己的代码仓库中维护的。这体现出“微服务自己知道如何部署自己”的自助原则。工作坊的微服务大致可分为两类，一类是纯后台服务，另一类是提供 Web 界面的服务。维护微服务的团队可根据需要自行定制用于在 Kubernetes 集群上部署它自己的资源文件。如果使用 kustomize，还可以以这个文件为入口，利用嵌套、变量等功能编写更易于维护的 Kubernetes 资源文件。

微服务的 CI/CD 过程

工作坊中的微服务，它们的 CI/CD 过程同样是由微服务自身所主导的。在上一篇文章基于 Kubernetes 的 CICD 基础设施即代码中我们介绍过微服务的部署流水线在 Jenkins 启动之后就已经内置创建好了。但实际上流水线虽然创建好了，但流水线中运行的内容却确实是由微服务自己控制和维护的。

这得益于 Jenkins 中基于 Jenkinsfile 的“流水线即代码”技术。简单来说，Jenkins 在运行流水线之前，会先去微服务代码库下载这个 Jenkinsfile 文件，再根据其中的内容决定如何运行流水线。查看各个微服务的代码库就会发现，它们的根目录都存在一个 Jenkinsfile，虽然整体结构都差不多，但具体细节还是有一些差异的。

在 Jenkinsfile 中，我们声明了微服务持续集成和持续部署的几个典型阶段：

1.检出代码

2.编译应用

3.生成新版容器镜像

4.部署新版容器镜像

其中，上述第 2 步要求 Jenkins 具有支持 .NET Core SDK 的运行器（Slave）节点 dotnet；而第 3、4 步则要求 Jenkins 具有支持 kubelet 和 docker 的节点 image-builder。而它们，则是由 Jenkins 中的 Kubernetes 插件提供的支持。

当流水线运行到这些步骤时，插件将负责按需地在 Kubernetes 集群上启动具有这些功能的 Slave 节点。具体的启动方法（比如，要使用的镜像、要挂载的存储等）都在“CICD 基础设施即代码”的过程中被自动写入。

解读与部署（三）：基于 Kubernetes 的微服务部署即代码