Version: v1.8

Policy Definition

In this section we will introduce how to define a custom policy with CUE. Make sure you’ve learned the basic knowledge about Definition Concept and how to manage definition.

Generate resources in policy is similar to trait, policy can be used to define things across components.

Let’s use vela def init to create a basic policy scaffold:

  1. vela def init my-plc -t policy --desc "My ingress route policy." > myroute.cue

The content of the scaffold expected to be:

  1. // $ cat myroute.cue
  2. "my-plc": {
  3.     annotations: {}
  4.     attributes: {}
  5.     description: "My ingress route policy."
  6.     labels: {}
  7.     type: "policy"
  8. }
  10. template: {
  11. }

The rule is aligned with component definition, you must specify output, while you can use outputs for more objects, the format as below:

  1. output: {
  2.     <full template data>
  3. }
  4. outputs: <unique-name>: 
  5.   <full template data>

Below is an example that we create a traffic split service mesh object in policy.

  1. "my-plc": {
  2.     description: "My service mesh policy."
  3.     type:        "policy"
  4. }
  6. template: {
  7.     #ServerWeight: {
  8.         service: string
  9.         weight:  int
  10.     }
  11.     parameter: {
  12.         weights: [...#ServerWeight]
  13.     }
  15.     output: {
  16.         apiVersion: "split.smi-spec.io/v1alpha3"
  17.         kind:       "TrafficSplit"
  18.         metadata: name: context.name
  19.         spec: {
  20.             service:  context.name
  21.             backends: parameter.weights
  22.         }
  23.     }
  24. }

Apply to our control plane to make this Policy work:

  1. vela def apply myroute.cue

Then our end users can discover it immediately and use it in Application.

After using vela up by the following command:

  1. cat <<EOF | vela up -f -
  2. apiVersion: core.oam.dev/v1beta1
  3. kind: Application
  4. metadata:
  5.   name: my-test-2
  6. spec:
  7.   components:
  8.     - name: server-v1
  9.       type: webservice
  10.       properties:
  11.         image: oamdev/hello-world:v1
  12.     - name: server-v2
  13.       type: webservice
  14.       properties:
  15.         image: oamdev/hello-world:v2
  16.   policies:
  17.     - type: my-plc
  18.       name: unified
  19.       properties:
  20.         weights:
  21.           - service: server-v1
  22.             weight: 80
  23.           - service: server-v2
  24.             weight: 20
  25. EOF

The policy will generate Kubernetes resources by KubeVela like below:

  1. apiVersion: split.smi-spec.io/v1alpha3
  2. kind: TrafficSplit
  3. metadata:
  4.   name: unified
  5.   namespace: default
  6. spec:
  7.   backends:
  8.   - service: server-v1
  9.     weight: 80
  10.   - service: server-v2
  11.     weight: 20
  12.   service: unified

You can define any Kubernetes API objects in policies if you want.

Not all policies generate resources, there’re several built-in policies which are used to control the whole delivery precess and workflows.

Policy Definition - 图1tip

These special polices are usually coded in the application controller.

Last updated on May 6, 2023 by Tianxin Dong