Application

    This documentation will walk through how to use KubeVela to design a simple application without any polices or placement rule defined.

    Components are deployable or provisionable entities that compose your application. It could be a Helm chart, a simple Kubernetes workload, a CUE or Terraform module, or a cloud database etc.

    Let’s check the available components in fresh new KubeVela.

    To show the specification for given component, you could use vela show.

    1. $ kubectl vela show webservice
    2. # Properties
    3. +------------------+----------------------------------------------------------------------------------+-----------------------+----------+---------+
    4. |       NAME       |                                   DESCRIPTION                                    |         TYPE          | REQUIRED | DEFAULT |
    5. +------------------+----------------------------------------------------------------------------------+-----------------------+----------+---------+
    6. | cmd              | Commands to run in the container                                                 | []string              | false    |         |
    7. | env              | Define arguments by using environment variables                                  | [[]env](#env)         | false    |         |
    8. | addRevisionLabel |                                                                                  | bool                  | true     | false   |
    9. | image            | Which image would you like to use for your service                               | string                | true     |         |
    10. | port             | Which port do you want customer traffic sent to                                  | int                   | true     |      80 |
    11. | cpu              | Number of CPU units for the service, like `0.5` (0.5 CPU core), `1` (1 CPU core) | string                | false    |         |
    12. | volumes          | Declare volumes and volumeMounts                                                 | [[]volumes](#volumes) | false    |         |
    13. +------------------+----------------------------------------------------------------------------------+-----------------------+----------+---------+
    14. ... // skip other fields

    You could always add more components to the platform at any time.

    Application is the full description of a deployment. Let’s define an application that deploys a Web Service and a Worker components.

    1. # sample.yaml
    2. apiVersion: core.oam.dev/v1beta1
    3. kind: Application
    4. metadata:
    5.   name: website
    6. spec:
    7.   components:
    8.     - name: frontend
    9.       type: webservice
    10.       properties:
    11.         image: nginx
    12.     - name: backend
    13.       type: worker
    14.       properties:
    15.         image: busybox
    16.         cmd:
    17.           - sleep
    18.           - '1000'

    Traits are platform provided features that could overlay a given component with extra operational behaviors.

    Let’s check the specification of sidecar trait.

    1. $ kubectl vela show sidecar
    2. # Properties
    3. +---------+-----------------------------------------+----------+----------+---------+
    4. |  NAME   |               DESCRIPTION               |   TYPE   | REQUIRED | DEFAULT |
    5. | name    | Specify the name of sidecar container   | string   | true     |         |
    6. | image   | Specify the image of sidecar container  | string   | true     |         |
    7. | command | Specify the commands run in the sidecar | []string | false    |         |

    Note that traits are designed to be overlays.

    Similarly, the system will assign a HPA instance based on the properties you set and “link” it to the target workload instance, the component itself is untouched.

    Now let’s attach sidecar and cpuscaler traits to the frontend component.

    1. # sample.yaml
    2. apiVersion: core.oam.dev/v1beta1
    3. kind: Application
    4. metadata:
    5.   name: website
    6. spec:
    7.   components:
    8.     - name: frontend              # This is the component I want to deploy
    9.       type: webservice
    10.       properties:
    11.         image: nginx
    12.       traits:
    13.         - type: cpuscaler         # Automatically scale the component by CPU usage after deployed
    14.           properties:
    15.             min: 1
    16.             max: 10
    17.             cpuPercent: 60
    18.         - type: sidecar           # Inject a fluentd sidecar before applying the component to runtime cluster
    19.           properties:
    20.             name: "sidecar-test"
    21.             image: "fluentd"
    22.     - name: backend
    23.       type: worker
    24.       properties:
    25.         image: busybox
    26.         cmd:
    27.           - sleep
    28.           - '1000'

    You’ll get the application becomes running.

    1. $ kubectl get application
    2. NAME        COMPONENT   TYPE         PHASE     HEALTHY   STATUS   AGE
    3. website     frontend    webservice   running   true               4m54s

    Check the details of the application.

    1. $ kubectl get app website -o yaml
    2. apiVersion: core.oam.dev/v1beta1
    3. kind: Application
    4. metadata:
    5.   generation: 1
    6.   name: website
    7. spec:
    8.   components:
    9.   - name: frontend
    10.     properties:
    11.       image: nginx
    12.     traits:
    13.     - properties:
    14.         cpuPercent: 60
    15.         max: 10
    16.         min: 1
    17.       type: cpuscaler
    18.     - properties:
    19.         image: fluentd
    20.         name: sidecar-test
    21.       type: sidecar
    22.     type: webservice
    23.   - name: backend
    24.     properties:
    25.       cmd:
    26.       - sleep
    27.       - "1000"
    28.       image: busybox
    29.     type: worker
    30. status:
    31.   ...
    32.   latestRevision:
    33.     name: website-v1
    34.     revision: 1
    35.     revisionHash: e9e062e2cddfe5fb
    36.   services:
    37.   - healthy: true
    38.     name: frontend
    39.     traits:
    40.     - healthy: true
    41.       type: cpuscaler
    42.     - healthy: true
    43.       type: sidecar
    44.   - healthy: true
    45.     name: backend
    46.   status: running

    Specifically:

    1. status.latestRevision declares current revision of this deployment.
    2. status.status declares the global state of this deployment.

    Furthermore, the system will decide how to/whether to rollout the application based on the attached .