开发者学堂课程【云原生技术趋势与行业发展解读：从 KubeVela 谈起：云原生应用交付会怎样发展】学习笔记，与课程紧密联系，让用户快速学习知识。
课程地址：https://developer.aliyun.com/learning/course/1035/detail/15146
从 KubeVela 谈起：云原生应用交付会怎样发展
三、云原生与开端：如何高效参与社区
第三部分就是社区了，大家可以看到，其实kubevela社区已经相对来说比较成熟了，在去年的CFTop的统计里面kubevale整体的活跃度是在top的这个30里面的，就是第29位，中国是第五位，那在这个统计里面第一名，就是大名鼎鼎的这个项目，所以，这个榜单也非常的具有权威性，也能证明kubevela的这个社区，是非常活跃的，同时我们有很多的这个这个社区的用户啊，还有非常多的贡献者，同时，这个社区也是中英文双语的，它是一个国际化的社区，就是你如果你英文好一点，也可以跟国外的用户，一起去交流分享经验。同时，如果你对参与开源社区非常感兴趣，这个项目也是一个很好的这个机会，一方面社区的核心的一些成员，大家都是国内的工程师，对于国内的，比如说语言上的障碍，你用中文去提问，沟通都不是问题，大家都可以很快的回复你。另一方面，如果你的这个水平很厉害了，你也天然的通过这个项目了解了国际化的开源社区运作的方式，可以学到的开源社区的运作，和cnCF其他的项目，国际化的一些项目是严格一致的，运作机制，规则，包括社区治理的方式，也是严格一致的，所以如果你玩的好的话，你也可以了解整个云原生生态里面的开源项目玩法，并且，拿这个作为一个桥梁，也可以参与到社区里面其他的项目里面。
所以，我也非常的欢迎大家参与到快乐社区来，可有机会先了解刊物，刊登解码，这个是一个搞开源一个很大的误区，我也是搞了三五年以后才理解，其实对于开源社区的维护者来说，写代码真的不是最重要的，重要的就是真的不起来用，感受一下到底这个项目能够提供什么功能，然后完了以后呢，就开始讨论，一方面就是有很多的社群，就是社区里面有会议，有一些像钉钉群，微信群，这些国内外的这种交流，不同的用户，你也可以去提一些issue，发一些这个discussion或者就是说你想要做某一个功能，你反馈某一个功能。或者怎样一定要写代码，你可以把这些发现的问题都可以提出来，这里面有一类特殊的问题，安全问题，可能有安全漏洞，那这个时候呢，你就不太适合跟其他方式一样，就直接去向公众暴露，你可能要去联系，在项目里面的一个安全邮箱，给这个邮箱，发对应的issue，你发现问题，那我们看到维护者看到以后会第一时间的反馈这个问题，并且去修复它，然后同时，修复完以后给大家整体的公开。
另外，你就可以整理issue，就是我们社区基本上每天都有几个会出现这个维护者的经历，其实也不能说每时每刻都在盯着里面的新的问题，那也非常希望大家能够参与进来，比如说，你觉得某一个人的需求就是你们公司想要的，或者就是你在开发过程中遇到的问题想要解决，你可以在下面留言，你是怎么解决的，有一些可能就是绕过这些问题的方式，又或者你就想这个问题你可以给他点个赞或者留言说，你非常想要解决这种情况，其实是可以加速这个问题被发现的概率，并且能够加速她被修复的概率。同时你也可以去社区里面去打标签，我们有一些完善的机器人，你只要留言就可以帮助这个issue的自动打标签，不需要有一些特权，同时也可以去看看大家到底关心什么问题，看看这个生态里面的趋势是怎样的，然后另一方面第三块就是贡献文档很简单，就是看到有错别字你想要去翻译一下，哪些地方发现英文没有中文或者中英文不一致你可以去纠正他，你有的时候发现你这个描述可以写的更好，那你可以去修改或者发现一些模块功能没有文档，那自然我们也非常欢迎您把这个文档加上去，第四就是给这个点赞，其实也是对于社区的支持。比如说当你在使用这个项目了或者说你们公司用了那么你可以来在社区里面把你们使用这个情况给大家分享培养去登记一下。然后第二个就是代码贡献，代码贡献的话也这里面有非常完善的文档，里面其实是非常依赖大家去了解读这个文章看看，我们也整理了很多的，比如说环境，开发规律，整个的这个代码更新文档，其实也是对自己、程序员写代码的一个修炼，它里面也会教你一些最基本的go语言，空间的开发的一些基础知识，包括一些开发规约，一些大家尝试，就是生态里面的核心，每天绝对是一些常识性的东西，但你可能不太了解，那么你可以去学习一下。同时，如果你要开始写了，你就去找一找这种标签，Goodfirstissue就是特别好的，适合当第一个练手的英雄，或者说标记了，要不可能就需要你搭把手，他可能不在这个关键路径上面，但是也是一个好的，这个去贡献的一个点的时候，可能会标记上，那你也可以去看看kubevela，自己有能力去解决这个问题，就是kubevela作为一个平台项目，他不光是这个平台自身的开发，他会有一系列的这种周边插件，包括使用的，比如说你部署一个小游戏，或者部署的一个其他的项目里面会有一系列的使用这种经验，也非常欢迎大家把这些最佳实践，能够分享出来。去扩展这个生态，做一些插件。最后我想说的是，就是这个社区的成功离不开所有贡献者的努力，更离不开大家持续的去贡献。因为社区的繁荣其实是一个需要持续投入，持续演进的过程，它不是大家就是脑子一热，觉得我今天想要去贡献一行代码就结束了，他其实是需要大家不断的去投入，更多的可能是希望大家能够和自己实际工作中的场景相结合起来，就是能够开源，和自己内部公司的业务需要相结合，这种的是自然是我们在社区里面，比如说也跟这个dnf的其他项目一致也有一些社区治理的体系，比如说你贡献了几个pr以后有了一些代码贡献或者文档或者其他的一些贡献，贡献第一个以后你就成为贡献者，然后你贡献了几个以后你就可以申请说我想成为这个社区的成员，你可以去这个仓库里面去提议说我已经达标了这个标准也很低，你可能只要贡献一到两个代码的pr或者贡献几个文档的就可以，你只要去提交几次代码，就是提交几个pr就可以成为这样一个社区成员，然后再往后也在这个文档里面有清晰的定义分别是有什么职责，要做到什么样才能达成，这里面在网上可能就是要偏大家不断的出现，然后贡献的更多同时参与到一些社区的讨论方向的制定等等里面去，整个社区呢最终也是一个开放式的这个社区，大家谁贡献的多，并且持续的多，就会有一个每天的席位，并且有一些投票权话语权，他是严格遵循CNCF这个模式的。
然后，我们每周，也会有会议，一次隔一周，就是比如说昨天刚开完中文的会，那么下周二的时候我们会有一个设计，再过一周再开会，但是中文的社会，如果你只参加中国国内社区的话，那么就是两周一次，如果你国内国外都参加的话，你就会每周都可以参加呢，我们也会挑选一些有意思的话题，包括不同的这种社区里面玩法，大家的时间去分享。
最后，其实就是分享一些这个近期的roadmap，时间也比较紧，大家如果关心这个项目的话，其实也可以参与到里面来，我们在当前的这个节点呢，我们也会去更多的投入到可观的相关能力，然后同时，我们会去做这个应用市场的能力，我们的应用可以导入导出到另外一个平台上面，在oam，kubevela上面做的这样实现的时候，就可以无缝地做切换做迁移，然后，我们会增加一些像微服务的治理的能力，多群之间的多环境之间的这种流量的恢复能力，同时，也会增强一些安全策略的一些能力，然后到今年这个12月份的时候，我们希望在更进一步的去提升这个开发者的体验，包括增加一些关于链条持续机器的能力，整体就就是这些了。
Q&A
第一个问题：云原生的技术和项目是比较多的，对接触不久的工程师该如何系统的学习一些技术？
回答：其实还是看大家的定位，如果大家的定位是业务的开发，那么其实最好不要去所谓系统的学习，这样的话你学个一年半载可能还没干这事儿就技术一年前学的技术可能就迭代掉了，除非你是定位是做平台开发者平台开发者，可能是需要你有一些比较好的这种底层技术的，一些技能的话学起来会快一点，所以我推荐如果大家只是想要了解这里面基础技术的话，可以从你怎么去写代码到发布这些概念去学，不要去学比如说怎么去做工作负载的管理，偏大家实际开发的过程中用到的技术切入更好一点，kubevela也是一个很好的这个切入点，刚刚也提到了，也非常欢迎大家来试一试。
第二个问题：是一个复杂的应用设计多个后端微服务，前端微服务，中间件，数据库等等，现在通过我们配合需要来实现一键这个场景能否使用非来实现达到一键部署的效果。
回答：这个其实就是比较适合的场景。首先，也是直接可以使用helm部署的，比如说你现在已经对这些服务都封装成了一个黑暗的包，那么你的那些需要的脚本就可以替换成kubevela的配置，你的那些封装成helm的那些包还是可以复用的，你也可以关注一下社区里面的一些helm的使用的文档。就是你可以把那些helm的包完全复用，另外一方面，你使用了以后，相比于你自己写的那些脚本啊，一方面他是更统一的，更规范的一个方式，因为大家都在玩这个，比你自己公司自己维护的，脚本的要可维护性强很多，另一方面就是他的能力会更强一点比如说你想要部署到不同的集群，不同的语音上面，会有一些直接可以使用的插件，所以，相对来说，你会有很多脚手架可以使用，就不需要每一个都自己去写shell。然后你也会未来也会拥有一些迁移的能力，比如你自己的这个平台变大了，有点来不及开发了，那你想要现成的使用一个平台，那你如果用了kubevela了以后，就不存在把这个shell再迁移一遍了，你可以很容易地使用云上面的这种服务，那现在可能还没有到那么完整，但是我们也是希望未来有这样一个机会。
第三个问题：这个kubevela平台和paas平台有什么区别？
回答：其实kubevela你可以认为它是一个paas的内核引擎，他不是一个完整的pass，因为完整的pass里面涉及到CICD到整个的管理，它里面涉及的内容非常多，KUBEVELA明显是没有那么完整的功能，但是kubevela它有一个很好的点，就是它有一个框架衔接的，它就像一层胶水，它可以把你现在paas里面的组件，比如说你自己有代码到镜像的一个构建过程，有这样一个可观测性的能力，可以把这些能力衔接起来，有点像胶水，把它们粘起来，然后提供一个统一的入口给到你的开发者用户，然后同时，它还可以管理不同的paas，比如说你底下有以前的一些老的平台，然后又想开发一个新的平台，那你怎么样两边都一起管，你可以用kubevela来做一个统一的入口，然后它天然的支持不同的这个实现，提供统一的入口，然后，也可以做迁移可能他会给你提供一层，这个抽象的方式，然后帮你管。
第四个问题：kubevela在kbs的生态中有什么优势，能够帮助工程师解决哪些问题？
回答：其实刚刚一直在说的就是这些问题。在kbs的生态中，首先它是一个很好的应用抽象，你通过一个顶层的应用的描述就可以免去了了解底下的那些复杂的API。另外一方面，它有一个跨环境、跨集群交付的能力，它可以跨不同的群，跨不同的云去做资源的交付和部署。然后同时，它也有丰富的插件的体系，它会有很多开箱即用的能力，可以帮助您使用，包括kubevela的界面UI也是一个插件。帮助工程师解决的最大的还是一个复杂性问题，他可以由浅入深地给你提供不同的能力。
第五个问题：如果异常掉电，数据块部分怎么办，重新拉起的数据怎么处理？
回答：这个其实分两个层面，就是首先就是如果你是数据面的一些负载，比如说你的kbs已经运行在自己群里面了，这个集群的话，其实不是油的那个不是由库管，库管是一个控制平面，它底下的那个子集群断电，他其实也只是影响它的控制，或者说控制平面锻炼，不影响你子集群的工作，另外一个方面，就是如果你的这个K8S本身你的数据在同一个机器上就只有一个K8S，那这个时候断电，就跟你之前不用出来了一样。
他就是你比如说你是用的etcd，能恢复就能恢复，不能恢复那就确实出问题了，这个其实依赖于你的k8s的原理。这个时候其实我也推荐他可能不是可以通过开源项目能解决的问题，他可能更多依赖于你对于k8s本身的了解，那可能你如果不了解的话，可能不能更好的可以用这个云的k8s，然后下面还有一个补充，就是不是基于operate来，这里面其实我们必须得分清楚，它是数据面还是控制kubevela，本身他在控制工作，他和底下数据面的那些模块不一样，然后kubevela本身的它的这个控制适用operate来做，他的这个控制面可以有三副本，那底下的控制程序也是通过pod来运转的，然后那个控制面的k8s里面的存储，比如说etcd的客户kubevela的存储呢，就在etcd上面，如果你用的是K8S，K8S控制面的K8S的存储，就可以切换成micicle。对应的kubevela存储也是micicle。第六个问题：老师对目前kubevela社区生态满意吗？还有哪些要解决问题？
回答：其实对前途未来社区生态如果自己要打分的话，应该要打80分，就是现在的这个社区，其实我们可以看到它是相对来说很活跃的，然后开发的这个频率也非常的高，热度非常的好。在另外一方面，我们和顶级的开源项目，还是有一定的差距，如果硬要说还要解决哪些问题的话，我觉得可能更多的还是要实现一个社区的自治，就是更多的人能够参与进来，能够完成这样一个从review到provea到pretend这样一个成长体系，然后社区能够更多的有主动的设计，主动的驱动，然后现在，可能主体的工程师还来自于阿里，未来我们希望社区能够更多的工程师，这样的话，整个社区，才是真正的相对来说特别繁荣的一个状态。
但是现在我们也可以看到，我们社区里面有很多的工程师来自于不同的公司，尤其是像招商银行，他们有投入了十几个工程师，在这个里面开发，我们也看到他们投入的非常的大，然后，也有很多晋级成为这个review approval的成员，所以我们也可以看到这个趋势，也在不断的这个变化，所以，我们整体来说还是有很大的信心的。
第七个问题：老师是不是认为kubenetic和devops是相爱相杀的关系？
回答：其实刚刚讲了很多，就是肯定他不存在问题，不存在相爱，他们可能就是平行世界的两个不同的角色，就是更多的可能就是互相看不见，我觉得可能就是现在，说白了就是devops偏要去kubenetic那里了，那人家爱答不理，你也没办法，还是要用新的东西，工程师不要一直死磕kubenetic应该考虑kubevela。
第八个问题：就是目前1.4版本支持性环境，
回答：这个问题我不太了解，回头可以到我们社区来一起再细聊一下这个现状环境到底指的是什么。
第九个问题：kubevela来自大厂，对个人开发者或者小企业是不太好，这个我觉得不太对，kubevela是有很多大厂，但是他不完全是，大厂现在有一百五六十个贡献者，里面有可能百分之四五十五六十是这个所谓的个人开发者或者小企业，我觉得他们也是所以不存在有问题。反正是我觉得目前的这个状态，其实每天大家都问一些k8s的一些问题，一般他们都愿意帮助你。所以现在这个环境，其实是非常友好的。
第十个问题：kubevela如何结合promise做原生配置的交互和管理。回答：这个有点太偏细节了，有专门的terephone的controller，就是把terephone这个工具成了原生的c rd operator控制器。你可以到社区里面来进一步的玩一玩，了解了解，就是完全是集成，能够使天然使用这个开户。
第十一个问题：crossplane和kubrvela的区别方面介绍一下。
回答：他们以前是一起的，之前两者是一起开发OEM的。然后这个crossplane项目，更偏向于对云资源的管理，他和terephone是竞争对手，kubrvela然后更偏向于整体的应用层。那其实是工作在两层，相当于crossplane管理的是云资源的平台。kubrvela管理整体的应用，包括云资源，容器，加上运维能力。然后其实可以使用crossplane来替换terephone，也就是说如果里面有一个插件叫资源管理，那我既可以选择crossplane也可以选择terephone。就是这样共互为替代的一个关系，但是他们都是底下的插件能力。
第十二个问题：性状从cpu到内存、磁盘都是国产的服务器。
回答：这个其实为了能够兼容所有批发环境，k8s的环境能够兼容的话就没问题，当然这里面还涉及到一个K8S版本的问题，就是K8S的1.18开始一直到1.22都是很好的支持，然后如果做一些hag的话，一直到1.6也能支持，但可能需要你自己去做一些配置上的调整。
