Ensuring applications adhere to organizational standards for security, compliance, and resource usage can feel like an endless battle in a dynamic Kubernetes environment. Without proper governance, applications can quickly become sprawling, insecure, and costly. This is where KubeVela Policies step in, offering a powerful way for platform teams to regain control.

In this chapter, we’ll explore how KubeVela provides an application-centric approach to enforce these critical rules. You’ll learn exactly what KubeVela Policies are, why they are essential for platform teams, and how to apply them to your applications to maintain control and order. We’ll move beyond raw Kubernetes resource-level policies and embrace KubeVela’s higher-level abstractions for comprehensive application governance.

To get the most out of this chapter, you should have a basic understanding of KubeVela Applications, Components, and Traits, as covered in previous sections.

The Governance Challenge for Platform Teams

Imagine you’re a platform engineer managing hundreds of applications across multiple Kubernetes clusters. Each application might consist of several Kubernetes Deployments, Services, ConfigMaps, and other resources. How do you ensure:

  • All container images originate from approved, secure registries?
  • No single application consumes more than its fair share of CPU or memory, preventing “noisy neighbor” issues?
  • Sensitive data is never exposed via unencrypted connections, adhering to security best practices?
  • Resources are cleaned up automatically and completely when an application is removed, avoiding orphaned resources and unnecessary cloud costs?

Applying these rules directly at the Kubernetes resource level (e.g., using Admission Controllers, raw ResourceQuota objects, or Pod Security Standards) becomes incredibly complex and fragmented. Developers would need to understand and apply these low-level policies, leading to cognitive overload, potential errors, and inconsistent application deployments.

📌 Key Idea: The core problem is that raw Kubernetes policies operate at the resource level, while platform teams need to govern at the application level.

KubeVela addresses this by elevating policy enforcement to the application layer. Instead of policing individual Kubernetes resources, you define policies that apply to entire KubeVela Applications. This provides a consistent, higher-level abstraction and a developer-friendly governance model.

KubeVela Policies: Application-Centric Control

KubeVela Policies are a core part of the Open Application Model (OAM), specifically designed to define and enforce rules and constraints on applications. They allow platform engineers to codify operational best practices, security requirements, and compliance mandates into reusable building blocks.

Essentially, a KubeVela Policy tells the KubeVela control plane how an application should behave or what conditions it must meet to be considered compliant and healthy. This separation of concerns is powerful: platform engineers can define these governance rules once, and developers can simply consume them by referencing policies in their application definitions, without needing to understand the intricate underlying Kubernetes details.

PolicyDefinition vs. Policy Instance

Just like Components and Traits, Policies in KubeVela are extensible. The framework distinguishes between two key concepts:

  1. PolicyDefinition: This is a blueprint or template for a type of policy. Platform engineers create PolicyDefinition resources to define new types of policies tailored to their organization’s specific needs. These definitions specify the policy’s parameters and how it interacts with the application. KubeVela ships with several built-in PolicyDefinitions (e.g., for resource quotas, garbage collection).
  2. Policy: This is an instance of a PolicyDefinition. Once a PolicyDefinition exists, developers or platform engineers can create Policy instances that refer to these definitions and apply them to applications. A Policy instance specifies the concrete values for the parameters defined in its PolicyDefinition.

🧠 Important: PolicyDefinition defines what kind of policy can exist, while a Policy instance defines a specific set of rules of that kind.

How Policies Integrate with Applications

The relationship between PolicyDefinition, Policy instances, and Applications is crucial for understanding KubeVela’s governance model:

flowchart TD PE[Platform Engineer] -->|Defines Policy Blueprint| PolicyDefinition[Policy Definition] PE -->|Creates Rule Set| PolicyInstance[Policy Instance] PolicyInstance -->|References Type| PolicyDefinition Developer[Developer] -->|Creates Application| Application[Application] Application -->|Attaches or References| PolicyInstance KubeVela[KubeVela Control Plane] -->|Enforces Rules| Application

In this flow:

  • Platform Engineers define PolicyDefinitions (reusable templates) and often create common Policy instances (specific rule sets).
  • Developers (or platform engineers managing applications) then create Application resources.
  • An Application resource includes a policies section, which can either embed a policy directly or, more commonly, reference an existing Policy object by name.
  • The KubeVela Control Plane observes these policies attached to applications and enforces them during the application’s lifecycle, ensuring compliance and desired behavior.

