吴就业

由于方向的错误，我们这个项目也迎来了终结。但我们换了个方向做云原生SaaS平台，而这个平台也不再基于kubevela，也不使用云厂商的Serverless，而是自实现Pod调度器，结合云提供的节点弹性扩缩容，实现自己的Serverless，没有最低request的限制，并通过超卖算法，实现资源的合理利用，进一步优化成本，体现Serverless的优势。此篇是该专栏的完结篇，后续该专栏不再更新。

由于terraform-controller使用的terraform docker镜像使用的terraform版本太低，import不支持把data也渲染出来，所以需要自己打一个terraform docker镜像。另外，由于高版本import出来的tf，用低版本apply也会有问题，同样需要重新安装terraform-controller addon插件，指定terraform-controller使用我们自己打的terraform docker镜像。

方案一的好处是，上层使用上没有任何区别，整条链路上没有任何改动。而方案二会修改application.yaml，且不会跑terrafrom-controller的逻辑，整条链路实际上是不完整的，导致测试覆盖率低，有一些底层的问题无法在测试阶段发现，例如terraform-controller可能存在严重的bug。方案一的缺点也很明显，因为需要mock非常多的接口，而且还需要对混合云提供的terraform provider的代码或者相关接口非常熟悉才可以。学习使用成本太高，效率没有方案二高。

考虑到成本计算的问题，以及业务的加入退出问题，我们在每个区域部署一个代理集群，在代理集群上部署四层代理Nginx，通过四层代理将kubevela发起的kubenetates api请求转发给目标k8s集群。在公司网络规划上只允许一个区域的一个VPC跟另一个区域的一个VPC打通，同区域不同机房的网络都可以打通的网络架构基础上，由于一个区域可能有多个业务，业务的k8s分布在不同云厂商或机房，要让kubevela管理分布在各个地域机房的K8s集群，需要引入代理。

由于kubevela以Addon提供安装扩展，因此我们需要用Addon作为自定义工作流步骤的载体，通过Addon安装工作流步骤和升级、卸载工作流步骤。自定义工作流步骤需要使用CUE语言，并且只能使用语言本身支持的操作和kubevela为我们提供的一系列内置操作。假设我们自定义一个工作流步骤是调用一个接口做某件事情，如果接口返回0，就是需要暂停工作流步骤等待人工完成审核，如果接口返回1，就是审核通过需要恢复工作流步骤，如果返回2，就是审核被驳回，需要终止工作流。发送http请求的HTTPDo操作。

平时的技术方案设计都会受限于我们当前所掌握的知识，我们只能设计出我们认知范围内的方案。

从Terraform controller源码ConfigurationReconciler类可以找到，terraform镜像可以从环境变量“TERRAFORM_IMAGE”取，而Terraform controller会打包成helm chart，通过查看helm chart的terraform_controller.yaml文件，发现。。。

terraformProvider、multiclusterProvider、oamProvider、configprovider、kube这些provider的Install方法注册了很多操作处理方法。这些方法就是提供给CUE中调用的方法。

kubevela安装一个Application的过程，就是执行工作流上的每个步骤的过程，并且当我们未配置工作流，kubevela会自动为组件的部署生成一个工作流步骤。工作流可以插入人工卡点，也可以插入一个read-object的工作流步骤，来衔接前后两个工作流，实现数据的传递。而当我们配置工作流后，组件的部署就需要我们编排，kubevela不会再为组件的部署生成任何工作流步骤。工作流的编排可以指定步骤的依赖关系，哪个步骤依赖哪个步骤，被依赖的步骤先执行。

terraform-controller是一个专门负责terraform一类的组件"安装"的Operator，通过打包成helm，再封装成kubevela的Addon，由kubevela安装到管控集群，为其它terraform provider插件提供模块定义支持。

addon支持从本地、git仓库、helm chart仓库安装，最终原理都相同，因此我们以本地安装为例。

我们需要将mycloud terraform provider包装成kubevela可安装的Addon插件，并且通过提供私有云基础设施资源对应的terraform module，用来生成kubevela中的组件定义，这样我们才能够在application部署描述文件中，通过为应用添加组件的方式，声明使用我们的基础设施资源。

以使用阿里云的基础设施为例，如何在kubevela上交付基础设施。

