wydevops——微服务直上K8S云就是这么简单(续5)

        本文接续《wydevops——微服务直上K8S云就是这么简单(续4)》继续介绍wydevops的chart阶段的配置参数、资源生成器插件机制，单Chart打包多服务和单Pod容器打包多服务等功能。

1. chart阶段配置参数

        wydevops的chart镜像生成依赖其内置的参数模板文件（_ci-cd-template.yaml）文件和资源生成器插件。以下是公共的_ci-cd-template.yaml文件的内容中chart部分的截图：

       chart参数是该文件中最长的一个配置节。chart参数是个列表，默认只有一个列表项，只打包一个chart镜像。重要参数说明如下:

name: 列表项的唯一名称，也是Chart镜像名称的一部分。

version: chart镜像的版本，完成的Chart镜像名称为：${name}-${version}.tgz

appVersion: 用来设置chart镜像中Chart.yaml文件中appVersion参数的值，wydevops默认appVersion与version是一致的。

customedHelmDir: 自定义的helm打包目录，定义了这个参数，wydevops会跳过使用内置的资源生成器插件生成资源配置文件的过程，直接执行helm package命令及后续的Chart镜像模板校验（helm template）、推送到仓库等过程。

refExternalCharts: 定义需要打包到这个Chart镜像中一起发布的微服务的Chart镜像，多个镜像名称间用英文逗号隔开。如果定义的是wydevops生成Chart镜像则可完美引入。如果是第三方打包的Chart镜像则不能保证引入成功（进行helm template时可能会报错），第三方Chart镜像引入策略如下：

• 将第三方Chart镜像中values.yaml文件的内容整体复制到当前Chart镜像values.yaml的deploymentX（X是values.yaml文件中已有的deployment后缀数值最大值加1）参数下。
• 然后将引入的Chart镜像中templates目录下所有文件中的".Values."字符串全部替换为".Values.deploymentX."。
• 最后将修改好的文件复制到当前Chart镜像的templates目录下。注意wydevops打包的Chart镜像是没有_helpers.tpl文件的，所以可不考虑该文件的合并问题，其他文件名基本不会重名。
• 由wydevops内置的externalChart-generator.sh插件完成。在该插件执行前后都有功能扩展点，其在源码中的位置如下图：

        源码中功能扩展点调用如下图，wydevops没有实现这个两个功能点，开发人员如有需要可自行实现项目级的功能扩展点，开发人员也可在项目级自己实现ExternalChart生成插件。

deployments: 是个列表属性，每一个列表项都集中定义了一个微服务的在K8S上发布可能涉及的所有参数，大部分参数采用默认值即可。其下重要参数说明如下：

deployments[x].refExternalContainers：定义需要引入到当前微服务的Pod容器中的外部Chart镜像的名称，支持定义多个Chart镜像，相互间使用英文逗号隔开。wydevops会将这些引入的Chart镜像中的chart[0].deployments[0].initContainers[0](如果存在的话)和chart[0].deployments[0].containers[0]参数合并到当前chart[x].deployments[x]参数对应的下属参数中。容器级的引入由wydevops内置的externalContainer-generator.sh插件完成（源码中的位置参考上图），在该插件执行前后都有功能扩展点，如下图。wydevops没有实现这个两个功能点，开发人员如有需要可自行实现项目级的功能扩展点，开发人员也可在项目级自己实现ExternalContainer生成插件。

特别说明：只能引入wydevops生成的Chart镜像中的容器。

deployments[x].kind：该参数值可选值有：Deployment、DaemonSet、StatefulSet。可通过项目中的ci-cd-config.yaml配置文件进行修改。

deployments[x].autoscaling：配置水平扩展功能，该功能默认是关闭的，可通过项目中的ci-cd-config.yaml配置文件进行修改。默认参数设置截图如下：

deployments[x].volumes: 配置挂载卷参数。默认会配置两个挂载卷：

• ${serviceName}-config: 这个卷挂载的是wydevops默认为服务自动生成的ConfigMap资源。该ConfigMap中存放着微服务运行需要的配置文件，这些配置文件是在参数映射文件中定义的。

