开发者学堂课程【如何贡献开源社区：云原生应用插件扩展：从开源技术 KubeVela 谈起:云原生应用交付会怎样发展】学习笔记，与课程紧密联系，让用户快速学习知识。
课程地址：https://developer.aliyun.com/learning/course/1196/detail/18135
从开源技术 KubeVela 谈起:云原生应用交付会怎样发展
内容介绍：
KubeVela
云原生时代的机会与挑战
云原生时代的 DevOps 技术
提问
一、KubeVela
KubeVela 和 K8S 两个之间具体的升级，能够帮助工程师在工作中更优质的体验，相对于开发者可能更接地气一点，因为 K8s 平台是偏大型的，可能更多的是给平台的工程师，比如像基础设施的一些工程师或者 sre 的工程师可能会涉及的多一点，今天介绍的项目是围绕开发者开箱即用，可以实实在在拿过去可能写几行代码或者执行几行命令，就可以让自己的业务跑到零上或者在容器里面去运行。整体来说相比于直接去运行 k8s 的可能不能做什么，而且要学的概念会少一些。项目的目标是希望大家用 k8s 技术的同时能够降低一些心智负担，写代码可以更快乐一些。
所以做一些工具、平台能够更好的去研究开发的过程，然后也能够更高效的去做一些事情，尤其是在现代云原生的生态里面可以更好的去驱动自己的业务发展。开源社区更多的是互补，如果是做一个偏内卷型的项目，可能就不能进某一个开源的生态，也会一定程度上阻止这种事情发生。在捐赠给 CF 的过程中，还有一些比如申请的过程，必须要讲清楚项目的独特性和陷阱，领域里面都在做事情特点是什么和其他的关系是什么，都是要非常重视并且回答的很好的。所以开源项目的维护者一般也会特别在意这一点，如果能够复用的绝对不会重新造轮子，讲述从开源技术 KubeVela 谈起云原生应用交付会怎样的发展。
从开源技术 KubeVela 谈起:云原生应用交付会怎样发展：主要内容第一块是云原生时代面临的机会和挑战；第二块是整个 DevOps 的相关技术云原生时代是怎样的，有哪些变化，应该有哪些新的东西，然后帮助开发者开发的更高效；第三部分是如何参与开源社区，然后云原生态园之间的一些关系。
更多的面向于普通的 DevOps 工程师视角去讲述问题。平时偏向运维平台或构建平台，所以会有一些群体上的差别。
二、云原生时代的机会与挑战
1、云原生带来了技术的全面升级
云原生的崛起，带来了交付介质、基础设施管理、运维模型和持续交付理论的全面升级和突破，加速了云计算时代到来。
随着云原生技术的不断的发展，在技术生态里面技术的历史在不断的变化，首先在二零一四年、一五年容器的镜像技术把整个单体应用的标准化基本上做完，写一份单体的代码，一个单体的 go 的代码或者一个 java 代码，可以随意的交付到任意的环境中，基本不存在差异，十多年或者七八年前还有很多讲段子是在本地写代码然后跑到生产环境中突然间不 work，现在有了容器尤其是容器镜像技术基本上段子也逐渐从生活中消失，不太会发生这个情况。
另外一块 Kubernetes 技术的不断的发展，基本上已经成为事实标准，不仅是在容器管理领域里面成为标准，已经逐渐成为一个基础设施的交付界面，交付界面相当于当于使用基础设施，比如使用计算存储或者一些运维的能力、网络的能力，都会通过 Kubernetes 去使用，在这个过程中也会有一些偏扩展性，在 Kubernetes 的基础上去通过写一些扩展，在 Kubernetes 的社区里面会叫 k8s CRD operrator，会写一些 CRD 做一些自动化的运维扩展，比如曾经写一个数据库的程序，想要写一个分布式的数据库是非常复杂的，搭一个 mysql 的主重组成为起来不容易，有 CRD 可以很容易的使用一个 mysql 集群并且是高可用的，几乎不需要去做运维操作，整体是自动化运维。另外一方面其他的非 k8s 形态比如 terraform等等很多围绕基础设施，sass、pass 平台的 api 提供的基础设施及代码的能力，ac 能力也在逐渐成熟，基本上可以看到 terraform的生态已经能够覆盖百分之八九十云的生态的各种 api，可以通过技术设施代码的方式去驱动整体的底座，可以看到现在的云计算能力更容易的去使用，只需要写几段配置就可以很容易的去驱动底层的基础设施代码，不需要再去写各种各样的复杂平台。
2、蓬勃发展的云原生生态
围绕 k8s 蓝图上面有近一千多个项目，可以看到 k8s 的生态非常繁荣，繁荣的生态里面有大大小小非常多的项目，基本上不可能全部看完。一方面证明了 k8s 生态已经成了一个实施界面，所有能力无论是运行、运维管理、灰度发布、CI 还是监控，所有的方面都在往 k8s交付界面上去继承，会看到蓝图上面的小卡片越来越多，生态是蓬勃发展的。
3、DevOps 工程师的生存现状
对于 DevOps 的工程师的生存现状是否有比较大的改善，从目前周围的朋友包括在社区里面接触到的一些普通的工程师，普遍说云原生里面的新概念太多，云原生的词刚造完又有很多新的词造出来，里面的各种技术也层出不穷，普遍说学不过来。
DevOps 开发和运维是分开的两种角色，希望运维的过程往 DevOps 方向靠近，开发的过程中也能负责运维或者开发运维一体化，下面的基础设施能力都很齐备，再也不需要去学习复杂的网络存储知识，可以有一定的能力把写的代码马上上线部署起来。过程中有很多理论，比如最有名的理论叫 shift left 左移理论，因为现在整体的基础设施 API 都已经非常的容易获得，在开发的过程中可以更加的关注质量，原先的代码要在设计开发和测试完以后到部署才能去控制代码质量，一般情况下开发和测试的是两拨人，可能要到测试团队开发已经完成，然后才关注质量，发现了很多问题然后再返工，效率明显很低，能最高效解决问题的方式肯定是在代码还没写的时候，比如设计计划的过程中知道代码质量行不行，然后在开发的过程中不断地开发马上上线实验，是最容易控制质量。左移是关注质量的时间周期越来越往开发去靠拢，意味着在开发能力非常强的时候效率非常高，因为在开发过程中马上就可以，以前传统的时候一行代码要在一个月两个月才能看到效果，现在一行代码完成几行命令，三分钟就能看到实际的效果，所以效率非常高，但是对于普通开发者只学习怎样写前端对，掌握各种的能力就像瘦弱勇士去挑战相扑选手，过程是非常痛苦因为需要学的东西太多。
4、工程师的认知负荷
不是工程师不够聪明，是现在的认知负荷有点爆炸，当只做简单的事情比如要回顾一个配置，认知在一个曲线相对下面一点，但是当学的东西越来越多比如创建数据库、开始去配置灰度发布、开始配置流量、开始配置存储的节点是用高效存储还是普通的云盘、开始关注集群的网络的时候，认知会不断往上攀升，了解的东西越来越多，工作的效率会降低。一个团队能够承载的认知负荷一定是有界限的，水平高的团队可能认知负荷高一点，水平低一点的可能相对来说偏中位线以下一些。合理的方式不是把所有右边的东西全都抛给开发团队，应该有一个界限，在开发团队认知的范围内能够理解的东西，应该让开发团队去操作，并且越灵活越好，因为藏的东西越多越不自由，只能受制于右边平台的团队，或者运维 FRE 团队来操控。
当认知超过就不应该关心太多，因为开发的心智负担越低，越容易把事情做好，同时也越稳定安全。对于不了解的东西可以凭勇气去点击一下，出事背后到底会发生什么就一无所知，很容易出现很大的风险，所以认知负荷控制在越合理的区间越好。
线会动因为随着能力的习得，比如开发团队已经了解配置，已经成为一个常识，就不需要了解太多，一个操作完了五年已经成为肌肉记忆，再增加一个新的技能有新鲜感，因为一个工程师工作三年、五年，只会点击一下上线发布按钮，新的知识都不会，一方面觉得很无聊，另一方面会焦虑，因为没有掌握新技能跟不上潮流，没机会跳槽，也学不到新的东西。
必然要让开发者时不时学点新东西，不能固定一个东西，业务也会发展，需求、场景也会变化，开发团队能够接受的负荷一定会缓慢地往上走，必须要能够灵活地提供扩展的能力给到开发者。
既不能太复杂，又不能太容易，要从开发者最核心的诉求开始出发，在云原生时代应该怎样去把平台做起来，或者普通的开发者到底应该用一个怎样的平台，DevOps 的流程到底应该怎样。
5、开发者对应用交付和管理的核心诉求
构建
开发和都署尽可能简单
易于获取且一致的开发/测试环境
易于发现和使用的API
交付
发布新版本不要影聘运行中的版本
安全、可灰度的发布环境
可回滚的版本管理能力
运行
服务能够厂24小时稳定运行
异常行为可观测
运行稳定且能够自愈
如果把当前一个软件的生命周期做一层抽象，整体一共分三个阶段，首先要写代码，把代码对应调用 API 了解，同时要开发、测试很容易得到测试环境，同时开发测试环境最好和生产环境相应的一致，比如可能依赖一些第三方的服务，依赖一些公司同事、其他团队一些微服务，同时还会依赖一些存储 API 或者中间件 API，要能够非常容易地发现和使用 API，在开发过程中要构建软件。第二个阶段是软件已经开发好，测试好就能够去把软件发布到生产环境，发布的过程是一个相对比较讲究的过程，因为现在很多都是互联网业务，每时每刻都有用户，比如直播，直播过程中发布应用直播用户全断是不能接受的，基本上都会要求能够灰度发布，在上线更新的过程中不会影响已有的用户，是一个恢复的过程，同时应该是一个安全的过程。如果发现发布新的程序软件有问题，也要能够快速的回本，所以在交付的过程中是核心诉求，可以恢复的发布。
第三个阶段是什么都没做的时候，软件最好能够一直稳定的运行，基本上正常的程序员也不可能期望软件没有问题，区别在于发生的待遇到底是高还是低，软件一旦出现bug 最希望的是能够一定程度让自己恢复，现在 k8s 一套基础设施云原生已经把这套理论了解很透彻，推崇的是不可变基础设施，如果软件出现一些 bug，比如挂了会帮你自动的重启，面向中态去恢复，网络出现 bug，出现抖动，会帮助自动的做一些迁移，比如某一台机器挂了，会帮你在另外一个地方再重新调度启动一台机器，所以这块的自愈能力在 k8s 生态里面已经做得很好，但是写了一些大规模的bug，或者相对来说非常异常的一些行为，可能已经没办法通过简单的自愈能力恢复的时候，可观测就需要能够让你快速的捕获到异常，并且报警。
所以在运行阶段最核心的诉求，在云原生的这套基础设施的基础之上，需要有一个比较好的可观测性的能力，才能快速地发现问题，甚至在事后定义的问题。
6、为什么 Kubernetes 解决不了?
what Kubernetesis not
Does not deploy source code and does not build your application.Continuous IntegrationDelivery,and Deployment
(CI/CD)workflows are determined by organization cultures and preferences as well as technical requirements.
翻译:K8s 故意不提供面向用户的应用交付与管理能力，因为
这个东西因不同团队、公司、文化差异巨大。
来源:Kubemetes 官方文档第一页
Google Kubernetes 团队首席布道师
Kelsey Hightower
@kelsevhightower
Kubernetes is a platform for building platforms. It's a better place to start not the endgame.
5:04AM·Nov 28.2017.Twitter Web Cient
251 Retweets44 Quote Tweets 752Likes
翻译:K8s 是一个用于构建平台的平台，它是一个很好的底座，而非终局。
诉求很简单就是构建交付和运行，简单的事情 k8s 生态这么多年却看不到比较好的结论或者 k8s 官方没有提供能力，因为 k8ss 不会提供这样的能力，在官网的第一页文档就写 Kubemetes 不是什么，Kubemetes 故意不做面向用户的应用交付管理能力，它认为应该是一个公共能够使用的底座，不想针对某一些可能跟不同团队不同公司存在偏好的一层去打交道，更多的偏向于基础设施。K8s 里面有很多步道师，Kelsey Hightower 是谷歌的国内首席导师名言，aKubernetes is a platform for building platforms. K8s 是一个用于构建平台的平台，不是拿过去用就好，是构建平台的开始，应该拿拿过去自己去搭一套平台给用户用，是一个很好的巨人应该站在它的肩膀上继续去操作。
