原创 吴就业 141 0 2023-10-13
本文为博主原创文章,未经博主允许不得转载。
本文链接:https://wujiuye.com/article/f6887f937f3b489a86a0f8659094ade3
作者:吴就业
链接:https://wujiuye.com/article/f6887f937f3b489a86a0f8659094ade3
来源:吴就业的网络日记
本文为博主原创文章,未经博主允许不得转载。
KubeVela于2020年年底开源,距离现在还未满三年时间,是一个非常年轻的产物。KubeVela是非常创新的产物,如OAM模型的抽象设计。所以也并未成熟,除了官方文档,找不到更多资料,在使用过程中,我们也遇到各种大大小小的问题。
Terraform Controller是KubeVela提供的一个terraform插件,用于实现基础设施组件的部署。我在打通kubevela到混合云基础设施交付这条链路上,遇到的问题基本与Terraform Controller有关,而且我们也并没有什么奇奇怪怪的用法,就是非常简单的实现申请一个基础设施资源,但这样都能遇到很多问题。
我认为KubeVela的OAM模型也并非是完美的设计,它目的是通过一份application.yaml描述将部署一个应用依赖的中间件、基础设施都部署起来,但它没考虑到,多个应用依赖相同中间件以及相同基础设施的问题。
可以得出的结论是:kubevela还很少用户,使用kubevela交付基础设施的用户更少,使用kubevela交付中间件的用户更少,使用kubevela打通私有云/混合云交付基础设施的用户说不定我们是排在前面的。
在实践的过程中,我们遇到很多问题,事实告诉我,如果不研究透从一个应用的yaml编写到应用部署完成,包括基础设施资源的申请,我们以一种懵懂的状态根本hod不住后期投入生产使用可能出现的各种问题。而且当前遇见的问题也没有办法解决。所以我把KubeVela、Terraform Controller的源码看了一遍,并且尝试去修复遇见的一些问题。
也有些问题没办法通过提PR解决,属于架构本身的缺陷,但我们了解原理之后,能够通过编写插件去作为补充。
通过前面的学习,我们应该了解了terraform-controller实现申请基础设施资源的原理是:启动一个Job,这个Job负责拉起一个Pod,Pod有一个容器是负责拉hcl代码的,有一个容器是负责执行terraform apply命令的。
k8s的Job有一个参数是backoffLimit,指定Job的最大重试次数,默认为int类型的最大值,可以说是无限重试。由于我们混合云平台提供的申请基础设施的api,其最终还是通过人工去处理工单的,例如当我们执行terraform apply申请vpc资源时,terraform调用混合云的api创建vpc,实际是生成一个工单。当工单被驳回时, terraform就会抛异常,Job执行失败,于是就会重试,就会创建新的同样错误的工单,如此反复。
因此这个PR就是支持配置backoffLimit参数,very simple!
将ConfigMap或Secret资源当作Volume挂载给Pod,要求ConfigMap或Secret资源必须与Pod在同一个namespace下才,否则会挂载失败。
这个PR是增加对要挂载的ConfigMap和Secret资源的命名空间的校验,然后给出正确的错误提示,且提示带有指导用户如何修改可以解决此问题的信息。不仅让用户能够知道问题错在哪,还要指导怎么解决问题。不至于看着无指向性的错误信息,拿去问ChartGPT都无法找到问题原因。
我们经常遇到由于各种原因导致 terraform apply命令无法执行成功,例如应用部署时指定了错误的namespace,这个namespace中又缺少“git ssh”这个Secret资源,由于IaC组件部署需要执行git clone拉取hcl代码,需要依赖这个Secret资源,不存在就无法拉取代码,就无法执行terraform apply,也就无法部署基础设施组件。
在这种情况下,我们需要卸载应用,而不是将“git ssh secret”添加到这个错误的namespace中,以使应用中的基础设施组件terraformApply执行成功再卸载。但是,我们会无法卸载这个应用程序,因为terraformDestroy同样的道理也无法执行,基础设施组件无法卸载。
这个PR就是解决这个问题,通过在执行terraformDestroy方法之前,检查“tfstate”文件是否存在,以及根据tfstate文件内容判断是否曾经apply成功,如果是,则执行terraformDestroy,否则跳过terraformDestroy。
了解底层,学习源码的目的,不是为了提PR,而是为了知道怎么用,遇到问题怎么解决。
平时的技术方案设计都会受限于我们当前所掌握的知识,我们只能设计出我们认知范围内的方案。所以我们云原生才搞的这么曲折,前期花了大量的时间调研学习。
初中学习物理有个知识点叫相对运动,需要有参照物。问题复杂度也是相对的,对于我而言算难题的对于你来说可能并不算。
因为前期投入时间去研究kubevela和terraform controller,为后期做存量基础设施资源导入,定时刷新output等需求扩展了认知,原本难度极大的需求,就变成了一个非常简单的需求。
声明:公众号、CSDN、掘金的曾用名:“Java艺术”,因此您可能看到一些早期的文章的图片有“Java艺术”的水印。
本篇介绍的内容是scheduler-plugins框架的LoadVariationRiskBalancing插件,这是一个k8s调度框架的评分插件,基于request、均值和标准差的K8s负载感知调度器。 我们通过实验去理解和验证该插件实现的负载感知均衡调度算法。
在降低增笑的大背景下,如何在保证稳定性的前提下,做到极致压缩k8s资源的使用,实现基础设施真正的按需付费,是我们云原生项目的目标之一。要实现如Railway这种产品的基础设施按实际使用付费,不能简单的使用云Serverless产品,因为这些产品都有最低限额的要求,例如阿里云最低限制要求Pod至少0.25cpu+0.5g内存,但其实大多数应用这个配额都用不到,大量的时间cpu负载几乎为0,内存消耗可能也就几十M(Java应用除外),大量的低使用率的Pod会造成资源的浪费。
我们在做云原生调度技术调研的时候,为了做实验获取一些数据,需要编写一个demo,支持动态模拟cup使用率和内存使用,所以用go开发了这么一个web程序。
由于我们的使用场景是将基础设施资源定义成KubeVela的组件,一个terraform “module”对应的就是一个kubevela的组件,对应terraform-controller的一个Configuration资源。因此导入的最小粒度是组件,即一个terraform “module”。
官方提供的工作流步骤有限,另外,对于自研的PaaS平台,我们需要借助工作流步骤实现一些例如存量项目基础设施导入、项目环境初始化、平台组件共享基础设施需要解决的差异对比审核、基础设施漂移等。
订阅
订阅新文章发布通知吧,不错过精彩内容!
输入邮箱,提交后我们会给您发送一封邮件,您需点击邮件中的链接完成订阅设置。