开发者学堂课程【如何贡献开源社区：云原生应用插件扩展：从开源技术 KubeVela 谈起:云原生应用交付会怎样发展】学习笔记，与课程紧密联系，让用户快速学习知识。
课程地址：https://developer.aliyun.com/learning/course/1196/detail/18135
从开源技术 KubeVela 谈起:云原生应用交付会怎样发展
四、提问
1、第一个问题
云原生技术项目比较多、堆处不久的，该如何系统的学习一些基础点？
看定位，如果定位是业务的开发，最好不要去所谓系统的学习，可能还开始一年前学的可能就别带掉了，除非定位是做平台开发者，开发者可能需要有一些比较好的底层技术技能，学起来快一点。如果大家想要了解基础，从怎么去写代码到发布 cdtop 概念去学，不要去学偏底下的，比如怎么去做工作负载管理，还是偏大家实际开发的过程中用到的技术切入更好一点，KubeVela 也是一个很好的切入点。
2、第二个问题
一个复杂的应用涉及多个后端微服务，前端微服务、中间件数据库等等，现在通过 hum 配合需要来实现一键部署，这个场景能否使用KubeVela 来实现达到一键部署的效果？
比较适合 KubeVela 的场景，首先 KubeVela 也是直接可以使用 hum 部署的，比如现在已经对这些服务都封装成了一个 hum 的包，需要的脚本可以替换成 KubeVela 的配置，封装成 hum 的包还是可以复用的，也可以关注一下社区里面的一些 hum 使用的文档。可以把 hum 的包完全用，另外一方面使用了 KubeVela 以后，相比于自己写的脚本，一方面是更统一，更规范的一个方式，因为大家都在使用比自己公司自己维护的需要脚本的可维护性强很多，另一方面是能力会更强一点，比如部署到不同的集群，不同云上会有一些可以直接使用的插件，相对来会有很多脚手架可以使用，不需要每一个都自己去写，未来也会有一些迁移的能力，比如平台变大来不及开发，想要现成的使用一个平台，如果用了 KubeVela 以后，就不存在把需要再迁移一遍，都是可以很容易地使用云上面 KubeVela 的服务，现在可能还没有那么完整，但是也希望未来有一个机会。
3、第三个问题
KubeVela 可以看作是一个平台和 paas 平台有什么区别？
KubeVela 可以认为它是一个 paas的内核引擎，不是一个完整的paas，完整的 paas 里面涉及到 cicd 到整个的管理，里面涉及的内容非常的多，KubeVela 明显是没有那么完整的功能，但是KubeVela 有一个很好的点，有一个框架衔接能力，就像一层胶水层，可以把现在 paas 里面的组件，比如自己有代码到镜像的一个构建过程，有一个可观测性能力，可以把这些能力衔接起来，有点像胶水粘起来，然后提供一个统一的入口给开发者用户，然后还可以管理不同的 paas，比如底下有以前一些老的平台，然后又想开发一个新的平台，可以用 KubeVela 来做一个统一的入口两边都一起管，然后它天然的支持用不同的实现提供统一的入口，然后也可以做牵引，会提供一层抽象的方式帮助管不同的环境。
4、第四个问题
KubeVela 在 k8s 生态有什么优势能够帮助 divorce 工程师解决哪些问题？
在 k8s 生态中，首先它是一个很好的应用抽象，通过一个顶层的描述就可以免去了解底下那些复杂的 API。另一方面，它有一个跨环境跨集群交付的能力，还可以跨不同的 K8S 集群，跨不同的云去做资源的交付和部署。同时也有丰富的插件体系，会有很多开箱即用能力可以帮助使用，包括 KubeVela 界面 UI 也是一个插件，帮助工程师解决最大的还是一个复杂性的问题，可以由浅入深地提供不同的能力。
5、第五个问题
如果异常掉电数据块部分写怎么办重新拉起破的数据怎么处理?
分两个层面,首先如果是数据面的一些附带比如 pod 已经运行在集群里面,集群不是 k8s 管的，不是由 KubeVela 管，是一个控制平面，底下的子集群断电，它的控制平面不影响或者控制平面的断电不影响子集群工作的 pod，另一方面是如果 k8s 本身的 KubeVela 和数据在同一个集群上就只有一个 k8s，这个时候 pod 断电跟之前不用 KubeVela 一样，比如是用 etcd 能恢复就能恢复，不能恢复确实会出问题，依赖于 k8s 运维，因为这个时候可能不是纯粹通过开源项目解决问题，可能更多依赖于对 k8s 本身的了解，如果不了解可能可以用云的 k8s 服务，比如阿里云 ect 服务。还有补充是不是基于 operate 来做，必须得分清楚它是数据还是控制面，KubeVela 在控制面工作和底下的模块不一样，KubeVela 本身的它控制用 operate 来做，控制面可以有三副本，底下控制面的程序也是通过 pod 来运转的，控制面的 K8S 里面的存储比如 etcd，KubeVela 存储就在 etcd 上面，如果用的是 K3S，K8S 控制面的的存储就可以切换成 mysql，对应的 KubeVela 存储也是 mysql。
6、第六个问题
对目前 KubeVela 社区生态是否满意，有哪些解决问题？
对目前 KubeVela 社区生态，自己打分打80分，现在的社区相对来说活跃，开发的频率也非常的高，热度非常好。另外一方面和顶级的开源项目，比如 kenneth 社区还有一定的差距。如果一定要解决问题，可能更多的还是要实现一个社区的自治，更多的人能够参与进来，能够完成一个从 review 的 approval 到每天的一个成长体系，然后大家社区能够更多的有主动的设计，主动的驱动，现在可能主体的工程师还是来自于阿里，未来希望社区能够更多的资质，整个社区才是真正相对来说特别繁荣的状态。社区里面有很多的工程师来自于不同的公司，尤其像招商银行，有投入了十几个工程师在里面全职的开发，投入非常大，然后也有很多晋级成为 review approval 的成员，所以看到趋势也在不断的变化，所以整体来说还是有很大的信心。
7、第七个问题
是不是认为 kubernetes 和 dx 是相爱相杀的关系， kubernetes 不解决 dx 的问题，不存在相爱相杀，是平行世界的两个不同的角色，更多的可能是互相看不见，dx 偏要去用 kubernetes 也没办法，还是要用新的东西，应该考虑 KubeVela。
8、第八个问题
目前1.4版本支持性状环境吗？
可以到社区细聊一下性状环境到底指什么。
9、第九个问题
KubeVela 来自大厂贡献，对个人开发者或者小企业是不是不太友好？
不太正确，KubeVela 有很多大厂贡献，不完全是大厂贡献，现在有一百五六十个贡献者，里面可能有百分之四五十是个人开发者或者企业，也能贡献所以不存在友不友好的问题。目前 KubeVela 的贡献，一般提一些 KubeVela 问题都愿意帮助回答。现在时机是非常友好的对于个人开发者和消息。
10、第十个问题
KubeVela 如何结合 terraform 或者 plumb 做云原生配置的交付和管理？
KubeVela 完全可以和 terraform 做很好的集成，plumb 目前的集成能力稍微差一点，KubeVela 有专门 terraform 的 control，把 terraform 工具变成云原生的 crdoperator 控制器，可以到社区里面来进一步了解，完全是集成能够天然使用 terraform。
11、第十一个问题
Crossplan 和 KubeVela 的区别？
以前是一起的，以前和 Crossplan 一起开发 OAM，Crossplan 项目更偏向于对云资源的管理，和 terraform 是竞争对手，KubeVela 更偏向于整体的应用层，Crossplan 和 KubeVela 工作在两层，Crossplan 相当于管理云资源的编排，KubeVela 管理整体的应用，包括云资源加容器加上运维能力。KubeVela 可以使用 Crossplan 来替换 terraform，如果 KubeVela 有个插件叫云资源管理，既可以选择 terraform，也可以选择 Crossplan，Crossplan 和 terraform 互为替代的一个关系，都是 KubeVela 底下的插件的能力。
12、第十二个问题
性创是从 cpu、内存、磁盘都是国产的服务器
KubeVela 能够兼容 k8s 环境，性创的环境服务器如果能够支持 k8s 就没问题。还涉及到 k8s 版本的问题，K8S 的1.18开始一直到1.22 KubeVela 都是很好的支持，如果做一些 APP 一直到1.16也能支持，但可能需要自己去做一些配置上的调整。
