Built-in Policy Type

Allow configuration drift for applied resources, delivery the resource without continuously reconciliation.

Examples (apply-once)

It’s generally used in scenario.

Specification (apply-once)

rules (apply-once)

selector (apply-once)

strategy (apply-once)

Garbage-Collect

Description

Configure the garbage collect behaviour for the application.

Examples (garbage-collect)

It’s used in scenario. It can be used to configure the collection policy, e.g. don’t delete the legacy resources when updating.

kind: Application
metadata:
  name: first-vela-app
spec:
  components:
    - name: express-server
      type: webservice
      properties:
        image: oamdev/hello-world
        port: 8000
      traits:
        - type: ingress-1-20
          properties:
            domain: testsvc.example.com
            http:
              "/": 8000
  policies:
    - name: keep-legacy-resource
      type: garbage-collect
      properties:
        keepLegacyResource: true

apiVersion: core.oam.dev/v1beta1
kind: Application
metadata:
  name: garbage-collect-app
spec:
  components:
    - name: hello-world-new
      type: webservice
      properties:
        image: oamdev/hello-world
      traits:
        - type: expose
          properties:
            port: [8000]
  policies:
    - name: garbage-collect
      type: garbage-collect
      properties:
        rules:
          - selector:
              traitTypes:
                - expose
            strategy: onAppDelete

Specification (garbage-collect)

rules (garbage-collect)

selector (garbage-collect)

Description

apiVersion: core.oam.dev/v1beta1
kind: Application
metadata:
  name: example-app-rollout
  namespace: default
spec:
  components:
    - name: hello-world-server
      type: webservice
      properties:
        image: crccheck/hello-world
        ports: 
        - port: 8000
          expose: true
        type: webservice
  policies:
    - name: health-policy-demo
      type: health
      properties:
        probeInterval: 5
        probeTimeout: 10

Specification (health)

Override

Description

Describe the configuration to override when deploying resources, it only works with specified deploy step in workflow.

Examples (override)

apiVersion: core.oam.dev/v1beta1
kind: Application
metadata:
  name: advance-override
  namespace: examples
spec:
  components:
    - name: nginx-advance-override-legacy
      type: webservice
      properties:
        image: nginx:1.20
    - name: nginx-advance-override-latest
      type: webservice
      properties:
        image: nginx
  policies:
      type: topology
      properties:
        clusterLabelSelector:
          region: hangzhou
    - name: topology-local
      type: topology
      properties:
        clusters: ["local"]
        namespace: examples-alternative
    - name: override-nginx-legacy
      type: override
      properties:
        selector: ["nginx-advance-override-legacy"]
    - name: override-nginx-latest
      type: override
      properties:
        selector: ["nginx-advance-override-latest", "nginx-advance-override-stable"]
        components:
          - name: nginx-advance-override-stable
            type: webservice
            properties:
              image: nginx:stable
  workflow:
    steps:
      - type: deploy
        name: deploy-local
        properties:
          policies: ["topology-local", "override-nginx-legacy"]
        name: deploy-hangzhou
        properties:
          policies: ["topology-hangzhou-clusters", "override-nginx-latest"]

Specification (override)

components (override)

traits (override)

Description

Describe the configuration to replicate components when deploying resources, it only works with specified deploy step in workflow.

Examples (replication)

In KubeVela, we can dispatch resources across the clusters. But projects like OpenYurt have finer-grained division like node pool. This requires to dispatch some similar resources to the same cluster. These resources are called replication. Back to the example of OpenYurt, it can integrate KubeVela and replicate the resources then dispatch them to the different node pool.

Usage

Replication is an internal policy. It can be only used with deploy workflow step. When using replication policy. A new field replicaKey will be added to context. User can use definitions that make use of context.replicaKey. For example, apply a replica-webservice ComponentDefinition.

In this ComponentDefinition, we can use context.replicaKey to distinguish the name of Deployment and Service.

apiVersion: core.oam.dev/v1beta1
kind: ComponentDefinition
metadata:
  annotations:
    definition.oam.dev/description: Webservice, but can be replicated
  name: replica-webservice
  namespace: vela-system
