Argo Rollouts Not Creating Rollout Resources: Causes and Fixes

Introduction

A common frustration when adopting Argo Rollouts is applying what appears to be a valid Rollout manifest and then seeing… nothing. You run kubectl get rollouts in the namespace, and the list comes back empty. Or perhaps you see an error at apply time saying the object cannot be created, even though the YAML seems to match the documentation. From a user’s point of view, it feels as if Argo Rollouts is “not creating” the resource. In reality, the Kubernetes API server is either rejecting the object, or the rollout exists but is not where you expect it. The good news is that this situation is usually caused by a small number of misconfigurations that you can identify and correct.

In this guide, you will walk through the most common reasons a rollout is not created, how admission webhooks and schema validation come into play, and which checks will reliably lead you to the root cause.

How Rollout Creation Works Behind the Scenes

To understand why your rollout is missing, it helps to recap what happens when you run kubectl apply -f rollout.yaml.

First, kubectl sends your manifest to the Kubernetes API server. If the Rollout type is recognized (the CRD is registered) and your user has permissions, the API server runs it through validation and admission webhooks. These webhooks may:

• Enforce required fields and structure.
• Default values when you omit optional fields.
• Reject objects that violate constraints.

If validation passes, the API server persists the rollout in etcd and returns a successful response. The Argo Rollouts controller then notices the new resource and starts reconciling it.

When something goes wrong before persistence, the rollout is never created. Your task is to figure out where in this path the failure occurs.

Step-by-Step Guide to Fix Missing Rollout Resources

Step 1: Check for Immediate Apply Errors

Start by re‑running your apply with –validate=true (the default) and watching the output carefully:

kubectl apply -f rollout.yaml

If Kubernetes rejects the manifest, the error message printed here is your first and best clue. Common problems include:

• Unknown fields or wrong nesting.
• Missing required sections of the spec.
• Invalid values for strategy, selectors, or ports.

For example, you might see:

error: error validating “rollout.yaml”: error validating data: ValidationError(Rollout.spec): missing required field “strategy” in io.argoproj.rollouts.v1alpha1.RolloutSpec

In this case, the rollout never made it past schema validation. Correcting the spec and re‑applying is the right move; no further debugging is needed until the manifest is accepted. If the apply command reports success (“created” or “configured”), but kubectl get rollouts still shows nothing, you may be looking in the wrong namespace or context.

Step 2: Verify the Namespace and Context

Rollouts are namespaced resources. If you apply a manifest without specifying metadata.namespace, Kubernetes assumes the current namespace in your kubeconfig context. If you later run kubectl get rollouts in a different namespace, it will appear as if the object was never created.

Confirm your current context and namespace:

kubectl config current-context
kubectl config view --minify -o jsonpath='{..namespace}'

Then, explicitly list rollouts in the namespace where you think the object should live:

kubectl get rollouts -n <your-namespace>

If you applied the manifest to the default namespace but expect it in production, you will see an empty list there. Adding metadata.namespace: production to your YAML removes this ambiguity and makes your intent obvious.

Step 3: Validate the Rollout Spec Against Known Patterns

If namespace and context line up, the next step is to compare your rollout spec against a minimal, known‑good example. Start with a simple rollout that you know should work:

apiVersion: argoproj.io/v1alpha1

kind: Rollout

metadata:

  name: example-rollout

  namespace: production

spec:

  replicas: 2

  selector:

    matchLabels:

      app: example-rollout

  template:

    metadata:

      labels:

        app: example-rollout

    spec:

      containers:

        - name: example

          image: nginx:stable

          ports:

            - containerPort: 80

  strategy:

    canary:

      steps:

        - setWeight: 50

        - pause: { duration: 60 }

Apply this manifest to the same cluster and namespace:

kubectl apply -f example-rollout.yaml
kubectl get rollouts -n production

If this example appears correctly, the platform is healthy and your original spec likely contains subtle schema or label issues. If even the simple example fails, focus on cluster‑wide problems such as CRD registration, webhooks, or RBAC.

Step 4: Inspect Admission Webhook and Validation Errors

