云原生时代的DevOps平台设计之道( 六 )


对运维人员友好之前的探讨,都是以开发人员为受众去考量的,但我们不应该忘记维护着底层基础设施正常工作的运维人员 。任何软件的稳定运行都只是暂时的,出问题只是一个时间问题 。云原生平台本身作为开发人员的基础设施,也需要被持续的维护 。如何优化运维人员的管理体验,也是在云原生平台设计过程中的重点 。
当今时代,Kubernetes 的使用与维护、容器化技术都已经成为了运维人员的标志性技能,对操作系统的掌控以及命令行工具的使用则是运维人员的看家本领 。所以云原生平台在面向运维人员的设计中,不必要在易用性或图形化上考虑过多,更多要考虑的是可靠性、安全性、底层基础设施生态的兼容性 。

云原生时代的DevOps平台设计之道

文章插图
Rancher 在运维层面的表现非常出众 。得益于其丰富的周边生态,Rancher 在各个领域都得到了自家其他产品的原生支持 。首当其冲的就是 RKE/RKE2/K3S 这几个 kubernetes 发行版,降低了不同场景下 Kubernetes 的安装难度 。容器安全方面有 NeuVector 容器安全平台负责全生命周期的管理 。基础设施方面有轻量级分布式块设备存储系统 Longhorn 。除了丰富的生态之外,Rancher 产品界面的设计尤其符合运维人员的喜好 。个人体验过程中认为 Kubectl Shell 非常惊艳,这是一个分屏式的命令行操作界面,运维人员可以一边在下半分屏 Shell 交互分页中敲命令,上半分屏中实时观察操作结果 。
KubeSphere 也比较适合运维人员维护和管理 。尤其是在监控报警层面,KubeSphere 制作了大量符合自身产品理念的可观测性图表,体验很不错 。对于集群或节点的控制也做了图形化的设计,便于运维人员掌控 。生态方面,KubeSphere 背靠青云,也在不断发展围绕自身的云原生项目,可以利用自家的驱动对接青云的云平台、云存储,以及负载均衡等基础设施 。其内置的可插拔式的组件管理系统,可以快速扩展出平台级的其他能力 。
Rainbond 对运维人员不太友好,甚至是一种“遗忘”了运维人员的设计理念 。体验之后发现所有的运维操作依然离不开登录服务器这个前提 。没有提供图形化亦或者命令行交互界面来操作集群和节点 。对接多集群时,提供了图形化安装 Kubernetes 集群继而安装 Rainbond 的能力,体验还算不错 。产品生态相较 Rancher 不够丰富,好在官方提供了很多文档支撑,来对接很多其他的云原生生态产品 。比如提供文档对接阿里云ACK、华为云CCE、腾讯云TKE等云基础设施的安装方式 。
在用户权限管理方面,Rancher 、KubeSphere 沿用了 Kubernetes RBAC 这一套体系,Rainbond 依然有些特立独行,权限管理体系并没有完全对照原生 Kubernetes RBAC 设计,甚至在使用 Rainbond 的时候,完全没有感觉到有 RBAC 体系的存在 。对接外部的身份管理系统时,KubeSphere 主推 LDAP 协议,而 Rainbond 使用了 Oauth2.0 协议的实现 。
其他方面,诸如稳定性、行为审计、监控报警方面三款产品各自有实现,没什么太大的区别 。
写在最后相对于招聘文武全才的“全栈式”开发人员搞定所有的 IT 事务,我更倾向于找到不同领域的专家来搞定各自领域的问题 。在运维事务的领域里,构建并维护一套功能齐备的云原生平台,能够更好的解决 IT 业务系统从底层基础设施到开发过程,最终到达生产上线的运维支持问题 。这是对 DevOps 理念比较合理的一种落地方式 。
文中重点提到了 Rancher 、KubeSphere、Rainbond 这三款云原生平台级产品各自不同的实现 。
归纳起来,Rancher 更偏向运维人员使用,来管理企业内部的各类 Kubernetes 基础设施 。开发人员想要很好的使用 Rancher,必须具备 Kubernetes 操作能力以及容器化技术 。从这个角度来说,Rancher 的定位应该位于 PaaS 与云原生平台之间 。

经验总结扩展阅读