• ${serviceName}-workdir: 这个卷挂载的是Pod容器中emptyDir类型的共享目录，是Pod中多个Container容器交换数据的目录。wydevops默认是按照double构建类型设计的，因此在配置文件中默认配置了这个参数。在生成Chart镜像的过程中wydevops一旦检测到当前构建类型是single，则会删除这个卷配置项。

关于持久化配置，wydevops推荐方案：在集群中预先定义好PV/PVC, 微服务只需挂载好需要的PVC即可，微服务内不负责创建和释放PVC。如果PVC内存储的数据需要在微服务卸载的时候删除掉，可使用helm提供的chart hook: pre-delete来实现，或者通过配置Container的lifecycle.preStop参数来实现微服务退出前持久化存储中废弃数据的清理。配置样例如下：

  上图来源于为容器的生命周期事件设置处理函数 | Kubernetes，详情请自行参考。

wydevops本身没有默认配置任何持久化挂载配置，可根据自己团队的情况统一在_ci-cd-template.yaml文件中配置好，开发人员也可以通过ci-cd-config.yaml进行定义。

  
deployments[x].initContainers: 是个列表参数，这个配置的是初始化容器。在double构建类型中，初始化容器运行的是应用业务镜像，用来将业务镜像中最新应用程序复制到container容器中应用基础镜像的工作目录中。

deployments[x].containers:  是个列表参数，配置Pod中运行的所有容器，这些容器共享相同的IP地址。每个配置项都定义有这个容器开放的端口号列表、卷挂载配置、探活和就绪配置、CPU和内存资源额度。当端口配置中存在多个端口时，wydevop会自行处理生成ClusterIP和NodePort类型的Service配置。 _ci-cd-template.yaml模板文件中端口配置参数如下图红框部分：

上面的service参数不要去手动设置，这个参数wydevops会自动填充的，以下是ci-cd.yaml文件（是由_ci-cd-template.yaml经过变量替换和处理后生成的）中对应的处理后的内容：

   container中的其他下属参数就不再介绍了。

deployments[x].configMaps: 默认配置的存储服务配置文件的ConfigMap的配置信息。开发人员可在项目中的ci-cd-config.yaml文件中定义新的ConfigMap文件配置。

deployments[x].resourcePlugins：配置的是构建当前镜像需要执行的资源生成器插件集合，插件执行之间没有顺序依赖关系。可通过ci-dc-config.yaml文件关闭某些插件的执行，或者配置新的需要执行的插件。目前wydevops默认提供以下的插件：

其中, ApisixRoute网关路由插件默认是禁用的，网关默认使用的是Ingress-nginx。

deployments[x].ingressRoute：该参数配置的是Ingress-nginx路由信息，如下图：

这个配置节由ingress-generator.sh解析，使用ingress-default-template.yaml模板进行渲染。

deployments[x].apisixRoute：该参数配置的是apisix网关的路由信息。解析器和模板位置如下图：

 params: 运维参数配置节，前文已经讲过了，这里略掉。     

主要的chart配置项参数就介绍到这里。

2.  资源生成器插件机制

      wydevops不可能内置所有的资源类型模板（k8s大约由30-40中资源，还不包括自动义资源）。因此需要定义一种可扩展的机制，来规范和约束Chart镜像中资源文件的生成过程。

wydevops的资源生成器插件有两种：

