DocsICP FilingConsole
Documentation
Home Page Container Compute Service User Guide Best practices KubeVela best practices

KubeVela best practices

Updated at:
Copy as MD
Product
My Favorites

This topic shows you how to install and use KubeVela on Alibaba Cloud Container Service for Kubernetes (ACK) to manage applications.

Prerequisites

Procedure

Step 1: Install the KubeVela component

  1. Log on to the ACS console. In the left navigation pane, click Clusters.

  2. On the Clusters page, click the name of the target cluster. In the left navigation pane, choose Applications > Helm.

  3. On the Helm page, click Deploy in the upper-left corner.

  4. In the search bar that appears, enter ack-kubevela, select the component from the search results, and then click Next. In the Basic Information section, enter an Application Name, select default for Namespace, and select Marketplace for Source.

  5. On the Parameter Configurations tab, set chart version to the latest available version, such as 1.9.7.

  6. Click OK to install the component.

  7. In the left-side navigation pane, choose Applications > Helm to check the deployment status of ack-kubevela.

    When the Status of ack-kubevela changes to Deployed, the component is successfully installed.

    Important

    The installation creates the following two core suites:

    1. KubeVela Core: includes the kubevela and cluster-gateway controllers.

    2. VelaUX: includes the VelaUX web server and an Internet-facing SLB as an access endpoint.

  8. In the left-side navigation pane, choose Network > Services to find the automatically created service. The velaux-server service is the external-facing service for VelaUX. The service has a LoadBalancer type and exposes port 8000/TCP.

    Note

    On the service details page for the vela-system namespace, you can find the endpoint for VelaUX. The default username is admin and the default password is VelaUX12345.

  9. Log on to VelaUX using the endpoint.

    Note

    You can then manage your applications and related resources using the Kubernetes API, VelaUX, or the Vela CLI.

Step 2: Install the Vela CLI (optional)

In addition to using VelaUX, you can install the Vela CLI on your local machine to manage applications and install add-ons.

  • For macOS or Linux

    curl -fsSl https://kubevela.io/script/install.sh | bash

  • For Windows

    powershell -Command "iwr -useb https://kubevela.io/script/install.ps1 | iex"

Deploy your first application

Note

The following example deploys a sample cube application with KubeVela, which creates the following cloud resources:

  • A standard Pod with 0.25 cores.

  • An Internet-facing SLB to access the application.

  • A 30 GiB Ultra Disk.

  1. Create a file named cube.yaml with the following content.

    apiVersion: core.oam.dev/v1beta1
kind: Application
metadata:
  name: cube
  namespace: default
spec:
  components:
  - name: cube
    properties:
      cpu: "0.25"
      exposeType: LoadBalancer # Declare an Internet-facing SLB
      image: registry.cn-hangzhou.aliyuncs.com/acr-toolkit/ack-cube:1.0
      memory: 512Mi
      ports:
      - expose: true
        port: 80
        protocol: TCP
    traits:
    - properties:
        "alibabacloud.com/compute-class": "general-purpose" # General-purpose Pod
        "app": "demo-1"
      type: labels
    - properties:
        replicas: 1
      type: scaler
    - properties:
        pvc:
        - mountPath: /home/admin
          name: demo-pvc
          resources:
            requests:
              storage: 30Gi
          storageClassName: alicloud-disk-topology-alltype # Declare an Ultra Disk.
      type: storage
    type: webservice
  policies:
  - name: default
    properties:
      clusters:
      - local
      namespace: default
    type: topology
  workflow:
    mode:
      steps: DAG
    steps:
    - meta:
        alias: Deploy To default
      name: default
      properties:
        policies:
        - default
      type: deploy

  2. Run the following command to create the application from the YAML file using the Vela CLI.

    vela up -f cube.yaml -n default -v demo-v1

    Expected output:

    Applying an application in vela K8s object format...
I1108 15:35:33.369515   65870 apply.go:121] "creating object" name="cube" resource="core.oam.dev/v1beta1, Kind=Application"
App has been deployed 
    Port forward: vela port-forward cube
             SSH: vela exec cube
         Logging: vela logs cube
      App status: vela status cube
        Endpoint: vela status cube --endpoint