Common KubeVela Policy Types

KubeVela ships with several powerful built-in policy types, and its extensibility allows you to define many more:

  • ResourceQuotaPolicy: Limits the total CPU, memory, or other compute resources that an application (or its components) can consume within a namespace. This is crucial for cost management and preventing resource exhaustion.
  • TopologyPolicy: Specifies deployment constraints, such as where an application should be deployed (e.g., specific clusters, namespaces, regions, or even node labels). Ideal for multi-cluster deployments, disaster recovery, and compliance with data residency.
  • GarbageCollectPolicy: Defines how resources associated with an application are cleaned up when the application itself is deleted. This prevents orphaned resources and reduces cloud costs by ensuring complete removal.
  • HealthCheckPolicy: Establishes criteria for determining an application’s overall health, going beyond simple Pod liveness/readiness probes to include dependencies or business logic.
  • OverridePolicy: Allows overriding certain parameters in components or traits based on environmental conditions or other criteria, providing dynamic configuration.
  • SharedResourcePolicy: Manages the lifecycle of resources shared across multiple applications.

These policies provide powerful ways to standardize application behavior, resource consumption, and deployment patterns across your fleet.

Step-by-Step: Applying a Resource Quota Policy

Let’s put theory into practice. We’ll apply a ResourceQuotaPolicy to an application to limit its resource consumption. This is a common requirement for platform teams to prevent “noisy neighbors” and manage cloud spend.

Prerequisites: Your KubeVela Environment

Ensure you have a running Kubernetes cluster with KubeVela installed. You should also have kubectl and vela CLI tools configured.

As of 2026-06-22, KubeVela v1.10.x is the current stable release series. Your vela CLI and KubeVela control plane should be compatible.

# Verify KubeVela CLI version (should be v1.10.x or newer)
vela version

# Verify kubectl access to your cluster
kubectl cluster-info

Step 1: Define a Simple Application

First, let’s define a basic KubeVela application. This application will deploy a simple Nginx server.

Create a file named my-nginx-app.yaml:

# my-nginx-app.yaml
apiVersion: core.oam.dev/v1beta1
kind: Application
metadata:
  name: my-nginx-app
spec:
  components:
    - name: nginx-server
      type: webservice
      properties:
        image: nginx:1.25.3
        port: 80
        cpu: "500m" # Requesting 500 millicores
        memory: "512Mi" # Requesting 512 MiB

Explanation:

  • This is a standard KubeVela Application resource.
  • It defines a single webservice component named nginx-server.
  • We’ve explicitly set cpu and memory requests for this component. This is important because ResourceQuotaPolicy will typically act upon these requests to ensure they don’t exceed defined limits.

Deploy this application:

vela up -f my-nginx-app.yaml --wait

The --wait flag ensures the command waits until the application is fully deployed and healthy according to its definition.

You can check its status:

vela status my-nginx-app

At this point, the application should be healthy and requesting its specified resources.

Step 2: Create a Resource Quota Policy Instance

Now, let’s define a specific Policy instance that limits the total resources an application can request. We’ll create a ResourceQuotaPolicy that enforces a maximum of 200m CPU and 256Mi memory for any application it’s applied to.

Create a file named low-resource-quota-policy.yaml:

# low-resource-quota-policy.yaml
apiVersion: core.oam.dev/v1beta1
kind: Policy
metadata:
  name: low-resource-quota # This is the name we'll reference later
spec:
  type: resource-quota # This refers to the built-in ResourceQuotaPolicyDefinition
  properties:
    cpu: "200m"
    memory: "256Mi"

Explanation:

  • kind: Policy: This tells Kubernetes and KubeVela that we are defining a specific policy rule set.
  • metadata.name: low-resource-quota: This is the unique name of this policy instance. We will use this name to reference it from our application.
  • spec.type: resource-quota: This specifies that this policy is an instance of the ResourceQuotaPolicyDefinition. KubeVela knows how to interpret the properties based on this type.
  • spec.properties: These are the parameters for this specific resource-quota policy. Here, we set a hard limit of 200m CPU and 256Mi memory.

Apply this Policy instance to your Kubernetes cluster using kubectl:

kubectl apply -f low-resource-quota-policy.yaml