执行vela up -f application.yaml命令，实际就是将application.yaml apply到k8s中（这里指的是kubevela底座的k8s集群，即管控集群），然后由application_controller监听事件处理application的安装/更新。application_controller中会将应用的部署转为工作流（Workflow），每一步称为一个工作流步骤（WorkflowSteps），安装应用，就是按依赖顺序执行工作流步骤。

官方文档把模块定义比作乐高积木，非常形象且易于理解：模块定义是组成 KubeVela 平台的基本扩展能力单元，一个模块定义就像乐高积木，它将底层的能力封装成抽象的模块，使得这些能力可以被最终用户快速理解、使用并和其他能力组装、衔接，最终构成一个具有丰富功能的业务应用。

体验什么叫yaml开发工程师

上一篇我们以一个简单的vpc资源为例，学习terraform provider的开发全流程，这篇主要介绍实际项目开发中我们可能会遇到的问题。这两篇以快速入门和避坑经验分享为主，推荐阅读官方文档学习更多。

介绍如何为私有云开发一个terraform provider。

通常申请IaC，我们需要向运维描述我们需要什么IaC、什么规格，运维根据我们的描述去检查是否已经申请过这样的资源，有就会直接给我们使用IaC的信息，没有再帮我们申请，然后告诉我们使用IaC的信息，例如mysql的jdbc和用户名、密码。如果将描述代码化，IaC的申请自动化，就能实现“基础设施即代码”。而terraform就是实现“将描述代码化”的工具软件。

一种方案就是添加一个controller（operator），监听terraform job创建的pod，然后给pod添加finalizers，然后监听job的删除，在真正删除之前先获取pod的容器的日记，将日记通过configmap保存下来，或者发送event。

当我们一个中间件使用多个configmap的时候，每个configmap的挂盘路径是不能一样的，否则后面的会覆盖前面的，另外subPath也是不能用的，这样会导致configmap内容更新的时候，容器里面的配置文件不会更新。

Kubernetes apiserver提供两种特殊的准入控制器，分别是MutatingAdmissionWebhook和ValidatingAdmissionWebhook。这两种准入控制器，将发送准入请求到外部的HTTP回调服务，并接收准入响应。准入控制器就是在对象持久化之前用于对 Kubernetes API Server 的请求进行拦截处理，在请求经过身份验证和授权之后放行通过。Mutating准入控制器可以修改被处理的资源对象，Validating准入控制器则不能修改。

虽然API上并没有对如何设计资源的状态做任何约定，包括kubernetes在1.19版本之前提供的内置资源，它们的状态也并不都遵循约定，但状态的设计建议还是遵循官方新提出的约定，可参考这篇《kubernetes设计与实现-API设计约定-condition设计约定：https://renhongcai.gitbook.io/kubernetes/di-shi-liu-zhang-api-she-ji-yue-ding/1.2-api_convention_condition》。

Operator是什么，为什么中间件云原生需要Operator？中间件云原生改造一定需要Operator吗？

使用PV+PVC方式，实际就是挂载一个远程文件系统/块存储设备，存在网络I/O性能开销，具体性能影响，要看远程文件系统/块存储设备的实现原理，可能会利用本地磁盘暂存+内存缓存减少一些网络I/O的开销，但肯定比不上使用节点本地磁盘。

Serverless、ServiceMesh是2023年全球架构师峰会（北京站）出现频率最高的词，本篇将从这两个方面分享笔者参会了解到的一些信息。参与此次会这后，我更坚信我们云原生项目所走的方向的正确性，以及预测到未来需要解决的难题。

在实战的过程中，我自己做了很多笔记，从模糊到清晰，逐渐了解云原生架构，不仅参与了中间件容器化架构改造与自动化部署Operator开发，还参与了IaC基础设施即代码的开发，kubevela terraform Addon插件开发，从应用层到中间件到基础设施都有参与，整条链路的一些核心原理都非常清晰。其实不仅是我，整个团队，包括领导，大家都是0经验，一点点学习摸索，请教一些资深的专家。我将通过专栏的形式，将笔记脱敏，并增加一些内容，形成从0基础入门学习的教程，当然，专栏是收费的，毕竟不是为爱发电。