Application default/cube applied.

  3. Run the following command to check the running status.

    vela status cube -n default

    Expected output:

    About:
  Name:      	cube
  Namespace: 	default
  Created at:	2023-11-08 15:35:33 +0800 CST
  Status:    	running
Workflow:
  mode: DAG-DAG
  finished: true
  Suspend: false
  Terminated: false
  Steps
  - id: 6vkbhba12p
    name: default
    type: deploy
    phase: succeeded
Services:
  - Name: cube
    Cluster: local  Namespace: default
    Type: webservice
    Healthy Ready:1/1
    Traits:
      labels      scaler      storage

    When the overall application status is running, the deployment is complete.

  4. Run the following command to view the access endpoint.

    vela status cube -n default --endpoint

    Expected output:

    Please access cube from the following endpoints:
+---------+-----------+--------------------------+-----------------------+-------+
| CLUSTER | COMPONENT | REF(KIND/NAMESPACE/NAME) |       ENDPOINT        | INNER |
+---------+-----------+--------------------------+-----------------------+-------+
| local   | cube      | Service/default/cube     | http://your-endpoint  | false |
+---------+-----------+--------------------------+-----------------------+-------+

  5. Access the endpoint in a browser. You will see the following cube application.image.png

  6. Use VelaUX for ongoing management and operations.

    After you log on to VelaUX, you can find an application named cube on the Applications page. The description "Automatically converted from KubeVela Application in Kubernetes." indicates that the application was successfully converted.

CI/CD and operations with KubeVela

1. Build and deploy images with ACR and GitHub

This section shows how to set up a continuous integration (CI) and continuous delivery (CD) pipeline that builds container images on ACK using Kaniko and deploys services using KubeVela.

  • Build an image in a container environment by using Kaniko and push it to a Container Registry (ACR) Personal Edition repository.

  • Describe and deliver a service by using a KubeVela Application.

Prerequisites

  • You have activated Container Registry (ACR) Personal Edition or Enterprise Edition.

  • You have a code repository. This example uses the repository located at https://gitee.com/AliyunContainerService/simple-web-demo.git.

Procedure

  1. Enable the vela-workflow add-on.

    Log on to VelaUX. In the top navigation bar, choose Extensions to go to the Addons page. In the search box, enter workflow to find the vela-workflow add-on. The card for the add-on shows a running status. Clicking the card opens a properties panel on the right, which displays the current version (v0.6.1) and its configuration parameters. The Disable and Upgrade buttons are available at the bottom.

  2. Create a Git secret.

    This example uses GitHub. This secret stores the key for the image build stage.

    kubectl create secret generic git-token --from-literal='GIT_TOKEN=<YOUR-GIT-TOKEN>'

  3. Create a registry credential secret.

    This example uses ACR Personal Edition. This secret stores the credentials for both the image build and application deployment stages.

    Note

    ACK provides a password-free add-on for ACR. You can use this add-on instead of creating a secret. For more information, see Pull images from Container Registry without using secrets.

    kubectl create secret docker-registry docker-regcred \
    --docker-server=registry.cn-beijing.aliyuncs.com \
    --docker-username=yourUserName \
    --docker-password=yourPassword

  4. Define the WorkflowRun.

    apiVersion: core.oam.dev/v1alpha1
kind: WorkflowRun
metadata:
  name: demo-wr
  namespace: default