spec:
  schematic:
    cue:
      template: |
        output: {
            apiVersion: "apps/v1"
            kind:       "Deployment"
            metadata: {
                if context.replicaKey != _|_ {
                    name: context.name + "-" + context.replicaKey
                }
                if context.replicaKey == _|_ {
                    name: context.name
                }
            }
            spec: {
                selector: matchLabels: {
                    "app.oam.dev/component": context.name
                    if context.replicaKey != _|_ {
                        "app.oam.dev/replicaKey": context.replicaKey
                    }
                }
                template: {
                    metadata: {
                        labels: {
                            if parameter.labels != _|_ {
                                parameter.labels
                            }
                            if parameter.addRevisionLabel {
                                "app.oam.dev/revision": context.revision
                            }
                            "app.oam.dev/name":      context.appName
                            "app.oam.dev/component": context.name
                            if context.replicaKey != _|_ {
                                "app.oam.dev/replicaKey": context.replicaKey
                            }
                        }
                        if parameter.annotations != _|_ {
                            annotations: parameter.annotations
                        }
                    }
                }
            }
        }
        outputs: {
            if len(exposePorts) != 0 {
                webserviceExpose: {
                    apiVersion: "v1"
                    kind:       "Service"
                    metadata: {
                        if context.replicaKey != _|_ {
                            name: context.name + "-" + context.replicaKey
                        }
                        if context.replicaKey == _|_ {
                            name: context.name
                        }
                    }
                    spec: {
                        selector: {
                            "app.oam.dev/component": context.name
                            if context.replicaKey != _|_ {
                                "app.oam.dev/replicaKey": context.replicaKey
                            }
                        }
                        ports: exposePorts
                        type:  parameter.exposeType
                    }
                }
            }
        }

Then user can apply application below. Replication policy is declared in application.spec.policies. These policies are used in deploy-with-rep workflow step. They work together to influence the deploy step.

• override: select hello-rep component to deploy.
• topology: select cluster local to deploy.
• replication: select hello-rep component to replicate.

As a result, there will be two Deployments and two Services:

apiVersion: core.oam.dev/v1beta1
kind: Application
metadata:
  name: app-replication-policy
spec:
  components:
    - name: hello-rep
      properties:
        image: crccheck/hello-world
        ports:
          - port: 80
            expose: true
  policies:
    - name: comp-to-replicate
      type: override
      properties:
        selector: [ "hello-rep" ]
      type: topology
      properties:
        clusters: [ "local" ]
    - name: replication-default
      type: replication
      properties:
        keys: ["beijing","hangzhou"]
        selector: ["hello-rep"]
  workflow:
    steps:
      - name: deploy-with-rep
        type: deploy
        properties:
          policies: ["comp-to-replicate","target-default","replication-default"]

Specification (replication)

Shared-Resource

Description

Configure the resources to be sharable across applications.

Examples (shared-resource)

It’s used in shared-resource scenario. It can be used to configure which resources can be shared between applications. The target resource will allow multiple application to read it but only the first one to be able to write it.

apiVersion: core.oam.dev/v1beta1
kind: Application
metadata:
  name: app1
spec:
  components:
    - name: ns1
      type: k8s-objects
      properties:
        objects:
          - apiVersion: v1
            kind: Namespace
            metadata:
              name: example
    - name: cm1
      type: k8s-objects
      properties:
        objects:
          - apiVersion: v1
            kind: ConfigMap
            metadata:
              name: cm1
              namespace: example
            data:
              key: value1
  policies:
    - name: shared-resource
      type: shared-resource
      properties:
        rules:
          - selector:
              resourceTypes: ["Namespace"]

apiVersion: core.oam.dev/v1beta1
kind: Application
metadata:
  name: app2
spec:
  components:
    - name: ns2
      type: k8s-objects
      properties:
        objects:
          - apiVersion: v1
            kind: Namespace
            metadata:
              name: example
    - name: cm2
      type: k8s-objects
      properties:
        objects:
          - apiVersion: v1
            kind: ConfigMap
            metadata:
              name: cm2
              namespace: example
            data:
              key: value2
  policies:
    - name: shared-resource
      type: shared-resource
      properties:
        rules:
          - selector:
              resourceTypes: ["Namespace"]

Specification (shared-resource)

rules (shared-resource)

selector (shared-resource)

Description

Describe the destination where components should be deployed to.

apiVersion: core.oam.dev/v1beta1
kind: Application
metadata:
  name: basic-topology
  namespace: examples
spec:
  components:
    - name: nginx-basic
      type: webservice
      properties:
        image: nginx
  policies:
    - name: topology-hangzhou-clusters
      type: topology
      properties:
        clusters: ["hangzhou-1", "hangzhou-2"]

apiVersion: core.oam.dev/v1beta1
kind: Application
metadata:
  name: local-ns-topology
  namespace: examples
spec:
  components:
    - name: nginx-local-ns
      type: webservice
      properties:
        image: nginx
  policies:
    - name: topology-local
      type: topology
      properties:

Specification (topology)