云原生时代的DevOps平台设计之道( 三 ) _生活百科

在这方面 KubeSphere 做的更加全面，通过集成 Jenkins 实现了基于图形化的流水线配置，这种方式对于以前就在使用 Jenkins 的团队很友好。并且这种实现继承了 Jenkins 生态原有的高自由度，可以更好的将其他第三方CI工具纳入流程之中。
Rainbond 通过在构建流程中加入自制的自动触发能力，也可以完成部分流水线工作。这种配置相对编写 Jenkinsfile 来说更简单一些，能够满足一些基本场景。然而其扩展性和自由度不足，能够接纳的第三方CI工具不够丰富。
Rancher 并没有在产品中集成 CI 方面的能力，在 CD 方面通过集成 fleet 项目来实现 GitOps ，使用的门槛较高。

文章插图
这样的使用体验还有一个优点，从始至终都不需要开发人员去编写格式严苛的 Kubernetes 声明式配置文件。这对开发人员而言无疑是一个极大的利好， Kubernetes 虽好，但学习曲线非常陡峭。Kubernetes 默认通过 yaml 格式的声明式配置文件来部署业务系统，其中绝大多数的字段定义都是运维特征的体现，换句话说，绝大多数的字段定义，都不应该是开发人员关注的事情。
DevOps 工程师应该抓住开发人员使用 Kubernetes 的痛点，避免其接触复杂运维事务。云原生平台理应提供这种使用体验，让开发人员对 Kubernetes 完全无感知的情况下，完成业务系统的部署工作。换句话说，让 Kubernetes 变得对开发人员“透明” 。
【云原生时代的DevOps平台设计之道】从这个方面来说，通过对三款开源云原生平台的体验，发现 Rancher 和 KubeSphere 虽说均可以基于图形化界面来部署自己的业务组件，然而这些图形化配置只是 yaml 声明式配置文件的 “翻译” ，对于 Kubernetes 不够熟悉的用户想要顺利使用，还是有一定的门槛。Rainbond 这一点则做的非常不错，部署业务时完全感受不到 Kubernetes 的存在，对于不熟悉 Kubernetes 的用户而言非常友好。然而产品化定制的程度越高，跟随 Kubernetes 前进的脚步就越难，上游 Kubernetes 不断在推出新的功能特性，如何将新特性抽象成为用户易于理解的功能将会是个挑战。最新版本的 Rainbond 推出了 Kubernetes 属性这一功能特性，允许用户以 yaml 形式编辑 workload ，也是为打破自设的“天花板” 。
降低操作基础设施的难度既然要设计一款平台级的软件产品，那么就需要将复杂且不易被掌握的技术，抽象成为用户易于理解的功能。DevOps 工程师设计的云原生平台产品，首要任务之一，是能够降低开发人员使用基础设施的门槛。这个章节主要讨论的，是开发人员自行管理自己业务系统的运维特征。
就拿存储这件事来说，开发人员到底关注什么呢？
围绕存储这个概念，我们可以说出一堆名词，块设备、文件系统、对象存储、本地磁盘、磁盘阵列、NFS、Ceph等等。这些名词毋庸置疑都与存储相关，也的确会被各种业务系统所使用，但我相信，绝大多数的开发人员对这些名词并不关心。
作为用户，开发人员只关心一件事情，我所负责的业务系统，指定目录中的数据需要被持久化的保存下来。
大多数情况下，业务系统涉及到的存储场景都应该是简单的。在云原生时代，我们甚至呼吁开发人员在开发业务系统的时候，应该尽量做到“无状态化”，即在业务系统中，不存在限制实例横向扩容的状态数据，至少做到不同实例之间，数据可以共享。根据这一点，DevOps 工程师们完全可以为开发人员提供一个能够适应大多数场景的默认存储类型，各个云厂商提供的 NAS 类型存储是个很好的选择。
使用复杂存储的场景更多见于业务系统所调用的各种中间件中，比如数据库需要高速稳定的块设备类型存储，再比如大数据领域的“存算分离”场景下对接对象存储等等。然而在大多数场景下，这些复杂中间件的维护并不是开发人员应该关心的事情。它们由专门的运维人员进行维护，开发人员只需要得到访问它们的地址即可。
所以在这种简单存储场景下，开发人员最好可以仅仅填写一下自己需要被持久化的目录地址，由云原生平台来实现底层存储的配置。对存储基础设施的操作，开发人员并不需要关心。

文章插图
从使用体验上来说，Rancher 和 KubeSphere 可选择的存储类型很多，这是因为它们的产品生态优于 Rainbond，比如 Rancher Lab 直接推出了轻量级的存储解决方案 Longhorn，对于各大公有云厂商提供的存储产品驱动也都有集成。Rainbond 依然在易用性方面做的够好，实现了上文中仅关注业务系统持久化目录的使用体验。然而仅对 NFS 类型的存储支持比较完善，对于其他类型的存储支持，需要在底层基础设施中自建驱动，安装起来不如前二者方便。