spec:
  context:
    image: registry.cn-beijing.aliyuncs.com/k8s-conformance/demo:v1
  workflowSpec:
   steps:
    - name: build-push
      type: build-push-image
      inputs:
        - from: context.image
          parameterKey: image
      properties:
        # You can specify your kaniko executor image in the kanikoExecutor field. If not specified, oamdev/kaniko-executor:v1.9.1 is used by default.
        # kanikoExecutor: gcr.io/kaniko-project/executor:latest
        # You can specify the repository address and branch in the context, or specify the full context directly. For more information, see https://github.com/GoogleContainerTools/kaniko#kaniko-build-contexts.
        context:
          git: gitee.com/AliyunContainerService/simple-web-demo
          branch: main
        # Note: This field is overwritten by the image from inputs.
        image: my-registry/test-image:v1
        # Specify the Dockerfile path. If not specified, ./Dockerfile is used by default.
        # dockerfile: ./Dockerfile
        credentials:
          image:
            name: docker-regcred
          git:
            name: git-token
            key: GIT_TOKEN
    - name: apply-app
      type: apply-app
      inputs:
        - from: context.image
          parameterKey: data.spec.components[0].properties.image
      properties:
        data:
          apiVersion: core.oam.dev/v1beta1
          kind: Application
          metadata:
            name: demo-1
            namespace: default
          spec:
            components:
            - name: demo-1
              properties:
                cpu: "0.25"
                exposeType: LoadBalancer # Declare an Internet-facing SLB
                image: image
                memory: 512Mi
                ports:
                - expose: true
                  port: 80
                  protocol: TCP
              traits:
              - properties:
                  "alibabacloud.com/compute-class": "general-purpose" # General-purpose Pod
                  "alibabacloud.com/compute-qos": "default"
                  "app": "demo-1"
                type: labels
              - properties:
                  replicas: 2
                type: scaler
              type: webservice
            policies:
            - name: default
              properties:
                clusters:
                - local
                namespace: default
              type: topology
            workflow:
              mode:
                steps: DAG
              steps:
              - meta:
                  alias: Deploy To default
                name: default
                properties:
                  policies:
                  - default
                type: deploy

  5. Check the workflow status and logs.

    vela workflow logs demo-wr -n default
#Expected output
? Select a step to show logs:  [Use arrows to move, type to filter]
>  build-push
   apply-app

    The entire workflow succeeds when all sub-tasks are complete.

  6. Check the application status and access endpoint.

    # List applications
vela ls -n default
# Expected output
APP   	COMPONENT	TYPE      	TRAITS       	PHASE  	HEALTHY	STATUS   	CREATED-TIME
demo-1	demo-1   	webservice	labels,scaler	running	healthy	Ready:2/2	2023-11-15 17:58:12 +0800 CST
# View application details
vela status demo-1 -n default
# Expected output
About:
  Name:      	demo-1
  Namespace: 	default
  Created at:	2023-11-15 17:58:12 +0800 CST
  Status:    	running
Workflow:
  mode: DAG-DAG
  finished: true
  Suspend: false
  Terminated: false
  Steps
  - id: 8nsijpwkfd
    name: default
    type: deploy
    phase: succeeded
Services:
  - Name: demo-1
    Cluster: local  Namespace: default
    Type: webservice
    Healthy Ready:2/2
    Traits:
      labels      scaler
# View the access endpoint
vela status demo-1 -n default --endpoint
# Expected output
Please access demo-1 from the following endpoints:
+---------+-----------+--------------------------+-----------------------+-------+
| CLUSTER | COMPONENT | REF(KIND/NAMESPACE/NAME) |       ENDPOINT        | INNER |
+---------+-----------+--------------------------+-----------------------+-------+
| local   | demo-1    | Service/default/demo-1   | http://your-endpoint | false |
+---------+-----------+--------------------------+-----------------------+-------+

  7. Access the application using the endpoint.

    image.png

2. High availability with a PodDisruptionBudget

A PodDisruptionBudget (PDB) ensures a minimum number of available Pod replicas for an application by defining a maxUnavailable value. When integrating with KubeVela, you can add it as a step in a WorkflowRun and apply it using an apply-object subtask.

Important

We recommend configuring a PDB for production workloads that require high availability. This ensures the minimum number of available replicas and prevents application unavailability due to voluntary and involuntary disruptions.

  1. Adjust the WorkflowRun.

    apiVersion: core.oam.dev/v1alpha1
kind: WorkflowRun
metadata:
  name: demo-wr
  namespace: default
spec:
  context:
    image: registry.cn-beijing.aliyuncs.com/k8s-conformance/demo:v1
  workflowSpec:
   steps:
    ......
    - name: apply-app
      type: apply-app
      ......
    - name: apply-pdb
      type: apply-object
      properties:
        value:
          apiVersion: policy/v1
          kind: PodDisruptionBudget
          metadata:
            name: demo-pdb
          spec:
            maxUnavailable: 20% # The maximum number of unavailable replicas is 20% of the total, providing eviction protection.
            selector:
              matchLabels:
                app: demo-1 # Associate by using a label selector.

  2. Submit the manifest using kubectl.

    kubectl apply -f demo-wr.yaml

  3. Rerun the workflow and check the creation status of the PDB.

    # Rerun the workflow