Argo Rollouts uses webhooks to enforce invariants and default certain fields. When a webhook rejects your rollout, you may see errors that mention admission failures. For instance:

Error from server (BadRequest): admission webhook “validate-rollout.argoproj.io” denied the request: invalid strategy: both canary and blueGreen specified

These messages explain exactly why the object was refused. Some typical causes include:

• Specifying both canary and blue-green under strategy.
• Omitting a selector that matches the pod template labels.
• Providing canary steps with invalid values or missing required fields.

Whenever you see an admission webhook message, take it at face value and adjust your manifest accordingly. The rollout will not be created until the webhook is satisfied.

Step 5: Check Selectors and Label Consistency

Even when a rollout is created successfully, it may not behave as expected if selectors and labels do not align. In some edge cases, it can seem as if the rollout is “missing” because no pods are associated with it.

Confirm that:

• spec.selector.matchLabels exactly matches the labels in spec.template.metadata.labels.
• No other deployment or rollout in the namespace uses the same selector; overlapping selectors can cause confusion.

You can inspect the rollout directly:

kubectl get rollout my-rollout -n production -o yaml

and verify that the labels and selectors line up. Once they do, the Argo Rollouts controller can create and manage the appropriate replica sets.

Step 6: Review RBAC for Rollout Creation

If you are working in a multi‑tenant cluster, it is possible that the user or service account applying your manifests lacks permission to create rollouts. In that case, you might see errors mentioning “forbidden” or “cannot create resource rollouts in API group argoproj.io.”

Check the error output from your apply command carefully. If permissions are the problem, coordinate with your cluster administrators to:

• Grant the necessary verbs (get, list, watch, create, update, delete) on rollouts.argoproj.io in the relevant namespaces.
• Or provide you with a dedicated service account and role binding for Argo Rollouts management.

Once RBAC is configured correctly, retry the apply and confirm that the rollout appears.

Step 7: Look for Conflicting Tools or Controllers

In more advanced setups, your cluster may have multiple tools that manage workloads, standard Deployments, GitOps controllers, admission controllers, or even other progressive delivery tools. Conflicts between these components can sometimes result in unexpected behavior around workload creation.

Ask yourself:

• Is a GitOps tool such as Argo CD or Flux also managing this namespace?
• Are there policies or mutating webhooks that rewrite manifests on the fly?

If the answer is yes, review their logs and configurations. It is possible that another controller is modifying or rejecting your rollout manifests before they reach the API server in the expected form.

Using kubectl Argo Rollouts for Rollout Visibility

Once you are confident that the rollout should exist but unsure how far it has progressed, the kubectl argo rollouts plugin provides detailed insights.

Run:

kubectl argo rollouts list rollouts -n production

and:

kubectl argo rollouts get rollout my-rollout -n production

These commands show you whether the rollout is present, which revision is current, and what the controller believes the status to be. If the rollout still does not appear here, you can be confident it was never created successfully and should return to earlier validation steps.

Conclusion: Treat Missing Rollouts as a Validation Problem First

When a rollout is not created, it is tempting to suspect deep issues with Argo Rollouts itself. In practice, most cases boil down to one of a few misconfigurations:

• The manifest failed schema or webhook validation.
• The rollout was created in a different namespace or context than you expect.
• RBAC or admission control prevented creation.
• Labels and selectors are inconsistent, hiding the rollout’s behavior.

By approaching the problem as a validation and configuration issue, you can systematically test a known‑good example, tighten up your manifests, and review admission and RBAC feedback.

Once the rollout is created reliably, you can turn your attention to higher‑level concerns such as strategy design, canary steps, and integration with metrics, confident that the underlying resource lifecycle is working as intended.

FAQs: Rollout Creation Issues in Argo Rollouts

Latest Post:

• How Argo Rollouts Works: Canary & Blue-Green Strategies
• Argo Rollouts Features: Blue-Green, Canary & Traffic Control
• Argo Rollouts vs Kubernetes Deployments: Key Differences & Benefits
• Is Argo Rollouts Safe? Security & Production Readiness Explained
• Business Use Cases for Argo Rollouts: Safe Deployments, KPIs & Continuous Delivery