Component Orchestration

Component Orchestration

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

tip

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:

...
components:
  - name: A
    type: helm
    dependsOn:
      - B
  - name: B
    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:

Apply a secret for MySQL password.
Apply MySQL controller.
Apply MySQL cluster.

Apply the following file:

apiVersion: core.oam.dev/v1beta1
kind: Application
metadata:
  name: mysql
  namespace: default
spec:
  components:
    - name: mysql-secret
      type: raw
      properties:
        apiVersion: v1
        kind: Secret
        metadata:
          name: mysql-secret
        type: kubernetes.io/opaque
        stringData:
          ROOT_PASSWORD: test
    - name: mysql-controller
      type: helm
      properties:
        repoType: helm
        url: https://presslabs.github.io/charts
        chart: mysql-operator
        version: "0.4.0"
    - name: mysql-cluster
      type: raw
      dependsOn:
        - mysql-controller
        - mysql-secret
      properties:
        apiVersion: mysql.presslabs.org/v1alpha1
        kind: MysqlCluster
        metadata:
          name: mysql-cluster
        spec:
          replicas: 1
          secretName: mysql-secret

Check the application in the cluster:

$ vela ls
APP     COMPONENT           TYPE    TRAITS  PHASE           HEALTHY STATUS  CREATED-TIME
mysql   mysql-secret        raw             runningWorkflow                 2021-10-14 12:09:55 +0800 CST
├─  mysql-controller    helm            runningWorkflow                 2021-10-14 12:09:55 +0800 CST
└─  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.

$ vela ls
APP     COMPONENT           TYPE    TRAITS  PHASE   HEALTHY STATUS  CREATED-TIME
mysql   mysql-secret        raw             running healthy         2021-10-14 12:09:55 +0800 CST
├─  mysql-controller    helm            running healthy         2021-10-14 12:09:55 +0800 CST
└─  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.

info

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:

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.
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:

valueFrom: |
          import "strings"
          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.

Specify inputs:

...
- name: wordpress
  type: helm
  inputs:
    - from: mysql-svc
      parameterKey: properties.values.externalDatabase.host

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:

...
- name: wordpress
  type: helm
  properties:
    values:
      externalDatabase:
        host: <input value>

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

apiVersion: core.oam.dev/v1beta1
kind: Application
metadata:
  name: wordpress-with-mysql
  namespace: default
spec:
  components:
    - name: mysql
      type: helm
      outputs:
        # the output is the mysql service address
        - name: mysql-svc
          valueFrom: output.metadata.name + ".default.svc.cluster.local"
      properties:
        repoType: helm
        url: https://charts.bitnami.com/bitnami
        chart: mysql
        version: "8.8.2"
        values:
          auth:
            rootPassword: mypassword
    - name: wordpress
      type: helm
      inputs:
        # set the host to mysql service address
        - from: mysql-svc
          parameterKey: properties.values.externalDatabase.host
      properties:
        repoType: helm
        url: https://charts.bitnami.com/bitnami
        chart: wordpress
        version: "12.0.3"
        values:
          mariadb:
            enabled: false
          externalDatabase:
            user: root
            password: mypassword
            database: mysql
            port: 3306

Check the application in the cluster:

$ vela ls
APP                     COMPONENT   TYPE    TRAITS  PHASE           HEALTHY STATUS  CREATED-TIME
wordpress-with-mysql    mysql       helm    running                 healthy         2021-10-12 18:04:10 +0800 CST
└─                      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.

note

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.

apiVersion: core.oam.dev/v1beta1
kind: Application
metadata:
  name: cm-with-message
spec:
  components:
    - name: podinfo
      outputs:
        - name: message
          valueFrom: output.status.conditions[0].message
        - name: ip
          valueFrom: outputs.service.spec.clusterIP
      properties:
        image: stefanprodan/podinfo:4.0.3
      type: webservice
      traits:
        - type: expose
          properties:
            port: [ 80 ]
    - name: configmap
      properties:
        apiVersion: v1
        kind: ConfigMap
        metadata:
          name: deployment-msg
      type: raw
      inputs:
        - from: message
          parameterKey: data.msg
        - from: ip
          parameterKey: data.ip
  policies:
    - name: topo
      properties:
        clusters: [ "local","cluster-worker" ]
      type: topology
    - name: override
      properties:
        selector:
          - configmap
          - podinfo
      type: override

$ vela status cm-with-message --tree                  
CLUSTER            NAMESPACE     RESOURCE                 STATUS    
cluster-worker─── default    ─┬─ ConfigMap/deployment-msg updated   
                              ├─ Service/podinfo          updated   
                              └─ Deployment/podinfo       updated   
local       ─── default      ─┬─ ConfigMap/deployment-msg updated   
                              ├─ Service/podinfo          updated   
                              └─ Deployment/podinfo       updated

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

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

Last updated on Aug 4, 2023 by Daniel Higuero