⚡ Quick Note: Remember, PolicyDefinitions are applied using vela def apply, but Policy instances (which are standard Kubernetes custom resources) are applied using kubectl apply.

Step 3: Attach the Policy to the Application

Now, we need to tell our my-nginx-app to use the low-resource-quota policy we just created. We do this by adding a policies section to our Application manifest and referencing the policy by its name.

Modify my-nginx-app.yaml to include the policy reference:

# my-nginx-app.yaml (modified to reference Policy object)
apiVersion: core.oam.dev/v1beta1
kind: Application
metadata:
  name: my-nginx-app
spec:
  components:
    - name: nginx-server
      type: webservice
      properties:
        image: nginx:1.25.3
        port: 80
        cpu: "500m" # Still requesting 500 millicores
        memory: "512Mi" # Still requesting 512 MiB
  policies: # <--- New section for policies
    - name: my-app-resource-limit # A unique name for this policy binding within the application
      type: resource-quota # The type of policy, matching the PolicyDefinition
      properties:
        policyRef: low-resource-quota # Referencing our Policy object by its name

Explanation of the policies section:

  • policies:: This top-level key within the Application spec is where you list all policies that apply to this application.
  • - name: my-app-resource-limit: This is an internal name for this specific policy binding within this application manifest. It helps differentiate multiple policies of the same type if needed.
  • type: resource-quota: This specifies that we are using a policy of the resource-quota type.
  • properties: policyRef: low-resource-quota: This is the crucial part. It tells KubeVela to apply the rules defined in the standalone Policy object named low-resource-quota to this application. This promotes reusability, as the low-resource-quota policy can now be applied to many applications.

Now, apply the updated application manifest:

vela up -f my-nginx-app.yaml --wait

Step 4: Observe Policy Enforcement

After updating the application, KubeVela’s control plane will reconcile the application with the attached policy. Our application requests 500m CPU and 512Mi memory, but the low-resource-quota policy limits it to 200m CPU and 256Mi memory. This means the policy should intervene.

Let’s check the status of the application:

vela status my-nginx-app --detail

You should see output indicating that the policy low-resource-quota is affecting the application. KubeVela, through its ResourceQuotaPolicy implementation, will typically create a Kubernetes ResourceQuota object in the application’s namespace. This ResourceQuota will then enforce the defined limits, preventing the application’s Pods from requesting more than allowed.

Look closely at the Policy section of the vela status --detail output for any warnings or messages. You can also inspect the underlying Kubernetes ResourceQuota object:

kubectl get resourcequota -n default # Or the namespace where your app is deployed
kubectl describe resourcequota low-resource-quota-my-app-resource-limit -n default # KubeVela names it based on policy and app

You will likely observe that the ResourceQuota object shows a limit of 200m CPU and 256Mi memory. When your application’s Pods attempt to request 500m CPU, the Kubernetes Admission Controller (which ResourceQuota leverages) will prevent the Pod from being scheduled or created if it exceeds the quota. KubeVela might also show the application in a unhealthy or progressing state if the policy prevents full deployment.

⚡ Real-world insight: ResourceQuotaPolicy directly translates to Kubernetes ResourceQuota resources. This means the enforcement is handled by Kubernetes itself, with KubeVela providing the higher-level abstraction and application-centric binding.

Step 5: Clean Up

To clean up the resources created in this step:

vela delete my-nginx-app
kubectl delete -f low-resource-quota-policy.yaml

This will remove both the KubeVela Application and the standalone Policy object.

Mini-Challenge: Enforcing Resource Cleanup with GarbageCollectPolicy

Platform teams constantly battle resource sprawl, where deleted applications leave behind orphaned Kubernetes resources (like PersistentVolumeClaims, Secrets, or even Deployments that somehow got detached). This leads to unnecessary cloud costs and clutter.

Challenge: Modify the my-nginx-app (or create a new simple application) and apply a GarbageCollectPolicy to it. This policy should ensure that all Kubernetes resources created by the application are automatically and cleanly deleted when the application itself is deleted via vela delete.

Hint:

  • You’ll need to define a Policy of type: garbage-collect.
  • The garbage-collect policy has properties like strategy and rules. A common strategy is onAppDelete, which ensures cleanup when the Application is deleted.
  • Attach this Policy instance to your my-nginx-app (or a new test application) in its policies section.
  • Deploy the application. Verify it creates some Kubernetes resources (e.g., kubectl get deploy,svc,pod -n default).
  • Then, vela delete the application and observe if all associated Kubernetes resources are gone.