• 一种是在_ci-cd-template.yaml文件中定义有参数配置节、在源码（或项目）中plugins目录中有对应的资源目录，且该目录下存在配置参数解析器（shell脚本文件，其名称i必须以“-generator.sh”结尾）和 资源模板文件（文件名称必须以“-template.yaml”结尾，该文件不是必须要存在的），这种插件主要是为某类资源定义的通用资源生成器插件。
• 另一种是在_ci-cd-template.yaml文件中没有参数配置节、在源码（或项目）中plugins目录中有对应的资源目录，且该目录下没有*.sh脚本文件，只有名称不是以“-template.yaml”结尾的压yaml文件，该文件的名称格式应为：${name}-${generatorName}.yaml, ${name}对应resourcePlugins配置项中的name参数, ${generatorName}对应resourcePlugins配置项中的generatorName参数。这种插件本质就是一个不需要处理的yaml文件，主要用于配置具体项目的某个某种资源。

       这两种插件都需要在resourcePlugins配置节中预定义好，才会被chart阶段主流程调用。在初始化阶段，wydevops的插件管理器（plugin-manager.sh）会在项目的wydevops/plugins目录和源码中script/plugins目录中查找并注册所有的资源生成器插件；并在chart阶段依次执行在项目ci-cd.yaml文件的resourcePlugins参数中定义好的插件（enable为false则不执行），如果找到的是第一种插件则执行对应的shell脚本，如果找到的是第二种插件，则直接复制插件目录中所有yaml文件到当前Chart镜像的template目录中。

        插件管理器中定义有通用生成器方法（commonGenerator_default），很多资源生成器都是直接调用该方法为资源模板文件提供参数的，例如下图：

