资源关联规则

    总体上这些资源关联规则主要会在以下场景中被用到：

    • 在 VelaUX 的资源拓扑视图中用来展示资源之间的拓扑关系。下面就是一个资源拓扑图的例子：

    • 通过 cli 使用 vela port-forward, vela logs, vela exec 以及 vela status --endpoint 或者在 VelaUX 上查看应用下实例的日志或访问端口等功能时，用来发现应用下面的 pod 或 service。

    系统所内置的资源关联规则是有限的，如果系统中添加了新的自定义资源（Kubernetes CustomResource），你可以创建一个 Kubernetes configmap 来为这个类型资源添加关系规则。

    接下来我们通过一个实际的例子来讲解资源关联规则的作用。

    你可以先通过下面的命令，启用一个尚在实验阶段的插件 。

    插件启用成功之后，我们就可以看到一个 cloneset 的 componentDefinition，而这个 Definition 创建出来的工作负载是一个 clonesets.apps.kruise.io，最终这个 clonset 会创建出来具体的 pod。

    1. $ vela componets
    2. NAME                    DEFINITION                      DESCRIPTION                                                 
    3. cloneset                autodetects.core.oam.dev        Describes long-running, scalable, containerized services    
    4.                                                         that have a stable network endpoint to receive external     
    5.                                                         network traffic from customers. If workload type is skipped 
    6.                                                         for any service defined in Appfile, it will be defaulted to 
    7.                                                         `webservice` type.

    接下来，创建一个 cloneset 的应用如下所示：

    1. cat <<EOF | vela up -f -
    2. apiVersion: core.oam.dev/v1beta1
    3. kind: Application
    4. metadata:
    5.   name: app-cloneset
    6. spec:
    7.   components:
    8.     - name: clone-set
    9.       type: cloneset
    10.       properties:
    11.         cmd:
    12.           - ./podinfo
    13.         image: stefanprodan/podinfo:4.0.3
    15.         updateStrategyType: InPlaceOnly
    16. EOF

    image

    同时，如果我们通过 vela logs 和 vela exec 时同样会遇到无法找到实例的问题。如下所示：

    1. $ vela exec app-cloneset
    2. Error: no pod found in your application

    其实以上问题的原因都是由于系统添加了一个 cloneset 的自定义资源之后，并没有与之相关的资源关联规则来定义它下面可能有那些类型的子资源。进而在展示资源拓扑图时 KubeVela 不知道该去查找哪些资源类型，也无法找到相应的实例。如果我们通过 kubectl 的命令查看由这个 cloneset 创建 pod 的详细信息会看到这样的结果：

    1. apiVersion: v1
    2. kind: Pod
    3. metadata:
    4. #...
    5.   name: clone-set-vsrj9
    6.   namespace: default
    7.   ownerReferences:
    8.   - apiVersion: apps.kruise.io/v1alpha1
    9.     blockOwnerDeletion: true
    10.     controller: true
    11.     kind: CloneSet
    12.     name: clone-set
    13.     uid: 817f55d2-a0d8-4efd-be0d-0021e1710dea
    14. spec:
    15. #...

    可见，该 pod 的 OwnerReference 就是应用所创建出来的 cloneset。接下来我们为系统添加定义了一个资源关联规则的 configmap 如下所示：

    我们看到，首先这个 configmap 包含了一个特殊的标签 "rules.oam.dev/resources": "true"。只有包含一个这样标签的 configmap 才会被 KubeVela 识别为是一个关于资源关联规则的定义。同时在这个例子中我们还通过一个 "rules.oam.dev/resource-format": "yaml" 注解定义了下面 data.rules 字段所定义的具体规则是通过 YAML 的格式定义的，除了使用 YAML 格式，你还可以使用 JSON 格式来定义这些规则，如下所示：

    1. apiVersion: v1
    2. kind: ConfigMap
    3.   name: clone-set-relation
    4.   namespace: vela-system
    5.   labels:
    6.     "rules.oam.dev/resource-format": "json"
    7.     "rules.oam.dev/resources": "true"
    8. data:
    9.   rules: |-
    10.    [
    11.      {
    12.        "parentResourceType": {
    13.            "group": "apps.kruise.io",
    14.            "kind": "CloneSet"
    15.        },
    16.        "childrenResourceType": [
    17.            {
    18.                "apiVersion": "v1",
    19.                "kind": "Pod"
    20.            }
    21.        ]
    22.      }
    23.   ]

    上面两个 configmap 作用完全等价。

    这个 configmap 创建成功之后，再次查看资源拓扑视图和实例列表如下所示：

    image

    我们再次使用 vela logs 和 vela exec 等命令时就不会再遇到的错误，如下所示：

    1. $ vela logs app-cloneset
    2. + clone-set-vsrj9 › clone-set

    同样的，如果你的某个自定义资源会创建 Kubernetes service ，你也可以为系统添加一个资源关联规则，从而支持查找应用的访问端点的功能： vela status --endpoints。

    集成在插件当中

    经过上面的介绍相信你应该已经想到，如果一个 KubeVela 中安装了某种自定义资源，你就可以通过在插件中添加一个这样的 configmap 来建立这个它与其他资源的关联规则。 具体方法是在插件的应用模版文件中的 定义一个资源关联规则的 configmap。例如：

    具体请参考文档 。