关于内置资源和自定义组件的最佳实践讨论 #5931
Replies: 1 comment
-
分离的好处是像 labels, annotations 这类 trait 可以很方便的给各种类型的 component 使用。像 env,cmd 这样的,对于类 deployment 的 component 类型也会比较通用。简化抽象的复杂性(O(N_{componenttype}N_{traittype}) -> O(N_{componenttype}+N_{traittype}))。但是实际使用的时候,对于高频使用的 webservice,为了简化用户的配置复杂性(总是需要配置 trait),我们也提供了一些 field 直接给 component properties 使用。总的来说分离的做法更优雅一些,如果是为了方便用户使用,将高频使用的 trait 能力合进 component type 也是可以的。 |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
最近在封装OpenKruise这个应用时在对一些公共字段定义的一些困惑,还要从KubeVela的内置资源定义说起。
以内置组件
Webservice
为例,他内置了:labels
、annotations
、cmd
、env
... 这些常见的内置资源定义。但是,在内置运维特征列表 也内置了:
Labels
、Annotations
、Cmd
、Env
...从上述的资源定义和使用的产生效果来说:
Webservice
定义的资源和内置运维特征列表有很多资源时重复的,例如我定义一个Webservice我想要添加annotations
,那么这个annotations
可以定义在Webservice
里边也可以定义在trait
里边。那么用户在使用的时候难免会困惑,所有想跟大家探讨几个问题:
1、应该优先以哪个为准,社区建议的最佳实践是什么?
2、我在编写一些自定义组件是不是就定义该组件
特有
部分就行了,已经存在了的像:Labels
、Annotations
、Cmd
、Env
这些资源定义我是否可以不用定义,而直接使用这些内置运维特征就行了,例如以:openkruise
的CloneSet
为例:下面是CloneSet 原始资源定义的yaml:
接下来我需要完成对CloneSet 的组件定义
在
CloneSet
组件定义中一些常见的labels
、annotations
、cmd
等我就直接复用内置运维特征列表的资源定义,而不用单独再去一定一次。所以如下CloneSet的定义我不添加任何资源描述参数:
对于特有
CloneSet
的updateStrategy
的资源定义我在单独定义一份traits
组件,这用通过组合的方式实现整体CloneSet
的定义。最后组合的Application效果:
Beta Was this translation helpful? Give feedback.
All reactions