Kubevela Application Rollout Trait Conflict

Threat/Impact Level: HIGH | Downtime Risk: HIGH | Time to Fix: 15–30 mins

TL;DR

• What broke: A KubeVela Application component has two or more traits that own conflicting control over the same resource axis (replica count, rollout strategy, or scaling), causing the rollout controller to fail reconciliation and surface application rollout failed: trait conflict.
• How to fix it: Remove the conflicting trait (typically a scaler or hpa trait co-existing with a rollout trait), and consolidate scaling intent into the rollout trait spec.
• Fast path: Use our Client-Side Sandbox above to auto-refactor this — paste your Application YAML and get a clean, conflict-free output without sending secrets anywhere.

ERROR controller-runtime/controller "Application" failed to reconcile
reason: trait conflict detected on component "web-frontend"
traits [rollout, scaler] both attempt to manage spec.replicas
application rollout failed: trait conflict

How to Fix It (The Solution)

Root Cause Identification

Run this to see rendered trait patches before they conflict:

vela traits --app <app-name> -n <namespace>
# Then inspect the Application status:
kubectl get application <app-name> -n <namespace> -o jsonpath='{.status.conditions}' | jq .

Look for reason: TraitConflict in the conditions array.

Basic Fix — Remove the Conflicting Trait

The most common conflict: scaler trait + rollout trait on the same component.

apiVersion: core.oam.dev/v1beta1
kind: Application
metadata:
  name: web-frontend
spec:
  components:
    - name: web-frontend
      type: webservice
      properties:
        image: myrepo/web:v2.1.0
        port: 8080
      traits:
-       - type: scaler
-         properties:
-           replicas: 5
        - type: rollout
          properties:
            targetSize: 5
            rolloutBatches:
              - replicas: 2
              - replicas: 3

Why: The rollout trait owns spec.replicas during progression. The scaler trait's static replica patch collides with it at render time. Remove scaler; set your target replica count inside rollout.properties.targetSize.

Enterprise Best Practice — HPA + Rollout Coexistence

If you need autoscaling AND controlled rollouts, you cannot run hpa and rollout traits simultaneously on the same component. The correct pattern is to disable HPA during rollout using a workflow step, then re-enable it post-rollout.

apiVersion: core.oam.dev/v1beta1
kind: Application
metadata:
  name: web-frontend
spec:
  components:
    - name: web-frontend
      type: webservice
      properties:
        image: myrepo/web:v2.1.0
      traits:
-       - type: hpa
-         properties:
-           min: 2
-           max: 10
-           cpuUtil: 60
        - type: rollout
          properties:
            targetSize: 5
            rolloutBatches:
              - replicas: 2
              - replicas: 3
+ # Re-apply HPA via a post-rollout workflow step, not as a concurrent trait
  workflow:
    steps:
      - name: rollout-web
        type: canary-deploy
        properties:
          component: web-frontend
+     - name: restore-hpa
+       type: apply-object
+       properties:
+         value:
+           apiVersion: autoscaling/v2
+           kind: HorizontalPodAutoscaler
+           metadata:
+             name: web-frontend-hpa
+             namespace: production
+           spec:
+             scaleTargetRef:
+               apiVersion: apps/v1
+               kind: Deployment
+               name: web-frontend
+             minReplicas: 2
+             maxReplicas: 10

This pattern sequences the operations: rollout completes → HPA is applied. No concurrent ownership conflict.

💡 Tired of pasting proprietary infrastructure configs into public LLMs? Generic AI interfaces log your company's ARNs, connection strings, and private keys. StackEngine enforces client-side zero-trust boundaries—the sandbox above executes 100% locally in your browser. Drop your broken manifest above to redact secrets locally and synthesize deterministic patch drafts with your own API key.

(For CI/CD pipeline automation, install via npm i -g stackengine).

package kubevela.traitconflict

deny[msg] {
  component := input.review.object.spec.components[_]
  traits := [t.type | t := component.traits[_]]
  "rollout" in traits
  "scaler" in traits
  msg := sprintf("Component '%v' has both 'rollout' and 'scaler' traits. Remove 'scaler' — replica count must be owned exclusively by 'rollout'.", [component.name])
}

deny[msg] {
  component := input.review.object.spec.components[_]
  traits := [t.type | t := component.traits[_]]
  "rollout" in traits
  "hpa" in traits
  msg := sprintf("Component '%v' has both 'rollout' and 'hpa' traits. HPA must be applied post-rollout via workflow step.", [component.name])
}

# .github/workflows/kubevela-validate.yml
- name: KubeVela Dry Run
  run: |
    vela dry-run -f app.yaml --server-side
    if [ $? -ne 0 ]; then
      echo "Trait conflict detected in dry-run. Block merge."
      exit 1
    fi