小熊科技|如何基于K8s构建下一代DevOps平台？( 二 ) 阿里妹导读：OAM是阿里巴巴与微软联合

挑战一：云资源与 DevOps 平台体验割裂
DevOps流程中充斥着大量需要外部平台创建的过程：
挑战二：研发、运维、基础设施关注点耦合
下图是常用的K8s的YAML配置文件，大家经常吐槽这个配置文件很复杂。简单来说YAML配置文件可以分为三大块，一块是运维比较关心的配置，包括实例数，策略和发布。第二块是研发关心的，涉及到镜像、端口号等。第三块是基础设施工程师看得懂的，如调度策略等。 K8s的配置文件中将方方面面的信息都耦合在一起，这对K8s工程师来说是非常适合的，但是对应用侧的终端工程师而言，有很多不需要关心的配置指标。

DevOps流程中缺乏对“应用”这个概念的描述
K8s 的 YAML文件的定位并不是终端用户

挑战三：平台的自定义封装，简单却能力不足
DevOps平台对K8s能力封装抽象，只剩下5个Deployment的字段需要研发填写。从用户角度而言，这种设置非常好用简单。但是针对稍微复杂的应用，涉及到应用状态管理，健康检查等等一系列的操作，此时这5个字段是不够的。

挑战四：CRD 扩展能力强大， DevOps 平台无法直接复用
CRD(Customize Resource Definition)扩展能力强大，几乎所有软件都可以通过CRD的方式进行扩展，包括数据库、存储、安全、编排、依赖管理、发布等。但是对DevOps平台来说，上面接口并没有向用户暴露，导致无法直接复用。

挑战五：DevOps 平台开发的新能力使用门槛高
如果平台想要扩展一些能力，而原生的自动扩缩容能力不太合适，希望开发定时的扩缩容YAML文件，随着业务情况而设置。但此时用户使用YAML的门槛非常高，不清楚如何使用YAML 。随着新能力开发越来越多，能力之间会出现冲突，这也非常难以管理。

CronHPA

运维同学怎么知道这个扩展能力怎么用？
看 CRD？看配置文件？看 …… 文档？
扩展能力间出现冲突，导致线上故障
比如：CronHPA 和默认 HPA 被同时安装给了同一个应用
K8s 扩展能力之间的冲突关系，如何有效管理？如何有效的对运维透出？

挑战六：不同 DevOps 平台需要完全重新对接
很多云原生实践中会遇到的问题，即需要定义非常复杂的YAML ，这种方式可以解决企业内部所有问题，但是挑战在于很难与生态进行对接。如RDS ， SLB的能力都嵌到YAML文件中，无法复用，几乎不具备原子化能力。同时无法协作，无法提供给兄弟部门或生态使用，只能给内部封闭生态使用。上层系统不同应用对接DevOps平台时，需要写不同格式的YAML ，这也是非常痛苦的。