Component Orchestration

This section will introduce the dependencies in components and how to pass data between components.

Component Orchestration - 图1tip

We use helm component type in the following examples, make sure you have the fluxcd addon enabled (vela addon enable fluxcd).

We can use dependsOn to specify the dependencies between components.

For example, component A depends on component B:

  1. ...
  2. components:
  3. - name: A
  4. type: helm
  5. dependsOn:
  6. - B
  7. - name: B
  8. type: helm

In this case, KubeVela will deploy B first, and then deploy A when the component B is running.

If we want to apply a MySQL cluster, we need:

  1. Apply a secret for MySQL password.
  2. Apply MySQL controller.
  3. Apply MySQL cluster.

Apply the following file:

  1. apiVersion: core.oam.dev/v1beta1
  2. kind: Application
  3. metadata:
  4. name: mysql
  5. namespace: default
  6. spec:
  7. components:
  8. - name: mysql-secret
  9. type: raw
  10. properties:
  11. apiVersion: v1
  12. kind: Secret
  13. metadata:
  14. name: mysql-secret
  15. type: kubernetes.io/opaque
  16. stringData:
  17. ROOT_PASSWORD: test
  18. - name: mysql-controller
  19. type: helm
  20. properties:
  21. repoType: helm
  22. url: https://presslabs.github.io/charts
  23. chart: mysql-operator
  24. version: "0.4.0"
  25. - name: mysql-cluster
  26. type: raw
  27. dependsOn:
  28. - mysql-controller
  29. - mysql-secret
  30. properties:
  31. apiVersion: mysql.presslabs.org/v1alpha1
  32. kind: MysqlCluster
  33. metadata:
  34. name: mysql-cluster
  35. spec:
  36. replicas: 1
  37. secretName: mysql-secret

Check the application in the cluster:

  1. $ vela ls
  2. APP COMPONENT TYPE TRAITS PHASE HEALTHY STATUS CREATED-TIME
  3. mysql mysql-secret raw runningWorkflow 2021-10-14 12:09:55 +0800 CST
  4. ├─ mysql-controller helm runningWorkflow 2021-10-14 12:09:55 +0800 CST
  5. └─ mysql-cluster raw runningWorkflow 2021-10-14 12:09:55 +0800 CST

In the beginning, the status is running workflow since the mysql-controller is not ready.

  1. $ vela ls
  2. APP COMPONENT TYPE TRAITS PHASE HEALTHY STATUS CREATED-TIME
  3. mysql mysql-secret raw running healthy 2021-10-14 12:09:55 +0800 CST
  4. ├─ mysql-controller helm running healthy 2021-10-14 12:09:55 +0800 CST
  5. └─ mysql-cluster raw running 2021-10-14 12:09:55 +0800 CST

After a while, all components is running successfully. The mysql-cluster will be deployed after mysql-controller and mysql-secret is healthy.

Component Orchestration - 图2info

dependsOn use healthy to check status. If the component is healthy, then KubeVela will deploy the next component. If you want to customize the healthy status of the component, please refer to Status Write Back

In KubeVela, we can use inputs and outputs in Components to pass data.

Outputs is made of name and valueFrom. Input will use name to reference output.

We can write valueFrom in the following ways:

  1. Use value expression, eg. valueFrom: output.metadata.name. Note that output is a built-in field referring to the resource in the component that is rendered and deployed to the cluster.
  2. Use CUE expressions, eg. use + to combine value and string: valueFrom: output.metadata.name + "testString" or you can import built-in packages in CUE like:
  1. valueFrom: |
  2. import "strings"
  3. strings.Join(["1","2"], ",")

Inputs is made of from and parameterKey. Input uses from to reference output, parameterKey is a expression that assigns the value of the input to the corresponding field.

eg.

  1. Specify inputs:
  1. ...
  2. - name: wordpress
  3. type: helm
  4. inputs:
  5. - from: mysql-svc
  6. parameterKey: properties.values.externalDatabase.host
  1. The field parameterKey specifies the field path of the parameter key in component to be assigned after rendering:

Which means the input value will be passed into the below properties:

  1. ...
  2. - name: wordpress
  3. type: helm
  4. properties:
  5. values:
  6. externalDatabase:
  7. host: <input value>

In the following we will apply a WordPress server with the MySQL address passed from a MySQL component:

  1. apiVersion: core.oam.dev/v1beta1
  2. kind: Application
  3. metadata:
  4. name: wordpress-with-mysql
  5. namespace: default
  6. spec:
  7. components:
  8. - name: mysql
  9. type: helm
  10. outputs:
  11. # the output is the mysql service address
  12. - name: mysql-svc
  13. valueFrom: output.metadata.name + ".default.svc.cluster.local"
  14. properties:
  15. repoType: helm
  16. url: https://charts.bitnami.com/bitnami
  17. chart: mysql
  18. version: "8.8.2"
  19. values:
  20. auth:
  21. rootPassword: mypassword
  22. - name: wordpress
  23. type: helm
  24. inputs:
  25. # set the host to mysql service address
  26. - from: mysql-svc
  27. parameterKey: properties.values.externalDatabase.host
  28. properties:
  29. repoType: helm
  30. url: https://charts.bitnami.com/bitnami
  31. chart: wordpress
  32. version: "12.0.3"
  33. values:
  34. mariadb:
  35. enabled: false
  36. externalDatabase:
  37. user: root
  38. password: mypassword
  39. database: mysql
  40. port: 3306

Check the application in the cluster:

  1. $ vela ls
  2. APP COMPONENT TYPE TRAITS PHASE HEALTHY STATUS CREATED-TIME
  3. wordpress-with-mysql mysql helm running healthy 2021-10-12 18:04:10 +0800 CST
  4. └─ wordpress helm running healthy 2021-10-12 18:04:10 +0800 CST

The WordPress with MySQL has been successfully applied.

In multi-cluster scenario, we can still make use of Dependency and Inputs/Outputs to orchestrate the components. The usage is the same as in the single-cluster scenario. Here’s a direct example. Here is a Inputs/Outpus example and Dependency is also available.

Component Orchestration - 图3note

The environment in example have one managed cluster named cluster-worker.

Deploy the following application, which will dispatch a Deployment and a Service. Then deploy a ConfigMap with some status information.

  1. apiVersion: core.oam.dev/v1beta1
  2. kind: Application
  3. metadata:
  4. name: cm-with-message
  5. spec:
  6. components:
  7. - name: podinfo
  8. outputs:
  9. - name: message
  10. valueFrom: output.status.conditions[0].message
  11. - name: ip
  12. valueFrom: outputs.service.spec.clusterIP
  13. properties:
  14. image: stefanprodan/podinfo:4.0.3
  15. type: webservice
  16. traits:
  17. - type: expose
  18. properties:
  19. port: [ 80 ]
  20. - name: configmap
  21. properties:
  22. apiVersion: v1
  23. kind: ConfigMap
  24. metadata:
  25. name: deployment-msg
  26. type: raw
  27. inputs:
  28. - from: message
  29. parameterKey: data.msg
  30. - from: ip
  31. parameterKey: data.ip
  32. policies:
  33. - name: topo
  34. properties:
  35. clusters: [ "local","cluster-worker" ]
  36. type: topology
  37. - name: override
  38. properties:
  39. selector:
  40. - configmap
  41. - podinfo
  42. type: override
  1. $ vela status cm-with-message --tree
  2. CLUSTER NAMESPACE RESOURCE STATUS
  3. cluster-worker─── default ─┬─ ConfigMap/deployment-msg updated
  4. ├─ Service/podinfo updated
  5. └─ Deployment/podinfo updated
  6. local ─── default ─┬─ ConfigMap/deployment-msg updated
  7. ├─ Service/podinfo updated
  8. └─ Deployment/podinfo updated

Check the ConfigMap in the cluster. The same to the other cluster.

  1. $ kubectl get cm deployment-msg -oyaml |grep -C3 ^data
  2. apiVersion: v1
  3. data:
  4. ip: 10.43.223.14
  5. msg: Deployment has minimum availability.
  6. kind: ConfigMap

Last updated on Feb 9, 2023 by dependabot[bot]