具体是否能调用通用生成器方法，需要看通用生成器方法是否能为资源模板文件提供所有的变量值。模板中引用的变量名称都是以"t_"开头的，如下图：

        如果通用生成器方法不能提供足够的变量值，则需要自行实现生成器方法(在*-generator.sh文件中进行定义）。

        自定义插件的方法可参考Ingress插件或ApisixRoute插件。resourcePlugins配置项、*-generator.sh文件、*-template.yaml这三者是自成体系的，与其他各类配置都无关。其中*-generator.sh文件中的生成器方法名称格式必须是：{自定义串}Generator_{生成器名称}。

3.  单Chart多服务功能演示

        应用场景：很多时候，我们希望将多个业务耦合紧密的微服务，打包到一个chart镜像进行统一部署和卸载，这时就会使用到单chart多服务打包功能。

仍以java-sample为例，上篇文章的例子中我们已经生成了java-sample服务1.0.1版本，该版本使用的端口是8052，采用双镜像构建类型生成的，在接下来的例子中，我们将把它作为外部Chart镜像引入到新构建的Chart镜像中。

首先，修改java-sample项目中的pom.xml文件，将项目名称更名为java-sample1，版本更新为1.0.2版本，如下图：

图中，我们还修改了一下cicdName参数的值，以便后续区别服务。并且清除了项目中的ci-cd.yaml文件等生成文件，仅保留了ci-cd-config.yaml文件（如上图左边显示的）。

接着，打开项目中的application-prod.yaml文件，修改端口号为8062，如下图：

继续打开application.yaml文件，修改url-prefix参数值（最后加了个1），如下图：

然后，打开ci-cd-config.yaml文件，进行如下红框部分的配置：

上图中，直接对refExternalCharts设置了一个Chart镜像的名称，wydeveops会检查该名称是否带有路径，如果没有带路径则尝试从配置的私库中拉取；如果带了路径则直接使用该路径下的chart镜像文件。如果路径是相对路径，则会在相对路径前加上当前项目主模块的路径（也就是wydevops-run.sh文件中的-P参数）。

当前wydevops-run.sh文件的内容如下（构建类型设置为single）：

接下来在git bash命令行窗口中执行以下命令清除集群中已经存在的java-sample和java-sample1服务：

/c/Users/wuyi/helm/helm uninstall java-sample -n develop --kubeconfig /d/kube-config
/c/Users/wuyi/helm/helm uninstall java-sample1 -n develop --kubeconfig /d/kube-config

上面命令最后面的kube-config文件就是java-sample项目中wydevops/deploy目录下的同名文件，可自行复制到d盘根目录下，或修改上述命令中kube-config文件的路径。

最后，在wydevops-run.sh文件所在目录打开git bash命令行，执行：bash wydevops-run.sh。

执行完毕后，我们在ubuntu on windows命令行中输入：kubectl get pod --all-namespaces，返回如下内容：

两个服务都已经部署好了。

现在来验证：

• 首先，打开java-sample项目的wydevops/chart-build/templates目录,可以看到存在java-sample开头的*.yaml文件，如下图：

• 打开java-sample项目的wydevops/chart-build/values.yaml文件,可以看到如下图红框内容：

       说明java-sample服务已经合并到values.yaml文件中了。

• 接下来，在浏览器中访问：http://localhost/wydevops/v1/sample/hello和http://localhost/wydevops/v1/sample1/hello，都会返回如下内容：

•   继续验证：在ubuntu on windows命令行中执行：

kubectl get deployment java-sample -n develop -o yaml

kubectl get deployment java-sample1 -n develop -o yaml

在返回的信息中都能看到如下图红框中的内容：

说明两个deployment是同一个Chart镜像安装的。

• 最后，在git bash命令行窗口中执行：   

/c/Users/wuyi/helm/helm uninstall java-sample1 -n develop --kubeconfig /d/kube-config

（上面命令最后面的kube-config文件就是java-sample项目中wydevops/deploy目录下的同名文件，可自行复制到d盘根目录下，或修改上述命令中kube-config文件的路径）

执行完毕后，再次到ubuntu on windows命令行中执行：kubectl get pod --all-namespaces

可以看到两个服务被同时终止了。

至此，单chart打包多个服务成功验证完毕。

4. 单Pod多服务功能演示

        应用场景：K8S集群中Pod资源是很宝贵的资源，有时候客户给你部署服务的Pod数量可能是有限的。另一方面，为提升K8S集群的稳定性，我们部署的Pod也不应太多，还需要给它留出一定数量的用于服务水平扩展的Pod资源。还有另外一种情况，就是多个微服务只被某个服务调用，此时没有必要为这些服务进行单独部署，此时也可以考虑部署到一个Pod中。

        接着上面的例子，继续演示单Pod多服务功能。此时在ubuntu on windows命令行中执行：kubectl get pod --all-namespaces，已经看不到那两个服务了，如下：

首先，打开项目中的ci-cd-config.yaml文件，按照下图进行修改：

上图中，直接对refExternalContainers设置了一个Chart镜像的名称。wydeveops会检查该名称是否带有路径，如果没有带路径则尝试从配置的私库中拉取；如果带了路径则直接使用该路径下的chart镜像文件。如果路径是相对路径，则会在相对路径前加上当前项目主模块的路径（也就是wydevops-run.sh文件中的-P参数）。

下一步，清除项目中的ci-cd.yaml文件。

最后，在wydevops-run.sh文件所在目录打开git bash命令行，执行：bash wydevops-run.sh。

执行完毕后，我们在ubuntu on windows命令行中输入：kubectl get pod --all-namespaces，返回如下内容：

从图中可以看到，java-sample1服务已经运行起来了，并且其内存在2个Container。

现在来验证：

• 打开项目中wydevops/chart-build/values.yaml文件，可以找到deployment0参数下有如下内容：

这个是引入的外部Chart镜像(java-sample是按双镜像方式打包的)中的业务镜像。

在该文件中继续向下找，还能找到如下内容：

这是当前Chart镜像java-sample1的Container配置，开放的端口是8062。

继续向下找，我们可以找到Containers中第二个配置项，内容如下：

从上图可以看到，这个容器是java-sample服务的应用基础镜像，开放的端口是8052。

继续向下还能找到路由数据的合并信息，如下图：

• 接着继续验证，在ubuntu on windows命令行中执行：kubectl get deployment java-sample1 -n develop -o yaml，在其返回的内容中，也能找到上一步中出现的那些镜像，截图如下：

• 最后在通过浏览器访问：

http://localhost/wydevops/v1/sample/hello

http://localhost/wydevops/v1/sample1/hello

都能成功返回正确信息，如下图：

至此，单Pod多服务演示完毕。

      上述两种微服务合并发布的功能是wydevops为大家带来的强大功能之一，不论合并的多个Chart镜像其构建类型是否一致，都能正确合并成功。希望大家喜欢这个功能。 后续会再发文介绍一下wydevops操作yaml文件的组件，这是wydevops能如此强大的最根本核心。再后面会转向介绍wydevops的Jenkins工作方式，这个主要就是配置方面的讲解，核心的东西都在本地工作模式下讲解过了。

今天就到这里了，期待你的点赞、收藏和关注！