vela workflow restart demo-wr -ndefault
# Expected output
Successfully restart workflow: demo-wr
# View the PDB
kubectl get pdb
# Expected output
NAME       MIN AVAILABLE   MAX UNAVAILABLE   ALLOWED DISRUPTIONS   AGE
demo-pdb   1               N/A               1                     2s

3. Manage container access using CloudShell

CloudShell is a KubeVela add-on that provides web terminal functionality based on the open-source cloudtty software.

  1. Install the CloudShell add-on from Extensions.

    In Extensions, search for and install CloudShell. The add-on is successfully installed when its status changes to running.

    The CloudShell add-on depends on the fluxcd add-on. Before installation, ensure the dependent add-on is enabled. After a successful installation, the status on the add-on details panel shows running. You can manage the add-on by using the Disable or Upgrade buttons in the lower-right corner.

  2. Access a container using the Web Terminal.

    In the instance list, find the target Pod and click the terminal icon in the Actions column. A dialog box appears, displaying the vela exec command. Click Open Cloud Shell. After the terminal window opens, you can run commands in the container. For example, run echo "Hello World!" to verify the connection.

4. Automatically scale applications using KEDA

KEDA is an open-source, event-driven auto scaling framework. You can integrate KEDA with KubeVela to achieve fine-grained auto scaling for various scenarios, including time-based scaling.

  1. Install the KEDA add-on from Extensions.

    In Extensions, search for and install KEDA. The add-on is successfully installed when its status changes to running. KubeVela also installs the keda-auto-scaler trait, which enables KEDA-based scaling.

    The KEDA add-on depends on the fluxcd add-on. During installation, the add-on's status is enabling, which indicates a background workflow is running. The installation is complete when the status changes to running.

  2. Modify the WorkflowRun to add the keda-auto-scaler trait.

    Note

    This example adds cron-based scaling. You can also configure triggers based on metrics or other event sources.

    apiVersion: core.oam.dev/v1alpha1
kind: WorkflowRun
metadata:
  name: demo-wr
  namespace: default
spec:
  context:
    image: registry.cn-beijing.aliyuncs.com/k8s-conformance/demo:v1
  workflowSpec:
   steps:
    ......
    - name: apply-app
      type: apply-app
      inputs:
        - from: context.image
          parameterKey: data.spec.components[0].properties.image
      properties:
        data:
          apiVersion: core.oam.dev/v1beta1
          kind: Application
          metadata:
            name: demo-1
            namespace: default
          spec:
            components:
            - name: demo-1
              properties:
                cpu: "0.25"
                exposeType: LoadBalancer # Declare an Internet-facing SLB
                image: image
                memory: 512Mi
                ports:
                - expose: true
                  port: 80
                  protocol: TCP
              traits:
              - properties:
                  "alibabacloud.com/compute-class": "general-purpose" # General-purpose Pod
                type: labels
              - properties:
                  replicas: 2
                type: scaler
              - type: keda-auto-scaler
                properties:
                  triggers:
                  - type: cron
                    metadata:
                      timezone: Asia/Shanghai  # The acceptable values would be a value from the IANA Time Zone Database.
                      start: 00 * * * *       # Scale up at the start of every hour
                      end: 10 * * * *         # Scale down at 10 minutes past every hour
                      desiredReplicas: "3"
              type: webservice

  3. Submit and rerun the workflow.

    kubectl apply -f demo-wr.yaml
# Rerun the workflow
vela workflow restart demo-wr -ndefault
# Expected output
Successfully restart workflow: demo-wr

  4. Check the application status.

    The application details show that keda-auto-scaler is enabled.

    vela status demo-1 -ndefault

    Expected output:

    About:
  Name:      	demo-1
  Namespace: 	default
  Created at:	2023-11-15 17:58:12 +0800 CST
  Status:    	running
Workflow:
  mode: DAG-DAG
  finished: true
  Suspend: false
  Terminated: false
  Steps
  - id: ziwddaa6mt
    name: default
    type: deploy
    phase: succeeded
Services:
  - Name: demo-1
    Cluster: local  Namespace: default
    Type: webservice
    Healthy Ready:2/2
    Traits:
      labels      scaler      keda-auto-scaler
Previous：Use BestEffort pods to run Spark applicationsNext：Tekton best practices