Alternative Commands

Besides Appfile, KubeVela also provides a set of alternatives commands to deploy the application. Think about “shortcuts” that could generate and apply Appfile without the need to write YAML file manually.

NOTE: These shortcuts are based on Appfile and designed for quick demo purpose only, we would recommend using Appfile instead for serious usage of KubeVela.

vela init

A shortcut to initialize and deploy an application with one service, run:

If you only want to initialize the Appfile only (i.e. dry run), add --render-only flag

  1. $ vela init
  2. Welcome to use KubeVela CLI! We're going to help you run applications through a couple of questions.
  4. Environment: default, namespace: default
  6. ? What is the domain of your application service (optional):  example.com
  7. ? What is your email (optional, used to generate certification):
  8. ? What would you like to name your application (required):  testapp
  9. ? Choose the workload type for your application (required, e.g., webservice):  webservice
  10. ? What would you like to name this webservice (required):  testsvc
  11. ? Which image would you like to use for your service (required): crccheck/hello-world
  12. ? Which port do you want customer traffic sent to (optional, default is 80): 8000
  14. ...
  15. ✅ Application Deployed Successfully!
  16.   - Name: testsvc
  17.     Type: webservice
  18.     HEALTHY Ready: 1/1
  19.     Routes:
  21.     Last Deployment:
  22.       Created at: ...
  23.       Updated at: ...

Check the application:

  1. $ vela show testapp
  2. About:
  4.   Name:          testapp
  5.   Created at:    ...
  6.   Updated at:    ...
  9. Environment:
  11.   Namespace:    default
  13. Services:
  15.   - Name:            testsvc
  16.     WorkloadType:    webservice
  17.     Arguments:
  18.       image:            crccheck/hello-world
  19.       port:             8000
  20.       Traits:

vela svc deploy

A shortcut to initialize and deploy service one by one.

Firstly, check the available workload types.

  1. $ vela workloads
  2. NAME          DESCRIPTION
  3. worker       Backend worker without ports exposed
  4. webservice    Long running service with network routes

Deploy the first service named frontend with Web Service type:

  1. $ vela svc deploy frontend --app testapp -t webservice --image crccheck/hello-world
  2. App testapp deployed

Deploy the second service named backend with “Backend Worker” type:

  1. $ vela svc deploy backend --app testapp2 -t worker --image crccheck/hello-world
  2. App testapp2 deployed
  1. $ vela ls
  2. SERVICE     APP         TYPE    TRAITS    STATUS     CREATED-TIME
  3. frontend    testapp                       ...
  4. backend     testapp                       ...

vela route

A shortcut to add route config.

  1. $ vela route testapp --domain frontend.mycustom.domain
  2. Adding route for app frontend
  4. Rendering configs for service (frontend)...
  5. ⠋ Deploying ...
  6. ✅ Application Deployed Successfully!
  7. Showing status of service(type: webservice) frontend deployed in Environment myenv
  8. Service frontend Status:   HEALTHY Ready: 1/1
  9.   route:  Visiting URL: http://frontend.mycustom.domain IP: 123.57.10.233
  11. Last Deployment:
  12.   Created at: 2020-10-29 15:45:13 +0800 CST
  13.   Updated at: 2020-10-29T16:12:45+08:00

Then you will be able to visit by:

  1. $ curl -H "Host:frontend.mycustom.domain" 123.57.10.233

If you have domain set in deployment environment

  1. $ vela route testapp
  2. Adding route for app frontend
  4. Rendering configs for service (frontend)...
  5. ⠋ Deploying ...
  6. ✅ Application Deployed Successfully!
  7. Showing status of service(type: webservice) frontend deployed in Environment default
  8. Service frontend Status:   HEALTHY Ready: 1/1
  9.   route:  Visiting URL: https://frontend.123.57.10.233.xip.io IP: 123.57.10.233
  11. Last Deployment:
  12.   Created at: 2020-10-29 11:26:46 +0800 CST
  13.   Updated at: 2020-10-29T11:28:01+08:00

vela autoscale

A shortcut to autoscale the service. Currently, Cli only supports setting CPU resource utilization auto-scaling policy. To configure cron auto-scaling policy, please refer to autoscale in Appfile.

  • Deploy an application

    Run the following command to deploy application helloworld.

    1. $ vela svc deploy frontend -t webservice -a helloworld --image nginx:1.9.2 --port 80 --cpu=0.05
    2. App helloworld deployed

    By default, the replicas of the workload webservice helloworld is one.

  • Scale the application by CPU utilization metrics

    1. $ vela autoscale helloworld --svc frontend --min 1 --max 5 --cpu-percent 5
    2. Adding autoscale for app frontend
    3. ⠋ Checking Status ...
    4. ✅ Application Deployed Successfully!
    5.   - Name: frontend
    6.     Type: webservice
    7.     HEALTHY Ready: 1/1
    8.     Traits:
    9.       - ✅ autoscale: type: cpu     cpu-utilization(target/current): 5%/0%    replicas(min/max/current): 1/5/0
    10.     Last Deployment:
    11.       Created at: 2020-11-06 16:10:54 +0800 CST
    12.       Updated at: 2020-11-06T16:19:04+08:0

  • Monitor the replicas changing when the application becomes overloaded

    Continue to monitor the replicas changing when the application becoming overloaded. You can use Apache HTTP server benchmarking tool ab to mock many requests to the application as we did in Autoscalig in Appfile.

    With more and more requests to the application, the replicas gradually increase from one to four.