What to observe/learn: After running vela delete <your-app>, execute kubectl get all -n <your-app-namespace> (or the namespace you used). You should find that no resources or significantly fewer resources (e.g., only KubeVela’s own internal tracking resources, not your application’s deployments, services, etc.) remain. This demonstrates how KubeVela policies automate cleanup, reducing manual toil, preventing resource leakage, and ultimately saving cloud costs.

Common Pitfalls & Troubleshooting

Even with KubeVela’s abstractions, policies can sometimes be tricky. Here are some common issues and how to approach them:

  1. Policy Not Taking Effect or Unexpected Behavior:

    • Incorrect policyRef: Double-check the metadata.name in your Policy object and the properties.policyRef in your Application manifest. They must match exactly.
    • Wrong type: Ensure the type in your Application’s policy reference (e.g., type: resource-quota) matches the type defined in the Policy instance.
    • Policy not applied: Did you kubectl apply -f your-policy.yaml the Policy instance itself? If it’s a PolicyDefinition, did you use vela def apply?
    • Timing/Reconciliation: KubeVela’s control plane needs time to reconcile changes. Wait a few moments and check vela status --detail again. Sometimes, a vela up -f <app.yaml> --refresh can force a re-evaluation.

  2. Conflicting Policies:

    • If multiple policies apply to the same resource or aspect of an application (e.g., two ResourceQuotaPolicy instances, or a ResourceQuotaPolicy and an OverridePolicy affecting resource requests), their interactions can be complex. KubeVela has a policy evaluation order, but it’s generally best to design policies to be as orthogonal as possible to avoid ambiguity.
    • Check vela status <app-name> --detail carefully for any warnings or errors related to policy conflicts. KubeVela will often log if a policy is being overridden or if conflicts are detected.

  3. Debugging Policies:

    • vela status <app-name> --detail: This is your primary diagnostic tool. It shows the status of all components, traits, workflows, and policies applied to the application. Look for the Policy sections and any Health or Message fields indicating issues or enforcement actions.
    • kubectl get policy <policy-name> -o yaml: Inspect the raw Policy object YAML to ensure its spec is correctly defined and matches your intent.
    • kubectl describe policy <policy-name>: Provides more detailed events and status information for the Policy object itself, which can reveal why it’s not being applied or is in an error state.
    • kubectl get policydefinition: Verify that the PolicyDefinition for the type you’re using (e.g., resource-quota) exists and is healthy in your cluster. If it’s a custom policy, check its definition carefully.
    • KubeVela Controller Logs: For deeper issues, inspect the logs of the KubeVela core controllers (e.g., vela-core deployment in the vela-system namespace) for error messages related to policy reconciliation.

Summary

In this chapter, we’ve taken a significant step into the world of application governance with KubeVela Policies. This powerful feature allows platform teams to embed crucial operational, security, and compliance rules directly into the application delivery process.

Here are the key takeaways:

  • Application-Centric Governance: KubeVela Policies enable platform teams to define and enforce rules at the application level, abstracting away low-level Kubernetes complexities for developers.
  • Separation of Concerns: PolicyDefinitions act as reusable blueprints, while Policy instances define specific rule sets. Developers then consume these Policy instances by referencing them in their Application manifests.
  • Extensibility: KubeVela’s policy framework is highly extensible, allowing platform engineers to define custom policies tailored to unique organizational needs.
  • Built-in Policies: KubeVela provides several powerful built-in policies, such as ResourceQuotaPolicy for resource management and GarbageCollectPolicy for automated cleanup.
  • Practical Enforcement: We demonstrated how to apply a ResourceQuotaPolicy to limit application resource consumption, a critical aspect of cost control and stability in any Kubernetes environment.

By leveraging KubeVela Policies, platform teams can ensure consistency, compliance, and security across their application fleet. This empowers developers to focus on building features without getting bogged down in infrastructure-level governance details, ultimately leading to faster, safer, and more reliable application delivery.

Next, we’ll dive into KubeVela Workflows, which allow you to define custom, multi-step application delivery processes, taking your application management to the next level.

References

This page is AI-assisted and reviewed. It references official documentation and recognized resources where relevant.