组件分裂

在 KubeVela 中，我们可以使用 deploy 工作流步骤和 override， topology 策略。但是例如OpenYurt 的项目中，有对集群具有更细粒度划分，例如”节点池”。需要将一些类似的资源下发到同一集群。这些资源称为replication。回到 OpenYurt 的例子，它可以集成 KubeVela，并将分裂出的多个相似 K8s 资源下发到不同的节点池。

为了将一个组件分裂为多个，我们添加了一个内置策略 replication。它只能与 deploy 工作流步骤一起使用。如果在 deploy 工作流步骤中使用 replication 策略，则在渲染组件时将向上下文添加一个新字段 context.replicaKey 。可以向下发一些资源到集群中，他们带有不同的 replicaKey。

组件分裂 - 图1备注

replication 策略仅在 KubeVela 1.6.0+ 版本中支持。

组件分裂 - 图2提示

context.replicaKey 经常在组件定义或运维特征定义中下发资源的 metadata.name 字段中使用，以避免名称冲突。我们将在后面的示例中看到它。

下面的组件定义是一个使用策略的示例 replication。它用 context.replicaKey 给的名称加上后缀。

  1. import (
  2.     "strconv"
  3. )
  5. "replica-webservice": {
  6.     alias: ""
  7.     annotations: {}
  8.     attributes: {
  9.         status: {}
  10.         workload: {
  11.             definition: {
  12.                 apiVersion: "apps/v1"
  13.                 kind:       "Deployment"
  14.             }
  15.             type: "deployments.apps"
  16.         }
  17.     }
  18.     description: "Webservice, but can be replicated"
  19.     labels: {}
  20.     type: "component"
  21. }
  23. template: {
  24.     output: {
  25.         apiVersion: "apps/v1"
  26.         kind:       "Deployment"
  27.         metadata: {
  28.             if context.replicaKey != _|_ {
  29.                 name: context.name + "-" + context.replicaKey
  30.             }
  31.             if context.replicaKey == _|_ {
  32.                 name: context.name
  33.             }
  34.         }
  35.         spec: {
  36.             selector: matchLabels: {
  37.                 "app.oam.dev/component": context.name
  38.                 if context.replicaKey != _|_ {
  39.                     "app.oam.dev/replicaKey": context.replicaKey
  40.                 }
  41.             }
  43.             template: {
  44.                 metadata: {
  45.                     labels: {
  46.                         if parameter.labels != _|_ {
  47.                             parameter.labels
  48.                         }
  49.                         "app.oam.dev/name":      context.appName
  50.                         "app.oam.dev/component": context.name
  51.                         if context.replicaKey != _|_ {
  52.                             "app.oam.dev/replicaKey": context.replicaKey
  53.                         }
  54.                     }
  55.                 }
  57.                 spec: {
  58.                     containers: [{
  59.                         name:  context.name
  60.                         image: parameter.image
  61.                         if parameter["ports"] != _|_ {
  62.                             ports: [ for v in parameter.ports {
  63.                                 {
  64.                                     containerPort: v.port
  65.                                     name:          "port-" + strconv.FormatInt(v.port, 10)
  66.                                 }}]
  67.                         }
  68.                     }]
  69.                 }
  70.             }
  71.         }
  72.     }
  73.     exposePorts: [
  74.         for v in parameter.ports {
  75.             port:       v.port
  76.             targetPort: v.port
  77.             name:       "port-" + strconv.FormatInt(v.port, 10)
  78.         },
  79.     ]
  80.     outputs: {
  81.         if len(exposePorts) != 0 {
  82.             webserviceExpose: {
  83.                 apiVersion: "v1"
  84.                 kind:       "Service"
  85.                 metadata: {
  86.                     if context.replicaKey != _|_ {
  87.                         name: context.name + "-" + context.replicaKey
  88.                     }
  89.                     if context.replicaKey == _|_ {
  90.                         name: context.name
  91.                     }
  92.                 }
  93.                 spec: {
  94.                     selector: {
  95.                         "app.oam.dev/component": context.name
  96.                         if context.replicaKey != _|_ {
  97.                             "app.oam.dev/replicaKey": context.replicaKey
  98.                         }
  99.                     }
  100.                     ports: exposePorts
  101.                 }
  102.             }
  103.         }
  104.     }
  105.     parameter: {
  106.         // +usage=Which image would you like to use for your service
  107.         // +short=i
  108.         image: string
  109.         // +usage=Which ports do you want customer traffic sent to, defaults to 80
  110.         ports?: [...{
  111.             // +usage=Number of port to expose on the pod's IP address
  112.             port: int
  113.         }]
  114.     }
  115. }

将定义复制到文件 replica-webservice.cue 并应用定义：

  1. vela def apply replica-webservice.cue

然后，用户可以创建下面的应用程序。replication 策略是在其中的 application.spec.policies 字段声明。并在 deploy 步骤中使用它来影响其结果。

  1. apiVersion: core.oam.dev/v1beta1
  2. kind: Application
  3. metadata:
  4.   name: app-replication-policy
  5. spec:
  6.   components:
  7.     - name: hello-rep
  8.       type: replica-webservice
  9.       properties:
  10.         image: crccheck/hello-world
  11.         ports:
  12.           - port: 80
  13.             expose: true
  14.   policies:
  15.     - name: replication-default
  16.       type: replication
  17.       properties:
  18.         keys: [ "beijing","hangzhou" ]
  19.         selector: [ "hello-rep" ]
  21.   workflow:
  22.     steps:
  23.       - name: deploy-with-rep
  24.         type: deploy
  25.         properties:
  26.           policies: [ "replication-default" ]

然后，应用程序将下发两个 Deployment 和两个 Service：

  1. vela status app-replication-policy --detail --tree
  1. CLUSTER    NAMESPACE  RESOURCE                      STATUS    APPLY_TIME          DETAIL
  2. local  ─── default─┬─ Service/hello-rep-beijing     updated   2022-11-03 11:26:03 Type: ClusterIP  Cluster-IP: 10.43.26.211  External-IP: <none>
  3.                    │                                                              Port(s): 80/TCP  Age: 3h10m
  4.                    ├─ Service/hello-rep-hangzhou    updated   2022-11-03 11:26:03 Type: ClusterIP  Cluster-IP: 10.43.36.44  External-IP: <none>
  5.                    │                                                              Port(s): 80/TCP  Age: 3h10m
  6.                    ├─ Deployment/hello-rep-beijing  updated   2022-11-03 11:26:03 Ready: 1/1  Up-to-date: 1  Available: 1  Age: 3h10m
  7.                    └─ Deployment/hello-rep-hangzhou updated   2022-11-03 11:26:03 Ready: 1/1  Up-to-date: 1  Available: 1  Age: 3h10m

在步骤中可以使用三种策略 deploy： topology、 override 和 replication。它们可以一起用于分裂组件和将组件下发到不同的集群。下面是它们一起使用时的规则：

  1. 策略的应用顺序为 topology -> override -> replication 。更多详细信息，可以参阅多集群应用
    • topology 选择要下发集群。如果不使用，则默认情况下应用程序将资源部署到 Local 群集。
    • override 修改组件 Properties。如果不使用，则不会更改任何属性。
    • replication 将一个组件分裂为多个组分裂

组件分裂 - 图3备注

默认情况下，KubeVela 所在的控制集群被注册为本地集群。你可以像使用管控集群一样使用它，但是你无法 detach 或 modify 这个集群。

  1. override 并且 replication 可以一起使用。但 override 会影响所有分裂的组件。override 的主要用意是修改不同群集中的同一个组件的属性。

Last updated on 2023年8月4日 by Daniel Higuero