vela metrics

A shortcut to add metrics config.

If your application has exposed metrics, you can easily setup monitoring system with the help of metrics capability.

Let’s run christianhxc/gorandom:1.0 as an example app. The app will emit random latencies as metrics.

  1. $ vela svc deploy metricapp -t webservice --image christianhxc/gorandom:1.0 --port 8080

Then add metrics by:

  1. $ vela metrics metricapp
  2. Adding metrics for app metricapp
  3. ⠋ Deploying ...
  4. ✅ Application Deployed Successfully!
  5.   - Name: metricapp
  6.     Type: webservice
  7.     HEALTHY Ready: 1/1
  8.     Routes:
  9.       - ✅ metrics: Monitoring port: 8080, path: /metrics, format: prometheus, schema: http.
  10.     Last Deployment:
  11.       Created at: 2020-11-02 14:31:56 +0800 CST
  12.       Updated at: 2020-11-02T14:32:00+08:00

The metrics trait will automatically discover port and label to monitor if no parameters specified. If more than one ports found, it will choose the first one by default.

Verify that the metrics are collected on prometheus

  1. $ kubectl --namespace monitoring port-forward `k -n monitoring get pods -l prometheus=oam -o name` 9090

Then access the prometheus dashboard via http://localhost:9090/targets

vela rollout

A shortcut to add rollout config.

Firstly, deploy your app by:

  1. $ vela svc deploy testapp -t webservice --image oamdev/testapp:v1 --port 8080
  2. App testapp deployed

Add route for visit:

  1. $ vela route testapp --domain myhost.com
  2. Adding route for app testapp
  3. ⠋ Checking Status ...
  4. ✅ Application Deployed Successfully!
  5.   - Name: testapp
  6.     Type: webservice
  7.     HEALTHY Ready: 1/1
  8.     Traits:
  9.       - ✅ route:  Visiting URL: http://myhost.com IP: <your-ingress-IP-address>
  11.     Last Deployment:
  12.       Created at: 2020-11-09 12:50:30 +0800 CST
  13.       Updated at: 2020-11-09T12:51:19+08:00
  1. $ curl -H "Host:myhost.com" http://<your-ingress-IP-address>/
  2. Hello World%

Secondly, add rollout policy for your app:

  1. $ vela rollout testapp --replicas 5 --step-weight 20 --interval 5s

Then update your app by:

  1. $ vela svc deploy testapp -t webservice --image oamdev/testapp:v2 --port 8080

Then it will rolling update your instance, you could try curl your app multiple times:

  1. $ curl -H "Host:myhost.com" http://39.97.232.19/
  2. Hello World  -- Updated Version Two!%                                         
  3. $ curl -H "Host:myhost.com" http://39.97.232.19/
  4. Hello World%                                                                  
  5. $ curl -H "Host:myhost.com" http://39.97.232.19/
  6. Hello World%                                                                  
  7. $ curl -H "Host:myhost.com" http://39.97.232.19/
  8. Hello World  -- Updated Version Two!%                                         
  9. $ curl -H "Host:myhost.com" http://39.97.232.19/
  10. Hello World%                                                                  
  11. $ curl -H "Host:myhost.com" http://39.97.232.19/
  12. Hello World  -- Updated Version Two!%

It will return both version of output info as both instances are all existing.

Under the hood, it was flagger canary running.

  1. $ kubectl get canaries.flagger.app testapp-trait-76fc76fddc -w
  2. NAME                       STATUS        WEIGHT   LASTTRANSITIONTIME
  3. testapp-trait-76fc76fddc   Progressing   0        2020-11-10T09:06:10Z
  4. testapp-trait-76fc76fddc   Progressing   20       2020-11-10T09:06:30Z
  5. testapp-trait-76fc76fddc   Progressing   40       2020-11-10T09:06:40Z
  6. testapp-trait-76fc76fddc   Progressing   60       2020-11-10T09:07:31Z
  7. testapp-trait-76fc76fddc   Promoting     0        2020-11-10T09:08:00Z
  8. testapp-trait-76fc76fddc   Promoting     100      2020-11-10T09:08:10Z
  9. testapp-trait-76fc76fddc   Finalising    0        2020-11-10T09:08:20Z
  10. testapp-trait-76fc76fddc   Succeeded     0        2020-11-10T09:08:30Z